From arne at arnebrasseur.net Mon Oct 1 08:34:57 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 01 Oct 2007 20:34:57 +0800 Subject: [Nitro] [Patch] FormHelper RDoc improvement Message-ID: <4700E970.2000904@arnebrasseur.net> This adds top-level documentation to FormHelper and fixes an interface change that wasn't reflected yet in the comments (f.property -> f.attribute). (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20071001.patch Type: text/x-patch Size: 66803 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/82328a4d/attachment-0001.bin From john at oxyliquit.de Mon Oct 1 08:38:24 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 01 Oct 2007 14:38:24 +0200 Subject: [Nitro] Request#params In-Reply-To: <47005B96.9090401@robmela.com> References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> Message-ID: Hi, > OgAdminController#save attempts to access request data via the 'request' > method call: > > klass = name_to_class(*request*['object_class_name'].to_s) > obj.assign(*request*, :assign_relations => true, :force_boolean => true) yes, I believe that was always like that, as a shortcut to request.params. > A couple problems > > - Major misnomer: request returns a @context object That I don't know about. > - @request does not have a [] method for accessing incoming request > variables ( nor should it...) Any reason why? * request.params['foo'] * request['foo'] I use the second form all the time. > I've worked around it for now by calling > @context.post_params['object_class_name'] .... which led up to the > question in my prev. email, since @context.params would be nicer... I'm not sure I follow you here. The parameters come from the "Request" (requested by browser) and I'm not sure if 'context' better describes where the parameters come from. IMO they belong to the current 'request cycle' and not to a 'generic context'. But mind you, that is just generally, if Nitro returns a `Context` object when you call `request` then that's just kind of an alias.... >> 31 def params >> 32 return method == :post ? @post_params : @get_params >> 33 end I'm not sure about the contents of those, but IIRC the plan (quite a while back) was to do a little more: def params return method == :post ? @get_params.merge(@post_params) : @get_params end (Where I assume the @get_params is an hash.) But that might now be obsolete when we have both .get/post_params available. Carry on :P Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From rob at robmela.com Mon Oct 1 08:41:13 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 08:41:13 -0400 Subject: [Nitro] Request#params In-Reply-To: <47005B96.9090401@robmela.com> References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> Message-ID: <4700EAE9.6020300@robmela.com> Whoa.. I should proofread... "@request does not have a [] method" should read "@context does not have..." Robert Mela wrote: > A second, related question -- > > OgAdminController#save attempts to access request data via the > 'request' method call: > > klass = name_to_class(*request*['object_class_name'].to_s) > obj.assign(*request*, :assign_relations => true, :force_boolean => true) > > A couple problems > > - Major misnomer: request returns a @context object > - @request does not have a [] method for accessing incoming request > variables ( nor should it...) > > I've worked around it for now by calling > @context.post_params['object_class_name'] .... which led up to the > question in my prev. email, since @context.params would be nicer... > > > > > > Robert Mela wrote: >> Not sure what the intent is here in request.rb, module Raw, included >> in class Context >> >> 31 def params >> 32 if method == :post >> 33 @post_params.instance_variable_get("@hash") >> 34 else >> 35 @get_params.instance_variable_get("@hash") >> 36 end >> 37 end >> >> >> @post_params is itself a hash and an instance variable on Context, >> and @post_params.instance_variable_get( "@hash" ) returns nil. >> >> Anything wrong with doing this instead? >> >> 31 def params >> 32 return method == :post ? @post_params : @get_params >> 33 end >> >> If that's acceptable I'll add it to the patches I'm preparing. >> >> thx. >> _______________________________________________ >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/05976721/attachment.vcf From john at oxyliquit.de Mon Oct 1 08:41:51 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 01 Oct 2007 14:41:51 +0200 Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?= In-Reply-To: References: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org> Message-ID: Hi, I used google to translate it, but the 2 last kanji aren't translatable apparently - so I asked Manveru what it meant: [11:54] uh, ok, then, did you read the nitro ML? [11:55] there's some japanese there which I'm unable to translate :) [11:55] nitro-general is now on ruby-forum? [11:56] uh, I do not know :) [11:56] that's just spam [11:56] ok :) [12:01] I'd hate to miss out on something, ah well ^^; [12:01] :) [12:02] or it's not spam but the sender hit send way too soon [12:02] and changed encoding while writing [12:02] XD [12:02] in any way just ignore it :) Jo On Sun, 30 Sep 2007 09:52:42 +0200, George Moschovitis wrote: > huh? ;-) > > -g. > > On 9/30/07, Aidan Rogers wrote: >> ??? >> >> On Sep 29, 2007, at 8:15 PM, Afa Reg wrote: >> >> > ?????? >> > -- >> > Posted via http://www.ruby-forum.com/. >> > _______________________________________________ >> > 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 > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From arne at arnebrasseur.net Mon Oct 1 08:42:55 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 01 Oct 2007 20:42:55 +0800 Subject: [Nitro] Updated tutorial Message-ID: <4700EB4F.2010708@arnebrasseur.net> One new chapter to the tutorial, plus a Mercurial repo. hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi /your/local/dir That URL should also show you the latest history of changes. e-mail me if you want commit access. The basic tutorial will broadly follow the outline from the Ramaze tutorial : http://ramaze.rubyforge.org/tutorial/todolist.html Small example apps are also welcome. All content can be freely copied and adapted, e.g. to the Nitro repo, to Oxyliquit, to Nitro RDoc, blogs, wikis, etc. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: nitrotutorial.tar.gz Type: application/x-gzip Size: 52140 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/4016481e/attachment-0001.gz From rob at robmela.com Mon Oct 1 09:26:16 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 09:26:16 -0400 Subject: [Nitro] Request#params In-Reply-To: References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> Message-ID: <4700F578.4000305@robmela.com> You're right... but.... still.... I swear -- 'request[]' failed in nitro/part/admin/og/controller.rb in OgAdminController::save I'll try a very simple test case to verify -- perhaps some code included via raw/model/webfile.rb is overriding it somehow... The accessors do work as advertised in this case: #!/usr/bin/env ruby require 'nitro_and_og' include Nitro class Foo def index render_text " request() returns #{request.nil? ? 'nil' : request.class.name } Parameters " end def paramtest(*args) %{ params=#{request.params}
request[:foo] = #{request[:foo]} } end end app=Application.new app.dispatcher.root = Foo app.start Jonathan Buch wrote: > Hi, > >> OgAdminController#save attempts to access request data via the 'request' >> method call: >> >> klass = name_to_class(*request*['object_class_name'].to_s) >> obj.assign(*request*, :assign_relations => true, :force_boolean => true) > > yes, I believe that was always like that, as a shortcut to > request.params. > >> A couple problems >> >> - Major misnomer: request returns a @context object > > That I don't know about. > >> - @request does not have a [] method for accessing incoming request >> variables ( nor should it...) > > Any reason why? > > * request.params['foo'] > * request['foo'] > > I use the second form all the time. > >> I've worked around it for now by calling >> @context.post_params['object_class_name'] .... which led up to the >> question in my prev. email, since @context.params would be nicer... > > I'm not sure I follow you here. The parameters come from the "Request" > (requested by browser) and I'm not sure if 'context' better describes > where the parameters come from. IMO they belong to the current > 'request cycle' and not to a 'generic context'. But mind you, that is > just generally, if Nitro returns a `Context` object when you call > `request` then that's just kind of an alias.... > >>> 31 def params >>> 32 return method == :post ? @post_params : @get_params >>> 33 end > > I'm not sure about the contents of those, but IIRC the plan (quite a > while > back) was to do a little more: > > def params > return method == :post ? @get_params.merge(@post_params) : @get_params > end > > (Where I assume the @get_params is an hash.) > > But that might now be obsolete when we have both .get/post_params > available. > > Carry on :P > > Jo > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/e8f25efa/attachment.vcf From rob at robmela.com Mon Oct 1 09:30:42 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 09:30:42 -0400 Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?= In-Reply-To: References: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org> Message-ID: <4700F682.3060803@robmela.com> I think it's actually Chinese -- something about supporting multiple users -- perhaps asking about multithreading? ?? -- does it support ? -- many ??? -- I'm not sure -- something about tasks or users. No compounds match in the Japanese dictionaries, but texts in Chinese do contain this. Looks like Greek to me ( as we say...) Jonathan Buch wrote: > Hi, > > I used google to translate it, but the 2 last kanji aren't translatable > apparently - so I asked Manveru what it meant: > > [11:54] uh, ok, then, did you read the nitro ML? > [11:55] there's some japanese there which I'm unable to > translate :) > [11:55] nitro-general is now on ruby-forum? > [11:56] uh, I do not know :) > [11:56] that's just spam > [11:56] ok :) > [12:01] I'd hate to miss out on something, ah well ^^; > [12:01] :) > [12:02] or it's not spam but the sender hit send way too soon > [12:02] and changed encoding while writing > [12:02] XD > [12:02] in any way just ignore it :) > > Jo > > On Sun, 30 Sep 2007 09:52:42 +0200, George Moschovitis > wrote: > > >> huh? ;-) >> >> -g. >> >> On 9/30/07, Aidan Rogers wrote: >> >>> ??? >>> >>> On Sep 29, 2007, at 8:15 PM, Afa Reg wrote: >>> >>> >>>> ?????? >>>> -- >>>> Posted via http://www.ruby-forum.com/. >>>> _______________________________________________ >>>> 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 >>> >> > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/c7a63e74/attachment.vcf From aidan at yoyo.org Mon Oct 1 09:42:42 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 1 Oct 2007 14:42:42 +0100 (BST) Subject: [Nitro] =?iso-8859-1?q?=E6=94=AF=E6=8C=81=E5=A4=9A=E7=94=A8=E6=88?= =?iso-8859-1?q?=B7=E4=B9=88?= In-Reply-To: References: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org> Message-ID: <31593.199.67.140.242.1191246162.squirrel@yoyo.org> Yeah, that's what I thought too - so I just replied "yes" to see what would happen :-) > Hi, > > I used google to translate it, but the 2 last kanji aren't translatable > apparently - so I asked Manveru what it meant: > > [11:54] uh, ok, then, did you read the nitro ML? > [11:55] there's some japanese there which I'm unable to > translate :) > [11:55] nitro-general is now on ruby-forum? > [11:56] uh, I do not know :) > [11:56] that's just spam > [11:56] ok :) > [12:01] I'd hate to miss out on something, ah well ^^; > [12:01] :) > [12:02] or it's not spam but the sender hit send way too soon > [12:02] and changed encoding while writing > [12:02] XD > [12:02] in any way just ignore it :) > > Jo > > On Sun, 30 Sep 2007 09:52:42 +0200, George Moschovitis > wrote: > >> huh? ;-) >> >> -g. >> >> On 9/30/07, Aidan Rogers wrote: >>> ????????? >>> >>> On Sep 29, 2007, at 8:15 PM, Afa Reg wrote: >>> >>> > ?????????????????? >>> > -- >>> > Posted via http://www.ruby-forum.com/. >>> > _______________________________________________ >>> > 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 >> >> > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From arne at arnebrasseur.net Mon Oct 1 11:24:50 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 01 Oct 2007 23:24:50 +0800 Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?= In-Reply-To: <4700F682.3060803@robmela.com> References: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org> <4700F682.3060803@robmela.com> Message-ID: <47011142.3070301@arnebrasseur.net> Robert Mela schreef: > I think it's actually Chinese -- something about supporting multiple > users -- perhaps asking about multithreading? > > ?? -- does it support > > ? -- many > > ??? -- I'm not sure -- something about tasks or users. No > compounds match in the Japanese dictionaries, but texts in Chinese do > contain this. ?? - (yong4 hu4) - user ? - (me5) - probably used here to make it a question, like ? That last character is simplified so it's Chinese from the mainland (PRC). Two new vocab items for me, very nice :-) (ab) > > Looks like Greek to me ( as we say...) > > Jonathan Buch wrote: >> Hi, >> >> I used google to translate it, but the 2 last kanji aren't translatable >> apparently - so I asked Manveru what it meant: >> >> [11:54] uh, ok, then, did you read the nitro ML? >> [11:55] there's some japanese there which I'm unable to >> translate :) >> [11:55] nitro-general is now on ruby-forum? >> [11:56] uh, I do not know :) >> [11:56] that's just spam >> [11:56] ok :) >> [12:01] I'd hate to miss out on something, ah well ^^; >> [12:01] :) >> [12:02] or it's not spam but the sender hit send way too soon >> [12:02] and changed encoding while writing >> [12:02] XD >> [12:02] in any way just ignore it :) >> >> Jo >> >> On Sun, 30 Sep 2007 09:52:42 +0200, George Moschovitis >> wrote: >> >> >>> huh? ;-) >>> >>> -g. >>> >>> On 9/30/07, Aidan Rogers wrote: >>> >>>> ??? >>>> >>>> On Sep 29, 2007, at 8:15 PM, Afa Reg wrote: >>>> >>>> >>>>> ?????? >>>>> -- >>>>> Posted via http://www.ruby-forum.com/. >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> >> >> > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From rob at robmela.com Mon Oct 1 11:41:00 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 11:41:00 -0400 Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?= In-Reply-To: <47011142.3070301@arnebrasseur.net> References: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org> <4700F682.3060803@robmela.com> <47011142.3070301@arnebrasseur.net> Message-ID: <4701150C.8030704@robmela.com> Japanese would have *? *( ka ) as the question particle at the end of the sentence. I think that Japanese would also have the verb towards the end... Are we off topic yet? Arne Brasseur wrote: > Robert Mela schreef: >> I think it's actually Chinese -- something about supporting multiple >> users -- perhaps asking about multithreading? >> >> ?? -- does it support >> >> ? -- many >> >> ??? -- I'm not sure -- something about tasks or users. No >> compounds match in the Japanese dictionaries, but texts in Chinese do >> contain this. > ?? - (yong4 hu4) - user > ? - (me5) - probably used here to make it a question, like ? > > That last character is simplified so it's Chinese from the mainland > (PRC). > > Two new vocab items for me, very nice :-) > > (ab) -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/e647f418/attachment.vcf From rob at robmela.com Mon Oct 1 12:03:11 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 12:03:11 -0400 Subject: [Nitro] Resending: Re: Request#params In-Reply-To: <4700F578.4000305@robmela.com> References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> <4700F578.4000305@robmela.com> Message-ID: <47011A3F.2050600@robmela.com> Resending With a fresh darcs get ( 30 minutes ago ) and this test program: #!/usr/bin/env ruby require 'ubygems' require 'sqlite3' require 'nitro_and_og' include Nitro require 'nitro/part/admin' # Og model class Book attr_accessor :title, String attr_accessor :author, String end # Controller class Foo def index render_text "Foo" end end Og.create_schema = true Og.use_uuid_primary_keys = true Og.start( :name => "library", :adapter => :sqlite, :evolve_schema => :full ) app=Application.new app.dispatcher.root = Foo app.start Saving a 'Book' produces this exception: ERROR: Error while handling OgAdminController#save() ERROR: undefined method `[]' for nil:NilClass /Users/rmela/nitro2/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in `[]' /Users/rmela/nitro2/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:93:in `save' Line 93 throws the exception: 92 def save 93 klass = name_to_class(request['object_class_name'].to_s) 94 95 if oid = request['oid'] 96 obj = klass[oid.to_s] 97 obj.assign(request, :assign_relations => true, :force_boolean => true) 98 else 99 obj = klass.new 100 obj.assign(request, :assign_relations => true) 101 end I modified that slightly to produce some output: 92 def save 93 if request.nil? 94 puts "OGADMIN request returns 'nil'" 95 else 96 puts "OGADMIN request() returns a #{request.class.name}" 97 puts "OGADMIN request.params returns #{request.params || 'nil'}" 98 puts "OGADMIN request['oid'] returns #{request['oid']}" 99 end which produced this exception: ERROR: undefined method `[]' for nil:NilClass /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in `[]' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:98:in `save' And this output: OGADMIN request() returns a Raw::Context OGADMIN request.params returns nil Robert Mela wrote: > You're right... but.... still.... I swear -- 'request[]' failed in > nitro/part/admin/og/controller.rb in OgAdminController::save > > I'll try a very simple test case to verify -- perhaps some code > included via raw/model/webfile.rb is overriding it somehow... > > The accessors do work as advertised in this case: > > #!/usr/bin/env ruby > require 'nitro_and_og' > include Nitro > > > class Foo > def index > render_text " > request() returns #{request.nil? ? 'nil' : request.class.name } > Parameters > " > end > def paramtest(*args) > %{ > params=#{request.params}
> request[:foo] = #{request[:foo]} > } > end > end > > app=Application.new > app.dispatcher.root = Foo > app.start > > > Jonathan Buch wrote: >> Hi, >> >>> OgAdminController#save attempts to access request data via the >>> 'request' >>> method call: >>> >>> klass = name_to_class(*request*['object_class_name'].to_s) >>> obj.assign(*request*, :assign_relations => true, :force_boolean => >>> true) >> >> yes, I believe that was always like that, as a shortcut to >> request.params. >> >>> A couple problems >>> >>> - Major misnomer: request returns a @context object >> >> That I don't know about. >> >>> - @request does not have a [] method for accessing incoming request >>> variables ( nor should it...) >> >> Any reason why? >> >> * request.params['foo'] >> * request['foo'] >> >> I use the second form all the time. >> >>> I've worked around it for now by calling >>> @context.post_params['object_class_name'] .... which led up to the >>> question in my prev. email, since @context.params would be nicer... >> >> I'm not sure I follow you here. The parameters come from the "Request" >> (requested by browser) and I'm not sure if 'context' better describes >> where the parameters come from. IMO they belong to the current >> 'request cycle' and not to a 'generic context'. But mind you, that is >> just generally, if Nitro returns a `Context` object when you call >> `request` then that's just kind of an alias.... >> >>>> 31 def params >>>> 32 return method == :post ? @post_params : @get_params >>>> 33 end >> >> I'm not sure about the contents of those, but IIRC the plan (quite a >> while >> back) was to do a little more: >> >> def params >> return method == :post ? @get_params.merge(@post_params) : @get_params >> end >> >> (Where I assume the @get_params is an hash.) >> >> But that might now be obsolete when we have both .get/post_params >> available. >> >> Carry on :P >> >> Jo >> > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/33ba411e/attachment.vcf From george.moschovitis at gmail.com Mon Oct 1 13:37:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 1 Oct 2007 20:37:56 +0300 Subject: [Nitro] Updated tutorial In-Reply-To: <4700EB4F.2010708@arnebrasseur.net> References: <4700EB4F.2010708@arnebrasseur.net> Message-ID: Many, many thanks Arne. Once again I am running short on time today and tomorrow, but I 'll be back on Wednesday. keep up the great work. -g. On 10/1/07, Arne Brasseur wrote: > One new chapter to the tutorial, plus a Mercurial repo. > > hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi > /your/local/dir > > That URL should also show you the latest history of changes. > > e-mail me if you want commit access. The basic tutorial will broadly > follow the outline from the Ramaze tutorial : > http://ramaze.rubyforge.org/tutorial/todolist.html > Small example apps are also welcome. > > All content can be freely copied and adapted, e.g. to the Nitro repo, to > Oxyliquit, to Nitro RDoc, blogs, wikis, etc. > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From rob at robmela.com Mon Oct 1 17:06:24 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 17:06:24 -0400 Subject: [Nitro] web file directory fixes Message-ID: <47016150.60200@robmela.com> Is it still correct to spam the group with patches, or should I be sending them directly to George? Anyhow, here are some fixes to get WebFile working with forms & Og Two little things: replace Nitro::Server.public_root with $nitro_current_application.public_dir replace WebFile.upload_root with WebFile.upload_dir, since WebFile defines upload_dir but not upload_root -------------- next part -------------- A non-text attachment was scrubbed... Name: webfile_upload_dir_fix.tar.gz Type: application/x-gzip Size: 18218 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/f4a6dcf8/attachment.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/f4a6dcf8/attachment.vcf From rob at robmela.com Mon Oct 1 17:18:23 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 17:18:23 -0400 Subject: [Nitro] OgAdminController request params fix(?) Message-ID: <4701641F.8070007@robmela.com> I suppose the right thing to do is to figure out why request['oid'] doesn't work inside OgAdminController. In the short term here's a workaround -- not sure whether this half-step should go into the repository or whether we should do the real fix. -------------- next part -------------- A non-text attachment was scrubbed... Name: ogadmin_request_params_fix.tar.gz Type: application/x-gzip Size: 18226 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/f6a310e4/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/f6a310e4/attachment-0001.vcf From rob at robmela.com Mon Oct 1 21:25:42 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 21:25:42 -0400 Subject: [Nitro] Updated tutorial In-Reply-To: References: <4700EB4F.2010708@arnebrasseur.net> Message-ID: <47019E16.3020401@robmela.com> I suppose I should merge the newly expanded http://robmela.com/cheatsheets into this... or copy stuff from this into cheatsheets... working through og relations today... George Moschovitis wrote: > Many, many thanks Arne. > > Once again I am running short on time today and tomorrow, but I 'll be > back on Wednesday. > > keep up the great work. > > -g. > > On 10/1/07, Arne Brasseur wrote: > >> One new chapter to the tutorial, plus a Mercurial repo. >> >> hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi >> /your/local/dir >> >> That URL should also show you the latest history of changes. >> >> e-mail me if you want commit access. The basic tutorial will broadly >> follow the outline from the Ramaze tutorial : >> http://ramaze.rubyforge.org/tutorial/todolist.html >> Small example apps are also welcome. >> >> All content can be freely copied and adapted, e.g. to the Nitro repo, to >> Oxyliquit, to Nitro RDoc, blogs, wikis, etc. >> >> (ab) >> >> -- >> Arne Brasseur >> http://www.arnebrasseur.net >> arne at arnebrasseur.net >> >> >> _______________________________________________ >> 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/918bd19c/attachment.vcf From rob at robmela.com Mon Oct 1 21:46:52 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 01 Oct 2007 21:46:52 -0400 Subject: [Nitro] Ignore the last webfile patch... In-Reply-To: <47016150.60200@robmela.com> References: <47016150.60200@robmela.com> Message-ID: <4701A30C.8090709@robmela.com> Looking through the test specs I saw Nitro::Application.current. Seems better than using $nitro_current_application Robert Mela wrote: > Is it still correct to spam the group with patches, or should I be > sending them directly to George? > > Anyhow, here are some fixes to get WebFile working with forms & Og > > Two little things: > > replace Nitro::Server.public_root with > $nitro_current_application.public_dir > replace WebFile.upload_root with WebFile.upload_dir, since WebFile > defines upload_dir but not upload_root > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: webfile_upload_dir_fix Url: http://rubyforge.org/pipermail/nitro-general/attachments/20071001/6bbcccab/attachment-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071001/6bbcccab/attachment-0001.vcf From george.moschovitis at gmail.com Tue Oct 2 06:11:24 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 2 Oct 2007 13:11:24 +0300 Subject: [Nitro] Facets 1.8.54 problem? Message-ID: Tom, sudo gem install facets does not work for me at the moment. I have to manually download the gem and install it from local disk. Can you please have a look at this? thanks, -g. -- http://gmosx.me.gr http://phidz.com 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/20071002/71ea3ebd/attachment.html From transfire at gmail.com Tue Oct 2 08:13:08 2007 From: transfire at gmail.com (Trans) Date: Tue, 02 Oct 2007 12:13:08 -0000 Subject: [Nitro] Facets 1.8.54 problem? In-Reply-To: References: Message-ID: <1191327188.260383.296270@k79g2000hse.googlegroups.com> On Oct 2, 6:11 am, "George Moschovitis" wrote: > Tom, > > sudo gem install facets does not work for me at the moment. > > I have to manually download the gem and install it from local disk. > > Can you please have a look at this? C:\Documents and Settings\trans>gem install facets Bulk updating Gem source index for: http://gems.rubyforge.org Successfully installed facets-1.8.54 Installing ri documentation for facets-1.8.54... Installing RDoc documentation for facets-1.8.54... C:\Documents and Settings\trans> No problems here. Try it again and let me know exactly what's going wrong. BTW, I'm going to release 2.0.0 today. T. From arne at arnebrasseur.net Wed Oct 3 02:46:54 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 03 Oct 2007 14:46:54 +0800 Subject: [Nitro] Where to define Og relations Message-ID: <47033ADE.40807@arnebrasseur.net> I just found out the hard way that defining a 'belongs_to' relation at the beginning of the model class does not work. Once any managed attributes are defined it does works. require "og" class Word belongs_to WordList attr_accessor :definitions, Array end gives: ./app/model/word.rb:3: undefined method `belongs_to' for Word:Class (NoMethodError) This: class Word attr_accessor :definitions, Array belongs_to WordList end works fine. Alternatively: class Word include Og::RelationDSL belongs_to WordList attr_accessor :definitions, Array end also works fine. It's not clear to me if this is intended or not, has_many seems to work fine once "og" is required. I haven't checked the other types of relations. G, is this known/intended? If so it should be documented. Robert, you could perhaps add this to your cheatsheets? Very nice work BTW! I'm using them all the time now. http://robmela.com/cheatsheets (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From transfire at gmail.com Wed Oct 3 03:27:34 2007 From: transfire at gmail.com (Trans) Date: Wed, 03 Oct 2007 07:27:34 -0000 Subject: [Nitro] ANN: Facets 2.0.0 Message-ID: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> Today I have officially released Facets 2.0.0. gem install facets Facets 2.0.0 represent the project's official push into "production ready" status --a major departure from the 1.x series which was focused on acquiring functionality. For more information about this release see the README below. As with any zero-point release, I expect some minor releases to quickly follow. Please, let me know if you encounter any problems so I can get them fixed right away. Special thanks to everyone that helped me get this release together! T. --- = Ruby Facets http://facets.rubyforge.com "ALL YOUR BASE ARE BELONG TO RUBY" == Introduction Ruby Facets is the single largest collection of general purpose method extensions and system additions for the Ruby programming language. The core extensions is a large collection of methods which extend the core capabilities of Ruby's built-in classes and modules. This collection of extension methods are unique by virtue of their atomicity. The methods are stored in relatively small groups of tightly coupled methods so that each can be required independently. This gives developers the potential for much finer control over which extra methods to bring into their code. The "more" additions are a collection of classes, modules and light meta-systems which constitutes an ever improving source of reusable components. Some very nice additions are provided, from the simple Functor class to a full-blown annotations system. == Installation You can install either via RubyGems or manually: % gem install facets or % tar -xzf facets-2.x.x.tar.gz % cd facets-2.x.x % sudo task/install IMPORTANT! Note that setup.rb is no longer used due to Facets new special layout. == Compatibility with 1.x series. Prior to 2.0, Facets was divided between CORE and MORE --standalone extensions vs. classes and modules, respectively. With 2.0, the idea of CORE has take only a slightly new meaning. Instead CORE now represents the libraries that are considered essential and as such are loaded automatically when using ++require "facets"++. While still primarily made up of extension methods a few classes now belong to core as well. In conjunction with this the extension methods are no longer stored on a per-method basis, but rather in tight knit packs. While dividing the extension methods up on a per-method basis had certain advantages, not the least of which was a simple organization, it proved too granular --rather than "atomic" it was "subatomic". With 2.0 we have address this issue. All the extension methods have now been organized into small tightly related groups. However, being able to require on the basis of a method is still a useful approach, so a compatibility layer for the 1.x series has been created. It makes it possible to load Facets libraries on a per method basis, just as before, via require redirection. For example: require 'facets/core/string/underscore' Will redirect according to the content of the underscore.rb file: require 'facets/string/stylize' So the underscore method will be loaded just as before. But a few other *stylization* methods will be loaded as well. This actually proves a more useful approach b/c often one will want to use one of the related methods as well. == Mission Facets holds to the notion that the more we can reasonably integrate into a common foundation directed toward general needs, the better that foundation will be able to serve everyone. There are a number of advantages here: * Better Code-reuse * Collaborative Improvements * Greater Name Consistency * One-stop Shop and Installation == Status The current status is quite good. While some parts are still considered beta, everything is relatively usable. == Installation The easiest way to install is via RubyGems. On the command line enter: > gem install facets To manually install, unpack the .tar.bz2 package and use the included setup.rb script. For example: > tar -xvzf facets-x.x.x.tar.gz > cd facets-x.x.x > sudo util/setup On Window the last step will be: > ruby util/setup == Usage For detailed usage of any given method or module please refer to the API RDocs. Most are well documented. Assistance in improving documentation though is always appreciated. If you plan to use more then a few of Facets core method it is recommended that you require require the main facility. require 'facets' This loads all the CORE functionality at once. Of course you can use the CORE library piecemeal if you prefer. The general require statement for a core extensions library is: require 'facets//' For example: require 'facets/time/stamp' Most "atoms" contain only a few methods, sometimes only one, but a few exceptions provide quite a few method, such as ++string/indexable.rb+ +. You can load per-class or per-module groups of core methods by requiring the class or module by name. For example" require 'facets/time' Will require all the Time method extensions. Note that some methods that were part of CORE in 1.8 and earlier are now part of MORE libraries. A good example is 'random.rb'. There were separated b/c they had more specialized usecases, where as CORE extensions are intended as general purpose. Using a Facets/MORE library of modules, classes or microframeworks is essentially the same. For example: require 'facets/basicobject' # PLEASE IGNORE THIS FOR NOW It is possible to eliminate the need for the 'facets/' prefix on requires if the Facets libpaths are added to the LOAD_PATH. But this isn't as straight-forward as it is for most libraries b/c of the layout of Facets library. require 'facets-topload' require 'basicobject' Understand that on the off chance that another library has the same name as one of Facets' everything will still work fine. You will just not be able to use the prefixless shortcut to require it. # END IGNORE. Again, for details pertaining to the functionality of each feature, please see the API Docs. == Method File Names Operator method redirect files are stored using English names. For instance for Proc#* is 'proc/op_mul'. For reference, here is the chart. +@ => op_plus_self -@ => op_minus_self + => op_plus - => op_minus ** => op_pow * => op_mul / => op_div % => op_mod ~ => op_tilde <=> => op_cmp << => op_lshift >> => op_rshift < => op_lt > => op_gt === => op_case_eq == => op_equal =~ => op_apply <= => op_lt_eq >= => op_gt_eq | => op_or & => op_and ^ => op_xor []= => op_store [] => op_fetch Facets simply takes the '*' and translates it into a string acceptable to all file systems. Also, if a method ends in '=', '?' or '!' it is simply removed. == Contribute This project thrives on contribution. If you have any extension methods, classes, modules or small frameworks that you think have general applicability and would like to see them included in this project, don't hesitiate to submit. There's a very good chance it will be included. Also, if you have better versions of any thing already included or simply have a patch, they too are more than welcome. We want Ruby Facets to be of the highest quality. == Authors This collection was put together by, and largely written by Thomas Sawyer (aka Trans). He can be reached via email at transfire at gmail.com. Some parts of this collection were written and/or inspired by other persons. Fortunately nearly all were copyrighted under the same open license, the Ruby License. In the few exceptions I have included the copyright notice with the source code. Any code file not specifically labeled shall fall under the Ruby License. In all cases, I have made every effort to give credit where credit is due. You will find these copyrights, thanks and acknowledgments embedded in the source code, and an unobtrusive "Author(s)" section is given in the RDocs. Also see the AUTHORS file for a list of all contributing Rubyists. If anyone is missing from the list, please let me know and I will correct right away. Thanks. == License The collection PER COLLECTION is licensed as follows: Ruby Facets Copyright (c) 2004-2006 Thomas Sawyer Distributed under the terms of the Ruby license. The Ruby license is a dual license that also provides for use of the GPL. Complete texts of both licenses accompany this document (see doc/ COPYING). This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc. 59 Temple Place, Suite 330 Boston, MA 02111-1307 USA Acknowledgments and Copyrights for particular snippets of borrowed code are given in their respective source. All licenses are either compatible with the Ruby license (namely the GPL) or the original author has given permission for inclusion of their code under such license. From arne at arnebrasseur.net Wed Oct 3 03:48:25 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 03 Oct 2007 15:48:25 +0800 Subject: [Nitro] RFC: Let the HTML format report 'charset=utf-8' when $KCODE='UTF8' Message-ID: <47034949.8060405@arnebrasseur.net> This just occurred to me as being a very natural way of doing things. With this patch when you set $KCODE to 'UTF8' (or 'u'), then Nitro's HTML headers contain not just Content-Type: text/html But Content-Type: text/html; charset=utf-8 Wed Oct 3 15:34:45 CST 2007 Arne Brasseur * Let the HTML format report 'charset=utf-8' when $KCODE='UTF8'. When I set $KCODE='UTF8', I expect all subsystems to use utf-8. It's POLS, it's "just standard Ruby", it's how it IMHO should be. My documentation patch from Monday is also included. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20071003.patch Type: text/x-patch Size: 66213 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/a76bdd5d/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20071001.patch Type: text/x-patch Size: 66803 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/a76bdd5d/attachment-0003.bin From george.moschovitis at gmail.com Wed Oct 3 03:59:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 10:59:26 +0300 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> Message-ID: Congratulations for your monumental effort! Can't wait to try it! -g. PS: after a couple of extra-full days I am back ;-) On 10/3/07, Trans wrote: > > Today I have officially released Facets 2.0.0. > > gem install facets > > Facets 2.0.0 represent the project's official push into "production > ready" status --a major departure from the 1.x series which was > focused on acquiring functionality. For more information about this > release see the README below. > > As with any zero-point release, I expect some minor releases to > quickly follow. Please, let me know if you encounter any problems so I > can get them fixed right away. > > Special thanks to everyone that helped me get this release together! > > T. > > --- > > = Ruby Facets > > http://facets.rubyforge.com > > "ALL YOUR BASE ARE BELONG TO RUBY" > > > == Introduction > > Ruby Facets is the single largest collection of general purpose method > extensions and system additions for the Ruby programming language. > > The core extensions is a large collection of methods which extend the > core capabilities of Ruby's built-in classes and modules. This > collection of extension methods are unique by virtue of their > atomicity. The methods are stored in relatively small groups of > tightly coupled methods so that each can be required independently. > This gives developers the potential for much finer control over which > extra methods to bring into their code. > > The "more" additions are a collection of classes, modules and light > meta-systems which constitutes an ever improving source of reusable > components. Some very nice additions are provided, from the simple > Functor class to a full-blown annotations system. > > > == Installation > > You can install either via RubyGems or manually: > > % gem install facets > > or > > % tar -xzf facets-2.x.x.tar.gz > % cd facets-2.x.x > % sudo task/install > > IMPORTANT! Note that setup.rb is no longer used due to Facets new > special layout. > > > == Compatibility with 1.x series. > > Prior to 2.0, Facets was divided between CORE and MORE --standalone > extensions vs. classes and modules, respectively. With 2.0, the idea > of CORE has take only a slightly new meaning. Instead CORE now > represents the libraries that are considered essential and as such are > loaded automatically when using ++require "facets"++. While still > primarily made up of extension methods a few classes now belong to > core as well. In conjunction with this the extension methods are no > longer stored on a per-method basis, but rather in tight knit packs. > While dividing the extension methods up on a per-method basis had > certain advantages, not the least of which was a simple organization, > it proved too granular --rather than "atomic" it was "subatomic". With > 2.0 we have address this issue. All the extension methods have now > been organized into small tightly related groups. > > However, being able to require on the basis of a method is still a > useful approach, so a compatibility layer for the 1.x series has been > created. It makes it possible to load Facets libraries on a per method > basis, just as before, via require redirection. > > For example: > > require 'facets/core/string/underscore' > > Will redirect according to the content of the underscore.rb file: > > require 'facets/string/stylize' > > So the underscore method will be loaded just as before. But a few > other *stylization* methods will be loaded as well. This actually > proves a more useful approach b/c often one will want to use one of > the related methods as well. > > > == Mission > > Facets holds to the notion that the more we can reasonably integrate > into a common foundation directed toward general needs, the better > that foundation will be able to serve everyone. There are a number of > advantages here: > > * Better Code-reuse > * Collaborative Improvements > * Greater Name Consistency > * One-stop Shop and Installation > > > == Status > > The current status is quite good. While some parts are still > considered beta, everything is relatively usable. > > > == Installation > > The easiest way to install is via RubyGems. On the command line enter: > > > gem install facets > > To manually install, unpack the .tar.bz2 package and use the included > setup.rb script. For example: > > > tar -xvzf facets-x.x.x.tar.gz > > cd facets-x.x.x > > sudo util/setup > > On Window the last step will be: > > > ruby util/setup > > > == Usage > > For detailed usage of any given method or module please refer to the > API RDocs. Most are well documented. Assistance in improving > documentation though is always appreciated. > > If you plan to use more then a few of Facets core method it is > recommended that you require require the main facility. > > require 'facets' > > This loads all the CORE functionality at once. > > Of course you can use the CORE library piecemeal if you prefer. The > general require statement for a core extensions library is: > > require 'facets//' > > For example: > > require 'facets/time/stamp' > > Most "atoms" contain only a few methods, sometimes only one, but a few > exceptions provide quite a few method, such as ++string/indexable.rb+ > +. > > You can load per-class or per-module groups of core methods by > requiring the class or module by name. For example" > > require 'facets/time' > > Will require all the Time method extensions. > > Note that some methods that were part of CORE in 1.8 and earlier are > now part of MORE libraries. A good example is 'random.rb'. There were > separated b/c they had more specialized usecases, where as CORE > extensions are intended as general purpose. > > Using a Facets/MORE library of modules, classes or microframeworks is > essentially the same. For example: > > require 'facets/basicobject' > > # PLEASE IGNORE THIS FOR NOW > > It is possible to eliminate the need for the 'facets/' prefix on > requires if the Facets libpaths are added to the LOAD_PATH. But this > isn't as straight-forward as it is for most libraries b/c of the > layout of Facets library. > > require 'facets-topload' > require 'basicobject' > > Understand that on the off chance that another library has the same > name as one of Facets' everything will still work fine. You will just > not be able to use the prefixless shortcut to require it. > > # END IGNORE. > > Again, for details pertaining to the functionality of each feature, > please see the API Docs. > > > == Method File Names > > Operator method redirect files are stored using English names. For > instance for Proc#* is 'proc/op_mul'. > > For reference, here is the chart. > > +@ => op_plus_self > -@ => op_minus_self > + => op_plus > - => op_minus > ** => op_pow > * => op_mul > / => op_div > % => op_mod > ~ => op_tilde > <=> => op_cmp > << => op_lshift > >> => op_rshift > < => op_lt > > => op_gt > === => op_case_eq > == => op_equal > =~ => op_apply > <= => op_lt_eq > >= => op_gt_eq > | => op_or > & => op_and > ^ => op_xor > []= => op_store > [] => op_fetch > > Facets simply takes the '*' and translates it into a string acceptable > to all file systems. Also, if a method ends in '=', '?' or '!' it is > simply removed. > > > == Contribute > > This project thrives on contribution. > > If you have any extension methods, classes, modules or small > frameworks that you think have general applicability and would like to > see them included in this project, don't hesitiate to submit. There's > a very good chance it will be included. Also, if you have better > versions of any thing already included or simply have a patch, they > too are more than welcome. We want Ruby Facets to be of the highest > quality. > > > == Authors > > This collection was put together by, and largely written by Thomas > Sawyer (aka Trans). He can be reached via email at transfire at > gmail.com. > > Some parts of this collection were written and/or inspired by other > persons. Fortunately nearly all were copyrighted under the same open > license, the Ruby License. In the few exceptions I have included the > copyright notice with the source code. > > Any code file not specifically labeled shall fall under the Ruby > License. > > In all cases, I have made every effort to give credit where credit is > due. You will find these copyrights, thanks and acknowledgments > embedded in the source code, and an unobtrusive "Author(s)" section is > given in the RDocs. > > Also see the AUTHORS file for a list of all contributing Rubyists. > > If anyone is missing from the list, please let me know and I will > correct right away. Thanks. > > > == License > > The collection PER COLLECTION is licensed as follows: > > Ruby Facets > Copyright (c) 2004-2006 Thomas Sawyer > > Distributed under the terms of the Ruby license. > > The Ruby license is a dual license that also provides for use of the > GPL. Complete texts of both licenses accompany this document (see doc/ > COPYING). > > This program is free software; you can redistribute it and/or > modify it under the terms of the GNU General Public License as > published by the Free Software Foundation; either version 2 of > the License, or (at your option) any later version. > > This program is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU General Public License for more details. > > You should have received a copy of the GNU General Public License > along with this program; if not, write to the > Free Software Foundation, Inc. > 59 Temple Place, Suite 330 > Boston, MA 02111-1307 USA > > Acknowledgments and Copyrights for particular snippets of borrowed > code are given in their respective source. All licenses are either > compatible with the Ruby license (namely the GPL) or the original > author has given permission for inclusion of their code under such > license. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071003/754f419a/attachment.html From george.moschovitis at gmail.com Wed Oct 3 04:05:50 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 11:05:50 +0300 Subject: [Nitro] [Patch] FormHelper RDoc improvement In-Reply-To: <4700E970.2000904@arnebrasseur.net> References: <4700E970.2000904@arnebrasseur.net> Message-ID: thanks. On 10/1/07, Arne Brasseur wrote: > > This adds top-level documentation to FormHelper and fixes an interface > change that wasn't reflected yet in the comments (f.property -> > f.attribute). > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071003/a0835e79/attachment.html From george.moschovitis at gmail.com Wed Oct 3 04:07:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 11:07:40 +0300 Subject: [Nitro] Request#params In-Reply-To: <47005629.60208@robmela.com> References: <47005629.60208@robmela.com> Message-ID: @post_params/@get_params are Dictionary objects. And I needed a version of them as Hash. Dictionary is not that compatible with Hash as someone would like. -g. On 10/1/07, Robert Mela wrote: > > Not sure what the intent is here in request.rb, module Raw, included in > class Context > > 31 def params > 32 if method == :post > 33 @post_params.instance_variable_get("@hash") > 34 else > 35 @get_params.instance_variable_get("@hash") > 36 end > 37 end > > > @post_params is itself a hash and an instance variable on Context, and > @post_params.instance_variable_get( "@hash" ) returns nil. > > Anything wrong with doing this instead? > > 31 def params > 32 return method == :post ? @post_params : @get_params > 33 end > > If that's acceptable I'll add it to the patches I'm preparing. > > thx. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071003/85c4dc8b/attachment-0001.html From george.moschovitis at gmail.com Wed Oct 3 04:09:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 11:09:21 +0300 Subject: [Nitro] Request#params In-Reply-To: References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> Message-ID: > > * request.params['foo'] > * request['foo'] > > I use the second form all the time. > I use request["foo"] too... btw you can also use: request[:foo] one more hidden 0.50.0 new feature? -g. -- http://gmosx.me.gr http://phidz.com 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/20071003/66e60730/attachment.html From george.moschovitis at gmail.com Wed Oct 3 04:19:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 11:19:58 +0300 Subject: [Nitro] web file directory fixes In-Reply-To: <47016150.60200@robmela.com> References: <47016150.60200@robmela.com> Message-ID: > > Is it still correct to spam the group with patches, or should I be > sending them directly to George? please 'spam' the group ;-) thanks for the patch. -g. -- http://gmosx.me.gr http://phidz.com 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/20071003/401d38b0/attachment.html From george.moschovitis at gmail.com Wed Oct 3 04:24:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 11:24:40 +0300 Subject: [Nitro] Where to define Og relations In-Reply-To: <47033ADE.40807@arnebrasseur.net> References: <47033ADE.40807@arnebrasseur.net> Message-ID: > > It's not clear to me if this is intended or not, has_many seems to work > fine once "og" is required. I haven't checked the other types of > relations. This is known/intended. Are you sure that has_many works without defining a serializable attribute first? This is what I use: class Word is Og::Model belongs_to :user end the shortcut is that calling attr_accessor :filed, Type automatically includes Og::Model. I hope this helps -g. -- http://gmosx.me.gr http://phidz.com 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/20071003/d3863993/attachment.html From amusic at freemail.gr Wed Oct 3 06:00:40 2007 From: amusic at freemail.gr (amusic at freemail.gr) Date: Wed, 3 Oct 2007 13:00:40 +0300 Subject: [Nitro] Installing Nitro on Windows in 11 steps Message-ID: <4703684860cde7.15282900@freemail.gr> Hello everyone, I'm new to the list and I've been told that some people have been having some trouble installing Nitro on a Windows system. So for those having trouble here's a 11 step checklist. (I assume that you've already installed Ruby and MySQL on your system) 1) Download Darcs from www.darcs.net and decompress it in any directory 2*) Add the darcs root folder in the PATH environmental variable (i.e. C:\Darcs;) 3) Download the latest Nitro version from the repository through darcs by: going to the directory you want to store nitro and typing in command line: `darcs get --partial http://repo.nitroproject.org nitro` 4) Find the RUBYOPTS environmental variable (it should already contain `-rubygems` in it and after it add the following: -I[PATH_TO_NITRO]\nitro\lib -I[PATH_TO_NITRO]\nitro\vendor -I[PATH_TO_NITRO]\og\lib -I[PATH_TO_NITRO]\glue\lib -I[PATH_TO_NITRO]\raw\lib * replace [PATH_TO_NITRO] with the path to your nitro folder (example: C:\nitro) 5) Add the same directories in the PATH environmental variable as well (ex. C:\nitro\nitro\lib;C:\nitro\nitro\vendor;C:\nitro\og\lib;C:\nitro\glue\lib;C:\nitro\raw\lib) 6) Go to the Nitro root directory and type: `darcs pull` and select "yes" to all patch prompts 7) Install the "facets" gem (gem install facets) 8) Install the "redcloth" gem (gem install redcloth) 9) Install the "xmlSimple" gem (gem install xml-simple) 10) Install the "mysql" gem (gem install mysql) [Select option 1] 11) Install the "uuidtools" gem (gem install uuidtools) * In order to get to your system's environmental variables, right click on your "My Computer" icon and select `Properties`. Select the `Advanced` Tab and on the bottom click on the `Environmental Variables` button. I intend to write an installer to automagically install Nitro on a windows system (and do all the dirty work) as well as keeping it up to date. Hope this helps. From george.moschovitis at gmail.com Wed Oct 3 07:11:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 14:11:55 +0300 Subject: [Nitro] Installing Nitro on Windows in 11 steps In-Reply-To: <4703684860cde7.15282900@freemail.gr> References: <4703684860cde7.15282900@freemail.gr> Message-ID: Welcome Sotiri ;-) thanks for this info! -g. On 10/3/07, amusic at freemail.gr wrote: > > > Hello everyone, I'm new to the list and I've been told that some people > have been having some trouble installing Nitro on a Windows system. So for > those having trouble here's a 11 step checklist. (I assume that you've > already installed Ruby and MySQL on your system) > > 1) Download Darcs from www.darcs.net and decompress it in any directory > > 2*) Add the darcs root folder in the PATH environmental variable (i.e. > C:\Darcs;) > > 3) Download the latest Nitro version from the repository through darcs by: > going to the directory you want to store nitro and > typing in command line: `darcs get --partial > http://repo.nitroproject.org nitro` > > 4) Find the RUBYOPTS environmental variable (it should already contain > `-rubygems` in it and after it add the following: > > -I[PATH_TO_NITRO]\nitro\lib -I[PATH_TO_NITRO]\nitro\vendor > -I[PATH_TO_NITRO]\og\lib -I[PATH_TO_NITRO]\glue\lib > -I[PATH_TO_NITRO]\raw\lib > > * replace [PATH_TO_NITRO] with the path to your nitro folder (example: > C:\nitro) > > 5) Add the same directories in the PATH environmental variable as well > (ex. > C:\nitro\nitro\lib;C:\nitro\nitro\vendor;C:\nitro\og\lib;C:\nitro\glue\lib;C:\nitro\raw\lib) > > 6) Go to the Nitro root directory and type: `darcs pull` and select "yes" > to all patch prompts > > 7) Install the "facets" gem (gem install facets) > 8) Install the "redcloth" gem (gem install redcloth) > 9) Install the "xmlSimple" gem (gem install xml-simple) > 10) Install the "mysql" gem (gem install mysql) [Select option 1] > 11) Install the "uuidtools" gem (gem install uuidtools) > > * In order to get to your system's environmental variables, right click on > your "My Computer" icon and select `Properties`. Select the `Advanced` Tab > and on the bottom click on the `Environmental Variables` button. > > I intend to write an installer to automagically install Nitro on a windows > system (and do all the dirty work) as well as keeping it up to date. > > Hope this helps. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071003/6a59bc63/attachment.html From rob at robmela.com Wed Oct 3 08:21:20 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 08:21:20 -0400 Subject: [Nitro] Where to define Og relations In-Reply-To: <47033ADE.40807@arnebrasseur.net> References: <47033ADE.40807@arnebrasseur.net> Message-ID: <47038940.6000804@robmela.com> Some of the relation declarations are for the benefit of Og in schema generation. Others are for the benefit of Forms in generating form elements to bind relations ( see the views in nitro/part/admin/og ) Arne Brasseur wrote: > I just found out the hard way that defining a 'belongs_to' relation at > the beginning of the model class does not work. Once any managed > attributes are defined it does works. > > require "og" > > class Word > belongs_to WordList > > attr_accessor :definitions, Array > end > > gives: > ./app/model/word.rb:3: undefined method `belongs_to' for Word:Class > (NoMethodError) > > This: > > class Word > attr_accessor :definitions, Array > > belongs_to WordList > end > > works fine. > > Alternatively: > > class Word > include Og::RelationDSL > belongs_to WordList > > attr_accessor :definitions, Array > end > > also works fine. > > It's not clear to me if this is intended or not, has_many seems to work > fine once "og" is required. I haven't checked the other types of relations. > > G, is this known/intended? If so it should be documented. Robert, you > could perhaps add this to your cheatsheets? Very nice work BTW! I'm > using them all the time now. > > http://robmela.com/cheatsheets > > (ab) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/fd7e8ce9/attachment.vcf From rob at robmela.com Wed Oct 3 08:26:29 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 08:26:29 -0400 Subject: [Nitro] Request#params In-Reply-To: References: <47005629.60208@robmela.com> <47005B96.9090401@robmela.com> Message-ID: <47038A75.8090603@robmela.com> It's not working in OgAdminController. Perhaps it's some interaction with WebFile...? Try OgAdminController with this model (written from memory -- some changes might be needed....) In app.rb: require 'raw/model/webfile' Model: class Asset attr_accessor :name, String attr_accessor :file, WebFile end George Moschovitis wrote: > > * request.params['foo'] > * request['foo'] > > I use the second form all the time. > > > I use request["foo"] too... > > btw you can also use: > > request[:foo] > > one more hidden 0.50.0 new feature? > > -g. > > > -- > http://gmosx.me.gr > http://phidz.com > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/1fb60d35/attachment.vcf From rob at robmela.com Wed Oct 3 08:35:05 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 08:35:05 -0400 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: <47038940.6000804@robmela.com> References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> Message-ID: <47038C79.6020804@robmela.com> Sorry... I misunderstood the question... I'm up to my eyeballs in exploring Og right now, and its filtering everything I see. I look at my wife and kids and visualize the generated foreign key attributes that join us.... :) Thanks for the kudos. What I'd like more than my cheatsheets is a collaborative effort to produce documentation similar to the PHP docs -- http://www.php.net/docs.php. I see it as a nitro app, with content in DocBook or something similar. Perhaps Nitro elements could be created named similarly to DocBook elements, such that the docbook pages can be served up directly, as-is. The same pages could be used later to generate a print book -- produced by a community(!) with proceeds going back to the project. Would someone be willing to host that in a mercurial or darcs archive? thx. Robert Mela wrote: > Some of the relation declarations are for the benefit of Og in schema > generation. > > Others are for the benefit of Forms in generating form elements to > bind relations ( see the views in nitro/part/admin/og ) > > Arne Brasseur wrote: >> >> G, is this known/intended? If so it should be documented. Robert, you >> could perhaps add this to your cheatsheets? Very nice work BTW! I'm >> using them all the time now. >> >> http://robmela.com/cheatsheets >> >> (ab) >> >> > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/3ea97df4/attachment-0001.vcf From rob at robmela.com Wed Oct 3 08:47:55 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 08:47:55 -0400 Subject: [Nitro] Installing Nitro on Windows in 11 steps In-Reply-To: <4703684860cde7.15282900@freemail.gr> References: <4703684860cde7.15282900@freemail.gr> Message-ID: <47038F7B.5050401@robmela.com> This is extremely thourough, complete, and well organized. I'm probably not the only one thinking that you should sign up at oxyliquit.de and post this as a tip... I'd be thrilled if folks could add it to their own collections ( e.g., if Arne wanted to add it to thedailynitro, or I to cheatsheets ). I envision doing that with credit to the author being one of the first things on the page -- author's name, and if desired, a link to the author's web site. Maybe nitroproject.org could host a "From the Archives" section, with gems like this as entries, indexed by category and tag, with descriptive links. amusic at freemail.gr wrote: > Hello everyone, I'm new to the list and I've been told that some people have been having some trouble installing Nitro on a Windows system. So for those having trouble here's a 11 step checklist. (I assume that you've already installed Ruby and MySQL on your system) > > 1) Download Darcs from www.darcs.net and decompress it in any directory > > 2*) Add the darcs root folder in the PATH environmental variable (i.e. C:\Darcs;) > > 3) Download the latest Nitro version from the repository through darcs by: > going to the directory you want to store nitro and > typing in command line: `darcs get --partial http://repo.nitroproject.org nitro` > > 4) Find the RUBYOPTS environmental variable (it should already contain `-rubygems` in it and after it add the following: > > -I[PATH_TO_NITRO]\nitro\lib -I[PATH_TO_NITRO]\nitro\vendor -I[PATH_TO_NITRO]\og\lib -I[PATH_TO_NITRO]\glue\lib -I[PATH_TO_NITRO]\raw\lib > > * replace [PATH_TO_NITRO] with the path to your nitro folder (example: C:\nitro) > > 5) Add the same directories in the PATH environmental variable as well > (ex. C:\nitro\nitro\lib;C:\nitro\nitro\vendor;C:\nitro\og\lib;C:\nitro\glue\lib;C:\nitro\raw\lib) > > 6) Go to the Nitro root directory and type: `darcs pull` and select "yes" to all patch prompts > > 7) Install the "facets" gem (gem install facets) > 8) Install the "redcloth" gem (gem install redcloth) > 9) Install the "xmlSimple" gem (gem install xml-simple) > 10) Install the "mysql" gem (gem install mysql) [Select option 1] > 11) Install the "uuidtools" gem (gem install uuidtools) > > * In order to get to your system's environmental variables, right click on your "My Computer" icon and select `Properties`. Select the `Advanced` Tab and on the bottom click on the `Environmental Variables` button. > > I intend to write an installer to automagically install Nitro on a windows system (and do all the dirty work) as well as keeping it up to date. > > Hope this helps. > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/01f45f9b/attachment.vcf From arne at arnebrasseur.net Wed Oct 3 08:52:10 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 03 Oct 2007 20:52:10 +0800 Subject: [Nitro] Nitro on Apache Message-ID: <4703907A.8090503@arnebrasseur.net> I'm for the first time trying to actually deploy a Nitro app on my shared hosting account. I'm trying to use FastCGI since that's what I had success with using Rails. It took some tweaking of the FastCGI adapter, it seems unmaintained. I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi that just loads Nitro, sets the mode to :live and requires app.rb. If I run it gives the two green lines : 03/10 05:13:11 INFO: Og uses the Mysql store. 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, listening at 0.0.0.0:9000 My .htaccess should be good. Now if I visit the site I get a server 500 error. The error log mentions : [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58] FastCGI: incomplete headers (0 bytes) received from server "/home/ar nebrasseur/subdomains/vocab/dispatch.fcgi" Have other people gotten this to work? Do I have other options having only limited control over the apache configuration? Thanks for any pointers! (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From george.moschovitis at gmail.com Wed Oct 3 09:01:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 3 Oct 2007 16:01:26 +0300 Subject: [Nitro] Nitro on Apache In-Reply-To: <4703907A.8090503@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> Message-ID: I use Apache + mod_proxy_ballancer + Mongrel. I will try to prepare a *short* tutorial. -g. On 10/3/07, Arne Brasseur wrote: > > I'm for the first time trying to actually deploy a Nitro app on my > shared hosting account. I'm trying to use FastCGI since that's what I > had success with using Rails. It took some tweaking of the FastCGI > adapter, it seems unmaintained. > > I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi > that just loads Nitro, sets the mode to :live and requires app.rb. If I > run it gives the two green lines : > > 03/10 05:13:11 INFO: Og uses the Mysql store. > 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, listening at > 0.0.0.0:9000 > > My .htaccess should be good. Now if I visit the site I get a server 500 > error. The error log mentions : > > [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58] FastCGI: > incomplete headers (0 bytes) received from server "/home/ar > nebrasseur/subdomains/vocab/dispatch.fcgi" > > Have other people gotten this to work? Do I have other options having > only limited control over the apache configuration? > > Thanks for any pointers! > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071003/7951a6e1/attachment.html From rob at robmela.com Wed Oct 3 09:08:35 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 09:08:35 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: <4703907A.8090503@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> Message-ID: <47039453.1020608@robmela.com> fcgi is not worth the trouble. I suggest running Nitro standalone and using Apache's reverse proxying features as a front-end. With Apache 2.2 there's mod_proxy_balancer, which is *very* nice. With both Apache 2.0 and 2.2 you can use mod_rewrite like this: ServerName robmela.com ServerAlias www.robmela.com ServerAlias blog.robmela.com RewriteEngine On RewriteRule ^/admin(.*) https://nb.robmela.com/admin$1 [L,R] RewriteRule ^/(.*) http://127.0.0.1:9001/$1 [L,P] #ProxyRequests off #ProxyPass / http://127.0.0.1:9001/ #ProxyPassReverse / http://127.0.0.1:9001/ #ProxyPreserveHost on There is one caveat for heavily loaded sites or applications with long-running pages... which I'll get into later as I'm writing an Apache / Mongrel how-to that covers some gotchas. Arne Brasseur wrote: > I'm for the first time trying to actually deploy a Nitro app on my > shared hosting account. I'm trying to use FastCGI since that's what I > had success with using Rails. It took some tweaking of the FastCGI > adapter, it seems unmaintained. > > I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi > that just loads Nitro, sets the mode to :live and requires app.rb. If I > run it gives the two green lines : > > 03/10 05:13:11 INFO: Og uses the Mysql store. > 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, listening at > 0.0.0.0:9000 > > My .htaccess should be good. Now if I visit the site I get a server 500 > error. The error log mentions : > > [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58] FastCGI: > incomplete headers (0 bytes) received from server "/home/ar > nebrasseur/subdomains/vocab/dispatch.fcgi" > > Have other people gotten this to work? Do I have other options having > only limited control over the apache configuration? > > Thanks for any pointers! > > (ab) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/62c0103f/attachment.vcf From rob at robmela.com Wed Oct 3 09:25:49 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 09:25:49 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> Message-ID: <4703985D.8@robmela.com> I'm preparing a lengthy how-to. I've spent many pressured hours on at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html NB: There's a major problem with the way Mongrel 1.0.1 handles connection limits. If it's over it's configured connection limit It accepts, then immediately closes with no processing. Things would work much better with mod_proxy_balancer if monger were modified ( perhaps configurably ) to simply not call accept() when it's reached its configured connection limit. The problem is less likely to be triggered if Mongrel is running Nitro, but it's still a flaw. It's a MAJOR headache on a busy Rails site with slow-loading pages. For details on mod_proxy and mod_proxy_balancer, look at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html There's also the mod_rewrite trick for handling static files -- cuts request times from tens of milliseconds to tenths of milliseconds, and with a lot less CPU -- very important on asset-heavy, busy sites... see the RewriteCond... RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f RewriteRule (.*) $1 [L] ProxyPass / balancer://myserverpool/ #### NB: trailing slash ProxyPassReverse / balancer://myserverpool/ ### NB: trailing slash ProxyPreserveHost on # no trailing slash BalancerMember http://192.168.10.10:10000 keepalive=on max=10 lbset=0 timeout=1 BalancerMember http://192.168.10.10:10001 keepalive=on max=10 lbset=1 BalancerMember http://192.168.10.11:10000 keepalive=on max=10 lbset=0 timeout=1 I've also got a Apache module that I'm polishing up that very simply handles very large hashed directory caches ( millions of entries ). Very useful for rails on large sites: http://myapp.mysite.net/image/1782.gif or /myappdir/public/image/1/7/8/2/1782.gif.cache George Moschovitis wrote: > I use Apache + mod_proxy_ballancer + Mongrel. > > I will try to prepare a *short* tutorial. > > -g. > > > > On 10/3/07, *Arne Brasseur* < arne at arnebrasseur.net > > wrote: > > I'm for the first time trying to actually deploy a Nitro app on my > shared hosting account. I'm trying to use FastCGI since that's what I > had success with using Rails. It took some tweaking of the FastCGI > adapter, it seems unmaintained. > > I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi > that just loads Nitro, sets the mode to :live and requires app.rb. > If I > run it gives the two green lines : > > 03/10 05:13:11 INFO: Og uses the Mysql store. > 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, > listening at > 0.0.0.0:9000 > > My .htaccess should be good. Now if I visit the site I get a > server 500 > error. The error log mentions : > > [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58 > ] FastCGI: > incomplete headers (0 bytes) received from server "/home/ar > nebrasseur/subdomains/vocab/dispatch.fcgi" > > Have other people gotten this to work? Do I have other options having > only limited control over the apache configuration? > > Thanks for any pointers! > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://gmosx.me.gr > http://phidz.com > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/f1e11ab1/attachment.vcf From rob at robmela.com Wed Oct 3 11:05:58 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 11:05:58 -0400 Subject: [Nitro] problem posting code on oxyliquit Message-ID: <4703AFD6.8030205@robmela.com> I tried to submit this as an oxyliquit tutorial but goofed on the initial post -- now when I edit and submit the changes it's not saved correctly... # # Using Apache 2.0 and 2.2 as a reverse proxy # for a Nitro application. # # Note that Apache 2.2 offers a load balancing # proxy. Oxyliquit tutorial forthcoming... # # This scheme is based on Apache's NameVirtualHost # feature. The following line should appear # in your httpd.conf file: # # NameVirtualHost *:80 # # Next, add the following. # # You *could* put this directly in httpd.conf. # # But with large numbers of virtual hosts, # it makes sense to have an include directory # under your_apache_install/conf and add this # to httpd.conf: # # Include conf/vhosts/* # # or # # Include conf/vhosts/foo.com # Include conf/vhosts/bar.com # ServerName myhost.com ServerAlias www.myhost.com ServerAlias myalias.net ServerAlias www.myalias.net RewriteEngine On ProxyRequests off ProxyPass / http://127.0.0.1:9001/ ProxyPassReverse / http://127.0.0.1:9001/ ProxyPreserveHost on # If your application exposes administrative URLs that # you want to protect, then you can redirect to an ssl # port on the server. RewriteRule ^/admin(.*) https://admin.myhost.com/admin$1 [L,R] RewriteRule ^/(.*) http://127.0.0.1:9001/$1 [L,P] # # If you want an SSL port for secure URLs for your app, # create an additional vhost # # Again, remember to add this somewhere before it: # # NameVirtualHost *:443 # ServerName admin.myhost.com ServerAlias topsecret.myhost.com ProxyRequests off ProxyPass / http://127.0.0.1:9001/ ProxyPassReverse / http://127.0.0.1:9001/ ProxyPreserveHost on AuthName "Restricted Access" AuthType Basic Require user YoursTruly AuthUserFile /top/secret/path/htpasswd AuthName "Restricted Access" AuthType Basic Require group SiteEditors AuthUserFile /top/secret/path/htpasswd SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /path-to-cert-files/ssl.crt/self_signed.cert SSLCertificateKeyFile /path-to-cert-files/ssl.key/self_signed.key SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/91e6027e/attachment.vcf From arne at arnebrasseur.net Wed Oct 3 11:12:21 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 03 Oct 2007 23:12:21 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: <47039453.1020608@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <47039453.1020608@robmela.com> Message-ID: <4703B155.3010508@arnebrasseur.net> Can I do this from .htaccess? (ab) Robert Mela schreef: > fcgi is not worth the trouble. > > I suggest running Nitro standalone and using Apache's reverse proxying > features as a front-end. > > With Apache 2.2 there's mod_proxy_balancer, which is *very* nice. > > With both Apache 2.0 and 2.2 you can use mod_rewrite like this: > > > > ServerName robmela.com > ServerAlias www.robmela.com > ServerAlias blog.robmela.com > RewriteEngine On > RewriteRule ^/admin(.*) https://nb.robmela.com/admin$1 [L,R] > RewriteRule ^/(.*) http://127.0.0.1:9001/$1 [L,P] > #ProxyRequests off > #ProxyPass / http://127.0.0.1:9001/ > #ProxyPassReverse / http://127.0.0.1:9001/ > #ProxyPreserveHost on > > > There is one caveat for heavily loaded sites or applications with > long-running pages... which I'll get into later as I'm writing an > Apache / Mongrel how-to that covers some gotchas. > > Arne Brasseur wrote: >> I'm for the first time trying to actually deploy a Nitro app on my >> shared hosting account. I'm trying to use FastCGI since that's what I >> had success with using Rails. It took some tweaking of the FastCGI >> adapter, it seems unmaintained. >> >> I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi >> that just loads Nitro, sets the mode to :live and requires app.rb. If >> I run it gives the two green lines : >> >> 03/10 05:13:11 INFO: Og uses the Mysql store. >> 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, listening >> at 0.0.0.0:9000 >> >> My .htaccess should be good. Now if I visit the site I get a server >> 500 error. The error log mentions : >> >> [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58] FastCGI: >> incomplete headers (0 bytes) received from server "/home/ar >> nebrasseur/subdomains/vocab/dispatch.fcgi" >> >> Have other people gotten this to work? Do I have other options having >> only limited control over the apache configuration? >> >> Thanks for any pointers! >> >> (ab) >> >> > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From wyhaines at gmail.com Wed Oct 3 11:18:11 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 3 Oct 2007 08:18:11 -0700 Subject: [Nitro] Nitro on Apache In-Reply-To: <4703985D.8@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> Message-ID: On 10/3/07, Robert Mela wrote: > NB: There's a major problem with the way Mongrel 1.0.1 handles > connection limits. If it's over it's configured connection limit It > accepts, then immediately closes with no processing. Things would work > much better with mod_proxy_balancer if monger were modified ( perhaps > configurably ) to simply not call accept() when it's reached its > configured connection limit. Use evented_mongrel or swiftiply w/ swiftiplied_mongrel. It will help this. It was an oversight on my part that evented mongrel doesn't use epoll if it is available. This has been patched and will be available in the next version, which means you could have more than 1024 (the limit on select()) connections queued up without any problems, if you had to (on Linux 2.6.x based systems). > The problem is less likely to be triggered if Mongrel is running Nitro, > but it's still a flaw. It's a MAJOR headache on a busy Rails site with > slow-loading pages. evented_mongrel will let you queue up lots of requests without incurring the RAM and performance killing overhead of threads in Mongrel. Swiftiply with swiftiplied_mongrel will load balance your slow requests across your backends optimally, with no crowding on any one backend, while again ensuring that you don't have RAM and performance killing overhead of threads in Mongrel. George had said that he was going to make sure Nitro 0.50 had builtin support for using both of these. I am not sure of the status of that or if he needs anything from me. George? Kirk Haines From rob at robmela.com Wed Oct 3 12:10:52 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 12:10:52 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> Message-ID: <4703BF0C.2010003@robmela.com> An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071003/50b9b3fc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/50b9b3fc/attachment.vcf From john at oxyliquit.de Wed Oct 3 12:53:53 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 03 Oct 2007 18:53:53 +0200 Subject: [Nitro] Nitro on Apache In-Reply-To: <47039453.1020608@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <47039453.1020608@robmela.com> Message-ID: Hi, thank you for adding the tutorial (it is however quite short and might have fit better into a tip). I had to clean up a little due to a slight misunderstanding between you and oxy which was more like 'wtf' ;). It led me on a small debugging trip to find out why there wasn't any content. Anyway, for tutorials the "description" field is supposed to be a small entry on what the tutorial contains. This is shown on the front page. Inside the tutorial then there should be one or more pages which you can add. This is available to help structure your tutorial in easyly digestable chunks. Anyway, thanks for using oxywtf. ^_^ Feel free to change my hastily added description. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Oct 3 12:58:35 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 03 Oct 2007 18:58:35 +0200 Subject: [Nitro] Installing Nitro on Windows in 11 steps In-Reply-To: <4703684860cde7.15282900@freemail.gr> References: <4703684860cde7.15282900@freemail.gr> Message-ID: Hi, and welcome! > Hope this helps. Very concise and easy to read, like Rob already said, I'd be happy if you could add this as an Oxyiliquit tip[1]. Thank you very much for supporting the poor windows guys, they don't get too much love these days! ^_^ Jo [1] http://www.oxyliquit.de/add/tip -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From wyhaines at gmail.com Wed Oct 3 13:25:34 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 3 Oct 2007 10:25:34 -0700 Subject: [Nitro] Nitro on Apache In-Reply-To: <4703BF0C.2010003@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> Message-ID: > I'm worried about queuing. > > I'm working to remediate a Rails app ( not mine ) that can take as long as > a minute to generate certain pages. > > Consider the case where mod_proxy_balancer sends a request to an application > server that's 1 second into a 60-second rails page. With queuing, wouldn't > the second request sit in the queue for 59 seconds while waiting for the > first request to complete? Yes. This brings up an interesting issue, though. 1 minute to render a page is horrific, and if everything is that slow, there are no good solutions. But if the app only has certain pages that are that slow, while the rest are fast, it brings up an interesting, solveable scaling quandry. > The current workaround is to have a hundred of Rails app server instances > chewing up huge amounts of RAM. I would quite happily trade that in for the > memory and performance overhead of whatever multiplexing or multithreading > scheme is used in the app server. All I need is a guarantee that the app > server will not call select if 1) it's already working on a request and 2) > it won't open and close a socket for a request it's not prepared to handle. > If the app doesn't call accept() Apache will gracefully move on to another > app server. (*nod*) Mongrel accpets requests as they come in. If it reaches its request limit, it starts killing things. That request limit, unless you have set it lower, is the select() limit of 1024 file handles. In a case where you have some actions that are very, very slow, a mongrel that is in this situation probably just crawls and takes forever to render anything. It also uses a ton of RAM. If one is using an evented_mongrel, you still have the problem that you mention, that a fast action sitting behind a slow one has to wait for the slow one to finish. The slow one will, however, finish a lot faster, and the overall RAM usage will be a _LOT_ lower, too. With Swiftiply, a fast action won't ever be queued up behind a slow action unless there are no available backends to take any actions at all. Then the fast action will wait until one of the backends finishes its unit of work and returns a response. As soon as that happens, the fast action that has been waiting for a backend will be picked up and handled. > I'll look at swiftiply -- this is the first I've heard of it. swiftiply.swiftcore.org #swiftcore on irc.freenode.net Kirk Haines From cwdinfo at gmail.com Wed Oct 3 13:49:25 2007 From: cwdinfo at gmail.com (s.ross) Date: Wed, 3 Oct 2007 10:49:25 -0700 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> Message-ID: Have you ever tried to make an app thread-safe? The dependencies are so bizarre that the testability of the app vastly increases in complexity. Bugs are subtle and don't happen often -- even then, they are not readily reproducible. Worse, they may not even be in your code! I've been a proponent (in the past) of some kind of MT Rails, but the more I think about injecting mutexes or bracketing sections of code with semaphores, etc, etc, hoping I've made my code reentrant, the less I like it when compared to the multiprocess model. Note also that a good deal of any Web app is made up of instance objects which are typically not long-lived and don't benefit from MT. So you get to think about a whole different set of things: Where do I store app- global data and how do I store thread-local data? This can be a nightmare for request/response cycles that typically take milliseconds and for which a multiprocess alternative exists. Just my $.02 On Oct 3, 2007, at 10:25 AM, Kirk Haines wrote: >> I would quite happily trade that in for the >> memory and performance overhead of whatever multiplexing or >> multithreading >> scheme is used in the app server. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071003/9c3b3e36/attachment.html From amusic at freemail.gr Wed Oct 3 14:00:04 2007 From: amusic at freemail.gr (Sotiris Varotsis) Date: Wed, 3 Oct 2007 21:00:04 +0300 Subject: [Nitro] Installing Nitro on Windows in 11 steps In-Reply-To: References: <4703684860cde7.15282900@freemail.gr> Message-ID: <00f101c805e7$3a990430$afcb0c90$@gr> The first installer build looks promising (as in installing Nitro on a system that already has mysql and ruby on it). Of course it assumes much for granted at this stage. I'm going to add some checks for presence of ruby, mysql or other nitro versions and do the relevant error handling, make it pretty and per George's suggestion make it a component based, all in one package (i.e. ruby/mysql/nitro). I expect it to be released really soon. Auto-updating (kind of like building a nitro specific darcs in the installer) will be a bit trickier and it will be looked upon later on. -aMUSiC -----Original Message----- From: Jonathan Buch [mailto:john at oxyliquit.de] Sent: Wednesday, October 03, 2007 7:59 PM To: amusic at freemail.gr; General discussion about Nitro Subject: Re: [Nitro] Installing Nitro on Windows in 11 steps Hi, and welcome! > Hope this helps. Very concise and easy to read, like Rob already said, I'd be happy if you could add this as an Oxyiliquit tip[1]. Thank you very much for supporting the poor windows guys, they don't get too much love these days! ^_^ Jo [1] http://www.oxyliquit.de/add/tip -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.0/1046 - Release Date: 3/10/2007 10:08 ?? No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.0/1046 - Release Date: 3/10/2007 10:08 ?? From rob at robmela.com Wed Oct 3 14:45:25 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 14:45:25 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> Message-ID: <4703E345.50705@robmela.com> Kirk Haines wrote: > Yes. This brings up an interesting issue, though. 1 minute to render > a page is horrific, and if everything is that slow, there are no good > solutions. But if the app only has certain pages that are that slow, > while the rest are fast, it brings up an interesting, solveable > scaling quandry. > I didn't write it... just wanna make that clear... I inherited it and have solved enough of it that at least users can get on to the system, which gives them a chance to grumble about the speed. This is the offending code in gems/mongrel-1.0.1/lib/mongrel.rb. I've set num_processors in mongrel_cluster.yml to 1, and it seems a fairly straightforward workaround to replace accept ( line 722 ) with a polling loop: def accept_workaround reap_dead_workers if worker queue length < max_processors return accept else sleep 0.1 seconds # more properly: wait for a barrier condition end end Gets me out of my current hell. A proper fix would have a barrier condition replacing the sleep, but compared to what I'm up against now, a 0.1 second polling loop is nothing. Swiftiply looks good -- scanning the docs now. As an alternative, the above, unless I'm missing something, would also mesh seamlessly with mod_proxy_balancer. - query worker_list.lengthand if it's greater than num_processors, b 721 while true 722 begin 723 client = @socket.accept 724 725 if $tcp_cork_opts 726 client.setsockopt(*$tcp_cork_opts) rescue nil 727 end 728 729 worker_list = @workers.list 730 731 if worker_list.length >= @num_processors 732 STDERR.puts "Server overloaded with #{worker_list.length} processors (#@num_processors max). Dropping connection." 733 client.close rescue Object 734 reap_dead_workers("max processors") 735 else -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/15d8c3a0/attachment-0001.vcf From wyhaines at gmail.com Wed Oct 3 14:49:08 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 3 Oct 2007 11:49:08 -0700 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> Message-ID: On 10/3/07, s.ross wrote: > Have you ever tried to make an app thread-safe? The dependencies are so > bizarre that the testability of the app vastly increases in complexity. Bugs > are subtle and don't happen often -- even then, they are not readily > reproducible. Worse, they may not even be in your code! Are you talking to me or to Robert? You attribute the quote at the bottom of your post to me, but those aren't my words -- they are Robert's. I have made apps threadsafe. IOWA is threadsafe, and IOWA apps are generally threadsafe. It's not a terrible nightmare, but often there are simpler alternatives, as you suggest. > This can be a nightmare for request/response cycles that typically take > milliseconds and for which a multiprocess alternative exists. It can be a nightmare for a lot of reasons. The main complains about the multiprocess alternative are the management issues. Managing your pool of backend processes, monitoring their individual health, stopping/restarting, sizing the pool to the loads, etc.... These are all issues that I am working towards solving with Swiftiply, regardless of what framework one uses. Kirk Haines From rob at robmela.com Wed Oct 3 16:08:08 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 03 Oct 2007 16:08:08 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> Message-ID: <4703F6A8.4030605@robmela.com> For sure -- it'd be labor intensive and tedious to take a legacy framework with all its associated plugins from disparate sources and make it thread-safe. You'd have to make the default mode single-threaded and allow a year or two for plugins and new development to catch up. There are actually very few cases where a framework user would need to consider concurrency. Most of the shared resources are things like session stores, database connections -- and all that's taken care of by the framework. Presumably a developer advanced enough to create a shared resource is also someone who has a clue as to what needs to be done. s.ross wrote: > Have you ever tried to make an app thread-safe? The dependencies are > so bizarre that the testability of the app vastly increases in > complexity. Bugs are subtle and don't happen often -- even then, they > are not readily reproducible. Worse, they may not even be in your code! > > I've been a proponent (in the past) of some kind of MT Rails, but the > more I think about injecting mutexes or bracketing sections of code > with semaphores, etc, etc, hoping I've made my code reentrant, the > less I like it when compared to the multiprocess model. Note also that > a good deal of any Web app is made up of instance objects which are > typically not long-lived and don't benefit from MT. So you get to > think about a whole different set of things: Where do I store > app-global data and how do I store thread-local data? > > This can be a nightmare for request/response cycles that typically > take milliseconds and for which a multiprocess alternative exists. > > Just my $.02 > > On Oct 3, 2007, at 10:25 AM, Kirk Haines wrote: > >>> I would quite happily trade that in for the >>> >>> memory and performance overhead of whatever multiplexing or >>> multithreading >>> >>> scheme is used in the app server. >>> > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071003/5b4f16e5/attachment.vcf From cwdinfo at gmail.com Wed Oct 3 17:34:43 2007 From: cwdinfo at gmail.com (s.ross) Date: Wed, 3 Oct 2007 14:34:43 -0700 Subject: [Nitro] Nitro on Apache In-Reply-To: <4703F6A8.4030605@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> <4703BF0C.2010003@robmela.com> <4703F6A8.4030605@robmela.com> Message-ID: <3D4B217B-F5BE-4E38-9379-A781DCBC5901@gmail.com> First to Kirk: Sorry about the attribution -- my mistake. Second, this is more a general comment on the desirability and cost/benefit of using threads in short-duration processes such as request/response cycles. The cost of tracking down and fixing a concurrency bug may be higher than adding a mongrel or whatever. If swiftiply solves some or much of this problem, I'll be very happy. In the meantime, the cheap way to remove blocking is add servers in separate processes. Rob, if Rails is any example, features and stability will trump concurrency for a long time. Certainly, threading is worth keeping on the radar, but then you have to open the discussion of whether green threads really do what you want and which of the next-generation Ruby engines are likely to succeed in providing an efficient threading model -- efficient enough to make thread-safety a priority. I believe one philosophy that typically works is the "sin no more" philosophy. If you know you didn't get concurrency right in the first place, at least don't knowingly create new problems. Hmmmm? On Oct 3, 2007, at 1:08 PM, Robert Mela wrote: > For sure -- it'd be labor intensive and tedious to take a legacy > framework with all its associated plugins from disparate sources > and make it thread-safe. You'd have to make the default mode > single-threaded and allow a year or two for plugins and new > development to catch up. > > There are actually very few cases where a framework user would need > to consider concurrency. Most of the shared resources are things > like session stores, database connections -- and all that's taken > care of by the framework. Presumably a developer advanced enough > to create a shared resource is also someone who has a clue as to > what needs to be done. > > From mvyver at gmail.com Thu Oct 4 05:49:14 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 4 Oct 2007 19:49:14 +1000 Subject: [Nitro] Nitro/Og rspec heads-up: any alternative solutions. Message-ID: <389c43e40710040249i19ef7429o7171a27252da3ce4@mail.gmail.com> Hi Devs, Hope this 'head-up' saves someone some time. I'd appreciate any alternative the are better then what I cam up with. The following is known on the rspec list and I've asked there for suggestions - will fwd if anything useful comes up. The essential point is that rspec describe blocks are not isolated name spaces. Consequence: if you're going to define classes then you'll need to choose different class names for each describe/example block, or else the spec's will run a good chance of being contaminated. Any other suggestions? Example, from the code snippets below, the last describe/example block will return two attributes for the Person class: @attrs # [:name, :age] :) module Og describe DbiAdapter, "field_sql_for_attribute (without :sql annotation)" do include OgSpecExpectations before(:all) do class Person attr_accessor :name, String, :sql => "some text" end end <...> end describe DbiAdapter, "field_sql_for_attribute (without :sql annotation)" do include OgSpecExpectations before(:all) do class Person attr_accessor :age, String end <...> @attrs = @man.store.serializable_attributes_for_class(Person) end <...> end end From arne at arnebrasseur.net Thu Oct 4 11:21:05 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Thu, 04 Oct 2007 23:21:05 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> Message-ID: <470504E1.90206@arnebrasseur.net> This seems the way to go, but unfortunately mod_proxy is not an option for me. I'm on shared hosting with little chance of changing apache's configuration, except by .htaccess files. It seems both cgi and fcgi adapters are simply broken because of changes to the adapter interface. E.g. what used to be class methods are now instance methods, but that's not all. Would it be hard to fix them? Or just one of them? I'm not too concerned about performance at this point, if it runs I'd be happy. If they're not being fixed please add a big BROKEN sign or remove them altogether. Thank you (once again)! (ab) George Moschovitis schreef: > I use Apache + mod_proxy_ballancer + Mongrel. > > I will try to prepare a *short* tutorial. > > -g. > > > > On 10/3/07, *Arne Brasseur* < arne at arnebrasseur.net > > wrote: > > I'm for the first time trying to actually deploy a Nitro app on my > shared hosting account. I'm trying to use FastCGI since that's what I > had success with using Rails. It took some tweaking of the FastCGI > adapter, it seems unmaintained. > > I'm mainly stealing ideas from Rails here, I created a dispatch.fcgi > that just loads Nitro, sets the mode to :live and requires app.rb. > If I > run it gives the two green lines : > > 03/10 05:13:11 INFO: Og uses the Mysql store. > 03/10 05:13:11 INFO: Starting Fastcgi server in live mode, > listening at > 0.0.0.0:9000 > > My .htaccess should be good. Now if I visit the site I get a > server 500 > error. The error log mentions : > > [Wed Oct 03 05:11:59 2007] [error] [client 61.225.17.58 > ] FastCGI: > incomplete headers (0 bytes) received from server "/home/ar > nebrasseur/subdomains/vocab/dispatch.fcgi" > > Have other people gotten this to work? Do I have other options having > only limited control over the apache configuration? > > Thanks for any pointers! > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://gmosx.me.gr > http://phidz.com > 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 -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071004/2bed7f6e/attachment.html From rob at robmela.com Thu Oct 4 13:32:49 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 04 Oct 2007 13:32:49 -0400 Subject: [Nitro] caching and index params Message-ID: <470523C1.6010905@robmela.com> Is this still true? # Handle static files? Set to true in live mode to avoid a # nasty bug: when caching is enabled and the index method # accepts parameters, static files may get corrupted. Think # something better. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071004/797f9fbf/attachment.vcf From prpht9 at gmail.com Thu Oct 4 15:07:12 2007 From: prpht9 at gmail.com (chris) Date: Thu, 4 Oct 2007 15:07:12 -0400 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: <47038C79.6020804@robmela.com> References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> <47038C79.6020804@robmela.com> Message-ID: Rob, This is similar to something I mentioned awhile back. And it has one particular issue. The documentation does not evolve and get transported to users when they do, say... "sudo gem install og --version= 0.40.0" or however you would type this for a specific version. (don't feel like looking it up) Including og and nitro documentation in rdoc along with the code accomplishes your goal and it keeps all evolving changes to documentation with the pertinent code. Tutorials should be a part of the rdoc documentation is what I'm saying. Oxyliquit provides a place for users to post tutorial ideas and the base ones, like your cheatsheets get installed with every gem. As for the collaborative documentation aspect, I'll have to think about that for a bit. The back of my head is screaming wiki with an automated export into darcs that only george can kick off. I'll post back when I have some more defined ideas. I would be willing to post an example of what I propose to this list for you guys to consider. I know this doesn't necessarily associate the comment threads like on the php docs site you mentioned, I'd have to put more thought into that than I have available brain power currently. Just my 2cents Chris Below is the comment I made a while back about documentation called "Keeping Documentation and Tutorials up-to-date" Hi all, > > A methodology recommendation has been rolling around in my head for a > few days now and I'd like to bring it up here on the mailing list. So, I'll > get started with a little background and a question. > > I was reading a post earlier today called "The basics" and want to ask > the question "Where are the new tutorials going to be published?". > > This seemed like an innocent enough question until i realized, your > probably going to put it on OxyLiquit . I'm not going > to knock putting them there, it's actually one of the top locations new > users are going to look for that information. The problem I see is the same > thing that happened to the other 4 tutorials. > > They went out of date almost as quickly as they were posted. > > I would like to make a recommendation to the Nitro/Og (raw, etc, etc.) > team. How about rolling a basic tutorial into the RDocs. IMHO the > situation your team is running into is a knowledge transfer gap between the > creators and the intermediate to expert users of Nitro, not the newbies who > barely know where to start. Rake's RDoc index pageis a good example of what I think Nitro's should look like. It gives all > the information a newbie needs to get their feet wet and attempt to get to > an intermediate level of understanding. > > What the expert users needs is good reference material that explains the > inner workings of how the components work with each other and small examples > of how someone can utilize them. eg: Rake::RDocTaskand > Rake::GemPackageTask > These examples do not need to be easily understood by a novice. However, > they do need to effectively communicate a technical concept to a competent > ruby developer without having to delve too deeply into the code to > accomplish something. I'm not saying they won't run into exceptions trying > to get it working, but they should know what is possible with the class or > module. > > note: I used rake just because it's something I picked up fairly quickly > due to the rdocs. > > The advantage of taking this approach to documenting your projects is > you create a basis for the expert users to write the tutorials. They could > write them on their blogs, (good for your google ranking), on Fora or on > OxyLiquit. I'm basically saying, you should not be writing full blown > tutorials, but moving smaller examples of how to perform actions into your > RDocs. This has key advantages... > > 1 - When a developer makes a change to the code they can make the example > adjustments without having to open another editor. > eg: Or even better, without having to open a web browser, login to a > wiki ( whatever ) and then make changes. Way too many steps. Developers > are lazy, I mean efficient. (tongue in cheek) > 2 - The examples for a particular version of each project are in revision > control with the code they reference. > eg: someone can download x.x lower version of the project and have the > correct examples for that version > 3 - The published RDocs can be available through your website and through > ri without you having to publish yet another piece of documentation. > eg: rake deploy is all it takes (if you use newgem, not sure if you do) > 4 - Patches from your userbase don't have to be just code, they can be > updates to your tutorials as well. > eg: In fact if I were in your shoes, the first page of the RDocs would > reference a page on how to submit updates to the examples as a patch. > > As a final note, I would like to say the HelloWorld example from the > repository for nitro-0.50 is a perfect starting point to put in the > RDocs. Then you could work the Blog example in for each of the components > you want to communicate howto ___. I'm all done ranting. > > Criticism always welcome, > > Chris Scheper > On 10/3/07, Robert Mela wrote: > > Sorry... I misunderstood the question... I'm up to my eyeballs in > exploring Og right now, and its filtering everything I see. I look at > my wife and kids and visualize the generated foreign key attributes that > join us.... :) > > Thanks for the kudos. What I'd like more than my cheatsheets is a > collaborative effort to produce documentation similar to the PHP docs -- > http://www.php.net/docs.php. I see it as a nitro app, with content > in DocBook or something similar. Perhaps Nitro elements could be > created named similarly to DocBook elements, such that the docbook pages > can be served up directly, as-is. The same pages could be used later > to generate a print book -- produced by a community(!) with proceeds > going back to the project. > > Would someone be willing to host that in a mercurial or darcs archive? > > thx. > > Robert Mela wrote: > > Some of the relation declarations are for the benefit of Og in schema > > generation. > > > > Others are for the benefit of Forms in generating form elements to > > bind relations ( see the views in nitro/part/admin/og ) > > > > Arne Brasseur wrote: > >> > >> G, is this known/intended? If so it should be documented. Robert, you > >> could perhaps add this to your cheatsheets? Very nice work BTW! I'm > >> using them all the time now. > >> > >> http://robmela.com/cheatsheets > >> > >> (ab) > >> > >> > > > > _______________________________________________ > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071004/1876495e/attachment-0001.html From mvyver at gmail.com Fri Oct 5 02:16:55 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 5 Oct 2007 16:16:55 +1000 Subject: [Nitro] Og [patch]: Rename write_attr_ to serialize_attr_ Message-ID: <389c43e40710042316o703d52eamd55609e4443dd5ea@mail.gmail.com> These changes should have no effect at the users level? * Rename write_attr_ to serialize_attr_ These names properly reflect what is happening. Renaming is also a precursor to some changes that 1) DRY out the serialization that occurs in Og, 2) Should permit Og's type mapping to be extensible (without touching the code). -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20071005-1.tar.gz Type: application/x-gzip Size: 18958 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071005/f82b1fb4/attachment.gz From george.moschovitis at gmail.com Fri Oct 5 03:33:13 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 5 Oct 2007 10:33:13 +0300 Subject: [Nitro] caching and index params In-Reply-To: <470523C1.6010905@robmela.com> References: <470523C1.6010905@robmela.com> Message-ID: I am not really sure... will have to check this... -g. On 10/4/07, Robert Mela wrote: > > Is this still true? > > # Handle static files? Set to true in live mode to avoid a > # nasty bug: when caching is enabled and the index method > # accepts parameters, static files may get corrupted. Think > # something better. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071005/a51b1a91/attachment-0001.html From george.moschovitis at gmail.com Fri Oct 5 03:34:05 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 5 Oct 2007 10:34:05 +0300 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> <47038C79.6020804@robmela.com> Message-ID: > > I would be willing to post an example of what I propose to this list for > you guys to consider. > please do so. -g. -- http://gmosx.me.gr http://phidz.com 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/20071005/f37fdd34/attachment.html From george.moschovitis at gmail.com Fri Oct 5 03:35:05 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 5 Oct 2007 10:35:05 +0300 Subject: [Nitro] Og [patch]: Rename write_attr_ to serialize_attr_ In-Reply-To: <389c43e40710042316o703d52eamd55609e4443dd5ea@mail.gmail.com> References: <389c43e40710042316o703d52eamd55609e4443dd5ea@mail.gmail.com> Message-ID: I kind of like read_attr write_attr (notice the symmetry) -g. On 10/5/07, Mark Van De Vyver wrote: > > These changes should have no effect at the users level? > > * Rename write_attr_ to serialize_attr_ > These names properly reflect what is happening. Renaming is also a > precursor to some changes that 1) DRY out the serialization that > occurs in Og, 2) Should permit Og's type mapping to be extensible > (without touching the code). > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071005/447545ba/attachment.html From george.moschovitis at gmail.com Fri Oct 5 03:39:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 5 Oct 2007 10:39:09 +0300 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <4703985D.8@robmela.com> Message-ID: > > George had said that he was going to make sure Nitro 0.50 had builtin > support for using both of these. I am not sure of the status of that > or if he needs anything from me. George? I am about to bring live a first (preview) version of my current project. I most certainly want to experiment with your code ;-) This will happen sooner rather than later. So please, be a bit more patient. -g. PS: And thanks for your great work and willingnes to help me make this a great deployment option for Nitro apps. -- http://gmosx.me.gr http://phidz.com 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/20071005/78874e6a/attachment.html From mvyver at gmail.com Fri Oct 5 04:57:22 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 5 Oct 2007 18:57:22 +1000 Subject: [Nitro] Og [patch]: Rename write_attr_ to serialize_attr_ In-Reply-To: References: <389c43e40710042316o703d52eamd55609e4443dd5ea@mail.gmail.com> Message-ID: <389c43e40710050157n6853be50o286842b62b3f912c@mail.gmail.com> On 10/5/07, George Moschovitis wrote: > I kind of like > > read_attr > write_attr I haven't touch write_attr - yet :) if you're still not convinced let me know I'll try and explain why. Mark > (notice the symmetry) > > -g. > > > On 10/5/07, Mark Van De Vyver < mvyver at gmail.com> wrote: > > > > These changes should have no effect at the users level? > > > > * Rename write_attr_ to serialize_attr_ > > These names properly reflect what is happening. Renaming is also a > > precursor to some changes that 1) DRY out the serialization that > > occurs in Og, 2) Should permit Og's type mapping to be extensible > > (without touching the code). > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > http://gmosx.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From mvyver at gmail.com Fri Oct 5 07:30:16 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 5 Oct 2007 21:30:16 +1000 Subject: [Nitro] Og [patch]: Rename write_attr_ to serialize_attr_ In-Reply-To: <389c43e40710050157n6853be50o286842b62b3f912c@mail.gmail.com> References: <389c43e40710042316o703d52eamd55609e4443dd5ea@mail.gmail.com> <389c43e40710050157n6853be50o286842b62b3f912c@mail.gmail.com> Message-ID: <389c43e40710050430x34d1900eycdfb1ab4349c4210@mail.gmail.com> Some detail... On 10/5/07, Mark Van De Vyver wrote: > On 10/5/07, George Moschovitis wrote: > > I kind of like > > > > read_attr > > write_attr The method SqlStore#read_attr currently calls: self.class.parse_(res[col + offset]) while SqlStore#write_attr currently calls: write_attr_(value) None of these actualy read or write anything - in fact I ignored even looking at them for a long time since I wasn't at the point of reading/writing data... silly me :) The RDoc is most accurate: They serliaze/deserialize instances of Og objects. Later on some other method reads/writes this data - for sql stores the closest methods to doing this are SqlStore#exec and SqlStore#query - even then I'd argue it's still misleading naming to call them read/write. anyway it is irrelevant right. Now SqlStore#quote (and hence Adapter) deals with arrays, but re-implements all that is done in write_attr. This opens the door for inconsistencies. I'm heading towards closing that door, but I'll close it first in the DbiAdapter, and then only when spec's are in place. I'd guess a reason for this is that someone baulked at using #write_attr in the quote loop, as in the following (untested): module SqlUtils def quote(vals) vals = [vals] unless vals.is_a?(Array) quoted = vals.inject("") do |s, val| s += write_attr + ',' end quoted.chop! vals.size > 1 ? "(#{quoted})" : quoted end end But essentially that is 99% of what is happening in SqlUtils#quote. The non DbiAdapter spec's will flow as I make them.... > I haven't touch write_attr - yet :) and won't until there is a spec in place. HTH Mark > if you're still not convinced let me know I'll try and explain why. > Mark > > > > (notice the symmetry) > > > > -g. > > > > > > On 10/5/07, Mark Van De Vyver < mvyver at gmail.com> wrote: > > > > > > These changes should have no effect at the users level? > > > > > > * Rename write_attr_ to serialize_attr_ > > > These names properly reflect what is happening. Renaming is also a > > > precursor to some changes that 1) DRY out the serialization that > > > occurs in Og, 2) Should permit Og's type mapping to be extensible > > > (without touching the code). > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > -- > > http://gmosx.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > From mvyver at gmail.com Fri Oct 5 07:52:28 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 5 Oct 2007 21:52:28 +1000 Subject: [Nitro] Og [Patch]: Specs for write_attr and serialize_attr_ in ./og/store/sql.rb Message-ID: <389c43e40710050452j26828d60n2328e43fded9d984@mail.gmail.com> 40 passing specs, 20 pending specs. I haven't touched the exisitng spec... it fails on my copy of the repo, but I'm not at the level it is specing just yet..... It'd be very useful - i.e. help keep things ticking, if Og's rake task was able to parse pending tests, even discern when a failure is in fact a pending test that now passes - a false negative. If anyone is bored.... HTH Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20071005-2.tar.gz Type: application/x-gzip Size: 19679 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071005/a047cc16/attachment-0001.gz From prpht9 at gmail.com Fri Oct 5 12:14:42 2007 From: prpht9 at gmail.com (chris) Date: Fri, 5 Oct 2007 12:14:42 -0400 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> <47038C79.6020804@robmela.com> Message-ID: Ok, probably won't get it done till Sunday. Chris On 10/5/07, George Moschovitis wrote: > > I would be willing to post an example of what I propose to this list for > > you guys to consider. > > > > please do so. > > -g. > > -- > http://gmosx.me.gr > http://phidz.com > 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 -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071005/50ce02c4/attachment.html From transfire at gmail.com Fri Oct 5 16:12:57 2007 From: transfire at gmail.com (Trans) Date: Fri, 05 Oct 2007 20:12:57 -0000 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> Message-ID: <1191615177.672859.276670@d55g2000hsg.googlegroups.com> Could anyone over here with a fresh install of Facets-2.0.0 try this out: $ irb1.8 irb(main):001:0> require 'rubygems' => true irb(main):002:0> require 'facets/string/interpolate' => true irb(main):003:0> a = 1 => 1 irb(main):004:0> String.interpolate{'this is #{a}'} NoMethodError: undefined method `interpolate' for String:Class from (irb):4 It's working for me, but apparently not someone else, and I'm not sure why. Thanks, T. From aidan at yoyo.org Fri Oct 5 17:17:11 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 5 Oct 2007 22:17:11 +0100 Subject: [Nitro] Updated tutorial In-Reply-To: <4700EB4F.2010708@arnebrasseur.net> References: <4700EB4F.2010708@arnebrasseur.net> Message-ID: Thanks for the updated tutorial - made life much easier :-) Aidan On Oct 1, 2007, at 1:42 PM, Arne Brasseur wrote: > One new chapter to the tutorial, plus a Mercurial repo. > > hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi /your/ > local/dir > > That URL should also show you the latest history of changes. > > e-mail me if you want commit access. The basic tutorial will > broadly follow the outline from the Ramaze tutorial : > http://ramaze.rubyforge.org/tutorial/todolist.html > Small example apps are also welcome. > > All content can be freely copied and adapted, e.g. to the Nitro > repo, to Oxyliquit, to Nitro RDoc, blogs, wikis, etc. > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From tastapod at gmail.com Fri Oct 5 18:12:04 2007 From: tastapod at gmail.com (Dan North) Date: Fri, 5 Oct 2007 23:12:04 +0100 Subject: [Nitro] Updated tutorial In-Reply-To: <47019E16.3020401@robmela.com> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> Message-ID: Wow, those cheatsheets are amazing. Please put them into the tutorial repository! On 10/2/07, Robert Mela wrote: > > I suppose I should merge the newly expanded > http://robmela.com/cheatsheets into this... or copy stuff from this into > cheatsheets... working through og relations today... > > > > George Moschovitis wrote: > > Many, many thanks Arne. > > > > Once again I am running short on time today and tomorrow, but I 'll be > > back on Wednesday. > > > > keep up the great work. > > > > -g. > > > > On 10/1/07, Arne Brasseur wrote: > > > >> One new chapter to the tutorial, plus a Mercurial repo. > >> > >> hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi > >> /your/local/dir > >> > >> That URL should also show you the latest history of changes. > >> > >> e-mail me if you want commit access. The basic tutorial will broadly > >> follow the outline from the Ramaze tutorial : > >> http://ramaze.rubyforge.org/tutorial/todolist.html > >> Small example apps are also welcome. > >> > >> All content can be freely copied and adapted, e.g. to the Nitro repo, > to > >> Oxyliquit, to Nitro RDoc, blogs, wikis, etc. > >> > >> (ab) > >> > >> -- > >> Arne Brasseur > >> http://www.arnebrasseur.net > >> arne at arnebrasseur.net > >> > >> > >> _______________________________________________ > >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071005/9e5c9c7a/attachment.html From rob at robmela.com Fri Oct 5 19:51:36 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 05 Oct 2007 19:51:36 -0400 Subject: [Nitro] Updated tutorial In-Reply-To: References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> Message-ID: <4706CE08.70106@robmela.com> Thanks. I'm a little bashful because they do need more work, and I'm sure the core developers see plenty of shortcomings. For future distribution I think we should integrate some of the content into the upcoming Rdocs documentation project. I'd like to structure the Rdocs such that they can generate HTML pages like these in a format that's really accessible to newbies and to people looking for information in a hurry. Dan North wrote: > Wow, those cheatsheets are amazing. Please put them into the tutorial > repository! > > On 10/2/07, *Robert Mela* > > wrote: > > I suppose I should merge the newly expanded > http://robmela.com/cheatsheets into this... or copy stuff from > this into > cheatsheets... working through og relations today... > > > > George Moschovitis wrote: > > Many, many thanks Arne. > > > > Once again I am running short on time today and tomorrow, but I > 'll be > > back on Wednesday. > > > > keep up the great work. > > > > -g. > > > > On 10/1/07, Arne Brasseur > wrote: > > > >> One new chapter to the tutorial, plus a Mercurial repo. > >> > >> hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi > >> /your/local/dir > >> > >> That URL should also show you the latest history of changes. > >> > >> e-mail me if you want commit access. The basic tutorial will > broadly > >> follow the outline from the Ramaze tutorial : > >> http://ramaze.rubyforge.org/tutorial/todolist.html > >> Small example apps are also welcome. > >> > >> All content can be freely copied and adapted, e.g. to the Nitro > repo, to > >> Oxyliquit, to Nitro RDoc, blogs, wikis, etc. > >> > >> (ab) > >> > >> -- > >> Arne Brasseur > >> http://www.arnebrasseur.net > >> arne at arnebrasseur.net > >> > >> > >> _______________________________________________ > >> 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071005/dff973e2/attachment.vcf From mvyver at gmail.com Fri Oct 5 22:41:25 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 6 Oct 2007 12:41:25 +1000 Subject: [Nitro] Og [RFC]: More jargon... Message-ID: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> Hi Devs, I'd appreciate thought and comments on the following. A word in advance, I'm not proposing immediate changes, but rather settling on some nomenclature that, when an oppotunity arises can be put in place/implemented. I'd think the process might be something like - the spec existing method/behavior - have spec accepted. - implement any changes to the code, the existing spec and documentation. Following on from the last email you'll notice there are issues with the names given to methods. I've found that looking at these names can lead you up the garden path/ down the creek (as you wish), but quite frustrating regardless. At the moment some related Og methods are prefixed with: write, read, parse, and quote. It seems they largely do the following - convert data in instances of Ruby objects into/from text (ASCII?) strings, to be formatted ready for (but not) storage/retrieval. IMHO they certainly don't write or read, it's debatable that some 'parse', and 'quote' is also drawing a long bow for what that method does. serialize/deserialize terms are candidates for prefixes _but_ Og doesn't store as binary - eg uses Yaml rather than Marshal - and this could be considered misleading? load/dump could be used as prefixes instead of read/write? I'm not nuts about stringify/destringify but they could be prefixes for the methods that convert to text strings. Anyway, I think it needs some thought and I'd appreciate any comments. Mark From arne at arnebrasseur.net Fri Oct 5 22:58:51 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 06 Oct 2007 10:58:51 +0800 Subject: [Nitro] Updated tutorial In-Reply-To: <4706CE08.70106@robmela.com> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> <4706CE08.70106@robmela.com> Message-ID: <4706F9EB.901@arnebrasseur.net> I personally also think the primary documentation should be the RDocs. Every module/class should have a toplevel RDoc section which explains its purpose and typical usage. Public methods should be fully documented. As far as external documentation goes I am (as I said before) a big big fan of wikis. However this would partly overlap with Oxywtf, so we don't need it right away. Better to not split community stuff over too many different locations. So if you feel like contributing stuff, head over to http://www.Oxywtf.de (insert catchy tune). The main virtue of the tutorial repo I see is that it can contain a lot of code examples along with their tutorials. However it might disappear again in the future as it's contents are merged into the main repo/rdoc/oxywtf. Should it get to contain more example apps then can be reasonbly shipped with the main distribution then it might become a package in its own right (e.g. nitro-examples). This will depend on community input. (ab) Robert Mela schreef: > Thanks. > > I'm a little bashful because they do need more work, and I'm sure the > core developers see plenty of shortcomings. > > For future distribution I think we should integrate some of the > content into the upcoming Rdocs documentation project. I'd like to > structure the Rdocs such that they can generate HTML pages like these > in a format that's really accessible to newbies and to people looking > for information in a hurry. > > Dan North wrote: >> Wow, those cheatsheets are amazing. Please put them into the tutorial >> repository! >> >> On 10/2/07, *Robert Mela* > >> wrote: >> >> I suppose I should merge the newly expanded >> http://robmela.com/cheatsheets into this... or copy stuff from >> this into >> cheatsheets... working through og relations today... >> >> >> >> George Moschovitis wrote: >> > Many, many thanks Arne. >> > >> > Once again I am running short on time today and tomorrow, but I >> 'll be >> > back on Wednesday. >> > >> > keep up the great work. >> > >> > -g. >> > >> > On 10/1/07, Arne Brasseur > > wrote: >> > >> >> One new chapter to the tutorial, plus a Mercurial repo. >> >> >> >> hg clone http://repo.arnebrasseur.net/nitrotutorial/hgweb.cgi >> >> /your/local/dir >> >> >> >> That URL should also show you the latest history of changes. >> >> >> >> e-mail me if you want commit access. The basic tutorial will >> broadly >> >> follow the outline from the Ramaze tutorial : >> >> http://ramaze.rubyforge.org/tutorial/todolist.html >> >> Small example apps are also welcome. >> >> >> >> All content can be freely copied and adapted, e.g. to the Nitro >> repo, to >> >> Oxyliquit, to Nitro RDoc, blogs, wikis, etc. >> >> >> >> (ab) >> >> >> >> -- >> >> Arne Brasseur >> >> http://www.arnebrasseur.net >> >> arne at arnebrasseur.net >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From rob at robmela.com Fri Oct 5 23:11:46 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 05 Oct 2007 23:11:46 -0400 Subject: [Nitro] Og [RFC]: More jargon... In-Reply-To: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> References: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> Message-ID: <4706FCF2.60402@robmela.com> Mark Van De Vyver wrote: > serialize/deserialize terms are candidates for prefixes _but_ Og > doesn't store as binary - eg uses Yaml rather than Marshal - and this > could be considered misleading? > load/dump could be used as prefixes instead of read/write? > I'm not nuts about stringify/destringify but they could be prefixes > for the methods that convert to text strings. > > I suggest marshal/unmarshal regardless of the underlying technique. "Marshal" may own the name but the fact is that converting to/from an external format, be it binary, YAML, or XML, is in fact marshalling and unmarshalling. I've seen output to XML referred to as "serialization" as well. > Anyway, I think it needs some thought and I'd appreciate any comments. > Mark > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071005/a0790e10/attachment.vcf From rob at robmela.com Sat Oct 6 11:21:41 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 06 Oct 2007 11:21:41 -0400 Subject: [Nitro] Updated tutorial In-Reply-To: <4706F9EB.901@arnebrasseur.net> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> <4706CE08.70106@robmela.com> <4706F9EB.901@arnebrasseur.net> Message-ID: <4707A805.2060809@robmela.com> Sounds like there's a consensus. I'll start reading up on RDocs. It might also make sense to coordinate on separate aspects of Nitro for the first pass. I'm finding that learning Nitro and Og while documenting the experience leaves coverage thin and incomplete. With what little time I have it would take a to really learn and document Nitro. It also makes it easier for each of us to take the role of newbie and step through each others' documentation, encountering the errors or missing pieces just as a new user would. :r Arne Brasseur wrote: > I personally also think the primary documentation should be the RDocs. > Every module/class should have a toplevel RDoc section which explains > its purpose and typical usage. Public methods should be fully documented. > > As far as external documentation goes I am (as I said before) a big > big fan of wikis. However this would partly overlap with Oxywtf, so we > don't need it right away. Better to not split community stuff over too > many different locations. So if you feel like contributing stuff, head > over to http://www.Oxywtf.de (insert catchy tune). > > The main virtue of the tutorial repo I see is that it can contain a > lot of code examples along with their tutorials. However it might > disappear again in the future as it's contents are merged into the > main repo/rdoc/oxywtf. Should it get to contain more example apps then > can be reasonbly shipped with the main distribution then it might > become a package in its own right (e.g. nitro-examples). This will > depend on community input. > > (ab) -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071006/9164d83e/attachment.vcf From transfire at gmail.com Sat Oct 6 12:44:59 2007 From: transfire at gmail.com (Trans) Date: Sat, 06 Oct 2007 16:44:59 -0000 Subject: [Nitro] Updated tutorial In-Reply-To: <4707A805.2060809@robmela.com> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> <4706CE08.70106@robmela.com> <4706F9EB.901@arnebrasseur.net> <4707A805.2060809@robmela.com> Message-ID: <1191689099.137217.233930@50g2000hsm.googlegroups.com> On Oct 6, 8:21 am, Robert Mela wrote: > Sounds like there's a consensus. I'll start reading up on RDocs. > > It might also make sense to coordinate on separate aspects of Nitro for > the first pass. I'm finding that learning Nitro and Og while > documenting the experience leaves coverage thin and incomplete. With > what little time I have it would take a to really learn and document Nitro. > > It also makes it easier for each of us to take the role of newbie and > step through each others' documentation, encountering the errors or > missing pieces just as a new user would. Actually I would argue against RDocs as the primary documentation. RDocs have some issues. The most overarching one is the need to write code to fit docs rather than the other way around. RDocs are really "programmer docs" not "user docs". I'm preparing to put together a Wiki for Facets Documentation (thanks to these Nitro tutorials btw, I can finally see how to proceed!). However, rather then use a simple flat-file system, I'm going to use a DB and index the documentation by class/module, method, arity, and more. This DB will be the official user documentation (and the RDocs will just be for the programmer's). It will be interesting to see how that builds up over time, and what can be done with the DB, say to generate a reference manual. Perhaps we can work together to create a system we can all use, Nitro, Facets or any other project too. T. P.S. Isn't require 'nitro_and_og' redundant now? Shouldn't it become: require 'nitro' is the same as: require 'raw' require 'og' ? From george.moschovitis at gmail.com Sun Oct 7 04:37:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Oct 2007 11:37:37 +0300 Subject: [Nitro] Og [Patch]: Specs for write_attr and serialize_attr_ in ./og/store/sql.rb In-Reply-To: <389c43e40710050452j26828d60n2328e43fded9d984@mail.gmail.com> References: <389c43e40710050452j26828d60n2328e43fded9d984@mail.gmail.com> Message-ID: thanks, i will review the patch. -g. On 10/5/07, Mark Van De Vyver wrote: > > 40 passing specs, 20 pending specs. I haven't touched the exisitng > spec... it fails on my copy of the repo, but I'm not at the level it > is specing just yet..... > > It'd be very useful - i.e. help keep things ticking, if Og's rake task > was able to parse pending tests, even discern when a failure is in > fact a pending test that now passes - a false negative. > If anyone is bored.... > > HTH > > Mark > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071007/3adc4f3c/attachment.html From george.moschovitis at gmail.com Sun Oct 7 04:40:51 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Oct 2007 11:40:51 +0300 Subject: [Nitro] Og [RFC]: More jargon... In-Reply-To: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> References: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> Message-ID: > > IMHO they certainly don't write or read, it's debatable that some > in lisp literature reading == parsing. In this point of view read is a valid prefix. I chose them because read has the same stringlength with write and makes the source code nicer ;-) but as I said, I fully agree with you that naming consistency is important. -g. -- http://gmosx.me.gr http://phidz.com 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/20071007/6711d478/attachment.html From george.moschovitis at gmail.com Sun Oct 7 04:42:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Oct 2007 11:42:44 +0300 Subject: [Nitro] Updated tutorial In-Reply-To: <1191689099.137217.233930@50g2000hsm.googlegroups.com> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> <4706CE08.70106@robmela.com> <4706F9EB.901@arnebrasseur.net> <4707A805.2060809@robmela.com> <1191689099.137217.233930@50g2000hsm.googlegroups.com> Message-ID: > > > P.S. Isn't require 'nitro_and_og' redundant now? Shouldn't it become: > > require 'nitro' > > is the same as: > > require 'raw' > require 'og' > > interesting obversation. However raw is not standalone. -g. -- http://gmosx.me.gr http://phidz.com 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/20071007/7b9206ca/attachment.html From george.moschovitis at gmail.com Sun Oct 7 04:44:53 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Oct 2007 11:44:53 +0300 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: <1191615177.672859.276670@d55g2000hsg.googlegroups.com> References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> <1191615177.672859.276670@d55g2000hsg.googlegroups.com> Message-ID: I tried it and get the same error... please notice that I didn't uninstall facets 1.8.54, perhaps this is the problem? -g. On 10/5/07, Trans wrote: > > Could anyone over here with a fresh install of Facets-2.0.0 try this > out: > > $ irb1.8 > irb(main):001:0> require 'rubygems' > => true > irb(main):002:0> require 'facets/string/interpolate' > => true > irb(main):003:0> a = 1 > => 1 > irb(main):004:0> String.interpolate{'this is #{a}'} > NoMethodError: undefined method `interpolate' for String:Class > from (irb):4 > > It's working for me, but apparently not someone else, and I'm not sure > why. > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071007/5f077c20/attachment.html From transfire at gmail.com Sun Oct 7 05:57:17 2007 From: transfire at gmail.com (Trans) Date: Sun, 07 Oct 2007 09:57:17 -0000 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> <1191615177.672859.276670@d55g2000hsg.googlegroups.com> Message-ID: <1191751037.592302.63030@57g2000hsv.googlegroups.com> On Oct 7, 1:44 am, "George Moschovitis" wrote: > I tried it and get the same error... > please notice that I didn't uninstall facets 1.8.54, perhaps this is the > problem? Did you just install? I uploaded 2.0.1 last night that should fix the problem. T. From george.moschovitis at gmail.com Sun Oct 7 06:01:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 7 Oct 2007 13:01:01 +0300 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: <1191751037.592302.63030@57g2000hsv.googlegroups.com> References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> <1191615177.672859.276670@d55g2000hsg.googlegroups.com> <1191751037.592302.63030@57g2000hsv.googlegroups.com> Message-ID: i tried it with 2.0.1 i get the same error... String.interpolate{'this is #{a}'} btw, are you sure that curly brackets work here? -g. On 10/7/07, Trans wrote: > > > > On Oct 7, 1:44 am, "George Moschovitis" > wrote: > > I tried it and get the same error... > > please notice that I didn't uninstall facets 1.8.54, perhaps this is the > > problem? > > Did you just install? I uploaded 2.0.1 last night that should fix the > problem. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071007/b80d2ca3/attachment-0001.html From mvyver at gmail.com Sun Oct 7 06:31:52 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 7 Oct 2007 20:31:52 +1000 Subject: [Nitro] Og [RFC]: More jargon... In-Reply-To: References: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> Message-ID: <389c43e40710070331h8216217j708fc364d689aa79@mail.gmail.com> Hi Devs, Votes please... On 10/7/07, George Moschovitis wrote: > > > IMHO they certainly don't write or read, it's debatable that some > > > > in lisp literature reading == parsing. In this point of view read is a valid > prefix. > I chose them because read has the same stringlength with write and makes > the source code nicer ;-) > > but as I said, I fully agree with you that naming consistency is important. Currently we have methods named: parse_attr_ write_attr_ Are any of the following name pairs preferred?: deconstruct_attr_ construct_attr_ decompose_attr_ compose_attr_ disassemble_attr_ assemble_attr_ > -g. > > -- > http://gmosx.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From mvyver at gmail.com Sun Oct 7 06:33:17 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 7 Oct 2007 20:33:17 +1000 Subject: [Nitro] Og [RFC]: More jargon... In-Reply-To: <389c43e40710070331h8216217j708fc364d689aa79@mail.gmail.com> References: <389c43e40710051941n1b8ab32ci53b01e3c4fcd39ee@mail.gmail.com> <389c43e40710070331h8216217j708fc364d689aa79@mail.gmail.com> Message-ID: <389c43e40710070333p363d88f3l7c4d5a25e1167c1@mail.gmail.com> addendum: On 10/7/07, Mark Van De Vyver wrote: > Hi Devs, > Votes please... > > On 10/7/07, George Moschovitis wrote: > > > > > IMHO they certainly don't write or read, it's debatable that some > > > > > > > in lisp literature reading == parsing. In this point of view read is a valid > > prefix. > > I chose them because read has the same stringlength with write and makes > > the source code nicer ;-) > > > > but as I said, I fully agree with you that naming consistency is important. > > Currently we have methods named: > parse_attr_ > write_attr_ > > > Are any of the following name pairs preferred?: > > deconstruct_attr_ > construct_attr_ > > decompose_attr_ > compose_attr_ > > disassemble_attr_ > assemble_attr_ marshall_attr_ unmarshall_attr_ Thanks Mark > > > > -g. > > > > -- > > http://gmosx.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > From transfire at gmail.com Sun Oct 7 10:14:15 2007 From: transfire at gmail.com (Trans) Date: Sun, 07 Oct 2007 14:14:15 -0000 Subject: [Nitro] ANN: Facets 2.0.0 In-Reply-To: References: <1191396454.436532.269200@d55g2000hsg.googlegroups.com> <1191615177.672859.276670@d55g2000hsg.googlegroups.com> <1191751037.592302.63030@57g2000hsv.googlegroups.com> Message-ID: <1191766455.186052.68340@o80g2000hse.googlegroups.com> On Oct 7, 3:01 am, "George Moschovitis" wrote: > i tried it with 2.0.1 > i get the same error... > > String.interpolate{'this is #{a}'} > > btw, are you sure that curly brackets work here? Yea, the curly brackets aren't the problem. Turns out there is a bug in RubyGems. On a windows system the require_paths are searched back-to-front, but on Linux systems they are searched front-to-back. Ugh, Tom From prpht9 at gmail.com Sun Oct 7 17:41:16 2007 From: prpht9 at gmail.com (chris) Date: Sun, 7 Oct 2007 17:41:16 -0400 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> <47038C79.6020804@robmela.com> Message-ID: Well this is my first attempt at a patch but here goes. It's really just an addition of rdoc information for Og::Model. I'd like to make one for Og::Mixin as well, because I need to make quite a few mixins for og and I'm not sure how to do it. I'll see what I can put together and post it here as well. Chris On 10/5/07, chris wrote: > > Ok, probably won't get it done till Sunday. > > Chris > > > On 10/5/07, George Moschovitis wrote: > > > I would be willing to post an example of what I propose to this list > > > for you guys to consider. > > > > > > > please do so. > > > > -g. > > > > -- > > http://gmosx.me.gr > > http://phidz.com > > 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 -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071007/40cd9f85/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle Type: application/octet-stream Size: 68541 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071007/40cd9f85/attachment-0001.obj From george.moschovitis at gmail.com Mon Oct 8 03:19:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 8 Oct 2007 10:19:01 +0300 Subject: [Nitro] Oops, and documentation idea... In-Reply-To: References: <47033ADE.40807@arnebrasseur.net> <47038940.6000804@robmela.com> <47038C79.6020804@robmela.com> Message-ID: thank you :) -g. On 10/8/07, chris wrote: > > Well this is my first attempt at a patch but here goes. > > It's really just an addition of rdoc information for Og::Model. I'd like > to make one for Og::Mixin as well, because I need to make quite a few mixins > for og and I'm not sure how to do it. I'll see what I can put together and > post it here as well. > > Chris > > > > On 10/5/07, chris wrote: > > > > Ok, probably won't get it done till Sunday. > > > > Chris > > > > > > On 10/5/07, George Moschovitis wrote: > > > > > I would be willing to post an example of what I propose to this > > > > list for you guys to consider. > > > > > > > > > > please do so. > > > > > > -g. > > > > > > -- > > > http://gmosx.me.gr > > > http://phidz.com > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071008/203510f2/attachment.html From mvyver at gmail.com Mon Oct 8 06:32:18 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 8 Oct 2007 20:32:18 +1000 Subject: [Nitro] OG [PATCH RFC]: Separate Og.start options hash from Og.manager_options In-Reply-To: <389c43e40709130056p21ef5f8etad1215edc3aaa125@mail.gmail.com> References: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> <389c43e40709130056p21ef5f8etad1215edc3aaa125@mail.gmail.com> Message-ID: <389c43e40710080332l26140532xb6ec9b7978427c03@mail.gmail.com> On 9/13/07, Mark Van De Vyver wrote: > Hi > On 9/13/07, George Moschovitis wrote: > > Seems logical. I am applying the patch. However a better solution is needed > > (that will properly handle multiple Og stores at the same time, for db > > partitioning/sharding, etc) > > I agree. My understanding is that each manger looks after only one > store, but there are multiple managers that are tracked. > I have a solution in mind - that should be backwards compatible, and > handle multiple stores, of different types, and possibly stores of one > type with multiple adapters. > > I'm beginning to form the view that the manager's options should be > separated from (i.e. not sync'd with) the store's options, and both > should at least be attr_readable. > > Anyone have a case for making them, that is `manger.options` and > `store.options`, attr_accessor? > > > We will get back to this at a later time. > > OK. But I'm working on an adapter's spec's now, so I'll post anything > I come up with while it is fresh in my mind. > I'm considering introducing some optional settings that at the moment are specific to the DBI adapter (but needn't be) Question: 1) Is it the case that _any_ setting that can be passed as an option to Og.start(options), should have it's default specified and documented using (example): setting(:name {:default =>true, :doc=>"doc"}) in the Og module file ./lib/og/og.rb? I ask because there is the following comment in og.rb: #-- # TODO: move this to the sql store. #++ which made me wonder if these setting calls should be placed there or elsewhere, even if they can be passed to Og.start(options).... ? Mark > Cheers > Mark > > > > > thank you, > > George. > > > > > > On 9/13/07, Mark Van De Vyver wrote: > > > > > > Hi Devs, > > > > > > Spec's helped indicate something was wrong but it still took much time > > > to work out what - esp given I was working on an adapter spec and this > > > is in the og.rb file.... :) > > > > > > Separate Og start options hash from Og.manager_options - consecutive > > > starts no longer pollute Og.manager_options > > > > > > The attached patch attempts to isolate the options hash that og > > > receives on start, and any changes made to it, from the defaults > > > stored in Og.manager_options. > > > > > > Reason, consider the following sequence (pre-patch): > > > > > > Og.start # Starts with Og default options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > Og.start ({}) # Starts with custom options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > Og.start # Starts with custom options - UNEXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > Instead I believe the startup behavior should be (post-patch): > > > > > > Og.start # Starts with Og default options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > Og.start({}) # Starts with custom options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > Og.start # Starts with Og default options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > The way to change default startup behavior would be (post-patch): > > > > > > Og.manger_options={}.update({}) > > > Og.start #starts with custom options - EXPECTED > > > Og.manager.close_store > > > Og.manager.unmanage_classes > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > -- > > http://www.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > From transfire at gmail.com Mon Oct 8 14:33:12 2007 From: transfire at gmail.com (Trans) Date: Mon, 08 Oct 2007 18:33:12 -0000 Subject: [Nitro] Facets 2.0.2 Message-ID: <1191868392.320912.70690@k79g2000hse.googlegroups.com> George or anyone else reading this. Could you give 2.0.2 and try and make sure it's resolved your load problems. Thanks. T. From prpht9 at gmail.com Mon Oct 8 14:48:16 2007 From: prpht9 at gmail.com (chris) Date: Mon, 8 Oct 2007 14:48:16 -0400 Subject: [Nitro] uninitialized constant OgAdminController::FormHelper (NameError) Message-ID: George, seems nitro-0.50.0 has an issue. When I try to run my nitro application i get... Install XMLSimple for XML input. /usr/local/lib/ruby/gems/1.8/gems/nitro-0.50.0/lib/nitro/part/admin/og/controller.rb:31: uninitialized constant OgAdminController::FormHelper (NameError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /usr/local/lib/ruby/gems/1.8/gems/nitro-0.50.0 /lib/nitro/part/admin.rb:4 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from app.rb:9 my last install of nitro-0.50.0 didn't have this. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071008/05cced90/attachment.html From george.moschovitis at gmail.com Mon Oct 8 15:41:14 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 8 Oct 2007 22:41:14 +0300 Subject: [Nitro] uninitialized constant OgAdminController::FormHelper (NameError) In-Reply-To: References: Message-ID: I will check this tomorrow and fix it. thanks for reporting. -g. On 10/8/07, chris wrote: > > George, > > seems nitro-0.50.0 has an issue. When I try to run my nitro application > i get... > > Install XMLSimple for XML input. > /usr/local/lib/ruby/gems/1.8/gems/nitro-0.50.0/lib/nitro/part/admin/og/controller.rb:31: > uninitialized constant OgAdminController::FormHelper (NameError) > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > from /usr/local/lib/ruby/gems/1.8/gems/nitro- 0.50.0 > /lib/nitro/part/admin.rb:4 > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > > from app.rb:9 > > my last install of nitro-0.50.0 didn't have this. > > Chris > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071008/56260fe4/attachment.html From john at oxyliquit.de Tue Oct 9 02:43:49 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 9 Oct 2007 08:43:49 +0200 Subject: [Nitro] OG [PATCH RFC]: Separate Og.start options hash from Og.manager_options In-Reply-To: <389c43e40710080332l26140532xb6ec9b7978427c03@mail.gmail.com> References: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> <389c43e40709130056p21ef5f8etad1215edc3aaa125@mail.gmail.com> <389c43e40710080332l26140532xb6ec9b7978427c03@mail.gmail.com> Message-ID: <20071009064349.GA24131@oxyliquit.de> Hi, > I'm considering introducing some optional settings that at the moment > are specific to the DBI adapter (but needn't be) > Question: > 1) Is it the case that _any_ setting that can be passed as an option > to Og.start(options), should have it's default specified and > elsewhere, even if they can be passed to Og.start(options).... ? yes, you can pass any option you like to Og.start, it will end up at each adapter where it can be used. MySQL for example has some options which postgresql does not have iirc. Just put the handling + defaults of those options in the recieving adapters, the other adapters will just ignore those options. Jo From john at oxyliquit.de Tue Oct 9 03:03:10 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 9 Oct 2007 09:03:10 +0200 Subject: [Nitro] Updated tutorial In-Reply-To: <4706F9EB.901@arnebrasseur.net> References: <4700EB4F.2010708@arnebrasseur.net> <47019E16.3020401@robmela.com> <4706CE08.70106@robmela.com> <4706F9EB.901@arnebrasseur.net> Message-ID: <20071009070310.GB24131@oxyliquit.de> Hi, > As far as external documentation goes I am (as I said before) a big big > fan of wikis. However this would partly overlap with Oxywtf, so we don't > need it right away. Better to not split community stuff over too many > different locations. So if you feel like contributing stuff, head over > to http://www.Oxywtf.de (insert catchy tune). well, np.org always had a wiki. :) I personally am not a fan of wikis in the following instances: * wiki too small * wiki contains only static page (only a single person editing) * there are very few contributors * wiki too unorganized * wiki has broken links to everywhere * there are often changing contributor 'styles' (hit 'n run) I know that there are plenty of good examples for successful wikis, but they all have something in common: They either have what I call a 'critical mass' or 'dedicated commitment of few'. > The main virtue of the tutorial repo I see is that it can contain a lot > of code examples along with their tutorials. However it might disappear > again in the future as it's contents are merged into the main > repo/rdoc/oxywtf. Should it get to contain more example apps then can be > reasonbly shipped with the main distribution then it might become a > package in its own right (e.g. nitro-examples). This will depend on > community input. I agree this to be worth a try. :) Like I see my oxywtf complementing a wiki (as opposed to 'competing') because of its rather strict nature, this repo could be another fitting piece in the puzzle. It'd be nice to have a few more contributed examples for people to look at and learn from, especially when they are in 'running state' in a repo and always up to date to the current nitro version. Jo From john at oxyliquit.de Tue Oct 9 03:12:41 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 9 Oct 2007 09:12:41 +0200 Subject: [Nitro] Nitro/Og rspec heads-up: any alternative solutions. In-Reply-To: <389c43e40710040249i19ef7429o7171a27252da3ce4@mail.gmail.com> References: <389c43e40710040249i19ef7429o7171a27252da3ce4@mail.gmail.com> Message-ID: <20071009071241.GC24131@oxyliquit.de> Hi, > The essential point is that rspec describe blocks are not isolated name spaces. > Consequence: if you're going to define classes then you'll need to > choose different class names for each describe/example block, or else > the spec's will run a good chance of being contaminated. one more point for the old Test::Unit! ;D But nah, I guess we just have to adhere to some naming scheme... Or packing each spec into a module (which is quite unnice with Og where the generated table name changes)... Jo From william.full.moon at gmail.com Tue Oct 9 04:36:30 2007 From: william.full.moon at gmail.com (* William) Date: Tue, 9 Oct 2007 18:36:30 +1000 Subject: [Nitro] Nitro/Og rspec heads-up: any alternative solutions. In-Reply-To: <20071009071241.GC24131@oxyliquit.de> References: <389c43e40710040249i19ef7429o7171a27252da3ce4@mail.gmail.com> <20071009071241.GC24131@oxyliquit.de> Message-ID: <9e03c3c60710090136t4f9bef49xef751147481dac40@mail.gmail.com> Hi ... I often have been know to make names like: * class Class_test_001 @desc = 'this tests something-K or another" end you use the desc to tell what's IN the test ;) w. On 09/10/2007, Jonathan Buch wrote: > > Hi, > > > The essential point is that rspec describe blocks are not isolated name > spaces. > > Consequence: if you're going to define classes then you'll need to > > choose different class names for each describe/example block, or else > > the spec's will run a good chance of being contaminated. > > one more point for the old Test::Unit! ;D > > But nah, I guess we just have to adhere to some naming scheme... > Or packing each spec into a module (which is quite unnice with Og where > the generated table name changes)... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071009/98ad8fef/attachment.html From george.moschovitis at gmail.com Tue Oct 9 12:50:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 9 Oct 2007 19:50:01 +0300 Subject: [Nitro] Facets 2.0.2 In-Reply-To: <1191868392.320912.70690@k79g2000hse.googlegroups.com> References: <1191868392.320912.70690@k79g2000hse.googlegroups.com> Message-ID: Yeap, it works now :) -g. On 10/8/07, Trans wrote: > > George or anyone else reading this. Could you give 2.0.2 and try and > make sure it's resolved your load problems. Thanks. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071009/d34d6bd6/attachment.html From billk at cts.com Wed Oct 10 01:40:56 2007 From: billk at cts.com (Bill Kelly) Date: Tue, 9 Oct 2007 22:40:56 -0700 Subject: [Nitro] de-bouncing Submit Order button Message-ID: <009601c80b00$21a3af20$6442a8c0@gonzo> Howdy! I'm writing an online store, and I don't want mine to be one of the ones that has to put bold-face warning text by the Submit button, saying: DANGER: PRESS THIS BUTTON ONLY ONCE! :) My current plan is to have any and all POSTs from the Submit button to redirect to a processing_order page, which uses a meta refresh every three seconds or so to poll for the final order completion page. Multiple Submit POSTs does order processing? redirects to: 1st yes processing_order page 2nd no processing_order page 3rd no processing_order page Coupled with that, I need a way to indicate that the current order is in the processing state, and this has to be totally atomic. I'm not sure how fancy I need to get. For example: unless session[:order_in_process] session[:order_in_process] = true # bill credit card end That's essentially what I want to do, but I don't like the potential race condition there. I'll be using Mongrel to host my Nitro app. My understanding is Mongrel uses ruby green threads, and I'm not planning to run multiple Mongrel proxys, just one. I'm also using the MemorySessionStore. So as far as I know, all my requests will be handled in the context of a single ruby process. If so, I presume I could eliminate the above race condition with a global mutex... do_order_processing = false $order_sync_mutex.synchronize { unless session[:order_in_process] session[:order_in_process] = true do_order_processing = true end } if do_order_processing # bill credit card end Anyway, I just wanted to ask if my approach seems reasonable, and/or if I've missed some horrible loophole. Thanks, Bill From aidan at yoyo.org Wed Oct 10 04:21:38 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Wed, 10 Oct 2007 09:21:38 +0100 (BST) Subject: [Nitro] de-bouncing Submit Order button In-Reply-To: <009601c80b00$21a3af20$6442a8c0@gonzo> References: <009601c80b00$21a3af20$6442a8c0@gonzo> Message-ID: <13332.192.193.220.142.1192004498.squirrel@yoyo.org> > Howdy! > > I'm writing an online store, and I don't want mine to be one of > the ones that has to put bold-face warning text by the Submit > button, saying: DANGER: PRESS THIS BUTTON ONLY ONCE! Why not deactivate the button on click and do the order processing asynchronously? Aidan From arne at arnebrasseur.net Wed Oct 10 06:07:27 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 10 Oct 2007 18:07:27 +0800 Subject: [Nitro] de-bouncing Submit Order button In-Reply-To: <13332.192.193.220.142.1192004498.squirrel@yoyo.org> References: <009601c80b00$21a3af20$6442a8c0@gonzo> <13332.192.193.220.142.1192004498.squirrel@yoyo.org> Message-ID: <470CA45F.5040403@arnebrasseur.net> Aidan Rogers schreef: >> Howdy! >> >> I'm writing an online store, and I don't want mine to be one of >> the ones that has to put bold-face warning text by the Submit >> button, saying: DANGER: PRESS THIS BUTTON ONLY ONCE! >> > > Why not deactivate the button on click and do the order processing > asynchronously? > Good idea but breaks when Javascript is disabled/not available. (ab) > Aidan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071010/ebae89b4/attachment.html From billk at cts.com Wed Oct 10 15:29:49 2007 From: billk at cts.com (Bill Kelly) Date: Wed, 10 Oct 2007 12:29:49 -0700 Subject: [Nitro] de-bouncing Submit Order button References: <009601c80b00$21a3af20$6442a8c0@gonzo> <13332.192.193.220.142.1192004498.squirrel@yoyo.org> Message-ID: <007801c80b73$ecc09dd0$6442a8c0@gonzo> From: Arne Brasseur > From: "Aidan Rogers" > >> > >> I'm writing an online store, and I don't want mine to be one of > >> the ones that has to put bold-face warning text by the Submit > >> button, saying: DANGER: PRESS THIS BUTTON ONLY ONCE! > > > > Why not deactivate the button on click and do the order processing > > asynchronously? > > Good idea but breaks when Javascript is disabled/not available. Indeed, I like the idea, thanks. My store currently uses no Javascript at all, though. Also I favor debouncing on the server side in the hopes of allowing the client to recover from situations like: - client clicks submit, but their wireless connection drops after the POST, and they get a server timed out - client clicks back button and clicks submit again; the server sees the POST a second time, but that's fine I think my proposed approach will handle these situations safely, but it all depends on all Nitro requests being handled by a single Ruby process. That means I have to make sure the http server isn't set up to proxy requests to multiple Mongrel processes, and such. (But we have a low-traffic site, so I don't anticipate needing to scale to multiple Mongrel processes anytime soon. If I did, I guess I could use a filesystem lock instead of a Ruby Mutex.) Regards, Bill From george.moschovitis at gmail.com Wed Oct 10 16:16:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 10 Oct 2007 23:16:01 +0300 Subject: [Nitro] de-bouncing Submit Order button In-Reply-To: <009601c80b00$21a3af20$6442a8c0@gonzo> References: <009601c80b00$21a3af20$6442a8c0@gonzo> Message-ID: I am not sure I understand your polling idea :( -g. -- http://gmosx.me.gr http://phidz.com 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/20071010/293b6987/attachment.html From transfire at gmail.com Wed Oct 10 17:42:33 2007 From: transfire at gmail.com (Trans) Date: Wed, 10 Oct 2007 21:42:33 -0000 Subject: [Nitro] ANN: English 0.1 Message-ID: <1192052553.473384.160540@r29g2000hsg.googlegroups.com> I just made the initial release of English. English is one the Facets spin-off projects. It is the collection of English language related libraries. On the whole the libraries contained are just as they were from Facets 1.8.54. However I worked on inflect.rb (singular/plural conversion) and it working even better now. Ah, another small step toward the next release of Nitro... gem install english T. From billk at cts.com Wed Oct 10 18:32:21 2007 From: billk at cts.com (Bill Kelly) Date: Wed, 10 Oct 2007 15:32:21 -0700 Subject: [Nitro] de-bouncing Submit Order button References: <009601c80b00$21a3af20$6442a8c0@gonzo> Message-ID: <00f601c80b8d$6c645c70$6442a8c0@gonzo> From: George Moschovitis > > I am not sure I understand your polling idea :( The polling idea was a method of presenting an, "We are processing your order, this may take a moment..." page, while the server is completing the purchase in an asynchronous thread. (Also it was conceived as a way of eliminating special cases, in that every (possible) multiple click of the Submit button goes through the same logic.) The processing_order page polls "itself" with a and as long as the server is still busy processing the order, the page remains at the "...this may take a moment." page. But when it polls and the order is complete, then its Controller redirects to a final order complete, or purchase failed page. The logic for the refresh page looks like this: # This is a meta-refresh holding page... the user can click the Submit button on # final_review as much as they like, and they'll end up here def processing_order do_process_order = false $order_sync_mutex.synchronize { if session[:order_process_state].nil? session[:order_process_state] = :in_process do_process_order = true end } if do_process_order kickoff_async_process_order_and_bill_cc sleep 2.0 # if it hasn't completed by this time, we'll show the "This may take a moment..." page end order_state = $order_sync_mutex.synchronize { session[:order_process_state] } case order_state when :complete then redirect :order_complete when :fail then redirect :purchase_error else # continue and display the processing_order meta refresh html end end So, everytime processing_order is invoked, it checks the session[:order_process_state] value. If we haven't begun processing the order yet, it knows to kick off the async processing. Regardless, it always checks the current session[:order_process_state] at the end, to determine whether to remain on the "This may take a moment" polling page, or proceed to the purchase succeeded/failed pages. Does that make sense and/or seem reasonable? Regards, Bill From rob at robmela.com Wed Oct 10 23:02:01 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 10 Oct 2007 23:02:01 -0400 Subject: [Nitro] Adapter options Message-ID: <470D9229.4080303@robmela.com> Patch to raw/lib/raw/adapter/mongrel.rb to -- allow passing application.options to Mongrel startup ( application.options currently available for webrick startup ) -- read and use mongrel options from conf/mongrel_#{Nitro.mode}.yml -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mongrel_config_options Url: http://rubyforge.org/pipermail/nitro-general/attachments/20071010/125dc4b0/attachment.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071010/125dc4b0/attachment-0001.vcf From george.moschovitis at gmail.com Thu Oct 11 06:47:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 11 Oct 2007 13:47:37 +0300 Subject: [Nitro] Adapter options In-Reply-To: <470D9229.4080303@robmela.com> References: <470D9229.4080303@robmela.com> Message-ID: please, resend as zipped attachment! -g. -- http://gmosx.me.gr http://phidz.com 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/20071011/5afc78da/attachment.html From mvyver at gmail.com Thu Oct 11 08:31:55 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 11 Oct 2007 22:31:55 +1000 Subject: [Nitro] OG [RFC]: Multiple field indices Message-ID: <389c43e40710110531h5058f597j7327b92dcb785d10@mail.gmail.com> Hi Devs, I have a initial attempt at implementing multiple field indices for Og. The code isn't ready for submission yet, I'm still working on the DBI adapter. However I'd appreciate feedback on any potential problems/issues. An initial RDoc is below, then I give some examples and the index code they generate. Note re the examples: They are generated using the MySQL DBD, but some have Sqlite valid commands, so this is just more for feature illustration at this point. For the Rdoc's I hope it is clear but if not not please let me know. Is there some killer feature missing? # Create indices on the table corresponding to klass. Returns +true+ if no # errors are encountered, +false+ is returned otherwise. The index name is # constructed in the following way: +__idx+ # # An single field +:index+ attribute can have optional text set using the # following annotations (See below for further details): # - +:index_name+ # - +:index_order+ # - +:index_length+ # - +:index_type+ # - +:index_using+ # - +:pre_index+ # - +:post_index+ # - +:pre_index_field+ # - +:post_index_field+ # # "CREATE #{pre_index} INDEX #{index_name} #{post_index} ON #{table} # (#{pre_field} #{field} #{post_field})" # # Multiple field indices can be specified using :index => Hash. # A field may belong to multiple indices, and the +:index+ Hash has the # following format: # {1 => index_details_hash, 2 => index_details_hash, ...} # # The contents of a valid index details hash will depend on the database # used. Users are responsible for nominating options that are valid for the # database being employed. # # The recognized +index_details_hash+ hash keys (their defaults) and # a brief description (alphabetical order): # - +:name+ (constructed) A string containing the index name. This need # only be provided once of an index, and can be given in any index_details_hash # of any index field. If not provided a name is constructed from the # table and field names (ordered) and the suffix "_idx". # - +:position+ (alphabetical) The position of the field in the index. If # a position is not given the field is placed in alphabetical order, after # the position fields. Discontinuities in position numbering is respected, and # the alphabetically sorted fields are interleaved between # discontinuously positioned fields. # - +:order+ (+nil+) The field sort order. Recognized values are: +:asc:+, # +:desc+ [MySQL & Sqlite specific]. # - +:length+ (+nil+) Index that uses only the leading +:length+ of column # values. Required for some datatypes. [MySQL specific]. # - +:type+ (+nil+) Need only be defined in one field's index hash. # Recognized types are: # * +:unique+, # * +:fulltext+, # * +:spatial+ # - +:using+ (+nil+) Recognized values are: # * +:btree+, (MySQL|PG) # * +:hash+, (MySQL|PG) # * +:gist+, (PG) # * +:gin+, (PG) # * +:rtree+ (MySQL) # - +:pre_index+ (+nil+) String to insert before the SQL 'INDEX' keyword. # - +:post_index+ (+nil+) String to insert after the SQL 'INDEX' keyword. # - +:pre_field+ (+nil+) String to insert before the index field name. # - +:post_field+ (+nil+) String to insert after the index field name. # # === Example # Multiple field index (MySQL so length is required for any text and binary fields) # # class Person # attr_accessor :name, String, :index => {1 => {:name => "my_first_idx", # :position => 2, :type => :unique, :length => 40}, # 4 => {:length => 20}} # attr_accessor :age, Integer, :index => true # attr_accessor :height_a, Float, :index => {1 => {:position => 1}, # 3 => true, # 4 => true} # attr_accessor :height_b, Float, :index => {1 => true, # 3 => true, # 4 => true} # end # # Multiple field index, illustrating pre and post index keywords (MySQL): # # class Person # attr_accessor :name, String, :index => true, # :pre_index => "UNIQUE", :post_index => "USING HASH", # :post_index_field =>"(20) ASC" # attr_accessor :age, Integer, :index => true, # :pre_index => "FULLTEXT", :post_index => "USING BTREE", # :post_index_field =>"DESC" # attr_accessor :height, Float, :index => true, # :pre_index => "SPATIAL", :post_index_field => "ASC" # end # # Note: Serializable (false) overrides index annotation. Only two indices # (+name+ and +age+) are created by the following: # # class MyClass # attr_accessor :test # attr_accessor :name, String, :doc => 'Hello', :index => true # attr_accessor :age, Fixnum, :index => true # attr_accessor :body, String, :index => true, :serialize => false # end # # === Errors # No exceptions are raised by this method. Specifically it is not possible # to discern if an index already exists, and whether this causes all drivers to # raise an exception. If DbiAdapter#create_one_table_index returns +false+ # then DbiAdapter#create_table_indices creates an error log entry and # returns false. # # === Notes # The +pre_index+, +post_index+, +pre_field+ and +post_feild+ text/keywords # are database dependent - please consult the database documentation for # details. All table, field, and index names are quoted using the reserved # word quote character, see + at options[:rw_quote_character]+. # Serializable (false) overrides index annotation. # class Person_013 attr_accessor :name, String, :index => true, :pre_index => "UNIQUE", :post_index => "USING BTREE", :pre_index_field => "", :post_index_field => "(20) ASC" attr_accessor :age, Integer, :index => true, :pre_index => "UNIQUE", :post_index => "USING BTREE", :pre_index_field => "", :index_length => 20, :index_order => :desc attr_accessor :height, Float, :index => true, :pre_index => "UNIQUE", :post_index => "USING BTREE", :pre_index_field => "", :post_index_field => "COLLATE collation-name", :index_order => :asc end "CREATE UNIQUE INDEX USING BTREE `ogperson_013_name_idx` ON `ogperson_013` ( `name` (20) ASC );" "CREATE UNIQUE INDEX USING BTREE `ogperson_013_age_idx` ON `ogperson_013` ( `age`(20) DESC );" "CREATE UNIQUE INDEX USING BTREE `ogperson_013_height_idx` ON `ogperson_013` ( `height` COLLATE collation-name ASC );" class Person_014 attr_accessor :name, String, :index => {1 => {:name => "my_own_idx", :position => 2, :type => :unique, :length => 40}, 4 => {:length => 20, :using => :btree}} attr_accessor :age, Integer, :index => true, :post_index => "IF NOT EXISTS" attr_accessor :height_a, Float, :index => {1 => {:position => 1}, 4 => true, 5 => true} attr_accessor :height_b, Float, :index => {1 => true, 4 => true, 5 => true} end "CREATE INDEX `ogperson_014_height_a_height_b_idx` ON `ogperson_014` ( `height_a`, `height_b` );" "CREATE INDEX `ogperson_014_height_b_height_a_name_idx` ON `ogperson_014` ( `height_b`, `height_a`, `name`(40) );" "CREATE INDEX `ogperson_014_height_a_height_b_name_idx` USING BTREE ON `ogperson_014` ( `height_a`, `height_b`, `name`(20) );" Reagrds Mark From george.moschovitis at gmail.com Thu Oct 11 09:44:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 11 Oct 2007 16:44:38 +0300 Subject: [Nitro] OG [RFC]: Multiple field indices In-Reply-To: <389c43e40710110531h5058f597j7327b92dcb785d10@mail.gmail.com> References: <389c43e40710110531h5058f597j7327b92dcb785d10@mail.gmail.com> Message-ID: Very interesting, I will check this in detail when I return home :) thanks, -g. On 10/11/07, Mark Van De Vyver wrote: > > Hi Devs, > > I have a initial attempt at implementing multiple field indices for Og. > The code isn't ready for submission yet, I'm still working on the DBI > adapter. However I'd appreciate feedback on any potential > problems/issues. > > An initial RDoc is below, then I give some examples and the index code > they generate. > Note re the examples: They are generated using the MySQL DBD, but > some have Sqlite valid commands, so this is just more for feature > illustration at this point. > For the Rdoc's I hope it is clear but if not not please let me know. > Is there some killer feature missing? > > # Create indices on the table corresponding to klass. Returns +true+ > if no > # errors are encountered, +false+ is returned otherwise. The index > name is > # constructed in the following way: +
__idx+ > # > # An single field +:index+ attribute can have optional text set using > the > # following annotations (See below for further details): > # - +:index_name+ > # - +:index_order+ > # - +:index_length+ > # - +:index_type+ > # - +:index_using+ > # - +:pre_index+ > # - +:post_index+ > # - +:pre_index_field+ > # - +:post_index_field+ > # > # "CREATE #{pre_index} INDEX #{index_name} #{post_index} ON #{table} > # (#{pre_field} #{field} #{post_field})" > # > # Multiple field indices can be specified using :index => > Hash. > # A field may belong to multiple indices, and the +:index+ Hash has > the > # following format: > # {1 => index_details_hash, 2 => index_details_hash, ...} > # > # The contents of a valid index details hash will depend on the > database > # used. Users are responsible for nominating options that are valid > for the > # database being employed. > # > # The recognized +index_details_hash+ hash keys (their defaults) and > # a brief description (alphabetical order): > # - +:name+ (constructed) A string containing the index name. This > need > # only be provided once of an index, and can be given in any > index_details_hash > # of any index field. If not provided a name is constructed from > the > # table and field names (ordered) and the suffix "_idx". > # - +:position+ (alphabetical) The position of the field in the > index. If > # a position is not given the field is placed in alphabetical > order, after > # the position fields. Discontinuities in position numbering is > respected, and > # the alphabetically sorted fields are interleaved between > # discontinuously positioned fields. > # - +:order+ (+nil+) The field sort order. Recognized values are: > +:asc:+, > # +:desc+ [MySQL & Sqlite specific]. > # - +:length+ (+nil+) Index that uses only the leading +:length+ of > column > # values. Required for some datatypes. [MySQL specific]. > # - +:type+ (+nil+) Need only be defined in one field's index hash. > # Recognized types are: > # * +:unique+, > # * +:fulltext+, > # * +:spatial+ > # - +:using+ (+nil+) Recognized values are: > # * +:btree+, (MySQL|PG) > # * +:hash+, (MySQL|PG) > # * +:gist+, (PG) > # * +:gin+, (PG) > # * +:rtree+ (MySQL) > # - +:pre_index+ (+nil+) String to insert before the SQL 'INDEX' > keyword. > # - +:post_index+ (+nil+) String to insert after the SQL 'INDEX' > keyword. > # - +:pre_field+ (+nil+) String to insert before the index field > name. > # - +:post_field+ (+nil+) String to insert after the index field > name. > # > # === Example > # Multiple field index (MySQL so length is required for any text > and binary fields) > # > # class Person > # attr_accessor :name, String, :index => {1 => {:name => > "my_first_idx", > # :position => 2, :type => :unique, :length => 40}, > # 4 => {:length => 20}} > # attr_accessor :age, Integer, :index => true > # attr_accessor :height_a, Float, :index => {1 => {:position => 1}, > # 3 => true, > # 4 => true} > # attr_accessor :height_b, Float, :index => {1 => true, > # 3 => true, > # 4 => true} > # end > # > # Multiple field index, illustrating pre and post index keywords > (MySQL): > # > # class Person > # attr_accessor :name, String, :index => true, > # :pre_index => "UNIQUE", :post_index => "USING HASH", > # :post_index_field =>"(20) ASC" > # attr_accessor :age, Integer, :index => true, > # :pre_index => "FULLTEXT", :post_index => "USING > BTREE", > # :post_index_field =>"DESC" > # attr_accessor :height, Float, :index => true, > # :pre_index => "SPATIAL", :post_index_field => "ASC" > # end > # > # Note: Serializable (false) overrides index annotation. Only two > indices > # (+name+ and +age+) are created by the following: > # > # class MyClass > # attr_accessor :test > # attr_accessor :name, String, :doc => 'Hello', :index => true > # attr_accessor :age, Fixnum, :index => true > # attr_accessor :body, String, :index => true, :serialize => false > # end > # > # === Errors > # No exceptions are raised by this method. Specifically it is not > possible > # to discern if an index already exists, and whether this causes > all drivers to > # raise an exception. If DbiAdapter#create_one_table_index returns > +false+ > # then DbiAdapter#create_table_indices creates an error log entry and > # returns false. > # > # === Notes > # The +pre_index+, +post_index+, +pre_field+ and +post_feild+ > text/keywords > # are database dependent - please consult the database documentation > for > # details. All table, field, and index names are quoted using the > reserved > # word quote character, see + at options[:rw_quote_character]+. > # Serializable (false) overrides index annotation. > # > > > class Person_013 > attr_accessor :name, String, :index => true, :pre_index => "UNIQUE", > :post_index => "USING BTREE", :pre_index_field => "", > :post_index_field => "(20) ASC" > attr_accessor :age, Integer, :index => true, :pre_index => "UNIQUE", > :post_index => "USING BTREE", :pre_index_field => "", :index_length => > 20, > :index_order => :desc > attr_accessor :height, Float, :index => true, :pre_index => "UNIQUE", > :post_index => "USING BTREE", :pre_index_field => "", > :post_index_field => "COLLATE collation-name", :index_order => :asc > end > > "CREATE UNIQUE INDEX USING BTREE `ogperson_013_name_idx` ON `ogperson_013` > ( `name` (20) ASC );" > "CREATE UNIQUE INDEX USING BTREE `ogperson_013_age_idx` ON `ogperson_013` > ( `age`(20) DESC );" > "CREATE UNIQUE INDEX USING BTREE `ogperson_013_height_idx` ON > `ogperson_013` > ( `height` COLLATE collation-name ASC );" > > > class Person_014 > attr_accessor :name, String, :index => {1 => {:name => "my_own_idx", > :position => 2, :type => :unique, :length => 40}, > 4 => {:length => 20, :using => > :btree}} > attr_accessor :age, Integer, :index => true, :post_index => "IF NOT > EXISTS" > attr_accessor :height_a, Float, :index => {1 => {:position => 1}, > 4 => true, > 5 => true} > attr_accessor :height_b, Float, :index => {1 => true, > 4 => true, > 5 => true} > end > > "CREATE INDEX `ogperson_014_height_a_height_b_idx` ON `ogperson_014` ( > `height_a`, `height_b` );" > "CREATE INDEX `ogperson_014_height_b_height_a_name_idx` ON > `ogperson_014` ( `height_b`, `height_a`, `name`(40) );" > "CREATE INDEX `ogperson_014_height_a_height_b_name_idx` USING BTREE ON > `ogperson_014` ( `height_a`, `height_b`, `name`(20) );" > > > Reagrds > > Mark > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071011/91a2b099/attachment-0001.html From rob at robmela.com Thu Oct 11 12:49:33 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 11 Oct 2007 12:49:33 -0400 Subject: [Nitro] Adapter options In-Reply-To: References: <470D9229.4080303@robmela.com> Message-ID: <470E541D.4030008@robmela.com> I suppose you want whipped cream and truffles too ;) George Moschovitis wrote: > please, resend as zipped attachment! > > -g. > > > > -- > http://gmosx.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org -------------- next part -------------- A non-text attachment was scrubbed... Name: mongrel_config_options.gz Type: application/x-gzip Size: 19047 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071011/4c41ffe0/attachment.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071011/4c41ffe0/attachment.vcf From mvyver at gmail.com Thu Oct 11 23:20:58 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 12 Oct 2007 13:20:58 +1000 Subject: [Nitro] OG [PATCH]: Alphabetize the setting listing - should help finding our way around? Message-ID: <389c43e40710112020y207a49b7y44c14fa441f15f9e@mail.gmail.com> Alphabetize the setting listing - should help finding our way around? -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20071012-1.tar.gz Type: application/x-gzip Size: 19567 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071012/56415232/attachment-0001.gz From george.moschovitis at gmail.com Fri Oct 12 04:21:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 12 Oct 2007 11:21:57 +0300 Subject: [Nitro] OG [PATCH]: Alphabetize the setting listing - should help finding our way around? In-Reply-To: <389c43e40710112020y207a49b7y44c14fa441f15f9e@mail.gmail.com> References: <389c43e40710112020y207a49b7y44c14fa441f15f9e@mail.gmail.com> Message-ID: thanks, this is useful! -g. -- http://gmosx.me.gr http://phidz.com 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/20071012/794ac3bf/attachment.html From george.moschovitis at gmail.com Fri Oct 12 08:00:08 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 12 Oct 2007 15:00:08 +0300 Subject: [Nitro] Questions Message-ID: Dear devs, I would like to hear your opinion on two issues: - I am thinking about automatically performing CGI.unescape to query parameters. - I am thinking about dropping the trailing x from template files. this is helpful with code editors: no need to setup syntax highlighting for .htmlx files. all files inside the template dirs will be recognised as templates. what do you think? -- http://gmosx.me.gr http://phidz.com 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/20071012/b31443f2/attachment.html From prpht9 at gmail.com Fri Oct 12 09:46:56 2007 From: prpht9 at gmail.com (chris) Date: Fri, 12 Oct 2007 09:46:56 -0400 Subject: [Nitro] Questions In-Reply-To: References: Message-ID: I love the removal of the x on htmlx idea. Just existing in the template directory should designate it as a template. However we may want to discuss the best way for <0.4X.0 nitro users to migrate if you make this change. Such as a command line tool to convert such files, with a couple checks to make sure your not overwriting files already present. Or even nitro automatically converting if the .html file if it doesn't exist already and kicking out a warning if it does. Chris On 10/12/07, George Moschovitis wrote: > > Dear devs, > > I would like to hear your opinion on two issues: > > - I am thinking about automatically performing CGI.unescape to query > parameters. > > - I am thinking about dropping the trailing x from template files. this is > helpful with code editors: no need to setup > syntax highlighting for .htmlx files. > all files inside the template dirs will be recognised as templates. > > what do you think? > > -- > http://gmosx.me.gr > http://phidz.com > 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 -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071012/30e03609/attachment.html From work at ashleymoran.me.uk Fri Oct 12 21:18:12 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Sat, 13 Oct 2007 02:18:12 +0100 Subject: [Nitro] Facets version in glue Message-ID: Hi Finally got back to Nitro - been swamped by business related stuff. While I've been away, the version of facets has been revved to 2.0.2, but the reference in the glue gem spec is 1.8.54 $ rake dist:all $ sudo gem install dist/glue-0.50.0.gem dist/og-0.50.0.gem dist/ raw-0.50.0.gem dist/nitro-0.50.0.gem ERROR: While executing gem ... (RuntimeError) Error instaling dist/glue-0.50.0.gem: glue requires facets = 1.8.54 I changed the requirement to allow Facets 2 but I wasn't sure if that was correct. From the discussions I've skimmed over, I was under the impression Nitro 0.50 was intended to use Facets 2? Incidentally, is the above the easiest way to get the latest Nitro? I remember setting a few environment variables first time round, can't remember what they are though. Thanks Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home From george.moschovitis at gmail.com Sat Oct 13 04:04:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 13 Oct 2007 11:04:44 +0300 Subject: [Nitro] Facets version in glue In-Reply-To: References: Message-ID: No, Nitro is not yet converted to use facets 2.0.2 -g. On 10/13/07, Ashley Moran wrote: > > Hi > > Finally got back to Nitro - been swamped by business related stuff. > While I've been away, the version of facets has been revved to 2.0.2, > but the reference in the glue gem spec is 1.8.54 > > $ rake dist:all > > $ sudo gem install dist/glue-0.50.0.gem dist/og-0.50.0.gem dist/ > raw-0.50.0.gem dist/nitro-0.50.0.gem > > ERROR: While executing gem ... (RuntimeError) > Error instaling dist/glue-0.50.0.gem: > glue requires facets = 1.8.54 > > I changed the requirement to allow Facets 2 but I wasn't sure if that > was correct. From the discussions I've skimmed over, I was under the > impression Nitro 0.50 was intended to use Facets 2? > > Incidentally, is the above the easiest way to get the latest Nitro? > I remember setting a few environment variables first time round, > can't remember what they are though. > > Thanks > Ashley > > > -- > blog @ http://aviewfromafar.net/ > linked-in @ http://www.linkedin.com/in/ashleymoran > currently @ home > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071013/781f8401/attachment.html From work at ashleymoran.me.uk Sat Oct 13 09:15:42 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Sat, 13 Oct 2007 14:15:42 +0100 Subject: [Nitro] Facets version in glue In-Reply-To: References: Message-ID: <010061C5-0267-4D5E-B3AD-0C4D13404CED@ashleymoran.me.uk> On Oct 13, 2007, at 9:04 am, George Moschovitis wrote: > No, Nitro is not yet converted to use facets 2.0.2 Ok cool, I will continue with 1.8.54 for now -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ home From arne at arnebrasseur.net Sat Oct 13 09:52:29 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 13 Oct 2007 21:52:29 +0800 Subject: [Nitro] Questions In-Reply-To: References: Message-ID: <4710CD9D.5090001@arnebrasseur.net> I'm ok with dropping the x. (ab) chris schreef: > I love the removal of the x on htmlx idea. Just existing in the > template directory should designate it as a template. However we may > want to discuss the best way for <0.4X.0 nitro users to migrate if you > make this change. Such as a command line tool to convert such files, > with a couple checks to make sure your not overwriting files already > present. Or even nitro automatically converting if the .html file if > it doesn't exist already and kicking out a warning if it does. > > Chris > > > On 10/12/07, *George Moschovitis* > wrote: > > Dear devs, > > I would like to hear your opinion on two issues: > > - I am thinking about automatically performing CGI.unescape to > query parameters. > > - I am thinking about dropping the trailing x from template files. > this is helpful with code editors: no need to setup > syntax highlighting for .htmlx files. > all files inside the template dirs will be recognised as templates. > > what do you think? > > -- > http://gmosx.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071013/960816df/attachment-0001.html From george.moschovitis at gmail.com Sat Oct 13 10:09:50 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 13 Oct 2007 17:09:50 +0300 Subject: [Nitro] Questions In-Reply-To: <4710CD9D.5090001@arnebrasseur.net> References: <4710CD9D.5090001@arnebrasseur.net> Message-ID: ok... On 10/13/07, Arne Brasseur wrote: > > I'm ok with dropping the x. > > (ab) > > chris schreef: > > I love the removal of the x on htmlx idea. Just existing in the template > directory should designate it as a template. However we may want to discuss > the best way for <0.4X.0 nitro users to migrate if you make this change. > Such as a command line tool to convert such files, with a couple checks to > make sure your not overwriting files already present. Or even nitro > automatically converting if the .html file if it doesn't exist already and > kicking out a warning if it does. > > Chris > > > On 10/12/07, George Moschovitis wrote: > > > > Dear devs, > > > > I would like to hear your opinion on two issues: > > > > - I am thinking about automatically performing CGI.unescape to query > > parameters. > > > > - I am thinking about dropping the trailing x from template files. this > > is helpful with code editors: no need to setup > > syntax highlighting for .htmlx files. > > all files inside the template dirs will be recognised as templates. > > > > what do you think? > > > > -- > > http://gmosx.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.netarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://gmosx.me.gr http://phidz.com 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/20071013/852a8d97/attachment.html From rob at robmela.com Mon Oct 15 23:57:47 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 15 Oct 2007 23:57:47 -0400 Subject: [Nitro] Questions In-Reply-To: References: <4710CD9D.5090001@arnebrasseur.net> Message-ID: <471436BB.2070004@robmela.com> I move the 'x' be replaced with ? I agree that directory location is sufficient. I also like the idea of unescaping CGI variables. George Moschovitis wrote: > ok... > > > On 10/13/07, *Arne Brasseur* > wrote: > > I'm ok with dropping the x. > > (ab) > > chris schreef: >> I love the removal of the x on htmlx idea. Just existing in the >> template directory should designate it as a template. However we >> may want to discuss the best way for <0.4X.0 nitro users to >> migrate if you make this change. Such as a command line tool to >> convert such files, with a couple checks to make sure your not >> overwriting files already present. Or even nitro automatically >> converting if the .html file if it doesn't exist already and >> kicking out a warning if it does. >> >> Chris > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071015/9d76cb9c/attachment.vcf From rob at robmela.com Tue Oct 16 09:23:28 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 09:23:28 -0400 Subject: [Nitro] Q: refers_to / belongs_to vs. joins_many / many_to_many Message-ID: <4714BB50.7080908@robmela.com> Poking about in og/relation/* and experimenting as I try to unravel this for http://robmela.com/cheatsheets/og_relations ( hopefully in a form that can be used in the rdocs for og or relation ) BelongsTo inherits from RefersTo but with this annotation in "enchant" target_class.ann!(:self)[:descendants] ||= [] target_class.ann!(:self, :descendants) << [owner_class, foreign_key] Something similar shows up in JoinsMany with a comment: # Add join class to ann(:descendants) to be able to use cascade deletes. owner_class.ann!(:self)[:descendants] ||= [] owner_class.ann!(:self, :descendants) << [tmp_join_class, owner_key] Is there a lack of symmetry here? RefersTo <= BelongsTo, with descendants annotation on the *latter* JoinsMany <= ManyToMany, with annotation on the *former* -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071016/ae073609/attachment.vcf From prpht9 at gmail.com Tue Oct 16 10:06:53 2007 From: prpht9 at gmail.com (chris) Date: Tue, 16 Oct 2007 10:06:53 -0400 Subject: [Nitro] Questions In-Reply-To: <471436BB.2070004@robmela.com> References: <4710CD9D.5090001@arnebrasseur.net> <471436BB.2070004@robmela.com> Message-ID: Rob, What's your reasoning for using the "?" as part of the file extension? Chris On 10/15/07, Robert Mela wrote: > > I move the 'x' be replaced with $BHe(B > > I agree that directory location is sufficient. I also like the idea of > unescaping CGI variables. > > George Moschovitis wrote: > > ok... > > > > > > On 10/13/07, *Arne Brasseur* > > wrote: > > > > I'm ok with dropping the x. > > > > (ab) > > > > chris schreef: > >> I love the removal of the x on htmlx idea. Just existing in the > >> template directory should designate it as a template. However we > >> may want to discuss the best way for <0.4X.0 nitro users to > >> migrate if you make this change. Such as a command line tool to > >> convert such files, with a couple checks to make sure your not > >> overwriting files already present. Or even nitro automatically > >> converting if the .html file if it doesn't exist already and > >> kicking out a warning if it does. > >> > >> Chris > > > > > _______________________________________________ > 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/20071016/37664e1a/attachment.html From rob at robmela.com Tue Oct 16 10:22:07 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 16 Oct 2007 10:22:07 -0400 Subject: [Nitro] Questions In-Reply-To: References: <4710CD9D.5090001@arnebrasseur.net> <471436BB.2070004@robmela.com> Message-ID: <4714C90F.8010308@robmela.com> I was trying to be silly.. It was supposed to be a Japanese character... sent as UTF-8... sorry about the noise. chris wrote: > Rob, > > What's your reasoning for using the "?" as part of the file extension? > > Chris > > > On 10/15/07, *Robert Mela* < rob at robmela.com > > wrote: > > I move the 'x' be replaced with $BHe(B > > I agree that directory location is sufficient. I also like the > idea of > unescaping CGI variables. > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071016/5bd7bfd0/attachment.vcf From mvyver at gmail.com Wed Oct 17 01:48:23 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 17 Oct 2007 15:48:23 +1000 Subject: [Nitro] Q: refers_to / belongs_to vs. joins_many / many_to_many In-Reply-To: <4714BB50.7080908@robmela.com> References: <4714BB50.7080908@robmela.com> Message-ID: <389c43e40710162248m1a88c7f1w48ebcd646dd0b4b3@mail.gmail.com> On 10/16/07, Robert Mela wrote: > Poking about in og/relation/* and experimenting as I try to unravel this > for http://robmela.com/cheatsheets/og_relations ( hopefully in a form > that can be used in the rdocs for og or relation ) Thanks, for the cheat sheets! Sorry I can't shed an light on the issue below - I haven't looked at or given thought to that area of the code. Mark > > BelongsTo inherits from RefersTo but with this annotation in "enchant" > > > target_class.ann!(:self)[:descendants] ||= [] > target_class.ann!(:self, :descendants) << [owner_class, foreign_key] > > Something similar shows up in JoinsMany with a comment: > > # Add join class to ann(:descendants) to be able to use cascade > deletes. > > owner_class.ann!(:self)[:descendants] ||= [] > owner_class.ann!(:self, :descendants) << [tmp_join_class, owner_key] > > > Is there a lack of symmetry here? > > RefersTo <= BelongsTo, with descendants annotation on the *latter* > JoinsMany <= ManyToMany, with annotation on the *former* > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From rob at robmela.com Thu Oct 18 21:09:12 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 18 Oct 2007 21:09:12 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: <470504E1.90206@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> Message-ID: <471803B8.7040007@robmela.com> What version of Apache, gcc, and what general OS? Are you not allowed to run your own web server at your providor? What, generally, is the interest level in the small but growing Nitro community in deploying with FastCGI? Arne Brasseur wrote: > This seems the way to go, but unfortunately mod_proxy is not an option > for me. I'm on shared hosting with little chance of changing apache's > configuration, except by .htaccess files. It seems both cgi and fcgi > adapters are simply broken because of changes to the adapter > interface. E.g. what used to be class methods are now instance > methods, but that's not all. > > Would it be hard to fix them? Or just one of them? I'm not too > concerned about performance at this point, if it runs I'd be happy. If > they're not being fixed please add a big BROKEN sign or remove them > altogether. > > Thank you (once again)! > > (ab) -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071018/2c577c2a/attachment-0001.vcf From arne at arnebrasseur.net Thu Oct 18 23:06:05 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 19 Oct 2007 11:06:05 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: <471803B8.7040007@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> Message-ID: <47181F1D.4060207@arnebrasseur.net> They run on debian. I don't have access to the main apache config. I can only use a web panel to select a directory as document root, the version of PHP and if I want to enable FastCGI on that domain. That's it. The rest has to be done with .htaccess files. They make a big thing out of supporting Ruby/Rails, but in the end the support totally sucks. They have a watchdog process that seemingly randomly kills user processes, so every few pages you get a "server 500" because the fcgi process got killed. But they're cheap and I payed two years in advance so I'll have to live with it a little longer. It's Dreamhost BTW, don't go there if you're serious about using Ruby stuff. I've been looking at it the last few days and have more or less functioning CGI/FastCGI adapters. They need more testing. After that I'll send a patch and write something on oxywtf about deploying with fcgi. Thanks for responding! (ab) Robert Mela schreef: > What version of Apache, gcc, and what general OS? > > Are you not allowed to run your own web server at your providor? > > What, generally, is the interest level in the small but growing Nitro > community in deploying with FastCGI? > > Arne Brasseur wrote: >> This seems the way to go, but unfortunately mod_proxy is not an >> option for me. I'm on shared hosting with little chance of changing >> apache's configuration, except by .htaccess files. It seems both cgi >> and fcgi adapters are simply broken because of changes to the adapter >> interface. E.g. what used to be class methods are now instance >> methods, but that's not all. >> >> Would it be hard to fix them? Or just one of them? I'm not too >> concerned about performance at this point, if it runs I'd be happy. >> If they're not being fixed please add a big BROKEN sign or remove >> them altogether. >> >> Thank you (once again)! >> >> (ab) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net From rob at robmela.com Thu Oct 18 23:51:13 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 18 Oct 2007 23:51:13 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: <471803B8.7040007@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> Message-ID: <471829B1.5080708@robmela.com> Here's an initial cracking of the nut. Needs much refinement. I have no idea whether this handles posts or not -- my hope is all the gnarly details are now handled by handle_context in adapter.rb. If the approach is acceptable then there's probably a lengthy method in raw/cgi.rb that can be removed. require "raw/adapter" # No multi-threading. Og.thread_safe = false if defined?(Og) and Og.respond_to?(:thread_safe) module Raw # A plain CGI adapter. To be used only in development # environments, this adapter is *extremely* slow for # live/production environments. This adapter is provided for # the sake of completeness. class CgiAdapter include AdapterHandlerMixin def start(server) # for server in context of CGI this is start, middle and end! @application = server # expected by handle_context in adapter.rb context = Context.new(server) context.env = ENV uri = ENV['REQUEST_URI'] script_name = ENV['SCRIPT_NAME'] context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') handle_context( context ) puts "Content-type: #{context.content_type}" context.response_headers['Content-length'] = context.output_buffer.length context.response_headers.each { |k,v| puts "#{k}: #{v}" } puts "\n" puts context.output_buffer end end end > > Arne Brasseur wrote: >> This seems the way to go, but unfortunately mod_proxy is not an >> option for me. I'm on shared hosting with little chance of changing >> apache's configuration, except by .htaccess files. It seems both cgi >> and fcgi adapters are simply broken because of changes to the adapter >> interface. E.g. what used to be class methods are now instance >> methods, but that's not all. >> >> Would it be hard to fix them? Or just one of them? I'm not too >> concerned about performance at this point, if it runs I'd be happy. >> If they're not being fixed please add a big BROKEN sign or remove >> them altogether. >> >> Thank you (once again)! >> >> (ab) > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071018/fff4ffaa/attachment.vcf From arne at arnebrasseur.net Fri Oct 19 01:03:41 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 19 Oct 2007 13:03:41 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: <471829B1.5080708@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> Message-ID: <47183AAD.2040303@arnebrasseur.net> Patience, I'm almost done with this. (ab) Robert Mela schreef: > Here's an initial cracking of the nut. Needs much refinement. > > I have no idea whether this handles posts or not -- my hope is all the > gnarly details are now handled by handle_context in adapter.rb. > > If the approach is acceptable then there's probably a lengthy method > in raw/cgi.rb that can be removed. > > > require "raw/adapter" > > # No multi-threading. > Og.thread_safe = false if defined?(Og) and Og.respond_to?(:thread_safe) > > module Raw > > # A plain CGI adapter. To be used only in development > # environments, this adapter is *extremely* slow for > # live/production environments. This adapter is provided for > # the sake of completeness. > > class CgiAdapter > include AdapterHandlerMixin > > def start(server) # for server in context of CGI this is start, > middle and end! > @application = server # expected by handle_context in adapter.rb > context = Context.new(server) > context.env = ENV > uri = ENV['REQUEST_URI'] > script_name = ENV['SCRIPT_NAME'] > context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') > handle_context( context ) > puts "Content-type: #{context.content_type}" > context.response_headers['Content-length'] = > context.output_buffer.length > context.response_headers.each { |k,v| puts "#{k}: #{v}" } > puts "\n" > puts context.output_buffer > end > end > end > >> >> Arne Brasseur wrote: >>> This seems the way to go, but unfortunately mod_proxy is not an >>> option for me. I'm on shared hosting with little chance of changing >>> apache's configuration, except by .htaccess files. It seems both cgi >>> and fcgi adapters are simply broken because of changes to the >>> adapter interface. E.g. what used to be class methods are now >>> instance methods, but that's not all. >>> >>> Would it be hard to fix them? Or just one of them? I'm not too >>> concerned about performance at this point, if it runs I'd be happy. >>> If they're not being fixed please add a big BROKEN sign or remove >>> them altogether. >>> >>> Thank you (once again)! >>> >>> (ab) >> >> _______________________________________________ >> 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 -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net From arne at arnebrasseur.net Fri Oct 19 05:03:50 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 19 Oct 2007 17:03:50 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: <47183AAD.2040303@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> Message-ID: <471872F6.6090303@arnebrasseur.net> Ok, this should fix FastCGI (and also CGI). Cgi.process has been factored out into a seperate handler class and adapted to the way things currently work. I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on OxyWTF on how to configure Lighttpd for FastCGI. (ab) Arne Brasseur schreef: > Patience, I'm almost done with this. > > (ab) > > Robert Mela schreef: > >> Here's an initial cracking of the nut. Needs much refinement. >> >> I have no idea whether this handles posts or not -- my hope is all the >> gnarly details are now handled by handle_context in adapter.rb. >> >> If the approach is acceptable then there's probably a lengthy method >> in raw/cgi.rb that can be removed. >> >> >> require "raw/adapter" >> >> # No multi-threading. >> Og.thread_safe = false if defined?(Og) and Og.respond_to?(:thread_safe) >> >> module Raw >> >> # A plain CGI adapter. To be used only in development >> # environments, this adapter is *extremely* slow for >> # live/production environments. This adapter is provided for >> # the sake of completeness. >> >> class CgiAdapter >> include AdapterHandlerMixin >> >> def start(server) # for server in context of CGI this is start, >> middle and end! >> @application = server # expected by handle_context in adapter.rb >> context = Context.new(server) >> context.env = ENV >> uri = ENV['REQUEST_URI'] >> script_name = ENV['SCRIPT_NAME'] >> context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') >> handle_context( context ) >> puts "Content-type: #{context.content_type}" >> context.response_headers['Content-length'] = >> context.output_buffer.length >> context.response_headers.each { |k,v| puts "#{k}: #{v}" } >> puts "\n" >> puts context.output_buffer >> end >> end >> end >> >> >>> Arne Brasseur wrote: >>> >>>> This seems the way to go, but unfortunately mod_proxy is not an >>>> option for me. I'm on shared hosting with little chance of changing >>>> apache's configuration, except by .htaccess files. It seems both cgi >>>> and fcgi adapters are simply broken because of changes to the >>>> adapter interface. E.g. what used to be class methods are now >>>> instance methods, but that's not all. >>>> >>>> Would it be hard to fix them? Or just one of them? I'm not too >>>> concerned about performance at this point, if it runs I'd be happy. >>>> If they're not being fixed please add a big BROKEN sign or remove >>>> them altogether. >>>> >>>> Thank you (once again)! >>>> >>>> (ab) >>>> >>> _______________________________________________ >>> 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 >> > > > -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071019/4d6e1b85/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20071019.patch Type: text/x-patch Size: 73601 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/4d6e1b85/attachment-0001.bin From george.moschovitis at gmail.com Fri Oct 19 05:09:47 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 19 Oct 2007 12:09:47 +0300 Subject: [Nitro] Nitro on Apache In-Reply-To: <471872F6.6090303@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> Message-ID: Are you sure this doesn't break mongrel? Have you tested it? thanks, -g. On 10/19/07, Arne Brasseur wrote: > > Ok, this should fix FastCGI (and also CGI). > > Cgi.process has been factored out into a seperate handler class and > adapted to the way things currently work. > > I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on OxyWTF > on how to configure Lighttpd for FastCGI. > > (ab) > > Arne Brasseur schreef: > > Patience, I'm almost done with this. > > (ab) > > Robert Mela schreef: > > Here's an initial cracking of the nut. Needs much refinement. > > I have no idea whether this handles posts or not -- my hope is all the > gnarly details are now handled by handle_context in adapter.rb. > > If the approach is acceptable then there's probably a lengthy method > in raw/cgi.rb that can be removed. > > > require "raw/adapter" > > # No multi-threading. > Og.thread_safe = false if defined?(Og) and Og.respond_to?(:thread_safe) > > module Raw > > # A plain CGI adapter. To be used only in development > # environments, this adapter is *extremely* slow for > # live/production environments. This adapter is provided for > # the sake of completeness. > > class CgiAdapter > include AdapterHandlerMixin > > def start(server) # for server in context of CGI this is start, > middle and end! > @application = server # expected by handle_context in adapter.rb > context = Context.new(server) > context.env = ENV > uri = ENV['REQUEST_URI'] > script_name = ENV['SCRIPT_NAME'] > context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') > handle_context( context ) > puts "Content-type: #{context.content_type}" > context.response_headers['Content-length'] = > context.output_buffer.length > context.response_headers.each { |k,v| puts "#{k}: #{v}" } > puts "\n" > puts context.output_buffer > end > end > end > > Arne Brasseur wrote: > > This seems the way to go, but unfortunately mod_proxy is not an > option for me. I'm on shared hosting with little chance of changing > apache's configuration, except by .htaccess files. It seems both cgi > and fcgi adapters are simply broken because of changes to the > adapter interface. E.g. what used to be class methods are now > instance methods, but that's not all. > > Would it be hard to fix them? Or just one of them? I'm not too > concerned about performance at this point, if it runs I'd be happy. > If they're not being fixed please add a big BROKEN sign or remove > them altogether. > > Thank you (once again)! > > (ab) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.nethttp://www.zhongwiki.comhttp://www.bankske.orgarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071019/09a2231f/attachment.html From arne at arnebrasseur.net Fri Oct 19 05:38:01 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 19 Oct 2007 17:38:01 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> Message-ID: <47187AF9.1060208@arnebrasseur.net> I just tried Mongrel, still works fine. I see no reason why it should be affected. (ab) George Moschovitis schreef: > Are you sure this doesn't break mongrel? Have you tested it? > > thanks, > -g. > > > > On 10/19/07, *Arne Brasseur* < arne at arnebrasseur.net > > wrote: > > Ok, this should fix FastCGI (and also CGI). > > Cgi.process has been factored out into a seperate handler class > and adapted to the way things currently work. > > I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on > OxyWTF on how to configure Lighttpd for FastCGI. > > (ab) > > Arne Brasseur schreef: >> Patience, I'm almost done with this. >> >> (ab) >> >> Robert Mela schreef: >> >>> Here's an initial cracking of the nut. Needs much refinement. >>> >>> I have no idea whether this handles posts or not -- my hope is all the >>> gnarly details are now handled by handle_context in adapter.rb >>> . >>> >>> If the approach is acceptable then there's probably a lengthy method >>> in raw/cgi.rb that can be removed. >>> >>> >>> require "raw/adapter" >>> >>> # No multi-threading. >>> Og.thread_safe = false if defined?(Og) and >>> Og.respond_to?(:thread_safe) >>> >>> module Raw >>> >>> # A plain CGI adapter. To be used only in development >>> # environments, this adapter is *extremely* slow for >>> # live/production environments. This adapter is provided for >>> >>> # the sake of completeness. >>> >>> class CgiAdapter >>> include AdapterHandlerMixin >>> >>> def start(server) # for server in context of CGI this is start, >>> middle and end! >>> @application = server # expected by handle_context in >>> adapter.rb >>> context = Context.new(server) >>> context.env = ENV >>> uri = ENV['REQUEST_URI'] >>> script_name = ENV['SCRIPT_NAME'] >>> context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') >>> >>> handle_context( context ) >>> puts "Content-type: #{context.content_type}" >>> context.response_headers['Content-length'] = >>> context.output_buffer.length >>> context.response_headers.each >>> { |k,v| puts "#{k}: #{v}" } >>> puts "\n" >>> puts context.output_buffer >>> end >>> end >>> end >>> >>> >>>> Arne Brasseur wrote: >>>> >>>>> This seems the way to go, but unfortunately mod_proxy is not an >>>>> option for me. I'm on shared hosting with little chance of changing >>>>> apache's configuration, except by .htaccess files. It seems both cgi >>>>> >>>>> and fcgi adapters are simply broken because of changes to the >>>>> adapter interface. E.g. what used to be class methods are now >>>>> instance methods, but that's not all. >>>>> >>>>> Would it be hard to fix them? Or just one of them? I'm not too >>>>> >>>>> concerned about performance at this point, if it runs I'd be happy. >>>>> If they're not being fixed please add a big BROKEN sign or remove >>>>> them altogether. >>>>> >>>>> Thank you (once again)! >>>>> >>>>> (ab) >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >> > > > -- > Arne Brasseur > http://www.arnebrasseur.net > http://www.zhongwiki.com > http://www.bankske.org > arne at arnebrasseur.net > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://gmosx.me.gr > http://phidz.com > 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 -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071019/8315d5e9/attachment.html From rob at robmela.com Fri Oct 19 10:30:54 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 19 Oct 2007 10:30:54 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: <4718B56A.1060607@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <47181F1D.4060207@arnebrasseur.net> <4718A6A3.4060904@robmela.com> <4718B56A.1060607@arnebrasseur.net> Message-ID: <4718BF9E.3000307@robmela.com> Arne Brasseur wrote: > Well FastCGI should be good, but actually using CGI with Nitro isn't > that easy. Nitro assumes that it handles the complete document-root, > while CGI scripts normally just handle a single URL. It takes some > clever server configuration to make this work the way it should. I > tried with Lighttpd, aliasing "/" to the nitro app script. This works > for the root, but not for other URL's. I suppose with apache and > mod_rewrite it should be possible. > I find the routing works fine if you use this the cgi adapter before handing the work off to AdapterHandlerMixin#handle_context: uri = ENV['REQUEST_URI'] script_name = ENV['SCRIPT_NAME'] context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') Somewhere inside @application.dispatcher.dispatch_context(context) -- called from handle_context -- everything is magically generated from REQUEST_URI. Question for George: It looks to me like Cgi::Http::process in the current CgiAdapter could be replaced by a little setup, leaving the heaving lifting to AdapterHandlerMixin#handle_context. I suspect that handle_context is likely to be better maintained, since it's what MongrelAdapter uses. This CGI adapter thing seems a little thing, but who knows -- it might hook that one 14-year old developer in Mozambique who only has CGI via a friend's account, and latches on to Nitro because it works with CGI... then later turns into a super coder.... > With FastCGI the configuration is different, there it's quite easy to > set things up. >> As for Dreamhost -- >> >> Which fcgi watchdog are you using? Or is it their determination? If >> so, do you know which one it is? IIRC, there's a mode wherein >> mod_fastcgi will do the process management/watchdog work internally, >> within the Apache process. If they've got full control over that >> configuration you're out of luck. Otherwise, it's worth >> experimenting -- given the financial constraints -- to see whether >> you place and name your fastcgi process in a way that it's handled by >> mod_fastcgi's internal process manager. > I don't have much to decide about this, and there's not much > information available on the exact workings of their watchdogs. > Apparently processes get killed when they take up too much memory, or > they run too long. So people have come up with solutions like stopping > all fastcgi processes in a cron job or running the garbage collector > after every few pages. One guy I just discovered made an alternate > rails FastCGI handler that captures SIGTERM and finishes rendering the > current page before exiting. This way the watchdogs do no real harm. > He's also on Dreamhost :). This would be very useful to me and > probably others as well, so I'll look at it again and try to > incorporate this in our FastCGI adapter. > > I didn't know much about all this adapter business and this has been > very educational. I figured since nobody seemed to really care here > about (F)CGI I could just go ahead and see what gives. > > I tested with Lighttpd and will do some more testing with Apache. > Reports on using this both positive and negative are very appreciated. > > (ab) >> >> >> Arne Brasseur wrote: >>> They run on debian. I don't have access to the main apache config. I >>> can only use a web panel to select a directory as document root, the >>> version of PHP and if I want to enable FastCGI on that domain. >>> That's it. The rest has to be done with .htaccess files. >>> >>> They make a big thing out of supporting Ruby/Rails, but in the end >>> the support totally sucks. They have a watchdog process that >>> seemingly randomly kills user processes, so every few pages you get >>> a "server 500" because the fcgi process got killed. >>> >>> But they're cheap and I payed two years in advance so I'll have to >>> live with it a little longer. It's Dreamhost BTW, don't go there if >>> you're serious about using Ruby stuff. >>> >>> I've been looking at it the last few days and have more or less >>> functioning CGI/FastCGI adapters. They need more testing. After that >>> I'll send a patch and write something on oxywtf about deploying with >>> fcgi. >>> >>> Thanks for responding! >>> >>> (ab) >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/8dcea953/attachment-0001.vcf From rob at robmela.com Fri Oct 19 10:45:42 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 19 Oct 2007 10:45:42 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> Message-ID: <4718C316.6080506@robmela.com> Mongrel uses AdapterHandlerMixin#handle_context, not Cgi.process... so it should be safe. It is possible to rip Cgi.process out of CgiAdapter and replace it with the same handle_context that MongrelAdapter uses. It may even then be possible to remove Cgi.process altogether -- need to grep to see where else it's used. George Moschovitis wrote: > Are you sure this doesn't break mongrel? Have you tested it? > > thanks, > -g. > > > > On 10/19/07, *Arne Brasseur* < arne at arnebrasseur.net > > wrote: > > Ok, this should fix FastCGI (and also CGI). > > Cgi.process has been factored out into a seperate handler class > and adapted to the way things currently work. > > I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on > OxyWTF on how to configure Lighttpd for FastCGI. > > (ab) > > Arne Brasseur schreef: >> Patience, I'm almost done with this. >> >> (ab) >> >> Robert Mela schreef: >> >>> Here's an initial cracking of the nut. Needs much refinement. >>> >>> I have no idea whether this handles posts or not -- my hope is all the >>> gnarly details are now handled by handle_context in adapter.rb >>> . >>> >>> If the approach is acceptable then there's probably a lengthy method >>> in raw/cgi.rb that can be removed. >>> >>> >>> require "raw/adapter" >>> >>> # No multi-threading. >>> Og.thread_safe = false if defined?(Og) and >>> Og.respond_to?(:thread_safe) >>> >>> module Raw >>> >>> # A plain CGI adapter. To be used only in development >>> # environments, this adapter is *extremely* slow for >>> # live/production environments. This adapter is provided for >>> >>> # the sake of completeness. >>> >>> class CgiAdapter >>> include AdapterHandlerMixin >>> >>> def start(server) # for server in context of CGI this is start, >>> middle and end! >>> @application = server # expected by handle_context in >>> adapter.rb >>> context = Context.new(server) >>> context.env = ENV >>> uri = ENV['REQUEST_URI'] >>> script_name = ENV['SCRIPT_NAME'] >>> context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') >>> >>> handle_context( context ) >>> puts "Content-type: #{context.content_type}" >>> context.response_headers['Content-length'] = >>> context.output_buffer.length >>> context.response_headers.each >>> { |k,v| puts "#{k}: #{v}" } >>> puts "\n" >>> puts context.output_buffer >>> end >>> end >>> end >>> >>> >>>> Arne Brasseur wrote: >>>> >>>>> This seems the way to go, but unfortunately mod_proxy is not an >>>>> option for me. I'm on shared hosting with little chance of changing >>>>> apache's configuration, except by .htaccess files. It seems both cgi >>>>> >>>>> and fcgi adapters are simply broken because of changes to the >>>>> adapter interface. E.g. what used to be class methods are now >>>>> instance methods, but that's not all. >>>>> >>>>> Would it be hard to fix them? Or just one of them? I'm not too >>>>> >>>>> concerned about performance at this point, if it runs I'd be happy. >>>>> If they're not being fixed please add a big BROKEN sign or remove >>>>> them altogether. >>>>> >>>>> Thank you (once again)! >>>>> >>>>> (ab) >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >> > > > -- > Arne Brasseur > http://www.arnebrasseur.net > http://www.zhongwiki.com > http://www.bankske.org > arne at arnebrasseur.net > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://gmosx.me.gr > http://phidz.com > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/e4e2b29d/attachment.vcf From rob at robmela.com Fri Oct 19 10:48:54 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 19 Oct 2007 10:48:54 -0400 Subject: [Nitro] Nitro on Apache In-Reply-To: <47187AF9.1060208@arnebrasseur.net> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> <47187AF9.1060208@arnebrasseur.net> Message-ID: <4718C3D6.2010305@robmela.com> Path translations behind the URL generating helpers may be the thing that breaks my idea of replacing Cgi.process with AdapterHandlerMixin#handle_context I also would need to see whether simply assigning context.in = STDIN is sufficient for handling POST and other methods with request bodies. Seems Cgi.process might be doing a bit more work there... Arne Brasseur wrote: > I just tried Mongrel, still works fine. I see no reason why it should > be affected. > > (ab) > > George Moschovitis schreef: >> Are you sure this doesn't break mongrel? Have you tested it? >> >> thanks, >> -g. >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/00eeb4db/attachment.vcf From rob at robmela.com Fri Oct 19 11:00:17 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 19 Oct 2007 11:00:17 -0400 Subject: [Nitro] Arne's CgiAdapter In-Reply-To: <4718C3D6.2010305@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> <47187AF9.1060208@arnebrasseur.net> <4718C3D6.2010305@robmela.com> Message-ID: <4718C681.4050107@robmela.com> Arne's adapter uses the AdapterHandlerMixin and handle_context -- it's far more complete and polished than the partial hack I posted. Also removes Cgi.process from cgi.rb as I thought might be desirable -- again, MongrelAdapter uses AdapterHandlerMixin#handle_context and should be unaffected. Yeah Arne! I think I'll give it a spin. Only open question so far is how well path handling works with the router? Robert Mela wrote: > Path translations behind the URL generating helpers may be the thing > that breaks my idea of replacing Cgi.process with > AdapterHandlerMixin#handle_context > > I also would need to see whether simply assigning context.in = STDIN > is sufficient for handling POST and other methods with request > bodies. Seems Cgi.process might be doing a bit more work there... > > Arne Brasseur wrote: >> I just tried Mongrel, still works fine. I see no reason why it should >> be affected. >> >> (ab) >> >> George Moschovitis schreef: >>> Are you sure this doesn't break mongrel? Have you tested it? >>> >>> thanks, >>> -g. >>> >>> > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071019/ef3ee90c/attachment.vcf From mvyver at gmail.com Fri Oct 19 19:55:43 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 20 Oct 2007 09:55:43 +1000 Subject: [Nitro] [OG] Fwd: NetBeans db tooling: Tell us what you want In-Reply-To: <56a83cd00710191259l46650e9au7204716e0ad1fd9b@mail.gmail.com> References: <56a83cd00710191259l46650e9au7204716e0ad1fd9b@mail.gmail.com> Message-ID: <389c43e40710191655y7ac15cb6tedebc753130cc281@mail.gmail.com> Hi All, I thought some on this list might be interested in the following survey. Apologies for the noise to those not using netbeans. Cheers Mark ---------- Forwarded message ---------- From: David Van Couvering Date: Oct 20, 2007 5:59 AM Subject: NetBeans db tooling: Tell us what you want To: dev at ruby.netbeans.org, users at ruby.netbeans.org Hi, all. I'm the architect for database tooling in NetBeans. I'm *not* a Ruby developer (I know, I know, what's wrong with me :)), and I need your guidance as to what tooling, if any, you need for databases as a Ruby developer. I know ActiveRecord and migrations take care of a lot of things, but maybe there are still some things you need. Sometimes you still do need to drop into SQL, and maybe you need to know what SQL is actually being sent to the database, things like that. I have put together a *very* short survey (it should take you no more than ten minutes) for specific features I am not sure of. I think some of these you would rate as "not important" but perhaps there are some you think *are* important, and I'd like to know what those are. There is also a space for you to provide your own comments on what you think is missing. Please take a look at http://FreeOnlineSurveys.com/rendersurvey.asp?sid=jbk4vr915xv9qr0350286 Your help is *much* appreciated! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe at ruby.netbeans.org For additional commands, e-mail: dev-help at ruby.netbeans.org From george.moschovitis at gmail.com Sat Oct 20 04:57:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 20 Oct 2007 11:57:28 +0300 Subject: [Nitro] ATOM serializer Message-ID: Dear devs, I am trying to make the atom serializer in raw/util/atom.rb work. I create a new simpler (and faster) version. This seems to work with Google reader but It does not show any kind of summary in Firefox (when viewing the feed). Here is an example: http://me.gr/blog/index.atom Can anyone on this list spot the problem(s) with this feed? Please help me debug this once and for all. thanks, George. -- http://gmosx.me.gr http://phidz.com 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/20071020/61ed44f1/attachment.html From arne at arnebrasseur.net Sat Oct 20 05:21:24 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 20 Oct 2007 17:21:24 +0800 Subject: [Nitro] Nitro on Apache In-Reply-To: <4718C316.6080506@robmela.com> References: <4703907A.8090503@arnebrasseur.net> <470504E1.90206@arnebrasseur.net> <471803B8.7040007@robmela.com> <471829B1.5080708@robmela.com> <47183AAD.2040303@arnebrasseur.net> <471872F6.6090303@arnebrasseur.net> <4718C316.6080506@robmela.com> Message-ID: <4719C894.4000000@arnebrasseur.net> Robert Mela schreef: > Mongrel uses AdapterHandlerMixin#handle_context, not Cgi.process... so > it should be safe. > > It is possible to rip Cgi.process out of CgiAdapter and replace it > with the same handle_context that MongrelAdapter uses. It may even > then be possible to remove Cgi.process altogether -- need to grep to > see where else it's used. I did grep and as far as I can tell only the old CGI and FastCGI adapters used it. That's why it's removed in my patch and replaced by CgiAdapter#process. It's a bit of a blend between the Mongrel handler and the original Cgi.process :) As for the URI handling, I did experiment a bit with stripping the SCRIPT_NAME in the CGI adapter and redefining EncodeURI#encode_uri to add it again. This should work. I left it out because it still had some edge cases that didn't behave right. Maybe it could be added again. Either way some documentation on how to set up your server so this isn't necessary, or how to adapt Nitro if it is necessary would be good. (ab) > > George Moschovitis wrote: >> Are you sure this doesn't break mongrel? Have you tested it? >> >> thanks, >> -g. >> >> >> >> On 10/19/07, *Arne Brasseur* < arne at arnebrasseur.net >> > wrote: >> >> Ok, this should fix FastCGI (and also CGI). >> >> Cgi.process has been factored out into a seperate handler class >> and adapted to the way things currently work. >> >> I've tested both CGI and FastCGI with Lighttpd and wrote a Tip on >> OxyWTF on how to configure Lighttpd for FastCGI. >> >> (ab) >> >> Arne Brasseur schreef: >>> Patience, I'm almost done with this. >>> >>> (ab) >>> >>> Robert Mela schreef: >>> >>>> Here's an initial cracking of the nut. Needs much refinement. >>>> >>>> I have no idea whether this handles posts or not -- my hope is >>>> all the gnarly details are now handled by handle_context in >>>> adapter.rb >>>> . >>>> >>>> If the approach is acceptable then there's probably a lengthy >>>> method in raw/cgi.rb that can be removed. >>>> >>>> >>>> require "raw/adapter" >>>> >>>> # No multi-threading. >>>> Og.thread_safe = false if defined?(Og) and >>>> Og.respond_to?(:thread_safe) >>>> >>>> module Raw >>>> >>>> # A plain CGI adapter. To be used only in development >>>> # environments, this adapter is *extremely* slow for >>>> # live/production environments. This adapter is provided for >>>> >>>> # the sake of completeness. >>>> >>>> class CgiAdapter >>>> include AdapterHandlerMixin >>>> def start(server) # for server in context of CGI >>>> this is start, middle and end! >>>> @application = server # expected by handle_context in >>>> adapter.rb >>>> context = Context.new(server) >>>> context.env = ENV >>>> uri = ENV['REQUEST_URI'] >>>> script_name = ENV['SCRIPT_NAME'] >>>> context.env['REQUEST_URI'] = uri.sub(/#{script_name}/i, '') >>>> >>>> handle_context( context ) >>>> puts "Content-type: #{context.content_type}" >>>> context.response_headers['Content-length'] = >>>> context.output_buffer.length >>>> context.response_headers.each >>>> { |k,v| puts "#{k}: #{v}" } >>>> puts "\n" >>>> puts context.output_buffer >>>> end >>>> end >>>> end >>>> >>>> >>>>> Arne Brasseur wrote: >>>>> >>>>>> This seems the way to go, but unfortunately mod_proxy is not >>>>>> an option for me. I'm on shared hosting with little chance of >>>>>> changing apache's configuration, except by .htaccess files. >>>>>> It seems both cgi >>>>>> and fcgi adapters are simply broken because of changes to the >>>>>> adapter interface. E.g. what used to be class methods are now >>>>>> instance methods, but that's not all. >>>>>> >>>>>> Would it be hard to fix them? Or just one of them? I'm not too >>>>>> concerned about performance at this point, if it runs I'd be >>>>>> happy. If they're not being fixed please add a big BROKEN >>>>>> sign or remove them altogether. >>>>>> >>>>>> Thank you (once again)! >>>>>> >>>>>> (ab) >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> >> -- Arne Brasseur >> http://www.arnebrasseur.net >> http://www.zhongwiki.com >> http://www.bankske.org >> arne at arnebrasseur.net >> >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> >> >> -- >> http://gmosx.me.gr >> http://phidz.com >> http://blog.gmosx.com >> http://cull.gr >> http://www.joy.gr >> http://nitroproject.org >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net From arne at arnebrasseur.net Sat Oct 20 05:38:28 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 20 Oct 2007 17:38:28 +0800 Subject: [Nitro] ATOM serializer In-Reply-To: References: Message-ID: <4719CC94.40208@arnebrasseur.net> Try the W3C validator: http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fwww.me.gr%2Fblog%2Findex.atom It reports a few issues that you might want to solve before doing more testing. (ab) George Moschovitis schreef: > Dear devs, > > I am trying to make the atom serializer in raw/util/atom.rb work. > I create a new simpler (and faster) version. This seems to work with > Google reader but It does not show any kind of summary > in Firefox (when viewing the feed). > > Here is an example: > > http://me.gr/blog/index.atom > > Can anyone on this list spot the problem(s) with this feed? > > Please help me debug this once and for all. > > thanks, > George. > > > > -- > http://gmosx.me.gr > http://phidz.com > 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 -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071020/0c8ffefe/attachment-0001.html From arne at arnebrasseur.net Sun Oct 21 09:51:52 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 21 Oct 2007 21:51:52 +0800 Subject: [Nitro] [PATCH] ATOM serializer In-Reply-To: <4719CC94.40208@arnebrasseur.net> References: <4719CC94.40208@arnebrasseur.net> Message-ID: <471B5978.3080803@arnebrasseur.net> Hi, This patch doesn't fix much but does two useful things: - issue a warning if there is no model annotation on the controller - check if the serialized object respond_to?(:author) before calling #author From looking at http://www.atomenabled.org/developers/syndication/ and at the W3C validator it seems the biggest issues are: - id's should be complete IRI's (a superset of URI's). Relative URL's are not valid. - the updated (timestamp) element is mandatory, both on the feed as on the entries For the second thing I would assume this could be done to play nicely with 'is Timestamped' ? As it stands this nice functionality is still undocumented, but for the adventurous this might help you get started: class RandomController ann :self, :model => RandomThing def index @random_things = RandomThing.all end end class RandomThing attr :title, String attr :author, String def body "you need this method" end end app.dispatcher.root.random = RandomController go to http://localhost:9000/random.atom Have fun! (ab) Arne Brasseur schreef: > Try the W3C validator: > http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fwww.me.gr%2Fblog%2Findex.atom > > It reports a few issues that you might want to solve before doing more > testing. > > (ab) > > George Moschovitis schreef: >> Dear devs, >> >> I am trying to make the atom serializer in raw/util/atom.rb work. >> I create a new simpler (and faster) version. This seems to work with >> Google reader but It does not show any kind of summary >> in Firefox (when viewing the feed). >> >> Here is an example: >> >> http://me.gr/blog/index.atom >> >> Can anyone on this list spot the problem(s) with this feed? >> >> Please help me debug this once and for all. >> >> thanks, >> George. >> >> >> >> -- >> http://gmosx.me.gr >> http://phidz.com >> 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 > > > -- > Arne Brasseur > http://www.arnebrasseur.net > http://www.zhongwiki.com > http://www.bankske.org > arne at arnebrasseur.net > > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071021/b1fad854/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20071021.patch Type: text/x-patch Size: 69571 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071021/b1fad854/attachment-0001.bin From george.moschovitis at gmail.com Sun Oct 21 16:24:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 21 Oct 2007 23:24:01 +0300 Subject: [Nitro] [PATCH] ATOM serializer In-Reply-To: <471B5978.3080803@arnebrasseur.net> References: <4719CC94.40208@arnebrasseur.net> <471B5978.3080803@arnebrasseur.net> Message-ID: Thanks for the patch. I will work on this further. -g. On 10/21/07, Arne Brasseur wrote: > > Hi, > > This patch doesn't fix much but does two useful things: > - issue a warning if there is no model annotation on the controller > - check if the serialized object respond_to?(:author) before calling > #author > > >From looking at http://www.atomenabled.org/developers/syndication/ and at > the W3C validator it seems the biggest issues are: > - id's should be complete IRI's (a superset of URI's). Relative URL's are > not valid. > - the updated (timestamp) element is mandatory, both on the feed as on the > entries > > For the second thing I would assume this could be done to play nicely with > 'is Timestamped' ? > > As it stands this nice functionality is still undocumented, but for the > adventurous this might help you get started: > > class RandomController > ann :self, :model => RandomThing > > def index > @random_things = RandomThing.all > end > end > > class RandomThing > attr :title, String > attr :author, String > > def body > "you need this method" > end > end > > app.dispatcher.root.random = RandomController > > go to http://localhost:9000/random.atom > > Have fun! > > (ab) > > Arne Brasseur schreef: > > Try the W3C validator: > http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fwww.me.gr%2Fblog%2Findex.atom > > It reports a few issues that you might want to solve before doing more > testing. > > (ab) > > George Moschovitis schreef: > > Dear devs, > > I am trying to make the atom serializer in raw/util/atom.rb work. > I create a new simpler (and faster) version. This seems to work with > Google reader but It does not show any kind of summary > in Firefox (when viewing the feed). > > Here is an example: > > http://me.gr/blog/index.atom > > Can anyone on this list spot the problem(s) with this feed? > > Please help me debug this once and for all. > > thanks, > George. > > > > -- > http://gmosx.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.nethttp://www.zhongwiki.comhttp://www.bankske.orgarne at arnebrasseur.net > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.nethttp://www.zhongwiki.comhttp://www.bankske.orgarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://gmosx.me.gr http://phidz.com 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/20071021/dd8cbdaf/attachment.html From james.britt at gmail.com Mon Oct 22 01:18:46 2007 From: james.britt at gmail.com (James Britt) Date: Sun, 21 Oct 2007 22:18:46 -0700 Subject: [Nitro] [OG] Fwd: NetBeans db tooling: Tell us what you want In-Reply-To: <389c43e40710191655y7ac15cb6tedebc753130cc281@mail.gmail.com> References: <56a83cd00710191259l46650e9au7204716e0ad1fd9b@mail.gmail.com> <389c43e40710191655y7ac15cb6tedebc753130cc281@mail.gmail.com> Message-ID: <471C32B6.3080305@gmail.com> Mark Van De Vyver wrote: > Hi All, > I thought some on this list might be interested in the following survey. > Apologies for the noise to those not using netbeans. It may be worthwhile for folks on this list to contact the survey owner and let him know that question #1 shows a profound ignorance. Tell him that many people develop in a language called "Ruby", and that it should be among the options for that question. -- James Britt "I never dispute another person's delusions, just their facts." - Len Bullard From arne at arnebrasseur.net Mon Oct 22 01:52:00 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 22 Oct 2007 13:52:00 +0800 Subject: [Nitro] [OG] Fwd: NetBeans db tooling: Tell us what you want In-Reply-To: <471C32B6.3080305@gmail.com> References: <56a83cd00710191259l46650e9au7204716e0ad1fd9b@mail.gmail.com> <389c43e40710191655y7ac15cb6tedebc753130cc281@mail.gmail.com> <471C32B6.3080305@gmail.com> Message-ID: <471C3A80.3070002@arnebrasseur.net> Done :) James Britt schreef: > Mark Van De Vyver wrote: > >> Hi All, >> I thought some on this list might be interested in the following survey. >> Apologies for the noise to those not using netbeans. >> > > It may be worthwhile for folks on this list to contact the survey owner > and let him know that question #1 shows a profound ignorance. > > Tell him that many people develop in a language called "Ruby", and that > it should be among the options for that question. > -- Arne Brasseur http://www.arnebrasseur.net http://www.zhongwiki.com http://www.bankske.org arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071022/d86a36a7/attachment.html From rob at robmela.com Tue Oct 23 17:15:21 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 23 Oct 2007 17:15:21 -0400 Subject: [Nitro] OgAdminController#save still broken Message-ID: <471E6469.3040203@robmela.com> request['foovar'] works fine normally ( see illustration code ) but blows up inside OgAdminController#save (again, just run the attached sample code ) Run using a fresh darcs get. Am I the only one seeing these problems with OgAdminController#save? Is nobody using the admin part? Is it somehow related to using WEBrick or SQLite? With each new darcs get I put my own workaround into OgAdminController -- replacing request[] with post_params[], after which everything works fine. ERROR: Error while handling OgAdminController#save() ERROR: undefined method `[]' for nil:NilClass /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in `[]' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:93:in `save' (eval):4:in `call' (eval):4:in `save' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in `send' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in `save___super' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in `send' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in `method_missing' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in `send' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in `render_action' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in `send' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in `handle_context' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:134:in `do_POST' /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__' /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' /opt/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /opt/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /opt/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /opt/local/lib/ruby/1.8/webrick/server.rb:95:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `each' /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:23:in `start' /opt/local/lib/ruby/1.8/webrick/server.rb:82:in `start' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:57:in `start' /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:135:in `start' ./app.rb:34 LOGGED FROM: /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:108:in `render_action' #!/usr/bin/env ruby require 'nitro_and_og' include Nitro require 'nitro/part/admin' class Book attr_accessor :title, String many_to_many Author end class Author attr_accessor :name, String has_many Book end Og.start( :adapter => :sqlite, :database => 'library', :create_schema => true, :destroy_schema => true ) class MyController def index render_text "admin
Sample Form" end def sampleform render_text "
" end def samplepost render_text "You entered '#{request['foo']}' in the text field" end end app = Application.new disp=app.dispatcher disp.root = MyController app.start -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071023/90b6741c/attachment.vcf From prpht9 at gmail.com Tue Oct 23 23:51:53 2007 From: prpht9 at gmail.com (chris) Date: Tue, 23 Oct 2007 23:51:53 -0400 Subject: [Nitro] OgAdminController#save still broken In-Reply-To: <471E6469.3040203@robmela.com> References: <471E6469.3040203@robmela.com> Message-ID: I have this same issue in 0.50.0 On 10/23/07, Robert Mela wrote: > > request['foovar'] works fine normally ( see illustration code ) but > blows up inside OgAdminController#save (again, just run the attached > sample code ) > > Run using a fresh darcs get. Am I the only one seeing these problems > with OgAdminController#save? Is nobody using the admin part? Is it > somehow related to using WEBrick or SQLite? > > With each new darcs get I put my own workaround into OgAdminController > -- replacing request[] with post_params[], after which everything works > fine. > > > > ERROR: Error while handling OgAdminController#save() > ERROR: undefined method `[]' for nil:NilClass > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in > `[]' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:93:in > `save' > (eval):4:in `call' > (eval):4:in `save' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in > `send' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in > `save___super' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in > `send' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in > `method_missing' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in > `send' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in > `render_action' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in > `send' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in > `handle_context' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:134:in > `do_POST' > /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__' > /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' > /opt/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' > /opt/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' > /opt/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' > /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start' > /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' > /opt/local/lib/ruby/1.8/webrick/server.rb:95:in `start' > /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `each' > /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `start' > /opt/local/lib/ruby/1.8/webrick/server.rb:23:in `start' > /opt/local/lib/ruby/1.8/webrick/server.rb:82:in `start' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:57:in > `start' > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:135:in > `start' > ./app.rb:34 > LOGGED FROM: > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:108:in > `render_action' > > > #!/usr/bin/env ruby > > require 'nitro_and_og' > include Nitro > > require 'nitro/part/admin' > > class Book > attr_accessor :title, String > many_to_many Author > end > > class Author > attr_accessor :name, String > has_many Book > end > > Og.start( :adapter => :sqlite, :database => 'library', > :create_schema => true, :destroy_schema => true ) > > class MyController > def index > render_text "admin
href='sampleform'>Sample Form" > end > > def sampleform > render_text " > type='submit' name='ClickMe'/>" > end > > def samplepost > render_text "You entered '#{request['foo']}' in the text field" > end > > end > > app = Application.new > disp=app.dispatcher > disp.root = MyController > app.start > > > _______________________________________________ > 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/20071023/277972d7/attachment-0001.html From george.moschovitis at gmail.com Wed Oct 24 03:31:43 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 24 Oct 2007 10:31:43 +0300 Subject: [Nitro] OgAdminController#save still broken In-Reply-To: References: <471E6469.3040203@robmela.com> Message-ID: I am using a custom Admin like part, so I have not seen it. Rob, can you send me a patch for this? -g. On 10/24/07, chris wrote: > > I have this same issue in 0.50.0 > > On 10/23/07, Robert Mela wrote: > > > request['foovar'] works fine normally ( see illustration code ) but > > blows up inside OgAdminController#save (again, just run the attached > > sample code ) > > > > Run using a fresh darcs get. Am I the only one seeing these problems > > with OgAdminController#save? Is nobody using the admin part? Is it > > somehow related to using WEBrick or SQLite? > > > > With each new darcs get I put my own workaround into OgAdminController > > -- replacing request[] with post_params[], after which everything works > > fine. > > > > > > > > ERROR: Error while handling OgAdminController#save() > > ERROR: undefined method `[]' for nil:NilClass > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/context/request.rb:304:in > > > > `[]' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/part/admin/og/controller.rb:93:in > > `save' > > (eval):4:in `call' > > (eval):4:in `save' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in > > > > `send' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in > > `save___super' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in > > > > `send' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in > > `method_missing' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in > > > > `send' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:92:in > > `render_action' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in > > > > `send' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:68:in > > `handle_context' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:134:in > > > > `do_POST' > > /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in > > `__send__' > > /opt/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in > > `service' > > /opt/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' > > /opt/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' > > /opt/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' > > /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start' > > /opt/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' > > /opt/local/lib/ruby/1.8/webrick/server.rb:95:in `start' > > /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `each' > > /opt/local/lib/ruby/1.8/webrick/server.rb:92:in `start' > > /opt/local/lib/ruby/1.8/webrick/server.rb:23:in `start' > > /opt/local/lib/ruby/1.8/webrick/server.rb:82:in `start' > > > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/webrick.rb:57:in > > `start' > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:135:in > > > > `start' > > ./app.rb:34 > > LOGGED FROM: > > > > /Users/rmela/nitro/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:108:in > > `render_action' > > > > > > #!/usr/bin/env ruby > > > > require 'nitro_and_og' > > include Nitro > > > > require 'nitro/part/admin' > > > > class Book > > attr_accessor :title, String > > many_to_many Author > > end > > > > class Author > > attr_accessor :name, String > > has_many Book > > end > > > > Og.start( :adapter => :sqlite, :database => 'library', > > :create_schema => true, :destroy_schema => true ) > > > > class MyController > > def index > > render_text "admin
> href='sampleform'>Sample Form" > > end > > > > def sampleform > > render_text " > > > type='submit' name='ClickMe'/>" > > end > > > > def samplepost > > render_text "You entered '#{request['foo']}' in the text field" > > end > > > > end > > > > app = Application.new > > disp=app.dispatcher > > disp.root = MyController > > app.start > > > > > > _______________________________________________ > > 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://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071024/86778ec6/attachment.html From rob at robmela.com Wed Oct 24 22:55:59 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 24 Oct 2007 22:55:59 -0400 Subject: [Nitro] OgAdminController#save still broken In-Reply-To: References: <471E6469.3040203@robmela.com> Message-ID: <472005BF.3000206@robmela.com> Could I try the custom admin part? I'm wondering why that would behave differently. What's attached is a workaround -- calling request.post_params['oid'] instead of request['oid']. What should really be fixed -- which will take a while to get to -- is whatever's causing the request['oid'] to fail in OgAdminController despite working elsewhere. Looks a bit like an order of initialization thing, or a clash between two definitions. I forget whether you need tar.gz or gz so here's both. George Moschovitis wrote: > I am using a custom Admin like part, so I have not seen it. > Rob, can you send me a patch for this? > > -g. -------------- next part -------------- A non-text attachment was scrubbed... Name: og_admin_controller_fix.tar.gz Type: application/x-gzip Size: 19503 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071024/72e3fdce/attachment-0002.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: og_admin_controller_fix.gz Type: application/x-gzip Size: 19343 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071024/72e3fdce/attachment-0003.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071024/72e3fdce/attachment-0001.vcf From george.moschovitis at gmail.com Thu Oct 25 03:32:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 25 Oct 2007 10:32:26 +0300 Subject: [Nitro] OgAdminController#save still broken In-Reply-To: <472005BF.3000206@robmela.com> References: <471E6469.3040203@robmela.com> <472005BF.3000206@robmela.com> Message-ID: > > Could I try the custom admin part? I'm wondering why that would behave > differently. by custom I mean totally recoded ;-) When it is ready for public consumption I will release it as an alternative to the AdminPart. -g. PS: thanks for the patch. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071025/5ef0b25b/attachment.html From rob at robmela.com Thu Oct 25 14:02:43 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 25 Oct 2007 14:02:43 -0400 Subject: [Nitro] cgi adapter and trivial patch Message-ID: <4720DA43.3050402@robmela.com> Yesterday I observed a senior architect -- an amazing software engineer -- evaluate Rails using a CGI adapter on shared hosting. The purpose was to evaluate the functionality and architecture of Rails. Performance is satisfactory for the purpose. I think there will be some percentage of users to whom the CGI adapter will be useful in initial evaluations. Having it work at all is a good first step. I'd like to fix the path translation issue as well -- I think that an example should be provided using Application.options ( which are passed to WEBrick and should also be getting used in the MongrelAdapter ) to control stripping SCRIPT_NAME from the incoming URI. What I'm not sure about is which ENV variable to strip SCRIPT_NAME off of to get URI generators working, e.g., how to get SCRIPT_NAME prepended to the results of "redirect MyController, :foo_action" Anyhow, here's a trivial patch that gets the adapter to compile all --- the 'end' for Module Raw was missing at the end of raw/adapter/cgi.rb -------------- next part -------------- A non-text attachment was scrubbed... Name: cgi_adapter_missing_kEND.gz Type: application/x-gzip Size: 19006 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071025/09c8d366/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071025/09c8d366/attachment-0001.vcf From arne at arnebrasseur.net Thu Oct 25 23:44:07 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Thu, 25 Oct 2007 20:44:07 -0700 (PDT) Subject: [Nitro] cgi adapter and trivial patch In-Reply-To: <4720DA43.3050402@robmela.com> References: <4720DA43.3050402@robmela.com> Message-ID: <1142.140.134.35.52.1193370247.squirrel@webmail.arnebrasseur.net> > What I'm not sure about is which ENV variable to strip SCRIPT_NAME off > of to get URI generators working, e.g., how to get SCRIPT_NAME prepended > to the results of "redirect MyController, :foo_action" For URI generation it should hook into the EncodeURI module. Maybe a hook should be provided to more easily do this? > Anyhow, here's a trivial patch that gets the adapter to compile all --- > the 'end' for Module Raw was missing at the end of raw/adapter/cgi.rb Oops, probably my bad, or something went wrong with the patching. (ab) From james.britt at gmail.com Fri Oct 26 01:25:10 2007 From: james.britt at gmail.com (James Britt) Date: Thu, 25 Oct 2007 22:25:10 -0700 Subject: [Nitro] New Blog Article About Nitro/Og Message-ID: <47217A36.7080108@gmail.com> http://www.urubatan.info/2007/10/ruby-out-of-the-rails-nitro-and-og/ Perhaps folks here could add comments to answer some of the questions and concerns raised in the posts, specifically about automatic code reloading, and the claimed lack of anything like Rails' migrations. -- James Britt www.ruby-doc.org - Ruby Help & Documentation www.risingtidesoftware.com - Wicked Cool Coding www.rubystuff.com - The Ruby Store for Ruby Stuff www.jamesbritt.com - Playing with Better Toys From transfire at gmail.com Fri Oct 26 09:50:21 2007 From: transfire at gmail.com (Trans) Date: Fri, 26 Oct 2007 13:50:21 -0000 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <47217A36.7080108@gmail.com> References: <47217A36.7080108@gmail.com> Message-ID: <1193406621.960480.250470@50g2000hsm.googlegroups.com> On Oct 26, 1:25 am, James Britt wrote: > http://www.urubatan.info/2007/10/ruby-out-of-the-rails-nitro-and-og/ > > Perhaps folks here could add comments to answer some of the questions > and concerns raised in the posts, specifically about automatic code > reloading, and the claimed lack of anything like Rails' migrations. To be honest. At this point, I don't think Nitro is ever going to make it beyond niche use. I've been following Nitro for a long time now, and while it certainly has improved a lot, there are no signs that it will ever move past the "some day" state it is in right now. Just look at the evidence: * A webpage that is never finished * Documentation that is never written * An API that is never quite stable * A revolving door of developers George has been talking about the release of 0.50 for around a year, but it doesn't seem to be any closer today then it was back then. I've talked to him about some of the stuff and he seems receptive, but then nothing ever happens. I guess he's too busy and that's understandable, but that doesn't change the facts. Today we have a number of new, strong web frameworks coming on the scene, such as Merb and Sinatra. Nitro is getting squeezed out. Unless things turn around and soon, I fear it's just going to fade. I think ruby-doc.org has been the biggest boon at keeping Nitro relevant, but I'm not sure that will last either. ruby-doc.org is getting it's own new competition, such as http://www.noobkit.com/. I don't mean to be a nay-sayer. I'm just calling it like I see it. Maybe you don't agree with me (and actually I hope you don't!), but it's something to consider in any case. T. From rob at robmela.com Fri Oct 26 10:02:33 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 10:02:33 -0400 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <47217A36.7080108@gmail.com> References: <47217A36.7080108@gmail.com> Message-ID: <4721F379.8080606@robmela.com> It might be worth putting a 0.49 release out there now. I'm afraid that as Nitro gets more attention the 0.41 release give an unfavorable impression of the system's quality. I'm still working through it as a newbie, and the only major problem I've had with stability is the admin part. Once that's resolved I'd feel confident recommending Nitro to friends who are decent programmers with real projects. Zed seems to like it and has mentioned it on the Mongrel list. James Britt wrote: > http://www.urubatan.info/2007/10/ruby-out-of-the-rails-nitro-and-og/ > > Perhaps folks here could add comments to answer some of the questions > and concerns raised in the posts, specifically about automatic code > reloading, and the claimed lack of anything like Rails' migrations. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071026/3efad375/attachment.vcf From george.moschovitis at gmail.com Fri Oct 26 10:03:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 26 Oct 2007 17:03:28 +0300 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <47217A36.7080108@gmail.com> References: <47217A36.7080108@gmail.com> Message-ID: > > Perhaps folks here could add comments to answer some of the questions > and concerns raised in the posts, specifically about automatic code > reloading, and the claimed lack of anything like Rails' migrations. thanks for bringing this to my attention... I have replied to the post. -g. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071026/83f835e7/attachment.html From william.full.moon at gmail.com Fri Oct 26 10:13:53 2007 From: william.full.moon at gmail.com (* William) Date: Sat, 27 Oct 2007 00:13:53 +1000 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <1193406621.960480.250470@50g2000hsm.googlegroups.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> Message-ID: <9e03c3c60710260713x1927522dhfd108d1138c48854@mail.gmail.com> Hey Gang ... I can quite see the point, and I am personally a bit sad that the framework itself is not available now. There are simple things (project management) things that need to be done. I sent a list out earlier to George regarding what is needed to be production ready. My perspective as "audience" is that it is too hot for people to just let BE. This is not a wise attitude. Sooner of later there as to be "ready enough" to say let go -- Freeze it as stable. It is easy, it takes under 5 seconds to make a decision. Everything else is discussion. Action follows decisions. Personally (again) I believe Nitro is the best concept I've seen in computer deplpoyment management for 20 years. The risk with these frameworks is of becomeing bloated. So locking down a release now is advised. The next release can cull bloat. One has to provide migration pathways for real-life projects. And one needs documentation. You can say, a project gets the following its documenters earn for it. Think about that. And set some action plans ... (keep up the good work) Aloha, Will On 26/10/2007, Trans wrote: > > > On Oct 26, 1:25 am, James Britt wrote: > > http://www.urubatan.info/2007/10/ruby-out-of-the-rails-nitro-and-og/ > > > > Perhaps folks here could add comments to answer some of the questions > > and concerns raised in the posts, specifically about automatic code > > reloading, and the claimed lack of anything like Rails' migrations. > > To be honest. At this point, I don't think Nitro is ever going to make > it beyond niche use. I've been following Nitro for a long time now, > and while it certainly has improved a lot, there are no signs that it > will ever move past the "some day" state it is in right now. Just look > at the evidence: > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071027/56bc281a/attachment.html From aidan at yoyo.org Fri Oct 26 10:14:47 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 26 Oct 2007 15:14:47 +0100 (BST) Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <1193406621.960480.250470@50g2000hsm.googlegroups.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> Message-ID: <19311.192.193.220.201.1193408087.squirrel@yoyo.org> > George has been talking about the release of 0.50 for around a year, > but it doesn't seem to be any closer today then it was back then. I've > talked to him about some of the stuff and he seems receptive, but then > nothing ever happens. I guess he's too busy and that's understandable, > but that doesn't change the facts. I think this is the reason that Ramaze came into being. It's also the reason I'm keen for Og to be it's own project, because I think Og is still pretty special. Aidan From george.moschovitis at gmail.com Fri Oct 26 10:37:59 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 26 Oct 2007 17:37:59 +0300 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <19311.192.193.220.201.1193408087.squirrel@yoyo.org> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> Message-ID: Dear all, I have answered privately to tom, but here are the main points: - tom's email motivated me to take some extra time to integrate the repo version with facets 2.0, make sure the example runs and release it as 0.50(even w/o docs/tests). - I send to Tom the full source code of the nitroproject.org web site. If everyone wants to work on this (fix bugs, add more content or graphics or whatever) please ask him (or me) for the source code. please understand that I am doing the best I can. This may be not enough, but I think more contribution and less remarks would be more helpful. thanks, George. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071026/72b996a8/attachment.html From rob at robmela.com Fri Oct 26 11:48:45 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 11:48:45 -0400 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> Message-ID: <47220C5D.6070007@robmela.com> I'd love to see the site code so I can learn yet more about Nitro. I'd be happy to move cheatsheets over to nitroproject.org, and certainly seeing how George and others code in Nitro will give me more stuff to fold into the cheatsheet docs. It'd also be a great way for users on this list to learn each others idioms. Best techniques for using Nitro, based on experience, would soon follow. This framework is just too wonderful to let wither. George Moschovitis wrote: > Dear all, > > I have answered privately to tom, but here are the main points: > > > - tom's email motivated me to take some extra time to integrate the > repo version with facets 2.0, make sure the example runs and release > it as 0.50 (even w/o docs/tests). > - I send to Tom the full source code of the nitroproject.org > web site. If everyone wants to work on this > (fix bugs, add more content or graphics or whatever) please ask him > (or me) for the source code. > > please understand that I am doing the best I can. This may be not > enough, but I think more contribution and less remarks would be more > helpful. > > > thanks, > George. > > > -- > http://me.gr > http://joy.gr > http://cull.gr > http://nitroproject.org > http://phidz.com > http://joyerz.com > ------------------------------------------------------------------------ > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071026/d8ef382e/attachment-0001.vcf From rob at robmela.com Fri Oct 26 11:58:57 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 11:58:57 -0400 Subject: [Nitro] nitroproject.org In-Reply-To: <47220C5D.6070007@robmela.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <47220C5D.6070007@robmela.com> Message-ID: <47220EC1.9050407@robmela.com> What I meant was collaboration on nitroproject.org (not cheatsheets) would be a great way to learn each others Nitro idioms.... Anyhow, as for a possible nitroproject.org/cheatsheets.... Part of what I'm playing around with is documenation format -- it's supposed to be a rapid, simple tutorial and a quick ref -- I don't want cheatsheets to acquire the completeness ( and information overload ) of a book nor of a complete reference. Though I could imagine making it dynamic, with user comments as php.net or the postgres documentation. Robert Mela wrote: > I'd love to see the site code so I can learn yet more about Nitro. > > I'd be happy to move cheatsheets over to nitroproject.org, and > certainly seeing how George and others code in Nitro will give me more > stuff to fold into the cheatsheet docs. It'd also be a great way for > users on this list to learn each others idioms. Best techniques for > using Nitro, based on experience, would soon follow. > > This framework is just too wonderful to let wither. > > > George Moschovitis wrote: >> Dear all, >> >> I have answered privately to tom, but here are the main points: >> >> >> - tom's email motivated me to take some extra time to integrate the >> repo version with facets 2.0, make sure the example runs and release >> it as 0.50 (even w/o docs/tests). >> - I send to Tom the full source code of the nitroproject.org >> web site. If everyone wants to work on this >> (fix bugs, add more content or graphics or whatever) please ask him >> (or me) for the source code. >> >> please understand that I am doing the best I can. This may be not >> enough, but I think more contribution and less remarks would be more >> helpful. >> >> >> thanks, >> George. >> >> >> -- >> http://me.gr >> http://joy.gr >> http://cull.gr >> http://nitroproject.org >> http://phidz.com >> http://joyerz.com >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071026/9a25ce2d/attachment.vcf From t_leitner at gmx.at Fri Oct 26 12:06:12 2007 From: t_leitner at gmx.at (Thomas Leitner) Date: Fri, 26 Oct 2007 18:06:12 +0200 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <47220C5D.6070007@robmela.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <47220C5D.6070007@robmela.com> Message-ID: How about a system like the one used by the Django framework? They have all the necessary user documentation as text files in the repository. It seems quite reasonable to have the documentation in the source code repository and using a markup language like Markdown or Textile would make it easy to read the docu as plain text and as HTML (I personally prefer Markdown with extras - see http:// maruku.rubyforge.org). This would be usage documentation in contrast to the API documentation provided by the RDocs. An additional wiki where users could post documentation, tips and tricks wouldn't be bad either, perhaps integrate oxywtf better into the documentation effort. Just some thoughts because I currently don't have time to provide anything else. Thomas On 26.10.2007, at 17:48, Robert Mela wrote: > I'd love to see the site code so I can learn yet more about Nitro. > > I'd be happy to move cheatsheets over to nitroproject.org, and > certainly seeing how George and others code in Nitro will give me > more stuff to fold into the cheatsheet docs. It'd also be a great > way for users on this list to learn each others idioms. Best > techniques for using Nitro, based on experience, would soon follow. > > This framework is just too wonderful to let wither. From rob at robmela.com Fri Oct 26 12:41:59 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 12:41:59 -0400 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <47220C5D.6070007@robmela.com> Message-ID: <472218D7.3010109@robmela.com> The really hard part of cheatsheets is gathering, verifying, and organizing the content. Especially keeping it neat and simple enough to be scanned and understood quickly, be quick as a quick ref, and yet no so dumbed down as to be useless after the first scan. The quantity of content, if and when they're finished, will be small enough that cconverting to this or that markup should only take a few hours to a day. I found that agonizing over choice of markup was preventing me from actually getting started. I think too that having some actual content makes the choice and implementation of markup much simpler. That said, they can live in any markup form. I've thought about docbook, since that makes them easier to organize, and from docbook one could generate markup, html, or whatever. I think cheatsheet content could be distributed among source code files -- and indeed it is, as some is lifted directly from George's comments. But the limitation of, say, RDoc, is that it would not be possible to achieve the right flow for a quick-scan tutorial and centralized quickref. I see cheatsheets as necessarily being less comprehensive than the RDocs. Thomas Leitner wrote: > How about a system like the one used by the Django framework? They > have all the necessary user documentation as text files in the > repository. It seems quite reasonable to have the documentation in > the source code repository and using a markup language like Markdown > or Textile would make it easy to read the docu as plain text and as > HTML (I personally prefer Markdown with extras - see http:// > maruku.rubyforge.org). This would be usage documentation in contrast > to the API documentation provided by the RDocs. > > An additional wiki where users could post documentation, tips and > tricks wouldn't be bad either, perhaps integrate oxywtf better into > the documentation effort. > > Just some thoughts because I currently don't have time to provide > anything else. > > Thomas > > On 26.10.2007, at 17:48, Robert Mela wrote: > > >> I'd love to see the site code so I can learn yet more about Nitro. >> >> I'd be happy to move cheatsheets over to nitroproject.org, and >> certainly seeing how George and others code in Nitro will give me >> more stuff to fold into the cheatsheet docs. It'd also be a great >> way for users on this list to learn each others idioms. Best >> techniques for using Nitro, based on experience, would soon follow. >> >> This framework is just too wonderful to let wither. >> > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071026/e6cab3af/attachment.vcf From rob at robmela.com Fri Oct 26 13:25:31 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 26 Oct 2007 13:25:31 -0400 Subject: [Nitro] Sinatra/Og ? Message-ID: <4722230B.7070505@robmela.com> Sinatra/Og? -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071026/2c1d0ac8/attachment.vcf From george.moschovitis at gmail.com Fri Oct 26 13:37:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 26 Oct 2007 20:37:38 +0300 Subject: [Nitro] nitroproject.org In-Reply-To: <47220EC1.9050407@robmela.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <47220C5D.6070007@robmela.com> <47220EC1.9050407@robmela.com> Message-ID: Rob, I emailed the source code to you. It would be great if you could clean up this stuff and prepare a nice .zip file for other people to use as reference. If you could integrate your cheatsheets it would be great as well. -g. On 10/26/07, Robert Mela wrote: > > What I meant was collaboration on nitroproject.org (not cheatsheets) > would be a great way to learn each others Nitro idioms.... > > Anyhow, as for a possible nitroproject.org/cheatsheets.... > > Part of what I'm playing around with is documenation format -- it's > supposed to be a rapid, simple tutorial and a quick ref -- I don't want > cheatsheets to acquire the completeness ( and information overload ) of > a book nor of a complete reference. Though I could imagine making it > dynamic, with user comments as php.net or the postgres documentation. > > Robert Mela wrote: > > I'd love to see the site code so I can learn yet more about Nitro. > > > > I'd be happy to move cheatsheets over to nitroproject.org, and > > certainly seeing how George and others code in Nitro will give me more > > stuff to fold into the cheatsheet docs. It'd also be a great way for > > users on this list to learn each others idioms. Best techniques for > > using Nitro, based on experience, would soon follow. > > > > This framework is just too wonderful to let wither. > > > > > > George Moschovitis wrote: > >> Dear all, > >> > >> I have answered privately to tom, but here are the main points: > >> > >> > >> - tom's email motivated me to take some extra time to integrate the > >> repo version with facets 2.0, make sure the example runs and release > >> it as 0.50 (even w/o docs/tests). > >> - I send to Tom the full source code of the nitroproject.org > >> web site. If everyone wants to work on this > >> (fix bugs, add more content or graphics or whatever) please ask him > >> (or me) for the source code. > >> > >> please understand that I am doing the best I can. This may be not > >> enough, but I think more contribution and less remarks would be more > >> helpful. > >> > >> > >> thanks, > >> George. > >> > >> > >> -- > >> http://me.gr > >> http://joy.gr > >> http://cull.gr > >> http://nitroproject.org > >> http://phidz.com > >> http://joyerz.com > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071026/4beb2d54/attachment.html From transfire at gmail.com Fri Oct 26 14:18:03 2007 From: transfire at gmail.com (Trans) Date: Fri, 26 Oct 2007 18:18:03 -0000 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> Message-ID: <1193422683.277490.53560@o38g2000hse.googlegroups.com> On Oct 26, 10:37 am, "George Moschovitis" wrote: > Dear all, > > I have answered privately to tom, but here are the main points: > > - tom's email motivated me to take some extra time to integrate the repo > version with facets 2.0, make sure the example runs and release it as > 0.50(even w/o docs/tests). > - I send to Tom the full source code of the nitroproject.org web site. If > everyone wants to work on this (fix bugs, add more content or graphics or > whatever) please ask him (or me) for the source code. > > please understand that I am doing the best I can. This may be not enough, > but I think more contribution and less remarks would be more helpful. Well this is what I propose, and if you agree I will do most of it myself: 1. Make Nitro a pure meta-project. Is should not contain any libs itself. What's in Nitro now likely belongs to Raw, but maybe Glue. 2. Then the Nitro repository would house well separated sub-projects, Og and Raw, plus the Nitro meta-project. The Examples can be placed in with their respective projects. We'd then have a clean project/ subproject repository: nitro/ nitro/ (or call meta/ ?) og/ raw/ glue/ We can leave in glue for now. And we can consider adding blow (http:// blow.rubyforge.org) to the collection. 3. Rather the working solely on a patch by patch basis, having a central repo trusted devs can push to would be more helpful. But who can host that? 4. Move the nitroproject.org site into the repository, preferably under the nitro metaproject directory, so we developers can contribute to it. 5. Give each sub-project it's own mini-website too under their respective sub-project directories. When published these subproject sites will tie into the main site. 6. Make OxyLiquit the offical FAQ system. Link it and nitropoject.org together better; blend the sites look and feel better, etc. 7. Since nitroproject.org runs on an old version of Nitro, we will need to update it to use the new verion, but not until 0.50 has a release candidate out. (I will probably need some help on this step.) 8. Add a documentation wiki to the main site --use docbook or whatever format you want. T. From george.moschovitis at gmail.com Fri Oct 26 16:07:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 26 Oct 2007 23:07:36 +0300 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <1193422683.277490.53560@o38g2000hse.googlegroups.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <1193422683.277490.53560@o38g2000hse.googlegroups.com> Message-ID: Ok, Let's start by making the repo version compatible with facets 2.0. I will work on this tomorrow. Be warned, I will probably need your help though. When this is done, you can work on ponits 1-2. Please also include blow as you describe. -g. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071026/3ffafb31/attachment-0001.html From reid.thompson at ateb.com Fri Oct 26 15:50:10 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Fri, 26 Oct 2007 15:50:10 -0400 Subject: [Nitro] To those who use and know well Nitro/Og ( sub New Blog Article About Nitro/Og) Message-ID: <472244F2.6070407@ateb.com> Confession #1 - I'm not a web programmer ( but I have several ideas for web based projects that I'd really like to use Ruby/Nitro/Og for )( 97+% of my programming is C / *NIX shell scripting) Confession #2 - I've been following Nitro/Og for a good while on the lists and various associated sites. I've used Og, which I really, really like, on several occasions to manage DB interactions( PostgreSQL). (Most of these have been batch, large dataset loads, which could Og isn't optimized for, but has been more than sufficient for.) I've started, but not finished, a first project with Nitro/Og ( this was a good while back, and Nitro was changing a lot, very quickly then ) which is now on a back, back burner. I really like the overall concept of what I *think* Nitro/Og represent. Much more so than Rails, because Nitro/Og should allow one to easily incorporate with pre-existing applications and database sets and because Nitro/Og should make converting an idea into a database driven application fairly simple and straightforward. However, given Confession #1, 'getting started' with Nitro ( less so with Og ) has been pretty much a futile effort( not simple and straightforward ). There've several threads recently re documentation and examples, etc -- "Please, Please" -- I know it may be a pain in the @$$ for those who have a good understanding of the framework and are using it, but for those who are looking for a base to build on -- a starting point, simple step by step introductions are a requirement). Having requested that, I realize that providing this has been precluded by the ongoing, rapid advancement of Nitro by those who do understand and use it. Documentation/Examples require a 'freezepoint'/version breakpoint in order to not be invalidated by framework advancements. Can .50 be that point? Or is there still too much to do to get the framework to a pausing place? Thanks, reid From george.moschovitis at gmail.com Sat Oct 27 12:59:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 27 Oct 2007 19:59:56 +0300 Subject: [Nitro] head/branch in the repo. Message-ID: Dear devs, if you pull from the darcs repo you will see 2 directories: - head: contains the current version of the repo (pretty stable, uses facets 1.8.54) - branch: this is the experimental code. Me and Tom will try to make this compatible with facets 2.0 and prepare it for immediate release as v0.50 please use a symbolic link or something to the new head directory to make your programms run. regards, George. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071027/65348612/attachment.html From george.moschovitis at gmail.com Sat Oct 27 13:42:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 27 Oct 2007 20:42:37 +0300 Subject: [Nitro] head/branch in the repo. In-Reply-To: References: Message-ID: Please ignore the previous post. The old repo works as it used to work. You can find the branch repo here: darcs get http://repo.nitroproject.org/branch -g. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071027/fb0b1142/attachment.html From transfire at gmail.com Sat Oct 27 13:45:50 2007 From: transfire at gmail.com (Trans) Date: Sat, 27 Oct 2007 17:45:50 -0000 Subject: [Nitro] head/branch in the repo. In-Reply-To: References: Message-ID: <1193507150.439120.279290@d55g2000hsg.googlegroups.com> On Oct 27, 12:59 pm, "George Moschovitis" wrote: > Dear devs, > > if you pull from the darcs repo you will see 2 directories: > > - head: contains the current version of the repo (pretty stable, uses facets > 1.8.54) > - branch: this is the experimental code. Me and Tom will try to make this > compatible with facets 2.0 and prepare it for immediate release as v0.50 > > please use a symbolic link or something to the new head directory to make > your programms run. > > regards, > George. Ok. I see what you did. I was a little confused. I thought you had actually put branch/ inside of head/. (Because you wrote "head/branch" in the subject line.) If you want, you can point http://repo.nitroproject.org to repo/head/ instead of just repo/ (assuming those are dir names), then everything will be like it was. And you can just let me know what the branch directory is, eg. http://nitroproject.org/repo/branch/ (?) T. From george.moschovitis at gmail.com Sat Oct 27 13:59:08 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 27 Oct 2007 20:59:08 +0300 Subject: [Nitro] head/branch in the repo. In-Reply-To: <1193507150.439120.279290@d55g2000hsg.googlegroups.com> References: <1193507150.439120.279290@d55g2000hsg.googlegroups.com> Message-ID: I think now everything is ok: darcs get repo.nitroproject.org == head darcs get repo.nitroproject.org/branch == branch just send me darc bundles: darcs send -o bundle email me bundle btw, where can i find blow ? -g. On 10/27/07, Trans wrote: > > > > On Oct 27, 12:59 pm, "George Moschovitis" > wrote: > > Dear devs, > > > > if you pull from the darcs repo you will see 2 directories: > > > > - head: contains the current version of the repo (pretty stable, uses > facets > > 1.8.54) > > - branch: this is the experimental code. Me and Tom will try to make > this > > compatible with facets 2.0 and prepare it for immediate release as > v0.50 > > > > please use a symbolic link or something to the new head directory to > make > > your programms run. > > > > regards, > > George. > > Ok. I see what you did. I was a little confused. I thought you had > actually put branch/ inside of head/. (Because you wrote "head/branch" > in the subject line.) > > If you want, you can point http://repo.nitroproject.org to repo/head/ > instead of just repo/ (assuming those are dir names), then everything > will be like it was. And you can just let me know what the branch > directory is, eg. http://nitroproject.org/repo/branch/ (?) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071027/9c9336da/attachment.html From david at makingthings.com Sat Oct 27 15:39:29 2007 From: david at makingthings.com (David Williams) Date: Sat, 27 Oct 2007 12:39:29 -0700 Subject: [Nitro] Og standalone experience - whew - so good... but hard to get anywhere as a newbie. Message-ID: <003501c818d1$171fa340$455ee9c0$@com> I'm just starting with Og. I love the way it's put together and the way it feels to work with it and I think I'll be able to do great things with it. Congatulations to all concerned. class Book property :author, String end Makes the database, table and makes sure it's all up to date! Are you kidding? This is SO easy. So good. I have comments which I hope can be helpful in showing what I encountered. Sensitive to how these posts can sound I'd like to emphasize that my intention is not to whine, but to point out how hard it is for newbies to get a purchase in here. I'd also like to help if I can. 1) There are a lot of dead ends that a newbie encounters when trying to understand Og. There's the beautiful http://www.nitroproject.org/ with documentation with version 0.42 (but the version number is very hard to find). The online repository seems to have not been altered since June 2007. When I try to add a note to the Fora (prior to which I was required to get an OpenId) I find that having composed a post, the post button is ignored (Firefox / Windows). A few words on the front page describing where things are would be so golden. Sometimes just a sentence or two of accurate status can be so helpful. 2) When I do a gem install og I seem to get Og 0.41, yet I see mentions of 0.50. What is the latest release? When is 0.50 going to be released. I worry when I see so much heavy lifting and refactoring going on in the codebase that 0.50 is not going to be for a while. This means that I don't know what to concentrate on 0.4x or 0.5. 5) The most active forum seems to be this one (http://rubyforge.org/mailman/listinfo/nitro-general) but I can't see how to search it! This makes a lot of the knowledge tied up in it inaccessible. 6) Finding a few paragraphs that describe and give examples of polymorphism and schema_inheritance is quite a challenge. Having looked around a little I have gleaned snippets from tests. Could someone consolidate these and put them into the source code so RDoc at least can find them? 7) I grabbed the latest version from the darc's repository, since people were saying "Don't use the 0.4x, use the latest". This was tricky itself... but that's another story. But I found that SchemaInhertance doesn't seem to work. (Og::SchemaInheritanceBase is missing?). And I can't find any test files to see how I should use polymorphism. 8) I installed the latest version via gem. I made the gems myself according to the instructions I found. But this was tricky since a) the rake script seems to assume a unix-y shell and so didn't work too well and b) once I was doing it on a Linux box the code to transfer the .gemspec's into the dist directory didn't seem to work. If any of this can be delegated to me with guidance please give it a shot. I think my main hope in this is to get someone - George maybe - to write a short paragraph that can be put around (on rubyforge and nitroproject) saying "Hi! The team and I working on stuff like crazy. Here's where we're at. If you just want to play use 0.4x - be aware that ___ and ___ have been massively re-written also don't worry about the startup speed, that's been fixed too. If really need the new features, you'll need to pull from the repo, however, be aware that ___ and ______ are not working right now. ____ will be fixed tomorrow, but _____ doesn't look too close at all. If you want to contribute or discuss, use ____ forum, since we don't look at the others too much. My timeframe for a general release for Nitro and Og V0.50 is _____." Or something. This would have made my entry into Og much more easy! Thanks and sorry for the long post. From transfire at gmail.com Sat Oct 27 16:14:19 2007 From: transfire at gmail.com (Trans) Date: Sat, 27 Oct 2007 20:14:19 -0000 Subject: [Nitro] Og standalone experience - whew - so good... but hard to get anywhere as a newbie. In-Reply-To: <003501c818d1$171fa340$455ee9c0$@com> References: <003501c818d1$171fa340$455ee9c0$@com> Message-ID: <1193516059.711516.182200@d55g2000hsg.googlegroups.com> David Williams wrote: > 1) There are a lot of dead ends that a newbie encounters when trying to > understand Og. There's the beautiful http://www.nitroproject.org/ with > documentation with version 0.42 (but the version number is very hard to > find). The online repository seems to have not been altered since June > 2007. When I try to add a note to the Fora (prior to which I was required > to get an OpenId) I find that having composed a post, the post button is > ignored (Firefox / Windows). A few words on the front page describing where > things are would be so golden. Sometimes just a sentence or two of accurate > status can be so helpful. > > 2) When I do a gem install og I seem to get Og 0.41, yet I see mentions of > 0.50. What is the latest release? When is 0.50 going to be released. I > worry when I see so much heavy lifting and refactoring going on in the > codebase that 0.50 is not going to be for a while. This means that I don't > know what to concentrate on 0.4x or 0.5. 3 & 4 ? ;-) "0.50" is in the darcs repository. George and I are working on a release as we speak. WE will also be updatin ghte website soon. Stay tuned... > 5) The most active forum seems to be this one > (http://rubyforge.org/mailman/listinfo/nitro-general) but I can't see how to > search it! This makes a lot of the knowledge tied up in it inaccessible. http://groups.google.com/group/nitro-general?hl=en Your welcome :-) > 6) Finding a few paragraphs that describe and give examples of polymorphism > and schema_inheritance is quite a challenge. Having looked around a little > I have gleaned snippets from tests. Could someone consolidate these and put > them into the source code so RDoc at least can find them? > > 7) I grabbed the latest version from the darc's repository, since people > were saying "Don't use the 0.4x, use the latest". This was tricky itself... Ah, you found it. > but that's another story. But I found that SchemaInhertance doesn't seem to > work. (Og::SchemaInheritanceBase is missing?). And I can't find any test > files to see how I should use polymorphism. > > 8) I installed the latest version via gem. I made the gems myself according > to the instructions I found. But this was tricky since a) the rake script > seems to assume a unix-y shell and so didn't work too well and b) once I was > doing it on a Linux box the code to transfer the .gemspec's into the dist > directory didn't seem to work. > > If any of this can be delegated to me with guidance please give it a shot. > > I think my main hope in this is to get someone - George maybe - to write a > short paragraph that can be put around (on rubyforge and nitroproject) > saying "Hi! The team and I working on stuff like crazy. Here's where we're > at. If you just want to play use 0.4x - be aware that ___ and ___ have been > massively re-written also don't worry about the startup speed, that's been > fixed too. If really need the new features, you'll need to pull from the > repo, however, be aware that ___ and ______ are not working right now. ____ > will be fixed tomorrow, but _____ doesn't look too close at all. If you > want to contribute or discuss, use ____ forum, since we don't look at the > others too much. My timeframe for a general release for Nitro and Og V0.50 > is _____." Or something. This would have made my entry into Og much more > easy! Well, I hope half the paragraph won't even be necessary here in a couple weeks. I think once George and I have straightened out 0.50, then we'll be able to get a better fix on how to create a larger community effort. So hold tight just a bit longer. I just got Nitro running on Facets 2.0 (mostly) so that's a good sign. T. From transfire at gmail.com Sat Oct 27 17:36:00 2007 From: transfire at gmail.com (Trans) Date: Sat, 27 Oct 2007 21:36:00 -0000 Subject: [Nitro] Nitro Wiki Message-ID: <1193520960.169963.293300@o38g2000hse.googlegroups.com> Has anyone written a wiki with Nitro? T. From rob at robmela.com Sat Oct 27 22:45:26 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 27 Oct 2007 22:45:26 -0400 Subject: [Nitro] Og standalone experience - whew - so good... but hard to get anywhere as a newbie. In-Reply-To: <003501c818d1$171fa340$455ee9c0$@com> References: <003501c818d1$171fa340$455ee9c0$@com> Message-ID: <4723F7C6.8010205@robmela.com> I think that, at long last, the rough edges that have stymied me will be worked out within the next few weeks. We're probably a couple weeks away from seeing an official 0.50. However, Until George and Tom produce the true kick-ass documentation and examples, the source itself is rich in comments and examples. I haven't looked through the Og inheritance examples in the specs, but I have seen the examples in og/examples/run.rb ( ArticleComment < Comment ) As an aside, there's a ton of great examples for using Og with forms in the Admin part code, especially: - OgAdminController#save ( nitro/lib/nitro/part/admin/og/controller.rb ) - nitro/lib/nitro/part/admin/og/template/update.htmlx One great thing is that the whole codebase is relatively small -- making it a lot easier to use as "documentation" than something really huge like Rails. No substitute for docs, I know... but for the next couple of weeks it might tide you over.... I think it'd be great if you could ask lots of questions on this list. Watching newbies, myself included, try to figure out how to use Nitro and Og will probably be helpful to whoever's writing tutorials and cheatsheets. David Williams wrote: > I'm just starting with Og. I love the way it's put together and the way it > feels to work with it and I think I'll be able to do great things with it. > > Congatulations to all concerned. > > class Book > property :author, String > end > > Makes the database, table and makes sure it's all up to date! Are you > kidding? This is SO easy. So good. > > I have comments which I hope can be helpful in showing what I encountered. > Sensitive to how these posts can sound I'd like to emphasize that my > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071027/fc1138fd/attachment.vcf From rob at robmela.com Sat Oct 27 23:15:17 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 27 Oct 2007 23:15:17 -0400 Subject: [Nitro] acts? Message-ID: <4723FEC5.10509@robmela.com> I see some stuff in the og/model directory that corresponds to some of the common Rails acts_as mixins. I'm curious as to what stage of completion/reliability these things are at. Also, are there other commonly used rails acts mixins that should be added to this list? For others, would revisable in some way obviate the need for acts_as_paranoid? What I see are: hierarchical.rb -- acts_as_tree, but based on nested sets ( I though Jonathan was working on materialized paths as well ? ) orderable.rb -- acts_as_list ? searchable.rb -- default suitable for small applications only: condition = search_props.collect { |p| "#{p} LIKE '%#{query}%'" }.join(' OR ') revisable.rb -- WOW! -- revisions and rollbacks for models ( what's the corresponding Rails acts_as? ) taggable.rb -- creates a Tag table and many_to_many relationship for class that includes it timestamped.rb -- creates and maintains timestamp columns for create, update, and access for including class cacheable.rb -- mixin that automatically adds cache handling code to class ( where is the cache implementation decided -- in Og optimistic_locking.rb -- yeah! uuid.rb -- uuid keys instead of autoincrement -- insures uniqueness across databases that may be merged ( autoincrement does not ) sti.rb -- all inheriting classes are stored in same table as base class. I'm also unclear on the workings of sti.rb, but I guess I could figure it out with some experimentation. At it's core it seems to work by adding an ogtype column to the table. But I wonder what it does for inheriting types that have additonal attributes -- does it add columns? How is inheritance reflected in the schema without STI? New tables? No need to answer if yer busy. I can experiment. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071027/5bfb4546/attachment.vcf From rob at robmela.com Sat Oct 27 23:21:27 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 27 Oct 2007 23:21:27 -0400 Subject: [Nitro] unmanageable? Message-ID: <47240037.3010207@robmela.com> I don't get the use case for unmanageable. Why would one make a class an Og object but have Og manager not manage it? BTW, "unmanageable" means "impossible to manage", as in "out of control" -- could there be a better name for it? "notmanaged" or "unmanaged"? -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071027/3c2e16a9/attachment.vcf From rob at robmela.com Sat Oct 27 23:43:09 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 27 Oct 2007 23:43:09 -0400 Subject: [Nitro] unmanageable? In-Reply-To: <47240037.3010207@robmela.com> References: <47240037.3010207@robmela.com> Message-ID: <4724054D.4030906@robmela.com> Oh... now I get part of it... but still, is there a use case for explicitly marking a class as Unmanageable, or is it just that this already extant feature is available in case that need arises? # # Unmanageable classes include classes: # * without serializable attributes # * explicitly marked as Unmanageable (is Og::Unamanageable) # * are polymorphic_parents (ie thay are used to spawn polymorphic relations) Robert Mela wrote: > I don't get the use case for unmanageable. Why would one make a class > an Og object but have Og manager not manage it? > > BTW, "unmanageable" means "impossible to manage", as in "out of > control" -- could there be a better name for it? "notmanaged" or > "unmanaged"? > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071027/408744b4/attachment.vcf From mvyver at gmail.com Sun Oct 28 00:33:10 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 28 Oct 2007 14:33:10 +1000 Subject: [Nitro] acts? In-Reply-To: <4723FEC5.10509@robmela.com> References: <4723FEC5.10509@robmela.com> Message-ID: <389c43e40710272133g48e96ff5v3f022fe2d4054cb1@mail.gmail.com> Interesting outline/guide - thanks On 10/28/07, Robert Mela wrote: > I see some stuff in the og/model directory that corresponds to some of > the common Rails acts_as mixins. > > I'm curious as to what stage of completion/reliability these things are > at. Also, are there other commonly used rails acts mixins that should > be added to this list? For others, would revisable in some way > obviate the need for acts_as_paranoid? > > What I see are: > > hierarchical.rb -- acts_as_tree, but based on nested sets ( I though > Jonathan was working on materialized paths as well ? ) > orderable.rb -- acts_as_list ? > searchable.rb -- default suitable for small applications only: > condition = search_props.collect { |p| "#{p} LIKE '%#{query}%'" }.join(' > OR ') > revisable.rb -- WOW! -- revisions and rollbacks for models ( what's the > corresponding Rails acts_as? ) > taggable.rb -- creates a Tag table and many_to_many relationship for > class that includes it > timestamped.rb -- creates and maintains timestamp columns for create, > update, and access for including class > cacheable.rb -- mixin that automatically adds cache handling code to > class ( where is the cache implementation decided -- in Og > optimistic_locking.rb -- yeah! > uuid.rb -- uuid keys instead of autoincrement -- insures uniqueness > across databases that may be merged ( autoincrement does not ) > sti.rb -- all inheriting classes are stored in same table as base class. > > I'm also unclear on the workings of sti.rb, but I guess I could figure > it out with some experimentation. At it's core it seems to work by > adding an ogtype column to the table. > But I wonder what it does for inheriting types that have additonal > attributes -- does it add columns? How is inheritance reflected in the > schema without STI? New tables? > > No need to answer if yer busy. I can experiment. > > > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From george.moschovitis at gmail.com Sun Oct 28 02:54:46 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 28 Oct 2007 08:54:46 +0200 Subject: [Nitro] Nitro Wiki In-Reply-To: <1193520960.169963.293300@o38g2000hse.googlegroups.com> References: <1193520960.169963.293300@o38g2000hse.googlegroups.com> Message-ID: Have a look at spark (a wiki written for Nitro 0.41.0) Have a look at rubyforge. -g. On 10/27/07, Trans wrote: > > Has anyone written a wiki with Nitro? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071028/3fa95e0a/attachment.html From george.moschovitis at gmail.com Sun Oct 28 02:58:11 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 28 Oct 2007 08:58:11 +0200 Subject: [Nitro] unmanageable? In-Reply-To: <4724054D.4030906@robmela.com> References: <47240037.3010207@robmela.com> <4724054D.4030906@robmela.com> Message-ID: Number 3 of thes points is the ..killer appp for Unmanageable: for example lets say you have a basic Content class: class Content .. end and you derive some Classes for your app: class Article < Content .. end class ForumPost < Content .. end as you can see Content is a 'helper' class. You don't want actual sql tables etc created for it. You hint Og by making Content unmanageable. -g. On 10/28/07, Robert Mela wrote: > > Oh... now I get part of it... but still, is there a use case for > explicitly marking a class as Unmanageable, or is it just that this > already extant feature is available in case that need arises? > > # > # Unmanageable classes include classes: > # * without serializable attributes > # * explicitly marked as Unmanageable (is Og::Unamanageable) > # * are polymorphic_parents (ie thay are used to spawn polymorphic > relations) > > Robert Mela wrote: > > I don't get the use case for unmanageable. Why would one make a class > > an Og object but have Og manager not manage it? > > > > BTW, "unmanageable" means "impossible to manage", as in "out of > > control" -- could there be a better name for it? "notmanaged" or > > "unmanaged"? > > _______________________________________________ > > 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://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071028/4b2be57a/attachment.html From george.moschovitis at gmail.com Wed Oct 31 10:47:22 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 31 Oct 2007 16:47:22 +0200 Subject: [Nitro] Nitro + Facets 2.0 Message-ID: FYI, Tom, more or less completed the transition of Nitro to Facets 2.0 :) When he releases the bug-fixed 2.0.3 version I will update the repo with his changes. -g. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071031/f41a4442/attachment-0001.html From rob at robmela.com Wed Oct 31 12:48:30 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 31 Oct 2007 12:48:30 -0400 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: References: Message-ID: <4728B1DE.5040906@robmela.com> YEEHA!!! I would love to use Nitro professionally and would like to see enough momentum and community built up behind it to support that sort of recommendation. To that end.... What's everyone thinking regarding the "PR" should occur surrounding the release of 0.50? And why not call it 0.95? George Moschovitis wrote: > FYI, > > Tom, more or less completed the transition of Nitro to Facets 2.0 :) > When he releases the bug-fixed 2.0.3 version I will update the repo > with his changes. > > -g. > > -- > http://me.gr > http://joy.gr > http://cull.gr > http://nitroproject.org > http://phidz.com > http://joyerz.com > ------------------------------------------------------------------------ > > _______________________________________________ > 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: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071031/6b74dbf9/attachment.vcf From george.moschovitis at gmail.com Wed Oct 31 15:30:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 31 Oct 2007 21:30:27 +0200 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: <4728B1DE.5040906@robmela.com> References: <4728B1DE.5040906@robmela.com> Message-ID: > > What's everyone thinking regarding the "PR" should occur surrounding the > release of 0.50? And why not call it 0.95? > I am not sure about PR. Any ideas? I like the 0.50 version though... -g. -- http://me.gr http://joy.gr http://cull.gr http://nitroproject.org http://phidz.com http://joyerz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071031/f1f17817/attachment.html From transfire at gmail.com Wed Oct 31 17:53:41 2007 From: transfire at gmail.com (Trans) Date: Wed, 31 Oct 2007 21:53:41 -0000 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: <4728B1DE.5040906@robmela.com> References: <4728B1DE.5040906@robmela.com> Message-ID: <1193867621.768443.77790@22g2000hsm.googlegroups.com> On Oct 31, 12:48 pm, Robert Mela wrote: > YEEHA!!! > > I would love to use Nitro professionally and would like to see enough > momentum and community built up behind it to support that sort of > recommendation. > > To that end.... > > What's everyone thinking regarding the "PR" should occur surrounding the > release of 0.50? And why not call it 0.95? 0.50 is good for now. But point taken, I would like to see the next focus move be toward reaching a high-quality 1.0 release. T. From james.britt at gmail.com Wed Oct 31 19:07:10 2007 From: james.britt at gmail.com (James Britt) Date: Wed, 31 Oct 2007 16:07:10 -0700 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: <4728B1DE.5040906@robmela.com> References: <4728B1DE.5040906@robmela.com> Message-ID: <47290A9E.8070402@gmail.com> Robert Mela wrote: > YEEHA!!! > > I would love to use Nitro professionally and would like to see enough > momentum and community built up behind it to support that sort of > recommendation. > > To that end.... > > What's everyone thinking regarding the "PR" should occur surrounding the > release of 0.50? And why not call it 0.95? Nitro PR might be a hard sell. There seems to be a perception that it's a Rails-a-like; at MtWest RubyConf earlier this year, Chad Fowler, in his keynote, basically said that people working on Nitro should just stop, because it's the same thing as Rails (though he approved of continued work on Iowa, because in his view it was sufficiently different from Rails). People who've spent time with both Nitro and Rails likely do not see them as the same thing; getting people to try Nitro is perhaps the best way to grow the community. But when folks think Nitro is "the same thing" as Rails, and they already know, or know about Rails, adoption is challenge. Nitro is not going to suit everyone, but that's true of Rails as well (witness the emergence of Camping, Merb, and Sinatra). However, people won't really know if its good for them or not unless they try it, so getting up and rolling needs to be really stupid simple. The Og/Nitro pain-points have been discussed here before, but I think they boil down to various issues that trip people up too early in the "try it and see" process. -- James Britt "Tear it up and start again." - Anonymous From me at pixelcort.com Wed Oct 31 19:28:24 2007 From: me at pixelcort.com (Cortland Klein) Date: Wed, 31 Oct 2007 16:28:24 -0700 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: <47290A9E.8070402@gmail.com> References: <4728B1DE.5040906@robmela.com> <47290A9E.8070402@gmail.com> Message-ID: <9BCB0C53-FD0F-4286-8FDE-29B110F9C45E@pixelcort.com> At this point, being a silent observer, I believe the biggest thing needed from the Nitro project now are tutorials and sample projects that actually work. Currently, getting Nitro to actually work on Mac OS X is a bit of a challenge, and spark nor flare seem to work 'out of the box'. I remember when I first saw nitro it was with some screen casts of it. Once 0.50 comes out some up-to-date screencasts, text-based tutorials and 'out of the box' working example projects would be in order. Also, a page on the site called "Why Nitro is different than Rails" is needed. On Oct 31, 2007, at 4:07 PM, James Britt wrote: > Nitro PR might be a hard sell. > > There seems to be a perception that it's a Rails-a-like; at MtWest > RubyConf earlier this year, Chad Fowler, in his keynote, basically > said > that people working on Nitro should just stop, because it's the same > thing as Rails (though he approved of continued work on Iowa, > because in > his view it was sufficiently different from Rails). > > People who've spent time with both Nitro and Rails likely do not see > them as the same thing; getting people to try Nitro is perhaps the > best > way to grow the community. But when folks think Nitro is "the same > thing" as Rails, and they already know, or know about Rails, > adoption is > challenge. > > Nitro is not going to suit everyone, but that's true of Rails as well > (witness the emergence of Camping, Merb, and Sinatra). However, > people > won't really know if its good for them or not unless they try it, so > getting up and rolling needs to be really stupid simple. > > The Og/Nitro pain-points have been discussed here before, but I think > they boil down to various issues that trip people up too early in the > "try it and see" process. -- Cortland Klein +1 408 506 9791 Student, Business Management San Jos? State University Campus Village B 336D (formerly 337B) 375 S. 9th St. #5180 (formerly #2028), San Jose, CA, 95112 Operations and Technology, Entrepreneurial Society http://e-society.org/ http://pixelcort.com/ From me at pixelcort.com Wed Oct 31 19:46:14 2007 From: me at pixelcort.com (Cortland Klein) Date: Wed, 31 Oct 2007 16:46:14 -0700 Subject: [Nitro] New Blog Article About Nitro/Og In-Reply-To: <1193422683.277490.53560@o38g2000hse.googlegroups.com> References: <47217A36.7080108@gmail.com> <1193406621.960480.250470@50g2000hsm.googlegroups.com> <19311.192.193.220.201.1193408087.squirrel@yoyo.org> <1193422683.277490.53560@o38g2000hse.googlegroups.com> Message-ID: <6B6A7E98-D92B-4DB6-AC16-8F3A80B48742@pixelcort.com> I can host a repository for the Nitro team if you all would like. I have a DreamHost account that I can set up and maintain a Trac and SVN space if desired. Whatever I can do to help this project, let me know. :-) On Oct 26, 2007, at 11:18 AM, Trans wrote: > 3. Rather the working solely on a patch by patch basis, having a > central repo trusted devs can push to would be more helpful. But who > can host that? -- Cortland Klein +1 408 506 9791 Student, Business Management San Jos? State University Campus Village B 336D (formerly 337B) 375 S. 9th St. #5180 (formerly #2028), San Jose, CA, 95112 Operations and Technology, Entrepreneurial Society http://e-society.org/ http://pixelcort.com/ From rob at robmela.com Wed Oct 31 21:40:48 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 31 Oct 2007 21:40:48 -0400 Subject: [Nitro] Nitro + Facets 2.0 In-Reply-To: <47290A9E.8070402@gmail.com> References: <4728B1DE.5040906@robmela.com> <47290A9E.8070402@gmail.com> Message-ID: <47292EA0.2000604@robmela.com> The points are 1) There are issues that trip new users up early in the process - Getting started needs to be brain-dead simple 2) The lack of differentiation from Rails So the questions to answer are: 1) What's the answer to "Why should I consider Nitro for my next project?" 2) What specifically is broken in the getting started steps? James Britt wrote: > Nitro PR might be a hard sell. > > There seems to be a perception that it's a Rails-a-like; at MtWest > RubyConf earlier this year, Chad Fowler, in his keynote, basically said > that people working on Nitro should just stop, because it's the same > thing as Rails (though he approved of continued work on Iowa, because in > his view it was sufficiently different from Rails). > > People who've spent time with both Nitro and Rails likely do not see > them as the same thing; getting people to try Nitro is perhaps the best > way to grow the community. But when folks think Nitro is "the same > thing" as Rails, and they already know, or know about Rails, adoption is > challenge. > > Nitro is not going to suit everyone, but that's true of Rails as well > (witness the emergence of Camping, Merb, and Sinatra). However, people > won't really know if its good for them or not unless they try it, so > getting up and rolling needs to be really stupid simple. > > The Og/Nitro pain-points have been discussed here before, but I think > they boil down to various issues that trip people up too early in the > "try it and see" process. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071031/1b6860d7/attachment.vcf From rob at robmela.com Wed Oct 31 21:59:08 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 31 Oct 2007 21:59:08 -0400 Subject: [Nitro] Useful parts Message-ID: <472932EC.4080001@robmela.com> What would be the most useful generic parts, aside from the admin part, to have in a 0.50 distribution? The admin part is an essential component, but there are others that would serve both as examples and as useful building blocks to speed anyone's first project with Nitro. Candidates, to my mind, would be Parts: - User management, possible a homologue to Rails' RBAC ( Role Based Access Control ) - Wiki and Blog components - Arne's Flickr thingy Elements: - Tag cloud - Breadcrumb trail Others? -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071031/c5b795d5/attachment.vcf