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 imple