From lasso at lassoweb.se Thu Feb 1 02:45:27 2007 From: lasso at lassoweb.se (Lars Olsson) Date: Thu, 1 Feb 2007 07:45:27 -0000 (UTC) Subject: [Nitro] Nitro and Firebrigade Message-ID: <27861.192.176.230.1.1170315927.squirrel@webmaiil.lassoweb.se> Hi! Firebrigade is new site which tests gems on different platforms: http://firebrigade.seattlerb.org/ Nitro has been submitted for testing, but unfortunatly doesn't seem to pass (it seems tests don't get called at all for some reason). I think it would be good to adjust Nitro to be able to use that site for testing. Running correctly on multiple platforms is a good thing :) Sincerely /lasso From george.moschovitis at gmail.com Thu Feb 1 03:47:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 1 Feb 2007 10:47:46 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <1170295160.404675.182690@p10g2000cwp.googlegroups.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> Message-ID: > > Fair enough. I've started tooling into this. One frustration: the > repo version doesn't pass tc_store.rb, which makes me a little I will work on the test cases today. Will push a new version later. -g. hesitant to whack around willy-nilly. I've got initial patch done > that's a non-functioning sketch of what I'm trying, but I'll wait > until I've got something finished before I waste anyone else's time > with it. > > > > > T. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-gene... at rubyforge > .orghttp://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070201/86af709a/attachment.html From fabian at fabian-buch.de Thu Feb 1 04:55:42 2007 From: fabian at fabian-buch.de (Fabian Buch) Date: Thu, 1 Feb 2007 10:55:42 +0100 Subject: [Nitro] Nitro and Firebrigade In-Reply-To: <27861.192.176.230.1.1170315927.squirrel@webmaiil.lassoweb.se> References: <27861.192.176.230.1.1170315927.squirrel@webmaiil.lassoweb.se> Message-ID: Am 01.02.2007 um 08:45 schrieb Lars Olsson: > Firebrigade is new site which tests gems on different platforms: > > http://firebrigade.seattlerb.org/ > > Nitro has been submitted for testing, but unfortunatly doesn't seem to > pass (it seems tests don't get called at all for some reason). Rails and most other's don't either. Maybe a bug in firebrigade? Fabian -- Nitro Q&A: http://oxyliquit.de LoxParts: http://loxparts.de Blog: http://blog.fabian-buch.de From george.moschovitis at gmail.com Thu Feb 1 04:58:15 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 1 Feb 2007 11:58:15 +0200 Subject: [Nitro] Facets symbol.to_s problem Message-ID: Tom, facets/core/symbol/to_s freezes the generated string, causing a lot of problems in Og, in code like: acc << symbol.to_s acc << "..." if ... can you please remove the .freeze ? There is a workaround of course "#{symbol}" but it looks uggly! -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070201/64c7049d/attachment.html From george.moschovitis at gmail.com Thu Feb 1 05:25:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 1 Feb 2007 12:25:44 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <1170295160.404675.182690@p10g2000cwp.googlegroups.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> Message-ID: > > Fair enough. I've started tooling into this. One frustration: the > repo version doesn't pass tc_store.rb, which makes me a little > hesitant to whack around willy-nilly. I've got initial patch done > Ok, I just updated the repo, and tc_store.rb passes, perhaps now you can work on your patch. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070201/16164635/attachment.html From george.moschovitis at gmail.com Thu Feb 1 07:43:51 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 1 Feb 2007 14:43:51 +0200 Subject: [Nitro] Nitroproject.org Message-ID: Dear devs, In February I would like to introduce a new version of the Nitroproject.orgsite. I want the Nitroproject.org site to be a central component of the Nitro experience: * It will host the documentation and the discussions of this mailing list. * Errors and info messaged in Nitro will point to the site. * I would like to introduce a mechanism of automatically acquiring Nitro parts/components/plugins on demand from this site (something like an automatic gen) I would like to spend the next two weeks planning the site. I am especially looking for suggestions on the layout of the site. I want the site to be beautiful, simple and accessible. If anyone can provide links to comparable sites I would really appreciate it. Of course, general ideas are welcome as well! best regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070201/bac11861/attachment.html From john at oxyliquit.de Thu Feb 1 09:14:17 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 01 Feb 2007 15:14:17 +0100 Subject: [Nitro] Nitroproject.org In-Reply-To: References: Message-ID: Hi > * It will host the documentation * rdoc * static documentation * wiki docs ? Together with kotrin from #nitro we had planned a page for static documentation already. The design is already finished, and the domain is supposed to be nitro-doc.com/org. Reliable static documentation, always updated for a certain version of Nitro is very much needed. As a reference the django doc is great. > * the discussions of this mailing list. A complete threaded news reader? > * Errors and info messaged in Nitro will point to the site. This sounds like a good idea. > * I would like to introduce a mechanism of automatically acquiring Nitro > parts/components/plugins on demand from this site (something like an > automatic gen) Be aware that http://www.loxparts.de/ from us thrives to provide that. > I would like to spend the next two weeks planning the site. I am especially > looking for suggestions on the layout of the site. I want the site to be > beautiful, simple and accessible. If anyone can provide links to comparable > sites I would really appreciate it. Of course, general ideas are welcome as > well! For using the mailing list: Integrating the bug tracker with the mailing list would be the best, operating on tags ([BUG]/[PATCH]). Similar pages, well, for docs the Django framework in python does this almost perfectly imo. http://www.djangoproject.com/documentation/ /me goes back to learning for networking... Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Thu Feb 1 10:17:02 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 01 Feb 2007 16:17:02 +0100 Subject: [Nitro] Nitroproject.org In-Reply-To: References: Message-ID: Hi, > Together with kotrin from #nitro we had planned a page for static > documentation already. The design is already finished, and the domain > is supposed to be nitro-doc.com/org. http://24.21.123.8:9000/ kotrin enabled the doc page again after I bugged him, many thanks! As you can see, 'everything' is in place, just the docs are missing. I would love, when everyone (even you, silent listener) could think of at least one part he would like documented and respond here. We could make a Table-Of-Contents first, then start filling it with Nitro 0.42 information. After that, kotrin can work on implementing some kind of versioning system, so it'll be ready when 0.43 gets released. kotrin unfortunately doesn't know much about Nitro, so he's not that much of a doc writer. But as with me, he perfers a static documentation over wikis. I love the work he's done already. So, we don't want to make Georges work look 'bad' or anything, we want to provide a 'habitat' around Nitro, so George can concentrate on Nitro and Og, and doesn't have to worry about (error) popping up on his pages diverting his attention away from the latest greatest features. ~_~ Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Thu Feb 1 10:30:41 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 15:30:41 -0000 Subject: [Nitro] Facets symbol.to_s problem In-Reply-To: References: Message-ID: <1170343841.810485.158220@v45g2000cwv.googlegroups.com> On Feb 1, 4:58 am, "George Moschovitis" wrote: > Tom, > > facets/core/symbol/to_s freezes the generated string, causing a lot of > problems in Og, in code like: > > acc << symbol.to_s > acc << "..." if ... > > can you please remove the .freeze ? There is a workaround of course > "#{symbol}" but it looks uggly! Okay. Will be in the next release. Thanks, T. From transfire at gmail.com Thu Feb 1 11:09:55 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 16:09:55 -0000 Subject: [Nitro] Nitroproject.org In-Reply-To: References: Message-ID: <1170346195.175844.327360@a34g2000cwb.googlegroups.com> On Feb 1, 9:14 am, "Jonathan Buch" wrote: > Hi > > > * It will host the documentation > > * rdoc > * static documentation We should have both. > * wiki docs We already have this enough in the Q&A site. > Together with kotrin from #nitro we had planned a page for static > documentation already. The design is already finished, and the domain > is supposed to be nitro-doc.com/org. > > Reliable static documentation, always updated for a certain version of > Nitro is very much needed. As a reference the django doc is great. > > > * the discussions of this mailing list. > > A complete threaded news reader? I would just have a link to the google group (despite the fact the the new interface sucks compared to the old one). No sense in repeating work that already done. > > * Errors and info messaged in Nitro will point to the site. > > This sounds like a good idea. > > > * I would like to introduce a mechanism of automatically acquiring Nitro > > parts/components/plugins on demand from this site (something like an > > automatic gen) > > Be aware thathttp://www.loxparts.de/from us thrives to provide that. Indeed. I think it behooves Nitro to harness separate "parts" like this rather then trying to do everything monolithically. I say just add redirection pages from nitroproject.org to these other sites. http://oxyliquit.de/ http://loxparts.de http://groups.google.com/group/nitro-general-google/topics?hl=en http://facets.rubyforge.org T. From transfire at gmail.com Thu Feb 1 11:13:22 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 16:13:22 -0000 Subject: [Nitro] Nitroproject.org In-Reply-To: References: Message-ID: <1170346402.764653.69750@k78g2000cwa.googlegroups.com> On Feb 1, 10:17 am, "Jonathan Buch" wrote: > Hi, > > > Together with kotrin from #nitro we had planned a page for static > > documentation already. The design is already finished, and the domain > > is supposed to be nitro-doc.com/org. > > http://24.21.123.8:9000/ > > kotrin enabled the doc page again after I bugged him, many thanks! very nice! couple of thoughts: could you change the top greenish header color to black with flames coming up- that would be cool. also, I think the left and right panes need to be equal sized. right now the right pane is too big and it looks a little uneven. great work! T. From nitrojesus.5.pistos at geoshell.com Thu Feb 1 12:34:21 2007 From: nitrojesus.5.pistos at geoshell.com (nitrojesus.5.pistos at geoshell.com) Date: Thu, 1 Feb 2007 12:34:21 -0500 Subject: [Nitro] Nitroproject.org In-Reply-To: References: Message-ID: <6c9d9ef0702010934l194b35ccmb131daae7610368d@mail.gmail.com> On 01/02/07, Jonathan Buch - john at oxyliquit.de wrote: > http://24.21.123.8:9000/ > I would love, when everyone (even you, silent listener) could think > of at least one part he would like documented and respond here. More [short] screencasts, and beginner/intro level tutorials. People need to be able to dive in easily, so that they can get hooked on how great Nitro and Og are. :) Things that I think tend to be good sales tools: - Why Nitro? (and not something else) - Why Og? (and not something else) Perhaps add: - Differences between Og and AR - Differences between Nitro and ___ There should probably also be a cookbookish section for lookup of snippets that answer "How do I ?" For more advanced developers, maybe a graphical overview of the pipeline of processing, from browser making HTTP request, to the innards of Nitro, all the way back to the browser. This would include what classes are involved, etc. Pistos From george.moschovitis at gmail.com Thu Feb 1 13:08:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 1 Feb 2007 20:08:09 +0200 Subject: [Nitro] Suggestion for next version of Facets Message-ID: Tom, I asked you before but please (PLEASE) consider including the multibyte libraries of ActiveSupport to the next version of Facets. Did I say PLEAAASE? ;-) -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070201/226704a4/attachment.html From nyarly at gmail.com Thu Feb 1 14:08:48 2007 From: nyarly at gmail.com (nyarly at gmail.com) Date: Thu, 01 Feb 2007 19:08:48 -0000 Subject: [Nitro] Facets symbol.to_s problem In-Reply-To: References: Message-ID: <1170356928.048379.158150@v45g2000cwv.googlegroups.com> On Feb 1, 1:58 am, "George Moschovitis" wrote: > Tom, > > facets/core/symbol/to_s freezes the generated string, causing a lot of > problems in Og, in code like: > > acc << symbol.to_s > acc << "..." if ... > > can you please remove the .freeze ? There is a workaround of course > "#{symbol}" but it looks uggly! Why do you need a facet for this? At least as of Ruby 1.8.5: $ ruby -e "p :test.to_s" "test" $ ruby -e "p :test.to_s.frozen?" false From transfire at gmail.com Thu Feb 1 15:14:45 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 20:14:45 -0000 Subject: [Nitro] Facets symbol.to_s problem In-Reply-To: <1170356928.048379.158150@v45g2000cwv.googlegroups.com> References: <1170356928.048379.158150@v45g2000cwv.googlegroups.com> Message-ID: <1170360885.201945.143740@m58g2000cwm.googlegroups.com> On Feb 1, 2:08 pm, "nya... at gmail.com" wrote: > On Feb 1, 1:58 am, "George Moschovitis" > wrote: > > > Tom, > > > facets/core/symbol/to_s freezes the generated string, causing a lot of > > problems in Og, in code like: > > > acc << symbol.to_s > > acc << "..." if ... > > > can you please remove the .freeze ? There is a workaround of course > > "#{symbol}" but it looks uggly! > > Why do you need a facet for this? At least as of Ruby 1.8.5: class Symbol # Same functionality as before, just a touch more efficient. def to_s @to_s || (@to_s = id2name) end end Not sure why it was being frozen. (Although some people have suggested getting rid of symbols in RUby 2.0 and replacing them with frozen strings) T. From transfire at gmail.com Thu Feb 1 15:20:00 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 20:20:00 -0000 Subject: [Nitro] Suggestion for next version of Facets In-Reply-To: References: Message-ID: <1170361200.913657.48920@v45g2000cwv.googlegroups.com> On Feb 1, 1:08 pm, "George Moschovitis" wrote: > Tom, > > I asked you before but please (PLEASE) consider including the multibyte > libraries of ActiveSupport to the next version of Facets. > Did I say PLEAAASE? ;-) Sorry. I had forgotten about that. Will do, T. From transfire at gmail.com Thu Feb 1 15:21:40 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 20:21:40 -0000 Subject: [Nitro] Facets 2.0 In-Reply-To: <05d401c74475$f2296510$0301a8c0@ghostgum> References: <4b6f054f0701291807u5b3af249m4721f2ed381d6d03@mail.gmail.com> <05d401c74475$f2296510$0301a8c0@ghostgum> Message-ID: <1170361300.422441.320150@j27g2000cwj.googlegroups.com> On Jan 30, 8:52 am, * William wrote: > Hi folks ... > > I like this. May I add one comment? > > Make it .... > > require 'facets/base' > require 'facets/core' > and > require 'facets/app' > require 'facets/usr' > require 'facets/etc' > > Or something along those lines. I'm not sure I follow --Facets being just a library, usr/, app/ etc. doesn't seem to apply. Or am I misunderstanding? Thanks, T. From nyarly at gmail.com Thu Feb 1 17:49:17 2007 From: nyarly at gmail.com (nyarly at gmail.com) Date: Thu, 01 Feb 2007 22:49:17 -0000 Subject: [Nitro] Facets Aspects problem Message-ID: <1170370157.640802.27940@q2g2000cwa.googlegroups.com> In trying to reduce the amount of eval'd code in Og I ran across the following fascinating snippet in facets/more/aspects.rb: target.instance_method(m).arity.times { |i| args << "a#{i}" } Which is fine, unless the method takes a variable number of arguments, in which case, the advised version of the method suddenly takes no arguments. Can I suggest: arity = target.instance_method(m).arity if arity < 0 (-(arity + 1).times{ |i| args << "a#{i}" } args << "*argv" else arity.times { |i| args << "a#{i}" } end Working on a workaround... From transfire at gmail.com Thu Feb 1 18:01:50 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 23:01:50 -0000 Subject: [Nitro] reap name 4 rake project Message-ID: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> One of my infamous "please help me name this damn thing" posts.... Alright, after lot of wrestling I've finally come to a conclusion and converted all my build tools to bonofide Rake tasks, along with an automator the sets these tasks up automatically based on one's ProjectInfo file (talk about coming full circle!) . I'm going to release the ProjectInfo class as a separate project (maybe others can build tools that key off of it too) and it will be a subrpoject of a larger project called Ratchets. Though I'm not sure if it will be "projectinfo.gem" or just "pinfo.gem" (opinions?) Anyway, I'm wondering what to call the project with these tasks? (Which will also be a subproject of Ratchets, btw) Should I stick with 'reap' even though the tasks are now for rake? Or should I use the new code name I've been developing them under, '4rake'. Or is there some other name that would be better? I like 'reap' b/c it's what I had been using -- those already aware of it will recognize it. But I also like '4rake' b/ c... well, b/c it's pretty dang obvious what it is for ;-) Suggestions? Thanks, T. From transfire at gmail.com Thu Feb 1 18:11:42 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 01 Feb 2007 23:11:42 -0000 Subject: [Nitro] Facets Aspects problem In-Reply-To: <1170370157.640802.27940@q2g2000cwa.googlegroups.com> References: <1170370157.640802.27940@q2g2000cwa.googlegroups.com> Message-ID: <1170371502.901304.286830@a75g2000cwd.googlegroups.com> On Feb 1, 5:49 pm, "nya... at gmail.com" wrote: > In trying to reduce the amount of eval'd code in Og I ran across the > following fascinating snippet in facets/more/aspects.rb: > > target.instance_method(m).arity.times { |i| args << "a#{i}" } > > Which is fine, unless the method takes a variable number of arguments, > in which case, the advised version of the method suddenly takes no > arguments. Good catch. That has to change. > Can I suggest: > > arity = target.instance_method(m).arity > if arity < 0 > (-(arity + 1).times{ |i| args << "a#{i}" } > args << "*argv" > else > arity.times { |i| args << "a#{i}" } > end > > Working on a workaround... Is this even eval'd too? What up with the "a#{i}"? Any wrapped method can work with: (*a, &b) No matter what the original args are. Hold on, let me look at the code... Okay try this: for m in [methods].flatten target.module_eval <<-end_eval, __FILE__, __LINE__ alias_method :__unwrapped_#{m}, :#{m} def #{m}(*a,&b) #{gen_advice_code(m, target.advices, :pre)} __unwrapped_#{m}(*a,&b) #{gen_advice_code(m, target.advices, :post)} end end_eval end Let me know. T. From nyarly at gmail.com Thu Feb 1 18:59:08 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 1 Feb 2007 15:59:08 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> Message-ID: <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Hey, and a patch. What'd'you know? So far, this is just og/store/sql.rb, but that seemed to be the biggest offender. Please let me know what you think, and I'll keep your comments in mind going forward. As the comment in the patch says, I suspect there are still some stray methods that existed in Og::SqlStore in order to support the eval_og_* methods that have been at least copied to the modules, so there might be room to do a little tidying up. Judson -------------- next part -------------- A non-text attachment was scrubbed... Name: eval-roundup.darcs Type: application/octet-stream Size: 102259 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070201/d0b5e713/attachment-0001.obj From nyarly at gmail.com Thu Feb 1 19:01:57 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 1 Feb 2007 16:01:57 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Message-ID: <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> One caveat: that patch relies on a fix to aspects.rb described elsewhere. I was a little loath to open a foreign module in og/store/sql.rb. Thoughts on how to resolve that would be appreciated. Judson From nyarly at gmail.com Thu Feb 1 20:07:27 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 1 Feb 2007 17:07:27 -0800 Subject: [Nitro] Facets Aspects problem In-Reply-To: <1170371502.901304.286830@a75g2000cwd.googlegroups.com> References: <1170370157.640802.27940@q2g2000cwa.googlegroups.com> <1170371502.901304.286830@a75g2000cwd.googlegroups.com> Message-ID: <8905c87a0702011707q7106c370n54ffcbc9763928d8@mail.gmail.com> On 2/1/07, transfire at gmail.com wrote: > > > On Feb 1, 5:49 pm, "nya... at gmail.com" wrote: > > In trying to reduce the amount of eval'd code in Og I ran across the > > following fascinating snippet in facets/more/aspects.rb: > > > > target.instance_method(m).arity.times { |i| args << "a#{i}" } > > > > Which is fine, unless the method takes a variable number of arguments, > > in which case, the advised version of the method suddenly takes no > > arguments. > > Good catch. That has to change. > > > Can I suggest: > > > > arity = target.instance_method(m).arity > > if arity < 0 > > (-(arity + 1).times{ |i| args << "a#{i}" } > > args << "*argv" > > else > > arity.times { |i| args << "a#{i}" } > > end > > > > Working on a workaround... > > Is this even eval'd too? What up with the "a#{i}"? Any wrapped method > can work with: > > (*a, &b) > > No matter what the original args are. Hold on, let me look at the > code... Okay try this: > > for m in [methods].flatten > target.module_eval <<-end_eval, __FILE__, __LINE__ > alias_method :__unwrapped_#{m}, :#{m} > def #{m}(*a,&b) > #{gen_advice_code(m, target.advices, :pre)} > __unwrapped_#{m}(*a,&b) > #{gen_advice_code(m, target.advices, :post)} > end > end_eval > end > > Let me know. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From transfire at gmail.com Thu Feb 1 20:17:15 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 02 Feb 2007 01:17:15 -0000 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> Message-ID: <1170379035.867893.147420@p10g2000cwp.googlegroups.com> On Feb 1, 7:01 pm, "Judson Lester" wrote: > One caveat: that patch relies on a fix to aspects.rb described > elsewhere. I was a little loath to open a foreign module in > og/store/sql.rb. Thoughts on how to resolve that would be > appreciated. Just fix aspects.rb in your local install while you work on it, when your pretty sure it's working right let me know and I'll patch facets and make a new release. Usually I can have that done in a day. T. From nyarly at gmail.com Thu Feb 1 22:59:33 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 1 Feb 2007 19:59:33 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: <1170379035.867893.147420@p10g2000cwp.googlegroups.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> <1170379035.867893.147420@p10g2000cwp.googlegroups.com> Message-ID: <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> On 2/1/07, transfire at gmail.com wrote: > Just fix aspects.rb in your local install while you work on it, when > your pretty sure it's working right let me know and I'll patch facets > and make a new release. Usually I can have that done in a day. > Sounds good to me. Quick question about Aspect::wrap, though. If a class has been Aspect::wrap'd, and you wrap it again, you'll get a stack overflow error when those methods get called. On the other hand, from what I can see, wrap puts the advice code around the methods when it's called; my impression therefore is that AOP on subclasses can't take. Is this the right venue to talk about that? Judson From transfire at gmail.com Thu Feb 1 23:32:10 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 02 Feb 2007 04:32:10 -0000 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> <1170379035.867893.147420@p10g2000cwp.googlegroups.com> <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> Message-ID: <1170390730.637372.141200@a34g2000cwb.googlegroups.com> On Feb 1, 10:59 pm, "Judson Lester" wrote: > On 2/1/07, transf... at gmail.com wrote: > > > Just fix aspects.rb in your local install while you work on it, when > > your pretty sure it's working right let me know and I'll patch facets > > and make a new release. Usually I can have that done in a day. > > Sounds good to me. Quick question about Aspect::wrap, though. If a > class has been Aspect::wrap'd, and you wrap it again, you'll get a > stack overflow error when those methods get called. Hmm.. that's not good. > On the other > hand, from what I can see, wrap puts the advice code around the > methods when it's called; my impression therefore is that AOP on > subclasses can't take. Is this the right venue to talk about that? Sure. I'm not sure it should effect subclasses. However aspects.rb isn't true AOP. I've haven't studied it enough to understand exactly how it works. (George is the author). But basically it's seems to be more a sophisticated method wrapping system. I've wondered on occasion how possible it would be to rewrite aspects.rb on top of cuts.rb. T. From nyarly at gmail.com Fri Feb 2 02:48:45 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 1 Feb 2007 23:48:45 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: <1170390730.637372.141200@a34g2000cwb.googlegroups.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> <1170379035.867893.147420@p10g2000cwp.googlegroups.com> <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> <1170390730.637372.141200@a34g2000cwb.googlegroups.com> Message-ID: <8905c87a0702012348u3b81a8c7x6673ddd382092743@mail.gmail.com> On 2/1/07, transfire at gmail.com wrote: > Sure. > > I'm not sure it should effect subclasses. > > However aspects.rb isn't true AOP. I've haven't studied it enough to > understand exactly how it works. (George is the author). But basically > it's seems to be more a sophisticated method wrapping system. I've > wondered on occasion how possible it would be to rewrite aspects.rb on > top of cuts.rb. Having spent a couple of hours looking at both, it seems very doable. However: The biggest thing that Aspects does that would be tricky to replicate with cuts is incorporating strings as advice and the methods of advice modules. I can see how that could be done, but especially regarding using Strings, I'm a little dubious. Is that a feature of Aspects that's actually used? Regarding cut.rb, I'm a little leery of how fragile it seems to be. The comments suggest that it should be that absolute first file required, which is sort of a smell right there. It looks like a lot of the stuff that wants to go into Class and Module might instead be able to be included into classes that get cut. Maybe some sort of hybrid library would be preferable? The metaprogrammic nicety of cut with the features of aspects, or the like. Judson From george.moschovitis at gmail.com Fri Feb 2 03:57:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 2 Feb 2007 10:57:09 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702012348u3b81a8c7x6673ddd382092743@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> <1170379035.867893.147420@p10g2000cwp.googlegroups.com> <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> <1170390730.637372.141200@a34g2000cwb.googlegroups.com> <8905c87a0702012348u3b81a8c7x6673ddd382092743@mail.gmail.com> Message-ID: > > modules. I can see how that could be done, but especially regarding > using Strings, I'm a little dubious. Is that a feature of Aspects > that's actually used? This is used, but if needed the affected parts can be rewritten. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070202/3d111caf/attachment.html From george.moschovitis at gmail.com Fri Feb 2 03:57:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 2 Feb 2007 10:57:57 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Message-ID: Thanks, I will have a look at this patch. -g. On 2/2/07, Judson Lester wrote: > > Hey, and a patch. What'd'you know? So far, this is just > og/store/sql.rb, but that seemed to be the biggest offender. Please > let me know what you think, and I'll keep your comments in mind going > forward. > > As the comment in the patch says, I suspect there are still some stray > methods that existed in Og::SqlStore in order to support the eval_og_* > methods that have been at least copied to the modules, so there might > be room to do a little tidying up. > > Judson > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070202/c522fb5c/attachment.html From george.moschovitis at gmail.com Fri Feb 2 05:19:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 2 Feb 2007 12:19:57 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Message-ID: Please, when working with Nitro's source code use 2 spaces for identation (not tabs). -g. On 2/2/07, George Moschovitis wrote: > > Thanks, > > I will have a look at this patch. > > -g. > > On 2/2/07, Judson Lester wrote: > > > Hey, and a patch. What'd'you know? So far, this is just > > og/store/sql.rb, but that seemed to be the biggest offender. Please > > let me know what you think, and I'll keep your comments in mind going > > forward. > > > > As the comment in the patch says, I suspect there are still some stray > > methods that existed in Og::SqlStore in order to support the eval_og_* > > methods that have been at least copied to the modules, so there might > > be room to do a little tidying up. > > > > Judson > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070202/f0cf7c5b/attachment-0001.html From george.moschovitis at gmail.com Fri Feb 2 05:41:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 2 Feb 2007 12:41:39 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Message-ID: Does this patch work? I applied it and get a bunch of errors... another thing, why are read/write_attr defined twice? I am attaching the slightly changed version for you to work on... -g. On 2/2/07, George Moschovitis wrote: > > Please, when working with Nitro's source code use 2 spaces for identation > (not tabs). > > -g. > > On 2/2/07, George Moschovitis < george.moschovitis at gmail.com> wrote: > > > > Thanks, > > > > I will have a look at this patch. > > > > -g. > > > > On 2/2/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > Hey, and a patch. What'd'you know? So far, this is just > > > og/store/sql.rb, but that seemed to be the biggest offender. Please > > > let me know what you think, and I'll keep your comments in mind going > > > forward. > > > > > > As the comment in the patch says, I suspect there are still some stray > > > methods that existed in Og::SqlStore in order to support the eval_og_* > > > > > > methods that have been at least copied to the modules, so there might > > > be room to do a little tidying up. > > > > > > Judson > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070202/8d57e696/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sql.rb Type: application/x-ruby Size: 30254 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070202/8d57e696/attachment-0001.bin From transfire at gmail.com Fri Feb 2 08:13:06 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 02 Feb 2007 13:13:06 -0000 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702012348u3b81a8c7x6673ddd382092743@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702011601p3513fcc7je1f95c5647ed5849@mail.gmail.com> <1170379035.867893.147420@p10g2000cwp.googlegroups.com> <8905c87a0702011959y4018295bucc34192a947b8aae@mail.gmail.com> <1170390730.637372.141200@a34g2000cwb.googlegroups.com> <8905c87a0702012348u3b81a8c7x6673ddd382092743@mail.gmail.com> Message-ID: <1170421986.858128.286830@v45g2000cwv.googlegroups.com> On Feb 2, 2:48 am, "Judson Lester" wrote: > Having spent a couple of hours looking at both, it seems very doable. However: > > The biggest thing that Aspects does that would be tricky to replicate > with cuts is incorporating strings as advice and the methods of advice > modules. I can see how that could be done, but especially regarding > using Strings, I'm a little dubious. Is that a feature of Aspects > that's actually used? case in point where i have no idea how this works. how are strings advice? btw aspects.rb needs two things real bad: better examples and testcases. > Regarding cut.rb, I'm a little leery of how fragile it seems to be. > The comments suggest that it should be that absolute first file > required, which is sort of a smell right there. understandable and I am alittelmyself too. a true implementation of cut-based aop would have to be implemented in ruby's c code. cut.rb is about as close as I think one can get in pure ruby. but it's still a relativley new lib that hasn't been thourghly tested. it's hard to say how fragile it is in the long run. the reason that it has to be required first is becuase it effects all objects. if an object is instantiated before cut.rb is required, then you will not be able to cut it --usually that is not a problem, but it's important to know. > It looks like a lot > of the stuff that wants to go into Class and Module might instead be > able to be included into classes that get cut. can you elaborate? > Maybe some sort of hybrid library would be preferable? The > metaprogrammic nicety of cut with the features of aspects, or the > like. well, cuts is "low-level", so i don't see hybridization being practical. cuts works by intercepting the #new call, so that any instantiation of a class will be extended by a proxycut that holds the advice. on the other hand, aspects.rb works by alias-wrapping every method of a class. ideally cuts should be quite robust and serve as a good foundation to build any aop-like lib, such as aspects.rb, but as i said it remains to be seen how robust cut.rb is and/or what improvements it may yet need to do the job well. i think it would be worth the effort to try. if it works it will ensure the robustness of both cut.rb and aspects.rb, if not then at least we'll know if cut.rb is even worth keeping around, and i'm sure aspects.rb will be improved by the effort nonetheless. T. P.S. I keep wanting to put cuts.rb rather then cut.rb ... maybe I should change the name. From nyarly at gmail.com Fri Feb 2 13:48:01 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 2 Feb 2007 10:48:01 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> Message-ID: <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> On 2/2/07, George Moschovitis wrote: > Does this patch work? I applied it and get a bunch of errors... To be honest, darcs is not my most proficient version control system. I think it works... the code it comes from is in my current og dev library. > another thing, why are read/write_attr defined twice? As I said, there are some stray methods. I'll go through and clean it up, see what I can strip out. Would you say that tc_store.rb tests sql.rb thoroughly? I don't want to introduce a huge break by deleting an important method. > I am attaching the slightly changed version for you to work on... Thanks, I'll put it in place of my existing sql.rb Regarding style, I've switched my editor config over to never use tabs for indents. Is the lack of indent inside the first module a project style issue as well? Judson From nyarly at gmail.com Fri Feb 2 15:49:07 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 2 Feb 2007 12:49:07 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> Message-ID: <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> Okay, I've reworked read_attr and write_attr, which meant adapting the change out to MySqlAdapter as well. I suspect the same will be true for the other Adaptors, in which case, I'm temped to make further changes to read_attr and write_attr to mimize those changes in the Adaptors. Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: rw_attr.patch Type: text/x-patch Size: 79367 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070202/c32cc027/attachment-0001.bin From nyarly at gmail.com Fri Feb 2 16:43:08 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 2 Feb 2007 13:43:08 -0800 Subject: [Nitro] [OG] Aspects, cuts [was: eval and style] Message-ID: <8905c87a0702021343x30c30b00ie067cca8f8c8afbd@mail.gmail.com> On 2/2/07, transfire at gmail.com wrote: > On Feb 2, 2:48 am, "Judson Lester" wrote: > > Having spent a couple of hours looking at both, it seems very doable. However: > > > > The biggest thing that Aspects does that would be tricky to replicate > > with cuts is incorporating strings as advice and the methods of advice > > modules. I can see how that could be done, but especially regarding > > using Strings, I'm a little dubious. Is that a feature of Aspects > > that's actually used? > > case in point where i have no idea how this works. how are strings > advice? Because of the way wrap works, strings are the simplest possible case of advice. They're interpolated directly into the new method. It seems like the wrapped methods really ought to do something like call_advice_post __unwrapped_method call_advice_post Or something. I'm not sure if advice should change after the fact or not. A cut based replacement might be a better option, though. > > Regarding cut.rb, I'm a little leery of how fragile it seems to be. > > The comments suggest that it should be that absolute first file > > required, which is sort of a smell right there. > > understandable and I am alittelmyself too. .... if an object is > instantiated before cut.rb is required, then you will not be able to > cut it --usually that is not a problem, but it's important to know. I'm still examining the problem, but it seems as if it should be possible for cut.rb to alter classes as needed, regardless of when it's required, since the key changes are made to the class, and all but singleton methods come from the class as-it-is not when-intantiated. Fiddling with cut.rb, I can see that the magic comes by creating a proxy class. Initial thought: what if instead a shadow class were created to hold the original methods, and calls were somehow delegated there. There are obvious scoping issues with this, but it would allow pre-existing classes to be cut. > > It looks like a lot > > of the stuff that wants to go into Class and Module might instead be > > able to be included into classes that get cut. > > can you elaborate? Essentially, a Class that's been cut would have a new definition of "include" and "extend" that function as the reverse of Module#included, and have the method current in Class mixed in. Again, this would rely on inverting the relationship of the proxycut class and the cut class, and resolving the issues that creates. Honestly, the more I look at this, the more it's a huge architectural change. Let me go away and fiddle with it, and I'll get back to you. > > > Maybe some sort of hybrid library would be preferable? The > > metaprogrammic nicety of cut with the features of aspects, or the > > like. > > well, cuts is "low-level", so i don't see hybridization being > practical. I really wasn't clear there, I think. It seems trivial to add Cut#pre and Cut#post, and so incorporate most of Aspect's features. > T. > > P.S. I keep wanting to put cuts.rb rather then cut.rb ... maybe I > should change the name. Ah, but the crucial method is Kernel#cut. I'd recommend keeping the name. From george.moschovitis at gmail.com Fri Feb 2 17:59:20 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 3 Feb 2007 00:59:20 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> Message-ID: Thanks, I am working on a rather big change at the moment (new dispatcher for nitro) but I will try to have a look at this tomorrow. -g. On 2/2/07, Judson Lester wrote: > > Okay, I've reworked read_attr and write_attr, which meant adapting the > change out to MySqlAdapter as well. I suspect the same will be true > for the other Adaptors, in which case, I'm temped to make further > changes to read_attr and write_attr to mimize those changes in the > Adaptors. > > Patch attached. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/d9dd7bc0/attachment.html From george.moschovitis at gmail.com Fri Feb 2 18:01:32 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 3 Feb 2007 01:01:32 +0200 Subject: [Nitro] Emmiter Message-ID: Dear devs, I am reviewing the source code, trying to clean it up a bit. Is anyone using the Emmiter code in lib/nitro/render.rb? I would like to remove this if no-one is using it. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/aa92bf9c/attachment.html From transfire at gmail.com Fri Feb 2 18:07:11 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 02 Feb 2007 23:07:11 -0000 Subject: [Nitro] [OG] Aspects, cuts [was: eval and style] In-Reply-To: <8905c87a0702021343x30c30b00ie067cca8f8c8afbd@mail.gmail.com> References: <8905c87a0702021343x30c30b00ie067cca8f8c8afbd@mail.gmail.com> Message-ID: <1170457631.322480.8510@v33g2000cwv.googlegroups.com> On Feb 2, 4:43 pm, "Judson Lester" wrote: > On 2/2/07, transf... at gmail.com wrote: > > > On Feb 2, 2:48 am, "Judson Lester" wrote: > > > Having spent a couple of hours looking at both, it seems very doable. However: > > > > The biggest thing that Aspects does that would be tricky to replicate > > > with cuts is incorporating strings as advice and the methods of advice > > > modules. I can see how that could be done, but especially regarding > > > using Strings, I'm a little dubious. Is that a feature of Aspects > > > that's actually used? > > > case in point where i have no idea how this works. how are strings > > advice? > > Because of the way wrap works, "strings are the simplest possible case > of advice." by "strings are the simplest possible case of advice." do you mean adding aspects to the String class? I'm not understanding something basic about this. > They're interpolated directly into the new method. hmm... or do you mean that the pre and post code is defined as a string, eg "x + y" rather than a block { x + y } > It seems like the wrapped methods really ought to do something like > > call_advice_post > __unwrapped_method > call_advice_post > > Or something. I'm not sure if advice should change after the fact or > not. A cut based replacement might be a better option, though. > > > > Regarding cut.rb, I'm a little leery of how fragile it seems to be. > > > The comments suggest that it should be that absolute first file > > > required, which is sort of a smell right there. > > > understandable and I am alittelmyself too. .... if an object is > > instantiated before cut.rb is required, then you will not be able to > > cut it --usually that is not a problem, but it's important to know. > > I'm still examining the problem, but it seems as if it should be > possible for cut.rb to alter classes as needed, regardless of when > it's required, since the key changes are made to the class, and all > but singleton methods come from the class as-it-is not > when-intantiated. Yes, but if a class is instantiated (ie. X.new) then the resulting object can't be cut unless cut.rb has already been loaded. hmm... in fact it may not effect any object whose class wan't already cut when it was instantiated. I don't recall for sure though. > Fiddling with cut.rb, I can see that the magic comes by creating a > proxy class. Initial thought: what if instead a shadow class were > created to hold the original methods, and calls were somehow delegated > there. There are obvious scoping issues with this, but it would allow > pre-existing classes to be cut. the proxy class is a subclass of the original so it's essentially shadowed already. the problem is harder than you might expect. (btw i've been getting this implemenation a little mixed up with my last one that used a object extending module as the proxy rather than a subclass --so a couple of my previous comments are off a little. sorry) in anycase, i think the pre-existing classes issue isn't too serious, i'm not sure what could prevent one form requiring 'cut.rb' early on, as this issue only effects objects already instantiated prior to loading cut.rb. but perhaps there's something i'm missing. > > > It looks like a lot > > > of the stuff that wants to go into Class and Module might instead be > > > able to be included into classes that get cut. > > > can you elaborate? > > Essentially, a Class that's been cut would have a new definition of > "include" and "extend" that function as the reverse of > Module#included, and have the method current in Class mixed in. > > Again, this would rely on inverting the relationship of the proxycut > class and the cut class, and resolving the issues that creates. > > Honestly, the more I look at this, the more it's a huge architectural > change. Let me go away and fiddle with it, and I'll get back to you. okay. FYI. Cut-based AOP, is founded on some theory. you can read about it here: http://rcrchive.net/rcrs/1 I would have directed you to the original on the rubygarden wiki, but the site is down :-( > > > Maybe some sort of hybrid library would be preferable? The > > > metaprogrammic nicety of cut with the features of aspects, or the > > > like. > > > well, cuts is "low-level", so i don't see hybridization being > > practical. > > I really wasn't clear there, I think. It seems trivial to add Cut#pre > and Cut#post, and so incorporate most of Aspect's features. oh I see. yes, that's doable via an extension. and that's basically what I meant by wondering if aspects.rb could be built on top of cut.rb. i don't know enough about how pre and post work to say for sure though. > > P.S. I keep wanting to put cuts.rb rather then cut.rb ... maybe I > > should change the name. > > Ah, but the crucial method is Kernel#cut. I'd recommend keeping the name. true. I'll keep it. thanks. T. From nyarly at gmail.com Fri Feb 2 20:38:23 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 2 Feb 2007 17:38:23 -0800 Subject: [Nitro] [OG] Aspects, cuts [was: eval and style] In-Reply-To: <1170457631.322480.8510@v33g2000cwv.googlegroups.com> References: <8905c87a0702021343x30c30b00ie067cca8f8c8afbd@mail.gmail.com> <1170457631.322480.8510@v33g2000cwv.googlegroups.com> Message-ID: <8905c87a0702021738l4d6e940eod96492876f92261e@mail.gmail.com> On 2/2/07, transfire at gmail.com wrote: > > > On Feb 2, 4:43 pm, "Judson Lester" wrote: > > On 2/2/07, transf... at gmail.com wrote: > > They're interpolated directly into the new method. > > hmm... or do you mean that the pre and post code is defined as a > string, eg "x + y" rather than a block { x + y } That's exactly it. Aspect::wrap aliases out the old method and redefines it as an eval'd string, which interpolates the pre and post advice for the method - even block calls are accomplished by interpolating something like "block_find.call" > > I'm still examining the problem, but it seems as if it should be > > possible for cut.rb to alter classes as needed, regardless of when > > it's required, since the key changes are made to the class, and all > > but singleton methods come from the class as-it-is not > > when-intantiated. > > Yes, but if a class is instantiated (ie. X.new) then the resulting > object can't be cut unless cut.rb has already been loaded. hmm... in > fact it may not effect any object whose class wan't already cut when > it was instantiated. I don't recall for sure though. A quick spin with irb confirms that instances of X instantiated before cut.rb was required are not modified, but even if X is defined before cut.rb is required, then instances created after cut.rb is required can be modified. > > > Fiddling with cut.rb, I can see that the magic comes by creating a > > proxy class. Initial thought: what if instead a shadow class were > > created to hold the original methods, and calls were somehow delegated > > there. There are obvious scoping issues with this, but it would allow > > pre-existing classes to be cut. > > the proxy class is a subclass of the original so it's essentially > shadowed already. the problem is harder than you might expect. (btw > i've been getting this implemenation a little mixed up with my last > one that used a object extending module as the proxy rather than a > subclass --so a couple of my previous comments are off a little. > sorry) in anycase, i think the pre-existing classes issue isn't too > serious, i'm not sure what could prevent one form requiring 'cut.rb' > early on, as this issue only effects objects already instantiated > prior to loading cut.rb. but perhaps there's something i'm missing. Oh, I completely recognize that it's more complicated than it looks. My apologies if I've sounded at all underwhelmed of any of facets or nitro/og - I'm incredibly impressed by both projects or I wouldn't have stuck around so long. For the most part, I think my objections are aesthetic. The order-of-require issue could be a problem elsewhere - if another library has a similar requirement, for instance. The other niggle is that it modifies all classes, instead of just classes that need to be cut. That's why I raised the idea of modifying the cut class only. > > okay. FYI. Cut-based AOP, is founded on some theory. you can read > about it here: > > http://rcrchive.net/rcrs/1 > Thanks very much. I was trying to find a concise version of just the theory to refresh from. All I could find is a lot of AspectJ hype. Judson From george.moschovitis at gmail.com Sat Feb 3 04:54:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 3 Feb 2007 11:54:09 +0200 Subject: [Nitro] Consistency Message-ID: Dear devs, I will perform the following changes to the source code (to make it little more consistent): - use everywhere alias instead of alias_method - use the name uri instead of url - use facets/more,facets/core instead of facet If anyone has any objection please let me know. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/d18343d6/attachment.html From john at oxyliquit.de Sat Feb 3 07:30:31 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 03 Feb 2007 13:30:31 +0100 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170281082.568410.307780@k78g2000cwa.googlegroups.com> <1170282901.617692.159970@a75g2000cwd.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> Message-ID: Hi, > Regarding style, I've switched my editor config over to never use tabs > for indents. Is the lack of indent inside the first module a project > style issue as well? Yeah, this is usually done in Nitro, to avoid 'unecessary' indenting of the 'actual' code, as everything should be in Nitro/Og space anyway. I do that in other projects as well, where there is only one 'namespace' module which wraps around each and every file. Other style issues: one empty line between comment and method, 2 spaces for one indent, `def meth(arg, arg)` (use brackets in method definitions) and that's basically it. I myself prefer empty lines to be indended as the current indend, but I think others here prefer lines which are empty to be 'really' empty. Just don't make spaces as the last character after a non-space and before a line break. I hope that helps writing halfway standard Nitro code. :P Noone here is a real stickler about that (well, except tabs..). Btw, I appriciate your work regarding Og simplicity very much! When you work on the MySQL adapter, that's fine, I'll adapt the sqlite and postgres adapters accordingly, so you don't have to worry about that. The Og test suite is quite good actually, and should tell you where something is going wrong. One thing to keep in mind, the tcs are sometimes quite 'near' at the implementation, so when you're getting rediculous results, it might be the tc which just assumes something it shouldn't. So, welcome to Nito dev land, Judson! Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Feb 3 07:36:32 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 03 Feb 2007 13:36:32 +0100 Subject: [Nitro] Emmiter In-Reply-To: References: Message-ID: Hi, > I am reviewing the source code, trying to clean it up a bit. Is anyone using > the Emmiter code in lib/nitro/render.rb? I would like to remove this if > no-one is using it. not using it, ok for me. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Feb 3 07:42:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 03 Feb 2007 13:42:28 +0100 Subject: [Nitro] Consistency In-Reply-To: References: Message-ID: Hi, > - use everywhere alias instead of alias_method > - use the name uri instead of url > - use facets/more,facets/core instead of facet > > If anyone has any objection please let me know. no objection today. :P except that url is a little more common than uri perhaps... http://www.google.com/trends?q=url,+uri&date=all&geo=all&ctab=1&sa=N uri is (as I remember from some class) also stuff like the ISBN, for web stuff plain URL might be better in the Nitro case... So how about the other way round, all uri > url? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Feb 3 08:47:25 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 3 Feb 2007 15:47:25 +0200 Subject: [Nitro] Consistency In-Reply-To: References: Message-ID: > > uri is (as I remember from some class) also stuff like the ISBN, > for web stuff plain URL might be better in the Nitro case... > So how about the other way round, all uri > url? > No, uri is the correct term. Consult Wikipedia for the details. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/9a6e75c7/attachment.html From transfire at gmail.com Sat Feb 3 09:42:12 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 03 Feb 2007 14:42:12 -0000 Subject: [Nitro] Consistency In-Reply-To: References: Message-ID: <1170513732.165597.154110@q2g2000cwa.googlegroups.com> On Feb 3, 4:54 am, "George Moschovitis" wrote: > Dear devs, > > I will perform the following changes to the source code (to make it little > more consistent): > > - use everywhere alias instead of alias_method downside of this it that alias can't take a variable. a = "newtest" b = "test" alias a b doesn't work. so if you want it all the same every where use alias_method. t. From george.moschovitis at gmail.com Sat Feb 3 10:09:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 3 Feb 2007 17:09:18 +0200 Subject: [Nitro] Consistency In-Reply-To: <1170513732.165597.154110@q2g2000cwa.googlegroups.com> References: <1170513732.165597.154110@q2g2000cwa.googlegroups.com> Message-ID: interesting, but I don't think we are using a variable anywhere (if we do, we canuse one or two alias_methods). -g. downside of this it that alias can't take a variable. > > a = "newtest" > b = "test" > alias a b > > doesn't work. so if you want it all the same every where use > alias_method. > > t. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/b124691d/attachment.html From william.full.moon at gmail.com Sat Feb 3 11:36:00 2007 From: william.full.moon at gmail.com (* William) Date: Sun, 4 Feb 2007 03:36:00 +1100 Subject: [Nitro] Nitroproject.org In-Reply-To: <6c9d9ef0702010934l194b35ccmb131daae7610368d@mail.gmail.com> References: <6c9d9ef0702010934l194b35ccmb131daae7610368d@mail.gmail.com> Message-ID: <006101c747b1$67bad730$0301a8c0@ghostgum> Hi men/women There is a small challenge with this call for action. The sands shift beneath the documentation. > I would love, when everyone (even you, silent listener) could think of > at least one part he would like documented and respond here. An earlier production on the NitroProject.org wiki held promise, then the wiki links were all messed up -- and I am no longer sure (a) what is still linked, and exists (b) what is incorrect or out-of-date and needs fixing (c) what is new and thus missing (d) what is 'lost' and (or) disconnected from the supporting matter .... Hmmm -- Lest this mail sound like a critique, I shall stop. What I really want to say is that fluid classes, etc can only be maintain documentation on-the-fly by the author. Big picture stuff probably needs to lag one 'release' behind the leading edge of agile development. It is a well known fact that Smalltalk, c and ruby were designed for terseness (where as English and most meat-languages) are for intra-personal communication (rather than 'science' or 'engineering'). A big thing that can be fixed is to NOT build the NitroProject.org web site on the work-in-progress release (except for bug fixes). My hand is on my heart. At one time I worked in a environment were we supported over 6,000 users on a product that is very similar in ethos to Nitro. You can't build the meta-documentation on an "in-progress instance" of the product. Please relax. All I'm saying is that before the documentation challenge can be satisfied, we need a stable documentation project/platform (structure) as precursor. To make that happen all we need is some discipline around "release management" and "migration" strategy. If I may continue, part of the solution is to have proposals written in NitroProject.org along side the 'current' documentation. That looks like a "design for ..." what's to come. With some write-up of what there now. Personally I am unsure if Nitro is yet stable enough to begin such a process. I'm not really a product information person, I just used to get hassled by them -- So my judgment could be flawed. My private utopia is a place where a Product Information person writes documentation from the Unit Test and Systems Test cases. BEFORE any one writes any code. (*ohmygawsh*) That would need to be CLEAR-ly delineated. (I think my ultimate notion here, could turn into a whole new "wiki" feature). In the short-term, that requirement can be satisfied by a "wiki versioning" system that permits "labels" or "release tags" --Such that I might compare "now" with "version -1" (etc.) I didn't mean to launch into something weird ... I think there are some useful points above -- And I think it is a group consensus that needs to develop around HOW we document things ;-) Aloha, Will. -----Original Message----- From: nitro-general-bounces at rubyforge.org [mailto:nitro-general-bounces at rubyforge.org] On Behalf Of nitrojesus.5.pistos at geoshell.com Sent: Friday, 2 February 2007 04:34 To: nitro-general at rubyforge.org Subject: Re: [Nitro] Nitroproject.org Importance: Low On 01/02/07, Jonathan Buch - john at oxyliquit.de wrote: > http://24.21.123.8:9000/ > I would love, when everyone (even you, silent listener) could think of > at least one part he would like documented and respond here. More [short] screencasts, and beginner/intro level tutorials. People need to be able to dive in easily, so that they can get hooked on how great Nitro and Og are. :) Things that I think tend to be good sales tools: - Why Nitro? (and not something else) - Why Og? (and not something else) Perhaps add: - Differences between Og and AR - Differences between Nitro and ___ There should probably also be a cookbookish section for lookup of snippets that answer "How do I ?" For more advanced developers, maybe a graphical overview of the pipeline of processing, from browser making HTTP request, to the innards of Nitro, all the way back to the browser. This would include what classes are involved, etc. Pistos _______________________________________________ Nitro-general mailing list Nitro-general at rubyforge.org http://rubyforge.org/mailman/listinfo/nitro-general -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 28-Jan-2007 13:12 From james.britt at gmail.com Sat Feb 3 12:35:37 2007 From: james.britt at gmail.com (James Britt) Date: Sat, 03 Feb 2007 10:35:37 -0700 Subject: [Nitro] Consistency In-Reply-To: References: Message-ID: <45C4C7E9.4000509@gmail.com> Jonathan Buch wrote: > Hi, > >> - use everywhere alias instead of alias_method >> - use the name uri instead of url >> - use facets/more,facets/core instead of facet >> >> If anyone has any objection please let me know. > > no objection today. :P except that url is a little more common > than uri perhaps... > > http://www.google.com/trends?q=url,+uri&date=all&geo=all&ctab=1&sa=N > > uri is (as I remember from some class) also stuff like the ISBN, > for web stuff plain URL might be better in the Nitro case... > So how about the other way round, all uri > url? Is Nitro limited to Web stuff? Could I not have URIs with my own protocol (e.g., jgb://some-stuff ) and teach Nitro to Do The Right Thing when it sees it? I think I tend to think of Web apps (or apps in general) as "fetch this resource, do something with it, and pass it on." Often it involves http:// , but not always. -- James Britt "Trying to port the desktop metaphor to the Web is like working on how to fuel your car with hay because that is what horses eat." - Dare Obasanjo From transfire at gmail.com Sat Feb 3 15:13:30 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 03 Feb 2007 20:13:30 -0000 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: Message-ID: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> On Jan 25, 5:01 am, "George Moschovitis" wrote: > Dear devs, > > I am thinking about replacing the current configuration/settings > system used in Nitro and Og with a much simpler implementation > based on global variables. Let me demonstrate with an example: > > instead of > > class Server > setting :root_dir, :default => 'public', :doc => 'The default dir' > end > > dir = Server.root_dir > > use the following: > > $server_root_dir = 'public' # The default dir > > dir = $server_root_dir > > The main drawback of the current version is that you have to > define the classes to be configured before executing any configuration > code and/or require the glue/configuration.rb file. This prohibits > the reusability and flexibility of the configuration files. Moreover, > as the configuration system uses annotations there is a slight performance > penalty that may be serious if a configuration variable is used > in a tight loop. > > I understand that global variables are considered evil, but I think > they are very suitable for configuration. I especially like the > fact that global variables default to nil (==false) if they are not > previously defined. > > I would like to hear some opinions on this. > > thanks in advance, George, Did you decide on this? Dod you do any work on this? Did you try making it an instatiable class? T. From vikingtux at gmail.com Sat Feb 3 15:27:59 2007 From: vikingtux at gmail.com (Alexandre Gravem) Date: Sat, 3 Feb 2007 18:27:59 -0200 Subject: [Nitro] Emmiter In-Reply-To: References: Message-ID: <40b05ebe0702031227q5d0230aeka8046b0941a19bf8@mail.gmail.com> I didn't even know it exists :) On 2/3/07, Jonathan Buch wrote: > > Hi, > > > I am reviewing the source code, trying to clean it up a bit. Is anyone > using > > the Emmiter code in lib/nitro/render.rb? I would like to remove this if > > no-one is using it. > > not using it, ok for me. > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070203/2dcccedf/attachment-0001.html From john at oxyliquit.de Sat Feb 3 16:11:15 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 03 Feb 2007 22:11:15 +0100 Subject: [Nitro] Simpler configuration method? In-Reply-To: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> References: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> Message-ID: Hi, > Did you decide on this? Dod you do any work on this? Did you try > making it an instatiable class? George and I (and some others) discussed on that in #nitro for a while. I managed to bring George away from the $global idea, his current take on it is (I hope I get that right): class Nitro::Conf < Hash end class Nitro::Compiler Conf[:Compiler_mixin_get_parameters] = true end Which I found at least better than using 400 $globals just for the Nitro internal configuration... But, the namespace issue still stays. It's possible (since this is a single hash) to override stuff accidentally. It also looks uglier than: class Nitro::Compiler setting :mixin_get_parameters, :default => true, :doc => "/meth?a=foo like /meth/foo" end Where each Klass gets its own namespace for settings. Implementation is slightly more complicated of course, also there are some issues with 'configuring not yet defined classes' (which is possible though, just not as visually pleasing). The current system also has the advantage of being able to view settings nicely 'threaded' at run-time, even with documentation. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Feb 3 16:23:14 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 03 Feb 2007 22:23:14 +0100 Subject: [Nitro] Consistency In-Reply-To: <45C4C7E9.4000509@gmail.com> References: <45C4C7E9.4000509@gmail.com> Message-ID: Hi, > Is Nitro limited to Web stuff? Could I not have URIs with my own > protocol (e.g., jgb://some-stuff ) and teach Nitro to Do The Right > Thing when it sees it? > > I think I tend to think of Web apps (or apps in general) as "fetch this > resource, do something with it, and pass it on." Often it involves > http:// , but not always. yes, I do think that Nitro is limited to Web stuff. At least at the moment. I'm not sure how hard it would be to write a 'adapter' like the CGI one, just for another type of 'getting called'. I don't think it would be particularily hard, but all the "mechanisms" within Nitro are of course quite 'web centered'. Somebody might prove me horribly wrong when I say this. :) Anyone have an idea of a protocol which would fit into the Nitro 'range' of working with things? I'd really be interested to hear one. :D (Nitro, going general purpose!) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From vikingtux at gmail.com Sun Feb 4 00:21:37 2007 From: vikingtux at gmail.com (Alexandre Gravem) Date: Sun, 4 Feb 2007 03:21:37 -0200 Subject: [Nitro] Consistency In-Reply-To: References: <45C4C7E9.4000509@gmail.com> Message-ID: <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> I think Nitro should stay limited to Web stuff ... maybe it could be extended to some ponctual non-web job but it is essentially a web framework. On 2/3/07, Jonathan Buch wrote: > > Hi, > > > Is Nitro limited to Web stuff? Could I not have URIs with my own > > protocol (e.g., jgb://some-stuff ) and teach Nitro to Do The Right > > Thing when it sees it? > > > > I think I tend to think of Web apps (or apps in general) as "fetch this > > resource, do something with it, and pass it on." Often it involves > > http:// , but not always. > > yes, I do think that Nitro is limited to Web stuff. At least at the > moment. I'm not sure how hard it would be to write a 'adapter' like the > CGI one, just for another type of 'getting called'. I don't think > it would be particularily hard, but all the "mechanisms" within Nitro > are of course quite 'web centered'. > > Somebody might prove me horribly wrong when I say this. :) > > Anyone have an idea of a protocol which would fit into the Nitro 'range' > of working with things? I'd really be interested to hear one. :D > (Nitro, going general purpose!) > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/ee74b3b3/attachment.html From george.moschovitis at gmail.com Sun Feb 4 05:22:07 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 12:22:07 +0200 Subject: [Nitro] Consistency In-Reply-To: <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> References: <45C4C7E9.4000509@gmail.com> <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> Message-ID: Nitro is about Web stuff. However I still think that uri is the correct term (in fact url is deprectated) -g. On 2/4/07, Alexandre Gravem wrote: > > I think Nitro should stay limited to Web stuff ... maybe it could be > extended to some ponctual non-web job but it is essentially a web framework. > > On 2/3/07, Jonathan Buch wrote: > > > > Hi, > > > > > Is Nitro limited to Web stuff? Could I not have URIs with my own > > > protocol (e.g., jgb://some-stuff ) and teach Nitro to Do The Right > > > Thing when it sees it? > > > > > > I think I tend to think of Web apps (or apps in general) as "fetch > > this > > > resource, do something with it, and pass it on." Often it involves > > > http:// , but not always. > > > > yes, I do think that Nitro is limited to Web stuff. At least at the > > moment. I'm not sure how hard it would be to write a 'adapter' like the > > > > CGI one, just for another type of 'getting called'. I don't think > > it would be particularily hard, but all the "mechanisms" within Nitro > > are of course quite 'web centered'. > > > > Somebody might prove me horribly wrong when I say this. :) > > > > Anyone have an idea of a protocol which would fit into the Nitro 'range' > > of working with things? I'd really be interested to hear one. :D > > (Nitro, going general purpose!) > > > > Jo > > > > -- > > Feel the love > > http://pinkjuice.com/pics/ruby.png > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/dd3bd85d/attachment.html From george.moschovitis at gmail.com Sun Feb 4 05:30:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 12:30:37 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170292113.043801.83870@k78g2000cwa.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> Message-ID: Hello, the attached patch does not apply :( darcs apply rw_attr.patch seems to enter an infinite loop... Perhaps I have many not committed changes... I just pushed my latest changes (please note that it contains the initial, raw version of a new RESTful dispatcher) so please try to send me your patch against the latest repo and I will try to apply it again. sorry for the inconvenience and thanks for your time. regards, George. On 2/2/07, Judson Lester wrote: > > Okay, I've reworked read_attr and write_attr, which meant adapting the > change out to MySqlAdapter as well. I suspect the same will be true > for the other Adaptors, in which case, I'm temped to make further > changes to read_attr and write_attr to mimize those changes in the > Adaptors. > > Patch attached. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/98762523/attachment.html From john at oxyliquit.de Sun Feb 4 05:38:02 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 04 Feb 2007 11:38:02 +0100 Subject: [Nitro] Consistency In-Reply-To: References: <45C4C7E9.4000509@gmail.com> <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> Message-ID: Hi, > Nitro is about Web stuff. However I still think that uri is the correct term (in fact url is deprectated) my argument wasn't that URL is more 'correct' than URI, it was that URL a) is more common, also with people who can distinguish it from URI and b) that URL is the subset of URI which Nitro actually uses. But that isn't entirely the point, like I said in my original post, 'no objections today', which meant that I'm fine with whatever does happen about uri/urls. :) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sun Feb 4 06:58:50 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 13:58:50 +0200 Subject: [Nitro] Simpler configuration method? In-Reply-To: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> References: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> Message-ID: > > George, > > Did you decide on this? Dod you do any work on this? Did you try > making it an instatiable class? > Nope, I haven't decided on this. I still believe that using globals is valid for this case, but I am sure that a lot of people will go mad if they see the $ symbol. It is amusing that people consider this unacceptable: $conf_template_root_dir = '...' but this acceptable: Conf["Template.root_dir"] = '...' or Conf[:Template][:root_dir] = '...' <--- this is curently used, Template.root_dir is syntax sugar for Conf[:Template][:root_dir] atm. as they are exactly the same thing... I think that global variables are the natural choice for *global* settings, but since everyone else disagrees I am probably wrong so I will leave the configuration system as it is for the moment. I will just try to add some kind of syntactic sugar for Conf[:Template][:root_dir] initialization. I am thinking something along the lines: Configuration.setup do Template.root_dir = ... Og.create_tables = ... end instead of Configuration.Template.root_dir = ... Configuration.Og.create_tables = ... Perhaps you can suggest something better? In any case I need to move the final solution to facets. (still trying to get rid of the glue gem). As you are the Ruby guru here perhaps you could come up with a better solution. regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/0a5b054d/attachment-0001.html From george.moschovitis at gmail.com Sun Feb 4 07:13:04 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 14:13:04 +0200 Subject: [Nitro] Consistency In-Reply-To: References: <45C4C7E9.4000509@gmail.com> <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> Message-ID: speaking about consistency, i am considering changing all '...' strings to "..." strings. Any objection? -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/2d68c5df/attachment.html From george.moschovitis at gmail.com Sun Feb 4 07:17:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 14:17:01 +0200 Subject: [Nitro] Singletons Message-ID: Dear devs, I am considering making some Nitro::Server and Nitro::Dispatcher singletons. Plus try to remove extraneous refs to these classes from all over the place (I will probably only keep the refs from Context). For example I will remove Dispatcher#server. This will simplify the code plus give you easy access to the Dispatcher and Server from everywhere. (kind of like Context.current etc is very helpful to access the context from your methods). any comments? George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/73445002/attachment.html From john at oxyliquit.de Sun Feb 4 08:02:51 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 04 Feb 2007 14:02:51 +0100 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170533610.880839.293990@a75g2000cwd.googlegroups.com> Message-ID: Hi, > It is amusing that people consider this unacceptable: > > $conf_template_root_dir = '...' > > but this acceptable: > > Conf["Template.root_dir"] = '...' > or > Conf[:Template][:root_dir] = '...' <--- this is curently used, > Template.root_dir is syntax sugar for Conf[:Template][:root_dir] atm. > > as they are exactly the same thing... [snipped rest] Those three things are different, in the sense where they are in memory and how they are accessed. The $global namespace is used by everything which is _really_ global, many people can create globals, name clashes may be possible. The first two are similar in the sense, that there is only a single namespace, the third make one namespace for one 'configuration area' and so one doesn't have to take care of that. dead simple grep, counting current settings (might be off a few): $ grep -R 'setting :' . | wc -l 256 irb(main):042:0> global_variables.size => 60 Would someone like to put our ~250 current settings into the global namespace? I just feel that it 'doesn't belong to us'. When we want to retain the ability to specify the default inside a class: class Template Conf[name][:root_dir] ||= '/' end Something like that has to be used, and we will still loose the ability to specify documentation stuff which can be used by a admin interface... However, I'd be ok with that one, but: class Template Conf["#{name}_root_dir"] ||= '/' end This one would be what George would agree on I guess, I just feel that it's not as nice, and it still has the problem that it is in a single namespace. http://pastie.caboo.se/37807 George and me discussing over this on IRC, there were a few good points made on either side there. (I hope it's ok posting this, George?) So, if we're gonna touch the Configuration at all, I vote for the 2 level namespace and Nitro::Conf (not ::Conf). This doesn't have much overhead (Conf having [] overridden, for creating them dynamically and returning a new Hash). It isn't as visually pleasing as the current .setting style, but ah well. My take on this, and I'll not back away, as the $global approach just 'feels' wrong to me. Comparison: # current: ## create: class Template setting :root_dir, :default => '' end ## access: * Template.root_dir * Configuration[:Template][:root_dir] * class Template def a self.class.root_dir end end # 1 level ## create: class Template Conf["#{self.name}_root_dir"] ||= '' end ## access: * Conf['Template_root_dir'] * class Template def a Conf["#{self.name}_root_dir"] end end # 2 level ## create: class Template Conf[self.name][:root_dir] ||= '' end ## access: * Conf[:Template][:root_dir] * class Template def a Conf[self.name][:root_dir] end end Did I miss something? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sun Feb 4 08:06:46 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 04 Feb 2007 14:06:46 +0100 Subject: [Nitro] Consistency In-Reply-To: References: <45C4C7E9.4000509@gmail.com> <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> Message-ID: Hi. > speaking about consistency, i am considering changing all '...' strings to > "..." strings. Any objection? I would rather suggest changing all strings which are not messed with ( " asdf #{foo} \n asdf" like that) to '..'. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Sun Feb 4 08:37:54 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 13:37:54 -0000 Subject: [Nitro] Singletons In-Reply-To: References: Message-ID: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> On Feb 4, 7:17 am, "George Moschovitis" wrote: > Dear devs, > > I am considering making some Nitro::Server and Nitro::Dispatcher singletons. > Plus try to remove extraneous refs to these classes from all over the place > (I will probably only keep the refs from Context). For example I will remove > Dispatcher#server. This will simplify the code plus give you easy access to > the Dispatcher and Server from everywhere. (kind of like Context.current etc > is very helpful to access the context from your methods). > > any comments? Please read: http://onestepback.org/index.cgi/Tech/Ruby/ DependencyInjectionInRuby.rdoc T. From malte at gmx-topmail.de Sun Feb 4 10:04:47 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Sun, 04 Feb 2007 16:04:47 +0100 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: Message-ID: <1170601487.5586.25.camel@aligatoro.ret> I'm looking at the first message of this thread, trying to understand what is being discussed. Please don't take this as a rant, I'm really trying to understand your views, by asking questions: George Moschovitis: > The main drawback of the current version is that you have to > define the classes to be configured before executing any configuration > code and/or require the glue/configuration.rb file. This prohibits > the reusability and flexibility of the configuration files. I don't really get the point you're making here. What reusability? If I set some attribute, I always know what attribute I'm going to set on what object. Why would I want to use a library without loading the library? Why would I want to configure something I do not use? > Moreover, as the configuration system uses annotations there is a > slight performance penalty that may be serious if a configuration > variable is used in a tight loop. Actually, this Annotation thing strikes me as a programmer as a little odd. A server's root directory is an attribute of this server, thus it is natural to do something like server = Framework::Server.new server.root_dir = my_dir Opposed to that, it is not the job of a class (here: Server) to care about the root directory of my specific server. If I do not instantiate the server myself, i.e., the framework has done this for me, then the lines above would read something like server = application.server server.root_dir = my_dir or application.server.root_dir = my_dir but never Framework::Server.root_dir = my_dir At least that's my understanding of OOP design. Now, who is going to enlighten me? :-) Malte From transfire at gmail.com Sun Feb 4 10:43:51 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 15:43:51 -0000 Subject: [Nitro] Simpler configuration method? In-Reply-To: <1170601487.5586.25.camel@aligatoro.ret> References: <1170601487.5586.25.camel@aligatoro.ret> Message-ID: <1170603831.363774.8120@j27g2000cwj.googlegroups.com> On Feb 4, 10:04 am, Malte Milatz wrote: > I'm looking at the first message of this thread, trying to understand > what is being discussed. Please don't take this as a rant, I'm really > trying to understand your views, by asking questions: > > George Moschovitis: > > > The main drawback of the current version is that you have to > > define the classes to be configured before executing any configuration > > code and/or require the glue/configuration.rb file. This prohibits > > the reusability and flexibility of the configuration files. > > I don't really get the point you're making here. What reusability? If I > set some attribute, I always know what attribute I'm going to set on > what object. Why would I want to use a library without loading the > library? Why would I want to configure something I do not use? > > > Moreover, as the configuration system uses annotations there is a > > slight performance penalty that may be serious if a configuration > > variable is used in a tight loop. > > Actually, this Annotation thing strikes me as a programmer as a little > odd. A server's root directory is an attribute of this server, thus it > is natural to do something like > > server = Framework::Server.new > server.root_dir = my_dir > > Opposed to that, it is not the job of a class (here: Server) to care > about the root directory of my specific server. If I do not instantiate > the server myself, i.e., the framework has done this for me, then the > lines above would read something like > > server = application.server > server.root_dir = my_dir > > or > > application.server.root_dir = my_dir > > but never > > Framework::Server.root_dir = my_dir > > At least that's my understanding of OOP design. > > Now, who is going to enlighten me? :-) I agree! What's being done presently is using a class/module as a global variable store. This is good case of how Ruby can somtimes be too flexible for it's own good. If you want globals then use a global var. eg. $nitro.server.root_dir = my_dir But I still think this probaly could be done better (albiet with a little more work) w/o globals via IOC. T. From george.moschovitis at gmail.com Sun Feb 4 12:21:12 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 19:21:12 +0200 Subject: [Nitro] Consistency In-Reply-To: References: <45C4C7E9.4000509@gmail.com> <40b05ebe0702032121y2f466abei8440093234bce8f6@mail.gmail.com> Message-ID: > > I would rather suggest changing all strings which are not messed with > ( " asdf #{foo} \n asdf" like that) to '..'. > this is the current situation... But I am thinking, let's just use "" all the time... -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/bf17ac49/attachment.html From george.moschovitis at gmail.com Sun Feb 4 12:23:35 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 19:23:35 +0200 Subject: [Nitro] Singletons In-Reply-To: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> Message-ID: > > http://onestepback.org/index.cgi/Tech/Ruby/ > DependencyInjectionInRuby.rdoc > I don't really want to add DI, IOC etc to Nitro. I would like to simplify Nitro and make it more accessible not include the most advanced concepts... What do others think? -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/3d3fa108/attachment-0001.html From george.moschovitis at gmail.com Sun Feb 4 12:28:48 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 19:28:48 +0200 Subject: [Nitro] Simpler configuration method? In-Reply-To: <1170603831.363774.8120@j27g2000cwj.googlegroups.com> References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> Message-ID: > > I agree! What's being done presently is using a class/module as a > global variable store. This is good case of how Ruby can somtimes be > too flexible for it's own good. If you want globals then use a global > var. eg. > > $nitro.server.root_dir = my_dir this is *exactly* what I have said... But I still think this probaly could be done better (albiet with a > little more work) w/o globals via IOC. I think IOC will make things unnecessarily complicated... Anyway, I will not touch the current configuration system for the time being (until someone suggests a clearly better alternative). -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/c6cb8790/attachment.html From george.moschovitis at gmail.com Sun Feb 4 12:34:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 19:34:57 +0200 Subject: [Nitro] Simpler configuration method? In-Reply-To: <1170601487.5586.25.camel@aligatoro.ret> References: <1170601487.5586.25.camel@aligatoro.ret> Message-ID: > > I don't really get the point you're making here. What reusability? If I > set some attribute, I always know what attribute I'm going to set on > what object. Why would I want to use a library without loading the > library? Why would I want to configure something I do not use? > I have alredy explained this (maybe on IRC though). Let me give you an example. You setup all your settings in a single configuration file: conf.rb Og.create_table = ... Template.root = ... ... For this to work you need to make sure that Og and Template are already defined... Lets say you want to use only the Template setting from a script you want to write. You cannot reuse conf.rb (you will get errors along the line that Og is not defined) An alternative (that is supported in the current implementation) would be to define your settings like this: Configuration.Og.create_table = ... Configuration.Template.root = ... The problems: 1. too long 2. Does not work nice with namespaces (ie Configuration.My::Name::Space.setting = ...) 3. values are accessed like this: Configuration.Og.create_table.value(notice the exta .value) Thats why we need a better configuration system. Using global variables would fix all the problems but we get objections ;-) So until someone proposes something better (well ok, IOC may be better, but I think it will make the code too complex...) we will postpone the decision for the future. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/2ce661b1/attachment.html From transfire at gmail.com Sun Feb 4 13:20:30 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 18:20:30 -0000 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> Message-ID: <1170613230.017379.220000@a75g2000cwd.googlegroups.com> On Feb 4, 12:28 pm, "George Moschovitis" wrote: > > I agree! What's being done presently is using a class/module as a > > global variable store. This is good case of how Ruby can somtimes be > > too flexible for it's own good. If you want globals then use a global > > var. eg. > > > $nitro.server.root_dir = my_dir > > this is *exactly* what I have said... > > But I still think this probaly could be done better (albiet with a > > > little more work) w/o globals via IOC. > > I think IOC will make things unnecessarily complicated... > > Anyway, I will not touch the current configuration system for the time > being (until someone suggests a clearly better alternative). Then you have my +1 vote for using a global, but just make it a single global (or at least very few globals) that everything gets tied too, eg. $nitro.server or $nitro_server. The alternative is of course a constant NiTro::Server, but while unlikely w/ contants there can be name ambiguity: module Nitro Server = NitroServer.new end module MyModule module Nitro ... Nitro::Server.settings # oops wrong Nitro T. From transfire at gmail.com Sun Feb 4 13:33:46 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 18:33:46 -0000 Subject: [Nitro] Singletons In-Reply-To: References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> Message-ID: <1170614026.240426.136820@h3g2000cwc.googlegroups.com> On Feb 4, 12:23 pm, "George Moschovitis" wrote: > > http://onestepback.org/index.cgi/Tech/Ruby/ > > DependencyInjectionInRuby.rdoc > > I don't really want to add DI, IOC etc to Nitro. I would like to simplify > Nitro and make it more accessible not include the most advanced concepts... > What do others think? Simple is good. I wouldn't want it if it's not so. Here's just a rough concept, maybe this can give you more of a concrete idea of how it could work and not be complex: class Class def needs *a (@needs ||= []).concat(a.flatten.collect{|e|e.to_sym}) end def need?(name) @needs.include?(name.to_sym) end end def Nitro.inject( services ) ObjectSpace.each_object(Class) do |k| if k.needs?(:server) k.class_eval do define_method{:server){ services[:server] } end end end end my_server = Nitro::Server.new Nitro.inject( :server => my_server ) class Nitro::Element needs :server end T. From transfire at gmail.com Sun Feb 4 13:41:51 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 18:41:51 -0000 Subject: [Nitro] reap name 4 rake project In-Reply-To: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> Message-ID: <1170614511.861640.215020@v45g2000cwv.googlegroups.com> On Feb 1, 6:01 pm, transf... at gmail.com wrote: > One of my infamous "please help me name this damn thing" posts.... > > Alright, after lot of wrestling I've finally come to a conclusion and > converted all my build tools to bonofide Rake tasks, along with an > automator the sets these tasks up automatically based on one's > ProjectInfo file (talk about coming full circle!) . I'm going to > release the ProjectInfo class as a separate project (maybe others can > build tools that key off of it too) and it will be a subrpoject of a > larger project called Ratchets. Though I'm not sure if it will be > "projectinfo.gem" or just "pinfo.gem" (opinions?) Anyway, I'm > wondering what to call the project with these tasks? (Which will also > be a subproject of Ratchets, btw) Should I stick with 'reap' even > though the tasks are now for rake? Or should I use the new code name > I've been developing them under, '4rake'. Or is there some other name > that would be better? I like 'reap' b/c it's what I had been using -- > those already aware of it will recognize it. But I also like '4rake' b/ > c... well, b/c it's pretty dang obvious what it is for ;-) > > Suggestions? Nobody? :-( I'm down to the last and must decide, shall I release it as Reap v10, or make a new project 4Rake v1.0, or some other name? (Hmm... this uses rake so there would be no reap command any longer, but it occured to me that I could wrap the rake command to make a reap command). T. From george.moschovitis at gmail.com Sun Feb 4 14:30:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 21:30:37 +0200 Subject: [Nitro] reap name 4 rake project In-Reply-To: <1170614511.861640.215020@v45g2000cwv.googlegroups.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> Message-ID: I would say keep reap.... but 4rake is ok too, choose what you want! -g. On 2/4/07, transfire at gmail.com wrote: > > > > On Feb 1, 6:01 pm, transf... at gmail.com wrote: > > One of my infamous "please help me name this damn thing" posts.... > > > > Alright, after lot of wrestling I've finally come to a conclusion and > > converted all my build tools to bonofide Rake tasks, along with an > > automator the sets these tasks up automatically based on one's > > ProjectInfo file (talk about coming full circle!) . I'm going to > > release the ProjectInfo class as a separate project (maybe others can > > build tools that key off of it too) and it will be a subrpoject of a > > larger project called Ratchets. Though I'm not sure if it will be > > "projectinfo.gem" or just "pinfo.gem" (opinions?) Anyway, I'm > > wondering what to call the project with these tasks? (Which will also > > be a subproject of Ratchets, btw) Should I stick with 'reap' even > > though the tasks are now for rake? Or should I use the new code name > > I've been developing them under, '4rake'. Or is there some other name > > that would be better? I like 'reap' b/c it's what I had been using -- > > those already aware of it will recognize it. But I also like '4rake' b/ > > c... well, b/c it's pretty dang obvious what it is for ;-) > > > > Suggestions? > > > Nobody? :-( > > I'm down to the last and must decide, shall I release it as Reap v10, > or make a new project 4Rake v1.0, or some other name? > > (Hmm... this uses rake so there would be no reap command any longer, > but it occured to me that I could wrap the rake command to make a reap > command). > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/e3379a77/attachment.html From transfire at gmail.com Sun Feb 4 15:05:49 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 20:05:49 -0000 Subject: [Nitro] Singletons In-Reply-To: <1170614026.240426.136820@h3g2000cwc.googlegroups.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> Message-ID: <1170619549.421526.282110@l53g2000cwa.googlegroups.com> On Feb 4, 1:33 pm, transf... at gmail.com wrote: > On Feb 4, 12:23 pm, "George Moschovitis" > > wrote: > > > http://onestepback.org/index.cgi/Tech/Ruby/ > > > DependencyInjectionInRuby.rdoc > > > I don't really want to add DI, IOC etc to Nitro. I would like to simplify > > Nitro and make it more accessible not include the most advanced concepts... > > What do others think? > > Simple is good. I wouldn't want it if it's not so. Here's just a rough > concept, maybe this can give you more of a concrete idea of how it > could work and not be complex: > > class Class > def needs *a > (@needs ||= []).concat(a.flatten.collect{|e|e.to_sym}) > end > def need?(name) > @needs.include?(name.to_sym) > end > end > > def Nitro.inject( services ) > ObjectSpace.each_object(Class) do |k| > if k.needs?(:server) > k.class_eval do > define_method{:server){ services[:server] } > end > end > end > end > > my_server = Nitro::Server.new > > Nitro.inject( :server => my_server ) > > class Nitro::Element > needs :server > end Hmm... I guess that is too complex. b/c why not just: $services = {} class Class def needs(name) define_method(name){ $services[name] } end end class Nitro::Element needs :server end my_server = Nitro::Server.new $services[:server] = my_server Okay, i'll shut up now... ;-) T. From nyarly at gmail.com Sun Feb 4 15:10:59 2007 From: nyarly at gmail.com (Judson Lester) Date: Sun, 4 Feb 2007 12:10:59 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <1170295160.404675.182690@p10g2000cwp.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> Message-ID: <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> Okay, did the darcs send again. Only included the patch that makes the changes to read_attr and write_attr. Jonathon, I'm working on a refactoring of read_attr and write_attr that would make writing adaptors simpler. Should be done in a day or two. On 2/4/07, George Moschovitis wrote: > Hello, > > the attached patch does not apply :( > > darcs apply rw_attr.patch seems to enter an infinite loop... > > Perhaps I have many not committed changes... I just pushed my latest changes > (please note that it contains the initial, raw version of a new RESTful > dispatcher) so please try to send me your patch against the latest repo and > I will try to apply it again. > > sorry for the inconvenience and thanks for your time. > > regards, > George. > > > On 2/2/07, Judson Lester < nyarly at gmail.com> wrote: > > > > Okay, I've reworked read_attr and write_attr, which meant adapting the > > change out to MySqlAdapter as well. I suspect the same will be true > > for the other Adaptors, in which case, I'm temped to make further > > changes to read_attr and write_attr to mimize those changes in the > > Adaptors. > > > > Patch attached. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- A non-text attachment was scrubbed... Name: rw_attr.patch Type: text/x-patch Size: 79367 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070204/3edfd42a/attachment-0001.bin From transfire at gmail.com Sun Feb 4 15:23:48 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 04 Feb 2007 20:23:48 -0000 Subject: [Nitro] reap name 4 rake project In-Reply-To: References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> Message-ID: <1170620628.734190.9470@j27g2000cwj.googlegroups.com> On Feb 4, 2:30 pm, "George Moschovitis" wrote: > I would say keep reap.... but 4rake is ok too, choose what you want! I don't want, so I can't choose. Clearly this is the lie of the Vulcan. For a completely logical life would be so fraut with uncertaintly that nothting whatsoever could be done. Sigh. Is that the problem, am I a Vulcan? T. From george.moschovitis at gmail.com Sun Feb 4 15:33:51 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 4 Feb 2007 22:33:51 +0200 Subject: [Nitro] Singletons In-Reply-To: <1170619549.421526.282110@l53g2000cwa.googlegroups.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> Message-ID: Ok this is nice. But really, a Nitro application needs *one* Server and *one* Dispatcher. -g. On 2/4/07, transfire at gmail.com wrote: > > > > On Feb 4, 1:33 pm, transf... at gmail.com wrote: > > On Feb 4, 12:23 pm, "George Moschovitis" > > > > wrote: > > > > http://onestepback.org/index.cgi/Tech/Ruby/ > > > > DependencyInjectionInRuby.rdoc > > > > > I don't really want to add DI, IOC etc to Nitro. I would like to > simplify > > > Nitro and make it more accessible not include the most advanced > concepts... > > > What do others think? > > > > Simple is good. I wouldn't want it if it's not so. Here's just a rough > > concept, maybe this can give you more of a concrete idea of how it > > could work and not be complex: > > > > class Class > > def needs *a > > (@needs ||= []).concat(a.flatten.collect{|e|e.to_sym}) > > end > > def need?(name) > > @needs.include?(name.to_sym) > > end > > end > > > > def Nitro.inject( services ) > > ObjectSpace.each_object(Class) do |k| > > if k.needs?(:server) > > k.class_eval do > > define_method{:server){ services[:server] } > > end > > end > > end > > end > > > > my_server = Nitro::Server.new > > > > Nitro.inject( :server => my_server ) > > > > class Nitro::Element > > needs :server > > end > > Hmm... I guess that is too complex. b/c why not just: > > $services = {} > > class Class > def needs(name) > define_method(name){ $services[name] } > end > end > > class Nitro::Element > needs :server > end > > my_server = Nitro::Server.new > > $services[:server] = my_server > > Okay, i'll shut up now... ;-) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070204/ffd7be92/attachment.html From zedshaw at zedshaw.com Sun Feb 4 18:41:48 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Sun, 4 Feb 2007 15:41:48 -0800 Subject: [Nitro] Singletons In-Reply-To: References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> Message-ID: <20070204154148.fd00ee17.zedshaw@zedshaw.com> On Sun, 4 Feb 2007 22:33:51 +0200 "George Moschovitis" wrote: > Ok this is nice. But really, a Nitro application needs *one* Server and > *one* Dispatcher. Not if I implement my master plan to allow multiple Ruby applications to live in one Mongrel. :-) -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From george.moschovitis at gmail.com Sun Feb 4 17:24:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 00:24:56 +0200 Subject: [Nitro] Singletons In-Reply-To: <20070204154148.fd00ee17.zedshaw@zedshaw.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> Message-ID: > > > Ok this is nice. But really, a Nitro application needs *one* Server and > > *one* Dispatcher. > > Not if I implement my master plan to allow multiple Ruby applications to > live in one Mongrel. :-) > oh, really? ;-) In any case I will get rid of cross references. I will leave only references from Context to Server and Dispatcher. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/fa406330/attachment.html From george.moschovitis at gmail.com Sun Feb 4 17:31:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 00:31:38 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> Message-ID: Dunno, why this patch does not apply (darcs does not respond...) are you sure you pulled the latest repo? Try: cd /your/repo darcs pull darcs send -o bundle and send the file 'bundle' to the list. -g. On 2/4/07, Judson Lester wrote: > > Okay, did the darcs send again. Only included the patch that makes > the changes to read_attr and write_attr. > > Jonathon, I'm working on a refactoring of read_attr and write_attr > that would make writing adaptors simpler. Should be done in a day or > two. > > > > On 2/4/07, George Moschovitis wrote: > > Hello, > > > > the attached patch does not apply :( > > > > darcs apply rw_attr.patch seems to enter an infinite loop... > > > > Perhaps I have many not committed changes... I just pushed my latest > changes > > (please note that it contains the initial, raw version of a new RESTful > > dispatcher) so please try to send me your patch against the latest repo > and > > I will try to apply it again. > > > > sorry for the inconvenience and thanks for your time. > > > > regards, > > George. > > > > > > On 2/2/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > > Okay, I've reworked read_attr and write_attr, which meant adapting the > > > change out to MySqlAdapter as well. I suspect the same will be true > > > for the other Adaptors, in which case, I'm temped to make further > > > changes to read_attr and write_attr to mimize those changes in the > > > Adaptors. > > > > > > Patch attached. > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/8de5f012/attachment.html From manveru at weez-int.com Sun Feb 4 20:24:09 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Mon, 05 Feb 2007 10:24:09 +0900 Subject: [Nitro] reap name 4 rake project In-Reply-To: <1170620628.734190.9470@j27g2000cwj.googlegroups.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> Message-ID: On Mon, 05 Feb 2007 05:23:48 +0900, wrote: > > > On Feb 4, 2:30 pm, "George Moschovitis" > wrote: >> I would say keep reap.... but 4rake is ok too, choose what you want! > > I don't want, so I can't choose. I'm for reap The obvioius benefit, it's shorter ;) Also, not sure how hoe solves it, they use the rake-command... and i really don't like that solution. 4rake doesn't tell me much, i know it's something for rake, but no idea what... reap is more like "let's reap some benefits/results/boon" :) ok, names are always very opinionated, a negative point for reap is the bad searchability, though 'reap ruby' should come up with decent results it will take longer to climb the top-10... so, let's ask ruby: %w[reap 4rake][rand(2)] # "4rake" wonderful :) > > Clearly this is the lie of the Vulcan. For a completely logical life > would be so fraut with uncertaintly that nothting whatsoever could be > done. Sigh. Is that the problem, am I a Vulcan? Half vulcan, half human, like tuvok :) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nyarly at gmail.com Sun Feb 4 23:32:32 2007 From: nyarly at gmail.com (Judson Lester) Date: Sun, 4 Feb 2007 20:32:32 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702011559k23b13a9eja8204eb04988c814@mail.gmail.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> Message-ID: <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> Huh. I get the same result: I approve 11 patches to pull, and then it never returns. Tell you what: attached are the two files I've made changes to. I'm just going to trash my repo and start over, unless you have a better idea. (they're og/store/sql.rb and og/adaptor/mysql.rb) Judson -------------- next part -------------- A non-text attachment was scrubbed... Name: sql.rb Type: application/x-ruby Size: 29556 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070204/e0cddbc0/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mysql.rb Type: application/x-ruby Size: 5165 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070204/e0cddbc0/attachment-0003.bin From john at oxyliquit.de Mon Feb 5 02:33:24 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 05 Feb 2007 08:33:24 +0100 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> Message-ID: Hi, >> $nitro.server.root_dir = my_dir > > this is *exactly* what I have said... No, it is not, your take at it was: $Server_root_dir (or with alternative $nitro_ prefix). Using $nitro as a more complex object (OpenObject?) would enable the above to work (maybe $nitro.server[:root_dir]). I'd be ok with using a single $global configuration object I guess, but I still don't feel really convinced about that... > Anyway, I will not touch the current configuration system for the time > being (until someone suggests a clearly better alternative). Thank you :) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Feb 5 03:31:00 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 10:31:00 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> Message-ID: I was going to suggest the same to you ;-) I will add your files, thanks On 2/5/07, Judson Lester wrote: > > Huh. I get the same result: I approve 11 patches to pull, and then it > never returns. > > Tell you what: attached are the two files I've made changes to. I'm > just going to trash my repo and start over, unless you have a better > idea. > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > Judson > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/5ca364fc/attachment.html From george.moschovitis at gmail.com Mon Feb 5 03:31:54 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 10:31:54 +0200 Subject: [Nitro] reap name 4 rake project In-Reply-To: References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> Message-ID: > > so, let's ask ruby: > > %w[reap 4rake][rand(2)] > # "4rake" > > wonderful :) > hahah -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/ca7f869c/attachment.html From transfire at gmail.com Mon Feb 5 06:26:04 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Mon, 05 Feb 2007 11:26:04 -0000 Subject: [Nitro] reap name 4 rake project In-Reply-To: References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> Message-ID: <1170674764.234731.255110@v45g2000cwv.googlegroups.com> On Feb 4, 8:24 pm, "Michael Fellinger" wrote: > On Mon, 05 Feb 2007 05:23:48 +0900, wrote: > > > On Feb 4, 2:30 pm, "George Moschovitis" > > wrote: > >> I would say keep reap.... but 4rake is ok too, choose what you want! > > > I don't want, so I can't choose. > > I'm for reap > > The obvioius benefit, it's shorter ;) > Also, not sure how hoe solves it, they use the rake-command... and i > really don't like that solution. could you elaborate on that? i basically agree and spent a lot of time on it, but i sort of came to the conclusion that offering something that competes against rake is a loosing proposition since rake is widespread and distibuted wirh ruby. > 4rake doesn't tell me much, i know it's something for rake, but no idea > what... > reap is more like "let's reap some benefits/results/boon" :) > > ok, names are always very opinionated, a negative point for reap is the > bad searchability, though 'reap ruby' should come up with decent results > it will take longer to climb the top-10... > > so, let's ask ruby: > > %w[reap 4rake][rand(2)] > # "4rake" > > wonderful :) lol. the flipping coin technique has never works for me, though i always try it 3 or 4 times for good measure. ;-) T. From wyhaines at gmail.com Mon Feb 5 09:17:02 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 5 Feb 2007 07:17:02 -0700 Subject: [Nitro] Singletons In-Reply-To: <20070204154148.fd00ee17.zedshaw@zedshaw.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> Message-ID: On 2/4/07, Zed A. Shaw wrote: > Not if I implement my master plan to allow multiple Ruby applications to live in one Mongrel. :-) That doesn't seem to be a Mongrel level issue, though, is it? If that is allowed at the framework level, then one can already do that with Mongrel. Kirk From wyhaines at gmail.com Mon Feb 5 10:39:15 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 5 Feb 2007 08:39:15 -0700 Subject: [Nitro] Singletons In-Reply-To: References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> Message-ID: On 2/5/07, Kirk Haines wrote: > On 2/4/07, Zed A. Shaw wrote: > > > Not if I implement my master plan to allow multiple Ruby applications to live in one Mongrel. :-) > > That doesn't seem to be a Mongrel level issue, though, is it? Replying to myself. :) This is probably a better discussion for the Mongrel list, but I suppose if one did something like incorporate _why's sandboxing, one could run multiple discrete apps at the same time without the framework having to support this. Seems like that would work, too. What are you thinking? Kirk From zedshaw at zedshaw.com Mon Feb 5 13:58:05 2007 From: zedshaw at zedshaw.com (Zed A. Shaw) Date: Mon, 5 Feb 2007 10:58:05 -0800 Subject: [Nitro] Singletons In-Reply-To: References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> Message-ID: <20070205105805.42df692a.zedshaw@zedshaw.com> On Mon, 5 Feb 2007 08:39:15 -0700 "Kirk Haines" wrote: > On 2/5/07, Kirk Haines wrote: > > On 2/4/07, Zed A. Shaw wrote: > > > > > Not if I implement my master plan to allow multiple Ruby applications to live in one Mongrel. :-) > > > > That doesn't seem to be a Mongrel level issue, though, is it? > > Replying to myself. :) > > This is probably a better discussion for the Mongrel list, but I > suppose if one did something like incorporate _why's sandboxing, one > could run multiple discrete apps at the same time without the > framework having to support this. Seems like that would work, too. > What are you thinking? Yeah, I'll be bringing this and other stuff up on the Mongrel list, but my comment was more that framework developers tend to assume they are THE ONE TRUE FRAMEWORK and don't play well with others. It's be nice if they assumed otherwise and then it'd be easier for Mongrel to at least run multiple instances of the same framework but different apps in small installations. As for Sandbox, it'd be great but currently afaik it's horribly slow. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help. From wyhaines at gmail.com Mon Feb 5 11:18:07 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 5 Feb 2007 09:18:07 -0700 Subject: [Nitro] Singletons In-Reply-To: <20070205105805.42df692a.zedshaw@zedshaw.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> <20070205105805.42df692a.zedshaw@zedshaw.com> Message-ID: On 2/5/07, Zed A. Shaw wrote: > Yeah, I'll be bringing this and other stuff up on the Mongrel list, but my comment > was more that framework developers tend to assume they are THE ONE TRUE > FRAMEWORK and don't play well with others. It's be nice if they assumed > otherwise and then it'd be easier for Mongrel to at least run multiple instances of > the same framework but different apps in small installations. (*nod*) Some frameworks more than others. AFAIK, Nitro, at least prior to the dust settling on what they decide to do with config settings, generally keeps it's stuff in its own namespaces, with the exception that it uses Facets, and Facets and ActiveSupport generally stomp on and mess with eachother in incompatible ways, which presents difficulties getting Nitro and Rails to be good neighbors. IOWA tries very hard to keep everything in its own namespace, and is very close to having everything in place so that multiple applications can live together side by side, so I'm with you on this one! I think the benefits of a framework having some consideration for the potential of having neighbors inside the interpreter outweigh the cons (which, in my experience, are very minimal), and I wish more software, in general, was written with an eye towards being a good neighbor. I made some comments on the IRC channel about this config issue. I think it is in Nitro's best interest to stay away from a sea of things that look like $perl_variables for three reasons: 1) PR. Ruby people generally don't like the stuff that looks Perlish (though the people who come to Ruby from Perl don't tend to care much), so a lot of $variables_like_this is going to come off to many people as ugly and backwards, regardless of what the real merits might be. 2) Issues with owning the whole interpreter, which is what you are getting at here. It's easy to think that Nitro is going to be by itself in the interpreter, but there are potential benefits in having a Nitro app that can be a good neighbor with other frameworks. Filling the global variable space with config variables isn't neighborly. 3) It makes it all but impossible to migrate from that point to one where one could have more than one Nitro application living side by side, regardless of what the other architectural issues in that may be. It's a showstopper. Even something like $nitro.config_item is a workable compromise there because it could easily integrate something like $nitro['app1'].config_item if Nitro ever moves in a direction to allow multiple side-by-side applications - there's very little paradigm shift there. > As for Sandbox, it'd be great but currently afaik it's horribly slow. I figured it probably was. Too bad. Kirk From transfire at gmail.com Mon Feb 5 11:52:32 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Mon, 05 Feb 2007 16:52:32 -0000 Subject: [Nitro] Singletons In-Reply-To: <20070205105805.42df692a.zedshaw@zedshaw.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> <20070205105805.42df692a.zedshaw@zedshaw.com> Message-ID: <1170694352.335611.77340@a34g2000cwb.googlegroups.com> On Feb 5, 1:58 pm, "Zed A. Shaw" wrote: > Yeah, I'll be bringing this and other stuff up on the Mongrel list, but my comment was more that framework developers tend to assume they are THE ONE TRUE FRAMEWORK and don't play well with others. It's be nice if they assumed otherwise and then it'd be easier for Mongrel to at least run multiple instances of the same framework but different apps in small installations. I'd like to discuss this. How can be accomplished easily? I've been thinking about it. Lets say we start off with: my_nitro_app = Nitro::Application.new( ... ) So now when I define other elements of my app, say a controller, or module, how do they get tied into this instance? T. From nitrojesus.5.pistos at geoshell.com Mon Feb 5 12:09:10 2007 From: nitrojesus.5.pistos at geoshell.com (nitrojesus.5.pistos at geoshell.com) Date: Mon, 5 Feb 2007 12:09:10 -0500 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> Message-ID: <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> On 05/02/07, Jonathan Buch - john at oxyliquit.de wrote: > > Anyway, I will not touch the current configuration system for the time > > being (until someone suggests a clearly better alternative). Could the specific problems be listed definitively? Then we can take the various proposed alternatives and examine how each one deals with (or fails to address) each problem specifically, and also what new problems it introduces. I think a good point was raised in that we need to state just what things are being configured, so that they can be segregated into (1) system-wide configuration (all Nitro servers running), (2) instance-specific configuration (differs per Nitro server); and (a) class-shared configuration vs. (b) object/instance configuration. I still am unconvinced that there is a need to configure anything before it is instantiated (in the case of objects) or declared (in the case of classes). Can we get a couple of examples? From wyhaines at gmail.com Mon Feb 5 12:32:30 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 5 Feb 2007 10:32:30 -0700 Subject: [Nitro] Simpler configuration method? In-Reply-To: <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> Message-ID: > I still am unconvinced that there is a need to configure anything > before it is instantiated (in the case of objects) or declared (in the > case of classes). Can we get a couple of examples? Here's the use case: You have a web site with public content and private content. The private content is by login only. Your config file contains all of the db connection information as well as all of your web app config information. You are asked to write a script which checks the database for accounts which have been approved, but which haven't been confirmed by the subscriber, and which have been sitting for more than 96 hours. You would like to just reuse your main config file. No sense duplicating the db connect info elsewhere, right? But you can't because you aren't starting the entire application environment -- you are just using Og, so none of the Nitro specific stuff that your config file has configuration for exists. Kirk Haines From george.moschovitis at gmail.com Mon Feb 5 12:45:10 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 19:45:10 +0200 Subject: [Nitro] Singletons In-Reply-To: References: <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> <20070205105805.42df692a.zedshaw@zedshaw.com> Message-ID: > > 1) PR. Ruby people generally don't like the stuff that looks Perlish > (though the people who come to Ruby from Perl don't tend to care > much), so a lot of $variables_like_this is going to come off to many > people as ugly and backwards, regardless of what the real merits might > be. > This is reason enough to avoid globals... -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/09ee0188/attachment.html From george.moschovitis at gmail.com Mon Feb 5 12:47:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 19:47:36 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> Message-ID: I added your files and get errors. I will investigate your patch some more. On thing that worries my are the potential speed penalty of this patch (I am not sure there is a penalty, will have to think about this). thanks, -g. On 2/5/07, George Moschovitis wrote: > > I was going to suggest the same to you ;-) > > I will add your files, > > thanks > > > On 2/5/07, Judson Lester < nyarly at gmail.com> wrote: > > > Huh. I get the same result: I approve 11 patches to pull, and then it > > never returns. > > > > Tell you what: attached are the two files I've made changes to. I'm > > just going to trash my repo and start over, unless you have a better > > idea. > > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > > > Judson > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/a486e880/attachment.html From malte at gmx-topmail.de Mon Feb 5 12:48:27 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Mon, 05 Feb 2007 18:48:27 +0100 Subject: [Nitro] Singletons In-Reply-To: <1170694352.335611.77340@a34g2000cwb.googlegroups.com> References: <1170596274.317797.252340@m58g2000cwm.googlegroups.com> <1170614026.240426.136820@h3g2000cwc.googlegroups.com> <1170619549.421526.282110@l53g2000cwa.googlegroups.com> <20070204154148.fd00ee17.zedshaw@zedshaw.com> <20070205105805.42df692a.zedshaw@zedshaw.com> <1170694352.335611.77340@a34g2000cwb.googlegroups.com> Message-ID: <1170697707.6347.15.camel@aligatoro.ret> transfire at gmail.com: > I'd like to discuss this. How can be accomplished easily? I've been > thinking about it. Lets say we start off with: > > my_nitro_app = Nitro::Application.new( ... ) > > So now when I define other elements of my app, say a controller, or > module, how do they get tied into this instance? A controller could e. g. be tied like this: my_nitro_app.mount('/' => MyController) This may be delegated to my_nitro_app.server.mount, i.e. the method that really does the work would be Nitro::Server#mount. I'm looking forward for further examples of how such an API may look. It means basically that functionality is moved from global constants (in this case, Nitro::Server) to instances that do not have to be globally accessible. As I understand it, this would be a total redesign of Nitro, and I'm not sure whether that will be a good thing. The example shows, though, that Dependency Injection / Inversion of Control is nothing complicated per se. The point is simply that you have mainly instance methods, as opposed to having mainly Module methods. Regards, Malte From nyarly at gmail.com Mon Feb 5 13:28:24 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 5 Feb 2007 10:28:24 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> Message-ID: <8905c87a0702051028u342f18fchf35f0494ec8b62f1@mail.gmail.com> Feel free to benchmark it. It probably possible to find some middle ground, where a eval-able string gets created for the class, and og_insert does the eval-ing. Something like that. What sort of errors are you getting? I know that the new write_attr wasn't working with the old adaptors - mysql.rb had to be updated. But the update is really simple. Judson On 2/5/07, George Moschovitis wrote: > I added your files and get errors. I will investigate your patch some more. > On thing that worries my are the potential speed penalty of this patch (I am > not sure there is a penalty, will have to think about this). > > thanks, > -g. > > > On 2/5/07, George Moschovitis wrote: > > I was going to suggest the same to you ;-) > > > > I will add your files, > > > > thanks > > > > > > > > > > On 2/5/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > > Huh. I get the same result: I approve 11 patches to pull, and then it > > > never returns. > > > > > > Tell you what: attached are the two files I've made changes to. I'm > > > just going to trash my repo and start over, unless you have a better > > > idea. > > > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > > > > > Judson > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Mon Feb 5 13:29:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 20:29:52 +0200 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> Message-ID: Thanks for helping me with this. My limited knowledge of the English language prohibits me from explaining the inefficiencies of the current implementation with such a nice example. -g. On 2/5/07, Kirk Haines wrote: > > > I still am unconvinced that there is a need to configure anything > > before it is instantiated (in the case of objects) or declared (in the > > case of classes). Can we get a couple of examples? > > Here's the use case: > > You have a web site with public content and private content. The > private content is by login only. Your config file contains all of > the db connection information as well as all of your web app config > information. > > You are asked to write a script which checks the database for accounts > which have been approved, but which haven't been confirmed by the > subscriber, and which have been sitting for more than 96 hours. You > would like to just reuse your main config file. No sense duplicating > the db connect info elsewhere, right? > > But you can't because you aren't starting the entire application > environment -- you are just using Og, so none of the Nitro specific > stuff that your config file has configuration for exists. > > > Kirk Haines > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/eef50ba3/attachment-0001.html From george.moschovitis at gmail.com Mon Feb 5 13:31:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 20:31:55 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702051028u342f18fchf35f0494ec8b62f1@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702021048p164b30c0pf8d8d1f4a6fc0769@mail.gmail.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> <8905c87a0702051028u342f18fchf35f0494ec8b62f1@mail.gmail.com> Message-ID: > > > What sort of errors are you getting? I know that the new write_attr > wasn't working with the old adaptors - mysql.rb had to be updated. > But the update is really simple. I am using mysql. this is the error I am getting: DEBUG: Rendering '/'. DEBUG: SELECT COUNT(*) AS COUNT FROM oglink WHERE live = 1 DEBUG: SELECT * FROM oglink WHERE live = 1 ORDER BY create_time DESC LIMIT 20 ERROR: wrong number of arguments (2 for 0) ERROR: /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in `og_read' /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in `read_all' /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:17:in `each_row' /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:16:in `each_row' /home/gmosx/code/public/og/lib/og/store/sql.rb:1112:in `read_all' /home/gmosx/code/public/og/lib/og/store/sql.rb:374:in `find' /home/gmosx/code/public/og/lib/og/entity.rb:266:in `all' -g. On 2/5/07, Judson Lester wrote: > > Feel free to benchmark it. It probably possible to find some middle > ground, where a eval-able string gets created for the class, and > og_insert does the eval-ing. Something like that. > Judson > > On 2/5/07, George Moschovitis wrote: > > I added your files and get errors. I will investigate your patch some > more. > > On thing that worries my are the potential speed penalty of this patch > (I am > > not sure there is a penalty, will have to think about this). > > > > thanks, > > -g. > > > > > > On 2/5/07, George Moschovitis wrote: > > > I was going to suggest the same to you ;-) > > > > > > I will add your files, > > > > > > thanks > > > > > > > > > > > > > > > On 2/5/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > > > > Huh. I get the same result: I approve 11 patches to pull, and then > it > > > > never returns. > > > > > > > > Tell you what: attached are the two files I've made changes to. I'm > > > > just going to trash my repo and start over, unless you have a better > > > > idea. > > > > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > > > > > > > Judson > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/7188eb05/attachment.html From nitrojesus.5.pistos at geoshell.com Mon Feb 5 13:47:09 2007 From: nitrojesus.5.pistos at geoshell.com (nitrojesus.5.pistos at geoshell.com) Date: Mon, 5 Feb 2007 13:47:09 -0500 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> Message-ID: <6c9d9ef0702051047uc2e2e5egd214f1a7fe0d6648@mail.gmail.com> On 05/02/07, Kirk Haines - wyhaines at gmail.com wrote: > > I still am unconvinced that there is a need to configure anything > > before it is instantiated (in the case of objects) or declared (in the > > case of classes). Can we get a couple of examples? > > Here's the use case: [snip] > But you can't because you aren't starting the entire application > environment -- you are just using Og, so none of the Nitro specific > stuff that your config file has configuration for exists. Okay, I see the use case, but I still don't see why, at the time Og the class is created, or an Og instance is instantiated -- at that time, load the config. Say, perhaps, inside the nitro.rb of "require 'nitro'" and the og.rb of require 'og'. It's just mystical to me... It's kind of like talking about how you drove from California to Houston in a car you didn't buy yet. :P No. Think of it as a big book of recipies. Some of them are for things that use the stove top, and some of them are for things that use the oven. But both live in the same book. Your thinking is that the configuration should just logically be separated so that the db configs are in one place and the web framework specific configs in a separate file, right? Then it would just naturally eliminate this issue, right? Maybe, if it's necessary to do so, then we should. I'm no expert, but isn't the problem you cited above an instance of coupling? i.e. you're trying to do Og stuff, and this other Nitro stuff is KrazyGlued to it, so it has to tag along, even though you don't want it. I'd say the current config situation is an instance of tight coupling, because the configs are glued right to the things that use them. What george wants is loose coupling. The configs are floating out there in ruby-space, and the things that need them can find what they need while the ones that aren't needed are just ignored. I agree with that position. Right. We want them loosely coupled between domains, but tightly between the config and the config-needers. -*- Pistos reads http://en.wikipedia.org/wiki/Coupling_(computer_science) to refresh his memory. They are just config settings, and there is no real cost to having settings available that are not used, while there is a lot of convenience to having whatever configs one needs available without really having to think about it. -*- Pistos nods. I don't have issues with that. However, you just said that it's a problem that we are trying to do some Og stuff, and all of sudden this Nitro stuff is tagging along, but it "can't fit through the doorway", because the Nitro scaffolding hasn't been setup yet. If I am doing Og stuff, I expect that nearly nothing about Nitro should stand in my way. I think $global_soup is not a good way to do it, though. If I were doing it (and, well, I have already done it), I'd put the configs under a high level namespace, like Nitro. I'd have some minimal class that guarantees that the config space is setup properly, and it would have to be required before any config manipulation takes place. See, I can completely agree with all those points. Right. The current Nitro/Og setup has exactly that problem, because there is a tight coupling between Nitro and its configs, and Og and its configs. So one files that sets configs has to expect that there be all the goodies for Nitro and Og already loaded. -*- Pistos nods. One can work around that, to some extent, by doing what I think you suggested, which is to have separate config files for Nitro and Og. Require both for your web app config. Require only the Og file for standalone scripts. Exactly. From nyarly at gmail.com Mon Feb 5 14:04:07 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 5 Feb 2007 11:04:07 -0800 Subject: [Nitro] [OG] eval and style In-Reply-To: References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702021249j465d81d4gee0d7123bb789e47@mail.gmail.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> <8905c87a0702051028u342f18fchf35f0494ec8b62f1@mail.gmail.com> Message-ID: <8905c87a0702051104n771cd915te79df3813b54570f@mail.gmail.com> That's really strange. I can't find anywhere that og_allocate is defined with 0 arguments. Can you point me to a test that drives that behavior? If I could see it in a ruby on my machine, I might be abel to hunt it down. Judson On 2/5/07, George Moschovitis wrote: > > > > > What sort of errors are you getting? I know that the new write_attr > > wasn't working with the old adaptors - mysql.rb had to be updated. > > But the update is really simple. > > > > I am using mysql. this is the error I am getting: > > DEBUG: Rendering '/'. > DEBUG: SELECT COUNT(*) AS COUNT FROM oglink WHERE live = 1 > DEBUG: SELECT * FROM oglink WHERE live = 1 ORDER BY create_time DESC LIMIT > 20 > ERROR: wrong number of arguments (2 for 0) > ERROR: > /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in > `og_read' > /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in > `read_all' > /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:17:in > `each_row' > /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:16:in > `each_row' > /home/gmosx/code/public/og/lib/og/store/sql.rb:1112:in > `read_all' > /home/gmosx/code/public/og/lib/og/store/sql.rb:374:in > `find' > /home/gmosx/code/public/og/lib/og/entity.rb:266:in `all' > > > -g. > > > On 2/5/07, Judson Lester wrote: > > Feel free to benchmark it. It probably possible to find some middle > > ground, where a eval-able string gets created for the class, and > > og_insert does the eval-ing. Something like that. > > > > > Judson > > > > On 2/5/07, George Moschovitis wrote: > > > I added your files and get errors. I will investigate your patch some > more. > > > On thing that worries my are the potential speed penalty of this patch > (I am > > > not sure there is a penalty, will have to think about this). > > > > > > thanks, > > > -g. > > > > > > > > > On 2/5/07, George Moschovitis < george.moschovitis at gmail.com> wrote: > > > > I was going to suggest the same to you ;-) > > > > > > > > I will add your files, > > > > > > > > thanks > > > > > > > > > > > > > > > > > > > > On 2/5/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > > > > > > Huh. I get the same result: I approve 11 patches to pull, and then > it > > > > > never returns. > > > > > > > > > > Tell you what: attached are the two files I've made changes to. I'm > > > > > just going to trash my repo and start over, unless you have a better > > > > > idea. > > > > > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > > > > > > > > > Judson > > > > > > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > http://blog.gmosx.com > > > > http://cull.gr > > > > http://www.joy.gr > > > > http://nitroproject.org > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Mon Feb 5 14:08:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 21:08:58 +0200 Subject: [Nitro] Problem with aspects (in Facets). Message-ID: While trying to make the no-eval sql.rb patch to work I found out that Aspects#wrap did not work as expected (at least for methods with default parameters, due to the way that airty works in Ruby). Here is a fix: def self.wrap(target, methods = target.instance_methods) include_advice_modules(target) for m in [methods].flatten target.module_eval <<-end_eval, __FILE__, __LINE__ alias_method :__unwrapped_#{m}, :#{m} def #{m}(*args) #{gen_advice_code(m, target.advices, :pre)} __unwrapped_#{m}(*args) #{gen_advice_code(m, target.advices, :post)} end end_eval end end this seems to work... But, I would like to ask Tom to have a look at the Aspects implementation and perhaps work his magic on a better solution. In the meantime please include this fix in facets/more/aspects.rb -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/733d2256/attachment.html From nyarly at gmail.com Mon Feb 5 14:34:59 2007 From: nyarly at gmail.com (nyarly at gmail.com) Date: Mon, 05 Feb 2007 19:34:59 -0000 Subject: [Nitro] Problem with aspects (in Facets). In-Reply-To: References: Message-ID: <1170704099.843833.188780@p10g2000cwp.googlegroups.com> Tom and I actually had a back and forth about this. The dependency slipped my mind: The only addendum to make to that fix is: ... def #{m}(*args, &block) #{gen_advice_code(m, target.advices, :pre)} __unwrapped_#{m}(*args, &block) ... On Feb 5, 11:08 am, "George Moschovitis" wrote: > While trying to make the no-eval sql.rb patch to work I found out that > Aspects#wrap did not work as expected (at least for methods with default > parameters, due to the way that airty works in Ruby). Here is a fix: > > def self.wrap(target, methods = target.instance_methods) > include_advice_modules(target) > > for m in [methods].flatten > target.module_eval <<-end_eval, __FILE__, __LINE__ > alias_method :__unwrapped_#{m}, :#{m} > def #{m}(*args) > #{gen_advice_code(m, target.advices, :pre)} > __unwrapped_#{m}(*args) > #{gen_advice_code(m, target.advices, :post)} > end > end_eval > end > end > > this seems to work... But, I would like to ask Tom to have a look at the > Aspects implementation and perhaps work his magic on a better solution. > In the meantime please include this fix in facets/more/aspects.rb > > -g. > > --http://blog.gmosx.comhttp://cull.grhttp://www.joy.grhttp://nitroproject.org > > _______________________________________________ > Nitro-general mailing list > Nitro-gene... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Mon Feb 5 15:06:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 22:06:31 +0200 Subject: [Nitro] [OG] eval and style In-Reply-To: <8905c87a0702051104n771cd915te79df3813b54570f@mail.gmail.com> References: <1170276785.656493.223630@j27g2000cwj.googlegroups.com> <8905c87a0702041210y77046a93qdd9275886d606ac6@mail.gmail.com> <8905c87a0702042032y773e608fyb371ab1227cfbd07@mail.gmail.com> <8905c87a0702051028u342f18fchf35f0494ec8b62f1@mail.gmail.com> <8905c87a0702051104n771cd915te79df3813b54570f@mail.gmail.com> Message-ID: the problem was with the Aspects#wrap method, see my other post for details... now your patch seems to work. I will have to polish the file a little bit more but it is definitely a step to the right direction. I hope to see more patches from you ;-) -g On 2/5/07, Judson Lester wrote: > > That's really strange. I can't find anywhere that og_allocate is > defined with 0 arguments. Can you point me to a test that drives that > behavior? If I could see it in a ruby on my machine, I might be abel > to hunt it down. > > Judson > > On 2/5/07, George Moschovitis wrote: > > > > > > > > What sort of errors are you getting? I know that the new write_attr > > > wasn't working with the old adaptors - mysql.rb had to be updated. > > > But the update is really simple. > > > > > > > > I am using mysql. this is the error I am getting: > > > > DEBUG: Rendering '/'. > > DEBUG: SELECT COUNT(*) AS COUNT FROM oglink WHERE live = 1 > > DEBUG: SELECT * FROM oglink WHERE live = 1 ORDER BY create_time DESC > LIMIT > > 20 > > ERROR: wrong number of arguments (2 for 0) > > ERROR: > > /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in > > `og_read' > > /home/gmosx/code/public/og/lib/og/store/sql.rb:1114:in > > `read_all' > > /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:17:in > > `each_row' > > /home/gmosx/code/public/og/lib/og/adapter/mysql/override.rb:16:in > > `each_row' > > /home/gmosx/code/public/og/lib/og/store/sql.rb:1112:in > > `read_all' > > /home/gmosx/code/public/og/lib/og/store/sql.rb:374:in > > `find' > > /home/gmosx/code/public/og/lib/og/entity.rb:266:in `all' > > > > > > -g. > > > > > > On 2/5/07, Judson Lester wrote: > > > Feel free to benchmark it. It probably possible to find some middle > > > ground, where a eval-able string gets created for the class, and > > > og_insert does the eval-ing. Something like that. > > > > > > > > Judson > > > > > > On 2/5/07, George Moschovitis wrote: > > > > I added your files and get errors. I will investigate your patch > some > > more. > > > > On thing that worries my are the potential speed penalty of this > patch > > (I am > > > > not sure there is a penalty, will have to think about this). > > > > > > > > thanks, > > > > -g. > > > > > > > > > > > > On 2/5/07, George Moschovitis < george.moschovitis at gmail.com> wrote: > > > > > I was going to suggest the same to you ;-) > > > > > > > > > > I will add your files, > > > > > > > > > > thanks > > > > > > > > > > > > > > > > > > > > > > > > > On 2/5/07, Judson Lester < nyarly at gmail.com> wrote: > > > > > > > > > > > > Huh. I get the same result: I approve 11 patches to pull, and > then > > it > > > > > > never returns. > > > > > > > > > > > > Tell you what: attached are the two files I've made changes > to. I'm > > > > > > just going to trash my repo and start over, unless you have a > better > > > > > > idea. > > > > > > (they're og/store/sql.rb and og/adaptor/mysql.rb) > > > > > > > > > > > > Judson > > > > > > > > > > > > _______________________________________________ > > > > > > Nitro-general mailing list > > > > > > Nitro-general at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://blog.gmosx.com > > > > > http://cull.gr > > > > > http://www.joy.gr > > > > > http://nitroproject.org > > > > > > > > > > > > > > > > -- > > > > http://blog.gmosx.com > > > > http://cull.gr > > > > http://www.joy.gr > > > > http://nitroproject.org > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/a867564f/attachment.html From george.moschovitis at gmail.com Mon Feb 5 15:07:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 5 Feb 2007 22:07:55 +0200 Subject: [Nitro] Problem with aspects (in Facets). In-Reply-To: <1170704099.843833.188780@p10g2000cwp.googlegroups.com> References: <1170704099.843833.188780@p10g2000cwp.googlegroups.com> Message-ID: > > > ... > def #{m}(*args, &block) > #{gen_advice_code(m, target.advices, :pre)} > __unwrapped_#{m}(*args, &block) > right, the block must be preserved as well. Hopefully Tom will integrate the change in the next version. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070205/9638f91b/attachment.html From transfire at gmail.com Tue Feb 6 01:34:08 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 06 Feb 2007 06:34:08 -0000 Subject: [Nitro] nitro-grougp-google Message-ID: <1170743648.047156.200610@a75g2000cwd.googlegroups.com> Hi-- I realized the other day that there is no real need for the "-google" portion of the google group name. the @googlegroups.com sort of gives it away ;-) So if it's okay with the google group members I'm going to change the name to just "nitro-general". Probably doesn't matter whatsoever, but just in case I wanted to give a heads up. T. From transfire at gmail.com Tue Feb 6 08:43:06 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 06 Feb 2007 13:43:06 -0000 Subject: [Nitro] Problem with aspects (in Facets). In-Reply-To: References: <1170704099.843833.188780@p10g2000cwp.googlegroups.com> Message-ID: <1170769386.110076.179490@k78g2000cwa.googlegroups.com> On Feb 5, 3:07 pm, "George Moschovitis" wrote: > > ... > > def #{m}(*args, &block) > > #{gen_advice_code(m, target.advices, :pre)} > > __unwrapped_#{m}(*args, &block) > > right, the block must be preserved as well. Hopefully Tom will integrate > the change in the next version. will do. and probably will be out today. assuming nothing comes up this will be the last rc before offical release of the 1.8 series. T. From transfire at gmail.com Tue Feb 6 11:40:29 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 06 Feb 2007 16:40:29 -0000 Subject: [Nitro] nitro-grougp-google In-Reply-To: <1170743648.047156.200610@a75g2000cwd.googlegroups.com> References: <1170743648.047156.200610@a75g2000cwd.googlegroups.com> Message-ID: <1170780029.898919.84640@l53g2000cwa.googlegroups.com> On Feb 6, 1:34 am, transf... at gmail.com wrote: > Hi-- > > I realized the other day that there is no real need for the "-google" > portion of the google group name. the @googlegroups.com sort of gives > it away ;-) So if it's okay with the google group members I'm going to > change the name to just "nitro-general". Probably doesn't matter > whatsoever, but just in case I wanted to give a heads up. Okay.... going to do it.... 3 2 1... T. From transfire at gmail.com Tue Feb 6 12:57:26 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 06 Feb 2007 17:57:26 -0000 Subject: [Nitro] nitro-grougp-google In-Reply-To: <1170780029.898919.84640@l53g2000cwa.googlegroups.com> References: <1170743648.047156.200610@a75g2000cwd.googlegroups.com> <1170780029.898919.84640@l53g2000cwa.googlegroups.com> Message-ID: <1170784646.607654.149530@a75g2000cwd.googlegroups.com> On Feb 6, 11:40 am, transf... at gmail.com wrote: > Okay.... going to do it.... 3 2 1... Done. T. From george.moschovitis at gmail.com Tue Feb 6 12:58:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 6 Feb 2007 19:58:23 +0200 Subject: [Nitro] Problem with aspects (in Facets). In-Reply-To: <1170769386.110076.179490@k78g2000cwa.googlegroups.com> References: <1170704099.843833.188780@p10g2000cwp.googlegroups.com> <1170769386.110076.179490@k78g2000cwa.googlegroups.com> Message-ID: thanks... -g. On 2/6/07, transfire at gmail.com wrote: > > > > On Feb 5, 3:07 pm, "George Moschovitis" > wrote: > > > ... > > > def #{m}(*args, &block) > > > #{gen_advice_code(m, target.advices, :pre)} > > > __unwrapped_#{m}(*args, &block) > > > > right, the block must be preserved as well. Hopefully Tom will > integrate > > the change in the next version. > > will do. and probably will be out today. assuming nothing comes up > this will be the last rc before offical release of the 1.8 series. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070206/a20ef08c/attachment-0001.html From george.moschovitis at gmail.com Tue Feb 6 17:23:48 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 7 Feb 2007 00:23:48 +0200 Subject: [Nitro] Repo warning Message-ID: Dear devs, for tomorrow I will start pushing some bigger changes to the repo. I am updating the repo to allow people like Judson and Tom (that are currently helping me with the latest changes) can follow along. You can expect the repo to remain unstable for the next 10 days or so. My aim is to remove unused code, and simplify the implementation wherever I can... regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070207/41b6cbb3/attachment.html From transfire at gmail.com Tue Feb 6 17:32:35 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 06 Feb 2007 22:32:35 -0000 Subject: [Nitro] reap name 4 rake project In-Reply-To: <1170674764.234731.255110@v45g2000cwv.googlegroups.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> <1170674764.234731.255110@v45g2000cwv.googlegroups.com> Message-ID: <1170801155.417053.20300@h3g2000cwc.googlegroups.com> hey all, good news. I made up my mind. the new project will be called "autorake". i feel "reap" should remain it's own project, even if it is now outdated, b/c it doesn't use rake, so it is fundamentally different. and it's still possible that i may fix reap up and backport some of this work to it in the furture. anyway, i have a few more adjustments I want to make, then i'll release the initial version. thanks for all your thoughts, btw. they help much more than you might realize! t. From transfire at gmail.com Tue Feb 6 17:38:28 2007 From: transfire at gmail.com (TRANS) Date: Tue, 6 Feb 2007 17:38:28 -0500 Subject: [Nitro] Facets 1.8.20 Message-ID: <4b6f054f0702061438u4ac4beb2jbdaeb0c3c6665cca@mail.gmail.com> Facets 1.8.20 is out. This should be the last Release Candidate of the 1.8 series before I stamp it Stable. BTW, I'm finding myself moving toward an odd dev, even stable versioning system. So 1.9 will be purely a development series leading up to 2.0. Is this just the natural evolution of all versoning schemes? ;-) T. From manveru at weez-int.com Tue Feb 6 20:25:05 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Wed, 07 Feb 2007 10:25:05 +0900 Subject: [Nitro] Simpler configuration method? In-Reply-To: References: <1170601487.5586.25.camel@aligatoro.ret> <1170603831.363774.8120@j27g2000cwj.googlegroups.com> <6c9d9ef0702050909n5fdbceacxda1b81ffb959c37e@mail.gmail.com> Message-ID: On Tue, 06 Feb 2007 03:29:52 +0900, George Moschovitis wrote: > Thanks for helping me with this. My limited knowledge of the English > language prohibits me from explaining the inefficiencies of the current > implementation with such a nice example. > > -g. > > On 2/5/07, Kirk Haines wrote: >> >> > I still am unconvinced that there is a need to configure anything >> > before it is instantiated (in the case of objects) or declared (in the >> > case of classes). Can we get a couple of examples? >> >> Here's the use case: >> >> You have a web site with public content and private content. The >> private content is by login only. Your config file contains all of >> the db connection information as well as all of your web app config >> information. >> >> You are asked to write a script which checks the database for accounts >> which have been approved, but which haven't been confirmed by the >> subscriber, and which have been sitting for more than 96 hours. You >> would like to just reuse your main config file. No sense duplicating >> the db connect info elsewhere, right? >> >> But you can't because you aren't starting the entire application >> environment -- you are just using Og, so none of the Nitro specific >> stuff that your config file has configuration for exists. Well, haven't said much in this discussion yet - but it certainly got me thinking. Since I work on the configuration-system for Ramaze it's been a tough challenge, but i came up with the solution of using a slightly modified OpenStruct called GlobalStruct, then i create an instance of it in the main-namespace (Ramaze::Global) as soon as one requires the file that defines the Global it will be filled with the default-values. One important thing that is especially nasty are custom classes/objects held in it. So I added handling of symbols/strings to all parts of the code that use the configuration later on. This makes for some bloat, but in general it offers a very nice way to do specification of classes that are not yet instantianted/defined (similar to how Og uses const_missing to catch the relations, but without the magic ;) so, as an example: ################################################# require 'global' Global.setup do |g| g.adapter = :mongrel g.cache = :MemoryCache end # or Global.setup YAML.load_file('conf/stage.yaml') Where the yaml just contains an Hash like: { :adapter => :mongrel, :cache => :MemoryCache }.to_yaml # => --- :adapter: :mongrel :cache: :MemoryCache ################################################# The point is to have one central point for the configuration. The configuration in Nitro is IMHO too tight coupled with the things that use them. Providing only one point for it allows for drastic improvments in documentability and interfacing that configuration. ^manveru >> Kirk Haines From m.fellinger at gmail.com Tue Feb 6 21:58:47 2007 From: m.fellinger at gmail.com (Michael Fellinger) Date: Wed, 7 Feb 2007 11:58:47 +0900 Subject: [Nitro] reap name 4 rake project In-Reply-To: <1170801155.417053.20300@h3g2000cwc.googlegroups.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> <1170674764.234731.255110@v45g2000cwv.googlegroups.com> <1170801155.417053.20300@h3g2000cwc.googlegroups.com> Message-ID: <9c00d3e00702061858i46ffebc9kc0a8fb2024a459ce@mail.gmail.com> On 2/7/07, transfire at gmail.com wrote: > hey all, > > good news. I made up my mind. the new project will be called > "autorake". i feel "reap" should remain it's own project, even if it > is now outdated, b/c it doesn't use rake, so it is fundamentally > different. and it's still possible that i may fix reap up and backport > some of this work to it in the furture. > > anyway, i have a few more adjustments I want to make, then i'll > release the initial version. > > thanks for all your thoughts, btw. they help much more than you might > realize! and off he goes to change the world... i really like the name autorake :) > > t. From dan at tastapod.com Wed Feb 7 09:21:36 2007 From: dan at tastapod.com (Dan North) Date: Wed, 07 Feb 2007 14:21:36 +0000 Subject: [Nitro] reap name 4 rake project In-Reply-To: <9c00d3e00702061858i46ffebc9kc0a8fb2024a459ce@mail.gmail.com> References: <1170370910.453650.181460@p10g2000cwp.googlegroups.com> <1170614511.861640.215020@v45g2000cwv.googlegroups.com> <1170620628.734190.9470@j27g2000cwj.googlegroups.com> <1170674764.234731.255110@v45g2000cwv.googlegroups.com> <1170801155.417053.20300@h3g2000cwc.googlegroups.com> <9c00d3e00702061858i46ffebc9kc0a8fb2024a459ce@mail.gmail.com> Message-ID: <45C9E070.3010302@tastapod.com> How about "brake"? As in: "I'm going to brake the build" :) Michael Fellinger wrote: > On 2/7/07, transfire at gmail.com wrote: > >> hey all, >> >> good news. I made up my mind. the new project will be called >> "autorake". i feel "reap" should remain it's own project, even if it >> is now outdated, b/c it doesn't use rake, so it is fundamentally >> different. and it's still possible that i may fix reap up and backport >> some of this work to it in the furture. >> >> anyway, i have a few more adjustments I want to make, then i'll >> release the initial version. >> >> thanks for all your thoughts, btw. they help much more than you might >> realize! >> > > and off he goes to change the world... > > i really like the name autorake :) > > >> t. >> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070207/0ff881fb/attachment.html From george.moschovitis at gmail.com Wed Feb 7 16:36:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 7 Feb 2007 23:36:55 +0200 Subject: [Nitro] Using Facets Builder Message-ID: Tom, I would like to get rid of Glue's implementation of Builder and use the Facets builder instead. Given the fact that I am working on other parts of Nitro/Og at the moment I am wondering if you (or someone else) can help me here. Youm most probably have to adapt the files: lib/nitro/helper/form lib/nitro/helper/xhtml lib/nitro/render -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070207/40a027c9/attachment.html From transfire at gmail.com Wed Feb 7 20:46:43 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 01:46:43 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: Message-ID: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> On Feb 7, 4:36 pm, "George Moschovitis" wrote: > Tom, > > I would like to get rid of Glue's implementation of Builder and use the > Facets builder instead. Given the fact that I am working on other parts of > Nitro/Og at the moment I am wondering if you (or someone else) can help me > here. Youm most probably have to adapt the files: > > lib/nitro/helper/form > lib/nitro/helper/xhtml > lib/nitro/render i'll have a look. btw, what did you think of the new builder code? pretty sexy? ;-) the neat thing is you just take a function module with all your helpers and drop it in and wham -- it builds. at least that's the idea... not lets see how it plays in the real world ;-) t. T. > -g. > > --http://blog.gmosx.comhttp://cull.grhttp://www.joy.grhttp://nitroproject.org > > _______________________________________________ > Nitro-general mailing list > Nitro-gene... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Thu Feb 8 04:08:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 11:08:27 +0200 Subject: [Nitro] Using Facets Builder In-Reply-To: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> Message-ID: > > i'll have a look. > thanks! If you need something, let me know... -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/dea2f561/attachment-0001.html From transfire at gmail.com Thu Feb 8 04:51:51 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 09:51:51 -0000 Subject: [Nitro] Example Comments Message-ID: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> I would like to request that code have examples put in the comments. When working on something it's hard to understand how methods/classes/ modules are intended to work without some examples. Thanks, T. From transfire at gmail.com Thu Feb 8 04:53:40 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 09:53:40 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> Message-ID: <1170928420.988730.231720@m58g2000cwm.googlegroups.com> On Feb 8, 4:08 am, "George Moschovitis" wrote: > > i'll have a look. > > thanks! If you need something, let me know... render.rb, where does this get used? # Access the programmatic renderer (builder). def build(&block) if block.arity == 1 yield XmlBuilder.new(@out) else XmlBuilder.new(@out).instance_eval(&block) end end T. From george.moschovitis at gmail.com Thu Feb 8 05:00:05 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 12:00:05 +0200 Subject: [Nitro] Using Facets Builder In-Reply-To: <1170928420.988730.231720@m58g2000cwm.googlegroups.com> References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> <1170928420.988730.231720@m58g2000cwm.googlegroups.com> Message-ID: It is an algternative way to generate html for your action. Here are two examples: # This is a programmatic renderer example. Just for # demonstration purposes. Some people tend to like this # aproach, dunno why, really. def prender build do |r| labels = ['George', 'Stella', 'Renos'] r.html { r.head { r.title 'A simple test' } r.body { 10.times { r.strong 'Hello World' r.br r.i 'Hello World' r.br } r.select(:id => 'names') { r.options :labels => labels, :selected => 1 } } } end end # The same example in different flavour :) def prender2 build do labels = ['George', 'Stella', 'Renos'] html { head { title 'A simple test' } body { 10.times { strong 'Hello World' br i 'Hello World222' br } select(:id => 'names') { options :labels => labels, :selected => 1 } } } end end on a nutchell, build just returns a builder instance. Btw, do not change your implementation to be compatible with this, just make build return your builder instance. But please make sure that your implementation can be used in the form helper (this helper, unlike the build command, is used very often) regards, George. On 2/8/07, transfire at gmail.com wrote: > > > > On Feb 8, 4:08 am, "George Moschovitis" > wrote: > > > i'll have a look. > > > > thanks! If you need something, let me know... > > render.rb, where does this get used? > > # Access the programmatic renderer (builder). > > def build(&block) > if block.arity == 1 > yield XmlBuilder.new(@out) > else > XmlBuilder.new(@out).instance_eval(&block) > end > end > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/6ee409c7/attachment.html From george.moschovitis at gmail.com Thu Feb 8 05:26:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 12:26:28 +0200 Subject: [Nitro] Example Comments In-Reply-To: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> Message-ID: Ok will try to do it. I would also like to ask anyone that is familiar with Nitro to send some patches with extra comments. thanks, George. On 2/8/07, transfire at gmail.com wrote: > > I would like to request that code have examples put in the comments. > When working on something it's hard to understand how methods/classes/ > modules are intended to work without some examples. > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/a330371b/attachment.html From transfire at gmail.com Thu Feb 8 05:27:39 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 10:27:39 -0000 Subject: [Nitro] Ungluing Glue Message-ID: <1170930459.403479.116860@a34g2000cwb.googlegroups.com> I noticed that glue sitll has Settings (and also still the name Configuration too). That's in Facets, so now that Nitro is working with latest Facets, can we get rid of that? What about the rest of glue? How do we stand on that? Also, I noticed lib/html is gone. That's good. It was a lib namespace faux paux. But now we have lib/part. That needs to be either renamed like lib/nitropart/, or probably better, moved into nitro/, ie. lib/ nitro/part T. From george.moschovitis at gmail.com Thu Feb 8 05:54:19 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 12:54:19 +0200 Subject: [Nitro] Ungluing Glue In-Reply-To: <1170930459.403479.116860@a34g2000cwb.googlegroups.com> References: <1170930459.403479.116860@a34g2000cwb.googlegroups.com> Message-ID: On 2/8/07, transfire at gmail.com wrote: > > I noticed that glue sitll has Settings (and also still the name > Configuration too). That's in Facets, so now that Nitro is working > with latest Facets, can we get rid of that? What about the rest of > glue? How do we stand on that? I will get rid of that... faux paux. But now we have lib/part. That needs to be either renamed > like lib/nitropart/, or probably better, moved into nitro/, ie. lib/ > nitro/part yeah, i am thinking about renaming this to /nitro/part... -g. T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/9f749ac9/attachment.html From transfire at gmail.com Thu Feb 8 06:18:26 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 11:18:26 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> <1170928420.988730.231720@m58g2000cwm.googlegroups.com> Message-ID: <1170933506.028728.89740@m58g2000cwm.googlegroups.com> On Feb 8, 5:00 am, "George Moschovitis" wrote: > It is an algternative way to generate html for your action. Here are two > examples: > > # This is a programmatic renderer example. Just for > # demonstration purposes. Some people tend to like this > # aproach, dunno why, really. > > def prender > build do |r| > labels = ['George', 'Stella', 'Renos'] > r.html { > r.head { > r.title 'A simple test' > } > r.body { > 10.times { > r.strong 'Hello World' > r.br > r.i 'Hello World' > r.br > } > r.select(:id => 'names') { > r.options :labels => labels, :selected => 1 > } > } > } > end > end > > # The same example in different flavour :) > > def prender2 > build do > labels = ['George', 'Stella', 'Renos'] > html { > head { > title 'A simple test' > } > body { > 10.times { > strong 'Hello World' > br > i 'Hello World222' > br > } > select(:id => 'names') { > options :labels => labels, :selected => 1 > } > } > } > end > end > > on a nutchell, build just returns a builder instance. Btw, do not change > your implementation to be compatible with this, just make build return your > builder instance. But please make sure that your implementation can be used > in the form helper (this helper, unlike the build command, is used very > often) got it. thanks. the form helper is a bit odd b/c it has a secondary builder inside of it. so i'm going to think about that --i'd like to avoid the double layer if it's possible. T. From transfire at gmail.com Thu Feb 8 11:03:03 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 16:03:03 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: Message-ID: <1170950583.519255.315810@s48g2000cws.googlegroups.com> On Feb 7, 4:36 pm, "George Moschovitis" wrote: > Tom, > > I would like to get rid of Glue's implementation of Builder and use the > Facets builder instead. Given the fact that I am working on other parts of > Nitro/Og at the moment I am wondering if you (or someone else) can help me > here. Youm most probably have to adapt the files: > > lib/nitro/helper/form > lib/nitro/helper/xhtml > lib/nitro/render What do you think of: Nitro::XhtmlHelper => Nitro::Html::Helper Nitro::TableHelper => Nitro::Html::TableHelper Nitro::FormHelper => Nitro::Html::FormHelper The distinction between xhtml vs. html is getting pretty moot these days. -t. From transfire at gmail.com Thu Feb 8 11:29:47 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 16:29:47 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> Message-ID: <1170952187.802654.33850@v45g2000cwv.googlegroups.com> On Feb 8, 4:08 am, "George Moschovitis" wrote: > > i'll have a look. > > thanks! If you need something, let me know... if errors = flash[:ERRORS] if errors.is_a? Array options[:errors].concat(errors) elsif errors.is_a? Glue::Validation::Errors options[:errors].concat(errors.to_a) else options[:errors] << errors end end from form.rb where does flash come in? it's complaing that it's undefined and I don't see where it gets defined? -t. From george.moschovitis at gmail.com Thu Feb 8 11:34:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 18:34:56 +0200 Subject: [Nitro] Using Facets Builder In-Reply-To: <1170952187.802654.33850@v45g2000cwv.googlegroups.com> References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> <1170952187.802654.33850@v45g2000cwv.googlegroups.com> Message-ID: When you call the form helper from an action flash is automagically defined (just like context/request/response/session, etc...) -g. On 2/8/07, transfire at gmail.com wrote: > > > > On Feb 8, 4:08 am, "George Moschovitis" > wrote: > > > i'll have a look. > > > > thanks! If you need something, let me know... > > if errors = flash[:ERRORS] > if errors.is_a? Array > options[:errors].concat(errors) > elsif errors.is_a? Glue::Validation::Errors > options[:errors].concat(errors.to_a) > else > options[:errors] << errors > end > end > > from form.rb where does flash come in? it's complaing that it's > undefined and I don't see where it gets defined? > > -t. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/fac7f62a/attachment.html From george.moschovitis at gmail.com Thu Feb 8 11:36:20 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 18:36:20 +0200 Subject: [Nitro] Using Facets Builder In-Reply-To: <1170950583.519255.315810@s48g2000cws.googlegroups.com> References: <1170950583.519255.315810@s48g2000cws.googlegroups.com> Message-ID: > > Nitro::XhtmlHelper => Nitro::Html::Helper > Nitro::TableHelper => Nitro::Html::TableHelper > Nitro::FormHelper => Nitro::Html::FormHelper > lets stick to Nitro::HtmlHelper Nitro::TableHelper Nitro::FormHelper there is no need for the extra ::Html:: -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/abfcd560/attachment.html From john at oxyliquit.de Thu Feb 8 11:37:18 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 08 Feb 2007 17:37:18 +0100 Subject: [Nitro] Using Facets Builder In-Reply-To: <1170952187.802654.33850@v45g2000cwv.googlegroups.com> References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> <1170952187.802654.33850@v45g2000cwv.googlegroups.com> Message-ID: Hi, > from form.rb where does flash come in? it's complaing that it's > undefined and I don't see where it gets defined? flash is from nitro, special 'object' for short time session storage. It's in nitro/lib/nitro/flash.rb and gets mixed into Controllers as far as I remember.. Hope that helps. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From william.full.moon at gmail.com Thu Feb 8 11:47:04 2007 From: william.full.moon at gmail.com (* William) Date: Fri, 9 Feb 2007 03:47:04 +1100 Subject: [Nitro] Example Comments In-Reply-To: References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> Message-ID: <000d01c74ba0$c796d530$0301a8c0@ghostgum> Can I add something to this? I reckon using the "=-begin ... =end" construct is best for these documentation type comments. That may be what people intended, it never hurts to make the notion specific. :-) _____ From: nitro-general-bounces at rubyforge.org [mailto:nitro-general-bounces at rubyforge.org] On Behalf Of George Moschovitis Sent: Thursday, 8 February 2007 21:26 To: General discussion about Nitro Subject: Re: [Nitro] Example Comments Importance: Low Ok will try to do it. I would also like to ask anyone that is familiar with Nitro to send some patches with extra comments. thanks, George. On 2/8/07, HYPERLINK "mailto:transfire at gmail.com"transfire at gmail.com wrote: I would like to request that code have examples put in the comments. When working on something it's hard to understand how methods/classes/ modules are intended to work without some examples. Thanks, T. _______________________________________________ Nitro-general mailing list HYPERLINK "mailto:Nitro-general at rubyforge.org"Nitro-general at rubyforge.org HYPERLINK "http://rubyforge.org/mailman/listinfo/nitro-general"http://rubyforge.org/ma ilman/listinfo/nitro-general -- HYPERLINK "http://blog.gmosx.com"http://blog.gmosx.com HYPERLINK "http://cull.gr"http://cull.gr HYPERLINK "http://www.joy.gr"http://www.joy.gr HYPERLINK "http://nitroproject.org"http://nitroproject.org -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.25/669 - Release Date: 04-Feb-2007 21:58 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/b04d58a3/attachment.html From transfire at gmail.com Thu Feb 8 12:27:35 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 08 Feb 2007 17:27:35 -0000 Subject: [Nitro] Using Facets Builder In-Reply-To: References: <1170899203.956090.79290@h3g2000cwc.googlegroups.com> <1170952187.802654.33850@v45g2000cwv.googlegroups.com> Message-ID: <1170955655.356394.15920@j27g2000cwj.googlegroups.com> On Feb 8, 11:34 am, "George Moschovitis" wrote: > When you call the form helper from an action flash is automagically defined > (just like context/request/response/session, etc...) hmm... but what if it's not called from an "action flash", right now my code is choking on this. T. From john at oxyliquit.de Thu Feb 8 14:21:19 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 08 Feb 2007 20:21:19 +0100 Subject: [Nitro] Example Comments In-Reply-To: <000d01c74ba0$c796d530$0301a8c0@ghostgum> References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> Message-ID: Hi, >> I would like to request that code have examples put in the comments. >> When working on something it's hard to understand how methods/classes/ >> modules are intended to work without some examples. > I reckon using the "=begin ... =end" construct is best for these > documentation type comments. >That may be what people intended, it never hurts to make the notion > specific. I very rarely see =begin =end in Ruby code. If, then mostly to encapsulate a bigger chunk of code which is not to be executed. Using normal rdoc features (# and at least 4 spaces IIRC) you get a code block which is presented nicely by rdoc. I see no need for another kind of documenting type. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Thu Feb 8 15:03:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 8 Feb 2007 22:03:52 +0200 Subject: [Nitro] Example Comments In-Reply-To: References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> Message-ID: > > I very rarely see =begin =end in Ruby code. If, then mostly to > encapsulate > a bigger chunk of code which is not to be executed. > I agree... -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070208/2b6dc06e/attachment.html From nyarly at gmail.com Thu Feb 8 17:25:09 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 8 Feb 2007 14:25:09 -0800 Subject: [Nitro] Example Comments In-Reply-To: References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> Message-ID: <8905c87a0702081425k5f244726o9746c2d8db63f040@mail.gmail.com> On 2/8/07, George Moschovitis wrote: > > > I very rarely see =begin =end in Ruby code. If, then mostly to > encapsulate > > a bigger chunk of code which is not to be executed. > > > > I agree... On the other hand, one of my favorite tricks is #=begin ... experimental code here ... =begin =end From nyarly at gmail.com Thu Feb 8 18:28:10 2007 From: nyarly at gmail.com (nyarly at gmail.com) Date: Thu, 08 Feb 2007 23:28:10 -0000 Subject: [Nitro] Error handling in ann_attr Message-ID: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> As a quickie: here's my buggy code: class Hosted attr_accessor :response, HTTPResponse end Amusingly, this added #response, #response=, #HTTPReponse and #HTTPResponse= So first of all, I'm fascinated by how facets snagged the name of the bogus constant I passed, but more significantly, I wish it had noticed that what I meant to do was annotate :response with a class, and had left off the module namespace. I'm architecturally uncertain as to whether that catch belongs in Facets or in Og, or I'd submit a patch. (On that note, George: I'm assuming that the repo is still unstable and I should put off patch work until it's stable again?) Judson From nyarly at gmail.com Thu Feb 8 19:40:19 2007 From: nyarly at gmail.com (nyarly at gmail.com) Date: Fri, 09 Feb 2007 00:40:19 -0000 Subject: [Nitro] Is there a reason I shouldn't want to do this? Message-ID: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> class Target attr_accessor :thing, String def initialize(t); thing=t; end end class SubTarget < Target attr_accessor :another_thing, String def initialize(t, a_t); super(t); another_thing = a_t; end end class Owner has_many :targets, Target end o = Owner.new o.add_target(SubTarget.new("one", "two")) At present, this creates three tables, with a foreign key from og_target to og_owner, and the SubTarget gets lost because the select is against the og_target table. Is there a philosophy here that I'm not understanding? From transfire at gmail.com Thu Feb 8 21:45:42 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 09 Feb 2007 02:45:42 -0000 Subject: [Nitro] Error handling in ann_attr In-Reply-To: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> References: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> Message-ID: <1170989142.727154.130930@m58g2000cwm.googlegroups.com> On Feb 8, 6:28 pm, "nya... at gmail.com" wrote: > As a quickie: here's my buggy code: > > class Hosted > attr_accessor :response, HTTPResponse > end > > Amusingly, this added #response, #response=, #HTTPReponse and > #HTTPResponse= > > So first of all, I'm fascinated by how facets snagged the name of the > bogus constant I passed, but more significantly, I wish it had noticed > that what I meant to do was annotate :response with a class, and had > left off the module namespace. > > I'm architecturally uncertain as to whether that catch belongs in > Facets or in Og, or I'd submit a patch. > > (On that note, George: I'm assuming that the repo is still unstable > and I should put off patch work until it's stable again?) Appearently Og is still using that old missing_constant return symbol trick! The idea is that it allows you to define a model prior to the actual constant being defined. Clever, but as you have now discovered this is TOO magical and no longer even works with the new implementation of annotated attrs. If there is the chance that the constant will not be defined before your model needs it then use the equivalent full spec: attr_accessor :response, :class => :HTTPResponse That should work (if not it's a bug that needs to be fixed). T. From nyarly at gmail.com Fri Feb 9 03:30:18 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 00:30:18 -0800 Subject: [Nitro] Error handling in ann_attr In-Reply-To: <1170989142.727154.130930@m58g2000cwm.googlegroups.com> References: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> <1170989142.727154.130930@m58g2000cwm.googlegroups.com> Message-ID: <8905c87a0702090030h35206f4ey8e85231072528c59@mail.gmail.com> On 2/8/07, transfire at gmail.com wrote: > Appearently Og is still using that old missing_constant return symbol > trick! The idea is that it allows you to define a model prior to the > actual constant being defined. Clever, but as you have now discovered > this is TOO magical and no longer even works with the new > implementation of annotated attrs. If there is the chance that the > constant will not be defined before your model needs it then use the > equivalent full spec: > > attr_accessor :response, :class => :HTTPResponse > > That should work (if not it's a bug that needs to be fixed). It is a bug that needs to be fixed: should have been Net::HTTPResponse. I do like the ability to omit the "class ComingSoon; end" malarkey, but I wonder if there isn't a way to guarantee that those missing constants actually become classes eventually. From george.moschovitis at gmail.com Fri Feb 9 03:32:17 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 10:32:17 +0200 Subject: [Nitro] Error handling in ann_attr In-Reply-To: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> References: <1170977290.210642.134890@a75g2000cwd.googlegroups.com> Message-ID: > > > (On that note, George: I'm assuming that the repo is still unstable > and I should put off patch work until it's stable again?) > I am updating the repo so that you can have an uptodate repo to send me patches. I am working mostly with Nitro at the moment, so please feel free to send your Og patches. thanks, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/d7a9ebed/attachment.html From george.moschovitis at gmail.com Fri Feb 9 03:34:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 10:34:37 +0200 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> Message-ID: You should propbably be using single table inheritance. Have a look at tc_sti.rb, tc_inheritance.rb etc for more details. However, at the moment sti seems to be buggy (after the latest Og changes). I will have a look at this tomorrow or something. regards, George. On 2/9/07, nyarly at gmail.com wrote: > > class Target > attr_accessor :thing, String > def initialize(t); thing=t; end > end > > class SubTarget < Target > attr_accessor :another_thing, String > def initialize(t, a_t); super(t); another_thing = a_t; end > end > > class Owner > has_many :targets, Target > end > > o = Owner.new > o.add_target(SubTarget.new("one", "two")) > > At present, this creates three tables, with a foreign key from > og_target to og_owner, and the SubTarget gets lost because the select > is against the og_target table. > > Is there a philosophy here that I'm not understanding? > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/40242bb5/attachment.html From john at oxyliquit.de Fri Feb 9 04:08:21 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 09 Feb 2007 10:08:21 +0100 Subject: [Nitro] Example Comments In-Reply-To: <8905c87a0702081425k5f244726o9746c2d8db63f040@mail.gmail.com> References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> <8905c87a0702081425k5f244726o9746c2d8db63f040@mail.gmail.com> Message-ID: Hi, >> > I very rarely see =begin =end in Ruby code. If, then mostly to >> > encapsulate a bigger chunk of code which is not to be executed. >> > > On the other hand, one of my favorite tricks is > > #=begin > > ... experimental code here ... > > =begin > =end which in no way contradics what I have been saying. ;) But yeah.. I haven't thought of that, I always commented both.... It's kinda like `#if 0 #endif` in C that way.. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Fri Feb 9 04:19:17 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 09 Feb 2007 10:19:17 +0100 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> Message-ID: Hi, > At present, this creates three tables, with a foreign key from > og_target to og_owner, and the SubTarget gets lost because the select > is against the og_target table. > > Is there a philosophy here that I'm not understanding? well, yeah, like G already said: You probably want STI in this case. The philosophy here being the underlying database. Because it creates 3 tables, it can't associate Owner with SubTarget with the same foreign key. class Target is Og::SchemaInheritanceBase attr_accessor :thing, String end With this your example will only create 2 tables and the foreign key will be valid for both classes. STI is always in a kind of flux though. But generally it works well when not doing anything too fancy. Hope that helped, Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From nyarly at gmail.com Fri Feb 9 13:16:01 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 10:16:01 -0800 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> Message-ID: <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> Aha! That's what STI means! On 2/9/07, George Moschovitis wrote: > You should propbably be using single table inheritance. Have a look at > tc_sti.rb, tc_inheritance.rb etc for more details. > However, at the moment sti seems to be buggy (after the latest Og changes). > I will have a look at this tomorrow or something. You're right: tc_inheritance.rb fails (I can't find tc_sti...). It's certainly worth it to me to hunt down the issue and submit a patch. Judson From nyarly at gmail.com Fri Feb 9 13:18:43 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 10:18:43 -0800 Subject: [Nitro] Example Comments In-Reply-To: References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> <8905c87a0702081425k5f244726o9746c2d8db63f040@mail.gmail.com> Message-ID: <8905c87a0702091018r5cb5f737r289472c86d293ffa@mail.gmail.com> > > On the other hand, one of my favorite tricks is > > > > #=begin > > > > ... experimental code here ... > > > > =begin > > =end > > which in no way contradics what I have been saying. ;) > Didn't say that it did. Just sharing, and justifying =begin =end style comments. > But yeah.. I haven't thought of that, I always commented both.... > It's kinda like `#if 0 #endif` in C that way.. Yeah, and I can't really say that it's better than if 0; end; in Ruby. Except maybe rcov doesn't count comments against executable code. Judson From nyarly at gmail.com Fri Feb 9 13:30:06 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 10:30:06 -0800 Subject: [Nitro] Annotation, validation Message-ID: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Again, an architectural question. Is there a reason that: class AnEntity attr_accessor :thing, String, :unique => true end doesn't imply class AnEntity attr_accessor :thing, String validate_unique :thing end and vice versa? I can see, possibly, not wanting to create validators and add overhead when you're expecting the backing store to accomplish that, but I guess that's the broader issue: couldn't the store adaptor determine whether validate_unique should generate a validator or add a UNIQUE constraint, or it's equivalent? Judson From transfire at gmail.com Fri Feb 9 14:08:42 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 09 Feb 2007 19:08:42 -0000 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake Message-ID: <1171048122.422397.219480@s48g2000cws.googlegroups.com> Hi-- I've released three ratchets' project today. projectinfo ========== This is the ProjectInfo class (which was born from reap) it's doesn't do anything on it's own. It's a support library for providing encapsulation of project information --it's quite extensive however, and somewhat unique in functionality. Also it can load up from a YAML configuration simply by ProjectInfo.load As long as your somewhere down in your project directory this will find it and load it up. (FYI, for the moment you have to create ProjectInfo files by hand. To make it easier just copy the one from projectinfo itself and edit to suit your needs.) exacto ====== This is a independent tool for extracting code from comments. Presently is only support =begin {handle}...=end comments, though I plan to make it more capable in the future. handle defaults to "test", which makes it a cinch to run embedded tests. Use it like this: $ exacto myfile.rb | ruby It also incudes a shortcut for the above called 'exrb' $ exrb myfile.rb autorake ======== This is main part of rathcets i've been working on. i decided to scale back a little and use rake as the task execution system (in the future I may split out the internal Project class (as reap?) that does all the work, but there sill some details to address with that). if you used reap in the past then you essentially know how to use autorake except it's more polished now. quick example: ~/ruby/autorake$ rake -T (in /file/trans/my/code/ruby/ratchets/src/autorake) AutoRake 0.4 beta rake announce # Make a release announcement rake changelog # Produce changelog (None) rake check # Rundown checklist rake diff # Verify the manifest rake install # Local setup & install rake loads # Test loadpath dependencies rake manifest # Generate package manifest rake notes # Compile developer notes rake pack # Build all packages rake prepare # Full preperations cycle rake publish # Publish website (Rubyforge) rake rdocs # Generate local rdocs rake release # Release packages (Rubyforge) rake ridocs # Generate local ri docs rake stats # Code count analysis rake syntax # Run syntax check rake test # Run isolated unit test rake tests # Extract embedded tests rake version # Calculate version (None) All you need is a ProjectInfo file in you project's root dir, and a Rakefile that starts with: require 'autorake' Couple of quick notes b/c I haven't done docs yet. The (None) you see means there is no SCM being used. If I were using Darcs for the AutoRake project it would say (Darcs) and could generate a version stamp and a changelog automatically via 'darcs' (file names default to VERSION and CHANGES). Subversion is not yet supported but that's next on the todo list (would any would like to make the adapter? :-) rdocs and ridocs, by default are stored in doc/rdoc and doc/ri, respectively. notes generate TODO and FIXME files in doc/ as well. The check task runs diff, syntax, loads and test, in that order; prepare runs changelog, version, manifest and then pack. Currently I'm using Rake's packaging system which is a little messy (IMHO) but it works well enough. Also, at the moment, only Rubyforge publishing and releasing is supported. On the todo list are generic versions of each. The only other major things it doesn't yet support is clean/clobber. This isn't a problem for pure ruby projects b/c internally it uses an "ignore" configuration parameter to only include the appropriate files in the manifest and the package. but clean/clobber is on the todo list. Being initial public releases of course there will arise some issue, please let me know what you encounter so I can fix asap. Note these have only been tested on Linux. Also, always good advice: be safe and backup up your projects from time to time. T. P.S. Facets is of course is required ;-) From transfire at gmail.com Fri Feb 9 14:18:13 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 09 Feb 2007 19:18:13 -0000 Subject: [Nitro] Ratchets and gen Message-ID: <1171048693.181582.220160@h3g2000cwc.googlegroups.com> Hi-- I noticed gen is no longer in the nitro repository. has that project been put on the back burner? i was thinking, i have code for what was once called 'seed' (originally from the reap project). i would like to take this and create a new imporved gen out of it that can accomodate regular ruby projects, generic plugins, nitro projects, nitro parts (tied to loxparts --btw why "lox"?), and any other project structure via easy to use plugin/component system. What do you think? T. From george.moschovitis at gmail.com Fri Feb 9 15:04:59 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 22:04:59 +0200 Subject: [Nitro] Ratchets and gen In-Reply-To: <1171048693.181582.220160@h3g2000cwc.googlegroups.com> References: <1171048693.181582.220160@h3g2000cwc.googlegroups.com> Message-ID: Yeap I have removed gen (glue will hopefully follow). You can use the name if you want, but I would suggest that you wait a week or two. I will finalize some ideas on nitro parts / plugins etc. thanks, -g. On 2/9/07, transfire at gmail.com wrote: > > Hi-- > > I noticed gen is no longer in the nitro repository. has that project > been put on the back burner? i was thinking, i have code for what was > once called 'seed' (originally from the reap project). i would like to > take this and create a new imporved gen out of it that can accomodate > regular ruby projects, generic plugins, nitro projects, nitro parts > (tied to loxparts --btw why "lox"?), and any other project structure > via easy to use plugin/component system. > > What do you think? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/d194a65e/attachment.html From george.moschovitis at gmail.com Fri Feb 9 15:06:00 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 22:06:00 +0200 Subject: [Nitro] Annotation, validation In-Reply-To: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Message-ID: This was on my todo list some time ago, I seem to have forgotten this. If you can provide a patch it would be nice ;-) -g. On 2/9/07, Judson Lester wrote: > > Again, an architectural question. > > Is there a reason that: > > class AnEntity > attr_accessor :thing, String, :unique => true > end > > doesn't imply > > class AnEntity > attr_accessor :thing, String > validate_unique :thing > end > > and vice versa? I can see, possibly, not wanting to create validators > and add overhead when you're expecting the backing store to accomplish > that, but I guess that's the broader issue: couldn't the store adaptor > determine whether validate_unique should generate a validator or add > a UNIQUE constraint, or it's equivalent? > > Judson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/59b6b58f/attachment.html From george.moschovitis at gmail.com Fri Feb 9 15:06:54 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 22:06:54 +0200 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> Message-ID: Ok If you will work on this I can use my time to fix some other parts. If you fail to fix this I will have a look. thanks, George. On 2/9/07, Judson Lester wrote: > > Aha! That's what STI means! > > On 2/9/07, George Moschovitis wrote: > > You should propbably be using single table inheritance. Have a look at > > tc_sti.rb, tc_inheritance.rb etc for more details. > > However, at the moment sti seems to be buggy (after the latest Og > changes). > > I will have a look at this tomorrow or something. > > You're right: tc_inheritance.rb fails (I can't find tc_sti...). It's > certainly worth it to me to hunt down the issue and submit a patch. > > Judson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/20522f33/attachment.html From george.moschovitis at gmail.com Fri Feb 9 15:08:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 9 Feb 2007 22:08:44 +0200 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: <1171048122.422397.219480@s48g2000cws.googlegroups.com> References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> Message-ID: Congrats Tom, and thanks for your great work. I am wondering if you could help the Nitro project and provide soem autorake files for Nitro and Og. Epscially this rake publish thing would be nice to have! regards, George. On 2/9/07, transfire at gmail.com wrote: > > Hi-- > > I've released three ratchets' project today. > > projectinfo > ========== > This is the ProjectInfo class (which was born from reap) it's doesn't > do anything on it's own. It's a support library for providing > encapsulation of project information --it's quite extensive however, > and somewhat unique in functionality. Also it can load up from a YAML > configuration simply by > > ProjectInfo.load > > As long as your somewhere down in your project directory this will > find it and load it up. (FYI, for the moment you have to create > ProjectInfo files by hand. To make it easier just copy the one from > projectinfo itself and edit to suit your needs.) > > exacto > ====== > This is a independent tool for extracting code from comments. > Presently is only support =begin {handle}...=end comments, though I > plan to make it more capable in the future. handle defaults to "test", > which makes it a cinch to run embedded tests. Use it like this: > > $ exacto myfile.rb | ruby > > It also incudes a shortcut for the above called 'exrb' > > $ exrb myfile.rb > > autorake > ======== > This is main part of rathcets i've been working on. i decided to scale > back a little and use rake as the task execution system (in the future > I may split out the internal Project class (as reap?) that does all > the work, but there sill some details to address with that). if you > used reap in the past then you essentially know how to use autorake > except it's more polished now. quick example: > > ~/ruby/autorake$ rake -T > (in /file/trans/my/code/ruby/ratchets/src/autorake) > AutoRake 0.4 beta > rake announce # Make a release announcement > rake changelog # Produce changelog (None) > rake check # Rundown checklist > rake diff # Verify the manifest > rake install # Local setup & install > rake loads # Test loadpath dependencies > rake manifest # Generate package manifest > rake notes # Compile developer notes > rake pack # Build all packages > rake prepare # Full preperations cycle > rake publish # Publish website (Rubyforge) > rake rdocs # Generate local rdocs > rake release # Release packages (Rubyforge) > rake ridocs # Generate local ri docs > rake stats # Code count analysis > rake syntax # Run syntax check > rake test # Run isolated unit test > rake tests # Extract embedded tests > rake version # Calculate version (None) > > All you need is a ProjectInfo file in you project's root dir, and a > Rakefile that starts with: > > require 'autorake' > > Couple of quick notes b/c I haven't done docs yet. The (None) you see > means there is no SCM being used. If I were using Darcs for the > AutoRake project it would say (Darcs) and could generate a version > stamp and a changelog automatically via 'darcs' (file names default to > VERSION and CHANGES). Subversion is not yet supported but that's next > on the todo list (would any would like to make the adapter? :-) rdocs > and ridocs, by default are stored in doc/rdoc and doc/ri, > respectively. notes generate TODO and FIXME files in doc/ as well. The > check task runs diff, syntax, loads and test, in that order; prepare > runs changelog, version, manifest and then pack. Currently I'm using > Rake's packaging system which is a little messy (IMHO) but it works > well enough. Also, at the moment, only Rubyforge publishing and > releasing is supported. On the todo list are generic versions of each. > The only other major things it doesn't yet support is clean/clobber. > This isn't a problem for pure ruby projects b/c internally it uses an > "ignore" configuration parameter to only include the appropriate files > in the manifest and the package. but clean/clobber is on the todo > list. > > Being initial public releases of course there will arise some issue, > please let me know what you encounter so I can fix asap. Note these > have only been tested on Linux. Also, always good advice: be safe and > backup up your projects from time to time. > > T. > > P.S. Facets is of course is required ;-) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070209/bf5e0dbe/attachment-0001.html From nyarly at gmail.com Fri Feb 9 17:51:12 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 14:51:12 -0800 Subject: [Nitro] Annotation, validation In-Reply-To: References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Message-ID: <8905c87a0702091451p13b71858p14c462d50faa006a@mail.gmail.com> On 2/9/07, George Moschovitis wrote: > This was on my todo list some time ago, I seem to have forgotten this. If > you can provide a patch it would be nice ;-) > Cool. I just didn't want to go charging in if there was a reason not to. It seems that the tricky part is that what really wants to happen is for Validations and Stores to interact, so that if the backing store can provide validation, the Validation defers, but otherwise the Validation does the work... Judson From nyarly at gmail.com Fri Feb 9 17:51:49 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 14:51:49 -0800 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> Message-ID: <8905c87a0702091451q349bcbb1y422befadd61e9bde@mail.gmail.com> On 2/9/07, George Moschovitis wrote: > Ok If you will work on this I can use my time to fix some other parts. If > you fail to fix this I will have a look. On the track of a bug now, actually. From nyarly at gmail.com Fri Feb 9 18:37:48 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 9 Feb 2007 15:37:48 -0800 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: <8905c87a0702091451q349bcbb1y422befadd61e9bde@mail.gmail.com> References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> <8905c87a0702091451q349bcbb1y422befadd61e9bde@mail.gmail.com> Message-ID: <8905c87a0702091537v23c47c50u906c5954e79e1a55@mail.gmail.com> On 2/9/07, Judson Lester wrote: > On 2/9/07, George Moschovitis wrote: > > Ok If you will work on this I can use my time to fix some other parts. If > > you fail to fix this I will have a look. > > On the track of a bug now, actually. > And it's a patch. Actually, this also includes a patch for a bug I found that probably results from the eval refactors I was doing. nil "other" values were being output as "", but "" wasn't being converted back to nil. -------------- next part -------------- A non-text attachment was scrubbed... Name: sti-fixes.patch Type: text/x-patch Size: 34212 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070209/3e9e9fdf/attachment-0001.bin From george.moschovitis at gmail.com Sat Feb 10 04:09:50 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 10 Feb 2007 11:09:50 +0200 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: <8905c87a0702091537v23c47c50u906c5954e79e1a55@mail.gmail.com> References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> <8905c87a0702091451q349bcbb1y422befadd61e9bde@mail.gmail.com> <8905c87a0702091537v23c47c50u906c5954e79e1a55@mail.gmail.com> Message-ID: Thanks, I will try this... -g. On 2/10/07, Judson Lester wrote: > > On 2/9/07, Judson Lester wrote: > > On 2/9/07, George Moschovitis wrote: > > > Ok If you will work on this I can use my time to fix some other parts. > If > > > you fail to fix this I will have a look. > > > > On the track of a bug now, actually. > > > > And it's a patch. > > Actually, this also includes a patch for a bug I found that probably > results from the eval refactors I was doing. nil "other" values were > being output as "", but "" wasn't being converted back to nil. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070210/28d1ddb1/attachment.html From george.moschovitis at gmail.com Sat Feb 10 04:11:15 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 10 Feb 2007 11:11:15 +0200 Subject: [Nitro] Is there a reason I shouldn't want to do this? In-Reply-To: References: <1170981619.041658.191340@j27g2000cwj.googlegroups.com> <8905c87a0702091016g4a5490d8r7004e301f7fdd403@mail.gmail.com> <8905c87a0702091451q349bcbb1y422befadd61e9bde@mail.gmail.com> <8905c87a0702091537v23c47c50u906c5954e79e1a55@mail.gmail.com> Message-ID: Please, can you resubmit this against the *latest* repo? thanks, George. On 2/10/07, George Moschovitis wrote: > > Thanks, I will try this... > > -g. > > On 2/10/07, Judson Lester wrote: > > > On 2/9/07, Judson Lester wrote: > > > On 2/9/07, George Moschovitis wrote: > > > > Ok If you will work on this I can use my time to fix some other > > parts. If > > > > you fail to fix this I will have a look. > > > > > > On the track of a bug now, actually. > > > > > > > And it's a patch. > > > > Actually, this also includes a patch for a bug I found that probably > > results from the eval refactors I was doing. nil "other" values were > > being output as "", but "" wasn't being converted back to nil. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070210/c5fc5e1d/attachment.html From fabian at fabian-buch.de Sat Feb 10 04:43:03 2007 From: fabian at fabian-buch.de (Fabian Buch) Date: Sat, 10 Feb 2007 10:43:03 +0100 Subject: [Nitro] Ratchets and gen In-Reply-To: <1171048693.181582.220160@h3g2000cwc.googlegroups.com> References: <1171048693.181582.220160@h3g2000cwc.googlegroups.com> Message-ID: <4B44912E-D9A7-41C4-BA8B-1B2AD4D57626@fabian-buch.de> Am 09.02.2007 um 20:18 schrieb transfire at gmail.com: > regular ruby projects, generic plugins, nitro projects, nitro parts > (tied to loxparts --btw why "lox"?), and any other project structure All Nitro stuff has to do with explosives: Nitro, Glycerin, Oxyliquit, and Lox (liquid oxygen) was used in making oxyliquit explosives in the past. back to studying.. Fabian -- Nitro Q&A: http://oxyliquit.de LoxParts: http://loxparts.de Blog: http://blog.fabian-buch.de From john at oxyliquit.de Sat Feb 10 04:47:43 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 10 Feb 2007 10:47:43 +0100 Subject: [Nitro] Annotation, validation In-Reply-To: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Message-ID: Hi, > and vice versa? I can see, possibly, not wanting to create validators > and add overhead when you're expecting the backing store to accomplish > that, but I guess that's the broader issue: couldn't the store adaptor > determine whether validate_unique should generate a validator or add a > UNIQUE constraint, or it's equivalent? this could be done, but as you said, it would create overhead. For a uniqe check, one database roundtrip is required. Depending on how fast you insert data this will kill performance. I vote for making this 'auto validator generator' despite this. But, we have to provide a way to go around the validators then. I don't remember exactly if .save! will do this... Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Feb 10 04:56:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 10 Feb 2007 10:56:28 +0100 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> Message-ID: Hi, > and thanks for your great work. I am wondering if you could help the Nitro > project and provide soem autorake files for Nitro and Og. Epscially this > rake publish thing would be nice to have! oh yes yes, a Rakefile, to also let these tests run on Firebrigade: http://firebrigade.seattlerb.org/build/show/12012 This I guess only looks that way, because it doesn't know how to run our tests. With a Rakefile that won't be a problem anymore. Only thing with Rake tests is, that it runs them in a single 'run', where some tests interfere with one another. A while back I minimized those interferances, but I think some are still there. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Feb 10 05:06:57 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 10 Feb 2007 11:06:57 +0100 Subject: [Nitro] Example Comments In-Reply-To: <8905c87a0702091018r5cb5f737r289472c86d293ffa@mail.gmail.com> References: <1170928311.449051.264160@p10g2000cwp.googlegroups.com> <000d01c74ba0$c796d530$0301a8c0@ghostgum> <8905c87a0702081425k5f244726o9746c2d8db63f040@mail.gmail.com> <8905c87a0702091018r5cb5f737r289472c86d293ffa@mail.gmail.com> Message-ID: Hi, >> which in no way contradics what I have been saying. ;) >> > Didn't say that it did. Just sharing, and justifying =begin =end > style comments. Which is why there's a winking smiley at the end. :P And yeah, thanks for sharing. :P >> But yeah.. I haven't thought of that, I always commented both.... >> It's kinda like `#if 0 #endif` in C that way.. > > Yeah, and I can't really say that it's better than if 0; end; in Ruby. > Except maybe rcov doesn't count comments against executable code. Well yes, like with the C PP #if version, it doesn't impose a runtime cost. So it's a little better I'd guess. (and, it doesn't need to be 'well formed' like normal C/Ruby code, which is a plus sometimes) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Feb 10 05:28:06 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 10 Feb 2007 12:28:06 +0200 Subject: [Nitro] Annotation, validation In-Reply-To: References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Message-ID: > > remember exactly if .save! will do this... > force_save! will do the trick ;-) -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070210/7142ee6b/attachment.html From transfire at gmail.com Sat Feb 10 09:38:12 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 10 Feb 2007 14:38:12 -0000 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> Message-ID: <1171118292.024681.208720@m58g2000cwm.googlegroups.com> On Feb 10, 4:56 am, "Jonathan Buch" wrote: > Hi, > > > and thanks for your great work. I am wondering if you could help the Nitro > > project and provide soem autorake files for Nitro and Og. Epscially this > > rake publish thing would be nice to have! > > oh yes yes, a Rakefile, to also let these tests run on Firebrigade: > > http://firebrigade.seattlerb.org/build/show/12012 > > This I guess only looks that way, because it doesn't know how to run our > tests. With a Rakefile that won't be a problem anymore. > > Only thing with Rake tests is, that it runs them in a single 'run', where > some tests interfere with one another. A while back I minimized those > interferances, but I think some are still there. If Firebrigade can run the test task as defined by our Rakefile that won't be a problem. autorake's test task runs each test as a separate proccess. (You see, I've had this problem before too ;-) T. From transfire at gmail.com Sat Feb 10 10:21:05 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 10 Feb 2007 15:21:05 -0000 Subject: [Nitro] render.rb stange methods Message-ID: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> In render.rb, I did def render p self.class.methods.sort ... I was suprised to see these two entries at the top of this list: "Glue", "ORMSupport" How are they methods!? I discovered this b/c I'm getting an error undefined method `mount_path' for Nitro::Context:Class for the first line of render: path = "#{self.class.mount_path}/#{path}".squeeze('/') unless path =~ /^\// Any ideas? T. From george.moschovitis at gmail.com Sat Feb 10 10:37:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 10 Feb 2007 17:37:57 +0200 Subject: [Nitro] render.rb stange methods In-Reply-To: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> Message-ID: > > > I was suprised to see these two entries at the top of this list: > > "Glue", "ORMSupport" > > How are they methods!? no idea... very strange indeed... I discovered this b/c I'm getting an error > > undefined method `mount_path' for Nitro::Context:Class > > for the first line of render: > > path = "#{self.class.mount_path}/#{path}".squeeze('/') unless path > =~ /^\// self.class should be a controller not a context. how are you calling render() ? -g. Any ideas? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070210/459ef57f/attachment.html From transfire at gmail.com Sat Feb 10 15:41:14 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 10 Feb 2007 20:41:14 -0000 Subject: [Nitro] render.rb stange methods In-Reply-To: References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> Message-ID: <1171140074.591881.41820@m58g2000cwm.googlegroups.com> On Feb 10, 10:37 am, "George Moschovitis" wrote: > > I was suprised to see these two entries at the top of this list: > > > "Glue", "ORMSupport" > > > How are they methods!? > > no idea... very strange indeed... > > I discovered this b/c I'm getting an error > > > > > undefined method `mount_path' for Nitro::Context:Class > > > for the first line of render: > > > path = "#{self.class.mount_path}/#{path}".squeeze('/') unless path > > =~ /^\// > > self.class should be a controller not a context. how are you calling > render() ? via #build -- I've been working on implementing the Facets builder. def index build do h1 "Hello World" build_form( :object=> mymodel ) end end the build_form method routes to FormBuilder#form which it gets by including FormHelper. I'm wondering if the fact that the new builder uses instance_eval(&builder_block) is going to be a problem? T. From george.moschovitis at gmail.com Sat Feb 10 16:18:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 10 Feb 2007 23:18:27 +0200 Subject: [Nitro] render.rb stange methods In-Reply-To: <1171140074.591881.41820@m58g2000cwm.googlegroups.com> References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> Message-ID: please, show me the build_form method source code. -g. On 2/10/07, transfire at gmail.com wrote: > > > > On Feb 10, 10:37 am, "George Moschovitis" > wrote: > > > I was suprised to see these two entries at the top of this list: > > > > > "Glue", "ORMSupport" > > > > > How are they methods!? > > > > no idea... very strange indeed... > > > > I discovered this b/c I'm getting an error > > > > > > > > > undefined method `mount_path' for Nitro::Context:Class > > > > > for the first line of render: > > > > > path = "#{self.class.mount_path}/#{path}".squeeze('/') unless path > > > =~ /^\// > > > > self.class should be a controller not a context. how are you calling > > render() ? > > via #build -- I've been working on implementing the Facets builder. > > def index > build do > h1 "Hello World" > build_form( :object=> mymodel ) > end > end > > the build_form method routes to FormBuilder#form which it gets by > including FormHelper. > > I'm wondering if the fact that the new builder uses > instance_eval(&builder_block) is going to be a problem? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070210/5b3fa706/attachment.html From transfire at gmail.com Sun Feb 11 16:21:58 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 11 Feb 2007 21:21:58 -0000 Subject: [Nitro] render.rb stange methods In-Reply-To: References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> Message-ID: <1171228918.794511.208130@a34g2000cwb.googlegroups.com> On Feb 10, 4:18 pm, "George Moschovitis" wrote: > please, show me the build_form method source code. okay. well, it's little complicated since I'm using facets builder (with one midification since 1.8.20) and had to change some of nitro to use it. but i'll see what i can do. in the mean time i'll see if I can't get any more clues. one question about the builder. compared to _why's markaby lib there is a difference between the two. markaby imports the helper module verbatium -- ie. it's methods are callable without any special convention. For example say we're using this helper: module AHelper extend self def foo; "FOO!"; end end With markaby we might have: builder.html { h1 "hello" foo } to do the same with Facets, it prefixes the methods by build_: builder.html { h1 "hello" build_foo } The basic reason why being that markaby only allows standard html tags. If you try to insert an arbitrary tag you will get an error. To get around this you have to use the tag! method. Facets' on the other hand allows any tag whatsoever (minus a handful of special keywords), so to avoid name clashes I use a prefix. Which way is better? Should I get rid of the prefix? And still allow the arbitrary tags? in a way i would like to but take nitro's FormHelper which defines a form method --that's going to clash with creating an ordinary form tag. does it matter --maybe the helper method should hacve a more specidic name like entity_form? i was wondering also. might it just be better to use _why's Markaby lib? since it's not really the typical usage, markaby could just be optional it's no biggy to me either way really, facets' building code is capable enough i believe, and is pretty much the same as markaby in functionality, but it is sort of reinventing the wheel in most respects, so if this isn't going to get much use is it worth it? T. From george.moschovitis at gmail.com Mon Feb 12 04:06:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 11:06:23 +0200 Subject: [Nitro] render.rb stange methods In-Reply-To: <1171228918.794511.208130@a34g2000cwb.googlegroups.com> References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> <1171228918.794511.208130@a34g2000cwb.googlegroups.com> Message-ID: I would like to ger rid of the skip_ prefix. Lets keep the facets builder. -g. On 2/11/07, transfire at gmail.com wrote: > > > On Feb 10, 4:18 pm, "George Moschovitis" > wrote: > > please, show me the build_form method source code. > > okay. well, it's little complicated since I'm using facets builder > (with one midification since 1.8.20) and had to change some of nitro > to use it. but i'll see what i can do. in the mean time i'll see if I > can't get any more clues. > > one question about the builder. compared to _why's markaby lib there > is a difference between the two. markaby imports the helper module > verbatium -- ie. it's methods are callable without any special > convention. For example say we're using this helper: > > module AHelper > extend self > def foo; "FOO!"; end > end > > With markaby we might have: > > builder.html { > h1 "hello" > foo > } > > to do the same with Facets, it prefixes the methods by build_: > > builder.html { > h1 "hello" > build_foo > } > > The basic reason why being that markaby only allows standard html > tags. If you try to insert an arbitrary tag you will get an error. To > get around this you have to use the tag! method. Facets' on the other > hand allows any tag whatsoever (minus a handful of special keywords), > so to avoid name clashes I use a prefix. > > Which way is better? Should I get rid of the prefix? And still allow > the arbitrary tags? in a way i would like to but take nitro's > FormHelper which defines a form method --that's going to clash with > creating an ordinary form tag. does it matter --maybe the helper > method should hacve a more specidic name like entity_form? > > i was wondering also. might it just be better to use _why's Markaby > lib? since it's not really the typical usage, markaby could just be > optional it's no biggy to me either way really, facets' building code > is capable enough i believe, and is pretty much the same as markaby in > functionality, but it is sort of reinventing the wheel in most > respects, so if this isn't going to get much use is it worth it? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/d5a62eb5/attachment.html From george.moschovitis at gmail.com Mon Feb 12 04:59:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 11:59:26 +0200 Subject: [Nitro] render.rb stange methods In-Reply-To: References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> <1171228918.794511.208130@a34g2000cwb.googlegroups.com> Message-ID: Please note that I am changing Nitro considerably at the moment. But please finish with your work on the new builder I will integrate this. -g. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/7647f7c2/attachment.html From george.moschovitis at gmail.com Mon Feb 12 07:28:48 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 14:28:48 +0200 Subject: [Nitro] Atom Publishing Protocol Client Message-ID: Dear devs, does anyone know of a APP Client GUI or Web based? thanks in advance, -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/a301cc56/attachment-0001.html From transfire at gmail.com Mon Feb 12 10:42:17 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Mon, 12 Feb 2007 15:42:17 -0000 Subject: [Nitro] render.rb stange methods In-Reply-To: References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> <1171228918.794511.208130@a34g2000cwb.googlegroups.com> Message-ID: <1171294937.129694.28010@p10g2000cwp.googlegroups.com> On Feb 12, 4:06 am, "George Moschovitis" wrote: > I would like to ger rid of the skip_ prefix. Lets keep the facets builder. okay. will do. we'll need to change the names of some of the helper methods to avoid clashes with html tags, i'll just use whatever comes to mind at the moment and we can discuss what they should be later. ~t. From george.moschovitis at gmail.com Mon Feb 12 11:02:45 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 18:02:45 +0200 Subject: [Nitro] render.rb stange methods In-Reply-To: <1171294937.129694.28010@p10g2000cwp.googlegroups.com> References: <1171120865.254276.6760@k78g2000cwa.googlegroups.com> <1171140074.591881.41820@m58g2000cwm.googlegroups.com> <1171228918.794511.208130@a34g2000cwb.googlegroups.com> <1171294937.129694.28010@p10g2000cwp.googlegroups.com> Message-ID: ok, thanks... okay. will do. we'll need to change the names of some of the helper > methods to avoid clashes with html tags, i'll just use whatever comes > to mind at the moment and we can discuss what they should be later. > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/77cb4515/attachment.html From nyarly at gmail.com Mon Feb 12 13:36:03 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 12 Feb 2007 10:36:03 -0800 Subject: [Nitro] Annotation, validation In-Reply-To: References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> Message-ID: <8905c87a0702121036i3323219ew4e756197682bc522@mail.gmail.com> On 2/10/07, Jonathan Buch wrote: > Hi, > this could be done, but as you said, it would create overhead. For a > uniqe check, one database roundtrip is required. Depending on how fast > you insert data this will kill performance. > > I vote for making this 'auto validator generator' despite this. Maybe a setting for Og along the lines of "validation_at_store" or something is in order before changing behavior then? From nyarly at gmail.com Mon Feb 12 15:11:30 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 12 Feb 2007 12:11:30 -0800 Subject: [Nitro] Darcs troubles Message-ID: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> I'm an admitted novice with Darcs. Right now, I feel clumsy with it, and more importantly, patches I submit using it can't be applied. Can anyone suggest what I'm doing wrong? Very likely I'm still in the realm of common gotchas. Twice now I've finished doing some edits, done a darcs record, a pull, resolved some conflicts, recorded, and then a send. The resulting bundle won't apply. I think one of them might? But I think my first bundle hung George's darcs when he tried to apply it, and the main repo hung my darcs when I tried to pull. (I since believe that had to do with working under a soft link into my local repo - which isn't thrilling behavior.) Is this a symptom of something? What am I doing wrong? On a related note, can I tell darcs to use an external merger? I find the default behavior of clobbering source files mostly just confusing. Judson From george.moschovitis at gmail.com Mon Feb 12 15:21:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 22:21:57 +0200 Subject: [Nitro] Elements Message-ID: Dear devs, Is anyone using Element template files? I would like to temporarily remove this functionality while I cleanup elements. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/7f99e37d/attachment.html From george.moschovitis at gmail.com Mon Feb 12 15:35:47 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 12 Feb 2007 22:35:47 +0200 Subject: [Nitro] Webrick log Message-ID: Dear devs, anyone knows how I can get rit of the following Webrick log crap? [2007-02-12 22:34:34] INFO WEBrick 1.3.1 [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 port=9000 thanks, -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070212/8f37d340/attachment.html From lasso at lassoweb.se Mon Feb 12 16:49:16 2007 From: lasso at lassoweb.se (Lars Olsson) Date: Mon, 12 Feb 2007 22:49:16 +0100 Subject: [Nitro] Webrick log In-Reply-To: References: Message-ID: <45D0E0DC.6060606@lassoweb.se> Hi, It's hardcoded: lib/ruby/1.8/webrick/server.rb, line 53-56 webrickv = WEBrick::VERSION rubyv = "#{RUBY_VERSION} (#{RUBY_RELEASE_DATE}) [#{RUBY_PLATFORM}]" @logger.info("WEBrick #{webrickv}") @logger.info("ruby #{rubyv}") so I think you got to hack webrick to make the log message disappear... Kindly /lasso George Moschovitis skrev: > Dear devs, > > anyone knows how I can get rit of the following Webrick log crap? > > [2007-02-12 22:34:34] INFO WEBrick 1.3.1 > [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] > [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 port=9000 > > > thanks, > -g. > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From wyhaines at gmail.com Mon Feb 12 17:08:59 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 12 Feb 2007 15:08:59 -0700 Subject: [Nitro] Webrick log In-Reply-To: References: Message-ID: On 2/12/07, George Moschovitis wrote: > anyone knows how I can get rit of the following Webrick log crap? > > [2007-02-12 22:34:34] INFO WEBrick 1.3.1 > [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] > [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 port=9000 Webrick lets you control the logging destination. When you create the webrick server instance, pass it a couple of parameters, :Logger and :AccessLog that provide an alternative destination for the webrick logging. @server = Iowa::WEBrick::HTTPServer.new( :Port => @config[Csocket][Cport], :BindAddress => @config[Csocket][Chostname], :DocumentRoot => Iowa.app.class.docroot, :Logger => swallow_logs, :AccessLog => swallow_logs, :CGIInterpreter => ruby) That's how my webrick handler does it. swallow_logs is an instance of a "logger" that does nothing but eat whatever it is fed. Kirk Haines From wyhaines at gmail.com Mon Feb 12 17:09:46 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Mon, 12 Feb 2007 15:09:46 -0700 Subject: [Nitro] Webrick log In-Reply-To: References: Message-ID: On 2/12/07, George Moschovitis wrote: > Dear devs, > > anyone knows how I can get rit of the following Webrick log crap? > > [2007-02-12 22:34:34] INFO WEBrick 1.3.1 > [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] > [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 port=9000 BTW, this has been discussed on ruby-talk before, so you can probably lookup much more detailed information in the archives. Kirk From george.moschovitis at gmail.com Mon Feb 12 17:19:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 00:19:36 +0200 Subject: [Nitro] Webrick log In-Reply-To: <45D0E0DC.6060606@lassoweb.se> References: <45D0E0DC.6060606@lassoweb.se> Message-ID: !#@@!#@!#@!C! !!! argh, -g. On 2/12/07, Lars Olsson wrote: > > Hi, > > It's hardcoded: > > lib/ruby/1.8/webrick/server.rb, line 53-56 > webrickv = WEBrick::VERSION > rubyv = "#{RUBY_VERSION} (#{RUBY_RELEASE_DATE}) [#{RUBY_PLATFORM}]" > @logger.info("WEBrick #{webrickv}") > @logger.info("ruby #{rubyv}") > > so I think you got to hack webrick to make the log message disappear... > > > Kindly > > /lasso > > > > George Moschovitis skrev: > > Dear devs, > > > > anyone knows how I can get rit of the following Webrick log crap? > > > > [2007-02-12 22:34:34] INFO WEBrick 1.3.1 > > [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] > > [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 > port=9000 > > > > > > thanks, > > -g. > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/f316dc17/attachment-0001.html From george.moschovitis at gmail.com Mon Feb 12 17:31:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 00:31:58 +0200 Subject: [Nitro] Webrick log In-Reply-To: References: Message-ID: Aha, there is a :Logger parameter too, thanks! -g. On 2/13/07, Kirk Haines wrote: > > On 2/12/07, George Moschovitis wrote: > > > anyone knows how I can get rit of the following Webrick log crap? > > > > [2007-02-12 22:34:34] INFO WEBrick 1.3.1 > > [2007-02-12 22:34:34] INFO ruby 1.8.4 (2005-12-24) [i486-linux] > > [2007-02-12 22:34:34] INFO WEBrick::HTTPServer#start: pid=13118 > port=9000 > > Webrick lets you control the logging destination. > > When you create the webrick server instance, pass it a couple of > parameters, :Logger and :AccessLog that provide an alternative > destination for the webrick logging. > > @server = Iowa::WEBrick::HTTPServer.new( > :Port => @config[Csocket][Cport], > :BindAddress => @config[Csocket][Chostname], > :DocumentRoot => Iowa.app.class.docroot, > :Logger => swallow_logs, > :AccessLog => swallow_logs, > :CGIInterpreter => ruby) > > That's how my webrick handler does it. swallow_logs is an instance of > a "logger" that does nothing but eat whatever it is fed. > > > Kirk Haines > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/6764f224/attachment.html From john at oxyliquit.de Mon Feb 12 17:33:45 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 12 Feb 2007 23:33:45 +0100 Subject: [Nitro] Annotation, validation In-Reply-To: <8905c87a0702121036i3323219ew4e756197682bc522@mail.gmail.com> References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> <8905c87a0702121036i3323219ew4e756197682bc522@mail.gmail.com> Message-ID: On Mon, 12 Feb 2007 19:36:03 +0100, Judson Lester wrote: > On 2/10/07, Jonathan Buch wrote: >> Hi, >> this could be done, but as you said, it would create overhead. For a >> uniqe check, one database roundtrip is required. Depending on how fast >> you insert data this will kill performance. >> >> I vote for making this 'auto validator generator' despite this. > > Maybe a setting for Og along the lines of "validation_at_store" or > something is in order before changing behavior then? Yeah, I'd like it to be an option... But G is revamping whole Nitro atm, lets see how the configuration turns out. G: reminder to send me nitro overview scan, and please think of how to use Og with these new settings (if done at all if I understood you correctly). Yeah, config would be better, one can then switch it off when the system gets too slow witout changing a line of the implementation... Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Mon Feb 12 17:57:40 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 12 Feb 2007 23:57:40 +0100 Subject: [Nitro] Darcs troubles In-Reply-To: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> Message-ID: Hi, > I'm an admitted novice with Darcs. Right now, I feel clumsy with it, > and more importantly, patches I submit using it can't be applied. Can > anyone suggest what I'm doing wrong? Very likely I'm still in the > realm of common gotchas. > > Twice now I've finished doing some edits, done a darcs record, a pull, > resolved some conflicts, recorded, and then a send. The resulting > bundle won't apply. I think one of them might? But I think my first > bundle hung George's darcs when he tried to apply it, and the main > repo hung my darcs when I tried to pull. (I since believe that had to > do with working under a soft link into my local repo - which isn't > thrilling behavior.) > > Is this a symptom of something? What am I doing wrong? when we had a second dev repo (sponsored by manveru) we had similar problems. I wrote like hate-mail to G then about this and how the development in general is handled. Now we gave up and just push to G again, patch for patch. Reasons we found that a repo gets broken: * Same changes by different patches * file moves/removes/renames * 'splatter-patches' (many small changes in one or more files) * not merging often enough with 'head' (G's repo) * conflict-patches (making patches because a conflict appeared) * `darcs revert`'ing, going to 'original state' (throwing away local changes which made the conflict) when the repo state is inconsistent * making patches after such a revert + inconsistent repo * too many people working on a single repo * probably some waterlilly in south japan which got stomped by an egyptian camel There will be more such signes, the further the inconsistent state of the repo 'progresses' and soon after there will be, like, no clean patch anymore. Solution: * get clean repo from George * merge changes by hand (diff/patch, copy/paste) * make clean `darcs record` * send patch to G * repeat When only working alone on a repo, this cycle will not be needed all too often. It's just that darcs gets confused, and if it does, bad things start to happen. I have 2 main repos: 1. clean George repo 2. my dev repo * often pull G repo [1.] * darcs pull ../nitro-0.40-george (only get 'good' patches) [2.] * darcs record [2.] * darcs send -o patchfile ../nitro-0.40-george [2.] * wait for G to apply, repeat When George 'reworks' a patch (meaning, he uses your patch internally, but makes changes to it and releases a new patch with it), you can almost throw away your repo and make a clean one. You have to observe via source what you're pulling and how it affects code you touched. This sounds like stress? Maybe. Am I just ranting? Possibly. But this doesn't mean that I don't like darcs. I love it, it's imo the most 'comforting' system around... > On a related note, can I tell darcs to use an external merger? I find the > default behavior of clobbering source files mostly just confusing. No idea on that. You mean using an external merger when you do `darcs pull`? When pressing 'p' while pulling patches, you can look at the whole patch which is very useful. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Feb 12 18:13:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 01:13:56 +0200 Subject: [Nitro] Annotation, validation In-Reply-To: References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> <8905c87a0702121036i3323219ew4e756197682bc522@mail.gmail.com> Message-ID: I will probably push some stuff to the repo tomorrow. Be warned, this will break almost everything, but it will give the chance to anyone interested to comment on the latest changes and offer valuable suggestions. -g. On 2/13/07, Jonathan Buch wrote: > > On Mon, 12 Feb 2007 19:36:03 +0100, Judson Lester > wrote: > > > On 2/10/07, Jonathan Buch wrote: > >> Hi, > >> this could be done, but as you said, it would create overhead. For a > >> uniqe check, one database roundtrip is required. Depending on how fast > >> you insert data this will kill performance. > >> > >> I vote for making this 'auto validator generator' despite this. > > > > Maybe a setting for Og along the lines of "validation_at_store" or > > something is in order before changing behavior then? > > Yeah, I'd like it to be an option... But G is revamping whole Nitro atm, > lets see how the configuration turns out. > > G: reminder to send me nitro overview scan, and please think of how to > use Og with these new settings (if done at all if I understood you > correctly). > > Yeah, config would be better, one can then switch it off when the system > gets too slow witout changing a line of the implementation... > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/7bc621c9/attachment.html From george.moschovitis at gmail.com Mon Feb 12 18:15:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 01:15:23 +0200 Subject: [Nitro] Annotation, validation In-Reply-To: References: <8905c87a0702091030n64f61aeah21df1911e4f24dce@mail.gmail.com> <8905c87a0702121036i3323219ew4e756197682bc522@mail.gmail.com> Message-ID: Btw, I am not working on Og at the moment (other than applying some patches from Jud) so Og patches are accepted ;-) And I am expecting some builder-related patches from Tom. -g. I will probably push some stuff to the repo tomorrow. Be warned, this will > break almost everything, but it will give the chance to anyone interested to > comment on the latest changes and offer valuable suggestions. > > -g. > > On 2/13/07, Jonathan Buch wrote: > > > > On Mon, 12 Feb 2007 19:36:03 +0100, Judson Lester > > wrote: > > > > > On 2/10/07, Jonathan Buch wrote: > > >> Hi, > > >> this could be done, but as you said, it would create overhead. For a > > >> uniqe check, one database roundtrip is required. Depending on how > > fast > > >> you insert data this will kill performance. > > >> > > >> I vote for making this 'auto validator generator' despite this. > > > > > > Maybe a setting for Og along the lines of "validation_at_store" or > > > something is in order before changing behavior then? > > > > Yeah, I'd like it to be an option... But G is revamping whole Nitro > > atm, > > lets see how the configuration turns out. > > > > G: reminder to send me nitro overview scan, and please think of how to > > use Og with these new settings (if done at all if I understood you > > correctly). > > > > Yeah, config would be better, one can then switch it off when the system > > gets too slow witout changing a line of the implementation... > > > > Jo > > > > -- > > Feel the love > > http://pinkjuice.com/pics/ruby.png > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/4a95bff9/attachment.html From nyarly at gmail.com Mon Feb 12 19:39:29 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 12 Feb 2007 16:39:29 -0800 Subject: [Nitro] Darcs troubles In-Reply-To: References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> Message-ID: <8905c87a0702121639u54e3fc19sbeab0379c329f165@mail.gmail.com> First of all, thanks for the advice! On 2/12/07, Jonathan Buch wrote: > This sounds like stress? Maybe. Am I just ranting? Possibly. > > But this doesn't mean that I don't like darcs. I love it, it's imo the > most 'comforting' system around... Comforting how, exactly? Because the error messages are more casual? "You wrecked your repo, but that's fine with me!" ;P The thing I need most with Darcs right now is to see some good in it. Right now the only feature it gives me is bleeding edge Nitro + Og. What *is* good about Darcs? > > > On a related note, can I tell darcs to use an external merger? I find the > > default behavior of clobbering source files mostly just confusing. > > No idea on that. > > You mean using an external merger when you do `darcs pull`? When pressing 'p' > while pulling patches, you can look at the whole patch which is very useful. You do a darcs pull. Darcs responds "x, y, and z have conflicts." Rather than have darcs "helpfully" add text to a source file, can I get it to open up (ideally) meld or xxdiff or something, and let me see the differences side by side? And with the clear annotation that the left is old and the right is new (or local and remote, or whatever)? (And has anyone else used monotone?) Judson From transfire at gmail.com Mon Feb 12 20:41:49 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 13 Feb 2007 01:41:49 -0000 Subject: [Nitro] Darcs troubles In-Reply-To: References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> Message-ID: <1171330909.386985.67070@m58g2000cwm.googlegroups.com> On Feb 12, 5:57 pm, "Jonathan Buch" wrote: > * probably some waterlilly in south japan which got stomped by > an egyptian camel damn camels! :) > There will be more such signes, the further the inconsistent state > of the repo 'progresses' and soon after there will be, like, no > clean patch anymore. > > Solution: > > * get clean repo from George > * merge changes by hand (diff/patch, copy/paste) > * make clean `darcs record` > * send patch to G > * repeat > > When only working alone on a repo, this cycle will not be needed all too > often. It's just that darcs gets confused, and if it does, bad things > start to happen. > > I have 2 main repos: > > 1. clean George repo > 2. my dev repo > > * often pull G repo [1.] > * darcs pull ../nitro-0.40-george (only get 'good' patches) [2.] > * darcs record [2.] > * darcs send -o patchfile ../nitro-0.40-george [2.] > * wait for G to apply, repeat > > When George 'reworks' a patch (meaning, he uses your patch internally, but > makes changes to it and releases a new patch with it), you can almost throw > away your repo and make a clean one. You have to observe via source what > you're pulling and how it affects code you touched. > > This sounds like stress? Maybe. Am I just ranting? Possibly. > > But this doesn't mean that I don't like darcs. I love it, it's imo the > most 'comforting' system around... I have to admit that the SCM doesn't work too well for me. I'm not blaming Darcs per say --I had troubles with Subversion too when I tried it. I'm just not SCM mined I guess. But I think the whole distributed SCM may be over-hyped just a little. It would still be nice if we were all pushing back to a central repo, rather then passing patches to George. However --and a big however, Nitro/Og is still maturing and going through many changes and that thwarts coop development a great deal. That's okay, Nitro/Og needs it and I have a feeling this round of major changes will be essentially the last (yea! onward to 1.0!) Even so, I have a suggestion for correcting the problem and one that I am currently moving toward in my own projects. I think it's a very good idea to divide the system into smaller components. Each component having it's own darcs repo. That way it becomes easy to work on a particular component without stepping on others toes. Also, it makes one much more aware of when an interface changes vs.just changing internal functionality, b/c it will have an effect on other components or not. Nitro's already consists of two divisions: nitro and og. Splitting darcs along that division in itself would help but we can go further. Nitro's template systems could be their own microprojects, for instance. Even Og's adapters could each be there own microproject --just depends on how far we think is best to take it. It's more like thinking in terms of parts -- we develop individual parts that eventually come together to create the whole. Its a good way to develop, b/c it helps to get the SOCs right. This requires some working out details on how best to achieve it though. I've been thinking about that myself b/c i want to do it for Facets/More lib. Right now I have every lib in a single dir. facets/ ProjectInfo lib/ facets/ more/ ann.rb ann_attr.rb cut.rb ...etc... What I want to do is something like (maybe, maybe not keeping more/ dir): facets/ ProjectInfo ann/ lib/ facets/ ann.rb ann_attr.rb cut/ lib/ facets/ cut.rb That way, each more-part can have it's own versioning, plus docs, etc. It would be much better this way for may reasons, not the least of which is it would also make it easier to depend on a specific component if that's all one needs. The difficulty though is how to build the final full product. At this point I think the only way to do it is to write a special script or rake task that builds a staging of the final product --it's too bad, setup.rb supports this layout via packages/ dir, but gems does not. Even so, I can build the tool to handle this -- or perhaps there's a better way to achieve the same? Thoughts? T. From george.moschovitis at gmail.com Tue Feb 13 06:52:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 13:52:23 +0200 Subject: [Nitro] Darcs troubles In-Reply-To: <1171330909.386985.67070@m58g2000cwm.googlegroups.com> References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <1171330909.386985.67070@m58g2000cwm.googlegroups.com> Message-ID: I am also considering the best way to organize Nitro in more manageable (and understandable) components. At the moment, I am thinking about switching to a Rails style organization: Nitro = the super-framework, integrates Gen, Og, Facets (the web, data, util sub-frameworks) Gen = What is currently Nitro and the user will be able to add additional plugins: nitro-mailer.rb nitro-navigation.rb etc, etc. plugins can define Gen, Og, Facets, functionality, Nitro parts and stuff like that. They will be distributed as gems. The Nitro directory will just contain some configuration docs, the nitro command, and the prototype application. All Web related code will be moved to the Gen (or if someone has a cool name suggestion let me know) namespace. Oh, and Glue will disappear in favor of Facets (unless Tom likes the name Glue and would like to use it somewhere) What do you think? George. PS: I pushed some new stuff to the repo. Be warned, it breaks almost everything. But I would like to ask you to have a look at the code and offer suggestions. The aim of these changes is to make the code more understandable and manageable but please keep in mind that at the moment this is work in progress. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/80383193/attachment.html From transfire at gmail.com Tue Feb 13 09:40:26 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 13 Feb 2007 14:40:26 -0000 Subject: [Nitro] Darcs troubles In-Reply-To: References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <1171330909.386985.67070@m58g2000cwm.googlegroups.com> Message-ID: <1171377626.282225.227340@a75g2000cwd.googlegroups.com> On Feb 13, 6:52 am, "George Moschovitis" wrote: > I am also considering the best way to organize Nitro in more manageable (and > understandable) components. At the moment, I am thinking about switching to > a Rails style organization: > > Nitro = the super-framework, integrates Gen, Og, Facets (the web, data, util > sub-frameworks) > Gen = What is currently Nitro > > and the user will be able to add additional plugins: > > nitro-mailer.rb > nitro-navigation.rb > > etc, etc. > > plugins can define Gen, Og, Facets, functionality, Nitro parts and stuff > like that. They will be distributed as gems. > > The Nitro directory will just contain some configuration docs, the nitro > command, and the prototype application. All Web related code will be moved > to the Gen (or if someone has a cool name suggestion let me know) namespace. > > Oh, and Glue will disappear in favor of Facets (unless Tom likes the name > Glue and would like to use it somewhere) > > What do you think? I think it's great! But... I don't really get the Nitro/Gen split. It seesm to narrow on one side, so it doesn't really buy us anything. Nitro is nothing without "Gen", so why make it separate? I'd rather see the template engines each be a separate part: nitro # contoller app nitro-nhtml # nitro's Which sqlite gem do we use? sqlite sqlite-ruby sqlite3-ruby T. From george.moschovitis at gmail.com Tue Feb 13 10:01:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 17:01:40 +0200 Subject: [Nitro] Which sqlite adapter? In-Reply-To: <1171378010.326913.284840@v33g2000cwv.googlegroups.com> References: <1171378010.326913.284840@v33g2000cwv.googlegroups.com> Message-ID: sqlite3-ruby -g. On 2/13/07, transfire at gmail.com wrote: > > Which sqlite gem do we use? > > sqlite > sqlite-ruby > sqlite3-ruby > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/c7885e72/attachment.html From transfire at gmail.com Tue Feb 13 10:44:14 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 13 Feb 2007 15:44:14 -0000 Subject: [Nitro] Which sqlite adapter? In-Reply-To: References: <1171378010.326913.284840@v33g2000cwv.googlegroups.com> Message-ID: <1171381454.214339.7780@q2g2000cwa.googlegroups.com> On Feb 13, 10:01 am, "George Moschovitis" wrote: > sqlite3-ruby Sigh.... Building native extensions. This could take a while... make: *** No rule to make target `ruby.h', needed by `sqlite3_api_wrap.o'. Stop. make: *** No rule to make target `ruby.h', needed by `sqlite3_api_wrap.o'. Stop. ruby extconf.rb install sqlite3-ruby checking for sqlite3.h... no make make install Successfully installed sqlite3-ruby-1.2.1 Installing RDoc documentation for sqlite3-ruby-1.2.1... lib/sqlite3/database.rb:638:65: Skipping require of dynamic string: "sqlite3/driver/#{driver.to_s.downcase}/driver" lib/sqlite3/database.rb:643:59: Skipping require of dynamic string: "sqlite3/driver/#{d.downcase}/driver" trans at upixie:~/ruby/nitro/repo.nitroproject.org/examples/blog$ ruby app.rb INFO: Og uses the Sqlite store. ERROR: RuntimeError in Og.setup: ERROR: libsqlite3.so: cannot open shared object file: No such file or directory ERROR: /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize' /usr/lib/ruby/1.8/dl/import.rb:29:in `dlload' /usr/lib/ruby/1.8/dl/import.rb:27:in `dlload' /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ api.rb:63 /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ driver.rb:33 /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: 643:in `load_driver' /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: 641:in `load_driver' /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: 107:in `initialize' /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/adapter/ sqlite.rb:35:in `initialize' /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: 88:in `init_store' /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: 87:in `init_store' /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: 75:in `initialize' /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og.rb:151:in `start' ./conf/debug.rb:9:in `setup_og' ./conf/debug.rb:23:in `setup' /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server.rb: 31:in `configure' /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ app.rb:115:in `configure' /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ app.rb:75:in `start' app.rb:28 From george.moschovitis at gmail.com Tue Feb 13 10:58:24 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 17:58:24 +0200 Subject: [Nitro] Darcs troubles In-Reply-To: <1171377626.282225.227340@a75g2000cwd.googlegroups.com> References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <1171330909.386985.67070@m58g2000cwm.googlegroups.com> <1171377626.282225.227340@a75g2000cwd.googlegroups.com> Message-ID: The relation of Nitro/Gen will be the same as the relation between Rails/ActionPack. Nitro will be a super-framework combining Gen (Web framework), Og (Orm), Facets (Infrastructure). Nitro will be customized by using Plugins (nitro_nhtml, nitro_mailer, etc...) makes sense? -g. I think it's great! But... I don't really get the Nitro/Gen split. It > seesm to narrow on one side, so it doesn't really buy us anything. > Nitro is nothing without "Gen", so why make it separate? I'd rather > see the template engines each be a separate part: > > nitro # contoller app > nitro-nhtml # nitro's nitro-builder # builder template sys. > nitro-rhtml # eruby templates > etc. > > And actually even parts for controller adapters: > > nitro # core controller code > nitro-apache # apache adapter > nitro-mongrel # mongrel adapter > etc. > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/92c9922c/attachment.html From george.moschovitis at gmail.com Tue Feb 13 11:24:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 18:24:39 +0200 Subject: [Nitro] Which sqlite adapter? In-Reply-To: <1171381454.214339.7780@q2g2000cwa.googlegroups.com> References: <1171378010.326913.284840@v33g2000cwv.googlegroups.com> <1171381454.214339.7780@q2g2000cwa.googlegroups.com> Message-ID: > ERROR: libsqlite3.so: cannot open shared object file: No such file or > directory Seems to me that you have not installed the sqlite3 driver correctly. -g. On 2/13/07, transfire at gmail.com wrote: > > > > On Feb 13, 10:01 am, "George Moschovitis" > wrote: > > sqlite3-ruby > > Sigh.... > > Building native extensions. This could take a while... > make: *** No rule to make target `ruby.h', needed by > `sqlite3_api_wrap.o'. Stop. > make: *** No rule to make target `ruby.h', needed by > `sqlite3_api_wrap.o'. Stop. > ruby extconf.rb install sqlite3-ruby > checking for sqlite3.h... no > > make > > make install > Successfully installed sqlite3-ruby-1.2.1 > Installing RDoc documentation for sqlite3-ruby-1.2.1... > > lib/sqlite3/database.rb:638:65: Skipping require of dynamic string: > "sqlite3/driver/#{driver.to_s.downcase}/driver" > > lib/sqlite3/database.rb:643:59: Skipping require of dynamic string: > "sqlite3/driver/#{d.downcase}/driver" > > trans at upixie:~/ruby/nitro/repo.nitroproject.org/examples/blog$ ruby > app.rb > INFO: Og uses the Sqlite store. > ERROR: RuntimeError in Og.setup: > ERROR: libsqlite3.so: cannot open shared object file: No such file or > directory > ERROR: /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize' > /usr/lib/ruby/1.8/dl/import.rb:29:in `dlload' > /usr/lib/ruby/1.8/dl/import.rb:27:in `dlload' > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ > api.rb:63 > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require' > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ > driver.rb:33 > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require' > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: > 643:in `load_driver' > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: > 641:in `load_driver' > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: > 107:in `initialize' > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/adapter/ > sqlite.rb:35:in `initialize' > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > 88:in `init_store' > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > 87:in `init_store' > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > 75:in `initialize' > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og.rb:151:in > `start' > ./conf/debug.rb:9:in `setup_og' > ./conf/debug.rb:23:in `setup' > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server.rb: > 31:in `configure' > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ > app.rb:115:in `configure' > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ > app.rb:75:in `start' > app.rb:28 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/932ef5ab/attachment-0001.html From george.moschovitis at gmail.com Tue Feb 13 11:26:12 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 13 Feb 2007 18:26:12 +0200 Subject: [Nitro] Which sqlite adapter? In-Reply-To: References: <1171378010.326913.284840@v33g2000cwv.googlegroups.com> <1171381454.214339.7780@q2g2000cwa.googlegroups.com> Message-ID: Btw, for the moment please use Mysql. I have applied some patches from Judster (that remove the evals from Og). Only the Mysql adapter is updated at the moment. Perhaps Judster can help with the other adapters too? -g. On 2/13/07, George Moschovitis wrote: > > > ERROR: libsqlite3.so: cannot open shared object file: No such file or > > directory > > Seems to me that you have not installed the sqlite3 driver correctly. > > -g. > > On 2/13/07, transfire at gmail.com wrote: > > > > > > > > On Feb 13, 10:01 am, "George Moschovitis" > > wrote: > > > sqlite3-ruby > > > > Sigh.... > > > > Building native extensions. This could take a while... > > make: *** No rule to make target `ruby.h', needed by > > `sqlite3_api_wrap.o'. Stop. > > make: *** No rule to make target `ruby.h', needed by > > `sqlite3_api_wrap.o'. Stop. > > ruby extconf.rb install sqlite3-ruby > > checking for sqlite3.h... no > > > > make > > > > make install > > Successfully installed sqlite3-ruby-1.2.1 > > Installing RDoc documentation for sqlite3-ruby-1.2.1... > > > > lib/sqlite3/database.rb:638:65: Skipping require of dynamic string: > > "sqlite3/driver/#{driver.to_s.downcase}/driver" > > > > lib/sqlite3/database.rb:643:59: Skipping require of dynamic string: > > "sqlite3/driver/#{d.downcase}/driver" > > > > trans at upixie:~/ruby/nitro/repo.nitroproject.org/examples/blog$ ruby > > app.rb > > INFO: Og uses the Sqlite store. > > ERROR: RuntimeError in Og.setup: > > ERROR: libsqlite3.so: cannot open shared object file: No such file or > > directory > > ERROR: /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize' > > /usr/lib/ruby/1.8/dl/import.rb:29:in `dlload' > > /usr/lib/ruby/1.8/dl/import.rb:27:in `dlload' > > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ > > api.rb:63 > > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > > `require' > > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/driver/dl/ > > driver.rb:33 > > /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > > `require' > > /usr/lib/ruby/gems/1.8/gems/sqlite3- ruby-1.2.1/lib/sqlite3/database.rb: > > 643:in `load_driver' > > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: > > 641:in `load_driver' > > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/database.rb: > > 107:in `initialize' > > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/adapter/ > > sqlite.rb:35:in `initialize' > > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > > 88:in `init_store' > > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > > 87:in `init_store' > > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og/manager.rb: > > 75:in `initialize' > > /home/trans/ruby/nitro/repo.nitroproject.org/og/lib/og.rb:151:in > > `start' > > ./conf/debug.rb:9:in `setup_og' > > ./conf/debug.rb:23:in `setup' > > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server.rb: > > 31:in `configure' > > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ > > app.rb:115:in `configure' > > /home/trans/ruby/nitro/repo.nitroproject.org/nitro/lib/nitro/server/ > > app.rb:75:in `start' > > app.rb:28 > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070213/2a1ec01e/attachment.html From john at oxyliquit.de Tue Feb 13 12:14:18 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 13 Feb 2007 18:14:18 +0100 Subject: [Nitro] Darcs troubles In-Reply-To: <8905c87a0702121639u54e3fc19sbeab0379c329f165@mail.gmail.com> References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <8905c87a0702121639u54e3fc19sbeab0379c329f165@mail.gmail.com> Message-ID: Hi, > Comforting how, exactly? Because the error messages are more casual? > "You wrecked your repo, but that's fine with me!" ;P well, yes, kinda :P > The thing I need most with Darcs right now is to see some good in it. > Right now the only feature it gives me is bleeding edge Nitro + Og. > What *is* good about Darcs? Nah, well, darcs is imo just a breeze to use. Creating new repos doesn't need more than `darcs init` whereas I need to look up into handbooks for other SCMs. It's merely that I can remember all important commands. I use darcs for all my projects nowadays, even if I'm the only one working on them. This gives me an overview on what I have done when and enables me to have dev repos of it wherever I want them to be. I can do work on train where I have no internet connection and still record what I have done. This is a feature of distributed SCMs and darcs is just one of those. Darcs has the feature of letting me specify exactly what I want to publish from a single file. Others only let you publish the whole file. >> > On a related note, can I tell darcs to use an external merger? I find the >> > default behavior of clobbering source files mostly just confusing. >> >> No idea on that. >> >> You mean using an external merger when you do `darcs pull`? When pressing 'p' >> while pulling patches, you can look at the whole patch which is very useful. > > You do a darcs pull. Darcs responds "x, y, and z have conflicts." > Rather than have darcs "helpfully" add text to a source file, can I > get it to open up (ideally) meld or xxdiff or something, and let me > see the differences side by side? And with the clear annotation that > the left is old and the right is new (or local and remote, or > whatever)? Ah, gotcha now. I find it often confusing with darcs, which 'block' of the conflict was mine and which one was from others too. :P A conflict though is mostly the product of working on a repo differing too much from the main repo in that area one worked on. So, pull often from Georges repo, that minimizes the conflicts. Don't pull patches which George has reworked. This kind of defeats the idea of a 'distributed SCM'... So, to come to an end: To not get confused, don't produce conflicts! :P > (And has anyone else used monotone?) Hm, nope. Any good? Differences, advantages? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Tue Feb 13 13:45:49 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 13 Feb 2007 18:45:49 -0000 Subject: [Nitro] Darcs troubles In-Reply-To: References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <8905c87a0702121639u54e3fc19sbeab0379c329f165@mail.gmail.com> Message-ID: <1171392349.287417.97610@l53g2000cwa.googlegroups.com> On Feb 13, 12:14 pm, "Jonathan Buch" wrote: > Nah, well, darcs is imo just a breeze to use. Creating new repos doesn't > need more than `darcs init` whereas I need to look up into handbooks for > other SCMs. It's merely that I can remember all important commands. > > I use darcs for all my projects nowadays, even if I'm the only one working > on them. This gives me an overview on what I have done when and enables > me to have dev repos of it wherever I want them to be. I can do work on > train where I have no internet connection and still record what I have done. > This is a feature of distributed SCMs and darcs is just one of those. > > Darcs has the feature of letting me specify exactly what I want to publish > from a single file. Others only let you publish the whole file. Those are good points. I find it often chorish to record however. I wish I could just add a log note to the source file which darcs would extract and use to record the change. That would be sweet. Alas, I don't see anyway to tell darcs to selectively record without going through the question-answer session. T. From nyarly at gmail.com Tue Feb 13 14:09:20 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 13 Feb 2007 11:09:20 -0800 Subject: [Nitro] Darcs troubles In-Reply-To: References: <8905c87a0702121211v100d87d3wb62ebf2cff95e866@mail.gmail.com> <8905c87a0702121639u54e3fc19sbeab0379c329f165@mail.gmail.com> Message-ID: <8905c87a0702131109h4d6f165mc92d3208852a0807@mail.gmail.com> At the risk of chattering up the list too much... On 2/13/07, Jonathan Buch wrote: > > You do a darcs pull. Darcs responds "x, y, and z have conflicts." > > Rather than have darcs "helpfully" add text to a source file, can I > > get it to open up (ideally) meld or xxdiff or something, and let me > > see the differences side by side? And with the clear annotation that > > the left is old and the right is new (or local and remote, or > > whatever)? > > Ah, gotcha now. > > I find it often confusing with darcs, which 'block' of the conflict was > mine and which one was from others too. :P Yeah. Hence the question about an external merger. > A conflict though is mostly the product of working on a repo differing > too much from the main repo in that area one worked on. > So, pull often from Georges repo, that minimizes the conflicts. Don't > pull patches which George has reworked. This kind of defeats the idea > of a 'distributed SCM'... > > So, to come to an end: To not get confused, don't produce conflicts! :P Wow. Those two paragraphs have got to be the single strongest argument against a particular SCM that I've ever seen. ;) > > (And has anyone else used monotone?) > > Hm, nope. Any good? Differences, advantages? Yes, it's good. For my internal projects, I use monotone. It's a distributed SCM, which is, AFAICT, about the end of it's similarity to darcs. As far as ease of use, there's a little initial hump to get over, but the documentation is there. Including per command on line help ("mtn init help" returns all the options you need.) After that, it's like carrying a Swiss army knife with a backhoe blade. For instance, I've been interested by Tom's Rachet's thing, but I basically have mtn repo for gems that I check out to start new projects. Whenever I make changes to it, I check it in, and then propagate back out to my projects, secure that it'll merge correctly. If you're interested, drop me a line off-list and I'll make you a believer. Judson From vikingtux at gmail.com Tue Feb 13 22:16:05 2007 From: vikingtux at gmail.com (Alexandre Gravem) Date: Wed, 14 Feb 2007 01:16:05 -0200 Subject: [Nitro] Elements In-Reply-To: References: Message-ID: <40b05ebe0702131916t6569b5cbmfc35e4ca43e22a22@mail.gmail.com> On 2/12/07, George Moschovitis wrote: > > Dear devs, > > Is anyone using Element template files? I would like to temporarily remove > this functionality while I cleanup elements. > Just to register ... for Elements template files do you mean the element/*.xhtml files that get converted to Elements? Yes, i just use Elements this way, I like it better because I am not the designer, so he can freely manipulate the layout without bother about ruby classes. - A. Gravem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/87ee51bf/attachment.html From george.moschovitis at gmail.com Wed Feb 14 03:35:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 14 Feb 2007 10:35:52 +0200 Subject: [Nitro] Elements In-Reply-To: <40b05ebe0702131916t6569b5cbmfc35e4ca43e22a22@mail.gmail.com> References: <40b05ebe0702131916t6569b5cbmfc35e4ca43e22a22@mail.gmail.com> Message-ID: Hmm... ok, I will bring this back in. Thanks for letting me know. regards, George. On 2/14/07, Alexandre Gravem wrote: > > On 2/12/07, George Moschovitis wrote: > > > > Dear devs, > > > > Is anyone using Element template files? I would like to temporarily > > remove this functionality while I cleanup elements. > > > > Just to register ... for Elements template files do you mean the > element/*.xhtml files that get converted to Elements? Yes, i just use > Elements this way, I like it better because I am not the designer, so he can > freely manipulate the layout without bother about ruby classes. > > - A. Gravem > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/52caa2e1/attachment-0001.html From george.moschovitis at gmail.com Wed Feb 14 09:35:53 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 14 Feb 2007 16:35:53 +0200 Subject: [Nitro] Ruby library for serialization Message-ID: Dear devs, is there a Ruby library that can convert a Ruby object to XML, Atom, Json etc? I tried facets/more/json and facets/more/xoxo and they just use the .to_s method of the object, ie class Article attr_accessor :title, :content, :author def to_s; @title; end end a = Article.new a.title = 'hello' a.content = '...' a.author = 'george' a.to_json # => 'hello' which is not what I expected. any suggestions? regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/7ba02ece/attachment.html From george.moschovitis at gmail.com Wed Feb 14 10:00:03 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 14 Feb 2007 17:00:03 +0200 Subject: [Nitro] ScriptCompiler Message-ID: Does anyone use the ScriptCompiler? I would like to deprecate this. Using JQuery, you can do almost anything that the ScriptCompiler allows you to do in a standard way. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/14b093c9/attachment.html From transfire at gmail.com Wed Feb 14 11:23:29 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Wed, 14 Feb 2007 16:23:29 -0000 Subject: [Nitro] Ruby library for serialization In-Reply-To: References: Message-ID: <1171470209.634826.76480@v45g2000cwv.googlegroups.com> On Feb 14, 9:35 am, "George Moschovitis" wrote: > Dear devs, > > is there a Ruby library that can convert a Ruby object to XML, Atom, Json > etc? > > I tried facets/more/json and facets/more/xoxo and they just use the .to_s > method of the object, ie > > class Article > attr_accessor :title, :content, :author > def to_s; @title; end > end > > a = Article.new > a.title = 'hello' > a.content = '...' > a.author = 'george' > > a.to_json # => 'hello' > > which is not what I expected. > > any suggestions? The JSON lib has #to_json, the XOXO lib has to_xoxo. There is a a way to do XML serialization that's built-into ruby, but it's a little more involved and I don't recall off hand how to do so. (Was it via the soap lib?) Need to look that up --if you do please let us know. T. From george.moschovitis at gmail.com Wed Feb 14 11:35:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 14 Feb 2007 18:35:41 +0200 Subject: [Nitro] Ruby library for serialization In-Reply-To: <1171470209.634826.76480@v45g2000cwv.googlegroups.com> References: <1171470209.634826.76480@v45g2000cwv.googlegroups.com> Message-ID: as i demonstrated to_json does not work as expected... -g. On 2/14/07, transfire at gmail.com wrote: > > > On Feb 14, 9:35 am, "George Moschovitis" > wrote: > > Dear devs, > > > > is there a Ruby library that can convert a Ruby object to XML, Atom, > Json > > etc? > > > > I tried facets/more/json and facets/more/xoxo and they just use the > .to_s > > method of the object, ie > > > > class Article > > attr_accessor :title, :content, :author > > def to_s; @title; end > > end > > > > a = Article.new > > a.title = 'hello' > > a.content = '...' > > a.author = 'george' > > > > a.to_json # => 'hello' > > > > which is not what I expected. > > > > any suggestions? > > The JSON lib has #to_json, the XOXO lib has to_xoxo. There is a a way > to do XML serialization that's built-into ruby, but it's a little more > involved and I don't recall off hand how to do so. (Was it via the > soap lib?) Need to look that up --if you do please let us know. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/c1481684/attachment.html From transfire at gmail.com Wed Feb 14 13:14:02 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Wed, 14 Feb 2007 18:14:02 -0000 Subject: [Nitro] Ruby library for serialization In-Reply-To: References: <1171470209.634826.76480@v45g2000cwv.googlegroups.com> Message-ID: <1171476842.923170.34740@a75g2000cwd.googlegroups.com> On Feb 14, 11:35 am, "George Moschovitis" wrote: > as i demonstrated to_json does not work as expected... sorry. i didn't read carfully enough. and you are right. to_json only works with specific types that account for it. but i have a solution. since YAML is a superset of JSON: class Object def to_json(*) str = to_yaml str.sub!(/^---.*?$/, '---') YAML.load(str).to_json end end I'll make this change to Facets. (Also fixed to_xoxo, so it will now work too). Thanks, T. From george.moschovitis at gmail.com Wed Feb 14 13:20:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 14 Feb 2007 20:20:36 +0200 Subject: [Nitro] Ruby library for serialization In-Reply-To: <1171476842.923170.34740@a75g2000cwd.googlegroups.com> References: <1171470209.634826.76480@v45g2000cwv.googlegroups.com> <1171476842.923170.34740@a75g2000cwd.googlegroups.com> Message-ID: Thanks for the quick reply, when you are finished, can you send me the new version of json.rb/xoxo.rb ? -g. On 2/14/07, transfire at gmail.com wrote: > > > > On Feb 14, 11:35 am, "George Moschovitis" > wrote: > > as i demonstrated to_json does not work as expected... > > sorry. i didn't read carfully enough. and you are right. to_json only > works with specific types that account for it. but i have a solution. > since YAML is a superset of JSON: > > class Object > def to_json(*) > str = to_yaml > str.sub!(/^---.*?$/, '---') > YAML.load(str).to_json > end > end > > I'll make this change to Facets. > > (Also fixed to_xoxo, so it will now work too). > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070214/9976c725/attachment.html From manveru at weez-int.com Thu Feb 15 01:45:31 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Thu, 15 Feb 2007 15:45:31 +0900 Subject: [Nitro] Nice summary about some REST-style... Message-ID: Hi guys, Since G. implemented REST-style recently i found that one quite interesting... http://www.lukeredpath.co.uk/2007/2/2/refactoring-rest-searching-for-an-abstraction It's not for Nitro, but should be fairly simple to translate to Nitro. ^ manveru From manveru at weez-int.com Thu Feb 15 02:21:01 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Thu, 15 Feb 2007 16:21:01 +0900 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: <1171118292.024681.208720@m58g2000cwm.googlegroups.com> References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> <1171118292.024681.208720@m58g2000cwm.googlegroups.com> Message-ID: On Sat, 10 Feb 2007 23:38:12 +0900, wrote: > > > On Feb 10, 4:56 am, "Jonathan Buch" wrote: >> Hi, >> >> > and thanks for your great work. I am wondering if you could help the >> Nitro >> > project and provide soem autorake files for Nitro and Og. Epscially >> this >> > rake publish thing would be nice to have! >> >> oh yes yes, a Rakefile, to also let these tests run on Firebrigade: >> >> http://firebrigade.seattlerb.org/build/show/12012 >> >> This I guess only looks that way, because it doesn't know how to run our >> tests. With a Rakefile that won't be a problem anymore. >> >> Only thing with Rake tests is, that it runs them in a single 'run', >> where >> some tests interfere with one another. A while back I minimized those >> interferances, but I think some are still there. > > If Firebrigade can run the test task as defined by our Rakefile that > won't be a problem. autorake's test task runs each test as a separate > proccess. > (You see, I've had this problem before too ;-) > Speaking of which... is there any work done already for integration with RSpec and or Rcov? Anyway, great work! Will try it immediatly :) ^ manveru > T. From george.moschovitis at gmail.com Thu Feb 15 02:58:14 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 15 Feb 2007 09:58:14 +0200 Subject: [Nitro] Nice summary about some REST-style... In-Reply-To: References: Message-ID: Something like this is planned for the next version of Nitro, only way better ;-) -g. On 2/15/07, Michael Fellinger wrote: > > Hi guys, > > Since G. implemented REST-style recently i found that one quite > interesting... > > http://www.lukeredpath.co.uk/2007/2/2/refactoring-rest-searching-for-an-abstraction > It's not for Nitro, but should be fairly simple to translate to Nitro. > > ^ manveru > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070215/3beb2d08/attachment-0001.html From manveru at weez-int.com Thu Feb 15 03:48:15 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Thu, 15 Feb 2007 17:48:15 +0900 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: <1171118292.024681.208720@m58g2000cwm.googlegroups.com> References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> <1171118292.024681.208720@m58g2000cwm.googlegroups.com> Message-ID: On Sat, 10 Feb 2007 23:38:12 +0900, wrote: > > > On Feb 10, 4:56 am, "Jonathan Buch" wrote: >> Hi, >> >> > and thanks for your great work. I am wondering if you could help the >> Nitro >> > project and provide soem autorake files for Nitro and Og. Epscially >> this >> > rake publish thing would be nice to have! >> >> oh yes yes, a Rakefile, to also let these tests run on Firebrigade: >> >> http://firebrigade.seattlerb.org/build/show/12012 >> >> This I guess only looks that way, because it doesn't know how to run our >> tests. With a Rakefile that won't be a problem anymore. >> >> Only thing with Rake tests is, that it runs them in a single 'run', >> where >> some tests interfere with one another. A while back I minimized those >> interferances, but I think some are still there. > > If Firebrigade can run the test task as defined by our Rakefile that > won't be a problem. autorake's test task runs each test as a separate > proccess. > (You see, I've had this problem before too ;-) Ok, after trying it... a couple of questions :) - I need a way to say my tests are in spec/tc_* - The MANIFEST lists all files, i got some non-ruby files as well, for which ruby -c fails, is there a way to only let it run over .rb files? - How exactly do autorake and ProjectInfo cooperate? does autorake use my ProjectInfo automagically? Maybe some more questions later... gotta go... All in all it seems like a really nice rake that finally understands it's not only about tasks but about tasks for a specific project, i find that very positive :) And thanks for all the fish. ^ manveru > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From manveru at weez-int.com Thu Feb 15 03:49:16 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Thu, 15 Feb 2007 17:49:16 +0900 Subject: [Nitro] Nice summary about some REST-style... In-Reply-To: References: Message-ID: On Thu, 15 Feb 2007 16:58:14 +0900, George Moschovitis wrote: > Something like this is planned for the next version of Nitro, only way > better ;-) > Can't wait to see it :) If it's anything like you told us on IRC it's gonna be great... especially if Og provides some kind of integrational wrapper... ^ manveru > -g. > > On 2/15/07, Michael Fellinger wrote: >> >> Hi guys, >> >> Since G. implemented REST-style recently i found that one quite >> interesting... >> >> http://www.lukeredpath.co.uk/2007/2/2/refactoring-rest-searching-for-an-abstraction >> It's not for Nitro, but should be fairly simple to translate to Nitro. >> >> ^ manveru >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> > > > From george.moschovitis at gmail.com Thu Feb 15 05:34:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 15 Feb 2007 12:34:46 +0200 Subject: [Nitro] nitro/service Message-ID: Dear devs, In the process of cleaning up Nitro, I am removing nitro/service. Nitro will provide implicit support for web services from now on, so this is no longer neede. And I doubt anyone has ever used this. regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070215/36df5aaa/attachment.html From transfire at gmail.com Thu Feb 15 05:36:53 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 15 Feb 2007 10:36:53 -0000 Subject: [Nitro] Ratchets releases: projectinfo, exacto, autorake In-Reply-To: References: <1171048122.422397.219480@s48g2000cws.googlegroups.com> <1171118292.024681.208720@m58g2000cwm.googlegroups.com> Message-ID: <1171535813.646266.54570@a34g2000cwb.googlegroups.com> On Feb 15, 3:48 am, "Michael Fellinger" wrote: > Ok, after trying it... a couple of questions :) > > - I need a way to say my tests are in spec/tc_* In ProjectInfo you can use tests: spec/tc_*.rb or test_files: spec/tc_*.rb or test: files: spec/tc_*.rb these should all be synonomous. also note, that i put the .rb on there just as an extra precaution --it's not required, and also you can specifiy more than one glob in an array if you need it. For example: test: files: - test/tc_*.rb - spec/tc_*.rb > - The MANIFEST lists all files, i got some non-ruby files as well, for > which ruby -c fails, is there a way to only let it run over .rb files? The manifest or syntax task? If syntax, you should be able to set scripts: lib/**/*.rb I just fixed a bug and that will now be the default in >0.5.2, but I'm not 100% about the name of that setting yet. But if you mean the manifest that's defined by distribute: **/* Since the intent of the manifest is to list all files that will be included in the distributed package, by default that includes everything minus "project.ignore" which contains typical exclusions (like _darcs). You can set distribute straight (though ignore is always excluded) or you can easily adjust it with a '-' prefix too. For example I often have a scrap directory to store old code that I'm not quite ready to throw away. So I have: distribute: [ -scrap ] # yes, this can be an array too it's a recursive glob btw, so everything within scrap/ is excluded. > - How exactly do autorake and ProjectInfo cooperate? does autorake use my > ProjectInfo automagically? Essentially yes. In autorake there's a Project class that delegates to ProjectInfo via #info. Then all the actual tasks are defined as methods of Project and each snags information from #info as needed. I had planned to define the task and the code that pulls the info it needs separately, but I let that SOC go for now. The ProjectIndfo class itself makes things easier by offering defaults and also by the way it loads. An entry like: test: files: **/test*.rb actually maps to ProjectInfo#test_files. > Maybe some more questions later... gotta go... > All in all it seems like a really nice rake that finally understands it's > not only about tasks but about tasks for a specific project, i find that > very positive :) That's it exactly, well put. And I am very glad to hear it. Let me know if you have any other troubles or suggestions. I just fixed a couple bugs and uploaded 0.5.1. > And thanks for all the fish. All 42 ;) Whew, it's late and I'm very tired. Nite. HTH, T. From pedro.gutierrez at netcourrier.com Thu Feb 15 08:23:43 2007 From: pedro.gutierrez at netcourrier.com (pedro gutierrez) Date: Thu, 15 Feb 2007 14:23:43 +0100 Subject: [Nitro] [Og] expected behaviour? Message-ID: <083CFE67-95AC-4A72-A35F-4E53C834FCC7@netcourrier.com> Hi everybody, My name is pedro, i am from spain, a ruby newbie, and a fan of nitro/ og ! This is my first post to the mailing list, I hope i will be clear and write correct english .. I've tested a very simple scenario of the has_many/belongs_to relationship, and had some strange behaviour, so I wanted to check that the result I got is the one it is expected. Let met explain the scenario: a Topic contains many Sections a Section belongs to a Topic That's all. Now, I create (and save) a "topic1", then I create (and save) a "section" attached to "topic1". Everything is fine so far. Then I create a second topic, named topic2, and save it. Then I try to move section from topic1 to topic2, by doing: section.topic = topic1. Immediately, Og issues an UPDATE sql statement in the form: UPDATE ogsection SET name='update issue', topic_oid=2 WHERE oid=1 The thing is that this statement has been executed BEFORE I call the save method on the section! Is that the expected behaviour? I was expecting that the changes where performed in memory, and then commited to the database when I do "section.save" I've attached the source code of my test case. please let me know if I am not very clear in my explanations, and thanks in advance for any help you could provide! Pedro. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.rb Type: text/x-ruby-script Size: 1736 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070215/4a481601/attachment.bin -------------- next part -------------- From john at oxyliquit.de Thu Feb 15 11:45:00 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 15 Feb 2007 17:45:00 +0100 Subject: [Nitro] [Og] expected behaviour? In-Reply-To: <083CFE67-95AC-4A72-A35F-4E53C834FCC7@netcourrier.com> References: <083CFE67-95AC-4A72-A35F-4E53C834FCC7@netcourrier.com> Message-ID: Weclome Predro! > a Topic contains many Sections > a Section belongs to a Topic > > That's all. Now, I create (and save) a "topic1", then I create (and > save) a "section" attached to "topic1". Everything is fine so far. > > Then I create a second topic, named topic2, and save it. > Then I try to move section from topic1 to topic2, by doing: > section.topic = topic1. > > Immediately, Og issues an UPDATE sql statement in the form: > UPDATE ogsection SET name='update issue', topic_oid=2 WHERE oid=1 > > The thing is that this statement has been executed BEFORE I call the > save method on the section! > > Is that the expected behaviour? I was expecting that the changes > where performed in memory, and then commited to the database when I > do "section.save" This looks like a bug in the code: og/relation/refers_to.rb:65: save unless self.unsaved? So, save when the current object is already saved. I'm not getting the all implications yet of removing that line, but it shouldn't hurt much. Og.setting :autosave_relations, :default => false ? Or does that look like overload... :P George? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Fri Feb 16 00:43:31 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 16 Feb 2007 05:43:31 -0000 Subject: [Nitro] Facets 1.8.49 Message-ID: <1171604611.934679.37390@v45g2000cwv.googlegroups.com> Facets 1.8.49 is out. 1.8 series is offically stamped stable as of this release. Among other things I spent some time testing Facets on Windows platform which I have never done before -- led to a handful of fixes which is great. T. From george.moschovitis at gmail.com Fri Feb 16 03:24:34 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 16 Feb 2007 10:24:34 +0200 Subject: [Nitro] Facets 1.8.49 In-Reply-To: <1171604611.934679.37390@v45g2000cwv.googlegroups.com> References: <1171604611.934679.37390@v45g2000cwv.googlegroups.com> Message-ID: congrats ;-) hopefully you will find some time to tackle the builder thing ;-) -g. On 2/16/07, transfire at gmail.com wrote: > > Facets 1.8.49 is out. 1.8 series is offically stamped stable as of > this release. > > Among other things I spent some time testing Facets on Windows > platform which I have never done before -- led to a handful of fixes > which is great. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070216/6e8dd288/attachment.html From g.h.p.ebberink at nclr.nl Fri Feb 16 04:19:40 2007 From: g.h.p.ebberink at nclr.nl (Gerald Ebberink) Date: Fri, 16 Feb 2007 10:19:40 +0100 Subject: [Nitro] uninitialized constant OgAdminController::Scaffolding Message-ID: <038f01c751ab$96869b90$f7185982@nclr036> Hello everybody, First of all I really like the idea of nitro, but somehow I can't seem to get much of it in working order. I have made two nice model classes and a small controller also I have included the admin part. Now if I go to http://localhost:9000/admin/og And click on any of the links I get :"uninitialized constant OgAdminController::Scaffolding" What does this error mean and how can I get rid of it.. Also I'm trying the screen casts, and I can't even get those to work Sorry for my bad English, It is not my native tongue. Kind regards, Gerald P.S. nitroproject.org seems to be broken, a lot of (error)'s like /blog etc.. P.P.S I'm not able to create an account on nitroproject Gerald Ebberink Laser Technician NCLR B.V. PO box 2662 Enschede 7500CR The Netherlands Work: 31 53 4891110 Direct: 31 53 4893961 Fax: 31 53 4891102 Email: g.h.p.ebberink at nclr.nl My Profile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070216/46528a83/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3142 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070216/46528a83/attachment-0001.jpe From pedro.gutierrez at netcourrier.com Fri Feb 16 05:39:39 2007 From: pedro.gutierrez at netcourrier.com (pedro gutierrez) Date: Fri, 16 Feb 2007 11:39:39 +0100 Subject: [Nitro] [Og] expected behaviour? In-Reply-To: References: <083CFE67-95AC-4A72-A35F-4E53C834FCC7@netcourrier.com> Message-ID: Ok, I was just wondering what is the expected behaviour. Maybe that's not a bug, as Og offers transparent persistence. However, I will try to remove og/relation/refers_to.rb:65 from my local copy of og, and see what happens. Thanks for the clue, and congratulations for such a nice job you guys are doing with nitro and og! Pedro. Le Feb 15, 2007 ? 5:45 PM, Jonathan Buch a ?crit : > Weclome Predro! > >> a Topic contains many Sections >> a Section belongs to a Topic >> >> That's all. Now, I create (and save) a "topic1", then I create (and >> save) a "section" attached to "topic1". Everything is fine so far. >> >> Then I create a second topic, named topic2, and save it. >> Then I try to move section from topic1 to topic2, by doing: >> section.topic = topic1. >> >> Immediately, Og issues an UPDATE sql statement in the form: >> UPDATE ogsection SET name='update issue', topic_oid=2 WHERE oid=1 >> >> The thing is that this statement has been executed BEFORE I call the >> save method on the section! >> >> Is that the expected behaviour? I was expecting that the changes >> where performed in memory, and then commited to the database when I >> do "section.save" > > This looks like a bug in the code: > > og/relation/refers_to.rb:65: save unless self.unsaved? > > So, save when the current object is already saved. I'm not getting > the all implications yet of removing that line, but it shouldn't > hurt much. > > Og.setting :autosave_relations, :default => false ? > > Or does that look like overload... :P George? > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Fri Feb 16 07:40:12 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 16 Feb 2007 14:40:12 +0200 Subject: [Nitro] uninitialized constant OgAdminController::Scaffolding In-Reply-To: <038f01c751ab$96869b90$f7185982@nclr036> References: <038f01c751ab$96869b90$f7185982@nclr036> Message-ID: Hello Gerald, I know about the problems with the np.org site. I am actively working to fix them at the moment. Regarding your other problems. Which version of nitro are you using? Do the examples, Spark, Flare work for you? regards, George. On 2/16/07, Gerald Ebberink wrote: > > Hello everybody, > > > > First of all I really like the idea of nitro, but somehow I can't seem to > get much of it in working order. > > > > I have made two nice model classes and a small controller also I have > included the admin part. > > Now if I go to http://localhost:9000/admin/og > > And click on any of the links I get :"uninitialized constant > OgAdminController::Scaffolding" > > > > What does this error mean and how can I get rid of it.. > > > > Also I'm trying the screen casts, and I can't even get those to work > > > > Sorry for my bad English, It is not my native tongue. > > > > Kind regards, > > Gerald > > > > P.S. nitroproject.org seems to be broken, a lot of (error)'s like /blog > etc.. > > P.P.S I'm not able to create an account on nitroproject > > > > *Gerald Ebberink* > Laser Technician > > *NCLR B.V.* > PO box 2662 > Enschede > 7500CR > The Netherlands > > *Work:* 31 53 4891110 > *Direct:* 31 53 4893961 > *Fax:* 31 53 4891102 > *Email:* g.h.p.ebberink at nclr.nl > > *My Profile * > > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070216/e2600a02/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3142 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070216/e2600a02/attachment.jpg From g.h.p.ebberink at nclr.nl Fri Feb 16 08:11:22 2007 From: g.h.p.ebberink at nclr.nl (Gerald Ebberink) Date: Fri, 16 Feb 2007 14:11:22 +0100 Subject: [Nitro] uninitialized constant OgAdminController::Scaffolding In-Reply-To: Message-ID: <005901c751cb$f4b286a0$f7185982@nclr036> Hello George, The nitro version in 0.41.0 For which I cannot find the examples. But the problem is something I have solved. In the file admin/og/controller.rb On line 44 (list method) change Scaffolding.per_page to Nitro::Scaffolding.per_page Kind regards, Gerald Ebberink Gerald Ebberink Laser Technician NCLR B.V. PO box 2662 Enschede 7500CR The Netherlands Work: 31 53 4891110 Direct: 31 53 4893961 Fax: 31 53 4891102 Email: g.h.p.ebberink at nclr.nl My Profile _____ From: nitro-general-bounces at rubyforge.org [mailto:nitro-general-bounces at rubyforge.org] On Behalf Of George Moschovitis Sent: vrijdag 16 februari 2007 13:40 To: General discussion about Nitro Subject: Re: [Nitro] uninitialized constant OgAdminController::Scaffolding Hello Gerald, I know about the problems with the np.org site. I am actively working to fix them at the moment. Regarding your other problems. Which version of nitro are you using? Do the examples, Spark, Flare work for you? regards, George. On 2/16/07, Gerald Ebberink wrote: Hello everybody, First of all I really like the idea of nitro, but somehow I can't seem to get much of it in working order. I have made two nice model classes and a small controller also I have included the admin part. Now if I go to http://localhost:9000/admin/og And click on any of the links I get :"uninitialized constant OgAdminController::Scaffolding" What does this error mean and how can I get rid of it.. Also I'm trying the screen casts, and I can't even get those to work Sorry for my bad English, It is not my native tongue. Kind regards, Gerald P.S. nitroproject.org seems to be broken, a lot of (error)'s like /blog etc.. P.P.S I'm not able to create an account on nitroproject Gerald Ebberink Laser Technician NCLR B.V. PO box 2662 Enschede 7500CR The Netherlands Work: 31 53 4891110 Direct: 31 53 4893961 Fax: 31 53 4891102 Email: g.h.p.ebberink at nclr.nl My Profile _______________________________________________ Nitro-general mailing list Nitro-general at rubyforge.org http://rubyforge.org/mailman/listinfo/nitro-general -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070216/a6387c3f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3142 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070216/a6387c3f/attachment-0001.jpe From g.h.p.ebberink at nclr.nl Fri Feb 16 08:38:02 2007 From: g.h.p.ebberink at nclr.nl (Gerald Ebberink) Date: Fri, 16 Feb 2007 14:38:02 +0100 Subject: [Nitro] uninitialized constant OgAdminController::Scaffolding In-Reply-To: Message-ID: <006f01c751cf$ae1a0750$f7185982@nclr036> I have just downloaded and tried flare, But alas, the admin panel is broken because of the sitepath method being undefined. Gerald Ebberink Laser Technician NCLR B.V. PO box 2662 Enschede 7500CR The Netherlands Work: 31 53 4891110 Direct: 31 53 4893961 Fax: 31 53 4891102 Email: g.h.p.ebberink at nclr.nl My Profile _____ From: nitro-general-bounces at rubyforge.org [mailto:nitro-general-bounces at rubyforge.org] On Behalf Of George Moschovitis Sent: vrijdag 16 februari 2007 13:40 To: General discussion about Nitro Subject: Re: [Nitro] uninitialized constant OgAdminController::Scaffolding Hello Gerald, I know about the problems with the np.org site. I am actively working to fix them at the moment. Regarding your other problems. Which version of nitro are you using? Do the examples, Spark, Flare work for you? regards, George. On 2/16/07, Gerald Ebberink wrote: Hello everybody, First of all I really like the idea of nitro, but somehow I can't seem to get much of it in working order. I have made two nice model classes and a small controller also I have included the admin part. Now if I go to http://localhost:9000/admin/og And click on any of the links I get :"uninitialized constant OgAdminController::Scaffolding" What does this error mean and how can I get rid of it.. Also I'm trying the screen casts, and I can't even get those to work Sorry for my bad English, It is not my native tongue. Kind regards, Gerald P.S. nitroproject.org seems to be broken, a lot of (error)'s like /blog etc.. P.P.S I'm not able to create an account on nitroproject Gerald Ebberink Laser Technician NCLR B.V. PO box 2662 Enschede 7500CR The Netherlands Work: 31 53 4891110 Direct: 31 53 4893961 Fax: 31 53 4891102 Email: g.h.p.ebberink at nclr.nl My Profile _______________________________________________ Nitro-general mailing list Nitro-general at rubyforge.org http://rubyforge.org/mailman/listinfo/nitro-general -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070216/f6cc5f1c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3142 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070216/f6cc5f1c/attachment.jpe From george.moschovitis at gmail.com Tue Feb 20 05:25:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 20 Feb 2007 12:25:40 +0200 Subject: [Nitro] Facets command bug Message-ID: Tom, there is a typo in facets/more/command.rb: $strderr << "Nothing to do." -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070220/b2ade64f/attachment.html From transfire at gmail.com Tue Feb 20 10:09:11 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 20 Feb 2007 15:09:11 -0000 Subject: [Nitro] Facets command bug In-Reply-To: References: Message-ID: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> Hi-- Is this from the latest 1.8.51? ~t. On Feb 20, 5:25 am, "George Moschovitis" wrote: > Tom, > > there is a typo in facets/more/command.rb: > > $strderr << "Nothing to do." > > -g. > > --http://blog.gmosx.comhttp://cull.grhttp://www.joy.grhttp://nitroproject.org > > _______________________________________________ > Nitro-general mailing list > Nitro-gene... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Tue Feb 20 10:48:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 20 Feb 2007 17:48:18 +0200 Subject: [Nitro] Facets command bug In-Reply-To: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> References: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> Message-ID: 1.8.49.... hey you are releasing new versions daily? ;-) -g. On 2/20/07, transfire at gmail.com wrote: > > Hi-- > > Is this from the latest 1.8.51? > > ~t. > > On Feb 20, 5:25 am, "George Moschovitis" > wrote: > > Tom, > > > > there is a typo in facets/more/command.rb: > > > > $strderr << "Nothing to do." > > > > -g. > > > > -- > http://blog.gmosx.comhttp://cull.grhttp://www.joy.grhttp://nitroproject.org > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-gene... at rubyforge > .orghttp://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070220/7b547527/attachment.html From transfire at gmail.com Tue Feb 20 11:52:34 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 20 Feb 2007 16:52:34 -0000 Subject: [Nitro] Facets command bug In-Reply-To: References: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> Message-ID: <1171990354.347138.260070@t69g2000cwt.googlegroups.com> On Feb 20, 10:48 am, "George Moschovitis" wrote: > 1.8.49.... > > hey you are releasing new versions daily? ;-) You can thank Tyler Rick for this one. He's been doing some nice work on Facets and Ratchets. He made some great improvements/bug-fixes to command.rb which were worth the new release. Btw, I just set up a new google group for facets-universal. http://groups.google.com/group/facets-universal?hl=en I'm going to start using that list a lot more, because I want to start thinking about Facets 2.0+. So Nitro developers, please keep an eye on it. T. From john at oxyliquit.de Tue Feb 20 15:46:06 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 20 Feb 2007 21:46:06 +0100 Subject: [Nitro] Facets command bug In-Reply-To: <1171990354.347138.260070@t69g2000cwt.googlegroups.com> References: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> <1171990354.347138.260070@t69g2000cwt.googlegroups.com> Message-ID: Hi, > I'm going to start using that list a lot more, because I want to start > thinking about Facets 2.0+. So Nitro developers, please keep an eye on > it. this is facets-universal at rubyforge.org right? if yes, then I'm already 'connected' :P Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Tue Feb 20 17:58:45 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 20 Feb 2007 22:58:45 -0000 Subject: [Nitro] Facets command bug In-Reply-To: References: <1171984151.943034.294470@v45g2000cwv.googlegroups.com> <1171990354.347138.260070@t69g2000cwt.googlegroups.com> Message-ID: <1172012325.185480.171540@v33g2000cwv.googlegroups.com> On Feb 20, 3:46 pm, "Jonathan Buch" wrote: > Hi, > > > I'm going to start using that list a lot more, because I want to start > > thinking about Facets 2.0+. So Nitro developers, please keep an eye on > > it. > > this is facets-univer... at rubyforge.org right? if yes, then I'm already > 'connected' :P yes, one and the same. the google-group is just an interface-to/ archive-of the rubyforge list. T. From lasso at lassoweb.se Wed Feb 21 03:32:29 2007 From: lasso at lassoweb.se (Lars Olsson) Date: Wed, 21 Feb 2007 08:32:29 -0000 (UTC) Subject: [Nitro] Interesting web framework article Message-ID: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> Hi list! Christian Neukirchen has published an interesting web framework article at http://chneukirchen.org/blog/archive/2007/02/introducing-rack.html Perhaps his Rack project can be useful for Nitro too? Sincerely /lasso PS. Som lowlife has spammed nitroproject.org DS From george.moschovitis at gmail.com Wed Feb 21 04:32:16 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 21 Feb 2007 11:32:16 +0200 Subject: [Nitro] Interesting web framework article In-Reply-To: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> Message-ID: Hello, > Christian Neukirchen has published an interesting web framework article at > http://chneukirchen.org/blog/archive/2007/02/introducing-rack.html I have already seen this. I will consider using this with Nitro in the next few days... PS. Som lowlife has spammed nitroproject.org DS I will introduce a new nitroproject.org site where the homepage is not editable (for example through tags) -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070221/e5bcbb8b/attachment.html From john at oxyliquit.de Wed Feb 21 08:42:12 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 21 Feb 2007 14:42:12 +0100 Subject: [Nitro] Og, adapting postgresql to reorgnaization Message-ID: Hi, just trying to get postgresql and sqlite working fully with the reorganized Og by Judson Lester (I hope you read this). I've got it running so far, but hit a wall with overriding og_insert(). Postgresql needs differently ordered og_insert (first .last_insert_id and then .exec("INSERT") ) First I just overrode the original og_insert, psql works fine, all testcases go green. But this prevents different og_insert implementations for different stores. Now my question: how do we best provide a way (for store creators) to override specific functions? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From james.britt at gmail.com Wed Feb 21 11:01:06 2007 From: james.britt at gmail.com (James Britt) Date: Wed, 21 Feb 2007 09:01:06 -0700 Subject: [Nitro] Interesting web framework article In-Reply-To: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> Message-ID: <45DC6CC2.2030505@gmail.com> Lars Olsson wrote: > Hi list! > > Christian Neukirchen has published an interesting web framework article at > http://chneukirchen.org/blog/archive/2007/02/introducing-rack.html > Interesting. The problem I've run into with mixing up assorted framework parts is the conflict of libraries. For example, one *should* be able to use Rails view and controller parts with Og, but I've never gotten it to work. I think facets or glue get into arguments with ActiveSupport of actionpack or something. It would be nice if the Web end of stuff was abstracted from the app end of stuff, but then the app stuff needs be cleanly decomposable as well and each supporting library cleanly name-spaced, . -- James Britt "Design depends largely on constraints." - Charles Eames From lasso at lassoweb.se Wed Feb 21 11:35:28 2007 From: lasso at lassoweb.se (Lars Olsson) Date: Wed, 21 Feb 2007 16:35:28 -0000 (UTC) Subject: [Nitro] Interesting web framework article In-Reply-To: <45DC6CC2.2030505@gmail.com> References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> <45DC6CC2.2030505@gmail.com> Message-ID: <43579.192.176.230.1.1172075728.squirrel@webmaiil.lassoweb.se> Hi! The dynamic nature of ruby makes it extremely easy (perhaps too easy) to extend the core of the language. Both rails and nitro extends things like String, Array and even Object. That makes it quite difficult to get some libs to get along. I sometimes wonder why inheritance/namespaces isn't used in ruby more often to avoid these kinds of clashes. Even though the syntax gets a little ugly, you don't 'taint' the core classes with you super extra cool functionality. Silly example: module Foo class Bar < String def revup self.reverse.upcase end end end include Foo baz = Bar.new("one two three") p baz.revup which gets us: "EERHT OWT ENO" The syntax is a litte ugly, but our Strings are safe. Compare this to: class String def revup self.reverse.upcase end end baz = "one two three" p baz.revup which is only good if we want *all* strings to have this method. But how often is that kind of method *really* what we need? Sincerely /lasso > Interesting. > > > The problem I've run into with mixing up assorted framework parts is the > conflict of libraries. For example, one *should* be able to use Rails view > and controller parts with Og, but I've never gotten it to work. I think > facets or glue get into arguments with ActiveSupport of actionpack or > something. > > It would be nice if the Web end of stuff was abstracted from the app end > of stuff, but then the app stuff needs be cleanly decomposable as well and > each supporting library cleanly name-spaced, . > > > -- > James Britt > > > "Design depends largely on constraints." > - Charles Eames > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From wyhaines at gmail.com Wed Feb 21 11:47:42 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 21 Feb 2007 09:47:42 -0700 Subject: [Nitro] Interesting web framework article In-Reply-To: <45DC6CC2.2030505@gmail.com> References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> <45DC6CC2.2030505@gmail.com> Message-ID: On 2/21/07, James Britt wrote: > The problem I've run into with mixing up assorted framework parts is the > conflict of libraries. For example, one *should* be able to use Rails > view and controller parts with Og, but I've never gotten it to work. I > think facets or glue get into arguments with ActiveSupport of actionpack > or something. Chris and I discussed that issue. It's a framework implementation thing, though, and doesn't necessarily negate his point, which is that if one has nicely behaved code that respects namespaces, rack makes it easier to have one process handling more than one framework. I think this is only a small point in favor or rack, though. I don't think that use case is particularly common, unlike your use case. I think a lot of people would love to mix and match Og/Rails or AR/Nitro. > It would be nice if the Web end of stuff was abstracted from the app end > of stuff, but then the app stuff needs be cleanly decomposable as well > and each supporting library cleanly name-spaced, . The name spacing issues are big ones, and I think this will remain an issue for any Nitro/Rails component interactions, since Rails doesn't respect namespaces, and Nitro, by depending on Facets, doesn't really, either. On the larger issue of the benefits of rack, though, I have been wrestling with that. I think the benefits are minimal for an existing framework like Nitro or IOWA or Rails, where everything that rack is doing, the establish frameworks already have established mechanisms for handling. Nitro already has a well defined way of representing requests. IOWA already has an established API for responses. Rails already has standards in place for how logging is handled. So, supporting rack means either changing these well defined things, or adding some sort of compatibility layer, which in turn adds a layer of indirection and inefficiency to the code. IOWA's run mode support is very modular, so I am planning on supporting rack in exactly the same way that I support other run modes, and I'll take a wait and see approach. If people start developing useful functionality that uses the rack API. that will be usable without me having to change my internals. There isn't much risk to this approach, and IMHO, it is one that I think George should consider for Nitro. One thing that I have wondered about is if two frameworks, for example IOWA and Nitro, both supported using the rack request/response model, if it would be easier to write reusable widgets that worked for both frameworks? Kirk Haines From wyhaines at gmail.com Wed Feb 21 11:58:49 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 21 Feb 2007 09:58:49 -0700 Subject: [Nitro] Interesting web framework article In-Reply-To: <43579.192.176.230.1.1172075728.squirrel@webmaiil.lassoweb.se> References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> <45DC6CC2.2030505@gmail.com> <43579.192.176.230.1.1172075728.squirrel@webmaiil.lassoweb.se> Message-ID: On 2/21/07, Lars Olsson wrote: > The dynamic nature of ruby makes it extremely easy (perhaps too easy) to > extend the core of the language. Both rails and nitro extends things like > String, Array and even Object. That makes it quite difficult to get some > libs to get along. > > I sometimes wonder why inheritance/namespaces isn't used in ruby more > often to avoid these kinds of clashes. Even though the syntax gets a > little ugly, you don't 'taint' the core classes with you super extra cool > functionality. It's a design choice. If you are Rails, you have made the decision that you own the world, and you don't want it to be easy for non-rails things to play in that world. So, messing with the core of the language makes perfect sense, and as you point out, there is some simplicity and elegance of code gained by this decision. If you are Nitro, you want to leverage Facets because it dramatically reduces the amount of code in Nitro itself to do so. Facets, however, by definition, extends the core classes as well because that IS elegant so long as it doesn't walk all over something else. It's a perfectly reasonable design decision, but there are consequences. The end result is that without a major change in design choices, some frameworks, like Nitro and Rails, are going to continue to have interoperability problems. Whether that's a significant issue or not, though, is open for argument. I think it probably reduces the number of users of Og, but I am less certain that the inability to use AR with Nitro affects Nitro's adoption overmuch. Kirk Haines From nyarly at gmail.com Wed Feb 21 13:49:04 2007 From: nyarly at gmail.com (Judson Lester) Date: Wed, 21 Feb 2007 10:49:04 -0800 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: References: Message-ID: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> I just sent George a patch to fix that issue. Basically, the SQL for inserts and updates is pulled out to a method in SqlStore, so that Postgres overrides that. As a sidenote, I altered the last_insert_id so that it returns currval(#{seq}) and explicitly put a nextval() in the insert_sql method. Which looks right to me... Judson On 2/21/07, Jonathan Buch wrote: > Hi, > > just trying to get postgresql and sqlite working fully with the > reorganized Og by Judson Lester (I hope you read this). > > I've got it running so far, but hit a wall with overriding og_insert(). > > Postgresql needs differently ordered og_insert (first > .last_insert_id and then .exec("INSERT") ) > > First I just overrode the original og_insert, psql works fine, all > testcases go green. > > But this prevents different og_insert implementations for different > stores. Now my question: how do we best provide a way (for store > creators) to override specific functions? > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Wed Feb 21 15:06:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 21 Feb 2007 22:06:36 +0200 Subject: [Nitro] Interesting web framework article In-Reply-To: References: <39131.192.176.230.1.1172046749.squirrel@webmail.lassoweb.se> <45DC6CC2.2030505@gmail.com> <43579.192.176.230.1.1172075728.squirrel@webmaiil.lassoweb.se> Message-ID: I agree, Rack seems to reimplement a lot of stuff that nitro already does. However, as I would like to minimize the code that I have to maintain, I will consider this again in the near future (in March). There are some more important changes to be done at the moment. I would like to finish with my changes on Nitro to work a bit on Og. regards, George. On 2/21/07, Kirk Haines wrote: > > On 2/21/07, Lars Olsson wrote: > > > The dynamic nature of ruby makes it extremely easy (perhaps too easy) to > > extend the core of the language. Both rails and nitro extends things > like > > String, Array and even Object. That makes it quite difficult to get some > > libs to get along. > > > > I sometimes wonder why inheritance/namespaces isn't used in ruby more > > often to avoid these kinds of clashes. Even though the syntax gets a > > little ugly, you don't 'taint' the core classes with you super extra > cool > > functionality. > > It's a design choice. > > If you are Rails, you have made the decision that you own the world, > and you don't want it to be easy for non-rails things to play in that > world. So, messing with the core of the language makes perfect sense, > and as you point out, there is some simplicity and elegance of code > gained by this decision. > > If you are Nitro, you want to leverage Facets because it dramatically > reduces the amount of code in Nitro itself to do so. Facets, however, > by definition, extends the core classes as well because that IS > elegant so long as it doesn't walk all over something else. It's a > perfectly reasonable design decision, but there are consequences. > > The end result is that without a major change in design choices, some > frameworks, like Nitro and Rails, are going to continue to have > interoperability problems. Whether that's a significant issue or not, > though, is open for argument. I think it probably reduces the number > of users of Og, but I am less certain that the inability to use AR > with Nitro affects Nitro's adoption overmuch. > > > Kirk Haines > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070221/4e9d4ab2/attachment.html From john at oxyliquit.de Wed Feb 21 17:41:17 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 21 Feb 2007 23:41:17 +0100 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> Message-ID: Hi, > I just sent George a patch to fix that issue. Basically, the SQL for > inserts and updates is pulled out to a method in SqlStore, so that > Postgres overrides that. only the sql? No way to override the implementation itself to provide more flexibility? > As a sidenote, I altered the last_insert_id so that it returns > currval(#{seq}) and explicitly put a nextval() in the insert_sql > method. Which looks right to me... Which has the (assumed) disadvantage of not being 'thread safe'. Assume 2 connections to the database, inserting into the same table. When those inserts happen too close to each other it may be that the currval() returns the wrong value. I see the same problem with the mysql adapter. Is this a non-issue? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From nyarly at gmail.com Wed Feb 21 19:33:28 2007 From: nyarly at gmail.com (Judson Lester) Date: Wed, 21 Feb 2007 16:33:28 -0800 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> Message-ID: <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> On 2/21/07, Jonathan Buch wrote: > Hi, > > > I just sent George a patch to fix that issue. Basically, the SQL for > > inserts and updates is pulled out to a method in SqlStore, so that > > Postgres overrides that. > > only the sql? No way to override the implementation itself to provide > more flexibility? If'n you want to, you can override og_insert, og_update, og_delete, or og_read (not entirely sure off the top of my head why that's not og_select...) and change their behavior entirely. But for MySQL the only tweak is to writing one type, and Postgres needs insert_sql updated. Why autoincrements weren't part of the original spec, I'll never know. > > As a sidenote, I altered the last_insert_id so that it returns > > currval(#{seq}) and explicitly put a nextval() in the insert_sql > > method. Which looks right to me... > > Which has the (assumed) disadvantage of not being 'thread safe'. > > Assume 2 connections to the database, inserting into the same table. > When those inserts happen too close to each other it may be that > the currval() returns the wrong value. I see the same problem with > the mysql adapter. Is this a non-issue? No - that's an issue across the board, regardless of ORM. My thought would be, on the DBs that support it, to wrap inserts in a transaction, so that the currval/nextval (because the same thread-safe issue applies to nextval) is consistent with the insert. Alternatively, we could push the pk setting into insert_sql and use the value calculated for the insert as the @pk value. Sadly, I think both of those solutions would work for postgres and neither necessarily for MySQL. Judson From george.moschovitis at gmail.com Thu Feb 22 04:53:59 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 22 Feb 2007 11:53:59 +0200 Subject: [Nitro] Aspects Message-ID: Dear devs, I pushed the psql patch to the repo. But please keep in mind that the repo version now uses a new aspects implementation that it still under construction. I am still working on this with Tom. -g. PS: I am still wondering if anyone has any comments regarding my changes in the directory structure etc... -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070222/c48cabdb/attachment.html From john at oxyliquit.de Thu Feb 22 08:50:05 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 22 Feb 2007 14:50:05 +0100 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> Message-ID: Hi, > If'n you want to, you can override og_insert, og_update, og_delete, or > og_read (not entirely sure off the top of my head why that's not > og_select...) and change their behavior entirely. Yeah, but overriding it entirely is not an option here since it'd conflict with the mysql version... (If I'm getting you right here, I'm better in reading code :P) > But for MySQL the > only tweak is to writing one type, and Postgres needs insert_sql > updated. Why autoincrements weren't part of the original spec, I'll > never know. [I guess need to have a look at that code to understand that part.] > No - that's an issue across the board, regardless of ORM. Allright, so I got this one right at least. :) > My thought > would be, on the DBs that support it, to wrap inserts in a > transaction, so that the currval/nextval (because the same thread-safe > issue applies to nextval) is consistent with the insert. I would like to stay with the current psql implementation (first nextval() then just use that value). I don't see a reason to misuse a transaction for that, as it'll make 4 instead of 2 'instructions'. > Alternatively, we could push the pk setting into insert_sql and use > the value calculated for the insert as the @pk value. Sadly, I think > both of those solutions would work for postgres and neither > necessarily for MySQL. I'm not sure we can make MySQL thread safe (as I think the standard table type doesn't react on 'transaction' anyway). Maybe we put a ruby-level synchronized around that part? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Thu Feb 22 13:11:24 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 22 Feb 2007 18:11:24 -0000 Subject: [Nitro] Aspects In-Reply-To: References: Message-ID: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> On Feb 22, 4:53 am, "George Moschovitis" wrote: > Dear devs, > > I pushed the psql patch to the repo. But please keep in mind that the repo > version now uses a new aspects implementation that it still under > construction. I am still working on this with Tom. I've taken a look at the latest aspects.rb you sent me. I realize my version was over barring in that it added special callbacks to every method created --and the callbacks themsevles needed efficiency improvements. But your version has functinal issues. For starters an initialize method in a mixin is way too fragile. But most importantly, having to depend on a setup call to do the wrapping is too unreliable. As a generic tool it would mean having to call that method when ever there's a chance that some new aspect may get called --and that's a very slow and inefficent process. The problem I think in general is that you are just writting this to be good enough for your Nitro/Og apps. But I have to think about it in terms of a general purpose tool. Thankfully, with a little patience, I know we can find a solution that satisfies both our criteria. Also, it may be a good topic to bring up on ruby-talk to see what insights others might offer. For anyone else reading this not familiar with aspects.rb and wondering what we're talking about, the basic question is this: before :some_method, :do_this_method after :some_method, :do_this_method The interface is a little more complicated than this, but that the basic idea. It's just way to add method intercepts before or after some method(s). The hardest part is being able to define these intercepts for methods that may not even exist yet --so "aspects" can be modular. (aspects.rb doesn't seem like the best name for this lib, btw, since by definition aspects are like modules; intercepts.rb would be better considering what this lib does, but that's an aside issue at this point.) T. From transfire at gmail.com Thu Feb 22 13:32:27 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Thu, 22 Feb 2007 18:32:27 -0000 Subject: [Nitro] New layout Message-ID: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> > PS: I am still wondering if anyone has any comments regarding my changes in > the directory structure etc... Well, I don't get it. Now we have another project called 'raw' along side 'nitro' and 'og', not to metion 'glue'. In the last discussion of this it sounded like you were going to move all of nitro to this subproject (ie. 'raw') and nitro would just a parent project. But from the looks of the code 'nitro' is a another subproject too. It doesn't make any sense to me. Can I use 'raw' by itself? Or does it represent a plugin to nitro, where by other plugins might be substitued? Also, why the name 'raw'? While we're on the subject --I don't understand what's gogin on with glue. We've all agreed to get rid of it more than a year ago, and yet glue is still here. In fact it's in some sense worse b/c glue as a project is still here, plus glue lib directories exit in both nitro and og (and now raw). While perhaps a step in the right direction, that's not getting rid of glue, that just masking it in other projects. So *please*, could you do this: anything in a glue/ subdir, move some where under og/ or nitro/ (or raw/), depending on what uses it. So ther should be no more glue libs _at all_. If there is a glue lib that is used by both Og and Nitro (or Raw) then let me know and probably we can put it in Facets. If for some reason we can't put it in Facets, then we either need to make it more generic so it can be (and I'm willing to temporariary let that go, if we just make plans to generic-ize a lib in the future); or we should consider why the lib is needed by both Nitro and Og and yet is not general --is the lib is truly needed?; or, worse case senario, have one version for Nitro and one Version for Og (I suspect this will never happen, but it's an okay last resort, espeically if it's a temporary measure). T. From nyarly at gmail.com Thu Feb 22 14:29:38 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 22 Feb 2007 11:29:38 -0800 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> Message-ID: <8905c87a0702221129h3a415862i5051566191411f0@mail.gmail.com> On 2/22/07, Jonathan Buch wrote: > I'm not sure we can make MySQL thread safe (as I think the standard table > type doesn't react on 'transaction' anyway). Maybe we put a ruby-level > synchronized around that part? Trouble is, when you have a db involved, process level locks aren't really enough. Slows down execution without real benefit. This is why MySQL's eternal claim that transactions were unnecessary has always galled me. Judson From nyarly at gmail.com Thu Feb 22 15:58:23 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 22 Feb 2007 12:58:23 -0800 Subject: [Nitro] Specs? Message-ID: <8905c87a0702221258i3e1faf2ex7de05ce5ba7e7f43@mail.gmail.com> I noticed in my most recent pull that you've added some rspec to nitro, George. Not to rag on Test::Unit, but I'd love to see rspec take over that role for the project - especially Og. Judson From john at oxyliquit.de Thu Feb 22 17:10:21 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 22 Feb 2007 23:10:21 +0100 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: <8905c87a0702221129h3a415862i5051566191411f0@mail.gmail.com> References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> <8905c87a0702221129h3a415862i5051566191411f0@mail.gmail.com> Message-ID: Hi, >> I'm not sure we can make MySQL thread safe (as I think the standard table >> type doesn't react on 'transaction' anyway). Maybe we put a ruby-level >> synchronized around that part? > > Trouble is, when you have a db involved, process level locks aren't > really enough. Slows down execution without real benefit. This is why > MySQL's eternal claim that transactions were unnecessary has always > galled me. I read this as: "Lets just leave mysql and it's users alone" ;D Allright, I would be happy if you could find a way to make changes so we get the old behaviour for psql again, making psql the 'premier' choice again. ;) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Thu Feb 22 20:01:36 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 23 Feb 2007 01:01:36 -0000 Subject: [Nitro] Aspects In-Reply-To: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> Message-ID: <1172192496.349441.281350@l53g2000cwa.googlegroups.com> On Feb 22, 1:11 pm, transf... at gmail.com wrote: > (aspects.rb doesn't seem like the best name for this lib, btw, since > by definition aspects are like modules; intercepts.rb would be better > considering what this lib does, but that's an aside issue at this > point.) I've reconsidered this. I think you're right, aspects.rb is okay -- just as long as it's a fully functional and robust system. T. From transfire at gmail.com Thu Feb 22 23:48:20 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Fri, 23 Feb 2007 04:48:20 -0000 Subject: [Nitro] Aspects In-Reply-To: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> Message-ID: <1172206100.888512.53690@k78g2000cwa.googlegroups.com> On Feb 22, 1:11 pm, transf... at gmail.com wrote: > improvements. But your version has functinal issues. For starters an > initialize method in a mixin is way too fragile. Doh. I misread the code there. Sorry, ignore that one. T. From Reid.Thompson at ateb.com Fri Feb 23 11:33:08 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Fri, 23 Feb 2007 11:33:08 -0500 Subject: [Nitro] Has anyone written an Og/PostgreSQL script that will reverse generate classes from an existing DB or table? Message-ID: <1172248388.6871.16.camel@localhost> From george.moschovitis at gmail.com Fri Feb 23 13:48:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 23 Feb 2007 20:48:21 +0200 Subject: [Nitro] Specs? In-Reply-To: <8905c87a0702221258i3e1faf2ex7de05ce5ba7e7f43@mail.gmail.com> References: <8905c87a0702221258i3e1faf2ex7de05ce5ba7e7f43@mail.gmail.com> Message-ID: Yeah this is the plan. The winning feature is this: spec * -f s documents nicelly nitro's internals. -g. On 2/22/07, Judson Lester wrote: > > I noticed in my most recent pull that you've added some rspec to > nitro, George. Not to rag on Test::Unit, but I'd love to see rspec > take over that role for the project - especially Og. > > Judson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070223/5a41910f/attachment.html From george.moschovitis at gmail.com Fri Feb 23 13:55:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 23 Feb 2007 20:55:46 +0200 Subject: [Nitro] New layout In-Reply-To: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> References: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> Message-ID: > > Well, I don't get it. Now we have another project called 'raw' along > side 'nitro' and 'og', not to metion 'glue'. Glue will go away in 0.50. I am removing files from glue these days. But I need you to add glue/cache to facets. Cache is used by both nitro/raw and og so I cannot move this to either directory. As I hace explained raw (Ruby Apps for Web) contains the low level http and Controller/View part of nitro. To make it clear: Nitro <-> Raw ~~~ Rails <-> ActionPack. this new directory allows to separate code like bin/nitro, part/* etc from the low level web stuff. Btw, Raw is not the final name. This is why I have only chnaged the directory name and not all the requires. So if you have a better suggestion let me know. > and og (and now raw). While perhaps a step in the right direction, these directories will be renamed. I just have not found the proper place a name for these dirs. Will happen before the next releas though. So I can assure you that Glue is about to go. Btw, I would like to hear your thoughts on the reorganization inside raw/lib/nitro -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070223/ae5eda62/attachment.html From nyarly at gmail.com Fri Feb 23 14:28:37 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 23 Feb 2007 11:28:37 -0800 Subject: [Nitro] Og, adapting postgresql to reorgnaization In-Reply-To: References: <8905c87a0702211049x7c4f4795mceb0e5fef8dfab72@mail.gmail.com> <8905c87a0702211633y39bbefb6icb6da828ca7dea5e@mail.gmail.com> <8905c87a0702221129h3a415862i5051566191411f0@mail.gmail.com> Message-ID: <8905c87a0702231128x70dd1f5di8794dc6a2a7d72c0@mail.gmail.com> It shouldn't be too hard. I'm in the midst of a patch, but when I get it done, I'll tweak that in. Judson On 2/22/07, Jonathan Buch wrote: > Hi, > > >> I'm not sure we can make MySQL thread safe (as I think the standard table > >> type doesn't react on 'transaction' anyway). Maybe we put a ruby-level > >> synchronized around that part? > > > > Trouble is, when you have a db involved, process level locks aren't > > really enough. Slows down execution without real benefit. This is why > > MySQL's eternal claim that transactions were unnecessary has always > > galled me. > > I read this as: "Lets just leave mysql and it's users alone" ;D > > Allright, I would be happy if you could find a way to make changes so we > get the old behaviour for psql again, making psql the 'premier' choice > again. ;) > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Fri Feb 23 15:03:06 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 23 Feb 2007 22:03:06 +0200 Subject: [Nitro] Aspects In-Reply-To: <1172206100.888512.53690@k78g2000cwa.googlegroups.com> References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> <1172206100.888512.53690@k78g2000cwa.googlegroups.com> Message-ID: I 'll have a look at your latest changes and get back on you for this. -g. On 2/23/07, transfire at gmail.com wrote: > > > > On Feb 22, 1:11 pm, transf... at gmail.com wrote: > > > improvements. But your version has functinal issues. For starters an > > initialize method in a mixin is way too fragile. > > Doh. I misread the code there. Sorry, ignore that one. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070223/b2bd6f29/attachment-0001.html From george.moschovitis at gmail.com Fri Feb 23 16:30:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 23 Feb 2007 23:30:40 +0200 Subject: [Nitro] Nitro's RDoc. Message-ID: Dear devs, I created an automatic script that creates RDoc docs from Nitro and pushes the files to: http://nitroproject.org/doc/index.html If anyone can show me how to use a better template with RDoc I would appreciate it. The Rdocs are quite unorganized at the moment, but I will improve them as a continue my work in cleaning up Nitro. I put the docs online to (hopefully) make it easier to more people to follow the progress... regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070223/737d7f8b/attachment.html From john at oxyliquit.de Fri Feb 23 17:46:46 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 23 Feb 2007 23:46:46 +0100 Subject: [Nitro] Has anyone written an Og/PostgreSQL script that will reverse generate classes from an existing DB or table? In-Reply-To: <1172248388.6871.16.camel@localhost> References: <1172248388.6871.16.camel@localhost> Message-ID: Hi, actually no, but I scratched something together in a few minutes for you. :) http://pastie.caboo.se/42556 Maybe you can get some ideas from that, one could for example also get relations etc... (sometimes I'm glad that one can use pure sql to get to that stuff in psql :P) Anyway when you like it just take it, when it's too limited (which it is) maybe we can make it more featureful. :) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From reid.thompson at ateb.com Sat Feb 24 20:35:12 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Sat, 24 Feb 2007 20:35:12 -0500 Subject: [Nitro] Has anyone written an Og/PostgreSQL script that will reverse generate classes from an existing DB or table? In-Reply-To: References: <1172248388.6871.16.camel@localhost> Message-ID: <20070225013512.GA8499@shienar> On 23:46 Fri 23 Feb , Jonathan Buch wrote: > Hi, > > actually no, but I scratched something together in a few minutes > for you. :) > > http://pastie.caboo.se/42556 > > Maybe you can get some ideas from that, one could for example also > get relations etc... (sometimes I'm glad that one can use pure sql > to get to that stuff in psql :P) > > Anyway when you like it just take it, when it's too limited (which it is) > maybe we can make it more featureful. :) > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png Very cool -- thanks much. I'll try to find some time to work this into my scripting at work Monday. reid From transfire at gmail.com Fri Feb 23 20:48:30 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 24 Feb 2007 01:48:30 -0000 Subject: [Nitro] New layout In-Reply-To: References: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> Message-ID: <1172281710.083807.272490@v33g2000cwv.googlegroups.com> On Feb 23, 1:55 pm, "George Moschovitis" wrote: > > Well, I don't get it. Now we have another project called 'raw' along > > side 'nitro' and 'og', not to metion 'glue'. > > Glue will go away in 0.50. I am removing files from glue these days. But I > need you to add glue/cache to facets. Cache is used by both nitro/raw and og > so I cannot move this to either directory. > > As I hace explained raw (Ruby Apps for Web) contains the low level http and > Controller/View part of nitro. To make it clear: > > Nitro <-> Raw > > ~~~ > > Rails <-> ActionPack. > > this new directory allows to separate code like bin/nitro, part/* etc from > the low level web stuff. Btw, Raw is not the final name. This is why I have > only chnaged the directory name and not all the requires. So if you have a > better suggestion let me know. fraid i don't know much about the Rails <-> ActionPack distinction. so if "raw" is the low level web stiff, whats nitro now? > > and og (and now raw). While perhaps a step in the right direction, > > these directories will be renamed. I just have not found the proper place a > name for these dirs. Will happen before the next releas though. renamed? but under there respective dirs (nitro, og, raw) right? > So I can assure you that Glue is about to go. on that day, i dance! > Btw, I would like to hear your thoughts on the reorganization inside > raw/lib/nitro okay i'll analyze. -t From george.moschovitis at gmail.com Sat Feb 24 02:30:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 24 Feb 2007 09:30:38 +0200 Subject: [Nitro] New layout In-Reply-To: <1172281710.083807.272490@v33g2000cwv.googlegroups.com> References: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> <1172281710.083807.272490@v33g2000cwv.googlegroups.com> Message-ID: > > fraid i don't know much about the Rails <-> ActionPack distinction. so > if "raw" is the low level web stiff, whats nitro now? raw is what Nitro was. nitro now is just a super-framework, integrates raw, og, facets together. The nitro dir contains the proto dir, commands, utilities, configurations, docs etc. > > renamed? but under there respective dirs (nitro, og, raw) right? yeap. okay i'll analyze. thanks, -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070224/c584a016/attachment.html From george.moschovitis at gmail.com Sat Feb 24 03:29:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 24 Feb 2007 10:29:52 +0200 Subject: [Nitro] New layout In-Reply-To: <1172281710.083807.272490@v33g2000cwv.googlegroups.com> References: <1172169147.087378.268800@a75g2000cwd.googlegroups.com> <1172281710.083807.272490@v33g2000cwv.googlegroups.com> Message-ID: > > > So I can assure you that Glue is about to go. > > on that day, i dance! > > As I said, I need some help here: - move glue/cache to facets - help me use facets/builder instead of glue/builder hope you (or someone else) can find some time to help here. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070224/4aff7a75/attachment.html From george.moschovitis at gmail.com Sat Feb 24 04:44:19 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 24 Feb 2007 11:44:19 +0200 Subject: [Nitro] Og threaded mode leak. Message-ID: Dear devs, Jonathan told me on the #irc that he has found a memory leak when running Og in multithreaded mode (according to him this was an old bug, never fixed). I would like to ask Jonathan (or someone else) to explain this bug to me in detail so that I can fix it. thanks in advance, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070224/90b18cfa/attachment.html From john at oxyliquit.de Sat Feb 24 08:40:00 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 24 Feb 2007 14:40:00 +0100 Subject: [Nitro] Og threaded mode leak. In-Reply-To: References: Message-ID: Hi, > Jonathan told me on the #irc that he has found a memory leak when running Og > in multithreaded mode (according to him this was an old bug, never fixed). I > would like to ask Jonathan (or someone else) to explain this bug to me in > detail so that I can fix it. the code in question of manager.rb: def get_store: unless st = thread[:og_store] and st.is_a?(@store_class) if 0 == @pool.size initialize_store end st = @pool.pop thread[:og_store] = st end This reads 'get stores, if it's zero, just make new stores'. This is one part of the problem. The second part is, that when you remove that 'make indefinit stores' you get a second problem, which is 'stalling threads' because the og-stores are not being forced to return to the pool. The fix is to make get_store like this: def store yield get_store put_store end And always go through the block so the stores are returned at once so threads are not 'blocking the application to death'. Test case (original by [Alex], revised heavily by me) http://pastie.caboo.se/42635 What it does, is first creating 1500 entries in a table, and after that it tries (in 1500 threads) to pull those entries out again. It counts the errors it gets, which should be 0. The behaviour I'm getting with psql: "FATAL: sorry, too many clients already" (after configured limit of 50 concurrent connections) and 1453 failing threads. This is only a testcase, but have been getting that with oxyliquit as well, it just leaks stores. (try doing `ps ax | grep postgres`, it's funny :P) Alex originally had the problem with sqlite, that everything just broke down after a few threads more. This had to do with file-descriptors and that it openened the sqlite db too often. I originally didn't see the problem (because everything worked fine with psql). Now I know that there isn't a problem with FCGI (because it sets Og.thread_safe to false) and so doesn't use the pool at all. Alex made a patch once, implementing the idea above, only allowing access to the store via a block, so it always is returned. It sadly didn't get the attention it deserved (partly my fault). The changes to be done aren't really hard, there are just many of the .get_store and .store which all have to be wrapped. I hope that helps, Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Sat Feb 24 08:40:47 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sat, 24 Feb 2007 13:40:47 -0000 Subject: [Nitro] Aspects In-Reply-To: References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> <1172206100.888512.53690@k78g2000cwa.googlegroups.com> Message-ID: <1172324447.222639.21980@j27g2000cwj.googlegroups.com> Playing around some. You might find this interesting: class Class alias :create :new def new(*a,&b) obj = allocate obj.extend advice obj.send(:initialize,*a,&b) return obj end end class Module def advice(&block) @advice ||= Advice.new(self) @advice.module_eval(&block) if block @advice end end class Advice < Module class << self alias :new :create end def initialize(base) base.ancestors[1..-1].reverse.each do |anc| include anc.advice end end end # example class X def y "y" end advice do def y '{' + super + '}' end end end class Z < X def y super + "!" end advice do def y '[' + super + ']' end end end puts X.new.y puts Z.new.y From john at oxyliquit.de Sat Feb 24 16:37:21 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 24 Feb 2007 22:37:21 +0100 Subject: [Nitro] Aspects In-Reply-To: <1172324447.222639.21980@j27g2000cwj.googlegroups.com> References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> <1172206100.888512.53690@k78g2000cwa.googlegroups.com> <1172324447.222639.21980@j27g2000cwj.googlegroups.com> Message-ID: Hi, > Playing around some. You might find this interesting: > puts X.new.y # => {y} > puts Z.new.y # => [{y!}] incredible! O.O Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From billk at cts.com Sat Feb 24 16:59:14 2007 From: billk at cts.com (Bill Kelly) Date: Sat, 24 Feb 2007 13:59:14 -0800 Subject: [Nitro] Og, serialized transactions? Message-ID: <019301c7585f$065241e0$6442a8c0@musicbox> From: "Judson Lester" > > On 2/22/07, Jonathan Buch wrote: > >> I'm not sure we can make MySQL thread safe (as I think the standard table >> type doesn't react on 'transaction' anyway). Maybe we put a ruby-level >> synchronized around that part? > > Trouble is, when you have a db involved, process level locks aren't > really enough. Slows down execution without real benefit. This is why > MySQL's eternal claim that transactions were unnecessary has always > galled me. Hi, On a related note, I'm wanting to use Og with postgres and have dozens of processes all interacting with the same database. If several processes all happened to do a find_or_create at the same time with the same name: playername = Playername.find_or_create_by_playername("fred") ...I'm concerned about how to eliminate the possibility of a race condition where I could end up with more than one "fred" player record being created. I haven't tried this yet, but I'm hoping something like the following would work: store = Playername.ogstore store.transaction { store.exec "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE" playername = Playername.find_or_create_by_playername("fred") } Am I on the right track here? (I presume I'll have to deal with catching an exception and retrying the transaction if it fails.) Thanks, Bill From nyarly at gmail.com Sat Feb 24 18:17:09 2007 From: nyarly at gmail.com (Judson Lester) Date: Sat, 24 Feb 2007 15:17:09 -0800 Subject: [Nitro] STI refactoring Message-ID: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> Attached find a bundle for a preliminary refactoing to pull the conditional behaviors across Og into simple method overrides in Og::SchemaInheritance. A little quicker, and cleaner code. Judson -------------- next part -------------- A non-text attachment was scrubbed... Name: sti-refactor.bundle Type: application/octet-stream Size: 27684 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070224/45b7bfb7/attachment-0001.obj From reid.thompson at ateb.com Sun Feb 25 19:42:48 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Sun, 25 Feb 2007 19:42:48 -0500 Subject: [Nitro] Og, serialized transactions? In-Reply-To: <019301c7585f$065241e0$6442a8c0@musicbox> References: <019301c7585f$065241e0$6442a8c0@musicbox> Message-ID: <20070226004247.GA17231@shienar> On 13:59 Sat 24 Feb , Bill Kelly wrote: > From: "Judson Lester" > > > > On 2/22/07, Jonathan Buch wrote: > > > >> I'm not sure we can make MySQL thread safe (as I think the standard table > >> type doesn't react on 'transaction' anyway). Maybe we put a ruby-level > >> synchronized around that part? > > > > Trouble is, when you have a db involved, process level locks aren't > > really enough. Slows down execution without real benefit. This is why > > MySQL's eternal claim that transactions were unnecessary has always > > galled me. > > Hi, > > On a related note, I'm wanting to use Og with postgres and > have dozens of processes all interacting with the same > database. > > If several processes all happened to do a find_or_create > at the same time with the same name: > > playername = Playername.find_or_create_by_playername("fred") > > ...I'm concerned about how to eliminate the possibility of > a race condition where I could end up with more than one > "fred" player record being created. > > I haven't tried this yet, but I'm hoping something like the > following would work: > > store = Playername.ogstore > store.transaction { > store.exec "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE" > playername = Playername.find_or_create_by_playername("fred") > } > > Am I on the right track here? (I presume I'll have to deal > with catching an exception and retrying the transaction if > it fails.) > > > Thanks, > > Bill > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general make playername unique - return an approprite response to the process that attempts to create a duplicate player, and handle it appropriately.l From billk at cts.com Sat Feb 24 20:59:24 2007 From: billk at cts.com (Bill Kelly) Date: Sat, 24 Feb 2007 17:59:24 -0800 Subject: [Nitro] Og, serialized transactions? References: <019301c7585f$065241e0$6442a8c0@musicbox> <20070226004247.GA17231@shienar> Message-ID: <01e701c75880$934b9210$6442a8c0@musicbox> From: "Reid Thompson" > On 13:59 Sat 24 Feb , Bill Kelly wrote: >> >> If several processes all happened to do a find_or_create >> at the same time with the same name: >> >> playername = Playername.find_or_create_by_playername("fred") >> >> ...I'm concerned about how to eliminate the possibility of >> a race condition where I could end up with more than one >> "fred" player record being created. > > make playername unique - return an approprite response to the process > that attempts to create a duplicate player, and handle it > appropriately. Ah. Makes sense. But I wonder how the error will be reported? I suppose find_or_create might raise an exception? Or maybe the exception could happen when my transaction commits? (I looked at how find_or_create_by_ works... very ingenious use of split and zip... :) Regarding the use of "unique", I also have a more complex scenario, which would require a multi-column unique constraint: class PlayerSeen property :first_seen, Time property :last_seen, Time property :times_seen, Integer refers_to :iphost, IPHost # \ refers_to :playername, Playername # - multi-column unique refers_to :servername, Servername # / end playerseen = PlayerSeen.find_or_create_by_iphost_oid_and_playername_oid_and_servername_oid(iphost.oid, playername.oid, servername.oid) E.g. CREATE UNIQUE INDEX playerseen_unique ON PlayerSeen.table_name (iphost_oid, playername_oid, servername_oid); Is it possible to specify a multi-column unique constraint in Og? Thanks, Bill From t_leitner at gmx.at Sun Feb 25 02:07:06 2007 From: t_leitner at gmx.at (Thomas Leitner) Date: Sun, 25 Feb 2007 08:07:06 +0100 Subject: [Nitro] SVK instead of darcs? Message-ID: <20070225080706.573a3519@localhost> Hi all, some time ago under the title "Nitro Development" there was a discussion about moving from darcs to another revision control system. I don't want to heat the discussion up again if everything's fine now with darcs. However, I came across SVK recently and took a few hours at looking at it and I have to say: it really rocks! First of all: after seeing this 'big picture' I was sold ;) http://perlcabal.org/~audreyt/svk-overview.png As one can see from the diagram, it would be possible to set up a central master subversion repository. People with submit privileges could then directly check in using a normal subversion client (however, they have to be online). People using SVK would have the possiblity to mirror the central repository locally, create a development branch, commit to this branch offline as often as they like and then push the changes to upstream master repository when they are online and have commit privileges or create a patch against the master repository which could be sent to a core developer for commiting. Also, merging should be fairly good as SVK implements the star merge algorithm. The main benefits I see for using SVK are: * distributed (core developers could have local development repository) * can use a SVN repository as master repository (most people can then easily download and use the edge version of nitro) * people can either use SVN or SVK to work with it (better community acceptance) * import of DARCS repository possible (http://svk.bestpractical.com/view/ImportingDarcsRepos) * good merging capabilities (star merge algorithm) And last a quick start tutorial in three small parts: http://www.bieberlabs.com/wordpress/archives/2004/11/30/using-svk http://www.bieberlabs.com/wordpress/archives/2004/12/31/svk-distributed-version-control-part-ii http://www.bieberlabs.com/wordpress/archives/2005/01/08/svk-distributed-version-control-part-iii Bye, Thomas From john at oxyliquit.de Sun Feb 25 05:28:13 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 25 Feb 2007 11:28:13 +0100 Subject: [Nitro] Og, serialized transactions? In-Reply-To: <01e701c75880$934b9210$6442a8c0@musicbox> References: <019301c7585f$065241e0$6442a8c0@musicbox> <20070226004247.GA17231@shienar> <01e701c75880$934b9210$6442a8c0@musicbox> Message-ID: Hi, > playerseen = PlayerSeen.find_or_create_by_iphost_oid_and_playername_oid_and_servername_oid(iphost.oid, playername.oid, > servername.oid) > > > E.g. > > CREATE UNIQUE INDEX playerseen_unique ON PlayerSeen.table_name > (iphost_oid, playername_oid, servername_oid); > > > Is it possible to specify a multi-column unique constraint in Og? sadly no, I stumbled on that too. We need an interface to create arbitrary indices (which could be used by the join-table-creation too). Right now you can specify that index in sql and Og will not mess with it. George told me he'd revive the constraints for psql again (like in 0.31, foreign keys etc). So I hope he reads this here. Maybe those two parts can be 'integrated'? Ideas? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sun Feb 25 05:35:42 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 25 Feb 2007 11:35:42 +0100 Subject: [Nitro] STI refactoring In-Reply-To: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> References: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> Message-ID: Hi, > Attached find a bundle for a preliminary refactoing to pull the > conditional behaviors across Og into simple method overrides in > Og::SchemaInheritance. A little quicker, and cleaner code. if you continue like that, you're gonna be my new hero. O.O That STI stuff bugged me for a long time, I just didn't know how to make it go away..... Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sun Feb 25 11:32:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 18:32:33 +0200 Subject: [Nitro] Og threaded mode leak. In-Reply-To: References: Message-ID: Jonathan, thanks for the detailed description. I will have a look at this. Btw, the get_store method is altered, this is not my initial implementation. Nitro would restore the store after each request (the last command in the request handling loop in adapters). Some patch must have altered the code. In any case I will have a look at this. thanks, George. On 2/24/07, Jonathan Buch wrote: > > Hi, > > > Jonathan told me on the #irc that he has found a memory leak when > running Og > > in multithreaded mode (according to him this was an old bug, never > fixed). I > > would like to ask Jonathan (or someone else) to explain this bug to me > in > > detail so that I can fix it. > > > the code in question of manager.rb: > > def get_store: > > unless st = thread[:og_store] and st.is_a?(@store_class) > if 0 == @pool.size > initialize_store > end > st = @pool.pop > thread[:og_store] = st > end > > This reads 'get stores, if it's zero, just make new stores'. This is one > part of the problem. > The second part is, that when you remove that 'make indefinit stores' you > get a second problem, which is 'stalling threads' because the og-stores > are not being forced to return to the pool. > > The fix is to make get_store like this: > > def store > yield get_store > put_store > end > > And always go through the block so the stores are returned at once so > threads are not 'blocking the application to death'. > > Test case (original by [Alex], revised heavily by me) > http://pastie.caboo.se/42635 > > What it does, is first creating 1500 entries in a table, and after that > it tries (in 1500 threads) to pull those entries out again. It counts > the errors it gets, which should be 0. > > The behaviour I'm getting with psql: > "FATAL: sorry, too many clients already" (after configured limit of > 50 concurrent connections) and 1453 failing threads. This is only > a testcase, but have been getting that with oxyliquit as well, it just > leaks stores. (try doing `ps ax | grep postgres`, it's funny :P) > > Alex originally had the problem with sqlite, that everything just broke > down after a few threads more. This had to do with file-descriptors > and that it openened the sqlite db too often. I originally didn't see > the problem (because everything worked fine with psql). Now I know that > there isn't a problem with FCGI (because it sets Og.thread_safe to false) > and so doesn't use the pool at all. > > Alex made a patch once, implementing the idea above, only allowing > access to the store via a block, so it always is returned. It sadly > didn't get the attention it deserved (partly my fault). The changes > to be done aren't really hard, there are just many of the .get_store > and .store which all have to be wrapped. > > I hope that helps, > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/bdc8bb96/attachment.html From george.moschovitis at gmail.com Sun Feb 25 11:38:17 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 18:38:17 +0200 Subject: [Nitro] STI refactoring In-Reply-To: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> References: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> Message-ID: Thanks, I will review the code and consider it for immediate inclusion. -g. On 2/25/07, Judson Lester wrote: > > Attached find a bundle for a preliminary refactoing to pull the > conditional behaviors across Og into simple method overrides in > Og::SchemaInheritance. A little quicker, and cleaner code. > > Judson > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/f0f0ba8c/attachment.html From george.moschovitis at gmail.com Sun Feb 25 11:39:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 18:39:41 +0200 Subject: [Nitro] Aspects In-Reply-To: <1172324447.222639.21980@j27g2000cwj.googlegroups.com> References: <1172167884.394735.205000@k78g2000cwa.googlegroups.com> <1172206100.888512.53690@k78g2000cwa.googlegroups.com> <1172324447.222639.21980@j27g2000cwj.googlegroups.com> Message-ID: erm... please give me some time to ...comprehend this ;-) -g. On 2/24/07, transfire at gmail.com wrote: > > Playing around some. You might find this interesting: > > > class Class > > alias :create :new > > def new(*a,&b) > obj = allocate > obj.extend advice > obj.send(:initialize,*a,&b) > return obj > end > > end > > > class Module > > def advice(&block) > @advice ||= Advice.new(self) > @advice.module_eval(&block) if block > @advice > end > > end > > class Advice < Module > class << self > alias :new :create > end > > def initialize(base) > base.ancestors[1..-1].reverse.each do |anc| > include anc.advice > end > end > end > > > > # example > > > class X > def y > "y" > end > > advice do > def y > '{' + super + '}' > end > end > > end > > > class Z < X > > def y > super + "!" > end > > advice do > def y > '[' + super + ']' > end > end > > end > > puts X.new.y > puts Z.new.y > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/d24ed9d1/attachment-0001.html From george.moschovitis at gmail.com Sun Feb 25 12:12:05 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 19:12:05 +0200 Subject: [Nitro] SVK instead of darcs? In-Reply-To: <20070225080706.573a3519@localhost> References: <20070225080706.573a3519@localhost> Message-ID: Hello Thomas, this looks *very* nice. However, I would like to concentrate on releasing the vastly improved 0.50 version of Nitro/Og before considering a switch. thanks, George. On 2/25/07, Thomas Leitner wrote: > > Hi all, > > some time ago under the title "Nitro Development" there was a > discussion about moving from darcs to another revision control system. > I don't want to heat the discussion up again if everything's fine now > with darcs. > > However, I came across SVK recently and took a few hours at looking at > it and I have to say: it really rocks! > > First of all: after seeing this 'big picture' I was sold ;) > http://perlcabal.org/~audreyt/svk-overview.png > > As one can see from the diagram, it would be possible to set up a > central master subversion repository. People with submit privileges > could then directly check in using a normal subversion client (however, > they have to be online). People using SVK would have the possiblity to > mirror the central repository locally, create a development branch, > commit to this branch offline as often as they like and then push the > changes to upstream master repository when they are online and have > commit privileges or create a patch against the master repository which > could be sent to a core developer for commiting. Also, merging should > be fairly good as SVK implements the star merge algorithm. > > The main benefits I see for using SVK are: > * distributed (core developers could have local development repository) > * can use a SVN repository as master repository (most people can then > easily download and use the edge version of nitro) > * people can either use SVN or SVK to work with it (better community > acceptance) > * import of DARCS repository possible > (http://svk.bestpractical.com/view/ImportingDarcsRepos) > * good merging capabilities (star merge algorithm) > > And last a quick start tutorial in three small parts: > http://www.bieberlabs.com/wordpress/archives/2004/11/30/using-svk > > http://www.bieberlabs.com/wordpress/archives/2004/12/31/svk-distributed-version-control-part-ii > > http://www.bieberlabs.com/wordpress/archives/2005/01/08/svk-distributed-version-control-part-iii > > Bye, > Thomas > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/e4c07100/attachment.html From george.moschovitis at gmail.com Sun Feb 25 12:15:42 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 19:15:42 +0200 Subject: [Nitro] Raw Message-ID: Dear devs, as no-one suggested a better name I will stick with 'Raw' for the web sub-framework of nitro. The latest repo version has all the requires changed to point to raw (plus I removed the glue directories in nitro and og). regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/48a6e838/attachment.html From george.moschovitis at gmail.com Sun Feb 25 12:24:00 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 19:24:00 +0200 Subject: [Nitro] Glue -> Facets Message-ID: Tom, can you please move glue/cache glue/cache.rb glue/logger.rb glue/fixture.rb to facets? thanks, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/4e5b4689/attachment.html From john at oxyliquit.de Sun Feb 25 13:08:45 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 25 Feb 2007 19:08:45 +0100 Subject: [Nitro] Og threaded mode leak. In-Reply-To: References: Message-ID: Hi, > Jonathan, thanks for the detailed description. I will have a look at this. > Btw, the get_store method is altered, this is not my initial implementation. > Nitro would restore the store after each request (the last command in the > request handling loop in adapters). Some patch must have altered the code. > In any case I will have a look at this. yes, that code has been altered by me. Before it was impossible for more than one store to co-exist (I made some extensive tests back then). For example it put stores back into the wrong pool which took me a night to find that out. But I didn't alter the way it basically works, just the 'putting back'. The original 'strategy' is still what it was (unless I really made a mistake there o.O). Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Sun Feb 25 14:08:03 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 25 Feb 2007 19:08:03 -0000 Subject: [Nitro] Glue -> Facets In-Reply-To: References: Message-ID: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> On Feb 25, 12:24 pm, "George Moschovitis" wrote: > Tom, > > can you please move > > glue/cache > glue/cache.rb > glue/logger.rb > glue/fixture.rb > > to facets? Sure. Except for one problem... I'm neck deep in an attempt to improve the organization of Facets -- something I posted about on facets-universal. Unfortunately I havent gotten any input, and I am once again stuck in the thick of this. See, the really sucky problem is that Gems doesnt support subpackages like setup.rb does. So if I makes a subproject for all the more libs I will be left with some 70 gems. And the way gems handles dependecies --well who wants to type 'Y' for 70 dependencies? Now, I was planning to make a special packager that could bundle them all up in one package, but I run into the some of same problems I have now, specifically that the rdocs for each lib get mixed up with the others. And I can't do anything special about it because Gems generates the rdocs automatically on install. (To top it off, RubyGems just apdopted a new webpage that serves these generated rdocs online!). I mentioned the issue on the gem mailing list and was basically told it was my own stupid fault for organizing my project the way I had. Well that's just great! I have to choose between a huge number of dependencies or screwed up docs. unless someone has a bright idea.... T. From transfire at gmail.com Sun Feb 25 15:02:53 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 25 Feb 2007 20:02:53 -0000 Subject: [Nitro] Raw In-Reply-To: References: Message-ID: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> On Feb 25, 12:15 pm, "George Moschovitis" wrote: > Dear devs, > > as no-one suggested a better name I will stick with 'Raw' for the web > sub-framework of nitro. The latest repo version has all the requires changed > to point to raw (plus I removed the glue directories in nitro and og). The only thing I've come up with is something analogous to Og. Wf - Web Framework Ws - Web System Wc - Web Controller T. From george.moschovitis at gmail.com Sun Feb 25 15:14:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 25 Feb 2007 22:14:46 +0200 Subject: [Nitro] Glue -> Facets In-Reply-To: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> References: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> Message-ID: I think I have told you about this before: The current organization of facets is great. The only thing I would improve is to get to replace: facet/* facets/core/* facets/more/* with core/* more/* So I really would like to ask you to postpone the re-organization for a little bit. Move the aforementioned files to facets so I can get rid of Glue and both projects (Nitro and Facets) can move forward. What do you think? -g. On 2/25/07, transfire at gmail.com wrote: > > > > On Feb 25, 12:24 pm, "George Moschovitis" > wrote: > > Tom, > > > > can you please move > > > > glue/cache > > glue/cache.rb > > glue/logger.rb > > glue/fixture.rb > > > > to facets? > > Sure. Except for one problem... > > I'm neck deep in an attempt to improve the organization of Facets -- > something I posted about on facets-universal. Unfortunately I havent > gotten any input, and I am once again stuck in the thick of this. See, > the really sucky problem is that Gems doesnt support subpackages like > setup.rb does. So if I makes a subproject for all the more libs I will > be left with some 70 gems. And the way gems handles dependecies --well > who wants to type 'Y' for 70 dependencies? Now, I was planning to make > a special packager that could bundle them all up in one package, but I > run into the some of same problems I have now, specifically that the > rdocs for each lib get mixed up with the others. And I can't do > anything special about it because Gems generates the rdocs > automatically on install. (To top it off, RubyGems just apdopted a new > webpage that serves these generated rdocs online!). I mentioned the > issue on the gem mailing list and was basically told it was my own > stupid fault for organizing my project the way I had. Well that's just > great! I have to choose between a huge number of dependencies or > screwed up docs. > > unless someone has a bright idea.... > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/6cb116b0/attachment.html From vikingtux at gmail.com Sun Feb 25 15:41:58 2007 From: vikingtux at gmail.com (Alexandre Gravem) Date: Sun, 25 Feb 2007 17:41:58 -0300 Subject: [Nitro] Raw In-Reply-To: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> Message-ID: <40b05ebe0702251241tce80c81l6fc6d82abe8afd2@mail.gmail.com> I liked "Raw" - A. Gravem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070225/c2353cf3/attachment-0001.html From noe.rubinstein at gmail.com Sun Feb 25 15:51:14 2007 From: noe.rubinstein at gmail.com (=?UTF-8?Q?No=C3=A9_Rubinstein?=) Date: Sun, 25 Feb 2007 21:51:14 +0100 Subject: [Nitro] Raw In-Reply-To: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> Message-ID: I think Raw is an excellent name. It sounds like, wild and powerfull and all. Well, I love Lojbanic (http://en.wikipedia.org/wiki/Lojban - http://lojban.org ) names too. Things like "jongasn" (wich means "link maker"), "sjuzbas" (helping builder), "pojlik" (explosive liquid), but I guess it's not an option. No?. From james.britt at gmail.com Sun Feb 25 16:02:26 2007 From: james.britt at gmail.com (James Britt) Date: Sun, 25 Feb 2007 14:02:26 -0700 Subject: [Nitro] Raw In-Reply-To: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> Message-ID: <45E1F962.5040705@gmail.com> transfire at gmail.com wrote: > > On Feb 25, 12:15 pm, "George Moschovitis" > wrote: >> Dear devs, >> >> as no-one suggested a better name I will stick with 'Raw' for the web >> sub-framework of nitro. The latest repo version has all the requires changed >> to point to raw (plus I removed the glue directories in nitro and og). > > The only thing I've come up with is something analogous to Og. > > Wf - Web Framework > Ws - Web System > Wc - Web Controller No Wtf? To go with oxywtf? Web Transformation Framework -- James Britt "Every object obscures another object." - Luis Bunuel From transfire at gmail.com Sun Feb 25 16:34:15 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Sun, 25 Feb 2007 21:34:15 -0000 Subject: [Nitro] Raw In-Reply-To: <45E1F962.5040705@gmail.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> <45E1F962.5040705@gmail.com> Message-ID: <1172439255.331944.193030@j27g2000cwj.googlegroups.com> On Feb 25, 4:02 pm, James Britt wrote: > transf... at gmail.com wrote: > > > On Feb 25, 12:15 pm, "George Moschovitis" > > wrote: > >> Dear devs, > > >> as no-one suggested a better name I will stick with 'Raw' for the web > >> sub-framework of nitro. The latest repo version has all the requires changed > >> to point to raw (plus I removed the glue directories in nitro and og). > > > The only thing I've come up with is something analogous to Og. > > > Wf - Web Framework > > Ws - Web System > > Wc - Web Controller > > No Wtf? To go with oxywtf? > > Web Transformation Framework LOL :) From john at oxyliquit.de Sun Feb 25 16:49:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 25 Feb 2007 22:49:28 +0100 Subject: [Nitro] Raw In-Reply-To: <45E1F962.5040705@gmail.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> <45E1F962.5040705@gmail.com> Message-ID: Hi, > No Wtf? To go with oxywtf? > Web Transformation Framework I like it! ;D No, seriously, while I find 'Raw' not really 'saying something', I can't think of anything better. My vote would've been for staying with Nitro, but that vote is over already, so I won't argue. :P (As we had at least one rails person visiting #nitro who was quite confused about Nitro being both the web-framework and the 'name for whole project including Og'....) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sun Feb 25 16:58:55 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 25 Feb 2007 22:58:55 +0100 Subject: [Nitro] Glue -> Facets In-Reply-To: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> References: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> Message-ID: Hi, > Well that's just > great! I have to choose between a huge number of dependencies or > screwed up docs. > > unless someone has a bright idea.... no bright idea here, but I think broken docs on rubygems page are less disturbing than to type 'y' 70 times. I love the 'spotlight' idea on the facets page btw.... When you provide generated docs by yourself on rubyforge (in a better way than rubygems does), wouldn't that be ok? (big link on the first 'page' of the rubygems-generated rdocs to rubyforge) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sun Feb 25 18:03:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 01:03:41 +0200 Subject: [Nitro] Raw In-Reply-To: References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> Message-ID: As I said in the initial post, Raw is the final name (I didn't have any other suggestions in time). And I think it is better than Wtf and friends ;-) -f. On 2/25/07, No? Rubinstein wrote: > > I think Raw is an excellent name. It sounds like, wild and powerfull and > all. > Well, I love Lojbanic (http://en.wikipedia.org/wiki/Lojban - > http://lojban.org ) names too. Things like "jongasn" (wich means "link > maker"), "sjuzbas" (helping builder), "pojlik" (explosive liquid), but > I guess it's not an option. > > No?. > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070226/ca406d3a/attachment.html From billk at cts.com Sun Feb 25 22:14:05 2007 From: billk at cts.com (Bill Kelly) Date: Sun, 25 Feb 2007 19:14:05 -0800 Subject: [Nitro] Og, serialized transactions? References: <019301c7585f$065241e0$6442a8c0@musicbox><20070226004247.GA17231@shienar><01e701c75880$934b9210$6442a8c0@musicbox> Message-ID: <00d601c75954$2c336880$6442a8c0@musicbox> From: "Jonathan Buch" > >> >> E.g. >> >> CREATE UNIQUE INDEX playerseen_unique ON PlayerSeen.table_name >> (iphost_oid, playername_oid, servername_oid); >> >> >> Is it possible to specify a multi-column unique constraint in Og? > > sadly no, I stumbled on that too. We need an interface to create > arbitrary indices (which could be used by the join-table-creation > too). > > Right now you can specify that index in sql and Og will not mess > with it. Alrighty, thanks. Is there any sort of hook or callback that would tell me when the table is actually being created by Og, so that I could create the index at that point? Thanks, Bill From james.britt at gmail.com Mon Feb 26 00:16:55 2007 From: james.britt at gmail.com (James Britt) Date: Sun, 25 Feb 2007 22:16:55 -0700 Subject: [Nitro] Raw In-Reply-To: References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> <45E1F962.5040705@gmail.com> Message-ID: <45E26D47.9010707@gmail.com> Jonathan Buch wrote: > Hi, > >> No Wtf? To go with oxywtf? >> Web Transformation Framework > > I like it! ;D > > No, seriously, while I find 'Raw' not really 'saying something', > I can't think of anything better. > My vote would've been for staying with Nitro, but that vote is > over already, so I won't argue. :P (As we had at least one > rails person visiting #nitro who was quite confused about Nitro > being both the web-framework and the 'name for whole project > including Og'....) I like Nitro for its imagery. It conjures up speed and technology. Maybe better to rename the web-controller part and call the whole package Nitro. -- James Britt "I can see them saying something like 'OMG Three Wizards Awesome'" - billinboston, on reddit.com From t_leitner at gmx.at Mon Feb 26 02:07:03 2007 From: t_leitner at gmx.at (Thomas Leitner) Date: Mon, 26 Feb 2007 08:07:03 +0100 Subject: [Nitro] SVK instead of darcs? In-Reply-To: References: <20070225080706.573a3519@localhost> Message-ID: <20070226080703.523fef64@localhost> | this looks *very* nice. However, I would like to concentrate on | releasing the vastly improved 0.50 version of Nitro/Og before | considering a switch. Yeah, no hurry :) I just wanted to mention it since the last thread on RCS did not include any information about SVK and how it can be useful/used. Thomas From george.moschovitis at gmail.com Mon Feb 26 02:17:54 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 09:17:54 +0200 Subject: [Nitro] Raw In-Reply-To: <45E26D47.9010707@gmail.com> References: <1172433773.403549.15810@m58g2000cwm.googlegroups.com> <45E1F962.5040705@gmail.com> <45E26D47.9010707@gmail.com> Message-ID: > > > Maybe better to rename the web-controller part and call the whole > package Nitro. > Thats exactly what we have done. the whole package is still named nitro. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070226/8491b882/attachment.html From george.moschovitis at gmail.com Mon Feb 26 06:07:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 13:07:58 +0200 Subject: [Nitro] Og threaded mode leak. In-Reply-To: References: Message-ID: Ok Jonathan, I reimplemented Og's multithreaded strategy. It works more or less like you describe: manager.with_store do |s| s.xxxx end that handles the store management. Can you please try it with your test suite and let me know if the memory leak is gone? Even better it would be nice to have an RSpec for this bug. Have a look in raw/spec for details in how to organize your rspecs. thanks for your help, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Mon Feb 26 06:08:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 13:08:33 +0200 Subject: [Nitro] Og threaded mode leak. In-Reply-To: References: Message-ID: > I reimplemented Og's multithreaded strategy. It works more or less > like you describe... you can find the latest version, allong with juds sti patch in the repo. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Mon Feb 26 06:12:02 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 13:12:02 +0200 Subject: [Nitro] STI refactoring In-Reply-To: References: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> Message-ID: Judson, I added your patch to the repo. I noticed a lot of sti related code commented out throughout the source code. Can you please clean this up? thanks, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Mon Feb 26 12:11:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 26 Feb 2007 19:11:46 +0200 Subject: [Nitro] Dir structure Message-ID: Dear devs, in the older version of Nitro there used to be glue directories in og/lib/glue and nitro/lib/glue. In the process of getting rid glue I moved these directories to: og/lib/glue (namespace Glue::) -> og/lib/og/mixin (namespace Og::Mixin) nitro/lib/glue (namespace Glue::)-> raw/lib/raw/mixin (namespace Raw::Mixin) the modules Og::Mixin and Raw::Mixin are included in the top-level for extra convienience. I am not happy with having 2 directories. I would like to have all mixins to a single directory. Moreover, the controller helpers are in fact mixins (mixed in to controller classes, not model classes). Since these mixins are high level constructs that work on top of the lower level Og and Raw libraries, and I would like to integrate the model and controller mixins I have the following idea for better organization. Move these files in Nitro (the high level framework that uses the lower level Raw and Og libraries): model mixins go to: nitro/model/ for example nitro/model/timestamped nitro/model/webfile nitro/model/taggable nitro/model/orderable controller mixins go to: nitro/controller/ for example nitro/controller/pager nitro/controller/table nitro/controller/autologin etc... One drawback of this is that modules like optimistic_locking, hierarchical etc, that useful for Og users that are not Nitro users now would reside in the Nitro dir. Please, I would really like to hear your input here and your suggestions. regards, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Mon Feb 26 13:38:33 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 10:38:33 -0800 Subject: [Nitro] Glue -> Facets In-Reply-To: References: <1172430483.482558.109540@p10g2000cwp.googlegroups.com> Message-ID: <8905c87a0702261038j3a2ce545p207e3f3e071af8f9@mail.gmail.com> Tom, Have you seen gem-plugin? Essentially, you register plugin gems as depending on core gems, and whenever you include the core gem, gem-plugin will either autoload it, or let you know what you're missing. Seems a natural starting place, if nothing else, for facets. I feel your pain about gems and rdocs and monolithic facets, by the way. Judson From nyarly at gmail.com Mon Feb 26 13:42:00 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 10:42:00 -0800 Subject: [Nitro] STI refactoring In-Reply-To: References: <8905c87a0702241517t296ce01kffaead881f9177b1@mail.gmail.com> Message-ID: <8905c87a0702261042v2b23c10au93279d796557a906@mail.gmail.com> Sure thing. I'll pull it out in the next sweep for STI conditions. Judson On 2/26/07, George Moschovitis wrote: > Judson, > > I added your patch to the repo. I noticed a lot of sti related code > commented out throughout the source code. Can you please clean this > up? > > thanks, > George. > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From nyarly at gmail.com Mon Feb 26 15:29:40 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 12:29:40 -0800 Subject: [Nitro] Dir structure In-Reply-To: References: Message-ID: <8905c87a0702261229l5599c0abu41e6ac1987c3cafb@mail.gmail.com> My frank opinion is that Og is too useful to couple tightly with Nitro. I'd vote for decoupling the two libraries entirely - possibly to the point of having separate projects. As a consequence, while I think it makes sense for mixins that help all of Nitro out to be in /nitro/something (model seems misleading - support? mixins?), I'd like to see Og specific mixins in og somewhere. If necessary, promote shared modules to Facets, perhaps, or examine why Og and Nitro share a module. Perhaps two separate modules makes more sense - although that's a completely unfounded opinion without an example to hand. Judson On 2/26/07, George Moschovitis wrote: > Dear devs, > > in the older version of Nitro there used to be glue directories in > og/lib/glue and nitro/lib/glue. In the process of getting rid glue I > moved these directories to: > > og/lib/glue (namespace Glue::) -> og/lib/og/mixin (namespace Og::Mixin) > nitro/lib/glue (namespace Glue::)-> raw/lib/raw/mixin (namespace Raw::Mixin) > > the modules Og::Mixin and Raw::Mixin are included in the top-level for > extra convienience. > > I am not happy with having 2 directories. I would like to have all > mixins to a single directory. Moreover, the controller helpers are in > fact mixins (mixed in to controller classes, not model classes). > > Since these mixins are high level constructs that work on top of the > lower level Og and Raw libraries, and I would like to integrate the > model and controller mixins I have the following idea for better > organization. Move these files in Nitro (the high level framework that > uses the lower level Raw and Og libraries): > > model mixins go to: > > nitro/model/ > > for example > > nitro/model/timestamped > nitro/model/webfile > nitro/model/taggable > nitro/model/orderable > > > controller mixins go to: > > nitro/controller/ > > for example > > nitro/controller/pager > nitro/controller/table > nitro/controller/autologin > > etc... > > One drawback of this is that modules like optimistic_locking, > hierarchical etc, that useful for Og users that are not Nitro users > now would reside in the Nitro dir. > > Please, I would really like to hear your input here and your suggestions. > > regards, > George. > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From transfire at gmail.com Mon Feb 26 15:31:41 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Mon, 26 Feb 2007 20:31:41 -0000 Subject: [Nitro] Dir structure In-Reply-To: References: Message-ID: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> On Feb 26, 12:11 pm, "George Moschovitis" wrote: > Dear devs, > > in the older version of Nitro there used to be glue directories in > og/lib/glue and nitro/lib/glue. In the process of getting rid glue I > moved these directories to: > > og/lib/glue (namespace Glue::) -> og/lib/og/mixin (namespace Og::Mixin) > nitro/lib/glue (namespace Glue::)-> raw/lib/raw/mixin (namespace Raw::Mixin) > > the modules Og::Mixin and Raw::Mixin are included in the top-level for > extra convienience. > > I am not happy with having 2 directories. I would like to have all > mixins to a single directory. Moreover, the controller helpers are in > fact mixins (mixed in to controller classes, not model classes). > > Since these mixins are high level constructs that work on top of the > lower level Og and Raw libraries, and I would like to integrate the > model and controller mixins I have the following idea for better > organization. Move these files in Nitro (the high level framework that > uses the lower level Raw and Og libraries): > > model mixins go to: > > nitro/model/ > > for example > > nitro/model/timestamped > nitro/model/webfile > nitro/model/taggable > nitro/model/orderable > > controller mixins go to: > > nitro/controller/ > > for example > > nitro/controller/pager > nitro/controller/table > nitro/controller/autologin > > etc... > > One drawback of this is that modules like optimistic_locking, > hierarchical etc, that useful for Og users that are not Nitro users > now would reside in the Nitro dir. > > Please, I would really like to hear your input here and your suggestions. This seems almost backwards. If I'm using Og will I have to depend on Nitro? T. From nyarly at gmail.com Mon Feb 26 15:50:02 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 12:50:02 -0800 Subject: [Nitro] Recent bug Message-ID: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> tc_store.rb is failing on my box now that I've pulled the repo. It looks like Og::Manager#store is returning nil, now? Some of my own Og based code is broken by this pull as well. If no one else is working on it right now, I'll continue to work on a fix. Judson From nyarly at gmail.com Mon Feb 26 16:35:45 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 13:35:45 -0800 Subject: [Nitro] Recent bug In-Reply-To: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> References: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> Message-ID: <8905c87a0702261335n18acac41h843a47e56645279e@mail.gmail.com> And here's the patch bundle. Is there any plan to convert tests into specs? test2spec seems to be retired from rspec... On 2/26/07, Judson Lester wrote: > tc_store.rb is failing on my box now that I've pulled the repo. It > looks like Og::Manager#store is returning nil, now? Some of my own Og > based code is broken by this pull as well. If no one else is working > on it right now, I'll continue to work on a fix. > > Judson > -------------- next part -------------- A non-text attachment was scrubbed... Name: with_store-fix.bundle Type: application/octet-stream Size: 24909 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070226/620e3c2d/attachment-0001.obj From john at oxyliquit.de Mon Feb 26 19:03:00 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 27 Feb 2007 01:03:00 +0100 Subject: [Nitro] Recent bug In-Reply-To: <8905c87a0702261335n18acac41h843a47e56645279e@mail.gmail.com> References: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> <8905c87a0702261335n18acac41h843a47e56645279e@mail.gmail.com> Message-ID: Hi, > And here's the patch bundle. that's great! > Is there any plan to convert tests into specs? test2spec seems to be > retired from rspec... Too bad I don't have much experience with rspec. What I like about is: the ability to specify human readable text as context/spec. What I find a little weird: writing '@something.should_be_empty' instead of 'assert @something.empty?'. The test::unit form is less opaque (for me) than rspec, it 'looks and behaves' more like normal Ruby... That said, I'm ok with using rspec exclusively. When I get the chance (between organizing stuff for going to finland) I will read a little into rspec and try to learn by rspec'ifying my tc_controller_param stuff. >> tc_store.rb is failing on my box now that I've pulled the repo. It >> looks like Og::Manager#store is returning nil, now? Some of my own Og >> based code is broken by this pull as well. If no one else is working >> on it right now, I'll continue to work on a fix. This change was done because of the store-leak problem. Though instead of .with_store I'd rather had liked to use .store(&block) instead of .with_store(&block) and make .get_store/.put_store private (only to be used by .store). Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From nyarly at gmail.com Mon Feb 26 21:05:15 2007 From: nyarly at gmail.com (Judson Lester) Date: Mon, 26 Feb 2007 18:05:15 -0800 Subject: [Nitro] Recent bug In-Reply-To: References: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> <8905c87a0702261335n18acac41h843a47e56645279e@mail.gmail.com> Message-ID: <8905c87a0702261805o7b9686d5s17fb2439174982a6@mail.gmail.com> On 2/26/07, Jonathan Buch wrote: > Hi, > > > And here's the patch bundle. > > that's great! > > > Is there any plan to convert tests into specs? test2spec seems to be > > retired from rspec... > > Too bad I don't have much experience with rspec. What I like about is: > the ability to specify human readable text as context/spec. What I > find a little weird: writing '@something.should_be_empty' instead of > 'assert @something.empty?'. The test::unit form is less opaque (for me) > than rspec, it 'looks and behaves' more like normal Ruby... I got over that VERY quickly :) And this point that I saw made recently is particularly cogent: @actual.should_eql @expected is a lot clearer in intent than assert_equal(@actual_or_expected, @expected_or_actual) Also, having mocks built in is so nice. And string diffs. Oh, (and you might have seen this one coming, given my rampage through Og) rspec has such a cleaner architecture than Test::Unit. Extending RSpec is a breeze - Test::Unit is a nightmare. > That said, I'm ok with using rspec exclusively. When I get the chance > (between organizing stuff for going to finland) I will read a little > into rspec and try to learn by rspec'ifying my tc_controller_param stuff. Their docco is very nicely laid out. And the whole thing is pretty POLS. Only con that I see to rspec at all is that their devs are a little religious about BDD. I still want a runner that would produce skeleton classes and methods based on specs (and possibly even specs from mocks...) but this would apparently be against the RSpec Way - so it remains a project for a rainy day. > >> tc_store.rb is failing on my box now that I've pulled the repo. It > >> looks like Og::Manager#store is returning nil, now? Some of my own Og > >> based code is broken by this pull as well. If no one else is working > >> on it right now, I'll continue to work on a fix. > > This change was done because of the store-leak problem. Though instead > of .with_store I'd rather had liked to use .store(&block) instead of > .with_store(&block) and make .get_store/.put_store private (only to be > used by .store). I saw that exchange. Honestly, get_store/put_store is easier to test/spec, and more in keeping with the Ruby paradigm of close-on-done blocks being a convenience. After all, if I really wanted to, I could __send(:get_store)__. Lets not get fascist about it; this isn't Java :) Judson From george.moschovitis at gmail.com Tue Feb 27 04:30:13 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 11:30:13 +0200 Subject: [Nitro] Dir structure In-Reply-To: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> Message-ID: But does really Taggable or Orderable belong to Og? -g. On 2/26/07, transfire at gmail.com wrote: > > > On Feb 26, 12:11 pm, "George Moschovitis" > wrote: > > Dear devs, > > > > in the older version of Nitro there used to be glue directories in > > og/lib/glue and nitro/lib/glue. In the process of getting rid glue I > > moved these directories to: > > > > og/lib/glue (namespace Glue::) -> og/lib/og/mixin (namespace Og::Mixin) > > nitro/lib/glue (namespace Glue::)-> raw/lib/raw/mixin (namespace Raw::Mixin) > > > > the modules Og::Mixin and Raw::Mixin are included in the top-level for > > extra convienience. > > > > I am not happy with having 2 directories. I would like to have all > > mixins to a single directory. Moreover, the controller helpers are in > > fact mixins (mixed in to controller classes, not model classes). > > > > Since these mixins are high level constructs that work on top of the > > lower level Og and Raw libraries, and I would like to integrate the > > model and controller mixins I have the following idea for better > > organization. Move these files in Nitro (the high level framework that > > uses the lower level Raw and Og libraries): > > > > model mixins go to: > > > > nitro/model/ > > > > for example > > > > nitro/model/timestamped > > nitro/model/webfile > > nitro/model/taggable > > nitro/model/orderable > > > > controller mixins go to: > > > > nitro/controller/ > > > > for example > > > > nitro/controller/pager > > nitro/controller/table > > nitro/controller/autologin > > > > etc... > > > > One drawback of this is that modules like optimistic_locking, > > hierarchical etc, that useful for Og users that are not Nitro users > > now would reside in the Nitro dir. > > > > Please, I would really like to hear your input here and your suggestions. > > This seems almost backwards. If I'm using Og will I have to depend on > Nitro? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 04:49:05 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 11:49:05 +0200 Subject: [Nitro] Recent bug In-Reply-To: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> References: <8905c87a0702261250t4406fd10x279c27ad270775e1@mail.gmail.com> Message-ID: The test cases are not updated in the repo version. I made a change to the store handling to make Og more thread safe. -g. On 2/26/07, Judson Lester wrote: > tc_store.rb is failing on my box now that I've pulled the repo. It > looks like Og::Manager#store is returning nil, now? Some of my own Og > based code is broken by this pull as well. If no one else is working > on it right now, I'll continue to work on a fix. > > Judson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Tue Feb 27 05:14:06 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 02:14:06 -0800 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> Message-ID: <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> On 2/27/07, George Moschovitis wrote: > But does really Taggable or Orderable belong to Og? > Well, looking at mixin/taggable.rb and mixin/orderable.rb, yes. I don't see any references to anything actually web related in either, and neither make any sense without Og. Give an example: I've got a library I've been working on, not ready for limelight yet, that builds CLIs. I've written an app that uses that and Og to manage some personal databases. It makes perfect sense to me to use Taggable for that sort of application. But I can't imagine building a Nitro app with Taggable but not Og. (Although it's a stretch to picture Nitro without Og in the first place.) Judson From john at oxyliquit.de Tue Feb 27 05:21:31 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 27 Feb 2007 11:21:31 +0100 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> Message-ID: Hi, > But does really Taggable or Orderable belong to Og? I think those have to be considered case by case. >> > nitro/model/timestamped This makes also sense in a non-raw environment. Since it just says when the Og model has been created/changed. I would let this remain in Og. >> > nitro/model/webfile Raw, makes no sense in Og alone and is a feature of Nitro. >> > nitro/model/taggable This is tricky, as it fits either way. There is no Raw-specific code in taggable itself (except one line of html) this would fit into Og as well. I'm sure someone would find a way of using tags in a non-web-2.0 environment. ;) >> > nitro/model/orderable Also tricky, but as with taggable, no code relying on Raw, only on Og. Having to have an ordered list might make sense without Raw as well. > > One drawback of this is that modules like optimistic_locking, > > hierarchical etc, that useful for Og users that are not Nitro users > > now would reside in the Nitro dir. I'm not sure we should put all those in the nitro dir, hierarchical as well doesn't depend on anything what nitro or raw has, only on Og and also makes sense without them. So, I vote for deciding case by case, looking if they use any 'features' which make them depend one one or the other and decide accordingly. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From nyarly at gmail.com Tue Feb 27 05:37:40 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 02:37:40 -0800 Subject: [Nitro] STI relations patch Message-ID: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> Attached, please find a bundle to add working relations between STI child classes. There's a spec called spec/sti_relations.rb included that demonstrates it's purpose. In essence, though, any relation created in a subclass of an STI tree wouldn't resolve properly. Judson -------------- next part -------------- A non-text attachment was scrubbed... Name: sti_reference.bundle Type: application/octet-stream Size: 29740 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070227/173c6c7a/attachment-0001.obj From george.moschovitis at gmail.com Tue Feb 27 05:47:45 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 12:47:45 +0200 Subject: [Nitro] Dir structure In-Reply-To: <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> Message-ID: Ok, point taken, but I would like to keep Og simpler. There are so many things that could be implemented as mixins I don't want to include everything in the default distribution. I will think about this a bit more. I will most probably keep an Og namespace for mixins as you suggest. regards, George. On 2/27/07, Judson Lester wrote: > On 2/27/07, George Moschovitis wrote: > > But does really Taggable or Orderable belong to Og? > > > > Well, looking at mixin/taggable.rb and mixin/orderable.rb, yes. I > don't see any references to anything actually web related in either, > and neither make any sense without Og. > > Give an example: I've got a library I've been working on, not ready > for limelight yet, that builds CLIs. I've written an app that uses > that and Og to manage some personal databases. It makes perfect sense > to me to use Taggable for that sort of application. But I can't > imagine building a Nitro app with Taggable but not Og. (Although it's > a stretch to picture Nitro without Og in the first place.) > > Judson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 06:09:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 13:09:38 +0200 Subject: [Nitro] STI relations patch In-Reply-To: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> Message-ID: Thanks. -g. On 2/27/07, Judson Lester wrote: > Attached, please find a bundle to add working relations between STI > child classes. There's a spec called spec/sti_relations.rb included > that demonstrates it's purpose. In essence, though, any relation > created in a subclass of an STI tree wouldn't resolve properly. > > Judson > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 06:16:03 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 13:16:03 +0200 Subject: [Nitro] STI relations patch In-Reply-To: References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> Message-ID: Please can you send me just the spec directory zipped? -g. On 2/27/07, George Moschovitis wrote: > Thanks. > > -g. > > On 2/27/07, Judson Lester wrote: > > Attached, please find a bundle to add working relations between STI > > child classes. There's a spec called spec/sti_relations.rb included > > that demonstrates it's purpose. In essence, though, any relation > > created in a subclass of an STI tree wouldn't resolve properly. > > > > Judson > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 06:18:07 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 13:18:07 +0200 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> Message-ID: btw, what is a CLI ? -g. On 2/27/07, George Moschovitis wrote: > Ok, > > point taken, but I would like to keep Og simpler. There are so many > things that could be implemented as mixins I don't want to include > everything in the default distribution. I will think about this a bit > more. I will most probably keep an Og namespace for mixins as you > suggest. > > regards, > George. > > > > On 2/27/07, Judson Lester wrote: > > On 2/27/07, George Moschovitis wrote: > > > But does really Taggable or Orderable belong to Og? > > > > > > > Well, looking at mixin/taggable.rb and mixin/orderable.rb, yes. I > > don't see any references to anything actually web related in either, > > and neither make any sense without Og. > > > > Give an example: I've got a library I've been working on, not ready > > for limelight yet, that builds CLIs. I've written an app that uses > > that and Og to manage some personal databases. It makes perfect sense > > to me to use Taggable for that sort of application. But I can't > > imagine building a Nitro app with Taggable but not Og. (Although it's > > a stretch to picture Nitro without Og in the first place.) > > > > Judson > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 06:25:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 13:25:46 +0200 Subject: [Nitro] Entity -> Model Message-ID: Dear devs, in the quest for consistency across the Nitro sub-frameworks I have renamed Og::Entity to Og::Model. Please pull the latest repo version before sending further Og patches. The rational is that model is used in Raw/Nitro and is more understandable to newcomers coming from AR/MVC. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Tue Feb 27 08:13:04 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 27 Feb 2007 14:13:04 +0100 Subject: [Nitro] Og, serialized transactions? In-Reply-To: <00d601c75954$2c336880$6442a8c0@musicbox> References: <019301c7585f$065241e0$6442a8c0@musicbox> <20070226004247.GA17231@shienar> <01e701c75880$934b9210$6442a8c0@musicbox> <00d601c75954$2c336880$6442a8c0@musicbox> Message-ID: Hi, >> Right now you can specify that index in sql and Og will not mess >> with it. > > Alrighty, thanks. > > Is there any sort of hook or callback that would tell me when > the table is actually being created by Og, so that I could create > the index at that point? Sorry, no such callback comes to my mind atm. When I do that, I just create a text file with sql stuff in it and just paste it into psql. Sorry for not being much help here. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Tue Feb 27 10:48:59 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 17:48:59 +0200 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> Message-ID: I wanted to avoid the case by case decision. Anyway, I think I rearanged things a bit better, will push something to the repo tomorrow. -g. On 2/27/07, Jonathan Buch wrote: > Hi, > > > But does really Taggable or Orderable belong to Og? > > I think those have to be considered case by case. > > >> > nitro/model/timestamped > > This makes also sense in a non-raw environment. Since it just > says when the Og model has been created/changed. I would let this > remain in Og. > > >> > nitro/model/webfile > > Raw, makes no sense in Og alone and is a feature of Nitro. > > >> > nitro/model/taggable > > This is tricky, as it fits either way. There is no Raw-specific > code in taggable itself (except one line of html) this would fit > into Og as well. I'm sure someone would find a way of using tags > in a non-web-2.0 environment. ;) > > >> > nitro/model/orderable > > Also tricky, but as with taggable, no code relying on Raw, only > on Og. Having to have an ordered list might make sense without > Raw as well. > > > > One drawback of this is that modules like optimistic_locking, > > > hierarchical etc, that useful for Og users that are not Nitro users > > > now would reside in the Nitro dir. > > I'm not sure we should put all those in the nitro dir, hierarchical > as well doesn't depend on anything what nitro or raw has, only on > Og and also makes sense without them. So, I vote for deciding case > by case, looking if they use any 'features' which make them depend > one one or the other and decide accordingly. > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 13:16:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 20:16:44 +0200 Subject: [Nitro] Facets instance_method? Message-ID: Tom, how about including klass.instance_method? :meth to facets. This is a very useful helper. thanks, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Tue Feb 27 13:18:28 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 10:18:28 -0800 Subject: [Nitro] STI relations patch In-Reply-To: References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> Message-ID: <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> Sure. They should be attached. Incidentally, I'm not thrilled yet with the way classes work with specs - contexts aren't lexical scopes, so the various fixture classes get away - need to figure out a way to prevent that... Judson On 2/27/07, George Moschovitis wrote: > Please can you send me just the spec directory zipped? > > -g. > > On 2/27/07, George Moschovitis wrote: > > Thanks. > > > > -g. > > > > On 2/27/07, Judson Lester wrote: > > > Attached, please find a bundle to add working relations between STI > > > child classes. There's a spec called spec/sti_relations.rb included > > > that demonstrates it's purpose. In essence, though, any relation > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > Judson > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- A non-text attachment was scrubbed... Name: og-specs.zip Type: application/zip Size: 2857 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070227/c1383a36/attachment-0001.zip From nyarly at gmail.com Tue Feb 27 13:27:44 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 10:27:44 -0800 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> Message-ID: <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> On 2/27/07, George Moschovitis wrote: > Ok, > > point taken, but I would like to keep Og simpler. There are so many > things that could be implemented as mixins I don't want to include > everything in the default distribution. I will think about this a bit > more. I will most probably keep an Og namespace for mixins as you > suggest. On possibility might be to create an Og Extras project - with things like Taggable and Orderable - possibly even OptimisticLocking - so that straight Og remains simple, but there's all kinds of features available for Og client devs. Oh, sorry for jargon: a CLI is a command line interface. Basically, I'm developing it for anything that's more complicated than a simple script, but that doesn't really make sense as a web app. Eventually, it could be the basis of rapid GUI development, too, but that's still a pipe dream. Judson From george.moschovitis at gmail.com Tue Feb 27 14:05:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 21:05:56 +0200 Subject: [Nitro] STI relations patch In-Reply-To: <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> Message-ID: thanks -g. On 2/27/07, Judson Lester wrote: > Sure. They should be attached. Incidentally, I'm not thrilled yet > with the way classes work with specs - contexts aren't lexical scopes, > so the various fixture classes get away - need to figure out a way to > prevent that... > > Judson > > On 2/27/07, George Moschovitis wrote: > > Please can you send me just the spec directory zipped? > > > > -g. > > > > On 2/27/07, George Moschovitis wrote: > > > Thanks. > > > > > > -g. > > > > > > On 2/27/07, Judson Lester wrote: > > > > Attached, please find a bundle to add working relations between STI > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > that demonstrates it's purpose. In essence, though, any relation > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > Judson > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Tue Feb 27 15:53:55 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 12:53:55 -0800 Subject: [Nitro] STI relations patch In-Reply-To: References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> Message-ID: <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> I'm sending a new bundle of the sti-relations changes, because afaict, the last one got mangled: none of the sigificant changes survived, and the old one won't reapply On 2/27/07, George Moschovitis wrote: > thanks > -g. > > On 2/27/07, Judson Lester wrote: > > Sure. They should be attached. Incidentally, I'm not thrilled yet > > with the way classes work with specs - contexts aren't lexical scopes, > > so the various fixture classes get away - need to figure out a way to > > prevent that... > > > > Judson > > > > On 2/27/07, George Moschovitis wrote: > > > Please can you send me just the spec directory zipped? > > > > > > -g. > > > > > > On 2/27/07, George Moschovitis wrote: > > > > Thanks. > > > > > > > > -g. > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > Attached, please find a bundle to add working relations between STI > > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > > that demonstrates it's purpose. In essence, though, any relation > > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > > > Judson > > > > > > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > -- > > > > http://blog.gmosx.com > > > > http://cull.gr > > > > http://www.joy.gr > > > > http://nitroproject.org > > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- A non-text attachment was scrubbed... Name: sti-relation-2.bundle Type: application/octet-stream Size: 32369 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070227/1c487518/attachment-0001.obj From john at oxyliquit.de Tue Feb 27 16:16:21 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 27 Feb 2007 22:16:21 +0100 Subject: [Nitro] Dir structure In-Reply-To: <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> Message-ID: Hi, > Eventually, it could be the basis of rapid GUI development, too, > but that's still a pipe dream. sidenote: I already used Og together with Cocoa (GUI library for Mac). It works like a charm, you just 'bind' a table within Cocoa to a Og Model and it Just Works! Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Tue Feb 27 16:23:37 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 27 Feb 2007 21:23:37 -0000 Subject: [Nitro] Entity -> Model In-Reply-To: References: Message-ID: <1172611417.612555.190000@p10g2000cwp.googlegroups.com> On Feb 27, 6:25 am, "George Moschovitis" wrote: > Dear devs, > > in the quest for consistency across the Nitro sub-frameworks I have > renamed Og::Entity to Og::Model. Please pull the latest repo version > before sending further Og patches. > > The rational is that model is used in Raw/Nitro and is more > understandable to newcomers coming from AR/MVC. Good change IMHO. Model is more commonly understood, in my experience. T. From george.moschovitis at gmail.com Tue Feb 27 16:44:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 27 Feb 2007 23:44:18 +0200 Subject: [Nitro] Dir structure In-Reply-To: <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> Message-ID: > On possibility might be to create an Og Extras project - with things > like Taggable and Orderable - possibly even OptimisticLocking - so > that straight Og remains simple, but there's all kinds of features > available for Og client devs. I am working on a plugin system for Nitro/Og that will handle this. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From transfire at gmail.com Tue Feb 27 16:41:41 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Tue, 27 Feb 2007 21:41:41 -0000 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> Message-ID: <1172612501.802900.172770@v33g2000cwv.googlegroups.com> On Feb 27, 5:47 am, "George Moschovitis" wrote: > Ok, > > point taken, but I would like to keep Og simpler. There are so many > things that could be implemented as mixins I don't want to include > everything in the default distribution. I will think about this a bit > more. I will most probably keep an Og namespace for mixins as you > suggest. Why so bare bones? I would think a user of Og would want to have access to these Og specific mixins without having to install yet another package (and would deter usage otherwise). I could understand it if it was some esoteric mixin with a very specific usecase, but in that case I would expect the mixin it to have it's own project all together. As for Raw, of course any mixin that is specific to Raw belongs with it too. If we put Raw specific mixin in Nitro then I don't think the Nitro/Raw split was worthit in the first place. Of course it a harder question for parts that use both Og and Raw, but I suspect they would much less common, and would probably do just as well as stand-alone projects, but if they are general/vital then Nitro seems the place to be. Query: Not that I would do this, I'm asking a theoretical quesiton here: could one use Raw with ActiveRecord (no Nitro no Og)? T. From nyarly at gmail.com Tue Feb 27 16:56:11 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 13:56:11 -0800 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> <8905c87a0702271027i1557f562g994d8610d86bdd6c@mail.gmail.com> Message-ID: <8905c87a0702271356o3eace2b7vc5a35f1099b3661d@mail.gmail.com> Jo, That's a much better example than mine, if only because of the install base. :) Judson On 2/27/07, Jonathan Buch wrote: > Hi, > > > Eventually, it could be the basis of rapid GUI development, too, > > but that's still a pipe dream. > > sidenote: I already used Og together with Cocoa (GUI library for Mac). > It works like a charm, you just 'bind' a table within Cocoa to a Og > Model and it Just Works! > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Tue Feb 27 17:13:02 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 00:13:02 +0200 Subject: [Nitro] Entity -> Model In-Reply-To: <1172611417.612555.190000@p10g2000cwp.googlegroups.com> References: <1172611417.612555.190000@p10g2000cwp.googlegroups.com> Message-ID: > Good change IMHO. Model is more commonly understood, in my experience. thanks. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Feb 27 17:18:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 00:18:57 +0200 Subject: [Nitro] STI relations patch In-Reply-To: <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> Message-ID: Judson, I have made some changes in Og. I would like to ask you to be patient till tomorrow. I will push the latest code and I would like to get a new patch from you against the latest repo. sorry for the inconvienience and thanks for your patience. -g. On 2/27/07, Judson Lester wrote: > I'm sending a new bundle of the sti-relations changes, because afaict, > the last one got mangled: none of the sigificant changes survived, and > the old one won't reapply > > On 2/27/07, George Moschovitis wrote: > > thanks > > -g. > > > > On 2/27/07, Judson Lester wrote: > > > Sure. They should be attached. Incidentally, I'm not thrilled yet > > > with the way classes work with specs - contexts aren't lexical scopes, > > > so the various fixture classes get away - need to figure out a way to > > > prevent that... > > > > > > Judson > > > > > > On 2/27/07, George Moschovitis wrote: > > > > Please can you send me just the spec directory zipped? > > > > > > > > -g. > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > Thanks. > > > > > > > > > > -g. > > > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > > Attached, please find a bundle to add working relations between STI > > > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > > > that demonstrates it's purpose. In essence, though, any relation > > > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > > > > > Judson > > > > > > > > > > > > _______________________________________________ > > > > > > Nitro-general mailing list > > > > > > Nitro-general at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://blog.gmosx.com > > > > > http://cull.gr > > > > > http://www.joy.gr > > > > > http://nitroproject.org > > > > > > > > > > > > > > > > > -- > > > > http://blog.gmosx.com > > > > http://cull.gr > > > > http://www.joy.gr > > > > http://nitroproject.org > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Tue Feb 27 17:34:34 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 14:34:34 -0800 Subject: [Nitro] Entity -> Model In-Reply-To: <1172611417.612555.190000@p10g2000cwp.googlegroups.com> References: <1172611417.612555.190000@p10g2000cwp.googlegroups.com> Message-ID: <8905c87a0702271434n28f2bc06ob18cdfa3b54b8bd8@mail.gmail.com> As much as changing Entity -> Model is fraught with refactoring peril, it's just simpler to talk about Model objects than "entities" Judson On 2/27/07, transfire at gmail.com wrote: > > > On Feb 27, 6:25 am, "George Moschovitis" > wrote: > > Dear devs, > > > > in the quest for consistency across the Nitro sub-frameworks I have > > renamed Og::Entity to Og::Model. Please pull the latest repo version > > before sending further Og patches. > > > > The rational is that model is used in Raw/Nitro and is more > > understandable to newcomers coming from AR/MVC. > > Good change IMHO. Model is more commonly understood, in my experience. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From nyarly at gmail.com Tue Feb 27 17:56:51 2007 From: nyarly at gmail.com (Judson Lester) Date: Tue, 27 Feb 2007 14:56:51 -0800 Subject: [Nitro] STI relations patch In-Reply-To: References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> Message-ID: <8905c87a0702271456r681f32b4r6a71679de649ae85@mail.gmail.com> Sure thing. You have my patience in exchange for a discussion regarding SCM once 0.5 is released. Fair? :) Judson On 2/27/07, George Moschovitis wrote: > Judson, > > I have made some changes in Og. I would like to ask you to be patient > till tomorrow. I will push the latest code and I would like to get a > new patch from you against the latest repo. > > sorry for the inconvienience and thanks for your patience. > > -g. > > On 2/27/07, Judson Lester wrote: > > I'm sending a new bundle of the sti-relations changes, because afaict, > > the last one got mangled: none of the sigificant changes survived, and > > the old one won't reapply > > > > On 2/27/07, George Moschovitis wrote: > > > thanks > > > -g. > > > > > > On 2/27/07, Judson Lester wrote: > > > > Sure. They should be attached. Incidentally, I'm not thrilled yet > > > > with the way classes work with specs - contexts aren't lexical scopes, > > > > so the various fixture classes get away - need to figure out a way to > > > > prevent that... > > > > > > > > Judson > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > Please can you send me just the spec directory zipped? > > > > > > > > > > -g. > > > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > > Thanks. > > > > > > > > > > > > -g. > > > > > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > > > Attached, please find a bundle to add working relations between STI > > > > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > > > > that demonstrates it's purpose. In essence, though, any relation > > > > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > > > > > > > Judson > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Nitro-general mailing list > > > > > > > Nitro-general at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://blog.gmosx.com > > > > > > http://cull.gr > > > > > > http://www.joy.gr > > > > > > http://nitroproject.org > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://blog.gmosx.com > > > > > http://cull.gr > > > > > http://www.joy.gr > > > > > http://nitroproject.org > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Wed Feb 28 02:44:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 09:44:41 +0200 Subject: [Nitro] Dir structure In-Reply-To: <1172612501.802900.172770@v33g2000cwv.googlegroups.com> References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> <1172612501.802900.172770@v33g2000cwv.googlegroups.com> Message-ID: I have put Og related mixins to: og/model/... for example: og/model/taggable og/model/hierarchical etc.. Raw related mixins go to: raw/model/webile raw/model/sweeper etc.. btw, for extra consistency I removed the notion of helper what used to be in raw/helper/... is now in: raw/controller/... raw/view/... for example: raw/controller/benchmark raw/controller/cookie raw/controller/send_file raw/view/pager raw/view/table etc... instead of helper :pager you now have to use the standard include Pager -g. On 2/27/07, transfire at gmail.com wrote: > > > On Feb 27, 5:47 am, "George Moschovitis" > wrote: > > Ok, > > > > point taken, but I would like to keep Og simpler. There are so many > > things that could be implemented as mixins I don't want to include > > everything in the default distribution. I will think about this a bit > > more. I will most probably keep an Og namespace for mixins as you > > suggest. > > Why so bare bones? I would think a user of Og would want to have > access to these Og specific mixins without having to install yet > another package (and would deter usage otherwise). I could understand > it if it was some esoteric mixin with a very specific usecase, but in > that case I would expect the mixin it to have it's own project all > together. > > As for Raw, of course any mixin that is specific to Raw belongs with > it too. If we put Raw specific mixin in Nitro then I don't think the > Nitro/Raw split was worthit in the first place. > > Of course it a harder question for parts that use both Og and Raw, but > I suspect they would much less common, and would probably do just as > well as stand-alone projects, but if they are general/vital then Nitro > seems the place to be. > > Query: Not that I would do this, I'm asking a theoretical quesiton > here: could one use Raw with ActiveRecord (no Nitro no Og)? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Feb 28 02:45:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 09:45:36 +0200 Subject: [Nitro] STI relations patch In-Reply-To: <8905c87a0702271456r681f32b4r6a71679de649ae85@mail.gmail.com> References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> <8905c87a0702271456r681f32b4r6a71679de649ae85@mail.gmail.com> Message-ID: ok :) On 2/28/07, Judson Lester wrote: > Sure thing. You have my patience in exchange for a discussion > regarding SCM once 0.5 is released. Fair? :) > > Judson > > On 2/27/07, George Moschovitis wrote: > > Judson, > > > > I have made some changes in Og. I would like to ask you to be patient > > till tomorrow. I will push the latest code and I would like to get a > > new patch from you against the latest repo. > > > > sorry for the inconvienience and thanks for your patience. > > > > -g. > > > > On 2/27/07, Judson Lester wrote: > > > I'm sending a new bundle of the sti-relations changes, because afaict, > > > the last one got mangled: none of the sigificant changes survived, and > > > the old one won't reapply > > > > > > On 2/27/07, George Moschovitis wrote: > > > > thanks > > > > -g. > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > Sure. They should be attached. Incidentally, I'm not thrilled yet > > > > > with the way classes work with specs - contexts aren't lexical scopes, > > > > > so the various fixture classes get away - need to figure out a way to > > > > > prevent that... > > > > > > > > > > Judson > > > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > > Please can you send me just the spec directory zipped? > > > > > > > > > > > > -g. > > > > > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > > > Thanks. > > > > > > > > > > > > > > -g. > > > > > > > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > > > > Attached, please find a bundle to add working relations between STI > > > > > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > > > > > that demonstrates it's purpose. In essence, though, any relation > > > > > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > > > > > > > > > Judson > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Nitro-general mailing list > > > > > > > > Nitro-general at rubyforge.org > > > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > http://blog.gmosx.com > > > > > > > http://cull.gr > > > > > > > http://www.joy.gr > > > > > > > http://nitroproject.org > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://blog.gmosx.com > > > > > > http://cull.gr > > > > > > http://www.joy.gr > > > > > > http://nitroproject.org > > > > > > _______________________________________________ > > > > > > Nitro-general mailing list > > > > > > Nitro-general at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > -- > > > > http://blog.gmosx.com > > > > http://cull.gr > > > > http://www.joy.gr > > > > http://nitroproject.org > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > -- > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Feb 28 02:48:29 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 09:48:29 +0200 Subject: [Nitro] STI relations patch In-Reply-To: References: <8905c87a0702270237o50a26107r9488ad45cb38970e@mail.gmail.com> <8905c87a0702271018j7ebf44a7sbbc1d5d610746abb@mail.gmail.com> <8905c87a0702271253ibd6aa9fq830aabe8d6c9d01f@mail.gmail.com> <8905c87a0702271456r681f32b4r6a71679de649ae85@mail.gmail.com> Message-ID: I pushed to the repo, so you can re-send the patch now... -g. On 2/28/07, George Moschovitis wrote: > ok :) > > > On 2/28/07, Judson Lester wrote: > > Sure thing. You have my patience in exchange for a discussion > > regarding SCM once 0.5 is released. Fair? :) > > > > Judson > > > > On 2/27/07, George Moschovitis wrote: > > > Judson, > > > > > > I have made some changes in Og. I would like to ask you to be patient > > > till tomorrow. I will push the latest code and I would like to get a > > > new patch from you against the latest repo. > > > > > > sorry for the inconvienience and thanks for your patience. > > > > > > -g. > > > > > > On 2/27/07, Judson Lester wrote: > > > > I'm sending a new bundle of the sti-relations changes, because afaict, > > > > the last one got mangled: none of the sigificant changes survived, and > > > > the old one won't reapply > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > thanks > > > > > -g. > > > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > > Sure. They should be attached. Incidentally, I'm not thrilled yet > > > > > > with the way classes work with specs - contexts aren't lexical scopes, > > > > > > so the various fixture classes get away - need to figure out a way to > > > > > > prevent that... > > > > > > > > > > > > Judson > > > > > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > > > Please can you send me just the spec directory zipped? > > > > > > > > > > > > > > -g. > > > > > > > > > > > > > > On 2/27/07, George Moschovitis wrote: > > > > > > > > Thanks. > > > > > > > > > > > > > > > > -g. > > > > > > > > > > > > > > > > On 2/27/07, Judson Lester wrote: > > > > > > > > > Attached, please find a bundle to add working relations between STI > > > > > > > > > child classes. There's a spec called spec/sti_relations.rb included > > > > > > > > > that demonstrates it's purpose. In essence, though, any relation > > > > > > > > > created in a subclass of an STI tree wouldn't resolve properly. > > > > > > > > > > > > > > > > > > Judson > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Nitro-general mailing list > > > > > > > > > Nitro-general at rubyforge.org > > > > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > http://blog.gmosx.com > > > > > > > > http://cull.gr > > > > > > > > http://www.joy.gr > > > > > > > > http://nitroproject.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > http://blog.gmosx.com > > > > > > > http://cull.gr > > > > > > > http://www.joy.gr > > > > > > > http://nitroproject.org > > > > > > > _______________________________________________ > > > > > > > Nitro-general mailing list > > > > > > > Nitro-general at rubyforge.org > > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Nitro-general mailing list > > > > > > Nitro-general at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://blog.gmosx.com > > > > > http://cull.gr > > > > > http://www.joy.gr > > > > > http://nitroproject.org > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > -- > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Feb 28 02:52:35 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 09:52:35 +0200 Subject: [Nitro] Dir structure In-Reply-To: References: <1172521901.662757.122670@v33g2000cwv.googlegroups.com> <8905c87a0702270214t8d47a39udca1587cc582c57e@mail.gmail.com> <1172612501.802900.172770@v33g2000cwv.googlegroups.com> Message-ID: Btw, I have also removed the scaffold directory. You can achieve the same now through mixins: (raw/model/enchant and raw/controller/rest, names are temporary) -g. > > As for Raw, of course any mixin that is specific to Raw belongs with > > it too. If we put Raw specific mixin in Nitro then I don't think the > > Nitro/Raw split was worthit in the first place. the Nitro/Raw split was done purely for directory organization purposes. -g. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Feb 28 11:23:17 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 18:23:17 +0200 Subject: [Nitro] Nitro homepage banner... Message-ID: Dear devs, attached to this email you will find the banner for the new nitro web site I am working on. This is of course under construction. I would like to hear ideas for a new Nitro moto/tagline to replace what you can see in this image. I would *really* love to hear your suggestions... thanks, George. -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-1.jpg Type: image/jpeg Size: 30123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070228/1b7f19fe/attachment-0001.jpg From george.moschovitis at gmail.com Wed Feb 28 11:24:19 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 28 Feb 2007 18:24:19 +0200 Subject: [Nitro] Nitro homepage banner... In-Reply-To: References: Message-ID: oh, you can also have a peek at the new logo (look in the box ;-)) -g. On 2/28/07, George Moschovitis wrote: > Dear devs, > > attached to this email you will find the banner for the new nitro web > site I am working on. This is of course under construction. I would > like to hear ideas for a new Nitro moto/tagline to replace what you > can see in this image. > > I would *really* love to hear your suggestions... > > thanks, > George. > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > -- http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Wed Feb 28 14:39:45 2007 From: nyarly at gmail.com (Judson Lester) Date: Wed, 28 Feb 2007 11:39:45 -0800 Subject: [Nitro] Nitro homepage banner... In-Reply-To: References: Message-ID: <8905c87a0702281139s3f39bcbds263f7f308872a8f8@mail.gmail.com> That looks pretty snazzy. Judson On 2/28/07, George Moschovitis wrote: > Dear devs, > > attached to this email you will find the banner for the new nitro web > site I am working on. This is of course under construction. I would > like to hear ideas for a new Nitro moto/tagline to replace what you > can see in this image. > > I would *really* love to hear your suggestions... > > thanks, > George. > > > -- > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From nyarly at gmail.com Wed Feb 28 15:15:08 2007 From: nyarly at gmail.com (Judson Lester) Date: Wed, 28 Feb 2007 12:15:08 -0800 Subject: [Nitro] One more time Message-ID: <8905c87a0702281215p3e1821a2s7b63bfd5f4f7623b@mail.gmail.com> Here's the new bundle for STI & relations. Judsin -------------- next part -------------- A non-text attachment was scrubbed... Name: sti-rel4.bndl Type: application/octet-stream Size: 27075 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070228/4052a0c1/attachment-0001.obj From surrender_it at yahoo.it Wed Feb 28 17:39:34 2007 From: surrender_it at yahoo.it (gabriele renzi) Date: Wed, 28 Feb 2007 23:39:34 +0100 Subject: [Nitro] Nitro homepage banner... In-Reply-To: References: Message-ID: George Moschovitis ha scritto: > oh, you can also have a peek at the new logo (look in the box ;-)) > > -g. > > On 2/28/07, George Moschovitis wrote: >> Dear devs, >> >> attached to this email you will find the banner for the new nitro web >> site I am working on. This is of course under construction. I would >> like to hear ideas for a new Nitro moto/tagline to replace what you >> can see in this image. >> >> I would *really* love to hear your suggestions... isn't it "state of the art" ? I thnk one "of" is missing. Other than that, the image is wonderful :) -- blog en: http://www.riffraff.info blog it: http://riffraff.blogsome.com jabber : rff.rff at gmail dot com From james.britt at gmail.com Wed Feb 28 23:07:22 2007 From: james.britt at gmail.com (James Britt) Date: Wed, 28 Feb 2007 21:07:22 -0700 Subject: [Nitro] Nitro homepage banner... In-Reply-To: References: Message-ID: <45E6517A.5020705@gmail.com> gabriele renzi wrote: > George Moschovitis ha scritto: >> oh, you can also have a peek at the new logo (look in the box ;-)) >> >> -g. >> >> On 2/28/07, George Moschovitis wrote: >>> Dear devs, >>> >>> attached to this email you will find the banner for the new nitro web >>> site I am working on. This is of course under construction. I would >>> like to hear ideas for a new Nitro moto/tagline to replace what you >>> can see in this image. >>> >>> I would *really* love to hear your suggestions... > > isn't it "state of the art" ? I thnk one "of" is missing. Other than > that, the image is wonderful :) Yeah, quite the slickness. Very nice! I want to add Nitro %w{ shirt hat coffer_cup } stuff to rubystuff.com! -- James Britt "Tear it up and start again." - Anonymous