From eduardorochabr at gmail.com Mon Jan 2 01:16:52 2006 From: eduardorochabr at gmail.com (Eduardo Rocha) Date: Mon, 2 Jan 2006 04:16:52 -0200 Subject: [Nitro] Memory Store Message-ID: I have installed Og 0.26 (via rubygems), and I have seen memory.rb file in alpha directory, so I guess is not ready yet, is that right? Also, in examples/README it points to mock_example.rb, which does not exists. Which alternatives are there for mocking the database? The easiest setup I could find is using KirbyBase, is there an even easier (only memory for example)? []'s Eduardo From rainhead at gmail.com Mon Jan 2 01:31:40 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Sun, 1 Jan 2006 22:31:40 -0800 Subject: [Nitro] Last patch breaks Og.setup Message-ID: <6C3F3744-56A0-44C0-9FA0-36B5C15CB6A6@gmail.com> George's last patch, 20051230113524 ("More Rdocs and small fixes here and there...") breaks Og.setup for very simple examples. George, did you run the tests? The following script did not work until I unpulled the last patch: >>> foo.rb #!/usr/bin/env ruby $DBG = true require '../nitro-clean/glycerin' require 'nitro' require 'og' include Nitro Og.setup( :store => :mysql, :name => 'cal', :user => 'nitro', :password => '2op1lot3') Nitro.run <<< Gives: D, [2006-01-01T22:30:52.344027 #31738] DEBUG -- : Using memory sessions. I, [2006-01-01T22:30:52.631521 #31738] INFO -- : Og uses the Mysql store. E, [2006-01-01T22:30:52.632242 #31738] ERROR -- : Og.setup had problems: TypeError => can't convert Symbol into String E, [2006-01-01T22:30:52.632613 #31738] ERROR -- : # E, [2006-01-01T22:30:52.632903 #31738] ERROR -- : /home/peidran/nitro- clean/og/lib/og/store.rb:23:in `+' /home/peidran/nitro-clean/og/lib/og/store.rb:23:in `for_name' /home/peidran/nitro-clean/og/lib/og/manager.rb:46:in `initialize' /home/peidran/nitro-clean/og/lib/og.rb:120:in `setup' foo.rb:10 P -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060102/234bd06f/attachment.bin From aidan at yoyo.org Mon Jan 2 04:16:59 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 2 Jan 2006 20:16:59 +1100 Subject: [Nitro] 1.0? Message-ID: <8166B99D-301A-42F7-8B67-7CEA373228CB@yoyo.org> Has the feature set for Nitro 1.0 been defined yet? If so, where might I read it? If not, why not? Regards, Aidan From kashia at vfemail.net Mon Jan 2 09:28:55 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 02 Jan 2006 15:28:55 +0100 Subject: [Nitro] Last patch breaks Og.setup In-Reply-To: <6C3F3744-56A0-44C0-9FA0-36B5C15CB6A6@gmail.com> References: <6C3F3744-56A0-44C0-9FA0-36B5C15CB6A6@gmail.com> Message-ID: yah, he removed a evil eval and broke some stuff then, just make line 23/24 look like: require('og/store/' + name.to_s) return Og::const_get("#{name.to_s.capitalize}Store") Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Jan 2 11:05:51 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 2 Jan 2006 18:05:51 +0200 Subject: [Nitro] Happy new year! Message-ID: Happy new year to everyone on this list ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 2 11:07:32 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 2 Jan 2006 18:07:32 +0200 Subject: [Nitro] Memory Store In-Reply-To: References: Message-ID: > Which alternatives are there for mocking the database? The easiest > setup I could find is using KirbyBase, is there an even easier (only > memory for example)? Have a look at lib/og/test you can use cvs/yaml fixtures for this... regards, George. > > []'s > Eduardo > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Mon Jan 2 13:23:57 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 02 Jan 2006 11:23:57 -0700 Subject: [Nitro] Happy new year! In-Reply-To: References: Message-ID: <43B96FBD.2090202@neurogami.com> George Moschovitis wrote: > Happy new year to everyone on this list ;-) Thanks, and ditto! James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From Aleksi.Niemela at cs.helsinki.fi Mon Jan 2 14:54:18 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Mon, 02 Jan 2006 21:54:18 +0200 Subject: [Nitro] Patch management Message-ID: <43B984EA.8030001@cs.helsinki.fi> I've heard there might be patches that are not accepted into Glycerin. I'd like to see few things happen: 1) In case George has looked at patches but doesn't accept for whatever reason (and that's his right) it would be nice if the reasons are made explicit. If some more work is needed to get the patch accepted, saying that would be most important. If there're ideological or other reasons making those public would provide sense of direction for the rest of devs. I propose all Patch talk is kept in this same Nitro mailing list but message subjects would be prefixed with "PATCH:". In time, I hope, the patch traffic will grow to annoying level and dedicated mailing list should be spawned. I hope no message containing a Patch won't go unanswered. Simple "committed" or "won't make into glue per http://www.nitrohq.com/view/ArchitecturalGuidelines" shouldn't be too much. Discussions might emerge for accepted and not-accepted patches. 2) All the patches would be public. Those shouldn't be sent only to George but for example to aforementioned public mailing list or they could be placed into separate directory at nitrohq for rest of Devs to fetch and work upon. One could go forward with public patches and more maintainers might show up naturally. In case George is busy sometime another maintainer could prepare glycerin "upgrade" bundle by accepting dozens of patches and testing those. George would then have an easy job to put that one bigger bundle in official glycerin. I guess this kind "parallel development" is one of the great ideas Darcs should enable. ---- I have no standing patches, I guess, so these points don't touch me personally, but I could imagine any dev could get frustrated if sending patches feels like throwing them into (mostly friendly) black hole. - Aleksi From rainhead at gmail.com Mon Jan 2 15:23:56 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Mon, 2 Jan 2006 12:23:56 -0800 Subject: [Nitro] Patch management In-Reply-To: <43B984EA.8030001@cs.helsinki.fi> References: <43B984EA.8030001@cs.helsinki.fi> Message-ID: Aleksi, Thanks for your message. I haven't had trouble with my patches disappear, although sometimes it's taken a while to get a response or see them committed, and I've wondered if they did disappear. Regardless, I think publishing patches and opening them up to general discussion is a very good idea. If patches are sent to the list, given the wonderful distributed nature of darcs, other users could apply e.g. an emergency patch without waiting for it to be approved and committed. Transparency and bookkeeping are also very important, and something that Nitro could use a good bit more of. I don't feel like it's a trust issue so much as an incomplete transition from being a private project to a public one. Publishing patches is one step in the right direction; a real bug tracker a la trac is another one. We don't have the resources to build our own tracker. We need one yesterday. If this would happen faster with some help from a sysadmin, that is my area of expertise. There are many documents besides traditional documentation that we desperately need in order to collaborate on documentation. Principally, these are: a development road map, a style guide, and a "map" of nitro's functions. George, you're in the best position to write these documents. If you need help editing, or if it would be helpful to be supplied with questions to guide your writing, let me/ us know. My $0.03 (inflation, donchya know) P On Jan 2, 2006, at 11:54 AM, Aleksi Niemela wrote: > I've heard there might be patches that are not accepted into Glycerin. > I'd like to see few things happen: > > 1) In case George has looked at patches but doesn't accept for > whatever > reason (and that's his right) it would be nice if the reasons are made > explicit. If some more work is needed to get the patch accepted, > saying > that would be most important. If there're ideological or other reasons > making those public would provide sense of direction for the rest > of devs. > > I propose all Patch talk is kept in this same Nitro mailing list but > message subjects would be prefixed with "PATCH:". In time, I hope, the > patch traffic will grow to annoying level and dedicated mailing list > should be spawned. > > I hope no message containing a Patch won't go unanswered. Simple > "committed" or "won't make into glue per > http://www.nitrohq.com/view/ArchitecturalGuidelines" shouldn't be too > much. Discussions might emerge for accepted and not-accepted patches. > > 2) All the patches would be public. Those shouldn't be sent only to > George but for example to aforementioned public mailing list or they > could be placed into separate directory at nitrohq for rest of Devs to > fetch and work upon. > > One could go forward with public patches and more maintainers might > show > up naturally. In case George is busy sometime another maintainer could > prepare glycerin "upgrade" bundle by accepting dozens of patches and > testing those. George would then have an easy job to put that one > bigger > bundle in official glycerin. > > I guess this kind "parallel development" is one of the great ideas > Darcs > should enable. > > ---- > > I have no standing patches, I guess, so these points don't touch me > personally, but I could imagine any dev could get frustrated if > sending > patches feels like throwing them into (mostly friendly) black hole. > > - Aleksi > > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060102/d26ff0b7/attachment.bin From aidan at yoyo.org Mon Jan 2 16:56:56 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Tue, 3 Jan 2006 08:56:56 +1100 Subject: [Nitro] test - please delete Message-ID: Sorry - my last message got to the list without a body - this is a test to see if the body arrived this time. Please delete this message. From aidan at yoyo.org Mon Jan 2 17:08:47 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Tue, 3 Jan 2006 09:08:47 +1100 Subject: [Nitro] Nitro 1.0 Message-ID: <663B9354-8A6B-469D-A1C1-854F5D8BBB93@yoyo.org> Hi all, My last attempt at posting this resulted in a blank message - let's try again :-) Has the feature set for Nitro 1.0 been defined yet? If so, where might I read it? If not, why not? Regards, Aidan From james_b at neurogami.com Mon Jan 2 19:07:51 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 02 Jan 2006 17:07:51 -0700 Subject: [Nitro] Nitro 1.0 In-Reply-To: <663B9354-8A6B-469D-A1C1-854F5D8BBB93@yoyo.org> References: <663B9354-8A6B-469D-A1C1-854F5D8BBB93@yoyo.org> Message-ID: <43B9C057.2060902@neurogami.com> Aidan Rogers wrote: > Hi all, > > My last attempt at posting this resulted in a blank message - let's > try again :-) Odd. I saw the message the first time. > > Has the feature set for Nitro 1.0 been defined yet? If so, where > might I read it? If not, why not? Probably too soon. It's often a mistake to plan all sorts of features; better to start small and evolve what makes sense as you go. I believe that's what George has been doing. I gripe about it because it breaks my code, but I think that in the end you get something better than if you had attempted to define the target right from the start. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From timh at dirtymonday.net Tue Jan 3 01:18:38 2006 From: timh at dirtymonday.net (TimH) Date: Mon, 2 Jan 2006 22:18:38 -0800 Subject: [Nitro] newer postgres interface snapshots Message-ID: <20060102221838.07ab6951.timh@dirtymonday.net> Postgresql interface snapshots starting at about November 21 will fail with the psql store. The biggest issue I have run accross is that columns returned are now converted to appropriate ruby objects (Date, boolean, etc...). This has prevented me from running Spark with recent snapshots. I've made a note in the WIki as well. Just FYI. --TimH From bryan.a.soto at gmail.com Tue Jan 3 02:52:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 2 Jan 2006 23:52:26 -0800 Subject: [Nitro] Patch management In-Reply-To: References: <43B984EA.8030001@cs.helsinki.fi> Message-ID: Hi Aleksi and Peter, I don't know either of you and perhaps public patches and discussion would help that :) Another benefit would be to identify common areas of interest for collaboration. As it stands, most people who submit patches are developing in isolation probably duplicating effort. As a silly example, how many people submitted a patch for the recent Store.for_name bug? I did ;) This would also cut down on the number of patches and help them not be missed. And yes, patches will be missed. George is only human, after all :) Plus, it would be a good way for new(er) people, I include myself in this group, to ease into things. I'd also like to add to Peter's list of docs that perhaps a proposed feature list for upcoming releases might be helpful? It seems to me that it would give people a concrete task as an entry point. I will finish off by saying, Aleksi, thank you for hosting the glycerin rdocs on your website. I believe the next gem will build the rdocs on install, so that will be a good thing. Peter, I'm not sure if you're aware, or perhaps it just doesn't meet your definition of "a real bug tracker", but there is one available on the Nitro Rubyforge site. I don't think that it's monitored though. Bryan On 1/2/06, Peter Abrahamsen wrote: > > Aleksi, > > Thanks for your message. I haven't had trouble with my patches > disappear, although sometimes it's taken a while to get a response or > see them committed, and I've wondered if they did disappear. > Regardless, I think publishing patches and opening them up to general > discussion is a very good idea. If patches are sent to the list, > given the wonderful distributed nature of darcs, other users could > apply e.g. an emergency patch without waiting for it to be approved > and committed. > > Transparency and bookkeeping are also very important, and something > that Nitro could use a good bit more of. I don't feel like it's a > trust issue so much as an incomplete transition from being a private > project to a public one. > > Publishing patches is one step in the right direction; a real bug > tracker a la trac is another one. We don't have the resources to > build our own tracker. We need one yesterday. If this would happen > faster with some help from a sysadmin, that is my area of expertise. > > There are many documents besides traditional documentation that we > desperately need in order to collaborate on documentation. > Principally, these are: a development road map, a style guide, and a > "map" of nitro's functions. George, you're in the best position to > write these documents. If you need help editing, or if it would be > helpful to be supplied with questions to guide your writing, let me/ > us know. > > My $0.03 (inflation, donchya know) > > P > > On Jan 2, 2006, at 11:54 AM, Aleksi Niemela wrote: > > > I've heard there might be patches that are not accepted into Glycerin. > > I'd like to see few things happen: > > > > 1) In case George has looked at patches but doesn't accept for > > whatever > > reason (and that's his right) it would be nice if the reasons are made > > explicit. If some more work is needed to get the patch accepted, > > saying > > that would be most important. If there're ideological or other reasons > > making those public would provide sense of direction for the rest > > of devs. > > > > I propose all Patch talk is kept in this same Nitro mailing list but > > message subjects would be prefixed with "PATCH:". In time, I hope, the > > patch traffic will grow to annoying level and dedicated mailing list > > should be spawned. > > > > I hope no message containing a Patch won't go unanswered. Simple > > "committed" or "won't make into glue per > > http://www.nitrohq.com/view/ArchitecturalGuidelines"shouldn't be too > > much. Discussions might emerge for accepted and not-accepted patches. > > > > 2) All the patches would be public. Those shouldn't be sent only to > > George but for example to aforementioned public mailing list or they > > could be placed into separate directory at nitrohq for rest of Devs to > > fetch and work upon. > > > > One could go forward with public patches and more maintainers might > > show > > up naturally. In case George is busy sometime another maintainer could > > prepare glycerin "upgrade" bundle by accepting dozens of patches and > > testing those. George would then have an easy job to put that one > > bigger > > bundle in official glycerin. > > > > I guess this kind "parallel development" is one of the great ideas > > Darcs > > should enable. > > > > ---- > > > > I have no standing patches, I guess, so these points don't touch me > > personally, but I could imagine any dev could get frustrated if > > sending > > patches feels like throwing them into (mostly friendly) black hole. > > > > - Aleksi > > > > _______________________________________________ > > 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/20060103/55a44c48/attachment.html From bryan.a.soto at gmail.com Tue Jan 3 03:21:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 3 Jan 2006 00:21:10 -0800 Subject: [Nitro] PATCH: kirby_evolve_schema Message-ID: Attached adds schema evolution to KirbyBase store. Og.setup flags are, as other stores, :evolve_schema and :evolve_schema_cautious. The beginnings of join tables are there as well, but don't work. They are created properly, but error when you actually try to use them in code. The problem specifically seems to be in KirbyBase#query. Og tries to use the query string generated for the join to create a code block for Kirby to actually do the selection. If you're interested in working on it, the join table creation code is at the end of KirbyBase#create_table commented out. -b -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060103/4fd75f25/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_kirby_evolve_schema Type: application/octet-stream Size: 7550 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/4fd75f25/attachment.obj From george.moschovitis at gmail.com Tue Jan 3 04:21:57 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 3 Jan 2006 11:21:57 +0200 Subject: [Nitro] Nitro 1.0 In-Reply-To: <663B9354-8A6B-469D-A1C1-854F5D8BBB93@yoyo.org> References: <663B9354-8A6B-469D-A1C1-854F5D8BBB93@yoyo.org> Message-ID: We are almost there ;-) I plan to make Nitro 1.0 feature complete during January. More details in a later post... -g. On 1/3/06, Aidan Rogers wrote: > Hi all, > > My last attempt at posting this resulted in a blank message - let's > try again :-) > > Has the feature set for Nitro 1.0 been defined yet? If so, where > might I read it? If not, why not? > > Regards, > > Aidan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 3 04:27:25 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 3 Jan 2006 11:27:25 +0200 Subject: [Nitro] Patch management In-Reply-To: <43B984EA.8030001@cs.helsinki.fi> References: <43B984EA.8030001@cs.helsinki.fi> Message-ID: Aleksi, I totally agree with this. I would like to ask everyone that sends patches to send them publicly to this list (with a PATCH: ....) title. Moreover, I would like to give admin rights to the repository to at least one more person. We should discuss this over the following days... -g. PS: I generally accept most patches, but sometimes it takes a bit longer... On 1/2/06, Aleksi Niemela wrote: > I've heard there might be patches that are not accepted into Glycerin. > I'd like to see few things happen: > > 1) In case George has looked at patches but doesn't accept for whatever > reason (and that's his right) it would be nice if the reasons are made > explicit. If some more work is needed to get the patch accepted, saying > that would be most important. If there're ideological or other reasons > making those public would provide sense of direction for the rest of devs. > > I propose all Patch talk is kept in this same Nitro mailing list but > message subjects would be prefixed with "PATCH:". In time, I hope, the > patch traffic will grow to annoying level and dedicated mailing list > should be spawned. > > I hope no message containing a Patch won't go unanswered. Simple > "committed" or "won't make into glue per > http://www.nitrohq.com/view/ArchitecturalGuidelines" shouldn't be too > much. Discussions might emerge for accepted and not-accepted patches. > > 2) All the patches would be public. Those shouldn't be sent only to > George but for example to aforementioned public mailing list or they > could be placed into separate directory at nitrohq for rest of Devs to > fetch and work upon. > > One could go forward with public patches and more maintainers might show > up naturally. In case George is busy sometime another maintainer could > prepare glycerin "upgrade" bundle by accepting dozens of patches and > testing those. George would then have an easy job to put that one bigger > bundle in official glycerin. > > I guess this kind "parallel development" is one of the great ideas Darcs > should enable. > > ---- > > I have no standing patches, I guess, so these points don't touch me > personally, but I could imagine any dev could get frustrated if sending > patches feels like throwing them into (mostly friendly) black hole. > > - Aleksi > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 3 04:30:36 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 3 Jan 2006 11:30:36 +0200 Subject: [Nitro] PATCH: kirby_evolve_schema In-Reply-To: References: Message-ID: thanks, will investigate! -g. On 1/3/06, Bryan Soto wrote: > Attached adds schema evolution to KirbyBase store. Og.setup flags are, as > other stores, :evolve_schema and :evolve_schema_cautious. > > The beginnings of join tables are there as well, but don't work. They are > created properly, but error when you actually try to use them in code. > > The problem specifically seems to be in KirbyBase#query. Og tries to use the > query string generated for the join to create a code block for Kirby to > actually do the selection. > > If you're interested in working on it, the join table creation code is at > the end of KirbyBase#create_table commented out. > > -b > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 3 05:32:21 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 3 Jan 2006 12:32:21 +0200 Subject: [Nitro] Default dir structure Message-ID: Dear devs, I would like to hear your opinion on the default (suggested) dir structure of Nitro. At the moment it goes like this: run.rb src src/template/* src/controller.rb src/model.rb ... public public/js/* ... log/* What do you think about this one: run.rb controller.rb model.rb template/* public/* log/* Or perhaps you have a better idea? -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From thoraval.yvon at free.fr Tue Jan 3 06:07:31 2006 From: thoraval.yvon at free.fr (Yvon Thoraval) Date: Tue, 3 Jan 2006 12:07:31 +0100 Subject: [Nitro] Default dir structure In-Reply-To: References: Message-ID: Le 3 janv. 06 ? 11:32, George Moschovitis a ?crit : > What do you think about this one: > > run.rb > controller.rb > model.rb > template/* > public/* > log/* i do agree, their is no needs of a subdir src... Yvon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060103/83664a1c/attachment.html From george.moschovitis at gmail.com Tue Jan 3 06:11:46 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 3 Jan 2006 13:11:46 +0200 Subject: [Nitro] Default dir structure In-Reply-To: References: Message-ID: BTw, I mean the USERS application dir. And this is only the suggested dir. Unlike Rails you can use any dir structure you need for Nitro applications. -g. On 1/3/06, Yvon Thoraval wrote: > > > Le 3 janv. 06 ? 11:32, George Moschovitis a ?crit : > > > What do you think about this one: > > > > > run.rb > > controller.rb > > model.rb > > template/* > > public/* > > log/* > > > i do agree, their is no needs of a subdir src... > > > Yvon > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rainhead at gmail.com Tue Jan 3 15:23:07 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Tue, 3 Jan 2006 12:23:07 -0800 Subject: [Nitro] Default dir structure In-Reply-To: References: Message-ID: <450FA4A1-1EE0-4130-A1AD-F4209C2238DB@gmail.com> I like that. Maybe a doc/, or empty README file? P On Jan 3, 2006, at 2:32 AM, George Moschovitis wrote: > What do you think about this one: > > run.rb > controller.rb > model.rb > template/* > public/* > log/* -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/204382ef/attachment.bin From m.fellinger at gmail.com Tue Jan 3 16:23:56 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Tue, 3 Jan 2006 22:23:56 +0100 Subject: [Nitro] Default dir structure In-Reply-To: References: Message-ID: <9c00d3e00601031323v50e8eb95o@mail.gmail.com> I'm not against it, wonder if that lowers the barrier of understandingan nitro-app for newcomers...In every case i'd like to know what you'll do to the public/js/* one:) (stupid question i know, but i wanted to mention it) ~~~~manveru 2006/1/3, George Moschovitis :> Dear devs,>> I would like to hear your opinion on the default (suggested) dir> structure of Nitro.> At the moment it goes like this:>> run.rb> src> src/template/*> src/controller.rb> src/model.rb> ...> public> public/js/*> ...> log/*>> What do you think about this one:>> run.rb> controller.rb> model.rb> template/*> public/*> log/*>> Or perhaps you have a better idea?>> -g.>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From rainhead at gmail.com Tue Jan 3 18:51:45 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Tue, 3 Jan 2006 15:51:45 -0800 Subject: [Nitro] PATCH: (2) template escape backslashes & RELEASES rdoc fix Message-ID: <79CCD5F0-C311-4520-8285-75158E49AEA8@gmail.com> I sent these to George a few days ago, but sending here as per the new procedure. The first one makes sure \'s in templates aren't eaten by Template processing. The second one makes rdoc work again by fixing some syntax in the nitro/doc/RELEASES file. -------------- next part -------------- A non-text attachment was scrubbed... Name: releases-rdoc-fix.gz Type: application/x-gzip Size: 1916 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/45c01b6e/attachment.gz -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: template-escape.gz Type: application/x-gzip Size: 1734 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/45c01b6e/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/45c01b6e/attachment.bin From bryan.a.soto at gmail.com Tue Jan 3 20:26:30 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 3 Jan 2006 17:26:30 -0800 Subject: [Nitro] PATCH: (2) template escape backslashes & RELEASES rdoc fix In-Reply-To: <79CCD5F0-C311-4520-8285-75158E49AEA8@gmail.com> References: <79CCD5F0-C311-4520-8285-75158E49AEA8@gmail.com> Message-ID: Hi, I tried out the template-escape patch against an app and got the following: home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:110:in `module_eval': (eval):37:in `module_eval': compile error (SyntaxError) (eval):24: unknown regexp options - all (eval):24: syntax error Show editable ^ (eval):24: syntax error Show editable ^ (eval):29: syntax error ^; end ; @out << %^ ^ (eval):36: syntax error from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:110:in `define_controller_action' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:160:in `scaffold_controller' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:123:in `scaffold' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:306:in `compile_scaffolding_code' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:305:in `compile_scaffolding_code' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/controller.rb:161:in `mounted' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:89:in `mount' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:68:in `mount' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:42:in `initialize' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server.rb:89:in `start' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server.rb:121:in `run' from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro.rb:73:in `run' from run.rb:31 Attached run.rb should help you duplicate if you're interested in reproducing the error. Substitute #{glycerin} as appropriate. RUBYOPT=-rubygems ruby -I#{glycerin}/glue/lib:#{glycerin}/nitro/lib:#{glycerin}nitro/src:#{glycerin}/og/lib run.rb Just be sure to include nitro/src in the include path for part/admin. I'll try to look into it tonight if someone doesn't beat me to it. :) Bryan On 1/3/06, Peter Abrahamsen wrote: > > I sent these to George a few days ago, but sending here as per the > new procedure. > > The first one makes sure \'s in templates aren't eaten by Template > processing. The second one makes rdoc work again by fixing some > syntax in the nitro/doc/RELEASES file. > > > > > > > _______________________________________________ > 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/20060103/ffc7e79f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: run.rb Type: application/octet-stream Size: 159 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060103/ffc7e79f/attachment.obj From bryan.a.soto at gmail.com Wed Jan 4 02:34:19 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 3 Jan 2006 23:34:19 -0800 Subject: [Nitro] PATCH: (2) template escape backslashes & RELEASES rdoc fix In-Reply-To: References: <79CCD5F0-C311-4520-8285-75158E49AEA8@gmail.com> Message-ID: #{glycerin}/nitro/proto/public/scaffold/edit.xhtml:5 The line is: Show editable The patch is basically converting "/\/all$/" into "/\\/all$/" quoting the backslash used as a quoting character thus causing the syntax error. At the very least, it's a new test case. I'm not quite sure what to do about it though... On 1/3/06, Bryan Soto wrote: > > Hi, > > I tried out the template-escape patch against an app and got the > following: > > home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:110:in > `module_eval': > (eval):37:in `module_eval': compile error (SyntaxError) > (eval):24: unknown regexp options - all > (eval):24: syntax error > Show editable > ^ > (eval):24: syntax error > Show editable > ^ > (eval):29: syntax error > ^; end ; @out << %^ > ^ > (eval):36: syntax error from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:110:in > `define_controller_action' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:160:in > `scaffold_controller' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:123:in > `scaffold' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:306:in > `compile_scaffolding_code' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/scaffolding.rb:305:in > `compile_scaffolding_code' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/controller.rb:161:in > `mounted' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:89:in > `mount' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:68:in > `mount' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/dispatcher.rb:42:in > `initialize' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server.rb:89:in `start' > from > /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server.rb:121:in `run' > from /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro.rb:73:in > `run' > from run.rb:31 > > Attached run.rb should help you duplicate if you're interested in > reproducing the error. > > Substitute #{glycerin} as appropriate. > > RUBYOPT=-rubygems ruby > -I#{glycerin}/glue/lib:#{glycerin}/nitro/lib:#{glycerin}nitro/src:#{glycerin}/og/lib > run.rb > > Just be sure to include nitro/src in the include path for part/admin. > > I'll try to look into it tonight if someone doesn't beat me to it. :) > > Bryan > > > On 1/3/06, Peter Abrahamsen wrote: > > > I sent these to George a few days ago, but sending here as per the > > new procedure. > > > > The first one makes sure \'s in templates aren't eaten by Template > > processing. The second one makes rdoc work again by fixing some > > syntax in the nitro/doc/RELEASES file. > > > > > > > > > > > > > > _______________________________________________ > > 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/20060104/703f1601/attachment.html From george.moschovitis at gmail.com Wed Jan 4 03:29:45 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 Jan 2006 10:29:45 +0200 Subject: [Nitro] Default dir structure In-Reply-To: <9c00d3e00601031323v50e8eb95o@mail.gmail.com> References: <9c00d3e00601031323v50e8eb95o@mail.gmail.com> Message-ID: public/js/* On 1/3/06, Michael Fellinger wrote: > I'm not against it, wonder if that lowers the barrier of understandingan nitro-app for newcomers...In every case i'd like to know what you'll do to the public/js/* one:) (stupid question i know, but i wanted to mention it) > ~~~~manveru > 2006/1/3, George Moschovitis :> Dear devs,>> I would like to hear your opinion on the default (suggested) dir> structure of Nitro.> At the moment it goes like this:>> run.rb> src> src/template/*> src/controller.rb> src/model.rb> ...> public> public/js/* will stay as it is ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rainhead at gmail.com Wed Jan 4 04:48:44 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Wed, 4 Jan 2006 01:48:44 -0800 Subject: [Nitro] PATCH: (2) template escape backslashes & RELEASES rdoc fix In-Reply-To: References: <79CCD5F0-C311-4520-8285-75158E49AEA8@gmail.com> Message-ID: <79B31B5C-D086-4F95-8120-E2FF4ECBE48D@gmail.com> Right, ok. Sorry to all for posting so clearly broken a patch. I've been pouring over the pickaxe (which doesn't seem to mention the %^ delimiter), and staring at the screen for a while, but I still don't quite get what's going on. This stuff drives me batty. George? Given that you already (theoretically) know how this stuff works, can you point the way? Here's an updated set of tests. I moved some length calls out of the template text (duh), and added the case you suggested. Careful incase some part of this mail system wrapped some lines. >>> def test_escapes # Don't treat backslashes specially. out = '' Template.process('foo\nbar', :out, binding) assert_equal(8, out.length, "Backslashes in template text are being treated as escapes.") # Don't escape newlines out = '' Template.process("foo\nbar", :out, binding) assert_equal(7, out.length, "Literal newlines in template text are being escaped.") out = '' Template.process(%q{#{len}}, :out, binding) assert_equal(8, out.length, "Newline escapes in inline ruby are being treated incorrectly.") out = '' Template.process(%q{#{'foo\nbar'}}, :out, binding) assert_equal(8, out.length, "Newline escapes in interpolated ruby expressions are being treated incorrectly.") out = '' assert_nothing_raised("Backslashes escaped where they shouldn't be") { Template.process(%q{#{'foo/bar'.gsub(/\/bar$/, '')}}, :out, binding) } end <<< On Jan 3, 2006, at 11:34 PM, Bryan Soto wrote: > #{glycerin}/nitro/proto/public/scaffold/edit.xhtml:5 > > The line is: Show > editable > > The patch is basically converting "/\/all$/" into "/\\/all$/" > quoting the backslash used as a quoting character thus causing the > syntax error. > > At the very least, it's a new test case. I'm not quite sure what to > do about it though... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060104/9abe9cd9/attachment.bin From rainhead at gmail.com Wed Jan 4 05:12:52 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Wed, 4 Jan 2006 02:12:52 -0800 Subject: [Nitro] 1.0? In-Reply-To: <8166B99D-301A-42F7-8B67-7CEA373228CB@yoyo.org> References: <8166B99D-301A-42F7-8B67-7CEA373228CB@yoyo.org> Message-ID: <60308BF8-CE9C-47F4-840D-18DF60686101@gmail.com> Someone just posted a mock Todo list for 1.0. FWIW, I agree with the gist of it, if not all the items. http://www.nitrohq.com/view/TodoForOneOu (which should probably read TodoForOneOh) P On Jan 2, 2006, at 1:16 AM, Aidan Rogers wrote: > Has the feature set for Nitro 1.0 been defined yet? If so, where > might I read it? If not, why not? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060104/a733ea7c/attachment.bin From kashia at vfemail.net Wed Jan 4 12:47:51 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 04 Jan 2006 18:47:51 +0100 Subject: [Nitro] [PATCH] Small TableHelper cleanup Message-ID: Hi, sent this to George only first. This renames a few variables and fixes a small harmless bug you wouldn't even notice if you'd just use the helper as you'd supposed to be... Anyway, cleanup is always good :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Wed Jan 4 12:50:11 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 04 Jan 2006 18:50:11 +0100 Subject: [Nitro] [PATCH] Small TableHelper cleanup In-Reply-To: References: Message-ID: well.. I better include the patch itself.. bugger :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: helper_table_cleanup.tar.bz2 Type: application/bzip2 Size: 1679 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060104/93d6abc2/attachment.bin From rob at motionpath.com Wed Jan 4 14:09:45 2006 From: rob at motionpath.com (rob) Date: Wed, 4 Jan 2006 19:09:45 +0000 Subject: [Nitro] newer postgres interface snapshots In-Reply-To: <20060102221838.07ab6951.timh@dirtymonday.net> References: <20060102221838.07ab6951.timh@dirtymonday.net> Message-ID: <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> If nobody else looks into this I will do so later on in the month. I am quite surprised at this as we have a number of applications that have dates, boolean, etc with the psql store and one of my co-workers was fairly recently using spark with PostgreSQL. Can this problem be reproduced now simply by running Spark? On 3 Jan 2006, at 06:18, TimH wrote: > Postgresql interface snapshots starting at about November 21 will > fail with the psql store. The biggest issue I have run accross is > that columns returned are now converted to appropriate ruby objects > (Date, boolean, etc...). This has prevented me from running Spark > with recent snapshots. I've made a note in the WIki as well. > > Just FYI. > > --TimH > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From timh at dirtymonday.net Wed Jan 4 14:17:03 2006 From: timh at dirtymonday.net (Tim Howe) Date: Wed, 4 Jan 2006 11:17:03 -0800 Subject: [Nitro] newer postgres interface snapshots In-Reply-To: <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> References: <20060102221838.07ab6951.timh@dirtymonday.net> <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> Message-ID: <20060104111703.1021c30f.timh@dirtymonday.net> On Wed, 4 Jan 2006 19:09:45 +0000 rob wrote: > If nobody else looks into this I will do so later on in the month. I > am quite surprised at this as we have a number of applications that > have dates, boolean, etc with the psql store and one of my co-workers > was fairly recently using spark with PostgreSQL. Can this problem be > reproduced now simply by running Spark? Yes. I even installed an entirely new Ruby installation, new gems, new Nitro 0.26, and new Spark 0.8.0. I then installed the latest Pg interface snap, and got the same errors. Then I installed the old Pg interface 0.7.1 release and everything worked fine. Snapshots beginning in late November should start to see these problems. Below is a quote from an email I got on Nov. 21st from Dave lee, the ruby postgres maintainer: I just wanted to get the word out that I have been working on a new release (0.8) and have created a couple snapshot releases over the last few days. There are some bug fixes, as well as new features such as better connect methods (takes connection string or connection hash), the exec and query methods now support optional bind parameters (using postgresql native bind params, $1, $2, etc), the rows returned by query are now a subclass of Array that provides hash-like features (including indexing by column name and a to_hash method), and also the data returned by queries is now converted to the appropriate ruby type in the simple cases, like integers, floats, booleans, and bytea. --TimH From rob at motionpath.com Wed Jan 4 14:56:29 2006 From: rob at motionpath.com (rob) Date: Wed, 4 Jan 2006 19:56:29 +0000 Subject: [Nitro] Default dir structure In-Reply-To: References: Message-ID: <27FDDEE0-F428-415B-893C-8F70D5CBC018@motionpath.com> It is good to retain the flexibility to choose different directory structures as peoples tastes and conceptions vary and some projects are naturally more complex than others and thus require greater division into categories to make them manageable. The /src directory could go in most cases but I have played and end up putting it back after a while as I prefer the additional level of visual segmentation for all but mini projects. For what it's worth our projects often start out similar to this (which would definitely be cluttered rather than useful for a smaller project): /conf/* /conf/main.yml # sample configuration file for use by application /conf/debug.rb /conf/stage.rb /log/* /public/css/* /public/js/prototype.js # the well known handy javascript library /public/js/* /public/images/* /public/* /run.rb /scripts/generate_rdoc.rb # i do not expect most people would want this /scripts/* /src/models/* /src/views/* /src/views/main/index.xhtml # bare-bones template /src/views/main/* /src/controllers/main.rb # bare-bones controller /src/controllers/* /src/elements/* /src/elements/generic.rb # bare-bones element /src/lib/* My opinion is that the user should be given a multiple-choice with each template assigned as being suitable for a different sized (small,medium,large,etc) as one consideration and the users like or dislike of folders as another consideration. Other things the generator should do is offer the user multiple choices about which store to use (creates the conf files), how things such as the compiler pipeline car constructed and if Nitro is to be included into the default namespace. Extra swish touches could be options to include a shebang in run.rb, say between "/where/is/bin/env ruby" and "/where/is/bin/ruby" I have a rudimentary implementation of this that we use to start our own projects but do not think it would be generally useful as it is heavily tied-in to our own systems and is console interactive only. Something I have considered is that it would be fun although a little time consuming to construct a GTK toolkit that allows you to draw our your nitro application with controllers, models, etc linked visually and a skeleton source code is produced for you. While this is unlikely to happen, a Nitro application with selector boxes (or javascript widgets but then you may have well as used GTK) that allow you to visually do the same. If someone is has time on their hands, there is a great project for you! Create a visual construction kit for the innovative and intelligent ruby web development framework. We would even need a new acronym RRAD (rocket-rapid application development/really rapid application development) perhaps. Or better yet, NRAD - Nitro-Rapid application development.... - rp On 3 Jan 2006, at 11:11, George Moschovitis wrote: > BTw, > > I mean the USERS application dir. And this is only the suggested dir. > Unlike Rails you can use any dir structure you need for Nitro > applications. > > -g. > > On 1/3/06, Yvon Thoraval wrote: >> >> >> Le 3 janv. 06 ? 11:32, George Moschovitis a ?crit : >> >> >> What do you think about this one: >> >> >> >> >> run.rb >> >> controller.rb >> >> model.rb >> >> template/* >> >> public/* >> >> log/* >> >> >> i do agree, their is no needs of a subdir src... >> >> >> Yvon >> >> >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Wed Jan 4 15:06:41 2006 From: rob at motionpath.com (rob) Date: Wed, 4 Jan 2006 20:06:41 +0000 Subject: [Nitro] newer postgres interface snapshots In-Reply-To: <20060104111703.1021c30f.timh@dirtymonday.net> References: <20060102221838.07ab6951.timh@dirtymonday.net> <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> <20060104111703.1021c30f.timh@dirtymonday.net> Message-ID: <51943115-9A2A-40B1-B1E7-DA4A54B0B671@motionpath.com> What versions of PostgreSQL have you observed this with? If it is a fairly recent version of PostgresSQL or caused by one of the small number of routines I added to the postgres adapter for use by Og (such as an analog to the MySQL adapters list_tables) I will still look at it before the end of the month even if it is the postgres adapter and not Nitro. On 4 Jan 2006, at 19:17, Tim Howe wrote: > On Wed, 4 Jan 2006 19:09:45 +0000 > rob wrote: > >> If nobody else looks into this I will do so later on in the month. I >> am quite surprised at this as we have a number of applications that >> have dates, boolean, etc with the psql store and one of my co-workers >> was fairly recently using spark with PostgreSQL. Can this problem be >> reproduced now simply by running Spark? > > Yes. I even installed an entirely new Ruby installation, new > gems, new Nitro 0.26, and new Spark 0.8.0. I then installed the > latest Pg interface snap, and got the same errors. Then I > installed the old Pg interface 0.7.1 release and everything worked > fine. Snapshots beginning in late November should start to see > these problems. Below is a quote from an email I got on Nov. 21st > from Dave lee, the ruby postgres maintainer: > > > I just wanted to get the word out that I have been working on a new > release (0.8) and have created a couple snapshot releases over the > last few days. There are some bug fixes, as well as new features such > as better connect methods (takes connection string or connection > hash), the exec and query methods now support optional bind parameters > (using postgresql native bind params, $1, $2, etc), the rows returned > by query are now a subclass of Array that provides hash-like features > (including indexing by column name and a to_hash method), and also the > data returned by queries is now converted to the appropriate ruby type > in the simple cases, like integers, floats, booleans, and bytea. > > > --TimH > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Wed Jan 4 15:14:51 2006 From: rob at motionpath.com (rob) Date: Wed, 4 Jan 2006 20:14:51 +0000 Subject: [Nitro] Optimized Autoreloading In-Reply-To: <20051230091805.534BB8F4322@taurus.navel.gr> References: <20051230091805.534BB8F4322@taurus.navel.gr> Message-ID: <83522B80-788B-4F97-A2C5-C4447E4CA21B@motionpath.com> Thanks Tim, this is a great feature. On 30 Dec 2005, at 09:18, gm at navel.gr wrote: > We have the following extra patches: > Will apply the following patches: > Fri Dec 30 11:24:19 EET 2005 George Moschovitis > * Bug fixed and optimized new reloader. Since the optimization is > so efficient autoreloading is enabled for live (production) sites > by default. > diffing dir... > Applying patches to the local directories... > diffing dir... > Finished applying... > _______________________________________________ > Nitro-repository mailing list > Nitro-repository at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-repository From timh at dirtymonday.net Wed Jan 4 15:57:11 2006 From: timh at dirtymonday.net (Tim Howe) Date: Wed, 4 Jan 2006 12:57:11 -0800 Subject: [Nitro] newer postgres interface snapshots In-Reply-To: <51943115-9A2A-40B1-B1E7-DA4A54B0B671@motionpath.com> References: <20060102221838.07ab6951.timh@dirtymonday.net> <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> <20060104111703.1021c30f.timh@dirtymonday.net> <51943115-9A2A-40B1-B1E7-DA4A54B0B671@motionpath.com> Message-ID: <20060104125711.2b0e85bd.timh@dirtymonday.net> On Wed, 4 Jan 2006 20:06:41 +0000 rob wrote: > What versions of PostgreSQL have you observed this with? If it is a > fairly recent version of PostgresSQL or caused by one of the small > number of routines I added to the postgres adapter for use by Og > (such as an analog to the MySQL adapters list_tables) I will still > look at it before the end of the month even if it is the postgres > adapter and not Nitro. The version of Pg won't matter , but that system is running 8.1.1. --TimH From rainhead at gmail.com Wed Jan 4 16:15:19 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Wed, 4 Jan 2006 13:15:19 -0800 Subject: [Nitro] Default dir structure In-Reply-To: <27FDDEE0-F428-415B-893C-8F70D5CBC018@motionpath.com> References: <27FDDEE0-F428-415B-893C-8F70D5CBC018@motionpath.com> Message-ID: <51F3826F-4D41-4972-8BCC-5528299F54F2@gmail.com> Rob, That's a cool idea, and could be a boon to the project if done well. Documentation's probably more important, though :) P On Jan 4, 2006, at 11:56 AM, rob wrote: > It is good to retain the flexibility to choose different directory > structures as peoples tastes and conceptions vary and some projects > are naturally more complex than others and thus require greater > division into categories to make them manageable. The /src directory > could go in most cases but I have played and end up putting it back > after a while as I prefer the additional level of visual segmentation > for all but mini projects. For what it's worth our projects often > start out similar to this (which would definitely be cluttered rather > than useful for a smaller project): > > /conf/* > /conf/main.yml # sample configuration file for use by application > /conf/debug.rb > /conf/stage.rb > /log/* > /public/css/* > /public/js/prototype.js # the well known handy javascript library > /public/js/* > /public/images/* > /public/* > /run.rb > /scripts/generate_rdoc.rb # i do not expect most people would want > this > /scripts/* > /src/models/* > /src/views/* > /src/views/main/index.xhtml # bare-bones template > /src/views/main/* > /src/controllers/main.rb # bare-bones controller > /src/controllers/* > /src/elements/* > /src/elements/generic.rb # bare-bones element > /src/lib/* > > My opinion is that the user should be given a multiple-choice with > each template assigned as being suitable for a different sized > (small,medium,large,etc) as one consideration and the users like or > dislike of folders as another consideration. Other things the > generator should do is offer the user multiple choices about which > store to use (creates the conf files), how things such as the > compiler pipeline car constructed and if Nitro is to be included into > the default namespace. Extra swish touches could be options to > include a shebang in run.rb, say between "/where/is/bin/env ruby" and > "/where/is/bin/ruby" I have a rudimentary implementation of this that > we use to start our own projects but do not think it would be > generally useful as it is heavily tied-in to our own systems and is > console interactive only. Something I have considered is that it > would be fun although a little time consuming to construct a GTK > toolkit that allows you to draw our your nitro application with > controllers, models, etc linked visually and a skeleton source code > is produced for you. While this is unlikely to happen, a Nitro > application with selector boxes (or javascript widgets but then you > may have well as used GTK) that allow you to visually do the same. If > someone is has time on their hands, there is a great project for you! > Create a visual construction kit for the innovative and intelligent > ruby web development framework. We would even need a new acronym RRAD > (rocket-rapid application development/really rapid application > development) perhaps. Or better yet, NRAD - Nitro-Rapid application > development.... > > - rp > > On 3 Jan 2006, at 11:11, George Moschovitis wrote: > >> BTw, >> >> I mean the USERS application dir. And this is only the suggested dir. >> Unlike Rails you can use any dir structure you need for Nitro >> applications. >> >> -g. >> >> On 1/3/06, Yvon Thoraval wrote: >>> >>> >>> Le 3 janv. 06 ? 11:32, George Moschovitis a ?crit : >>> >>> >>> What do you think about this one: >>> >>> >>> >>> >>> run.rb >>> >>> controller.rb >>> >>> model.rb >>> >>> template/* >>> >>> public/* >>> >>> log/* >>> >>> >>> i do agree, their is no needs of a subdir src... >>> >>> >>> Yvon >>> >>> >>> >>> _______________________________________________ >>> Nitro-general mailing list >>> Nitro-general at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/nitro-general >>> >>> >>> >> >> >> -- >> http://www.gmosx.com >> http://www.navel.gr >> http://www.nitrohq.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: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060104/64bd2c5b/attachment.bin From bryan.a.soto at gmail.com Wed Jan 4 17:01:22 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 4 Jan 2006 14:01:22 -0800 Subject: [Nitro] Default dir structure In-Reply-To: <51F3826F-4D41-4972-8BCC-5528299F54F2@gmail.com> References: <27FDDEE0-F428-415B-893C-8F70D5CBC018@motionpath.com> <51F3826F-4D41-4972-8BCC-5528299F54F2@gmail.com> Message-ID: But if NRAD were completed and generated all the source code, there'd be no need to document anything! It's a win all around! ;) It is a cool idea, and I think someone is actually working along similar lines for Rails. A snippet from the user's guide: "Eventually you'll realize that AppTrain is just a simple Web front end for creating applications that run on the Rails framework." See http://apptrain.rubyforge.org/apptrain_users_guide.html for more info. It's nowhere near Rob's vision yet though. :) More seriously, Rob is correct in that the generator could do a bit more than it does (and would need to for NRAD to work). Has anyone run across any items that could be automatically generated? Rob mentioned: * Multiple versions of application layout * Generating config files, i.e. Og.setup * Compiler pipeline * Pollute the application level namespace with Nitro's internals (No, really, I'm not biased ;) * Fix shebang lines As to the original question, my preferred layout is almost a subset of Rob's. I also like src/views but, rather than src/elements, I use src/tags. I personally like the src directory and I think for new users, it's visually distinctive. You have a single ruby file in the top level, so you know that's your entry point and if you want to go poking around, the src directory is the conventional place to store the app's source code. Just my $0.03 (I wasn't aware of the inflation Peter mentioned, but it's in a mailing list so it must be true :) b On 1/4/06, Peter Abrahamsen wrote: > > Rob, > > That's a cool idea, and could be a boon to the project if done well. > Documentation's probably more important, though :) > > P > > On Jan 4, 2006, at 11:56 AM, rob wrote: > > > It is good to retain the flexibility to choose different directory > > structures as peoples tastes and conceptions vary and some projects > > are naturally more complex than others and thus require greater > > division into categories to make them manageable. The /src directory > > could go in most cases but I have played and end up putting it back > > after a while as I prefer the additional level of visual segmentation > > for all but mini projects. For what it's worth our projects often > > start out similar to this (which would definitely be cluttered rather > > than useful for a smaller project): > > > > /conf/* > > /conf/main.yml # sample configuration file for use by application > > /conf/debug.rb > > /conf/stage.rb > > /log/* > > /public/css/* > > /public/js/prototype.js # the well known handy javascript library > > /public/js/* > > /public/images/* > > /public/* > > /run.rb > > /scripts/generate_rdoc.rb # i do not expect most people would want > > this > > /scripts/* > > /src/models/* > > /src/views/* > > /src/views/main/index.xhtml # bare-bones template > > /src/views/main/* > > /src/controllers/main.rb # bare-bones controller > > /src/controllers/* > > /src/elements/* > > /src/elements/generic.rb # bare-bones element > > /src/lib/* > > > > My opinion is that the user should be given a multiple-choice with > > each template assigned as being suitable for a different sized > > (small,medium,large,etc) as one consideration and the users like or > > dislike of folders as another consideration. Other things the > > generator should do is offer the user multiple choices about which > > store to use (creates the conf files), how things such as the > > compiler pipeline car constructed and if Nitro is to be included into > > the default namespace. Extra swish touches could be options to > > include a shebang in run.rb, say between "/where/is/bin/env ruby" and > > "/where/is/bin/ruby" I have a rudimentary implementation of this that > > we use to start our own projects but do not think it would be > > generally useful as it is heavily tied-in to our own systems and is > > console interactive only. Something I have considered is that it > > would be fun although a little time consuming to construct a GTK > > toolkit that allows you to draw our your nitro application with > > controllers, models, etc linked visually and a skeleton source code > > is produced for you. While this is unlikely to happen, a Nitro > > application with selector boxes (or javascript widgets but then you > > may have well as used GTK) that allow you to visually do the same. If > > someone is has time on their hands, there is a great project for you! > > Create a visual construction kit for the innovative and intelligent > > ruby web development framework. We would even need a new acronym RRAD > > (rocket-rapid application development/really rapid application > > development) perhaps. Or better yet, NRAD - Nitro-Rapid application > > development.... > > > > - rp > > > > On 3 Jan 2006, at 11:11, George Moschovitis wrote: > > > >> BTw, > >> > >> I mean the USERS application dir. And this is only the suggested dir. > >> Unlike Rails you can use any dir structure you need for Nitro > >> applications. > >> > >> -g. > >> > >> On 1/3/06, Yvon Thoraval wrote: > >>> > >>> > >>> Le 3 janv. 06 ? 11:32, George Moschovitis a ?crit : > >>> > >>> > >>> What do you think about this one: > >>> > >>> > >>> > >>> > >>> run.rb > >>> > >>> controller.rb > >>> > >>> model.rb > >>> > >>> template/* > >>> > >>> public/* > >>> > >>> log/* > >>> > >>> > >>> i do agree, their is no needs of a subdir src... > >>> > >>> > >>> Yvon > >>> > >>> > >>> > >>> _______________________________________________ > >>> Nitro-general mailing list > >>> Nitro-general at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/nitro-general > >>> > >>> > >>> > >> > >> > >> -- > >> http://www.gmosx.com > >> http://www.navel.gr > >> http://www.nitrohq.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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060104/32eb9f53/attachment.html From rainhead at gmail.com Wed Jan 4 19:28:38 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Wed, 4 Jan 2006 16:28:38 -0800 Subject: [Nitro] Default dir structure In-Reply-To: References: <27FDDEE0-F428-415B-893C-8F70D5CBC018@motionpath.com> <51F3826F-4D41-4972-8BCC-5528299F54F2@gmail.com> Message-ID: <33A1CE1C-ADAB-4A43-8DB6-1BD8832F9762@gmail.com> Sure: * the reverse-engineering stuff if we're keeping that around, and load from db dump * apache/lighttpd/scgi integration (*KEY*) Are we thinking this'll be a strictly one-time process to set up the initial environment? P On Jan 4, 2006, at 2:01 PM, Bryan Soto wrote: > Has anyone run across any items that could be automatically generated? > > Rob mentioned: > * Multiple versions of application layout > * Generating config files, i.e. Og.setup > * Compiler pipeline > * Pollute the application level namespace with Nitro's internals > (No, really, I'm not biased ;) > * Fix shebang lines -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060104/1d9ac1f6/attachment.bin From chris at motionpath.com Thu Jan 5 13:24:13 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Thu, 5 Jan 2006 18:24:13 +0000 Subject: [Nitro] PATCH: Multipart forms and @params, Some Controls code updates. Message-ID: Happy 2006 list!... Haven't quiet got round to getting up to speed with the list -99 nitro emails was my christmas present from the list ;-) sure it's all great! anyway. here's some patches: Mostly control code related, (and there'll be more to follow including a blob upload control), started an array control. Fixed the multipart form data issues not being compatible with the @params hash, I think I also made the params array operate like someone on the list wanted (request['this.that'] and request['this'] ['that'] should both work - will maybe move this functionality to the request [] method if everyone things that the @params hash looks a mess. --next step is to make the structure_params function recursive so that more complicated depth can be achieved with the POST data ie. INPUTS with names: name="person.name" name="person.address.name" name="person.address.line1" name="person.address.line2" name="person.address.phone[]" name="person.address.phone[]" creating the @params (request) hash as { 'person' => { 'address' => { 'name' => 'string', 'line1' => 'string', 'line2' => 'string', 'phone' => ['string','string'] } } } right. home time. ? chrisfarms Design & Development. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060105/29ff5e6a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro.patch.gz Type: application/x-gzip Size: 14894 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060105/29ff5e6a/attachment.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060105/29ff5e6a/attachment-0001.html From bryan.a.soto at gmail.com Thu Jan 5 18:11:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 5 Jan 2006 15:11:10 -0800 Subject: [Nitro] PATCH: Multipart forms and @params, Some Controls code updates. In-Reply-To: References: Message-ID: Just a quick note, after applying this patch there was an additional failure in the nitro unit tests: 3) Failure: test_parse_query_parameters(TestAdapterCgi) [./test/nitro/tc_cgi.rb:36]: <2> expected but was <3>. On 1/5/06, Chris Farmiloe wrote: > > > > Happy 2006 list!... > > Haven't quiet got round to getting up to speed with the list > -99 nitro emails was my christmas present from the list ;-) > sure it's all great! > > anyway. here's some patches: > > Mostly control code related, (and there'll be more to follow including > a blob upload control), started an array control. > > > Fixed the multipart form data issues not being compatible with > the @params hash, I think I also made the params array operate like > someone on the list wanted (request['this.that'] and > request['this']['that'] > should both work - will maybe move this functionality to the request [] > method > if everyone things that the @params hash looks a mess. > > --next step is to make the structure_params function recursive so that > more complicated depth can be achieved with the POST data ie. INPUTS with > names: > > name="person.name" > name="person.address.name" > name="person.address.line1" > name="person.address.line2" > name="person.address.phone[]" > name="person.address.phone[]" > > creating the @params (request) hash as > > { > 'person' => { > 'address' => { > 'name' => 'string', > 'line1' => 'string', > 'line2' => 'string', > 'phone' => ['string','string'] > } > } > } > > > > right. home time. > > > > > > > > > > chrisfarms > Design & Development. > > > > > _______________________________________________ > 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/20060105/d5ca3c92/attachment.html From bryan.a.soto at gmail.com Thu Jan 5 20:27:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 5 Jan 2006 17:27:21 -0800 Subject: [Nitro] PATCH: Multipart forms and @params, Some Controls code updates. In-Reply-To: References: Message-ID: Hi, On a personal note, I find I'm understanding a bit more how Nitro works with your and Peter's submissions (I haven't gotten to Kashia's yet :) That said, I ran into a problem with it I can't quite figure out. The attached run.rb (set to sqlite, but mysql or postgres should work. Not kirby since it uses many_to_many) causes this error when: 1) Run against glycerin: RUBYOPT=-rubygems ruby -I#{glycerin}/glue/lib -I#{glycerin}/nitro/lib -I#{glycerin}/nitro/src -I#{glycerin}/og/lib run.rb 2) From /admin create a user. 3) Leave permissions set to None 4) Save. It's something in the patch as it doesn't happen against unpatched glycerin, but I can't quite figure out where. Adding a breakpoint to glue/property.rb:123 shows v is an empty StringIO. primary_keys.each do |v| # require 'dev-utils/debug'; breakpoint next if v == 'nil' or v == 'none' collection << rel.target_class[v.to_s.to_i] end I hope this helps someone figure out what exactly is happening. E, [2006-01-05T16:21:25.985566 #4529] ERROR -- : Error while handling '/admin/users/save'. E, [2006-01-05T16:21:26.002286 #4529] ERROR -- : undefined method `unsaved?' for nil:NilClass (eval):25:in `add_permission' /home/bryan/checkout/darcs/dev-nitro/og/lib/og/collection.rb:123:in `<<' /home/bryan/checkout/darcs/dev-nitro/glue/lib/glue/property.rb:124:in `populate_object' /home/bryan/checkout/darcs/dev-nitro/glue/lib/glue/property.rb:122:in `populate_object' /home/bryan/checkout/darcs/dev-nitro/glue/lib/glue/property.rb:95:in `populate_object' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/context.rb:100:in `fill' (eval):9:in `users__save' (eval):6:in `users__save_action' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/render.rb:127:in `render' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/adapter/webrick.rb:151:in `do_POST' /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib/ruby/1.8/webrick/server.rb:82:in `start' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/adapter/webrick.rb:55:in `start' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server/runner.rb:307:in `invoke_server' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server/runner.rb:273:in `invoke' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro/server.rb:123:in `run' /home/bryan/checkout/darcs/dev-nitro/nitro/lib/nitro.rb:73:in `start' run.rb:22 On 1/5/06, Bryan Soto wrote: > > Just a quick note, after applying this patch there was an additional > failure in the nitro unit tests: > > 3) Failure: > test_parse_query_parameters(TestAdapterCgi) [./test/nitro/tc_cgi.rb:36]: > <2> expected but was > <3>. > > On 1/5/06, Chris Farmiloe wrote: > > > > > > > Happy 2006 list!... > > > > Haven't quiet got round to getting up to speed with the list > > -99 nitro emails was my christmas present from the list ;-) > > sure it's all great! > > > > anyway. here's some patches: > > > > Mostly control code related, (and there'll be more to follow including > > a blob upload control), started an array control. > > > > > > Fixed the multipart form data issues not being compatible with > > the @params hash, I think I also made the params array operate like > > someone on the list wanted (request[' this.that'] and > > request['this']['that'] > > should both work - will maybe move this functionality to the request [] > > method > > if everyone things that the @params hash looks a mess. > > > > --next step is to make the structure_params function recursive so that > > more complicated depth can be achieved with the POST data ie. INPUTS > > with names: > > > > name=" person.name" > > name="person.address.name" > > name="person.address.line1 " > > name="person.address.line2" > > name="person.address.phone[]" > > name="person.address.phone[]" > > > > creating the @params (request) hash as > > > > { > > 'person' => { > > 'address' => { > > 'name' => 'string', > > 'line1' => 'string', > > 'line2' => 'string', > > 'phone' => ['string','string'] > > } > > } > > } > > > > > > > > right. home time. > > > > > > > > > > > > > > > > > > > > chrisfarms > > Design & Development. > > > > > > > > > > _______________________________________________ > > 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/20060105/680d1f11/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: run.rb Type: application/octet-stream Size: 296 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060105/680d1f11/attachment.obj From gwtmp01 at mac.com Thu Jan 5 22:37:54 2006 From: gwtmp01 at mac.com (Gary Wright) Date: Thu, 5 Jan 2006 22:37:54 -0500 Subject: [Nitro] Help for Og Beginner Message-ID: <8CA36263-907F-4118-B2EE-56270468E241@mac.com> I've volunteered to learn and then share information about Og with my local Ruby User's group next week. I've had a hard time finding a simple Og example that actually works. The standard tutorial says: WARNING: This tutorial refers to an older version of Og. Many new and exciting features were added in the meantime. Hopefuly this tutorial will be updated soon. There must be a simple working example of Og somewhere? I've got the gem installed and by looking at the API docs I guessed that I needed to do something like: db = Og::Store.create( :database => 'test', :adapter => 'mysql', :user => 'user', :password => 'password' ) to establish a database connection but that just gets me: undefined method `ogmanager' for Post:Class when I try to save an instance of Post. (p.save) The tutorial uses Og::Database, which is not defined. Notes: The default API link: http://www.nitrohq.com/rdoc/og/index.html fails with an error. The alternate site: http://www.cs.helsinki.fi/u/kaniemel/rdoc/og/ worked. The 0.26.0 gem for og doesn't seem to build/install the rdocs correctly. The Og FAQs are really just that: questions with no answers! I'm looking forward to playing with OG but I'd hoped to not have to read the source to do it. Can someone point me in the correct direction? I'm going to watch the videos later tonight... Gary Wright From bryan.a.soto at gmail.com Fri Jan 6 02:30:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 5 Jan 2006 23:30:58 -0800 Subject: [Nitro] Help for Og Beginner In-Reply-To: <8CA36263-907F-4118-B2EE-56270468E241@mac.com> References: <8CA36263-907F-4118-B2EE-56270468E241@mac.com> Message-ID: Hi Gary, Currently the best examples would be available at: http://rubyforge.org/frs/?group_id=418 Check out spark, flare and the examples archive. They're all combinations of Nitro and Og. Hopefully those will help. Also, db = Og.setup( # <= changed :database => 'test', :store => :mysql, # <= changed :user => 'user', :password => 'password' ) Depending on your setup, you might need to add :socket => /path/to/socket or :server => '127.0.0.1' The basic idea is that Og will "enchant" your classes. So, for example, if you were to make a database of members of your RUG, an Og model would be class Member property :full_name, String # String is default and can be omitted. property :skill_level, Fixnum property :email_address # Omitting the default validate_value :full_name # See http://www.cs.helsinki.fi/u/kaniemel/rdoc/glue/classes/Glue/Validation/ClassMethods.html#M000063 validate_numeric :skill_level validate_inclusion :skill_level, :in => 1..10 validate_unique :email_address # See http://www.cs.helsinki.fi/u/kaniemel/rdoc/og/classes/Glue/Validation/ClassMethods.html#M000705 end Then define your store: Og.setup( # <= changed :database => 'rug_members', :store => :mysql, # <= changed :user => 'user', :password => 'password' ) After which in code, member = Member.new member.full_name = 'Gary Wright' member.email_address = "gary's email" member.skill_level = 10 member.save If any of the validations were to fail, they'd be available via member.errors where the could be iterated over member.errors.errors.each do | field, msg| puts "#[field} had an error!: #{msg}" end Finding a single member via email address: Member.find_by_email_address('an email address') # => nil or selecting a group by skill level: Member.find_all_by_skill_leve(10) # => an array of members including Gary I hope that's enough to give you a start and to understand the examples, spark and flare. Currently though, this mailing list and irc, #nitro on freenode, are the best places for info. Hopefully that will change soon. At the very least, beginning with the next release, the rdoc should be built on install. Hope that helps and please don't hesitate to ask more questions. Bryan On 1/5/06, Gary Wright wrote: > > > I've volunteered to learn and then share information about Og with > my local > Ruby User's group next week. I've had a hard time finding a simple Og > example that actually works. The standard tutorial says: > > WARNING: This tutorial refers to an older version of Og. Many new > and > exciting features were added in the meantime. Hopefuly this > tutorial > will be updated soon. > > There must be a simple working example of Og somewhere? > > I've got the gem installed and by looking at the API docs I guessed that > I needed to do something like: > > db = Og::Store.create( > :database => 'test', > :adapter => 'mysql', > :user => 'user', > :password => 'password' > ) > > to establish a database connection but that just gets me: > > undefined method `ogmanager' for Post:Class > > when I try to save an instance of Post. (p.save) > > The tutorial uses Og::Database, which is not defined. > > Notes: > The default API link: http://www.nitrohq.com/rdoc/og/index.html > fails with an error. > The alternate site: http://www.cs.helsinki.fi/u/kaniemel/rdoc/og/ > worked. > The 0.26.0 gem for og doesn't seem to build/install the rdocs > correctly. > The Og FAQs are really just that: questions with no answers! > > I'm looking forward to playing with OG but I'd hoped to not have to > read the source to do it. > > Can someone point me in the correct direction? > > I'm going to watch the videos later tonight... > > Gary Wright > > > > > _______________________________________________ > 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/20060106/844c9db5/attachment.html From zimba.tm at gmail.com Fri Jan 6 03:21:33 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Fri, 06 Jan 2006 09:21:33 +0100 Subject: [Nitro] [PATCH] Controls patch + bugfix Message-ID: <43BE288D.9000208@gmail.com> Hi, this patch contains three different things * Implemented the + and - for Fixnum control * Added a password control class User property :password, String, :control => :password end * Corrected a small bug in part/admin avoiding the generation on the css. It was using RenderExit intead of Nitro::RenderExit Cheers, zimba.tm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bundle Url: http://rubyforge.org/pipermail/nitro-general/attachments/20060106/230b82e3/attachment.pl From rainhead at gmail.com Fri Jan 6 04:09:00 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Fri, 6 Jan 2006 01:09:00 -0800 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: <43BE288D.9000208@gmail.com> References: <43BE288D.9000208@gmail.com> Message-ID: Jonas, Thanks for your work. Would you mind sending future patches as attachments? Thanks! P On Jan 6, 2006, at 12:21 AM, Jonas Pfenniger wrote: > Hi, > > this patch contains three different things > > * Implemented the + and - for Fixnum control > * Added a password control > > class User > property :password, String, :control => :password > end > > * Corrected a small bug in part/admin avoiding the generation on the > css. It was using RenderExit intead of Nitro::RenderExit > > > Cheers, > zimba.tm > > New patches: > > [Implemented FixNum control's javascript > Jonas Pfenniger **20060105203222] { > hunk ./nitro/lib/nitro/helper/form/controls.rb 84 > - %{ + -} > + %{ onclick="e=document.getElementById('#{prop.symbol} > _ctl');e.value=parseInt(e.value)+1;return false;">+ onclick="e=document.getElementById('#{prop.symbol} > _ctl');e.value=parseInt(e.value)-1;return false;">-} > } > > [Added password control > Jonas Pfenniger **20060106081508] { > hunk ./nitro/lib/nitro/helper/form/controls.rb 109 > +# Password > + > +class PasswordControl < Control > + setting :style, :default => 'width: 250px', :doc => 'The default > style' > + > + def render > + %{} > + end > +end > + > hunk ./nitro/lib/nitro/helper/form/controls.rb 256 > + :password => PasswordControl, > } > > [Corrected small bug. part/admin was using RenderExit instead of > Nitro::RenderExit > Jonas Pfenniger **20060106081739] { > hunk ./nitro/src/part/admin/controller.rb 59 > - raise RenderExit > + raise Nitro::RenderExit > } > > Context: > > [More flexible elements, auto inject ElementMixin if needed, handle > elements in Nitro::Element namespace (safer), rdoc fixes. > George Moschovitis **20060105134500] > [Moved wee into helpers from adapter, some rdocs. > George Moschovitis **20060105111714] > [Add db dump/reload functionality, fixed some bugs too. > George Moschovitis **20060104164703] > [Charset setting for admin part. > George Moschovitis **20060104112006] > [Added support for WebFiles (ie file uploads) featuring imagemagick > integration, thumbnails etc. Based on OgFile. Still under > construction. Also added a new Gallery example to demonstrate this. > George Moschovitis **20060103173028] > [Added some template_root autodetection code, for more intelligent > Template.root defaults. > George Moschovitis **20060103105619] > [More rdoc stuff, og store fix. > George Moschovitis **20060103095522] > [fix_gen_executable > bryan.a.soto at gmail.com**20051227234324 > > Makes reap generate a gen executable. > > ] > [bugfix_scaffold > bryan.a.soto at gmail.com**20051230210508 > > Specifies Nitro namespace so scaffolding can correctly fill Og > objects if user didn't include Nitro namespace in his app. > > ] > [Better handling of errors on transactions. [timlarson] > George Moschovitis **20051230115326] > [More Rdocs and small fixes here and there... > George Moschovitis **20051230113524] > [Better handling of NoAction error. [tsume] > George Moschovitis **20051230110921] > [Updated ProjectInfo's to generate rdocs, added some more rdocs > comments here and there. > George Moschovitis **20051230102254] > [Bug fixed and optimized new reloader. Since the optimization is so > efficient autoreloading is enabled for live (production) sites by > default. > George Moschovitis **20051230092419] > [Implemented autoreload optimization (check for dirty). Much faster > development mode. [timlarson] > George Moschovitis **20051229163334] > [Even more CGI fixes. [james_b] > George Moschovitis **20051229142411] > [Some fixes to the Cgi infrastructure. > George Moschovitis **20051229134913] > [Removed obsolete files and directories. > George Moschovitis **20051229120449] > [Updated INSTALL docs. [tsume] > George Moschovitis **20051229115516] > [Added support for auto accumulation in Og collections + test case. > [epiperak] > George Moschovitis **20051229114008] > [Updated to scriptaculous 1.5.1 > George Moschovitis **20051229110226] > [Small fixes in Rakefiles. > George Moschovitis **20051229104414] > [Use the generic setup.rb method for non-gem installation. [tsume] > George Moschovitis **20051229102613] > [Script compiler fixes, builder fixes, bumped version. > George Moschovitis **20051228120643] > [The helper alos requires the file (temp implementation). > George Moschovitis **20051227122318] > [Show off builder in flickr example. > George Moschovitis **20051227122200] > [More great javascript improvements, auto_require needed javascript > files. > George Moschovitis **20051227120036] > [Draggable, AutoComplete, many improvements to the javascript helper. > George Moschovitis **20051227112821] > [Pass compiler to morphers, compiler.shared for compiler-stage > shared memory and more compiler improvement.s > George Moschovitis **20051227104444] > [Cleaned up flickr. > George Moschovitis **20051227102526] > [Refactored javascript helper. > George Moschovitis **20051227092450] > [Small beautifications to the flickr example. > George Moschovitis **20051227085606] > [Implemented INCREDIBLE scriptgenerator for dead easy dhtml/ajax > effects. Updated Flickr example. > George Moschovitis **20051223165640] > [Implemented client-side morphers. > George Moschovitis **20051223133402] > [Added new flickr example. > George Moschovitis **20051223133313] > [Small fixes. > George Moschovitis **20051223091512] > [Fix to the glue mailer so bcc and cc work > rob at motionpath.com**20051222185208] > [Add Nitro:: scope to Server in admin part > chrisfarms at gmail.com**20051222220806] > [Test cases need gems and facets > rob at motionpath.com**20051222124409] > [tc_nitro_controller_aspect > bryan.a.soto at gmail.com**20051221224659 > > Makes the test case pass. > > ] > [bugfix_remove_breakpoint > bryan.a.soto at gmail.com**20051221220552 > > Removes breakpoint call from test case. Was loading active_support > (Yes, Rails) from rake test runs. > > ] > [TAG 0.26.0 > George Moschovitis **20051223090149] > Patch bundle hash: > 37efb29f89448c234d6ff840ea2b91d0157360c6 > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060106/a22d1434/attachment.bin From george.moschovitis at gmail.com Fri Jan 6 06:10:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 6 Jan 2006 13:10:24 +0200 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: References: <43BE288D.9000208@gmail.com> Message-ID: Yeah, please resend this patch as a .gz/.zip attachment, gmail fucks up with the patch. thanks again ;-) -g. On 1/6/06, Peter Abrahamsen wrote: > Jonas, > > Thanks for your work. Would you mind sending future patches as > attachments? > > Thanks! > > P > > On Jan 6, 2006, at 12:21 AM, Jonas Pfenniger wrote: > > > Hi, > > > > this patch contains three different things > > > > * Implemented the + and - for Fixnum control > > * Added a password control > > > > class User > > property :password, String, :control => :password > > end > > > > * Corrected a small bug in part/admin avoiding the generation on the > > css. It was using RenderExit intead of Nitro::RenderExit > > > > > > Cheers, > > zimba.tm > > > > New patches: > > > > [Implemented FixNum control's javascript > > Jonas Pfenniger **20060105203222] { > > hunk ./nitro/lib/nitro/helper/form/controls.rb 84 > > - %{ + -} > > + %{ > onclick="e=document.getElementById('#{prop.symbol} > > _ctl');e.value=parseInt(e.value)+1;return false;">+ > onclick="e=document.getElementById('#{prop.symbol} > > _ctl');e.value=parseInt(e.value)-1;return false;">-} > > } > > > > [Added password control > > Jonas Pfenniger **20060106081508] { > > hunk ./nitro/lib/nitro/helper/form/controls.rb 109 > > +# Password > > + > > +class PasswordControl < Control > > + setting :style, :default => 'width: 250px', :doc => 'The default > > style' > > + > > + def render > > + %{} > > + end > > +end > > + > > hunk ./nitro/lib/nitro/helper/form/controls.rb 256 > > + :password => PasswordControl, > > } > > > > [Corrected small bug. part/admin was using RenderExit instead of > > Nitro::RenderExit > > Jonas Pfenniger **20060106081739] { > > hunk ./nitro/src/part/admin/controller.rb 59 > > - raise RenderExit > > + raise Nitro::RenderExit > > } > > > > Context: > > > > [More flexible elements, auto inject ElementMixin if needed, handle > > elements in Nitro::Element namespace (safer), rdoc fixes. > > George Moschovitis **20060105134500] > > [Moved wee into helpers from adapter, some rdocs. > > George Moschovitis **20060105111714] > > [Add db dump/reload functionality, fixed some bugs too. > > George Moschovitis **20060104164703] > > [Charset setting for admin part. > > George Moschovitis **20060104112006] > > [Added support for WebFiles (ie file uploads) featuring imagemagick > > integration, thumbnails etc. Based on OgFile. Still under > > construction. Also added a new Gallery example to demonstrate this. > > George Moschovitis **20060103173028] > > [Added some template_root autodetection code, for more intelligent > > Template.root defaults. > > George Moschovitis **20060103105619] > > [More rdoc stuff, og store fix. > > George Moschovitis **20060103095522] > > [fix_gen_executable > > bryan.a.soto at gmail.com**20051227234324 > > > > Makes reap generate a gen executable. > > > > ] > > [bugfix_scaffold > > bryan.a.soto at gmail.com**20051230210508 > > > > Specifies Nitro namespace so scaffolding can correctly fill Og > > objects if user didn't include Nitro namespace in his app. > > > > ] > > [Better handling of errors on transactions. [timlarson] > > George Moschovitis **20051230115326] > > [More Rdocs and small fixes here and there... > > George Moschovitis **20051230113524] > > [Better handling of NoAction error. [tsume] > > George Moschovitis **20051230110921] > > [Updated ProjectInfo's to generate rdocs, added some more rdocs > > comments here and there. > > George Moschovitis **20051230102254] > > [Bug fixed and optimized new reloader. Since the optimization is so > > efficient autoreloading is enabled for live (production) sites by > > default. > > George Moschovitis **20051230092419] > > [Implemented autoreload optimization (check for dirty). Much faster > > development mode. [timlarson] > > George Moschovitis **20051229163334] > > [Even more CGI fixes. [james_b] > > George Moschovitis **20051229142411] > > [Some fixes to the Cgi infrastructure. > > George Moschovitis **20051229134913] > > [Removed obsolete files and directories. > > George Moschovitis **20051229120449] > > [Updated INSTALL docs. [tsume] > > George Moschovitis **20051229115516] > > [Added support for auto accumulation in Og collections + test case. > > [epiperak] > > George Moschovitis **20051229114008] > > [Updated to scriptaculous 1.5.1 > > George Moschovitis **20051229110226] > > [Small fixes in Rakefiles. > > George Moschovitis **20051229104414] > > [Use the generic setup.rb method for non-gem installation. [tsume] > > George Moschovitis **20051229102613] > > [Script compiler fixes, builder fixes, bumped version. > > George Moschovitis **20051228120643] > > [The helper alos requires the file (temp implementation). > > George Moschovitis **20051227122318] > > [Show off builder in flickr example. > > George Moschovitis **20051227122200] > > [More great javascript improvements, auto_require needed javascript > > files. > > George Moschovitis **20051227120036] > > [Draggable, AutoComplete, many improvements to the javascript helper. > > George Moschovitis **20051227112821] > > [Pass compiler to morphers, compiler.shared for compiler-stage > > shared memory and more compiler improvement.s > > George Moschovitis **20051227104444] > > [Cleaned up flickr. > > George Moschovitis **20051227102526] > > [Refactored javascript helper. > > George Moschovitis **20051227092450] > > [Small beautifications to the flickr example. > > George Moschovitis **20051227085606] > > [Implemented INCREDIBLE scriptgenerator for dead easy dhtml/ajax > > effects. Updated Flickr example. > > George Moschovitis **20051223165640] > > [Implemented client-side morphers. > > George Moschovitis **20051223133402] > > [Added new flickr example. > > George Moschovitis **20051223133313] > > [Small fixes. > > George Moschovitis **20051223091512] > > [Fix to the glue mailer so bcc and cc work > > rob at motionpath.com**20051222185208] > > [Add Nitro:: scope to Server in admin part > > chrisfarms at gmail.com**20051222220806] > > [Test cases need gems and facets > > rob at motionpath.com**20051222124409] > > [tc_nitro_controller_aspect > > bryan.a.soto at gmail.com**20051221224659 > > > > Makes the test case pass. > > > > ] > > [bugfix_remove_breakpoint > > bryan.a.soto at gmail.com**20051221220552 > > > > Removes breakpoint call from test case. Was loading active_support > > (Yes, Rails) from rake test runs. > > > > ] > > [TAG 0.26.0 > > George Moschovitis **20051223090149] > > Patch bundle hash: > > 37efb29f89448c234d6ff840ea2b91d0157360c6 > > _______________________________________________ > > 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://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Fri Jan 6 08:37:29 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Fri, 06 Jan 2006 14:37:29 +0100 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: References: <43BE288D.9000208@gmail.com> Message-ID: <43BE7299.7020000@gmail.com> Ok, didn't know this. Here it is :) George Moschovitis wrote: >Yeah, please resend this patch as a .gz/.zip attachment, gmail fucks >up with the patch. > >thanks again ;-) > >-g. > >On 1/6/06, Peter Abrahamsen wrote: > > >>Jonas, >> >>Thanks for your work. Would you mind sending future patches as >>attachments? >> >>Thanks! >> >>P >> >>On Jan 6, 2006, at 12:21 AM, Jonas Pfenniger wrote: >> >> >> >>>Hi, >>> >>>this patch contains three different things >>> >>>* Implemented the + and - for Fixnum control >>>* Added a password control >>> >>>class User >>> property :password, String, :control => :password >>>end >>> >>>* Corrected a small bug in part/admin avoiding the generation on the >>>css. It was using RenderExit intead of Nitro::RenderExit >>> >>> >>>Cheers, >>> zimba.tm >>> >>>New patches: >>> >>>[Implemented FixNum control's javascript >>>Jonas Pfenniger **20060105203222] { >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 84 >>>- %{ + -} >>>+ %{ >>onclick="e=document.getElementById('#{prop.symbol} >>>_ctl');e.value=parseInt(e.value)+1;return false;">+ >>onclick="e=document.getElementById('#{prop.symbol} >>>_ctl');e.value=parseInt(e.value)-1;return false;">-} >>>} >>> >>>[Added password control >>>Jonas Pfenniger **20060106081508] { >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 109 >>>+# Password >>>+ >>>+class PasswordControl < Control >>>+ setting :style, :default => 'width: 250px', :doc => 'The default >>>style' >>>+ >>>+ def render >>>+ %{} >>>+ end >>>+end >>>+ >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 256 >>>+ :password => PasswordControl, >>>} >>> >>>[Corrected small bug. part/admin was using RenderExit instead of >>>Nitro::RenderExit >>>Jonas Pfenniger **20060106081739] { >>>hunk ./nitro/src/part/admin/controller.rb 59 >>>- raise RenderExit >>>+ raise Nitro::RenderExit >>>} >>> >>>Context: >>> >>>[More flexible elements, auto inject ElementMixin if needed, handle >>>elements in Nitro::Element namespace (safer), rdoc fixes. >>>George Moschovitis **20060105134500] >>>[Moved wee into helpers from adapter, some rdocs. >>>George Moschovitis **20060105111714] >>>[Add db dump/reload functionality, fixed some bugs too. >>>George Moschovitis **20060104164703] >>>[Charset setting for admin part. >>>George Moschovitis **20060104112006] >>>[Added support for WebFiles (ie file uploads) featuring imagemagick >>>integration, thumbnails etc. Based on OgFile. Still under >>>construction. Also added a new Gallery example to demonstrate this. >>>George Moschovitis **20060103173028] >>>[Added some template_root autodetection code, for more intelligent >>>Template.root defaults. >>>George Moschovitis **20060103105619] >>>[More rdoc stuff, og store fix. >>>George Moschovitis **20060103095522] >>>[fix_gen_executable >>>bryan.a.soto at gmail.com**20051227234324 >>> >>> Makes reap generate a gen executable. >>> >>>] >>>[bugfix_scaffold >>>bryan.a.soto at gmail.com**20051230210508 >>> >>> Specifies Nitro namespace so scaffolding can correctly fill Og >>>objects if user didn't include Nitro namespace in his app. >>> >>>] >>>[Better handling of errors on transactions. [timlarson] >>>George Moschovitis **20051230115326] >>>[More Rdocs and small fixes here and there... >>>George Moschovitis **20051230113524] >>>[Better handling of NoAction error. [tsume] >>>George Moschovitis **20051230110921] >>>[Updated ProjectInfo's to generate rdocs, added some more rdocs >>>comments here and there. >>>George Moschovitis **20051230102254] >>>[Bug fixed and optimized new reloader. Since the optimization is so >>>efficient autoreloading is enabled for live (production) sites by >>>default. >>>George Moschovitis **20051230092419] >>>[Implemented autoreload optimization (check for dirty). Much faster >>>development mode. [timlarson] >>>George Moschovitis **20051229163334] >>>[Even more CGI fixes. [james_b] >>>George Moschovitis **20051229142411] >>>[Some fixes to the Cgi infrastructure. >>>George Moschovitis **20051229134913] >>>[Removed obsolete files and directories. >>>George Moschovitis **20051229120449] >>>[Updated INSTALL docs. [tsume] >>>George Moschovitis **20051229115516] >>>[Added support for auto accumulation in Og collections + test case. >>>[epiperak] >>>George Moschovitis **20051229114008] >>>[Updated to scriptaculous 1.5.1 >>>George Moschovitis **20051229110226] >>>[Small fixes in Rakefiles. >>>George Moschovitis **20051229104414] >>>[Use the generic setup.rb method for non-gem installation. [tsume] >>>George Moschovitis **20051229102613] >>>[Script compiler fixes, builder fixes, bumped version. >>>George Moschovitis **20051228120643] >>>[The helper alos requires the file (temp implementation). >>>George Moschovitis **20051227122318] >>>[Show off builder in flickr example. >>>George Moschovitis **20051227122200] >>>[More great javascript improvements, auto_require needed javascript >>>files. >>>George Moschovitis **20051227120036] >>>[Draggable, AutoComplete, many improvements to the javascript helper. >>>George Moschovitis **20051227112821] >>>[Pass compiler to morphers, compiler.shared for compiler-stage >>>shared memory and more compiler improvement.s >>>George Moschovitis **20051227104444] >>>[Cleaned up flickr. >>>George Moschovitis **20051227102526] >>>[Refactored javascript helper. >>>George Moschovitis **20051227092450] >>>[Small beautifications to the flickr example. >>>George Moschovitis **20051227085606] >>>[Implemented INCREDIBLE scriptgenerator for dead easy dhtml/ajax >>>effects. Updated Flickr example. >>>George Moschovitis **20051223165640] >>>[Implemented client-side morphers. >>>George Moschovitis **20051223133402] >>>[Added new flickr example. >>>George Moschovitis **20051223133313] >>>[Small fixes. >>>George Moschovitis **20051223091512] >>>[Fix to the glue mailer so bcc and cc work >>>rob at motionpath.com**20051222185208] >>>[Add Nitro:: scope to Server in admin part >>>chrisfarms at gmail.com**20051222220806] >>>[Test cases need gems and facets >>>rob at motionpath.com**20051222124409] >>>[tc_nitro_controller_aspect >>>bryan.a.soto at gmail.com**20051221224659 >>> >>> Makes the test case pass. >>> >>>] >>>[bugfix_remove_breakpoint >>>bryan.a.soto at gmail.com**20051221220552 >>> >>> Removes breakpoint call from test case. Was loading active_support >>>(Yes, Rails) from rake test runs. >>> >>>] >>>[TAG 0.26.0 >>>George Moschovitis **20051223090149] >>>Patch bundle hash: >>>37efb29f89448c234d6ff840ea2b91d0157360c6 >>>_______________________________________________ >>>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://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.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: bundle.tgz Type: application/x-gtar Size: 2309 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060106/76d9a102/attachment.gtar From aidan at yoyo.org Fri Jan 6 11:00:03 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Sat, 7 Jan 2006 03:00:03 +1100 Subject: [Nitro] BUG: Nitro dispatcher Message-ID: Hi all, I believe I've found a bug in the Nitro dispatcher. I've no idea where exactly, hence I can only report it here. To reproduce: Set up a controller with a method that takes two arguments, e.g.: def some_method(foo, bar) # do something here - irrelevant what it is end then in your browser go to http://localhost:9999/some_method/some_value/a.value.with.dots.in.it And nothing will happen. Assuming you are using WEBrick, as I am, you won't even get a log message that the web server even took the request. Can someone please verify this bug for me, and then someone even nicer please fix it? Thanks! Aidan From tim at keow.org Fri Jan 6 15:30:20 2006 From: tim at keow.org (Tim Larson) Date: Fri, 6 Jan 2006 20:30:20 +0000 Subject: [Nitro] transaction exception logging In-Reply-To: References: <20051223145329.GB23021@localhost> Message-ID: <20060106203019.GB20466@localhost> On Mon, Dec 26, 2005 at 12:31:55PM +0200, George Moschovitis wrote: > Ok, will consider this, any other opinions? > > -g. Thanks for the patch: Fri Dec 30 13:53:26 EET 2005 George Moschovitis * Better handling of errors on transactions. [timlarson] Would you consider adding "raise ex" after the rollback, for the reason mentioned below (for handling exceptions)? The application may (and mine does) want to have its own exception handling outside of the transaction, and this is currently blocked because the transaction swallows the exception, making it look like it never happened and losing any information contained in the exception. --Tim Larson > > On 12/23/05, Tim Larson wrote: > > In og/lib/og/store.rb "def transaction", why is there all > > that logging code present? It make it harder to find the > > error location than a simple rollback and re-raising of > > the exception would. Also it makes test case output for > > expected failures be unnecessarily verbose and redundant, > > and the lack of re-raising the exception makes it difficult > > to test when and if the right exceptions are being raised > > by the code being tested. > > > > I am recommending: > > > > def transaction(&block) > > begin > > start > > yield(self) > > commit > > rescue => ex > > #Logger.error 'Erro > > #Logger.error ex > > #Logger.error ex.ba > > rollback > > raise ex > > end > > end > > > > --Tim Larson From bryan.a.soto at gmail.com Fri Jan 6 16:25:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 6 Jan 2006 13:25:47 -0800 Subject: [Nitro] BUG: Nitro dispatcher In-Reply-To: References: Message-ID: Hi, Reproduced against gem and glycerin. The problem seems to be in the webrick adapter (at least I couldn't duplicate with FastCGI). For you, Aidan, attached is a patch to change it to handle periods. If you do use it, could you report back any problems you find? I'm honestly not sure why it's looking for periods in the url and ignoring them, so changing the behaviour might be a bad thing. But with the patch, your some_method is called. Also, I'm not sure what version you're running, so patching might fail. If so, it's simple enough to fix by hand. All you have to do is comment two lines. :) For anyone who might know why it's doing what it's doing, could you join in and educate us? I'm curious... Thanks, Bryan On 1/6/06, Aidan Rogers wrote: > > Hi all, > > I believe I've found a bug in the Nitro dispatcher. I've no idea > where exactly, hence I can only report it here. To reproduce: > > Set up a controller with a method that takes two arguments, e.g.: > > def some_method(foo, bar) > # do something here - irrelevant what it is > end > > then in your browser go to > > http://localhost:9999/some_method/some_value/a.value.with.dots.in.it > > And nothing will happen. Assuming you are using WEBrick, as I am, > you won't even get a log message that the web server even took the > request. Can someone please verify this bug for me, and then someone > even nicer please fix it? > > Thanks! > > Aidan > > _______________________________________________ > 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/20060106/328bad98/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: webrick_handle_periods.patch Type: text/x-patch Size: 679 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060106/328bad98/attachment.bin From bryan.a.soto at gmail.com Fri Jan 6 18:30:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 6 Jan 2006 15:30:58 -0800 Subject: [Nitro] PATCH: Outstanding as of Jan. 6, 2006 Message-ID: In the hopes of keeping people aware, here is a summary of outstanding patches. Format is: patch name: * Short summary of thread where Pending means no comments. If you've applied and tested, please speak up :) link for download of patch from Rubyforge. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kirby_evolve_schema: * George is investigating. http://rubyforge.org/pipermail/nitro-general/2006-January/002356.html template escape backslashes: * Problem with implementation, improperly escapes quoting backslashes. Request for help. http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html RELEASES rdoc fix: * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html Small TableHelper cleanup: * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002372.html Multipart forms and @params, Controls code updates: * Problem handling many_to_many relationships. http://rubyforge.org/pipermail/nitro-general/2006-January/002382.html Controls patch + bugfix: * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002390.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060106/f604c23f/attachment.html From bryan.a.soto at gmail.com Fri Jan 6 19:38:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 6 Jan 2006 16:38:10 -0800 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: <43BE7299.7020000@gmail.com> References: <43BE288D.9000208@gmail.com> <43BE7299.7020000@gmail.com> Message-ID: Hi Jonas, I like the password control, it's very cool. And you beat me to that Nitro::RenderExit that was bugging me ;) As a note for George, both this and Chris' patch implement the plus/minus button for fixnums, so if you use both, you'll have conflicts. Only difference I noticed was, when the fixnum field contained "TEST": Chris' patch: would consider this as 0, and increment or decrement. Jonas' patch: is stricter and converts this to nan (Not a number). Other than that, everything seems to work as advertised. :) Jonas, I wonder if I understand controls correctly. You specify controls for properties, via annotations or directly in the model, than you can use form_for to have Nitro just create the form for you rather than coding everything out in the view? Is that right? bryan On 1/6/06, Jonas Pfenniger wrote: > > Ok, didn't know this. > > Here it is :) > > George Moschovitis wrote: > > >Yeah, please resend this patch as a .gz/.zip attachment, gmail fucks > >up with the patch. > > > >thanks again ;-) > > > >-g. > > > >On 1/6/06, Peter Abrahamsen wrote: > > > > > >>Jonas, > >> > >>Thanks for your work. Would you mind sending future patches as > >>attachments? > >> > >>Thanks! > >> > >>P > >> > >>On Jan 6, 2006, at 12:21 AM, Jonas Pfenniger wrote: > >> > >> > >> > >>>Hi, > >>> > >>>this patch contains three different things > >>> > >>>* Implemented the + and - for Fixnum control > >>>* Added a password control > >>> > >>>class User > >>> property :password, String, :control => :password > >>>end > >>> > >>>* Corrected a small bug in part/admin avoiding the generation on the > >>>css. It was using RenderExit intead of Nitro::RenderExit > >>> > >>> > >>>Cheers, > >>> zimba.tm > >>> > >>>New patches: > >>> > >>>[Implemented FixNum control's javascript > >>>Jonas Pfenniger **20060105203222] { > >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 84 > >>>- %{ + -} > >>>+ %{ >>>onclick="e=document.getElementById('#{prop.symbol} > >>>_ctl');e.value=parseInt(e.value)+1;return false;">+ >>>onclick="e=document.getElementById('#{prop.symbol} > >>>_ctl');e.value=parseInt(e.value)-1;return false;">-} > >>>} > >>> > >>>[Added password control > >>>Jonas Pfenniger **20060106081508] { > >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 109 > >>>+# Password > >>>+ > >>>+class PasswordControl < Control > >>>+ setting :style, :default => 'width: 250px', :doc => 'The default > >>>style' > >>>+ > >>>+ def render > >>>+ %{} > >>>+ end > >>>+end > >>>+ > >>>hunk ./nitro/lib/nitro/helper/form/controls.rb 256 > >>>+ :password => PasswordControl, > >>>} > >>> > >>>[Corrected small bug. part/admin was using RenderExit instead of > >>>Nitro::RenderExit > >>>Jonas Pfenniger **20060106081739] { > >>>hunk ./nitro/src/part/admin/controller.rb 59 > >>>- raise RenderExit > >>>+ raise Nitro::RenderExit > >>>} > >>> > >>>Context: > >>> > >>>[More flexible elements, auto inject ElementMixin if needed, handle > >>>elements in Nitro::Element namespace (safer), rdoc fixes. > >>>George Moschovitis **20060105134500] > >>>[Moved wee into helpers from adapter, some rdocs. > >>>George Moschovitis **20060105111714] > >>>[Add db dump/reload functionality, fixed some bugs too. > >>>George Moschovitis **20060104164703] > >>>[Charset setting for admin part. > >>>George Moschovitis **20060104112006] > >>>[Added support for WebFiles (ie file uploads) featuring imagemagick > >>>integration, thumbnails etc. Based on OgFile. Still under > >>>construction. Also added a new Gallery example to demonstrate this. > >>>George Moschovitis **20060103173028] > >>>[Added some template_root autodetection code, for more intelligent > >>>Template.root defaults. > >>>George Moschovitis **20060103105619] > >>>[More rdoc stuff, og store fix. > >>>George Moschovitis **20060103095522] > >>>[fix_gen_executable > >>>bryan.a.soto at gmail.com**20051227234324 > >>> > >>> Makes reap generate a gen executable. > >>> > >>>] > >>>[bugfix_scaffold > >>>bryan.a.soto at gmail.com**20051230210508 > >>> > >>> Specifies Nitro namespace so scaffolding can correctly fill Og > >>>objects if user didn't include Nitro namespace in his app. > >>> > >>>] > >>>[Better handling of errors on transactions. [timlarson] > >>>George Moschovitis **20051230115326] > >>>[More Rdocs and small fixes here and there... > >>>George Moschovitis **20051230113524] > >>>[Better handling of NoAction error. [tsume] > >>>George Moschovitis **20051230110921] > >>>[Updated ProjectInfo's to generate rdocs, added some more rdocs > >>>comments here and there. > >>>George Moschovitis **20051230102254] > >>>[Bug fixed and optimized new reloader. Since the optimization is so > >>>efficient autoreloading is enabled for live (production) sites by > >>>default. > >>>George Moschovitis **20051230092419] > >>>[Implemented autoreload optimization (check for dirty). Much faster > >>>development mode. [timlarson] > >>>George Moschovitis **20051229163334] > >>>[Even more CGI fixes. [james_b] > >>>George Moschovitis **20051229142411] > >>>[Some fixes to the Cgi infrastructure. > >>>George Moschovitis **20051229134913] > >>>[Removed obsolete files and directories. > >>>George Moschovitis **20051229120449] > >>>[Updated INSTALL docs. [tsume] > >>>George Moschovitis **20051229115516] > >>>[Added support for auto accumulation in Og collections + test case. > >>>[epiperak] > >>>George Moschovitis **20051229114008] > >>>[Updated to scriptaculous 1.5.1 > >>>George Moschovitis **20051229110226] > >>>[Small fixes in Rakefiles. > >>>George Moschovitis **20051229104414] > >>>[Use the generic setup.rb method for non-gem installation. [tsume] > >>>George Moschovitis **20051229102613] > >>>[Script compiler fixes, builder fixes, bumped version. > >>>George Moschovitis **20051228120643] > >>>[The helper alos requires the file (temp implementation). > >>>George Moschovitis **20051227122318] > >>>[Show off builder in flickr example. > >>>George Moschovitis **20051227122200] > >>>[More great javascript improvements, auto_require needed javascript > >>>files. > >>>George Moschovitis **20051227120036] > >>>[Draggable, AutoComplete, many improvements to the javascript helper. > >>>George Moschovitis **20051227112821] > >>>[Pass compiler to morphers, compiler.shared for compiler-stage > >>>shared memory and more compiler improvement.s > >>>George Moschovitis **20051227104444] > >>>[Cleaned up flickr. > >>>George Moschovitis **20051227102526] > >>>[Refactored javascript helper. > >>>George Moschovitis **20051227092450] > >>>[Small beautifications to the flickr example. > >>>George Moschovitis **20051227085606] > >>>[Implemented INCREDIBLE scriptgenerator for dead easy dhtml/ajax > >>>effects. Updated Flickr example. > >>>George Moschovitis **20051223165640] > >>>[Implemented client-side morphers. > >>>George Moschovitis **20051223133402] > >>>[Added new flickr example. > >>>George Moschovitis **20051223133313] > >>>[Small fixes. > >>>George Moschovitis **20051223091512] > >>>[Fix to the glue mailer so bcc and cc work > >>>rob at motionpath.com**20051222185208] > >>>[Add Nitro:: scope to Server in admin part > >>>chrisfarms at gmail.com**20051222220806] > >>>[Test cases need gems and facets > >>>rob at motionpath.com**20051222124409] > >>>[tc_nitro_controller_aspect > >>>bryan.a.soto at gmail.com**20051221224659 > >>> > >>> Makes the test case pass. > >>> > >>>] > >>>[bugfix_remove_breakpoint > >>>bryan.a.soto at gmail.com**20051221220552 > >>> > >>> Removes breakpoint call from test case. Was loading active_support > >>>(Yes, Rails) from rake test runs. > >>> > >>>] > >>>[TAG 0.26.0 > >>>George Moschovitis **20051223090149] > >>>Patch bundle hash: > >>>37efb29f89448c234d6ff840ea2b91d0157360c6 > >>>_______________________________________________ > >>>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://www.gmosx.com > >http://www.navel.gr > >http://www.nitrohq.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 -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060106/1455b3df/attachment.html From james_b at neurogami.com Fri Jan 6 19:40:53 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 17:40:53 -0700 Subject: [Nitro] Nitro setting content type of application/xhtml+xml ? Message-ID: <43BF0E15.2090707@neurogami.com> In trying to figure out why I get CSS issues in a Nitro app, I found that the server is returning content-type: application/xhtml+xml which breaks IE and upsets the CSS rendering (it seems) in Firefox. Is this something Nitro might be doing? I've grepped the source but not found anything, but maybe the content-type is dynamically generated. Thanks, James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From james_b at neurogami.com Fri Jan 6 20:28:12 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 18:28:12 -0700 Subject: [Nitro] Ruby syntax coloring on Nitro wiki Message-ID: <43BF192C.1000003@neurogami.com> Sorry if this has been mentioned before, but I'm looking through the nitrhq pages for help on Nitro templating, and noticed that the code shown on http://www.nitrohq.com/view/Templates/Nitro has sections where it seems to be black text on a dark gray background, which is damn hard to read. James From timh at dirtymonday.net Fri Jan 6 21:28:46 2006 From: timh at dirtymonday.net (TimH) Date: Fri, 6 Jan 2006 18:28:46 -0800 Subject: [Nitro] Ruby syntax coloring on Nitro wiki In-Reply-To: <43BF192C.1000003@neurogami.com> References: <43BF192C.1000003@neurogami.com> Message-ID: <20060106182846.6920ee20.timh@dirtymonday.net> On Fri, 06 Jan 2006 18:28:12 -0700 James Britt wrote: > Sorry if this has been mentioned before, but I'm looking through the > nitrhq pages for help on Nitro templating, and noticed that the code > shown on > > http://www.nitrohq.com/view/Templates/Nitro > > has sections where it seems to be black text on a dark gray background, > which is damn hard to read. It has been mentioned over and over again. That's all I'll say on that. It could easily be fixed by editing the public/style.css file for spark and changing this line: pre {background: #424242; padding: 10px; overflow: auto;} to something like this pre {background: #424242; color: #FFF; padding: 10px; overflow: auto;} --TimH From james_b at neurogami.com Fri Jan 6 21:50:13 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 19:50:13 -0700 Subject: [Nitro] Nitro templating question Message-ID: <43BF2C65.8000900@neurogami.com> Does Nitro have something similar to "layouts" in Rails? This is were you can define a main template for a controller, and have sub-templates for each action. I have group of pages with the same header, footer, and so on, but the main body varies, and I'd like to just have a single "shell" template and plug in the guts that differ for each page. (I looked around the wiki, but didn't see it, nor did anything jump out at me in Nitro 0.26 examples, but if I missed something, please tell me.) Thanks, James Britt From james_b at neurogami.com Fri Jan 6 21:59:32 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 19:59:32 -0700 Subject: [Nitro] Ruby syntax coloring on Nitro wiki In-Reply-To: <20060106182846.6920ee20.timh@dirtymonday.net> References: <43BF192C.1000003@neurogami.com> <20060106182846.6920ee20.timh@dirtymonday.net> Message-ID: <43BF2E94.6060201@neurogami.com> TimH wrote: > > It has been mentioned over and over again. That's all I'll say on that. It could easily be fixed by editing the public/style.css file for spark and changing this line: > > pre {background: #424242; padding: 10px; overflow: auto;} > > to something like this > > pre {background: #424242; color: #FFF; padding: 10px; overflow: auto;} Ah, well light text on very dark backgrounds hurt my eyes, so I think I have to stick to Firefox's 'disable colors'. Thanks, James From bryan.a.soto at gmail.com Fri Jan 6 22:32:39 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 6 Jan 2006 19:32:39 -0800 Subject: [Nitro] Nitro templating question In-Reply-To: <43BF2C65.8000900@neurogami.com> References: <43BF2C65.8000900@neurogami.com> Message-ID: I think the closest thing to Rails layouts would be the Page tag. The best place to take a look at it might be in the skin.rb file in src subdirectories of flare or spark. Even a gen app xxx will create one, so you can take a look at it in the nitro/proto directory. Typical usage is Although, now that I think about it, you can probably define a layout.xhtmlfile and then use Hope that helps. bryan On 1/6/06, James Britt wrote: > > Does Nitro have something similar to "layouts" in Rails? > > This is were you can define a main template for a controller, and have > sub-templates for each action. > > I have group of pages with the same header, footer, and so on, but the > main body varies, and I'd like to just have a single "shell" template > and plug in the guts that differ for each page. > > > (I looked around the wiki, but didn't see it, nor did anything jump out > at me in Nitro 0.26 examples, but if I missed something, please tell me.) > > > Thanks, > > James Britt > _______________________________________________ > 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/20060106/a5055359/attachment.html From james_b at neurogami.com Fri Jan 6 22:45:33 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 20:45:33 -0700 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> Message-ID: <43BF395D.7090606@neurogami.com> Bryan Soto wrote: > I think the closest thing to Rails layouts would be the Page tag. The > best place to take a look at it might be in the skin.rb file in src > subdirectories of flare or spark. Even a gen app xxx will create one, so > you can take a look at it in the nitro/proto directory. > > Typical usage is > > > > > Although, now that I think about it, you can probably define a > layout.xhtml file and then use > > Hope that helps. Thanks. I'll go poke around. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From james_b at neurogami.com Fri Jan 6 23:03:33 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 21:03:33 -0700 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> Message-ID: <43BF3D95.9020804@neurogami.com> Bryan Soto wrote: > I think the closest thing to Rails layouts would be the Page tag. The > best place to take a look at it might be in the skin.rb file in src > subdirectories of flare or spark. Even a gen app xxx will create one, so > you can take a look at it in the nitro/proto directory. What I've found in skin.rb is a bunch of disconnected HTML embedded as raw strings in Ruby code. For anything but the most trivial page layout that is a nightmare to design and maintain. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From james_b at neurogami.com Fri Jan 6 23:20:27 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 06 Jan 2006 21:20:27 -0700 Subject: [Nitro] Nitro setting content type of application/xhtml+xml ? In-Reply-To: <43BF0E15.2090707@neurogami.com> References: <43BF0E15.2090707@neurogami.com> Message-ID: <43BF418B.3000701@neurogami.com> James Britt wrote: > In trying to figure out why I get CSS issues in a Nitro app, I found > that the server is returning > content-type: application/xhtml+xml > > which breaks IE and upsets the CSS rendering (it seems) in Firefox. > > > Is this something Nitro might be doing? I've grepped the source but not > found anything, but maybe the content-type is dynamically generated. I believe the fault was my Apache configured to use MultiViews; it would look for somepage, see somepage.xhml, and return it, setting the content type. James From george.moschovitis at gmail.com Sat Jan 7 05:57:29 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 Jan 2006 12:57:29 +0200 Subject: [Nitro] transaction exception logging In-Reply-To: <20060106203019.GB20466@localhost> References: <20051223145329.GB23021@localhost> <20060106203019.GB20466@localhost> Message-ID: Ok On 1/6/06, Tim Larson wrote: > On Mon, Dec 26, 2005 at 12:31:55PM +0200, George Moschovitis wrote: > > Ok, will consider this, any other opinions? > > > > -g. > > Thanks for the patch: > Fri Dec 30 13:53:26 EET 2005 George Moschovitis > * Better handling of errors on transactions. [timlarson] > > Would you consider adding "raise ex" after the rollback, > for the reason mentioned below (for handling exceptions)? > The application may (and mine does) want to have its own > exception handling outside of the transaction, and this > is currently blocked because the transaction swallows the > exception, making it look like it never happened and > losing any information contained in the exception. > > --Tim Larson > > > > > On 12/23/05, Tim Larson wrote: > > > In og/lib/og/store.rb "def transaction", why is there all > > > that logging code present? It make it harder to find the > > > error location than a simple rollback and re-raising of > > > the exception would. Also it makes test case output for > > > expected failures be unnecessarily verbose and redundant, > > > and the lack of re-raising the exception makes it difficult > > > to test when and if the right exceptions are being raised > > > by the code being tested. > > > > > > I am recommending: > > > > > > def transaction(&block) > > > begin > > > start > > > yield(self) > > > commit > > > rescue => ex > > > #Logger.error 'Erro > > > #Logger.error ex > > > #Logger.error ex.ba > > > rollback > > > raise ex > > > end > > > end > > > > > > --Tim Larson > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Jan 7 06:06:40 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 Jan 2006 13:06:40 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43BF3D95.9020804@neurogami.com> References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: > What I've found in skin.rb is a bunch of disconnected HTML embedded as > raw strings in Ruby code. For anything but the most trivial page layout > that is a nightmare to design and maintain. Really? I think rails layout system is only usefull for small, silly applications. Like many original rails features this seems tailored to 37signals simplistic applications, this is not a general solution. I find Nitro's elements or xslt compilers to be much more intuitive, elegant and powerful. I mean: .. and class Nitro::Element class Page def render %~ ... ... #{content} ... #{content :sidebar} ... ~ end end is quite easy to do. I can easily add external template file support for elements to make this better for you (ie keep th render xhtml in a separate .xhtml file). Any other ideas? regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Jan 7 06:07:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 Jan 2006 13:07:37 +0200 Subject: [Nitro] PATCH: Outstanding as of Jan. 6, 2006 In-Reply-To: References: Message-ID: thanks, I have integrated most of these patch to my repo version, will upload to the nitrohq.com repo real soon now ;-) -g. On 1/7/06, Bryan Soto wrote: > In the hopes of keeping people aware, here is a summary of outstanding > patches. Format is: > > patch name: > * Short summary of thread where Pending means no comments. If you've > applied and tested, please speak up :) > link for download of patch from Rubyforge. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > kirby_evolve_schema: > * George is investigating. > http://rubyforge.org/pipermail/nitro-general/2006-January/002356.html > > template escape backslashes: > * Problem with implementation, improperly escapes quoting backslashes. > Request for help. > http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html > > RELEASES rdoc fix: > * Pending. > http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html > > Small TableHelper cleanup: > * Pending. > http://rubyforge.org/pipermail/nitro-general/2006-January/002372.html > > Multipart forms and @params, Controls code updates: > * Problem handling many_to_many relationships. > http://rubyforge.org/pipermail/nitro-general/2006-January/002382.html > > Controls patch + bugfix: > * Pending. > http://rubyforge.org/pipermail/nitro-general/2006-January/002390.html > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Sat Jan 7 10:21:26 2006 From: james_b at neurogami.com (James Britt) Date: Sat, 07 Jan 2006 08:21:26 -0700 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: <43BFDC76.9020802@neurogami.com> George Moschovitis wrote: >>What I've found in skin.rb is a bunch of disconnected HTML embedded as >>raw strings in Ruby code. For anything but the most trivial page layout >>that is a nightmare to design and maintain. > > > > Really? > > I think rails layout system is only usefull for small, silly > applications. Like many original rails features this seems tailored to > 37signals simplistic applications, this is not a general solution. I > find Nitro's elements or xslt compilers to be much more intuitive, > elegant and powerful. I mean: I didn't intend my comment as any sort of comparison to other frameworks, and much prefer to Nitro development continue based on what makes the most sense for Nitro and its users. I've seen how things go when there is a perpetual state of tool/language/philosophy antagonism, and it tends to produce more heat than light. .. > is quite easy to do. Easy for small items/pages, but just as I do not want much code in my page templates, I do not want much templating in my code files. I prefer to be able to run my template files through an XML/XHTML validator tool to check them, not wait to "compile" a complete page to see if I have a problem. > I can easily add external template file support > for elements to make this better for you (ie keep th render xhtml in a > separate .xhtml file). Any other ideas? No, I just want to be able to keep presentation files separate from Ruby code. I want my designers (and me) to be able to edit the markup in a markup editor. Thanks, James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From rob at motionpath.com Sat Jan 7 10:36:42 2006 From: rob at motionpath.com (rob) Date: Sat, 7 Jan 2006 15:36:42 +0000 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: Spooky, I was discussing this with Chris yesterday. I also would prefer external template file support for elements. On 7 Jan 2006, at 11:06, George Moschovitis wrote: >> What I've found in skin.rb is a bunch of disconnected HTML >> embedded as >> raw strings in Ruby code. For anything but the most trivial page >> layout >> that is a nightmare to design and maintain. > > > Really? > > I think rails layout system is only usefull for small, silly > applications. Like many original rails features this seems tailored to > 37signals simplistic applications, this is not a general solution. I > find Nitro's elements or xslt compilers to be much more intuitive, > elegant and powerful. I mean: > > > .. > > > > and > > > class Nitro::Element > class Page > def render > %~ > > > > > ... > ... > #{content} > ... > #{content :sidebar} > ... > > ~ > end > end > > is quite easy to do. I can easily add external template file support > for elements to make this better for you (ie keep th render xhtml in a > separate .xhtml file). Any other ideas? > > regards, > George. > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Sat Jan 7 13:48:38 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 7 Jan 2006 10:48:38 -0800 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: So rather than elements, James would like external layouts similar to Rails and Rob would like to be able to specify external template files rather than coding the view in the element itself. Correct? So how should it work? According to the Rails book, a layout should be defined with the same name as the controller, and any action called on that controller will use that template. I'm sure they also have a method where you can specify a different name. So that's one option. And for elements, perhaps a new property, Element.template_root, where a directory is stored, and any element rendered looks there for it's corresponding template file, i.e. Page would look for #{ Element.template_root}/page.xhtml. Overridable by a method name in the tag perhaps? Any other ideas on either of these anybody? On 1/7/06, rob wrote: > > Spooky, I was discussing this with Chris yesterday. I also would > prefer external template file support for elements. > > On 7 Jan 2006, at 11:06, George Moschovitis wrote: > > >> What I've found in skin.rb is a bunch of disconnected HTML > >> embedded as > >> raw strings in Ruby code. For anything but the most trivial page > >> layout > >> that is a nightmare to design and maintain. > > > > > > Really? > > > > I think rails layout system is only usefull for small, silly > > applications. Like many original rails features this seems tailored to > > 37signals simplistic applications, this is not a general solution. I > > find Nitro's elements or xslt compilers to be much more intuitive, > > elegant and powerful. I mean: > > > > > > .. > > > > > > > > and > > > > > > class Nitro::Element > > class Page > > def render > > %~ > > > > > > > > > > ... > > ... > > #{content} > > ... > > #{content :sidebar} > > ... > > > > ~ > > end > > end > > > > is quite easy to do. I can easily add external template file support > > for elements to make this better for you (ie keep th render xhtml in a > > separate .xhtml file). Any other ideas? > > > > regards, > > George. > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.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 -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060107/6f82b436/attachment.html From datapanix at gmail.com Sat Jan 7 14:31:03 2006 From: datapanix at gmail.com (lester bangs) Date: Sat, 7 Jan 2006 19:31:03 +0000 (UTC) Subject: [Nitro] Two errors preventing me from evaluating Nitro Message-ID: Running stock Nitro 0.26 installed via 'gem install nitro', Ruby 1.8.2, WinXP. #1: running 'nitro' at a command prompt starts the server properly and i get the welcome screen. however, if i try to navigate to any of the /examples apps, it bombs and i get the following stack trace: c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/dispatcher.rb:202:in `dispatch' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/render.rb:115:in `render' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/adapter/webrick.rb:145:in `do_GET' c:/ruby/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__' c:/ruby/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' c:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' c:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' c:/ruby/lib/ruby/1.8/webrick/server.rb:155:in `start_thread' c:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start' c:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start_thread' c:/ruby/lib/ruby/1.8/webrick/server.rb:94:in `start' c:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `each' c:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `start' c:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start' c:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/adapter/webrick.rb:55:in `start' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/server/runner.rb:297:in `invoke_server' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/server/runner.rb:263:in `invoke' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/server.rb:124:in `run' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro.rb:73:in `run' c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/../proto/run.rb:95 #2 running 'nitrogen' at a command prompt produces the following error: D, [2006-01-07T14:24:25.694000 #1436] DEBUG -- : Using memory sessions. c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': No such file to load -- nano/dir/%3A%3Arecurse (LoadError) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/bin/nitrogen:8 from c:/ruby/bin/nitrogen:18:in `load' from c:/ruby/bin/nitrogen:18 Any ideas why I'm getting these errors. If I can't get past these, it's back to Rails for me. Thanks. From james_b at neurogami.com Sat Jan 7 14:44:22 2006 From: james_b at neurogami.com (James Britt) Date: Sat, 07 Jan 2006 12:44:22 -0700 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: <43C01A16.5060303@neurogami.com> Bryan Soto wrote: > So rather than elements, James would like external layouts similar to > Rails and Rob would like to be able to specify external template files > rather than coding the view in the element itself. Correct? > Not quite. I'm not asking that Elements go away or anything, or that I can't find a use for them, but I am looking for a simple way to do Dreamweaver-style templates when I want to. Dreamweaver lets you create a template that defines an entire page (what Rials calls a 'layout'), with slots for inserting free-form content or calls to library templates (which render small chunks of stuff; what Rials calls 'partials'). Dreamweaver was the first place I saw this template style; I used Rails as an example because I thought most here would be reasonably familiar with it, but it's not unique or original to Rails, and I don't want to encourage Rails/Nitro comparisons, because I think they serve different audiences. Bryan's earlier reply to my inquires got me pointed in the right direction, and I had little trouble making use of Elements and Pages. And indeed it would be trivial to write my code to slurp in a disk file rather than have the HTML stuffed into a method. Whether or not there should be a built-in Nitro way to do that file-slurping is another matter. I'd like to see it, because I think that's something I would use, but since Ruby/Nitro makes it easy to alter things, it isn't essential. > So how should it work? > > According to the Rails book, a layout should be defined with the same > name as the controller, and any action called on that controller will > use that template. I'm sure they also have a method where you can > specify a different name. So that's one option. I've been a big fan of convention over configuration since the late '90s, and I like the idea that if I simple name something correctly and place it in a reasonable spot, Nitro will just Do The Right Thing. For example, if I have a file named main.layout.xhtml in my templates directory, Nitro could just figure out that I want to use a layout for the main controller. Methods that that do not want a layout would then need to say so, or they could explicitly request the use of a different layout. If there is no *.layout.* file, then it is assumed that none is to be used unless a controller method explicitly asks for one by name. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Sat Jan 7 15:32:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 7 Jan 2006 12:32:53 -0800 Subject: [Nitro] Two errors preventing me from evaluating Nitro In-Reply-To: References: Message-ID: Hi, Re: #1, I'm not sure if that's old or what. I, for one, didn't even know running nitro at the command prompt did that. Anyway, the examples are actually a separate download available at the Rubyforge site. Also checkout spark and flare which are standalone examples. http://rubyforge.org/frs/?group_id=418 Re: #2, I believe gen is the way to create an app now. gen app app_name_here. Good luck, bryan On 1/7/06, lester bangs wrote: > > Running stock Nitro 0.26 installed via 'gem install nitro', Ruby 1.8.2, > WinXP. > > #1: running 'nitro' at a command prompt starts the server properly and i > get > the welcome screen. however, if i try to navigate to any of the /examples > apps, it bombs and i get the following stack trace: > > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/dispatcher.rb:202:in > `dispatch' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/render.rb:115:in > `render' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0 > /lib/nitro/adapter/webrick.rb:145:in > `do_GET' > c:/ruby/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__' > c:/ruby/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' > c:/ruby/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' > c:/ruby/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' > c:/ruby/lib/ruby/1.8/webrick/server.rb:155:in `start_thread' > c:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start' > c:/ruby/lib/ruby/1.8/webrick/server.rb:144:in `start_thread' > c:/ruby/lib/ruby/1.8/webrick/server.rb:94:in `start' > c:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `each' > c:/ruby/lib/ruby/1.8/webrick/server.rb:89:in `start' > c:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start' > c:/ruby/lib/ruby/1.8/webrick/server.rb:79:in `start' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0 > /lib/nitro/adapter/webrick.rb:55:in > `start' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0 > /lib/nitro/server/runner.rb:297:in > `invoke_server' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0 > /lib/nitro/server/runner.rb:263:in > `invoke' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/server.rb:124:in > `run' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro.rb:73:in `run' > c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/../proto/run.rb:95 > > #2 running 'nitrogen' at a command prompt produces the following error: > > D, [2006-01-07T14:24:25.694000 #1436] DEBUG -- : Using memory sessions. > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require__': No > such file to load -- nano/dir/%3A%3Arecurse (LoadError) > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require' > from c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.26.0/bin/nitrogen:8 > from c:/ruby/bin/nitrogen:18:in `load' > from c:/ruby/bin/nitrogen:18 > > Any ideas why I'm getting these errors. If I can't get past these, it's > back > to Rails for me. > > Thanks. > > _______________________________________________ > 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/20060107/47a94e20/attachment.html From datapanix at gmail.com Sat Jan 7 16:24:23 2006 From: datapanix at gmail.com (Lester Bangs) Date: Sat, 7 Jan 2006 21:24:23 +0000 (UTC) Subject: [Nitro] Two errors preventing me from evaluating Nitro References: Message-ID: Bryan Soto gmail.com> writes: > Hi,Re: #1, I'm not sure if that's old or what. I, for one, didn't even know running nitro at the command prompt did that. Anyway, the examples are actually a separate download available at the Rubyforge site. Also checkout spark and flare which are standalone examples. Doh! Got it, thanks. >#2, I believe gen is the way to create an app now. > gen app app_name_here. This one is a little more tricky. 'gen' at a command prompt gives an error that it cant find the command. Do I need to explicitly path it to run the command? I'm used to typing "rails [app]" from anywhere on my system to get an app scaffold. Thanks for the help! From bryan.a.soto at gmail.com Sun Jan 8 00:35:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 7 Jan 2006 21:35:35 -0800 Subject: [Nitro] Two errors preventing me from evaluating Nitro In-Reply-To: References: Message-ID: I'm sorry, I forgot about that. It's fixed in the upcoming release. C:\>copy c:\ruby\lib\ruby\gems\1.8\gems\gen-0.26.0\bin\gen c:\ruby\bin\gen Then create c:\ruby\bin\gen.cmd containing @ruby "c:/ruby/bin/gen" %* Bryan On 1/7/06, Lester Bangs wrote: > > Bryan Soto gmail.com> writes: > > > Hi,Re: #1, I'm not sure if that's old or what. I, for > one, didn't > even know running nitro at the command prompt did > that. Anyway, the examples are > actually a separate download available at the Rubyforge > site. Also checkout > spark and flare which are standalone examples. > > Doh! Got it, thanks. > > >#2, I believe gen is the way to create an app now. > > gen app app_name_here. > > This one is a little more tricky. 'gen' at a command > prompt gives an error that it cant find the command. > Do I need to explicitly path it to run the command? > I'm used to typing "rails [app]" from anywhere on my > system to get an app scaffold. > > Thanks for the help! > > > _______________________________________________ > 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/20060108/af6c4c49/attachment.html From m.fellinger at gmail.com Sun Jan 8 02:08:05 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sun, 8 Jan 2006 08:08:05 +0100 Subject: [Nitro] Ruby syntax coloring on Nitro wiki In-Reply-To: <43BF2E94.6060201@neurogami.com> References: <43BF192C.1000003@neurogami.com> <20060106182846.6920ee20.timh@dirtymonday.net> <43BF2E94.6060201@neurogami.com> Message-ID: <9c00d3e00601072308v37bac40cj@mail.gmail.com> I remember that i even sent a patch for that...not sure if it's now in the repo, have to check that out later 2006/1/7, James Britt :> TimH wrote:> >> > It has been mentioned over and over again. That's all I'll say on that. It could easily be fixed by editing the public/style.css file for spark and changing this line:> >> > pre {background: #424242; padding: 10px; overflow: auto;}> >> > to something like this> >> > pre {background: #424242; color: #FFF; padding: 10px; overflow: auto;}>> Ah, well light text on very dark backgrounds hurt my eyes, so I think I> have to stick to Firefox's 'disable colors'.>>> Thanks,>>>> James> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From kevwil at gmail.com Sun Jan 8 12:08:14 2006 From: kevwil at gmail.com (Kevin Williams) Date: Sun, 8 Jan 2006 10:08:14 -0700 Subject: [Nitro] scgi questions Message-ID: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> I'm trying to get a Nitro app to run under SCGI from Apache 2.0.55 onWindows XP. I got Rails to run in the same environment yesterday, soI'm pretty sure the Apache/SCGI part is working. I did "gen app ./nitro_scgi" (after creating gen.cmd in Ruby's binfolder) and added my conf/scgi.yaml file. Am I correct that I shouldrun "ruby script/scgi_service" to run the app? By doing that, I seemto get WebRick running on port 9999. I set the scgi.yaml to use port19999, so I'm not sure where the 9999 came from. I guess I wish thescgi_rails gem was more generic and I could use the same for Nitrothat I would for Rails. Also, the "script/scgi_ctl" file didn't like the same "-S"command-line option to disable POSIX signals, so I added":disable_signals: true" to scgi.yaml manually. So, how do I get Nitro to do SCGI under Apache2? --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From kevwil at gmail.com Sun Jan 8 11:27:43 2006 From: kevwil at gmail.com (Kevin Williams) Date: Sun, 8 Jan 2006 09:27:43 -0700 Subject: [Nitro] Nitro and Facets version In-Reply-To: <20051030200836.443e0851@localhost> References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> Message-ID: <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> I'm just now trying Nitro/Og, wanting to check out its SCGI support.It appears that if I "gen" my app I will get an SCGI-supportedconfiguration out of the box. I'm on a fresh Windows XP box with Ruby& Gems newly installed. After installing all the nitro gems, I have a"nitrogen" command but not "gen". Is the "gen" gem supposed to createan executable script called "gen", or are we supposed to keep using"nitrogen"? I'm confused, getting old I guess. On 10/30/05, Michael Kohl wrote:> Hi other Michael,>> On Sun, 30 Oct 2005 18:49:27 +0100> Michael Fellinger wrote:>> > /usr/lib/ruby/gems/1.8/gems/gen-0.24.0/bin$ ruby -rubygems gen app> > ~/testapp /usr/lib/ruby/gems/1.8/gems/gen-0.24.0/bin$> > ls /home/manveru/testapp conf doc public README run.rb scgi.rb> > script>> This unfortunately gives me the same error about facets versions.>> > it seems as if the new gem 'gen' took over the job of nitrogen and> > now creates the apps>> That's what I figured from the name. ;) I just thought that not putting> anything into $PATH is meant to tell us to just not use this yet.>> Thanks nonetheless,> Michael>> --> web at citizen428.net citizen428 at gentoo.org> http://citizen428.net/ http://dev.gentoo.org/~citizen428/> GnuPG key: 0x90CA09E3/4D21 916E DBCE 72B8 CDC5 BD87 DE2D 91A2 90CA 09E3>>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general>>>> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From james_b at neurogami.com Sun Jan 8 14:59:34 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 08 Jan 2006 12:59:34 -0700 Subject: [Nitro] scgi questions In-Reply-To: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> Message-ID: <43C16F26.3090105@neurogami.com> Kevin Williams wrote: > I'm trying to get a Nitro app to run under SCGI from Apache 2.0.55 onWindows XP. I got Rails to run in the same environment yesterday, soI'm pretty sure the Apache/SCGI part is working. > I did "gen app ./nitro_scgi" (after creating gen.cmd in Ruby's binfolder) and added my conf/scgi.yaml file. Am I correct that I shouldrun "ruby script/scgi_service" to run the app? By doing that, I seemto get WebRick running on port 9999. I set the scgi.yaml to use port19999, so I'm not sure where the 9999 came from. I guess I wish thescgi_rails gem was more generic and I could use the same for Nitrothat I would for Rails. > Also, the "script/scgi_ctl" file didn't like the same "-S"command-line option to disable POSIX signals, so I added":disable_signals: true" to scgi.yaml manually. > So, how do I get Nitro to do SCGI under Apache2? Good question. I'm right now trying to get a Nitro app to run under SCGI + Apache2 on a Linux box, and I keep getting a "port in use" exception. Apparently port 9999 is hard-coded someplace. I have scgi.yaml configured to set the port to 6666, I've changed the default port values in the local SCGI scripts to 6666, so none of the files or scripts in my application folder have 9999 in them, but that value is still getting set from someplace. Any clues? Thanks, James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From rob at motionpath.com Sun Jan 8 17:49:20 2006 From: rob at motionpath.com (rob) Date: Sun, 8 Jan 2006 22:49:20 +0000 Subject: [Nitro] scgi questions In-Reply-To: <43C16F26.3090105@neurogami.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> Message-ID: <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> I don't know specifically about your issue but a clue could be obtained by typing: grep -r 9999 /path/to/nitro/directory then looking at the corresponding file. This will reveal where 9999 is being hard-coded, if it is. On 8 Jan 2006, at 19:59, James Britt wrote: > Kevin Williams wrote: >> I'm trying to get a Nitro app to run under SCGI from Apache 2.0.55 >> onWindows XP. I got Rails to run in the same environment >> yesterday, soI'm pretty sure the Apache/SCGI part is working. >> I did "gen app ./nitro_scgi" (after creating gen.cmd in Ruby's >> binfolder) and added my conf/scgi.yaml file. Am I correct that I >> shouldrun "ruby script/scgi_service" to run the app? By doing >> that, I seemto get WebRick running on port 9999. I set the >> scgi.yaml to use port19999, so I'm not sure where the 9999 came >> from. I guess I wish thescgi_rails gem was more generic and I >> could use the same for Nitrothat I would for Rails. >> Also, the "script/scgi_ctl" file didn't like the same "-S"command- >> line option to disable POSIX signals, so I added":disable_signals: >> true" to scgi.yaml manually. >> So, how do I get Nitro to do SCGI under Apache2? > > Good question. I'm right now trying to get a Nitro app to run under > SCGI + Apache2 on a Linux box, and I keep getting a "port in use" > exception. Apparently port 9999 is hard-coded someplace. > > I have scgi.yaml configured to set the port to 6666, I've changed the > default port values in the local SCGI scripts to 6666, so none of the > files or scripts in my application folder have 9999 in them, but that > value is still getting set from someplace. > > > > Any clues? > > Thanks, > > > > James > -- > > http://www.ruby-doc.org - Ruby Help & Documentation > http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted > http://www.rubystuff.com - The Ruby Store for Ruby Stuff > http://www.jamesbritt.com - Playing with Better Toys > http://www.30secondrule.com - Building Better Tools > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From james_b at neurogami.com Sun Jan 8 18:21:00 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 08 Jan 2006 16:21:00 -0700 Subject: [Nitro] scgi questions In-Reply-To: <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> Message-ID: <43C19E5C.3060204@neurogami.com> rob wrote: > I don't know specifically about your issue but a clue could be > obtained by typing: > > grep -r 9999 /path/to/nitro/directory > > then looking at the corresponding file. This will reveal where 9999 > is being hard-coded, if it is. That value is assigned as the port number in lib/nitro/server.rb. My hunch is that configuration values are never passed on to the actual Webrick server, so it just stay at the default. As an experiment I added faulty markup to scgi.yaml; I got a parsing error when I ran scgi_ctl, so I know it is finding and reading the config file. But after that, it seems the values are never properly passed on. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From james_b at neurogami.com Sun Jan 8 19:20:39 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 08 Jan 2006 17:20:39 -0700 Subject: [Nitro] [OT] Earthquake in Greece Message-ID: <43C1AC57.3070901@neurogami.com> Any of our fellow Nitrates effected by the earthquake in Greece? http://earthquake.usgs.gov/recenteqsww/Quakes/ushrak.htm Hope all are well. James From aidan at yoyo.org Sun Jan 8 22:00:49 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 9 Jan 2006 14:00:49 +1100 Subject: [Nitro] schema_inheritance In-Reply-To: References: <4b6f054f0512250939v58e9e261p9d692e73d685c4@mail.gmail.com> Message-ID: <966A5E06-974B-429F-99DD-A6B63D132A42@yoyo.org> Did this get fixed? Aidan On 27/12/2005, at 12:52 PM, Emmanuel Piperakis wrote: >> use: >> >> is SchemaInheritanceBase >> >> perhaps we can improve the name. > > G. the initial email I posted reported a bug in the 0.26, where > when I use > the schema_inheritance only the frist subclasss' fields are added > to the > superclass. That must be realy easy to fix, and it worked for 0.25 > and it > prevents me from upgrading. > > e.g > > class Project > property :koko, String > schema_inheritance > end > > class FProject < Project > property :haha, String > end > > class DProject < Project > property :kaka, String > end > > ONLY :haha is added and NOT :kaka. I tried switching the order of the > classes (first DProject and then FProject) and then only :kaka was > added > to the table and NOT :haha, therefore there a very simple problem. You > only take one subclass... > > Could you please fix this? From aidan at yoyo.org Sun Jan 8 23:08:47 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 9 Jan 2006 15:08:47 +1100 Subject: [Nitro] PATCH: schema_inheritance In-Reply-To: <966A5E06-974B-429F-99DD-A6B63D132A42@yoyo.org> References: <4b6f054f0512250939v58e9e261p9d692e73d685c4@mail.gmail.com> <966A5E06-974B-429F-99DD-A6B63D132A42@yoyo.org> Message-ID: <074F4D21-FFF3-4861-9EB2-E2DBFAB352DE@yoyo.org> In answer to my own question, here is a patch. I've not used diff/ patch for quite a while, so unsure of the protocol. I've tested it with my own application, as well as with a small test app (which I've also attached - it would be easily turned into a test case, but I don't have my environment set up to run the regular nitro test cases). Please let me know if I've done anything crazy :-) Aidan -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.rb Type: text/x-ruby-script Size: 652 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060108/5f8a7531/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: og_schema_inheritance.patch Type: application/octet-stream Size: 701 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060108/5f8a7531/attachment.obj -------------- next part -------------- On 09/01/2006, at 2:00 PM, Aidan Rogers wrote: > Did this get fixed? > > Aidan > > On 27/12/2005, at 12:52 PM, Emmanuel Piperakis wrote: > >>> use: >>> >>> is SchemaInheritanceBase >>> >>> perhaps we can improve the name. >> >> G. the initial email I posted reported a bug in the 0.26, where >> when I use >> the schema_inheritance only the frist subclasss' fields are added >> to the >> superclass. That must be realy easy to fix, and it worked for 0.25 >> and it >> prevents me from upgrading. >> >> e.g >> >> class Project >> property :koko, String >> schema_inheritance >> end >> >> class FProject < Project >> property :haha, String >> end >> >> class DProject < Project >> property :kaka, String >> end >> >> ONLY :haha is added and NOT :kaka. I tried switching the order of the >> classes (first DProject and then FProject) and then only :kaka was >> added >> to the table and NOT :haha, therefore there a very simple problem. >> You >> only take one subclass... >> >> Could you please fix this? > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From zimba.tm at gmail.com Mon Jan 9 03:46:50 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 09 Jan 2006 09:46:50 +0100 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: References: <43BE288D.9000208@gmail.com> <43BE7299.7020000@gmail.com> Message-ID: <43C222FA.1060908@gmail.com> Bryan Soto wrote: > Hi Jonas, Hi Bryan > > I like the password control, it's very cool. And you beat me to that > Nitro::RenderExit that was bugging me ;) Thanks. George always import Nitro so he didn't encounter this problem :-p > > As a note for George, both this and Chris' patch implement the > plus/minus button for fixnums, so if you use both, you'll have > conflicts. Only difference I noticed was, when the fixnum field > contained "TEST": > > Chris' patch: > would consider this as 0, and increment or decrement. > > Jonas' patch: > is stricter and converts this to nan (Not a number). > > Other than that, everything seems to work as advertised. :) I think Chris' patch is better because a number is always expected. Or it should return NULL if Nan ? > > Jonas, I wonder if I understand controls correctly. You specify > controls for properties, via annotations or directly in the model, > than you can use form_for to have Nitro just create the form for you > rather than coding everything out in the view? Is that right? I always used that feature with part/admin so I can't tell exactly. But it uses the form rendering so it should work like you said. Every control extends the Control class and implements the render method. There are also other facilities like js and css methods. The Control.map setting defines a hash with the various controls. When building your model, you can override the default control for a specific property by using :control => :control_name. As an example : class User property :login, String property :password, String, :control => :password end Now when using the part/admin, you'll have a password input instead of a text input. Btw, I'm not very satified with my PasswordControl implementation because it puts the password in clear in the html. I could do something better if I knew a generic way to tell that the field didn't change. Cheers, Jonas Pfenniger From george.moschovitis at gmail.com Mon Jan 9 03:56:10 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 10:56:10 +0200 Subject: [Nitro] [OT] Earthquake in Greece In-Reply-To: <43C1AC57.3070901@neurogami.com> References: <43C1AC57.3070901@neurogami.com> Message-ID: We certainly felt the earthquake, but everything is ok ;-) Thankfully the epicenter of the earthquake was inside the sea ;-) thanks for asking -g. On 1/9/06, James Britt wrote: > Any of our fellow Nitrates effected by the earthquake in Greece? > > http://earthquake.usgs.gov/recenteqsww/Quakes/ushrak.htm > > > Hope all are well. > > > James > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 9 04:12:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 11:12:24 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43C01A16.5060303@neurogami.com> References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> <43C01A16.5060303@neurogami.com> Message-ID: > matter. I'd like to see it, because I think that's something I would > use, but since Ruby/Nitro makes it easy to alter things, it isn't essential. will add... > I've been a big fan of convention over configuration since the late > '90s, and I like the idea that if I simple name something correctly and > place it in a reasonable spot, Nitro will just Do The Right Thing. Nitro is adding some conventions recently. For example autosearch for the template root in tempate, src/template and public in the repo version. However I prefer to add conventions at the end and make sure that you can always configure things if you want to. > For example, if I have a file named main.layout.xhtml in my templates > .. > need to say so, or they could explicitly request the use of a different > layout. ok will add something similar that fits with the current nitro architecture. Stay tuned ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 9 04:14:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 11:14:07 +0200 Subject: [Nitro] PATCH: schema_inheritance In-Reply-To: <074F4D21-FFF3-4861-9EB2-E2DBFAB352DE@yoyo.org> References: <4b6f054f0512250939v58e9e261p9d692e73d685c4@mail.gmail.com> <966A5E06-974B-429F-99DD-A6B63D132A42@yoyo.org> <074F4D21-FFF3-4861-9EB2-E2DBFAB352DE@yoyo.org> Message-ID: thanks a lot, will investigate... -g. On 1/9/06, Aidan Rogers wrote: > In answer to my own question, here is a patch. I've not used diff/ > patch for quite a while, so unsure of the protocol. > > I've tested it with my own application, as well as with a small test > app (which I've also attached - it would be easily turned into a test > case, but I don't have my environment set up to run the regular nitro > test cases). > > Please let me know if I've done anything crazy :-) > > Aidan > > > > On 09/01/2006, at 2:00 PM, Aidan Rogers wrote: > > > Did this get fixed? > > > > Aidan > > > > On 27/12/2005, at 12:52 PM, Emmanuel Piperakis wrote: > > > >>> use: > >>> > >>> is SchemaInheritanceBase > >>> > >>> perhaps we can improve the name. > >> > >> G. the initial email I posted reported a bug in the 0.26, where > >> when I use > >> the schema_inheritance only the frist subclasss' fields are added > >> to the > >> superclass. That must be realy easy to fix, and it worked for 0.25 > >> and it > >> prevents me from upgrading. > >> > >> e.g > >> > >> class Project > >> property :koko, String > >> schema_inheritance > >> end > >> > >> class FProject < Project > >> property :haha, String > >> end > >> > >> class DProject < Project > >> property :kaka, String > >> end > >> > >> ONLY :haha is added and NOT :kaka. I tried switching the order of the > >> classes (first DProject and then FProject) and then only :kaka was > >> added > >> to the table and NOT :haha, therefore there a very simple problem. > >> You > >> only take one subclass... > >> > >> Could you please fix this? > > > > _______________________________________________ > > 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://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 9 06:26:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 13:26:34 +0200 Subject: [Nitro] schema_inheritance In-Reply-To: References: <4b6f054f0512250939v58e9e261p9d692e73d685c4@mail.gmail.com> Message-ID: I created a test case for this and it passes. There are some problem with evolution though, some warnings.... perhaps Rob should take a look at this (tc_inheritance2.rb) regards, George. On 12/27/05, Emmanuel Piperakis wrote: > > use: > > > > is SchemaInheritanceBase > > > > perhaps we can improve the name. > > G. the initial email I posted reported a bug in the 0.26, where when I use > the schema_inheritance only the frist subclasss' fields are added to the > superclass. That must be realy easy to fix, and it worked for 0.25 and it > prevents me from upgrading. > > e.g > > class Project > property :koko, String > schema_inheritance > end > > class FProject < Project > property :haha, String > end > > class DProject < Project > property :kaka, String > end > > ONLY :haha is added and NOT :kaka. I tried switching the order of the > classes (first DProject and then FProject) and then only :kaka was added > to the table and NOT :haha, therefore there a very simple problem. You > only take one subclass... > > Could you please fix this? > > Thanx > > Emmanouil Piperakis (epiperak at cs.ntua.gr) > {To explore is Human, to Create is Devine, > To teach is Primal, to Rule is Sin} > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Mon Jan 9 10:42:07 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 09 Jan 2006 16:42:07 +0100 Subject: [Nitro] [PATCH] TableHelper sort implementation Message-ID: Hi, I needed some kind of automatic sorting of table columns built into the TableHelper, so here's the patch. Please tell me of any quirks if you happen to use it :) Sort Usage: =========== # true, # right align the order controls # :values => [nil, 'first_name', 'last_name'], # column names from DB # :asc_pic => "/images/asc.png", # :desc_pic => "/images/desc.png" } # ?> # #
# #{table :values => users, :headers => header, # :order => order_opts, :alternating_rows => true } #
If you don't provide pictures (:asc/desc_pic) to the order_opts it'll fall back to "^ v". Like you can see in the example, it doesn't put sort controls into the column where order_opts[:values] is nil/false. Now, to use this feature in conjunction with for example a Pager put something along following into your controller: # page = request.params[Pager.key] # order_by = request.params[TableHelper.order_by_key] || 'oid' # order_direction = request.params[TableHelper.order_direction_key] || "ASC" # order = "#{order_by} #{order_direction}" # # entries, @pager = paginate(Container, :condition => "blbla", # :order => order, :per_page => 10, :page => page) .. now, that I think about it.. can that stuff be put directly into the Pager?... Alternating Rows ================ The additional :alternating_rows in the table controls produces html code like: # # # ... So you can use CSS to style the rows. theader/tfooter/tbody Usage =========================== When you like a little more control over the general layout of the table, you can use :footer and several blocks like this: # "rights = 'root'").map { |u| [u.name, u.first_name, u.last_name, u.email] } # users = User.find(:condition => "rights != 'root'").map { |u| [u.name, u.first_name, u.last_name, u.email] } # email_missing = User.count(:condition => "email IS NULL") # footer = ['', '', '', "#{email_missing} emails missing."] # ?> #
# #{table :values => [admins, users], :headers => header, # :order => order_opts, :alternating_rows => true, # :footer => footer } #
produces code like: # # .. # .. # .. admin rows .. # .. user rows .. #
This can be used by CSS to style the header/footer/body of the table explicitly. Hope someone can use it, every comment is helpful. (And I hope the code/usage is clear/clean enough... *sigh*) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: table_helper_sort_implementation.tar.bz2 Type: application/bzip2 Size: 3838 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060109/56aa7ff5/attachment.bin From george.moschovitis at gmail.com Mon Jan 9 10:47:26 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 17:47:26 +0200 Subject: [Nitro] [PATCH] TableHelper sort implementation In-Reply-To: References: Message-ID: interesting, will have a look, thanks! -g. On 1/9/06, Kashia Buch wrote: > Hi, > > I needed some kind of automatic sorting of table columns built into the TableHelper, so here's the patch. Please tell me of any quirks if you happen to use it :) > > Sort Usage: > =========== > # # users = User.all.map { |u| [u.name, u.first_name, u.last_name, u.email] } > # headers = ['Username', 'First name', 'Last name', 'Email'] > # order_opts = { :right => true, # right align the order controls > # :values => [nil, 'first_name', 'last_name'], # column names from DB > # :asc_pic => "/images/asc.png", > # :desc_pic => "/images/desc.png" } > # ?> > # > #
> # #{table :values => users, :headers => header, > # :order => order_opts, :alternating_rows => true } > #
> > If you don't provide pictures (:asc/desc_pic) to the order_opts it'll fall back to "^ v". Like you can see in the example, it doesn't put sort controls into the column where order_opts[:values] is nil/false. > > Now, to use this feature in conjunction with for example a Pager put something along following into your controller: > > # page = request.params[Pager.key] > # order_by = request.params[TableHelper.order_by_key] || 'oid' > # order_direction = request.params[TableHelper.order_direction_key] || "ASC" > # order = "#{order_by} #{order_direction}" > # > # entries, @pager = paginate(Container, :condition => "blbla", > # :order => order, :per_page => 10, :page => page) > > .. > > now, that I think about it.. can that stuff be put directly into the Pager?... > > > Alternating Rows > ================ > The additional :alternating_rows in the table controls produces html code like: > > # > # > # ... > > So you can use CSS to style the rows. > > theader/tfooter/tbody Usage > =========================== > > When you like a little more control over the general layout of the table, you can use :footer and several blocks like this: > > # # admins = User.find(:condition => "rights = 'root'").map { |u| [u.name, u.first_name, u.last_name, u.email] } > # users = User.find(:condition => "rights != 'root'").map { |u| [u.name, u.first_name, u.last_name, u.email] } > # email_missing = User.count(:condition => "email IS NULL") > # footer = ['', '', '', "#{email_missing} emails missing."] > # ?> > #
> # #{table :values => [admins, users], :headers => header, > # :order => order_opts, :alternating_rows => true, > # :footer => footer } > #
> > produces code like: > > # > # .. > # .. > # .. admin rows .. > # .. user rows .. > #
> > This can be used by CSS to style the header/footer/body of the table explicitly. > > Hope someone can use it, every comment is helpful. (And I hope the code/usage is clear/clean enough... *sigh*) > > Kash > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Mon Jan 9 12:18:58 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 09 Jan 2006 18:18:58 +0100 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> Message-ID: <43C29B02.6070405@gmail.com> George Moschovitis wrote: >>What I've found in skin.rb is a bunch of disconnected HTML embedded as >>raw strings in Ruby code. For anything but the most trivial page layout >>that is a nightmare to design and maintain. >> >> > > >Really? > >I think rails layout system is only usefull for small, silly >applications. Like many original rails features this seems tailored to >37signals simplistic applications, this is not a general solution. I >find Nitro's elements or xslt compilers to be much more intuitive, >elegant and powerful. I mean: > > > .. > > > >and > > >class Nitro::Element > class Page > def render > %~ > > > > > ... > ... > #{content} > ... > #{content :sidebar} > ... > > ~ > end >end > >is quite easy to do. I can easily add external template file support >for elements to make this better for you (ie keep th render xhtml in a >separate .xhtml file). Any other ideas? > >regards, >George. > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.com > >_______________________________________________ >Nitro-general mailing list >Nitro-general at rubyforge.org >http://rubyforge.org/mailman/listinfo/nitro-general > > > George, I have some questions regarding the Elements. I understand #{content :sidebar} use a child element, but I don't know where to set it up. Is there an accessor in the controller for it ? What is the difference between a Control and an Element ? How do you change the template surrounding a page without changin the enclosing tag ? eg. I use around my content, but sometimes I want a different html template. It there a mechanism for this ? Cheers, zimbatm From george.moschovitis at gmail.com Mon Jan 9 12:30:36 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Jan 2006 19:30:36 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43C29B02.6070405@gmail.com> References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> <43C29B02.6070405@gmail.com> Message-ID: > I have some questions regarding the Elements. > I understand #{content :sidebar} use a child element, but I don't know > where to set it up. Is there an accessor in the controller for it ? xxxx yyy class SideBar name :sidebar def render ... end end class Page def render %{ .... #{content} <---- xxxx ... ... #{content :sidebar} <---- yyyyy } end end hope this helps... > What is the difference between a Control and an Element ? a control is used by the scaffolder, it is a visual representation of a property. It is a form element. > How do you change the template surrounding a page without changin the > enclosing tag ? eg. I use around my content, but sometimes I want > a different html template. It there a mechanism for this ? hmm I use different tags. But of course you can use a specialized render method that renders multiple sorounding html according to some conditions... regards, -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Mon Jan 9 18:01:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 9 Jan 2006 15:01:10 -0800 Subject: [Nitro] [PATCH] Controls patch + bugfix In-Reply-To: <43C222FA.1060908@gmail.com> References: <43BE288D.9000208@gmail.com> <43BE7299.7020000@gmail.com> <43C222FA.1060908@gmail.com> Message-ID: On 1/9/06, Jonas Pfenniger wrote: > > Btw, I'm not very satified with my PasswordControl implementation > because it puts the password in clear in the html. I could do something > better if I knew a generic way to tell that the field didn't change. > > > Well, it's the opposite of generic, but perhaps a hidden field and some javascript would suffice? Untested change follows: %{ } Although that could lead to someone's password being changed to a string of asterisks. Or as a different implementation, gmail has you type in the old password, then the new and makes the change on the server. Any other thoughts? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060109/32ff473b/attachment.html From george.moschovitis at gmail.com Tue Jan 10 11:08:14 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 10 Jan 2006 18:08:14 +0200 Subject: [Nitro] Nitro and Facets version In-Reply-To: <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> Message-ID: Please avoid using nitrogen/nitro in 0.26.0 These commands are not used a lot in Nitro, as Nitro does not force a structure on the directory. Prefer to use ruby run.rb in your app dir. The 0.27.0 release is coming early next week. This release will be focused to small 'details' like the utility scripts. Ie things that baffle newcomers like you. best regards, George. > I'm just now trying Nitro/Og, wanting to check out its SCGI support.It appears that if I "gen" my app I will get an SCGI-supportedconfiguration out of the box. I'm on a fresh Windows XP box with Ruby& Gems newly installed. After installing all the nitro gems, I have a"nitrogen" command but not "gen". Is the "gen" gem supposed to createan executable script called "gen", or are we supposed to keep using"nitrogen"? I'm confused, getting old I guess. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kevwil at gmail.com Tue Jan 10 11:20:56 2006 From: kevwil at gmail.com (Kevin Williams) Date: Tue, 10 Jan 2006 09:20:56 -0700 Subject: [Nitro] scgi questions In-Reply-To: <43C19E5C.3060204@neurogami.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> <43C19E5C.3060204@neurogami.com> Message-ID: <683a886f0601100820l3a6b127dg67cffe1ae4c742a1@mail.gmail.com> I see in another thread that 0.27.0 is coming soon. Will scgi be fixedin that release? On 1/8/06, James Britt wrote:> rob wrote:> > I don't know specifically about your issue but a clue could be> > obtained by typing:> >> > grep -r 9999 /path/to/nitro/directory> >> > then looking at the corresponding file. This will reveal where 9999> > is being hard-coded, if it is.>> That value is assigned as the port number in lib/nitro/server.rb.>> My hunch is that configuration values are never passed on to the actual> Webrick server, so it just stay at the default.>> As an experiment I added faulty markup to scgi.yaml; I got a parsing> error when I ran scgi_ctl, so I know it is finding and reading the> config file. But after that, it seems the values are never properly> passed on.>>> James>> -->> http://www.ruby-doc.org - Ruby Help & Documentation> http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted> http://www.rubystuff.com - The Ruby Store for Ruby Stuff> http://www.jamesbritt.com - Playing with Better Toys> http://www.30secondrule.com - Building Better Tools> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From george.moschovitis at gmail.com Tue Jan 10 11:28:56 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 10 Jan 2006 18:28:56 +0200 Subject: [Nitro] scgi questions In-Reply-To: <683a886f0601100820l3a6b127dg67cffe1ae4c742a1@mail.gmail.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> <43C19E5C.3060204@neurogami.com> <683a886f0601100820l3a6b127dg67cffe1ae4c742a1@mail.gmail.com> Message-ID: I will test the SCGI before releasing on Linux. regards, George. On 1/10/06, Kevin Williams wrote: > I see in another thread that 0.27.0 is coming soon. Will scgi be fixedin that release? > > On 1/8/06, James Britt wrote:> rob wrote:> > I don't know specifically about your issue but a clue could be> > obtained by typing:> >> > grep -r 9999 /path/to/nitro/directory> >> > then looking at the corresponding file. This will reveal where 9999> > is being hard-coded, if it is.>> That value is assigned as the port number in lib/nitro/server.rb.>> My hunch is that configuration values are never passed on to the actual> Webrick server, so it just stay at the default.>> As an experiment I added faulty markup to scgi.yaml; I got a parsing> error when I ran scgi_ctl, so I know it is finding and reading the> config file. But after that, it seems the values are never properly> passed on.>>> James>> -->> http://www.ruby-doc.org - Ruby Help & Documentation> http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted> http://www.rubystuff.com - The Ruby Store for Ruby Stuff> http://www.jamesbritt.com - Playing with Better Toys> http://! > www.30secondrule.com - Building Better Tools> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > > --Cheers, > Kevin > "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Tue Jan 10 12:47:20 2006 From: kashia at vfemail.net (Kashia Buch) Date: Tue, 10 Jan 2006 18:47:20 +0100 Subject: [Nitro] [PATCH] TableHelper sort implementation (needs fix) In-Reply-To: References: Message-ID: Aaargh, table.rb needs a require 'glue/uri' require 'glue/configuration' at the top. I promise, next time I'll: a) unit test my changes b) write unit tests for my own changes The changes I made, only work when you try it with the pager (because the table.rb misses a few includes). So please forgive me. Tomorrow I'll post a fix + unit tests for the new functions. Question on darcs: can I "revert" a patch, then make the little fix and record the patch again? (so to say, everyone who got that patch now, just throws it away and takes my new patch) Or I'll just make that trivial fix (+ unit tests) and submit that. Sorry again, Kash From kevwil at gmail.com Tue Jan 10 11:19:58 2006 From: kevwil at gmail.com (Kevin Williams) Date: Tue, 10 Jan 2006 09:19:58 -0700 Subject: [Nitro] Nitro and Facets version In-Reply-To: References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> Message-ID: <683a886f0601100819t646e14e3g20985ce02fdac1d6@mail.gmail.com> I tried nitrogen but it didn't work. I created my own gen.bat to callthe correct "gen" buried within the gems folders, and it worked like acharm. On 1/10/06, George Moschovitis wrote:> Please avoid using nitrogen/nitro in 0.26.0>> These commands are not used a lot in Nitro, as Nitro does not force a> structure on the directory. Prefer to use>> ruby run.rb in your app dir.>>> The 0.27.0 release is coming early next week. This release will be> focused to small 'details' like the utility scripts. Ie things that> baffle newcomers like you.>> best regards,> George.>> > I'm just now trying Nitro/Og, wanting to check out its SCGI support.It appears that if I "gen" my app I will get an SCGI-supportedconfiguration out of the box. I'm on a fresh Windows XP box with Ruby& Gems newly installed. After installing all the nitro gems, I have a"nitrogen" command but not "gen". Is the "gen" gem supposed to createan executable script called "gen", or are we supposed to keep using"nitrogen"? I'm confused, getting old I guess.>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net From Aleksi.Niemela at cs.helsinki.fi Tue Jan 10 13:24:14 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Tue, 10 Jan 2006 20:24:14 +0200 Subject: [Nitro] [PATCH] TableHelper sort implementation (needs fix) In-Reply-To: References: Message-ID: <43C3FBCE.7080006@cs.helsinki.fi> Kashia Buch wrote: >I promise, next time I'll: > >a) unit test my changes >b) write unit tests for my own changes > > > Great ideas! Thanks for your patches. I've been going to write table helper sorter by myself but now it's not needed :). >Question on darcs: can I "revert" a patch, then make the little fix and record the patch again? (so to say, everyone who got that patch now, just throws it away and takes my new patch) >Or I'll just make that trivial fix (+ unit tests) and submit that. > > Perhaps you'd like to take a look at Darcs manual: http://abridgegame.org/darcs/manual/node6.html#SECTION00623000000000000000 You like to do "unrecord", or completely wipe out your changes and "revert" to pristine tree. We rest probably want to do "rollback" to your patch. http://abridgegame.org/darcs/manual/node7.html#SECTION00782000000000000000 But what do I know, I'm completely newbie to Darcs myself. - Aleksi From kashia at vfemail.net Tue Jan 10 15:06:40 2006 From: kashia at vfemail.net (Kashia Buch) Date: Tue, 10 Jan 2006 21:06:40 +0100 Subject: [Nitro] [PATCH] TableHelper sort implementation In-Reply-To: References: Message-ID: Hi, got to work on the new patch a little earlier, so here it is :) this time with more unit tests, which pass as well ;) Please "darcs rollback" the first patch if you applied that. Kash -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: tablehelper_sort_implementation_2.tar.bz2 Type: application/bzip2 Size: 4378 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060110/dd41d0a2/attachment.bin From kashia at vfemail.net Tue Jan 10 15:29:54 2006 From: kashia at vfemail.net (Kashia Buch) Date: Tue, 10 Jan 2006 21:29:54 +0100 Subject: [Nitro] [PATCH] TableHelper sort implementation (needs fix) In-Reply-To: <43C3FBCE.7080006@cs.helsinki.fi> References: <43C3FBCE.7080006@cs.helsinki.fi> Message-ID: Hi, > You like to do "unrecord", or completely wipe out your changes and > "revert" to pristine tree. We rest probably want to do "rollback" to > your patch. > > http://abridgegame.org/darcs/manual/node7.html#SECTION00782000000000000000 Thanks, I'll have a look at that :) I just don't want to enter some command which deletes all my changes, removes the patch and then probably even kicks my butt all at once ;) I'm just too new using darcs. The idea of a patch only RCS is really cool, though I'm more comfortable with GNU Arch. I'll have to use it awhile to get used to the idea which stands behind darcs :) Anyway, I'm happy someone can need my patch :D please tell me when anything's missing :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From Aleksi.Niemela at cs.helsinki.fi Tue Jan 10 17:26:53 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Wed, 11 Jan 2006 00:26:53 +0200 Subject: [Nitro] Og.setup benchmarking results Message-ID: <43C434AD.50502@cs.helsinki.fi> Hello, Tim was claiming Og.setup was too slow so I made a benchmark out of his partial schema. 29 tables and some 70 constraints were created in PostgreSQL. I measured total time, time spent at sql execution in ruby postgres bindings (I use postgres-pr, the pure ruby lib) or in postgres itself. Did the tests two times against a clean, freshly initiated database and then two reruns. Here are the results, hopefully they come through the mail. Fresh run Rerun Total PSQL Og Total PSQL Og With sql printing 18.16 13.68 4.48 2.89 0.49 2.4 18.49 14.04 4.45 2.86 0.48 2.38 Without sql printing 11.78 9.83 1.95 2.26 0.19 2.07 11.56 9.7 1.86 2.28 0.19 2.09 I see no point trying to make Og side faster. Without debug prints Og uses 20% of real time trying to generate SQL to execute in setup. In rerun practically no SQL code executed so the same 2 secs gets spent in Og. Maybe some portion of it could be shaved off. I didn't measure how long will all the enchanting take out of that 2 secs. Web app with complex Og schema won't have huge performance under CGI. But I wouldn't expect so. - Aleksi From george.moschovitis at gmail.com Wed Jan 11 04:29:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 11:29:18 +0200 Subject: [Nitro] Og.setup benchmarking results In-Reply-To: <43C434AD.50502@cs.helsinki.fi> References: <43C434AD.50502@cs.helsinki.fi> Message-ID: > Web app with complex Og schema won't have huge performance under CGI. > But I wouldn't expect so. CGI is next to useless with Nitro... BTW there is a nice option: Og.create_schema = false this will speed up Og.setup even further (useful for live/production applications) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Jan 11 04:31:12 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 11:31:12 +0200 Subject: [Nitro] [PATCH] TableHelper sort implementation (needs fix) In-Reply-To: References: <43C3FBCE.7080006@cs.helsinki.fi> Message-ID: > Anyway, I'm happy someone can need my patch :D please tell me when anything's missing :) Will use your patch too ;-) thanks ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rob at motionpath.com Wed Jan 11 04:32:52 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 11 Jan 2006 09:32:52 +0000 Subject: [Nitro] Og.setup benchmarking results In-Reply-To: <43C434AD.50502@cs.helsinki.fi> References: <43C434AD.50502@cs.helsinki.fi> Message-ID: <1136971972.10521.24.camel@robs-p4> It's worth keeping in mind you don't often start webapps so the startup speed has little bearing on the actual CGI applications performance. When Og does become a bottleneck in bigger web apps it's often not too hard to convert just that bit to use more SQL. On Wed, 2006-01-11 at 00:26 +0200, Aleksi Niemela wrote: > Hello, > > Tim was claiming Og.setup was too slow so I made a benchmark out of his > partial schema. 29 tables and some 70 constraints were created in > PostgreSQL. I measured total time, time spent at sql execution in ruby > postgres bindings (I use postgres-pr, the pure ruby lib) or in postgres > itself. Did the tests two times against a clean, freshly initiated > database and then two reruns. > > Here are the results, hopefully they come through the mail. > > > Fresh run > > > Rerun > > > Total PSQL Og > Total PSQL Og > With sql printing 18.16 13.68 4.48 > 2.89 0.49 2.4 > > 18.49 14.04 4.45 > 2.86 0.48 2.38 > > > > > > > > > Without sql printing > > > > > > > > 11.78 9.83 1.95 > 2.26 0.19 2.07 > > 11.56 9.7 1.86 > 2.28 0.19 2.09 > > > I see no point trying to make Og side faster. Without debug prints Og > uses 20% of real time trying to generate SQL to execute in setup. In > rerun practically no SQL code executed so the same 2 secs gets spent in > Og. Maybe some portion of it could be shaved off. I didn't measure how > long will all the enchanting take out of that 2 secs. > > Web app with complex Og schema won't have huge performance under CGI. > But I wouldn't expect so. > > - Aleksi > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From guillaume.pierronnet at gmail.com Wed Jan 11 04:37:58 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Wed, 11 Jan 2006 10:37:58 +0100 Subject: [Nitro] scgi questions In-Reply-To: References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> <43C19E5C.3060204@neurogami.com> <683a886f0601100820l3a6b127dg67cffe1ae4c742a1@mail.gmail.com> Message-ID: <6a7d49ca0601110137s371b4043v@mail.gmail.com> i'm currently patching Nitro to support scgi more "naturally", by respecting Nitro::Server.port setting for example. I think removing the scgi_service script and merge it into nitro/server/runner.rb would clarify things a lot. A near-zero configuration for scgi will be useful. Expect a patch soon ;) Guillaume 2006/1/10, George Moschovitis : > I will test the SCGI before releasing on Linux. > > regards, > George. > > On 1/10/06, Kevin Williams wrote: > > I see in another thread that 0.27.0 is coming soon. Will scgi be fixedin that release? > > > > On 1/8/06, James Britt wrote:> rob wrote:> > I don't know specifically about your issue but a clue could be> > obtained by typing:> >> > grep -r 9999 /path/to/nitro/directory> >> > then looking at the corresponding file. This will reveal where 9999> > is being hard-coded, if it is.>> That value is assigned as the port number in lib/nitro/server.rb.>> My hunch is that configuration values are never passed on to the actual> Webrick server, so it just stay at the default.>> As an experiment I added faulty markup to scgi.yaml; I got a parsing> error when I ran scgi_ctl, so I know it is finding and reading the> config file. But after that, it seems the values are never properly> passed on.>>> James>> -->> http://www.ruby-doc.org - Ruby Help & Documentation> http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted> http://www.rubystuff.com - The Ruby Store for Ruby Stuff> http://www.jamesbritt.com - Playing with Better Toys> http:! > //! > > www.30secondrule.com - Building Better Tools> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > > > > --Cheers, > > Kevin > > "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Wed Jan 11 04:38:43 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 11:38:43 +0200 Subject: [Nitro] Og.setup benchmarking results In-Reply-To: <1136971972.10521.24.camel@robs-p4> References: <43C434AD.50502@cs.helsinki.fi> <1136971972.10521.24.camel@robs-p4> Message-ID: He means CGI Adapter applications... FastCGI/SCGI persists Og so there is no problem. -g. On 1/11/06, Rob Pitt wrote: > It's worth keeping in mind you don't often start webapps so the startup > speed has little bearing on the actual CGI applications performance. > > When Og does become a bottleneck in bigger web apps it's often not too > hard to convert just that bit to use more SQL. > > On Wed, 2006-01-11 at 00:26 +0200, Aleksi Niemela wrote: > > Hello, > > > > Tim was claiming Og.setup was too slow so I made a benchmark out of his > > partial schema. 29 tables and some 70 constraints were created in > > PostgreSQL. I measured total time, time spent at sql execution in ruby > > postgres bindings (I use postgres-pr, the pure ruby lib) or in postgres > > itself. Did the tests two times against a clean, freshly initiated > > database and then two reruns. > > > > Here are the results, hopefully they come through the mail. > > > > > > Fresh run > > > > > > Rerun > > > > > > Total PSQL Og > > Total PSQL Og > > With sql printing 18.16 13.68 4.48 > > 2.89 0.49 2.4 > > > > 18.49 14.04 4.45 > > 2.86 0.48 2.38 > > > > > > > > > > > > > > > > > > Without sql printing > > > > > > > > > > > > > > > > 11.78 9.83 1.95 > > 2.26 0.19 2.07 > > > > 11.56 9.7 1.86 > > 2.28 0.19 2.09 > > > > > > I see no point trying to make Og side faster. Without debug prints Og > > uses 20% of real time trying to generate SQL to execute in setup. In > > rerun practically no SQL code executed so the same 2 secs gets spent in > > Og. Maybe some portion of it could be shaved off. I didn't measure how > > long will all the enchanting take out of that 2 secs. > > > > Web app with complex Og schema won't have huge performance under CGI. > > But I wouldn't expect so. > > > > - Aleksi > > > > _______________________________________________ > > 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://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Jan 11 04:39:58 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 11:39:58 +0200 Subject: [Nitro] [PATCH] TableHelper sort implementation In-Reply-To: References: Message-ID: Kashia, will applying the latest patch I got some conflicts, can you please resend me the following file: nitro/lib/nitro/helper/table.rb just this files as a zipped attachment. Thanks in advance. -g. On 1/10/06, Kashia Buch wrote: > Hi, > > got to work on the new patch a little earlier, so here it is :) > > this time with more unit tests, which pass as well ;) > > Please "darcs rollback" the first patch if you applied that. > > Kash > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Jan 11 05:09:47 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 12:09:47 +0200 Subject: [Nitro] scgi questions In-Reply-To: <6a7d49ca0601110137s371b4043v@mail.gmail.com> References: <683a886f0601080908g72f179ch9de58905721ca461@mail.gmail.com> <43C16F26.3090105@neurogami.com> <73680480-158D-4AD9-8F04-B87A5C83E9BC@motionpath.com> <43C19E5C.3060204@neurogami.com> <683a886f0601100820l3a6b127dg67cffe1ae4c742a1@mail.gmail.com> <6a7d49ca0601110137s371b4043v@mail.gmail.com> Message-ID: > respecting Nitro::Server.port setting for example. I think removing > the scgi_service script and merge it into nitro/server/runner.rb would > clarify things a lot. > A near-zero configuration for scgi will be useful. > Expect a patch soon ;) Yeap this is useful! I would love to see a patch (I am quite busy with a lot of things at the moment). Please note that at some point in the future I would like to add an alternative method of starting Nitro applications (along with the current Run/Runner method). I have not finalized the details yet though. But Runner will stay so your scgi patch for Runner is more than welcome. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Wed Jan 11 06:56:59 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 11 Jan 2006 12:56:59 +0100 Subject: [Nitro] [PATCH] TableHelper sort implementation In-Reply-To: References: Message-ID: Yo, > will applying the latest patch I got some conflicts, > can you please resend me the following file: > > nitro/lib/nitro/helper/table.rb > > just this files as a zipped attachment. Thanks in advance. Here it is, but this actually shouldn't happen when you unrolled my previous patch like Aleksi proposed. (I couldn't try this obviously, so I don't even know if that method works) >> Please "darcs rollback" the first patch if you applied that. If you didn't get this, I didn't only pack a fix + tests, I made a whole new patch of all of my table.rb / tc_table.rb changes into a whole new patch. Please tell me how you resolved this issue :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: table.rb.tar.bz2 Type: application/bzip2 Size: 1987 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060111/9fe95120/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: tc_table.rb.tar.bz2 Type: application/bzip2 Size: 989 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060111/9fe95120/attachment-0001.bin From george.moschovitis at gmail.com Wed Jan 11 09:35:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 16:35:30 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43C01A16.5060303@neurogami.com> References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> <43C01A16.5060303@neurogami.com> Message-ID: > Dreamweaver lets you create a template that defines an entire page (what > Rials calls a 'layout'), with slots for inserting free-form content or > calls to library templates (which render small chunks of stuff; what > Rials calls 'partials'). James, I improved elements quite a bit. Now you can place xhtml files in Element.template_root (typically /element or /src/element') and Nitro automatically converts them to Elements. I also added a simple Layout helper if you want to be compatible with Rails. Not enabled by default (because i think Layout sucks). I think the new ... with the template for layout in element/layout.xhtml will be just fine for you. There are some more improvements (for example all sub-elements are now implicitly named) and some comments. check out the repo version. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Wed Jan 11 11:54:33 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 11 Jan 2006 17:54:33 +0100 Subject: [Nitro] Installing Trac Message-ID: <43C53849.9010106@gmail.com> Hello, Some patches get lost or ignored, some bugs are comming over and over, new comers wonder what's happening here without getting answers right away, the status of various nitro's parts are unknown. We could avoid all that by installing a bug tracking software. So I made a little research on the web and found that Trac supports Darcs as a backend[1] with some modifications. I wish we had something like that. What do you think ? Cheers, Jonas Pfenniger [1]: http://www.darcs.net/DarcsWiki/TracOnDarcs From george.moschovitis at gmail.com Wed Jan 11 12:03:10 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Jan 2006 19:03:10 +0200 Subject: [Nitro] Installing Trac In-Reply-To: <43C53849.9010106@gmail.com> References: <43C53849.9010106@gmail.com> Message-ID: > I wish we had something like that. What do you think ? Ok, will *try* to setup this over the next days. I hope Tasos Koutoumanos will have some time to help me with this. Btw, in the next week I plan to announce a new initiative for the further development of Nitro/Og. In short, I think that it is beneficial for the project to build a team of core developers with repository admin rights. Everyone who would like to help here, let me know. More details about this real soon ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Wed Jan 11 12:19:49 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 11 Jan 2006 18:19:49 +0100 Subject: [Nitro] Installing Trac In-Reply-To: References: <43C53849.9010106@gmail.com> Message-ID: <43C53E35.2000609@gmail.com> George Moschovitis wrote: >>I wish we had something like that. What do you think ? >> >> > >Ok, will *try* to setup this over the next days. I hope Tasos >Koutoumanos will have some time to help me with this. > > Great ! Let me know if you need some help :) >Btw, in the next week I plan to announce a new initiative for the >further development of Nitro/Og. In short, I think that it is >beneficial for the project to build a team of core developers with >repository admin rights. Everyone who would like to help here, let me >know. More details about this real soon ;-) > > Cool ! I think it's important to list the weak points of Nitro and build a map of them. You are the one who has the best overview of it and can do it. Then seek for voluteers to work on every missing part of the puzzle :) >regards, >George. > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.com > >_______________________________________________ >Nitro-general mailing list >Nitro-general at rubyforge.org >http://rubyforge.org/mailman/listinfo/nitro-general > > > From james_b at neurogami.com Wed Jan 11 13:24:32 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 11 Jan 2006 11:24:32 -0700 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> <43C01A16.5060303@neurogami.com> Message-ID: <43C54D60.40005@neurogami.com> George Moschovitis wrote: > > > James, > > I improved elements quite a bit. Now you can place xhtml files in > Element.template_root > (typically /element or /src/element') and Nitro automatically converts > them to Elements. I also added a simple Layout helper if you want to > be compatible with Rails. Not enabled by default (because i think > Layout sucks). Please don't misunderstand; I was not and am not looking for any sort of Rails compatibility. I used Rails as an example for what I consider a fairly common templating technique, one I happen to find handy, perhaps because it is familiar to me. But thanks for the changes; I'll go grab the repo stuff James From george.moschovitis at gmail.com Thu Jan 12 03:47:35 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 12 Jan 2006 10:47:35 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43C54D60.40005@neurogami.com> References: <43BF2C65.8000900@neurogami.com> <43BF3D95.9020804@neurogami.com> <43C01A16.5060303@neurogami.com> <43C54D60.40005@neurogami.com> Message-ID: > Please don't misunderstand; I was not and am not looking for any sort of no missunderstanding ;-) Keep sending your useful comments and remarks ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Jan 12 09:06:50 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 12 Jan 2006 16:06:50 +0200 Subject: [Nitro] preparing Nitro 0.27.0 Message-ID: Dear devs, Nitro 0.27.0 is scheduled for release on Monday 16 January. Please grab the repo version (glycerin) and start reporting bugs or problems (and even better, patches). The repo will be updated a lot, so pull regularly. thanks in advance, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Thu Jan 12 10:55:53 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Thu, 12 Jan 2006 16:55:53 +0100 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules Message-ID: <43C67C09.7060208@gmail.com> module Test class Item property :name end end Og creates an ogtest_item table which contains the items. When trying to access it in the AdminController, it generates a link called http://localhost:9999/admin/test::item/list which doesn't exist. It would be nice to have a link like http://localhost:9999/admin/test/item/list instead. I wish I could do this, but Nitro has too much magic that I don't understand. Cheers, zimba From chris at motionpath.com Thu Jan 12 13:48:15 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Thu, 12 Jan 2006 18:48:15 +0000 Subject: [Nitro] PATCH: Multipart forms and @params, Some Controls code updates. In-Reply-To: References: Message-ID: <6DA9B378-4418-415A-A1EA-68BF42566271@motionpath.com> ooo its a 0.27 dash ... Heres some fixes/updates to my last @params patch Hope it helps. ? Chris Farmiloe Design & Development. Motionpath Digital Media Ltd. On 5 Jan 2006, at 23:11, Bryan Soto wrote: > Just a quick note, after applying this patch there was an > additional failure in the nitro unit tests: > > 3) Failure: > test_parse_query_parameters(TestAdapterCgi) [./test/nitro/tc_cgi.rb: > 36]: > <2> expected but was > <3>. > > On 1/5/06, Chris Farmiloe wrote: > > > Happy 2006 list!... > > Haven't quiet got round to getting up to speed with the list > -99 nitro emails was my christmas present from the list ;-) > sure it's all great! > > anyway. here's some patches: > > Mostly control code related, (and there'll be more to follow including > a blob upload control), started an array control. > > > Fixed the multipart form data issues not being compatible with > the @params hash, I think I also made the params array operate like > someone on the list wanted (request[' this.that'] and request > ['this']['that'] > should both work - will maybe move this functionality to the > request [] method > if everyone things that the @params hash looks a mess. > > --next step is to make the structure_params function recursive so that > more complicated depth can be achieved with the POST data ie. > INPUTS with names: > > name=" person.name" > name="person.address.name" > name="person.address.line1 " > name="person.address.line2" > name="person.address.phone[]" > name="person.address.phone[]" > > creating the @params (request) hash as > > { > 'person' => { > 'address' => { > 'name' => 'string', > 'line1' => 'string', > 'line2' => 'string', > 'phone' => ['string','string'] > } > } > } > > > > right. home time. > > > > > > > > > > chrisfarms > Design & Development. > > > > > _______________________________________________ > 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/20060112/51474589/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro.patch.gz Type: application/x-gzip Size: 14011 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060112/51474589/attachment.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060112/51474589/attachment-0001.html From vseguip at gmail.com Thu Jan 12 15:41:34 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Thu, 12 Jan 2006 21:41:34 +0100 Subject: [Nitro] Og name clashes with Gtk2 Message-ID: Hello, I was just testing the Og library and I think it's great. However, I wanted it to integrate with a Gtk2 GUI and found that there seems to be a name clash between ruby GTK2 bindings and Og. The ruby bindings of gtk2 define the method "property" and "properties" for all descendants of Glib::Object. Apparently, this leads Og to think of them as manageable (which they are not) and crashes the program, probably due to strange accesses to Glib. There is a workaround this to only require gtk2 after setting up the connection but it will still fail since I actually want to manage GLib objects, and then "properties" clashes with the ruby -gtk2 definition of properties. Is there an easy workaround to this problem? If not, what would it take to rename the og default method lookup to something else (e.g. og_properties instead of properties, etc)? Thanks in advance for your time and help, V. Segu? P.S.: I'm posting this from another machine but if needed I could supply a simple program to illustrate the problem. From rainhead at gmail.com Thu Jan 12 19:49:09 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Thu, 12 Jan 2006 18:49:09 -0600 Subject: [Nitro] Nicaragua Message-ID: <971C30B3-A5E9-488E-B1D1-7BCBA72E14EC@gmail.com> Friends, I'm in Nicaragua for the next ~5 months, and will probably not have much opportunity to contribute to this project. I'm working on a wireless freenet, which really doesn't leave me with much time for other computer-related things. I look forward to seeing what becomes of the Nitro project in this time, and will keep an eye on the list. Cheers, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2410 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060112/0b58b26a/attachment.bin From timh at dirtymonday.net Thu Jan 12 23:55:22 2006 From: timh at dirtymonday.net (TimH) Date: Thu, 12 Jan 2006 20:55:22 -0800 Subject: [Nitro] newer postgres interface snapshots In-Reply-To: <51943115-9A2A-40B1-B1E7-DA4A54B0B671@motionpath.com> References: <20060102221838.07ab6951.timh@dirtymonday.net> <29286B3E-6A1A-4448-88EE-BEBB1EF8F1C7@motionpath.com> <20060104111703.1021c30f.timh@dirtymonday.net> <51943115-9A2A-40B1-B1E7-DA4A54B0B671@motionpath.com> Message-ID: <20060112205522.39c4eaed.timh@dirtymonday.net> On Wed, 4 Jan 2006 20:06:41 +0000 rob wrote: > What versions of PostgreSQL have you observed this with? If it is a > fairly recent version of PostgresSQL or caused by one of the small > number of routines I added to the postgres adapter for use by Og > (such as an analog to the MySQL adapters list_tables) I will still > look at it before the end of the month even if it is the postgres > adapter and not Nitro. I plan to start hunting down what needs to change in the psql store code to work with the ruby-postgres API changes. Is this something you are looking at as well? If soperhaps we should collaborate some. I could make my darcs repository available and/or viceversa... --TimH From george.moschovitis at gmail.com Fri Jan 13 04:59:59 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Jan 2006 11:59:59 +0200 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules In-Reply-To: <43C67C09.7060208@gmail.com> References: <43C67C09.7060208@gmail.com> Message-ID: Zimb, ok will check this! -g. On 1/12/06, Jonas Pfenniger wrote: > > module Test > class Item > property :name > end > end > > Og creates an ogtest_item table which contains the items. > > When trying to access it in the AdminController, it generates a link > called http://localhost:9999/admin/test::item/list which doesn't exist. > > It would be nice to have a link like > http://localhost:9999/admin/test/item/list instead. I wish I could do > this, but Nitro has too much magic that I don't understand. > > > Cheers, > zimba > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 13 05:03:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Jan 2006 12:03:18 +0200 Subject: [Nitro] Og name clashes with Gtk2 In-Reply-To: References: Message-ID: Hmm, interesting (and annoying) bug report :( Will have to think for the best solution to this. BTW, please note that properties is not a feauture of Og. You can use objects with properties on non-db projects. regards, George. On 1/12/06, vseguip at gmail.com wrote: > Hello, I was just testing the Og library and I think it's great. > However, I wanted it to integrate with a Gtk2 GUI and found that there > seems to be a name clash between ruby GTK2 bindings and Og. > > The ruby bindings of gtk2 define the method "property" and > "properties" for all descendants of Glib::Object. Apparently, this > leads Og to think of them as manageable (which they are not) and > crashes the program, probably due to strange accesses to Glib. > > There is a workaround this to only require gtk2 after setting up the > connection but it will still fail since I actually want to manage GLib > objects, and then "properties" clashes with the ruby -gtk2 definition > of properties. > > Is there an easy workaround to this problem? If not, what would it > take to rename the og default method lookup to something else (e.g. > og_properties instead of properties, etc)? > > > Thanks in advance for your time and help, > V. Segu? > > > P.S.: I'm posting this from another machine but if needed I could > supply a simple program to illustrate the problem. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 13 05:04:04 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Jan 2006 12:04:04 +0200 Subject: [Nitro] Nicaragua In-Reply-To: <971C30B3-A5E9-488E-B1D1-7BCBA72E14EC@gmail.com> References: <971C30B3-A5E9-488E-B1D1-7BCBA72E14EC@gmail.com> Message-ID: Hello peter, I wish you the best and hope to talk with you soon ;-) -g. On 1/13/06, Peter Abrahamsen wrote: > Friends, > > I'm in Nicaragua for the next ~5 months, and will probably not have > much opportunity to contribute to this project. I'm working on a > wireless freenet, which really doesn't leave me with much time for > other computer-related things. I look forward to seeing what becomes > of the Nitro project in this time, and will keep an eye on the list. > > Cheers, > > Peter > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Fri Jan 13 05:28:00 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Fri, 13 Jan 2006 11:28:00 +0100 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules In-Reply-To: References: <43C67C09.7060208@gmail.com> Message-ID: <43C780B0.60304@gmail.com> Great G :) I'm building a mutli-module application and this will be a great help for me. It will be ready in two months or so. George Moschovitis wrote: >Zimb, > >ok will check this! > >-g. > >On 1/12/06, Jonas Pfenniger wrote: > > >>module Test >> class Item >> property :name >> end >>end >> >>Og creates an ogtest_item table which contains the items. >> >>When trying to access it in the AdminController, it generates a link >>called http://localhost:9999/admin/test::item/list which doesn't exist. >> >>It would be nice to have a link like >>http://localhost:9999/admin/test/item/list instead. I wish I could do >>this, but Nitro has too much magic that I don't understand. >> >> >>Cheers, >> zimba >>_______________________________________________ >>Nitro-general mailing list >>Nitro-general at rubyforge.org >>http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.com > >_______________________________________________ >Nitro-general mailing list >Nitro-general at rubyforge.org >http://rubyforge.org/mailman/listinfo/nitro-general > > > From aidan at yoyo.org Fri Jan 13 06:53:55 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 13 Jan 2006 22:53:55 +1100 Subject: [Nitro] BUG + PATCH: Comparison of managed Og objects Message-ID: I had an annoying bug where I had an array of Og managed objects, and calling array.include?( obj ) on an object that blatantly wasn't in the array was returning true. As it turns out, in manager.rb there is a redefinition for the '==' method, which is buggy - it compares the primary keys of the two objects but doesn't compare their classes. Here is a fix. My one possible issue is that there is a great big DON'T DO THIS!!! comment just before that particular area of the code. Is this something that perhaps needs removing altogether? Anyway, the fix now compares class types and then primary keys. Aidan (a.k.a. five on #nitro) --- manager.rb 2006-01-13 22:49:03.000000000 +1100 +++ /tmp/manager.rb 2006-01-13 22:48:53.000000000 +1100 @@ -104,7 +104,11 @@ # DON'T DO THIS!!! klass.module_eval %{ def ==(other) - other ? @#{klass.primary_key.symbol} == other.# {klass.primary_key.symbol} : false + if( other.instance_of?(#{klass}) && @# {klass.primary_key.symbol} == other.#{klass.primary_key.symbol} ) + true + else + false + end end } From vseguip at gmail.com Fri Jan 13 07:08:50 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Fri, 13 Jan 2006 13:08:50 +0100 Subject: [Nitro] Og name clashes with Gtk2 In-Reply-To: References: Message-ID: I attach a patch that renames :properties to og_properties. It will alias :og_properties to :properties, so stuff ought to work equally well. To avoid clashes you just have to define the global variable $DONT_ALIAS_OG_PROPERTIES to true before requiring og. The patch quality is poor as it is a blind find/replace of "properties" with "og_properties" (more meant to be a workaround for anyone interested) so use at your own risk :-). V. Segu? -------------- next part -------------- A non-text attachment was scrubbed... Name: og_properties.patch Type: text/x-patch Size: 11270 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060113/7212bf9c/attachment.bin From george.moschovitis at gmail.com Fri Jan 13 07:47:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Jan 2006 14:47:34 +0200 Subject: [Nitro] BUG + PATCH: Comparison of managed Og objects In-Reply-To: References: Message-ID: thanks, added the fix, but as you said, this code may be removed... -g. On 1/13/06, Aidan Rogers wrote: > I had an annoying bug where I had an array of Og managed objects, and > calling array.include?( obj ) on an object that blatantly wasn't in > the array was returning true. > > As it turns out, in manager.rb there is a redefinition for the '==' > method, which is buggy - it compares the primary keys of the two > objects but doesn't compare their classes. > > Here is a fix. > > My one possible issue is that there is a great big DON'T DO THIS!!! > comment just before that particular area of the code. Is this > something that perhaps needs removing altogether? > > Anyway, the fix now compares class types and then primary keys. > > Aidan (a.k.a. five on #nitro) > > --- manager.rb 2006-01-13 22:49:03.000000000 +1100 > +++ /tmp/manager.rb 2006-01-13 22:48:53.000000000 +1100 > @@ -104,7 +104,11 @@ > # DON'T DO THIS!!! > klass.module_eval %{ > def ==(other) > - other ? @#{klass.primary_key.symbol} == other.# > {klass.primary_key.symbol} : false > + if( other.instance_of?(#{klass}) && @# > {klass.primary_key.symbol} == other.#{klass.primary_key.symbol} ) > + true > + else > + false > + end > end > } > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From vseguip at gmail.com Fri Jan 13 10:56:03 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Fri, 13 Jan 2006 16:56:03 +0100 Subject: [Nitro] [Bug] Og creates uneeded when using join_many and psqlstore Message-ID: Hi, if I execute the tc_join_psql.rb with a psql store it will create four tables, one for Article, one for Category, and 2 join tables, one for ArticleToCategory and an uneeded table with a primary key consisting of article_oid & category_oid that do *not* really reference the foreign oid's tables. If I execute with sqlite store, it will correctly create only 3 tables. Og version: Glycerin (downloaded from repo) pgsql version: 0.7.1 (Ubuntu package) SQL of the useless (?) table: -- Table: ogj_tc_join_article_tc_join_category -- DROP TABLE ogj_tc_join_article_tc_join_category; CREATE TABLE ogj_tc_join_article_tc_join_category ( article_oid int4 NOT NULL, category_oid int4 NOT NULL, CONSTRAINT ogj_tc_join_article_tc_join_category_pkey PRIMARY KEY (article_oid, category_oid) ) WITH OIDS; ALTER TABLE ogj_tc_join_article_tc_join_category OWNER TO vseguip; Cheers, V.Segu? From guillaume.pierronnet at gmail.com Fri Jan 13 11:28:37 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Fri, 13 Jan 2006 17:28:37 +0100 Subject: [Nitro] nitro scgi support improvement Message-ID: <6a7d49ca0601130828q77471248n@mail.gmail.com> hi all, i'm working on improving SCGI support in Nitro. Here is a preliminary patch. For now, i simplified a lot the process of starting a "SCGIfied" nitro app. You just need to launch './run.rb --scgi', avoiding the use of proto/scripts/scgi_* scripts. Nitro::Server.address and Nitro::Server.port settings are used. You can directly pass options to SCGIProcessor with Nitro::Server.options hash. Look at the patch for all possible options. I'll add the Drb management support. Feedbacks and suggestions are welcome. Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: scgi_patch.gz Type: application/x-gzip Size: 2687 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060113/f0fc155f/attachment.gz From Aleksi.Niemela at cs.helsinki.fi Fri Jan 13 19:14:24 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Sat, 14 Jan 2006 02:14:24 +0200 Subject: [Nitro] nitro scgi support improvement In-Reply-To: <6a7d49ca0601130828q77471248n@mail.gmail.com> References: <6a7d49ca0601130828q77471248n@mail.gmail.com> Message-ID: <43C84260.5070406@cs.helsinki.fi> guillaume pierronnet wrote: >i'm working on improving SCGI support in Nitro. Here is a preliminary patch. > >For now, i simplified a lot the process of starting a "SCGIfied" nitro >app. You just need to launch './run.rb --scgi', avoiding the use of >proto/scripts/scgi_* scripts. > > > Hello, thanks for your patch! Attached other devs can find the same patch in Darcs format. Guillaume, you know that we work with Darcs thesedays? I tested this patch to the extent that I managed to get Apache to serve and with Nitro serving SCGI on non-standard port by changing gen generated default app just a little (to set Nitro::Server.port basically). Oh, and this was on Windows. I did not test scgi_ctl or service utilities. But I've considered to alter the daemonizing to work also under Windows using Win32 Service APIs. I'm not sure what that Drb thingie is used for but perhaps it's for administration to hook additional Nitro apps on constantly running Nitro SCGI server. Let me know if some of the patch tar.gz, gzip and windows zipped formats didn't work for you so I know what to use in the future. - Aleksi -------------- next part -------------- A non-text attachment was scrubbed... Name: guillaumes_patch_2.zip Type: application/x-zip-compressed Size: 4705 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060113/63d7fd03/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: guillaumes_patch.gz Type: application/x-gzip Size: 4663 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060113/63d7fd03/attachment.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: guillaumes_patch.tar.gz Type: application/x-gzip Size: 4771 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060113/63d7fd03/attachment-0001.gz From rob at motionpath.com Sat Jan 14 07:24:53 2006 From: rob at motionpath.com (Rob Pitt) Date: Sat, 14 Jan 2006 12:24:53 +0000 Subject: [Nitro] Og name clashes with Gtk2 In-Reply-To: References: Message-ID: <1137241493.10521.37.camel@robs-p4> I noticed some discussion on IRC about changing the method name for properties. I am against this as some of our libraries do use the property method and i think it is well named. A better solution would be to change the manageable check to be more intelligent. Perhaps objects should export a method can_be_og_managed? or similar. n Fri, 2006-01-13 at 12:03 +0200, George Moschovitis wrote: > Hmm, interesting (and annoying) bug report :( Will have to think for > the best solution to this. > BTW, please note that properties is not a feauture of Og. You can use > objects with properties on non-db projects. > > regards, > George. > > On 1/12/06, vseguip at gmail.com wrote: > > Hello, I was just testing the Og library and I think it's great. > > However, I wanted it to integrate with a Gtk2 GUI and found that there > > seems to be a name clash between ruby GTK2 bindings and Og. > > > > The ruby bindings of gtk2 define the method "property" and > > "properties" for all descendants of Glib::Object. Apparently, this > > leads Og to think of them as manageable (which they are not) and > > crashes the program, probably due to strange accesses to Glib. > > > > There is a workaround this to only require gtk2 after setting up the > > connection but it will still fail since I actually want to manage GLib > > objects, and then "properties" clashes with the ruby -gtk2 definition > > of properties. > > > > Is there an easy workaround to this problem? If not, what would it > > take to rename the og default method lookup to something else (e.g. > > og_properties instead of properties, etc)? > > > > > > Thanks in advance for your time and help, > > V. Segu? > > > > > > P.S.: I'm posting this from another machine but if needed I could > > supply a simple program to illustrate the problem. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Sat Jan 14 07:27:55 2006 From: rob at motionpath.com (Rob Pitt) Date: Sat, 14 Jan 2006 12:27:55 +0000 Subject: [Nitro] nitro scgi support improvement In-Reply-To: <43C84260.5070406@cs.helsinki.fi> References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> Message-ID: <1137241675.10521.40.camel@robs-p4> I am unsure how SCGI works but if it is anything like FastCGI you need Drb so that the multiple spawned FastCGI processes can share sessions. On Sat, 2006-01-14 at 02:14 +0200, Aleksi Niemela wrote: > guillaume pierronnet wrote: > > >i'm working on improving SCGI support in Nitro. Here is a preliminary patch. > > > >For now, i simplified a lot the process of starting a "SCGIfied" nitro > >app. You just need to launch './run.rb --scgi', avoiding the use of > >proto/scripts/scgi_* scripts. > > > > > > > Hello, > > thanks for your patch! Attached other devs can find the same patch in > Darcs format. Guillaume, you know that we work with Darcs thesedays? > > I tested this patch to the extent that I managed to get Apache to serve > and with Nitro serving SCGI on non-standard port by changing gen > generated default app just a little (to set Nitro::Server.port > basically). Oh, and this was on Windows. I did not test scgi_ctl or > service utilities. But I've considered to alter the daemonizing to work > also under Windows using Win32 Service APIs. > > I'm not sure what that Drb thingie is used for but perhaps it's for > administration to hook additional Nitro apps on constantly running Nitro > SCGI server. > > Let me know if some of the patch tar.gz, gzip and windows zipped formats > didn't work for you so I know what to use in the future. > > - Aleksi > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Sun Jan 15 06:13:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 15 Jan 2006 13:13:23 +0200 Subject: [Nitro] nitro scgi support improvement In-Reply-To: <1137241675.10521.40.camel@robs-p4> References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> <1137241675.10521.40.camel@robs-p4> Message-ID: On 1/14/06, Rob Pitt wrote: > I am unsure how SCGI works but if it is anything like FastCGI you need > Drb so that the multiple spawned FastCGI processes can share sessions. Correct, you need DRB sessions for SCGI, just like in FCGI -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Sun Jan 15 07:49:45 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 15 Jan 2006 13:49:45 +0100 Subject: [Nitro] [PATCH] Prototype ACGI support Message-ID: Hi all, yesterday I spent half of the day, just to implement ACGI. Result: ACGI seemed nice at first, but on my computer it is unusable. This patch is _not_ for production use, it's only for those who want to experiment with it a bit. Maybe it works better at someone elses computer, I seem to have problems with file locks on my computer (which actually shouldn't happen) So, for those who want to take a look, this patch doesn't break anything, it just adds another cgi handler. Usage: * copy acgi.c and Makefile.acgi to your public/ folder. * in public/: make -f Makefile.acgi * edit your .htaccess file to use acgi.cgi instead of fcgi/cgi.rb * Then just point your browser to your application. If you enabled error loggin in Apache, "tail -f" it to get an idea on how your program is doing. What it should doing is: start the Nitro application once (it uses the normal rub.rb) and handle the incoming requests from the browser. The idea from acgi is quite nice for small applications (if it would work correctly). It creates a server (nitro application) and locks server.lock in /tmp/acgi_ipc/. For each request from the browser it locks client.lock, processes the request and unlocks the client.lock again. The server will stay started for all requests. All this is done by the acgi.c program so it works very fast. Blocking lock requests handle concurrent requests. Well, since I spent this half day getting it to work, maybe someone can make use of it, it may be of educational value for someone, it may even work perfectly for someone. Have a nice day, Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Sun Jan 15 13:21:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 15 Jan 2006 10:21:47 -0800 Subject: [Nitro] nitro scgi support improvement In-Reply-To: References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> <1137241675.10521.40.camel@robs-p4> Message-ID: On 1/15/06, George Moschovitis wrote: > > On 1/14/06, Rob Pitt wrote: > > I am unsure how SCGI works but if it is anything like FastCGI you need > > Drb so that the multiple spawned FastCGI processes can share sessions. > > Correct, you need DRB sessions for SCGI, just like in FCGI > > -g. > > For anyone searching the archive later, I'll mention File based sessions work for FCGI as well. Probably slower, but at least you can build up to a DRB session as needed. And how does one know they need to do this? If you have multiple processes running, and you perform some action, i.e. log on, that should store info in that user's session, and on a later request that info mysteriously disappears and the user has to log on _again_, you're multiple processes are storing info per process. You need to switch to File or DRB storage so that all the processes store and retrieve the session info from one place, thus sharing the data. No doubt everyone on the list knows this, but for some newcomer to how servers and browsers interact in a session based web app (me for example a few months ago), it was an odd thing. Maybe this will spare some other newcomer. Or perhaps the FCGI, SCGI and potentially ACGI adapters should default to File based session info? I'll see about a patch if anyone thinks it's an okay idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060115/0a45b553/attachment.html From bryan.a.soto at gmail.com Sun Jan 15 13:42:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 15 Jan 2006 10:42:10 -0800 Subject: [Nitro] [PATCH] Prototype ACGI support In-Reply-To: References: Message-ID: Hi Kashia, I think you forgot to attach the patch. Just curious, google seems to think ACGI is Mac only. Is that the case? I was going to try it out, but I'm on WinXP and Linux. Thanks, Bryan On 1/15/06, Kashia Buch wrote: > > Hi all, > > yesterday I spent half of the day, just to implement ACGI. Result: ACGI > seemed nice at first, but on my computer it is unusable. This patch is _not_ > for production use, it's only for those who want to experiment with it a > bit. Maybe it works better at someone elses computer, I seem to have > problems with file locks on my computer (which actually shouldn't happen) > > So, for those who want to take a look, this patch doesn't break anything, > it just adds another cgi handler. > > Usage: > > * copy acgi.c and Makefile.acgi to your public/ folder. > * in public/: make -f Makefile.acgi > * edit your .htaccess file to use acgi.cgi instead of fcgi/cgi.rb > * Then just point your browser to your application. > > If you enabled error loggin in Apache, "tail -f" it to get an idea on how > your program is doing. What it should doing is: start the Nitro application > once (it uses the normal rub.rb) and handle the incoming requests from the > browser. > > The idea from acgi is quite nice for small applications (if it would work > correctly). It creates a server (nitro application) and locks server.lockin /tmp/acgi_ipc/. For each request from the browser it locks > client.lock, processes the request and unlocks the client.lock again. > The server will stay started for all requests. > All this is done by the acgi.c program so it works very fast. Blocking > lock requests handle concurrent requests. > > Well, since I spent this half day getting it to work, maybe someone can > make use of it, it may be of educational value for someone, it may even work > perfectly for someone. > > Have a nice day, > > Kash > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060115/adcb5b2c/attachment.html From kashia at vfemail.net Sun Jan 15 16:14:02 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 15 Jan 2006 22:14:02 +0100 Subject: [Nitro] [PATCH] Prototype ACGI support In-Reply-To: References: Message-ID: Bugger, seem to forget this all the time :) Sorry for that again :) Kash -------------- next part -------------- A non-text attachment was scrubbed... Name: acgi.tar.bz2 Type: application/bzip2 Size: 6563 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060115/d17dd1e1/attachment.bin From kashia at vfemail.net Sun Jan 15 16:18:14 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 15 Jan 2006 22:18:14 +0100 Subject: [Nitro] [PATCH] Prototype ACGI support In-Reply-To: References: Message-ID: Hi, > I think you forgot to attach the patch. Yeah, sorry ^^; Attached it to a reply to myself.. (sometimes I could just hit myself..) > Just curious, google seems to think ACGI is Mac only. Is that the case? I > was going to try it out, but I'm on WinXP and Linux. AFAICS ACGI is portable to all Systems with POSIX support. There doesn't seem to be anything in the C file which would prevent anyone on Linux or Cygwin from using it. Have fun experimenting :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Jan 15 18:11:05 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 16 Jan 2006 00:11:05 +0100 Subject: [Nitro] Speed up SELECTS (using PSQL VIEWS) Message-ID: Hi, it seemed to me nitro was a bit slow for heavily normalized databases, but I found a way around it using PostgreSQL VIEWs. Maybe someone else can tell me, if there's such a function already in Nitro I just didn't discover? would be nice. So, on to my example. Suppose you have a model like class File < Nitro::Controller is Taggable property :title, String has_one :filetype, FileType # ... blabla end using it in a xhtml like: #{i.title} : #{i.tags.join(", ")} will query the database for each tag, which makes Og encredibly inefficient. Now, if you do this: * create an additional View class class FileView < Nitro::Controller #is ViewOnly # << something like this would be cool though property :title, String property :tags, String property :filetype, String # this should be done automaticly/more efficient by Glue::ViewOnly def add_tag=; raise "write disabled"; end def filetype=; raise "write disabled"; end def filetype_oid=; raise "write disabled"; end end * create a VIEW in psql CREATE VIEW ogviewfile AS SELECT c.oid, c.title, array_to_string(ARRAY(SELECT ogtag.name FROM ogtag,ogj_file_tag WHERE ogj_file_tag.container_oid=c.oid AND ogj_file_tag.tag_oid=ogtag.oid), ', ') AS tags, f.filetype FROM ogfile c LEFT OUTER JOIN ogfiletype f ON (f.oid = c.filetype_oid); obviously create the view, before you execute your nitro/og project, since og would create a new ogviewfile table, which we don't want. (Use normal, INNER joins, to get still better speed..., the ARRAY(subquery) makes an array of the given column, array_to_string is basically the same as array.join(", ")) This VIEW basically presents us all the information we want, a neat sql table like: oid | title | tags | filetype ----------------------------- 1 | asdf | a, b | which is used by og. the xhtml can now look like: #{i.title} : #{i.tags} and only a single SQL query will be made for the whole page (which could be thousands of rows, depending on what you want to do), which leads to an unbelievable speedup in your Og/Nitro application. This might be possible with other RDBMS, but I don't know. So, hope I might've helped someone get some ideas, and, I want a Glue::ViewOnly module, so get coding ;) *sigh* ah well, with my luck something like this is already in Nitro, and I just overlooked it, I love doing useless work.... .. Good night everyone Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Jan 15 18:22:50 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 16 Jan 2006 00:22:50 +0100 Subject: [Nitro] Speed up SELECTS (using PSQL VIEWS) In-Reply-To: References: Message-ID: Uh, smal correction On Mon, 16 Jan 2006 00:11:05 +0100, Kashia Buch wrote: > < Nitro::Controller this is crap, obviously, nevermind, I am tired and was writing out of my memory ^^; Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From vseguip at gmail.com Mon Jan 16 02:23:00 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Mon, 16 Jan 2006 08:23:00 +0100 Subject: [Nitro] Og name clashes with Gtk2 In-Reply-To: <1137241493.10521.37.camel@robs-p4> References: <1137241493.10521.37.camel@robs-p4> Message-ID: On 1/14/06, Rob Pitt wrote: > I noticed some discussion on IRC about changing the method name for > properties. I am against this as some of our libraries do use the > property method and i think it is well named. A better solution would be > to change the manageable check to be more intelligent. Perhaps objects > should export a method can_be_og_managed? or similar. > Hi Rob, there should not be any problem (at least theoretically) since I alias "property" and "properties" methods to the new method names in the patch. Cheers, V. Segu? From george.moschovitis at gmail.com Mon Jan 16 03:30:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 10:30:30 +0200 Subject: [Nitro] nitro scgi support improvement In-Reply-To: References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> <1137241675.10521.40.camel@robs-p4> Message-ID: > No doubt everyone on the list knows this, but for some newcomer to how > servers and browsers interact in a session based web app (me for example a > few months ago), it was an odd thing. Maybe this will spare some other > newcomer. Or perhaps the FCGI, SCGI and potentially ACGI adapters should > default to File based session info? I'll see about a patch if anyone thinks > it's an okay idea. this is a nice point. Please send me the patch. I will also try to add some warning messages and/or try to start the drb server from the Runner. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From guillaume.pierronnet at gmail.com Mon Jan 16 03:52:05 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Mon, 16 Jan 2006 09:52:05 +0100 Subject: [Nitro] nitro scgi support improvement In-Reply-To: References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> <1137241675.10521.40.camel@robs-p4> Message-ID: <6a7d49ca0601160052x19f065e1p@mail.gmail.com> By drb in SCGI, i was thinking of the process management, i.e. throttling max_connections per seconds, seing process status, nice restart and others things that exists in the Zed Shaw's Rails SCGI adapter. I was just wondering about the usefulness of that, and if these features can be implemented for other adapters as well, not just SCGI. To come back to the session's conversation, remember that SCGI is multithreaded and doesn't need session sharing. For multi-process Nitro apps, Drb, og or file sessions are indispensable. File is the most easy to setup. However, remember that files used in File sessions are not locked between processes and can lead to race conditions. We need a cross-platform file locking system. 2006/1/15, Bryan Soto : > On 1/15/06, George Moschovitis wrote: > > On 1/14/06, Rob Pitt wrote: > > > I am unsure how SCGI works but if it is anything like FastCGI you need > > > Drb so that the multiple spawned FastCGI processes can share sessions. > > > > Correct, you need DRB sessions for SCGI, just like in FCGI > > > > -g. > > > > > > For anyone searching the archive later, I'll mention File based sessions > work for FCGI as well. Probably slower, but at least you can build up to a > DRB session as needed. > > And how does one know they need to do this? If you have multiple processes > running, and you perform some action, i.e. log on, that should store info in > that user's session, and on a later request that info mysteriously > disappears and the user has to log on _again_, you're multiple processes are > storing info per process. You need to switch to File or DRB storage so that > all the processes store and retrieve the session info from one place, thus > sharing the data. > > No doubt everyone on the list knows this, but for some newcomer to how > servers and browsers interact in a session based web app (me for example a > few months ago), it was an odd thing. Maybe this will spare some other > newcomer. Or perhaps the FCGI, SCGI and potentially ACGI adapters should > default to File based session info? I'll see about a patch if anyone thinks > it's an okay idea. > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From george.moschovitis at gmail.com Mon Jan 16 04:27:55 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 11:27:55 +0200 Subject: [Nitro] nitro scgi support improvement In-Reply-To: <6a7d49ca0601160052x19f065e1p@mail.gmail.com> References: <6a7d49ca0601130828q77471248n@mail.gmail.com> <43C84260.5070406@cs.helsinki.fi> <1137241675.10521.40.camel@robs-p4> <6a7d49ca0601160052x19f065e1p@mail.gmail.com> Message-ID: > By drb in SCGI, i was thinking of the process management, i.e. > throttling max_connections per seconds, seing process status, nice > restart and others things that exists in the Zed Shaw's Rails SCGI > adapter. > I was just wondering about the usefulness of that, and if these > features can be implemented for other adapters as well, not just SCGI. This sounds very nice. I would like to see what you come up with ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 16 06:50:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 13:50:15 +0200 Subject: [Nitro] Nitro 0.27.0 preview gems Message-ID: Dear devs, you can find some preview gems for Nitro 0.27.0 here: http://www.nitrohq.com/d27.zip please try to install these gems and report back any bugs. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 16 09:31:57 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 16:31:57 +0200 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs Message-ID: Dear devs, new versions of Nitro and Og where just released homepage: http://www.nitrohq.com install: gem install nitro download: http://rubyforge.org/projects/nitro/ irc: irc.freenode.net #nitro mailing list: http://rubyforge.org/pipermail/nitro-general/ Whats new: Once again we have a great mix of cool new features, along with bugfixes and a myriad of smaller improvements. Go and download the most advanced Ruby Web/ORM Framework you can find. Most notable changes: * Added groundbreaking client side action/scripting support: class FlickrDemo < Nitro::Controller helper :javascript class Client # Actions defined here are executed as javescript in the # browser. def clear_me hide :hide_me end def grab ajax_upadate ... end end end in the template:
...
clear the client element is converted to a javascript call that executes the code in the client action. A domain specific language is provided for the client action to implement stuff like ajax async updates, scriptaculous visual fx and more. * A collection of morphers to work along with client actions. Here are some examples:
Drag me
in the controller: def tags_auto_complete %{
  • navel
  • nitro
  • sexy
} end More stuff is coming in future versions. * Greatly imporoved the Elements system. The ElementMixin module is auto-injected if missing. Nitro automatically transforms xhtml template files in the Element.template_root into Element classes for even better separation of code and design. A simple Rails style layout helper is implememnted on top of the general and powerful Elements mechanism for people familiar with Rails. * New WebFile system. Uploading files and handling photos was never easier: class Photo is Timestamped is Taggable property :title, String property :file, WebFile, :magick => { :small => '64x64', :medium => '128x128' } end # the upload action def upload photo = Photo.assign(request) photo.save end This saves the photo, and creates 2 thumbnails. You can easily access the photo and thumbnails like this: ie obj.{propertyname}_#{thumbname}_thumbnail * Og live collections support accumulation. Here is an example: class Category has_many :projects end class Project has_many :clients end class Client end clients = category.projects.clients # => returns all clients for this category! * Improved TableHelper, better configurability, more skinnable, sorting support and more. * Added some intelligent auto-discovery features to minimize the setup code. For example helpers are automatically loaded, and the template_root is auto-discovered. * Optimized the autoreloading system to only reload the dirty files. In fact the new autoreloading system is so efficient that it is enables by default even in live/production mode. * Added Flickr, a great new example that shows off the new javascript integration and AJAX features of Nitro. * Added Gallery example to demonstrate the new WebFile functionality. * Improved the generated RDOC comments. * Fixes in CGI adapter. * Added evolution support to the KirbyBase adapter. * Updated to scriptaculous 1.5.1 * Scaffolding - auto admin interface improvements. * Added setup.rb for non-gem installation (experimental). * Added ACGI adapter (experimental). Nitro provides everything you need to develop professional Web applications using Ruby and Javascript. Nitro redefines Rapid Application Development by providing a clean, yet efficient API, a layer of domain specific languages implemented on top of Ruby and the most powerful and elegant object relational mapping solution available everywhere. have fun, George Moschovitis -- http://www.nitrohq.com http://www.gmosx.com http://www.navel.gr From kashia at vfemail.net Mon Jan 16 09:53:31 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 16 Jan 2006 15:53:31 +0100 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: References: Message-ID: Hey, George you are absolutely crazy ;) that ACGI patch absolutely wasn't meant for presenting to anyone (especially not to users)! I hereby claim myself innocent of whatever support questions come in for that ;) (crap, my name shows up in the patch ^^;) And, btw, I love the WebFile Picture magick :D Thank you for another cool release :D Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Jan 16 09:58:50 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 16:58:50 +0200 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: References: Message-ID: > you are absolutely crazy ;) > that ACGI patch absolutely wasn't meant for presenting to anyone (especially not to users)! I hereby claim myself innocent of whatever support questions come in for that ;) > (crap, my name shows up in the patch ^^;) Thats why I added the *experimental* part on the change log. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 16 10:10:26 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 17:10:26 +0200 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: References: <43CBB127.3000503@johnwlong.com> Message-ID: Some 0.26.0->0.27.0 help is available in dos/MIGRATION -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Mon Jan 16 10:11:50 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 16 Jan 2006 16:11:50 +0100 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: References: Message-ID: Hi, > Thats why I added the *experimental* part on the change log. it seems your and my definition of *experimental* differ a bit. But ok, someone might have a use for the acgi code in there :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From alang at cronosys.com Mon Jan 16 11:55:27 2006 From: alang at cronosys.com (Alan Garrison) Date: Mon, 16 Jan 2006 11:55:27 -0500 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: References: <43CBB127.3000503@johnwlong.com> Message-ID: <43CBCFFF.5010509@cronosys.com> George Moschovitis wrote: > Some 0.26.0->0.27.0 help is available in dos/MIGRATION You've added DOS support? ;) -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From george.moschovitis at gmail.com Mon Jan 16 11:58:57 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 Jan 2006 18:58:57 +0200 Subject: [Nitro] Nitro + Og 0.27.0 Client code, WebFile, Elements improved, New examples RDocs In-Reply-To: <43CBCFFF.5010509@cronosys.com> References: <43CBB127.3000503@johnwlong.com> <43CBCFFF.5010509@cronosys.com> Message-ID: > You've added DOS support? ;) I meant doc ;-) -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Tue Jan 17 19:57:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 17 Jan 2006 16:57:40 -0800 Subject: [Nitro] PATCH: sqlite_schema_evolution Message-ID: Attached patch adds Sqlite3 schema evolution support. If applied, all Og stores will have schema evolution. Hurrah! Can anyone chime in with features that are in the Postgres adapter but not the other stores? I know of: * Kirby join tables which I'm planning to try next. Anything else? bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060117/88b88de1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlite_schema_evolution.zip Type: application/zip Size: 5030 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060117/88b88de1/attachment.zip From james_b at neurogami.com Wed Jan 18 02:11:18 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 18 Jan 2006 00:11:18 -0700 Subject: [Nitro] Nitro and Facets version In-Reply-To: References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> Message-ID: <43CDEA16.5060105@neurogami.com> George Moschovitis wrote: > Please avoid using nitrogen/nitro in 0.26.0 > > These commands are not used a lot in Nitro, as Nitro does not force a > structure on the directory. Prefer to use > > ruby run.rb in your app dir. Well, but having a simple script to create a basic directory structure and config/app files very handy. (Actually, what's needed is a gen generator. You create the dirs and files you think you'll be using for 90% of your apps, point the gen-gen script at it, and it creates a generator tool for creating that same set of dir and files on demand. One of those phantom 'free time' projects, I suppose.) I like the idea of how Rails plops down things you're (most likely) going to use, but loathe how the ratio of needed/gee-maybe-but-unlikely is so poor. I guess YAGNI isn't in the Popular Buzz Terms list. > > > The 0.27.0 release is coming early next week. This release will be > focused to small 'details' like the utility scripts. Ie things that > baffle newcomers like you. 0.27.0 includes a 'nitrogen' script in the bin folder. It advises the user to run 'gen', which is not provided. James Britt -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From george.moschovitis at gmail.com Wed Jan 18 03:43:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 Jan 2006 10:43:30 +0200 Subject: [Nitro] Nitro and Facets version In-Reply-To: <43CDEA16.5060105@neurogami.com> References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> <43CDEA16.5060105@neurogami.com> Message-ID: > 0.27.0 includes a 'nitrogen' script in the bin folder. It advises the > user to run 'gen', which is not provided. gen in provided by the gen gem. I just tried it. Use gen app my_app -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Jan 18 03:50:29 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 Jan 2006 10:50:29 +0200 Subject: [Nitro] PATCH: sqlite_schema_evolution In-Reply-To: References: Message-ID: Thanks ;-) -g. On 1/18/06, Bryan Soto wrote: > Attached patch adds Sqlite3 schema evolution support. > > If applied, all Og stores will have schema evolution. Hurrah! > > Can anyone chime in with features that are in the Postgres adapter but not > the other stores? I know of: > > * Kirby join tables which I'm planning to try next. > > Anything else? > > bryan > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Wed Jan 18 08:32:24 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 18 Jan 2006 14:32:24 +0100 Subject: [Nitro] Questions on Element, Control and rendering Message-ID: <43CE4368.5050209@gmail.com> Hello list, As an example, I want to code a generic calendar that I can use everywhere I need/want. So I looked a little bit around. I understand that there are controls and elements. What I would like to be able to do, it use it like that in my html page : class Calendar < Nitro::Element attr :name attr :date def header %~ ' ~ end end = What is the difference between an Element and a Control ? Elements are transformed by the renderer. They have a notion of childs and parent. Controls are used by the form helper. They only represent a value. = Can't these two classes be merged in one or are they too different ? For me, elements are bit like actions outside a class. It's a bit like HMVC where you have subcontrollers. = Is it possible to pass ruby objects to an Element instead of strings ? In the previous example, "cal" and "30-12-2005" are strings. Also I don't know, bust is there a way to make them mandatory or optional like ruby's method parameters ? And can I inject the values from the action ? def index @page.getElementById('name').date = Time.now end = Is it possible to add javascript include in the page's header from the element ? Taking that example again. Imagine we have a javascript library that adds calendar functionnalities. Like this popular one : http://www.dynarch.com/projects/calendar/ . Is it possible to add a method in Element that would include the library once in the header for every instance of the calendar if used ? = What is the workflow of Nitro ? I wish I'd understand what Nitro does in general. Where it goes from the request to the result. Sorry for that long email. I've looked for those questions in the wiki and they were missing so I'll update it when/if I get answers. Cheers, Jonas Pfenniger From zimba.tm at gmail.com Wed Jan 18 08:41:52 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 18 Jan 2006 14:41:52 +0100 Subject: [Nitro] Installing Trac In-Reply-To: References: <43C53849.9010106@gmail.com> Message-ID: <43CE45A0.6090900@gmail.com> Hi George, what's going on with the install, do you need any help ? also the reference doc is down in the wiki George Moschovitis wrote: >>I wish we had something like that. What do you think ? >> >> > >Ok, will *try* to setup this over the next days. I hope Tasos >Koutoumanos will have some time to help me with this. > >Btw, in the next week I plan to announce a new initiative for the >further development of Nitro/Og. In short, I think that it is >beneficial for the project to build a team of core developers with >repository admin rights. Everyone who would like to help here, let me >know. More details about this real soon ;-) > >regards, >George. > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.com > >_______________________________________________ >Nitro-general mailing list >Nitro-general at rubyforge.org >http://rubyforge.org/mailman/listinfo/nitro-general > > > From george.moschovitis at gmail.com Wed Jan 18 08:50:54 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 Jan 2006 15:50:54 +0200 Subject: [Nitro] Questions on Element, Control and rendering In-Reply-To: <43CE4368.5050209@gmail.com> References: <43CE4368.5050209@gmail.com> Message-ID: > As an example, I want to code a generic calendar that I can use > everywhere I need/want. funny, i was working on this too ;-) forget about controls at the moment. What you need are elements. Controls are used by the scaffolder. However I was thinking about renameing the scaffolder controls to PropertyControl or something, and have Control as an alias to element when used to implement ...controls ;-) > = What is the difference between an Element and a Control ? > > Elements are transformed by the renderer. They have a notion of childs > and parent. > Controls are used by the form helper. They only represent a value. Yeah. Please note that Elements are statically resolved when compiling a template. They are a form of template macro. > = Can't these two classes be merged in one or are they too different ? > > For me, elements are bit like actions outside a class. It's a bit like > HMVC where you have subcontrollers. As I said, I am thinking on this. I think the name control for the form helper widgets is a bit unfortunate. Any other opinions on this? > = Is it possible to pass ruby objects to an Element instead of strings ? Dont forget that Elements are just transformers of code. here is an example element: class Calendar def render %{

\#{#{myob}.name}

} end end I know this is not elegant but it works with the current element infrastructure. > = Is it possible to add javascript include in the page's header from the > element ? Have a look at lib/nitro/helper/javascript/prototype.rb In general your calendar should be implemented as a helper. Ie you use helper for such kind of run-time ...helpers and elements for compile time template transformations. regards, Geogre. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Jan 18 08:58:44 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 Jan 2006 15:58:44 +0200 Subject: [Nitro] Installing Trac In-Reply-To: <43CE45A0.6090900@gmail.com> References: <43C53849.9010106@gmail.com> <43CE45A0.6090900@gmail.com> Message-ID: I told an associate to investigate trac and how to setup it. Most probably he wil lhave this figured out by tommorow and then he will install trac on the nitrohq server. so... be a bit patient ;-) > also the reference doc is down in the wiki will update it later.... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Wed Jan 18 10:02:30 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 18 Jan 2006 08:02:30 -0700 Subject: [Nitro] Nitro and Facets version In-Reply-To: References: <20051030183111.0aee2b9a@localhost> <200510301849.31116.m.fellinger@gmail.com> <20051030200836.443e0851@localhost> <683a886f0601080827j4828c8e0mcbbd9905e59ff1d6@mail.gmail.com> <43CDEA16.5060105@neurogami.com> Message-ID: <43CE5886.5050407@neurogami.com> George Moschovitis wrote: >>0.27.0 includes a 'nitrogen' script in the bin folder. It advises the >>user to run 'gen', which is not provided. > > > gen in provided by the gen gem. I just tried it. Ah, I was unaware there was a separate gem for this. Thanks. James From aidan at yoyo.org Thu Jan 19 02:49:18 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 19 Jan 2006 18:49:18 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) Message-ID: Hi all, I've encountered what is possibly a bug in lib/og/relation/ has_many.rb. Consider this code - assume all that is needed to manage Bar and Baz is accurate: module Foo class Bar property :bar_prop, String has_many :bazs, Baz end class Baz property :baz_prop, String belongs_to :bar, Bar end end bar = Foo::Bar.new baz = Foo::Baz.create # bar.save bar.add_baz(baz) bar.save assert(bar.bazs.to_ary.include? baz) That assertion should be true (caveat: not a real test case!). However, it is false. This is because the add_baz method (which is eval'd to be part of the class in has_many.rb line 57) sets the foreign key of the owner of baz to the primary key of the owner. However, this doesn't work if the owner hasn't been saved, because it does not have a primary key at that point. One workaround is to save the owner (commented out in the above example) before adding, or to use 'create' instead of 'new'. This ensures the owner has a primary key. No problem in most cases. The reason I discovered this (possible) bug is that I was trying to access the various relations of my owner class in a method that I was using as a post_insert - can't save in that method, otherwise I'd get a nasty infinite loop. So, one possible fix is to say in the add_* method: def add_#{target_singular_name}(obj, options = nil) return unless obj self.save unless self.saved? # THIS LINE IS THE NEW ONE obj.#{foreign_key} = @#{owner_class.primary_key} obj.save end However, this may have some unpleasant side effects that I can't foresee at this moment. Can anyone shed any light on this? Can anyone think of a reason this might be bad? ------------- Strange bug part 2. So, given all of the above, and regardless of how you fix it or workaround it, here's the really strange part. If I then want to output my bar to yaml, I'd require 'yaml' and say: puts bar.to_yaml There's no mention of the bazs property, as I'd expect. This is definitely a bug. Next weirdness: If before to_yaml I put: puts bar.bazs.inspect Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in `to_yaml': can't dump anonymous class Class (TypeError) but using: puts.find_bazs.inspect gives no error (although, still no bazs property in the yaml). Anyone? :-) Aidan ps. I'll keep investigating this - I think this may be some crossover weirdness with YAML and the module_eval that happens in Og. From aidan at yoyo.org Thu Jan 19 12:13:42 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 20 Jan 2006 04:13:42 +1100 Subject: [Nitro] patch not included in 0.27.0? Message-ID: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> George, I submitted a patch to the ML on 9th January to fix a schema_inheritance bug in Og. This patch didn't make it into 0.27.0 (I know, because my app broke again!). Was this deliberate, or an oversight? Thanks, Aidan From bryan.a.soto at gmail.com Thu Jan 19 16:13:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 19 Jan 2006 13:13:09 -0800 Subject: [Nitro] patch not included in 0.27.0? In-Reply-To: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> References: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> Message-ID: On 1/19/06, Aidan Rogers wrote: > > George, > > I submitted a patch to the ML on 9th January to fix a > schema_inheritance bug in Og. This patch didn't make it into 0.27.0 > (I know, because my app broke again!). Was this deliberate, or an > oversight? > > Thanks, > > Aidan > I don't know about George, but it was an oversight on my part. I'd decided to send out a Friday (for me at least) email of outstanding patches and didn't last week because I thought we were all caught up. My apologies to you. And, since your email is a good segue, I've been looking at Trac since it seems to be in our near future and noticed it integrates rather heavily with Subversion. Will we be switching from Darcs? I have no preference between them, just curious. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060119/f44610fe/attachment.html From bryan.a.soto at gmail.com Thu Jan 19 16:15:59 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 19 Jan 2006 13:15:59 -0800 Subject: [Nitro] patch not included in 0.27.0? In-Reply-To: References: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> Message-ID: On 1/19/06, Bryan Soto wrote: > > On 1/19/06, Aidan Rogers wrote: > > > > George, > > > > I submitted a patch to the ML on 9th January to fix a > > schema_inheritance bug in Og. This patch didn't make it into 0.27.0 > > (I know, because my app broke again!). Was this deliberate, or an > > oversight? > > > > Thanks, > > > > Aidan > > > > > I don't know about George, but it was an oversight on my part. I'd decided > to send out a Friday (for me at least) email of outstanding patches and > didn't last week because I thought we were all caught up. > > My apologies to you. > > And, since your email is a good segue, I've been looking at Trac since it > seems to be in our near future and noticed it integrates rather heavily with > Subversion. Will we be switching from Darcs? I have no preference between > them, just curious. > > > And a mistaken send on my part before I think to look through past emails. Darcs is supported with modifications for anyone else who is as badly forgetful as myself. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060119/a31bec0e/attachment.html From bryan.a.soto at gmail.com Thu Jan 19 16:30:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 19 Jan 2006 13:30:42 -0800 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: On 1/18/06, Aidan Rogers wrote: > > One workaround is to save the owner (commented out in the above > example) before adding, or to use 'create' instead of 'new'. This > ensures the owner has a primary key. No problem in most cases. The > reason I discovered this (possible) bug is that I was trying to > access the various relations of my owner class in a method that I was > using as a post_insert - can't save in that method, otherwise I'd get > a nasty infinite loop. > > So, one possible fix is to say in the add_* method: > > def add_#{target_singular_name}(obj, options = nil) > return unless obj > self.save unless self.saved? # THIS LINE IS THE NEW ONE > obj.#{foreign_key} = @#{owner_class.primary_key} > obj.save > end > > However, this may have some unpleasant side effects that I can't > foresee at this moment. Can anyone shed any light on this? Can > anyone think of a reason this might be bad? Well, first thought I have is that the object, if there are failing validations, might not save and the problem would still exist. I think we should have the object determine when it's collections are saved rather than the collections saving the object. Strange bug part 2. > > Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in > `to_yaml': can't dump anonymous class Class (TypeError) > > Anyone? :-) > > You make me glad I think I've figured out why the Og unit tests aren't running ;) Will, hopefully, follow up with a patch and/or explanation today. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060119/e05845d9/attachment.html From aidan at yoyo.org Thu Jan 19 16:42:03 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 20 Jan 2006 08:42:03 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: <8427E6BE-9F9D-4AD0-9976-83735942A521@yoyo.org> Happy to help :-) Btw, any chance my credit in Authors could be changed to aidan at infurious.com - I'm starting a small software company and every bit of publicity helps. Aidan On 20/01/2006, at 8:30 AM, Bryan Soto wrote: > On 1/18/06, Aidan Rogers wrote: > One workaround is to save the owner (commented out in the above > example) before adding, or to use 'create' instead of 'new'. This > ensures the owner has a primary key. No problem in most cases. The > reason I discovered this (possible) bug is that I was trying to > access the various relations of my owner class in a method that I was > using as a post_insert - can't save in that method, otherwise I'd get > a nasty infinite loop. > > So, one possible fix is to say in the add_* method: > > def add_#{target_singular_name}(obj, options = nil) > return unless obj > self.save unless self.saved? # THIS LINE IS THE NEW ONE > obj.#{foreign_key} = @#{owner_class.primary_key} > obj.save > end > > However, this may have some unpleasant side effects that I can't > foresee at this moment. Can anyone shed any light on this? Can > anyone think of a reason this might be bad? > > Well, first thought I have is that the object, if there are failing > validations, might not save and the problem would still exist. > > I think we should have the object determine when it's collections > are saved rather than the collections saving the object. > > Strange bug part 2. > > Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in > `to_yaml': can't dump anonymous class Class (TypeError) > > Anyone? :-) > > > You make me glad I think I've figured out why the Og unit tests > aren't running ;) Will, hopefully, follow up with a patch and/or > explanation today. > > bryan > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Thu Jan 19 17:25:17 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 19 Jan 2006 14:25:17 -0800 Subject: [Nitro] Og Unit Tests Message-ID: Okay list, there are two problems with the unit tests which are both related. 1. Resolve polymorphic relations: E, [2006-01-19T13:49:28.405806 #22605] ERROR -- : Og.setup had problems: TypeError => (eval):2:in `resolve_polymorphic_relations': superclass mismatch for class Comment E, [2006-01-19T13:49:28.406438 #22605] ERROR -- : # 2. Multiple uses of Og.setup $ grep -R Og.setup * | wc -l 26 Basically, the problem is this. Each call to Og.setup results in Og iterating over all the classes in ObjectSpace to find Classes it can manage. Because there are multiple calls to Og.setup, classes are "managed" multiple times, which ultimately causes this class TC_OgPolymorphic::User::Comment < TC_OgPolymorphic::User::Comment end to be evaled which results in the TypeError listed in item one. Note that the super and sub class are both the same name. Now, I'm personally of the opinion that there shouldn't be multiple calls to Og.setup strewn throughout the test code. I think it should be all done via the config file that way all tests run against a single store. This also has the benefit that if a store isn't up to par with Postgres, it'll show up as an error. But I also recognize that what is happening with the type error is a bug which should be corrected. The attached patch, not bundle as I'm not sure this is the right solution, simply checks to see if we attempt to create a super and sub class of the same name and skips over it. It allows the tests to run with easier to correct errors, i.e. hardcoded passwords, hardcoded stores, etc. These, of course, are easily correctted by having only a single Og.setup call. :) Anyway, I'm happy to take care of the Og.setup issue, but didn't actually do a bundle in case there are valid reasons why it shouldn't be done. Wasted effort and all that. I did actually comment out all the Og.setup calls last night, and going by my memory (be wary given recent performance ;), the results were: * 1 test which needed to be skipped (renamed to xtest_* due to a non-existent database field) * 13 errors * 4 failures So this is probably something to address for 0.28. ;) bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060119/f78ae179/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_resolve_polymorphic_relations Type: application/octet-stream Size: 564 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060119/f78ae179/attachment.obj From george.moschovitis at gmail.com Fri Jan 20 03:54:01 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 10:54:01 +0200 Subject: [Nitro] patch not included in 0.27.0? In-Reply-To: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> References: <20558EA6-18E4-415B-8261-E238E71DE3F6@yoyo.org> Message-ID: If I remember correctly, I either added the patch, or the patch was not needed. Epiperak's error report for schema_inheritance was not valid (In fact I added emanuels example as a test case that passes.) However I will investigate your patch again. Thanks for pointing this out! -g. On 1/19/06, Aidan Rogers wrote: > George, > > I submitted a patch to the ML on 9th January to fix a > schema_inheritance bug in Og. This patch didn't make it into 0.27.0 > (I know, because my app broke again!). Was this deliberate, or an > oversight? > > Thanks, > > Aidan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 20 03:55:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 10:55:37 +0200 Subject: [Nitro] Og Unit Tests In-Reply-To: References: Message-ID: Thanks for the insight and patch Bryan. I plan to concentrate on Og for the forthcoming 0.28.0 version so I 'll have some time to look at vraious Og issues reported lately. -g. On 1/20/06, Bryan Soto wrote: > Okay list, there are two problems with the unit tests which are both > related. > > 1. Resolve polymorphic relations: > > E, [2006-01-19T13:49:28.405806 #22605] ERROR -- : Og.setup had problems: > TypeError => (eval):2:in `resolve_polymorphic_relations': > superclass mismatch for class Comment > E, [2006-01-19T13:49:28.406438 #22605] ERROR -- : # `resolve_polymorphic_relations': superclass mismatch for > class Comment> > > 2. Multiple uses of Og.setup > > $ grep -R Og.setup * | wc -l > 26 > > Basically, the problem is this. Each call to Og.setup results in Og > iterating over all the classes in ObjectSpace to find Classes it can manage. > Because there are multiple calls to Og.setup, classes are "managed" multiple > times, which ultimately causes this > > class TC_OgPolymorphic::User::Comment < TC_OgPolymorphic::User::Comment > end > > to be evaled which results in the TypeError listed in item one. Note that > the super and sub class are both the same name. > > Now, I'm personally of the opinion that there shouldn't be multiple calls > to Og.setup strewn throughout the test code. I think it should be all done > via the config file that way all tests run against a single store. This also > has the benefit that if a store isn't up to par with Postgres, it'll show up > as an error. But I also recognize that what is happening with the type error > is a bug which should be corrected. The attached patch, not bundle as I'm > not sure this is the right solution, simply checks to see if we attempt to > create a super and sub class of the same name and skips over it. It allows > the tests to run with easier to correct errors, i.e. hardcoded passwords, > hardcoded stores, etc. These, of course, are easily correctted by having > only a single Og.setup call. :) > > Anyway, I'm happy to take care of the Og.setup issue, but didn't actually > do a bundle in case there are valid reasons why it shouldn't be done. Wasted > effort and all that. > > I did actually comment out all the Og.setup calls last night, and going by > my memory (be wary given recent performance ;), the results were: > > * 1 test which needed to be skipped (renamed to xtest_* due to a > non-existent database field) > * 13 errors > * 4 failures > > So this is probably something to address for 0.28. ;) > > bryan > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 20 04:33:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 11:33:28 +0200 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: > However, this doesn't work if the owner hasn't been saved, because it > does not have a primary key at that point. Hmm I am not 100% sure but your fix seems reasonable. > puts bar.to_yaml > > There's no mention of the bazs property, as I'd expect. This is > definitely a bug. Nope, this is not a bug. bazs is a virtual field so yaml cannot dump it. Dunno how to fix this. > Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in > `to_yaml': can't dump anonymous class Class (TypeError) > > but using: > > puts.find_bazs.inspect > > gives no error (although, still no bazs property in the yaml). Hmm will check this. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 20 04:48:03 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 11:48:03 +0200 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: <8427E6BE-9F9D-4AD0-9976-83735942A521@yoyo.org> References: <8427E6BE-9F9D-4AD0-9976-83735942A521@yoyo.org> Message-ID: > aidan at infurious.com - I'm starting a small software company and every Sure, no problem ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From guillaume.pierronnet at gmail.com Fri Jan 20 04:56:50 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Fri, 20 Jan 2006 10:56:50 +0100 Subject: [Nitro] 4 tiny fixes Message-ID: <6a7d49ca0601200156y54af68e4k@mail.gmail.com> hi list, George, here are 4 fixes, i made a test case for 2 of them. I don't have fixed the problem focused with test_case2.xhtml since it seems to be REXML related. In fact, REXML doesn't handle "text" event before seeing the first tag. Keep up the good work! -------------- next part -------------- A non-text attachment was scrubbed... Name: test_case.tar.gz Type: application/x-gzip Size: 634 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060120/4975a78c/attachment.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: 4fixes.gz Type: application/x-gzip Size: 3858 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060120/4975a78c/attachment-0001.gz From rob at motionpath.com Fri Jan 20 05:02:10 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 20 Jan 2006 10:02:10 +0000 Subject: [Nitro] [PATCH] Nitro Testcases should require rubygems Message-ID: <1137751330.9014.31.camel@robs-p4> Self explanatory. -------------- next part -------------- A non-text attachment was scrubbed... Name: require-testcase.patch.bz2 Type: application/x-bzip Size: 11627 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060120/c949dbe2/attachment.bin From rob at motionpath.com Fri Jan 20 05:09:39 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 20 Jan 2006 10:09:39 +0000 Subject: [Nitro] [PATCH] parse_multipart test case Message-ID: <1137751780.9014.40.camel@robs-p4> Here is a test case for parse_multipart. I made this because I have created a new parse_multipart method that theoretically should only use 20k of RAM at once but in practise even if I force GC.start ruby will not deallocate the memory while receiving very large files :( I would submit this patch too, but I have since thought of a much saner way to do it. One thing I did implement is a progress report of the POST upload stored in session[:upload_progress] containing the start time, the content length and the amount of bytes read. When the POST was finished it also set :finished to Time.now too so you can do things like progress bars. I am not happy to submit this patch as it uses a lot more CPU than it should and could have been implemented a lot more simplistically and I would be happy to describe a better method if anyone was game for coding it but I cannot at present code it myself as the replacement method I wrote works for us. -------------- next part -------------- A non-text attachment was scrubbed... Name: tc_cgi.patch.bz2 Type: application/x-bzip Size: 12450 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060120/e2c54261/attachment.bin From rob at motionpath.com Fri Jan 20 05:11:24 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 20 Jan 2006 10:11:24 +0000 Subject: [Nitro] Re-doing parts of Nitro in C Message-ID: <1137751884.9014.43.camel@robs-p4> What are your positions on re-doing particularly processor or memory intensive parts of Nitro in C as ruby modules? Perhaps as an alternative, i.e. the pure ruby version would be used in case the end user cannot compile for some reason? From vseguip at gmail.com Fri Jan 20 05:59:58 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Fri, 20 Jan 2006 11:59:58 +0100 Subject: [Nitro] [NITRO] Feature request: create a deep copy method for managed Og clases Message-ID: Hi, It would be fine if Nitro featured a way to copy existing objects in the Database.Ideally, it should be able to copy the record in the table and (optionally) recurse through all weak entities and copy them too. For instance suppose we have the following schema: A |<---------joins many------------>| B | | | | AtoB --------- has _many ---------- AtoBprops If I copy an object of class A then it sould copythe record in the table, and optionally recursively copy all AtoB and AtoBprops but not the related B object since B entities are not weak. Cheers, V. Segu? From george.moschovitis at gmail.com Fri Jan 20 06:22:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 13:22:08 +0200 Subject: [Nitro] Re-doing parts of Nitro in C In-Reply-To: <1137751884.9014.43.camel@robs-p4> References: <1137751884.9014.43.camel@robs-p4> Message-ID: This is on my todo list. Out of couriosity, wich parts have you identified as processor intensive? -g. On 1/20/06, Rob Pitt wrote: > What are your positions on re-doing particularly processor or memory > intensive parts of Nitro in C as ruby modules? Perhaps as an > alternative, i.e. the pure ruby version would be used in case the end > user cannot compile for some reason? > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 20 06:25:05 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 13:25:05 +0200 Subject: [Nitro] [PATCH] Nitro Testcases should require rubygems In-Reply-To: <1137751330.9014.31.camel@robs-p4> References: <1137751330.9014.31.camel@robs-p4> Message-ID: I think this shouldn't be included as some people use Nitro without rubygems. Any opinions on this? -g. PS: if you use the nitro gems you should probably use RUBYOPT=-rubygems On 1/20/06, Rob Pitt wrote: > Self explanatory. > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Jan 20 06:33:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 13:33:15 +0200 Subject: [Nitro] [PATCH] parse_multipart test case In-Reply-To: <1137751780.9014.40.camel@robs-p4> References: <1137751780.9014.40.camel@robs-p4> Message-ID: > would be happy to describe a better method if anyone was game for coding > it but I cannot at present code it myself as the replacement method I > wrote works for us. Please send me the code. I may be able to implement this in a better way. thanks in advance, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rob at motionpath.com Fri Jan 20 07:28:17 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 20 Jan 2006 12:28:17 +0000 Subject: [Nitro] [PATCH] Nitro Testcases should require rubygems In-Reply-To: References: <1137751330.9014.31.camel@robs-p4> Message-ID: <1137760097.9014.51.camel@robs-p4> People use ruby without having rubygems installed? Adding it fixed the auto-require of facets, etc. I am not using the nitro gems but glycerin appears first in my RUBYLIB env. How about putting a begin/rescue around it? =) On Fri, 2006-01-20 at 13:25 +0200, George Moschovitis wrote: > I think this shouldn't be included as some people use Nitro without rubygems. > Any opinions on this? > > -g. > > PS: if you use the nitro gems you should probably use RUBYOPT=-rubygems > > > > On 1/20/06, Rob Pitt wrote: > > Self explanatory. > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From Walter at mwsewall.com Fri Jan 20 09:52:06 2006 From: Walter at mwsewall.com (Walter) Date: Fri, 20 Jan 2006 09:52:06 -0500 Subject: [Nitro] Og Unit Tests Message-ID: <9DB53D616B4D5B47B8353ACBF155C6B72151B4@mwsewall.com> > > Thanks for the insight and patch Bryan. I plan to concentrate on Og > for the forthcoming 0.28.0 version so I 'll have some time to look at > vraious Og issues reported lately. > > -g. > Any plans to allow for non auto-sequenced compound primary keys. This would allow for much easier integration with legacy systems. Walt -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 1/18/2006 From george.moschovitis at gmail.com Fri Jan 20 10:04:49 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Jan 2006 17:04:49 +0200 Subject: [Nitro] Og Unit Tests In-Reply-To: <9DB53D616B4D5B47B8353ACBF155C6B72151B4@mwsewall.com> References: <9DB53D616B4D5B47B8353ACBF155C6B72151B4@mwsewall.com> Message-ID: > Any plans to allow for non auto-sequenced compound primary keys. This would allow for much easier integration with legacy systems. Can you explain this in more detail? -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From Walter at mwsewall.com Fri Jan 20 11:59:34 2006 From: Walter at mwsewall.com (Walter) Date: Fri, 20 Jan 2006 11:59:34 -0500 Subject: [Nitro] Og Unit Tests Message-ID: <9DB53D616B4D5B47B8353ACBF155C6B72151F5@mwsewall.com> > > > Any plans to allow for non auto-sequenced compound primary keys. This > would allow for much easier integration with legacy systems. > > Can you explain this in more detail? > I deal with a legacy accounting/Fuel Oil program that does NOT use auto increment primary keys named oid or id or anything like that. Basically there is a separate table that contains the next available entry number, whether it is a journal entry or an invoice and whatever. I must get the next "KEY" from that table and assign it to the object. If we take an invoice for example there is an invoice header and invoice line items. The header primary key is the division and the invoice number that I would need to get from the above method, and the division is whatever division I am in when I create the invoice. The index is based on (div, inv_no). For each line item in the invoice there is an InvoiceLineItem whose key is the invoice number of the invoice header it is a child of and the line item number for this line item (not always sequential). Basically I need to be able to assign the keys during creation, but Og should be able to use the compound primary keys for lookups/updates/deletes. I would still like to do invoice.line_items and have Og find them for me. If there were a KeyGenerator that could be plugged-in, one could create their own to work with the above, and other methods, assuming the table had that generator assigned to it. Perhaps one KeyGenerator would simple be a ManualGenerator where key setting was manual. This would allow for different methods of key generation, and allow it to work with legacy databases, which is something Rails cannot do very well. Walt -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.20/234 - Release Date: 1/18/2006 From jos at catnook.com Fri Jan 20 12:42:26 2006 From: jos at catnook.com (Jos Backus) Date: Fri, 20 Jan 2006 09:42:26 -0800 Subject: [Nitro] [NITRO] Feature request: create a deep copy method for managed Og clases In-Reply-To: References: Message-ID: <20060120174248.GB62836@lizzy.catnook.local> On Fri, Jan 20, 2006 at 11:59:58AM +0100, vseguip at gmail.com wrote: > Hi, > It would be fine if Nitro featured a way to copy existing objects in > the Database.Ideally, it should be able to copy the record in the > table and (optionally) recurse through all weak entities and copy them > too. For instance suppose we have the following schema: > > > A |<---------joins many------------>| B > | > | > | > | > AtoB --------- has _many ---------- AtoBprops > > > > If I copy an object of class A then it sould copythe record in the > table, and optionally recursively copy all AtoB and AtoBprops but not > the related B object since B entities are not weak. I posted a request along those same lines under the title `Og deep copy?' a couple of weeks ago. So this feature would be useful to me too. One application is the case where one has a datacenter configuration database with prototype hosts with various components (disks, NICs, etc.). Using this feature one could instantiate new hosts with their dependent objects based on those existing prototype hosts with ease because the dependent objects would be created as deep copies automatically. -- Jos Backus jos at catnook.com From james_b at neurogami.com Fri Jan 20 15:55:38 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 20 Jan 2006 13:55:38 -0700 Subject: [Nitro] Cannot require 'builder' in a Nitro app Message-ID: <43D14E4A.4020401@neurogami.com> I'm trying to use Jim Wierich's XML Builder library in Nitro to create atom and rss feeds. I cannot call "require 'builder'" without errors. This is with Nitro 0.27 on winxp with Ruby 1.8.2 rubygems automagically included by way of RUBYOPTS If I run this bare script: require 'builder' It runs fine. But as soon as I add nitro to the mix, I get assorted errors This: require 'builder' require 'nitro' Gives this: C:\WINDOWS\system32\cmd.exe /c c:/ruby/bin/ruby build.rb c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:90:in `bind': singleton method called for a different object (TypeError) from c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:90:in `method_added' from c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:89:in `method_added' from c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/openobject.rb:56 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' from c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/annotation.rb:53 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' ... 6 levels... from c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.27.0/lib/nitro.rb:11 from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:25:in `require__' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:25:in `require' from build.rb:2 shell returned 1 And this: require 'nitro' require 'builder Gives this: C:\WINDOWS\system32\cmd.exe /c c:/ruby/bin/ruby build.rb c:/ruby/lib/ruby/gems/1.8/gems/builder-1.2.4/lib/builder/blankslate.rb:11: Builder is not a module (TypeError) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' from c:/ruby/lib/ruby/gems/1.8/gems/builder-1.2.4/lib/builder/xmlbase.rb:3 Are there special libraries that cannot be used wth Nitro? Is there a trick to including certain libraries? Thanks, James From bryan.a.soto at gmail.com Fri Jan 20 21:15:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 20 Jan 2006 18:15:53 -0800 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: <43D14E4A.4020401@neurogami.com> References: <43D14E4A.4020401@neurogami.com> Message-ID: On 1/20/06, James Britt wrote: > > I'm trying to use Jim Wierich's XML Builder library in Nitro to create > atom and rss feeds. I cannot call "require 'builder'" without errors. > > Are there special libraries that cannot be used wth Nitro? > > Is there a trick to including certain libraries? Hi James, I wish I had a simple answer for you. Basic problem is a collision between Jim's Builder and Glue::Builder and Glue being included into the top level namespace by default. There is a $GLUE_DONT_INCLUDE flag, but it doesn't appear to have been tested against as setting it before requiring nitro gives some missing constant errors. I'll try to get a patch in to fix that... In the mean time, there is an XmlHelper and RssHelper (0.9) available in Nitro. Hopefully they'll meet your needs. Docs available via gem_server or http://www.cs.helsinki.fi/u/kaniemel/rdoc/nitro/classes/Nitro/XmlHelper.html http://www.cs.helsinki.fi/u/kaniemel/rdoc/nitro/classes/Nitro/RssHelper.html # Sample of RssHelper usage class TC_RssHelper < Test::Unit::TestCase # :nodoc: all include Nitro include RssHelper Blog = Struct.new(:title, :body, :to_href) def test_render blogs = [] blogs << Blog.new('Hello1', 'World1', 'uri1'); blogs << Blog.new('Hello2', 'World2', 'uri2'); blogs << Blog.new('Hello3', 'World3', 'uri3'); rss = build_rss(blogs, :link => 'http://www.navel.gr') assert_match %r{http://www.navel.gr/uri1}, rss assert_match %r{http://www.navel.gr/uri2}, rss end end - - - - - # flare/src/controller.rb build do |r| r.pi! :xml, :version => '1.0', :encoding => 'utf-8' r.respose do if error_message r.error '1' r.message error_message else r.error '0' end end end - - - - - Sorry about the stumbling block, but I hope this helps. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060120/b6eaad7b/attachment.html From bryan.a.soto at gmail.com Fri Jan 20 21:36:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 20 Jan 2006 18:36:25 -0800 Subject: [Nitro] PATCH: Outstanding as of Jan. 20, 2006 Message-ID: In the hopes of keeping people aware, here is a summary of outstanding patches. Format is: patch name: * Short summary of thread where Pending means no comments. If you've applied and tested, please speak up :) link for download of patch from Rubyforge. Order is oldest to newest. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RELEASES rdoc fix: * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html Schema Inheritance * George is investigating. http://rubyforge.org/pipermail/nitro-general/2006-January/002424.html Nitro scgi support * Aleksi tested on Windows with success. http://rubyforge.org/pipermail/nitro-general/2006-January/002472.html (patch) http://rubyforge.org/pipermail/nitro-general/2006-January/002473.html (bundle) 4 tiny fixes * Pending http://rubyforge.org/pipermail/nitro-general/2006-January/002516.html Nitro Testcases should require 'rubygems' * George asked for opinions on whether or not test cases should explicitly require rubygems. http://rubyforge.org/pipermail/nitro-general/2006-January/002517.html Parse_multipart test case * George requested patch to go along with test case. http://rubyforge.org/pipermail/nitro-general/2006-January/002518.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060120/aa97d678/attachment.html From james_b at neurogami.com Fri Jan 20 22:13:30 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 20 Jan 2006 20:13:30 -0700 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: References: <43D14E4A.4020401@neurogami.com> Message-ID: <43D1A6DA.4020903@neurogami.com> Bryan Soto wrote: > > Hi James, > > I wish I had a simple answer for you. Basic problem is a collision between > Jim's Builder and Glue::Builder and Glue being included into the top level > namespace by default. There is a $GLUE_DONT_INCLUDE flag, but it doesn't > appear to have been tested against as setting it before requiring nitro > gives some missing constant errors. I'll try to get a patch in to fix > that... > > In the mean time, there is an XmlHelper and RssHelper (0.9) available in > Nitro. Hopefully they'll meet your needs. Docs available via gem_server or > This doesn't really solve my problem. I have assorted code that emits XML using Builder, and I simply want to use it in other places. I do not want to have to learn and use two similar but not-really-the-same libraries; one is quite enough. (Indeed, I wonder why Nitro doesn't just use Jim's Builder rather than reinventing the wheel.) I've managed to get around the issue by copying the Builder::XmlMarkup lib and renaming things, and using my munged version. It's cheesy, but for the moment all I want to do is get a site finished. Thanks, James From james_b at neurogami.com Sat Jan 21 00:24:34 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 20 Jan 2006 22:24:34 -0700 Subject: [Nitro] Outputting the XML decl Message-ID: <43D1C592.9030407@neurogami.com> My templates have the xml declaration at the top But it gets stripped someplace before getting sent to the browser. How can I get Nitro to emit the markup I designate? Thanks, James From bryan.a.soto at gmail.com Sat Jan 21 00:25:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 20 Jan 2006 21:25:40 -0800 Subject: [Nitro] PATCH: Outstanding as of Jan. 20, 2006 In-Reply-To: References: Message-ID: > > 4 tiny fixes > * Pending > > http://rubyforge.org/pipermail/nitro-general/2006-January/002516.html > These were applied, no response email was sent. Sorry for the noise. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060121/1c29dc9e/attachment.html From bryan.a.soto at gmail.com Sat Jan 21 00:38:06 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 20 Jan 2006 21:38:06 -0800 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: <43D1A6DA.4020903@neurogami.com> References: <43D14E4A.4020401@neurogami.com> <43D1A6DA.4020903@neurogami.com> Message-ID: On 1/20/06, James Britt wrote: > > This doesn't really solve my problem. I have assorted code that emits > XML using Builder, and I simply want to use it in other places. > > I do not want to have to learn and use two similar but > not-really-the-same libraries; one is quite enough. > > (Indeed, I wonder why Nitro doesn't just use Jim's Builder rather than > reinventing the wheel.) > > I've managed to get around the issue by copying the Builder::XmlMarkup > lib and renaming things, and using my munged version. > > It's cheesy, but for the moment all I want to do is get a site finished. > Hi, I wasn't sure if they would, but I thought it couldn't hurt to mention them. Anyway, glad you got around the issue. I will follow up on that and try to get a patch in soon. Glue should play nice to avoid collisions like that. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060121/852c2d01/attachment.html From nitro at tap.homeip.net Sat Jan 21 15:51:23 2006 From: nitro at tap.homeip.net (Joshua Hoke) Date: Sat, 21 Jan 2006 15:51:23 -0500 Subject: [Nitro] Questions on Element, Control and rendering In-Reply-To: References: <43CE4368.5050209@gmail.com> Message-ID: <20060121205123.GA7840@blah> (Resent with the correct From address.) On Wed, Jan 18, 2006 at 03:50:54PM +0200, George Moschovitis wrote: > > As an example, I want to code a generic calendar that I can use > > everywhere I need/want. > > funny, i was working on this too ;-) This is what I use Nitro for (to generate a calendar of events.) I don't know how much you have worked out already, but attached is some code that might be helpful to generate the calendar. You should be able to use it like this: make_month_table(2006, 1) { |date| response = "#{date.mday}" # You could also add events or whatever content you want to go # in the cell for this day. return response } I guess it's up to you how to integrate it with what you're doing. Joshua Hoke -------------- next part -------------- require "date" require "time" def make_month_table(year, month) html = "" html += "\n" html += "\n" html += "\n" start_date = Date::civil(year, month, 1) end_date = (start_date >> 1) - 1 padcount = start_date.wday html += "\n\n" if padcount > 0 while padcount > 0 html += " \n" padcount -= 1 end start_date.step(end_date, 1) do |date| html += "\n" if date.wday == 0 html += " \n" html += "\n" if date.wday == 6 end if end_date.wday != 6 (end_date.wday+1).upto(6) { |x| html += "\n" } html += "\n" end html += "\n
" html += Date::DAYNAMES.join("") html += "
\n" html += yield date html += "
\n" return html end From james_b at neurogami.com Sun Jan 22 01:50:09 2006 From: james_b at neurogami.com (James Britt) Date: Sat, 21 Jan 2006 23:50:09 -0700 Subject: [Nitro] Mysterious behavior when Nitro is given a URL with '.' in it Message-ID: <43D32B21.9000601@neurogami.com> I think this was discussed here before, but I could not find the thread; my apologies if this is rehashing old issues. I'm planning on revamping a site and having it run on Nitro. All new URLs will (likely) omit file extensions, but I need to handle old links. Most of these look like this: wwww.mydomain.org/index.rb/2005/12#some-stuff It seems, though, that any URL with '.' it just causes Nitro to emit a blank page. I've tried mapping /index\.rb(.+)/, but to no avail. The site will run under fastcgi, or maybe scgi. I'd prefer to avoid having to rely on server-specific tricks, such as mod_rewrite, since I have people doing development with WEBrick as well. How do I get Nitro to play nice with dot.embedded.urls ? Thanks, James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From james_b at neurogami.com Sun Jan 22 02:34:53 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 22 Jan 2006 00:34:53 -0700 Subject: [Nitro] Mysterious behavior when Nitro is given a URL with '.' in it In-Reply-To: <43D32B21.9000601@neurogami.com> References: <43D32B21.9000601@neurogami.com> Message-ID: <43D3359D.3010504@neurogami.com> James Britt wrote: > I think this was discussed here before, but I could not find the thread; > my apologies if this is rehashing old issues. Indeed, I see that this is due to the same code that was a problem for me once before. > > I'm planning on revamping a site and having it run on Nitro. All new > URLs will (likely) omit file extensions, but I need to handle old links. > > Most of these look like this: > > wwww.mydomain.org/index.rb/2005/12#some-stuff > > It seems, though, that any URL with '.' it just causes Nitro to emit a > blank page. Various adapters have code such as this: def handle(req, res) unless handle_file(req, res) path = req.request_uri.path unless path =~ /\./ This is really bad. How, for example, can I create a URL that appears to refer to an image file (/image/foo.png) but is in fact dynamically generated or pulled from database? How can I remap old URLs? This pretty much means you can't have, say: /controller/method/this.or.that because Nitro just ignores it. I changed my version of Nitro to skip this check, and, with casual clicking around, saw no ill effects. Why not assume that all requests are Nitro requests and let the Nitro handle it as it sees fit? Here's a suggestion Ive just tried this out, seems OK, but who knows. In server.rb, I added another Server setting: # could use a better name here ... setting :skip_regex, :default => /\./, :doc => 'Skip requests where this pattern matches' In webrick.rb (which I'm currently using for dev) I replaced that hard-coded regex with this: # line 131 or so unless path =~ Nitro::Server.skip_regex And it seems OK when I add this to run.rb: Server.skip_regex = /\.gif|\.css/ which allows all sorts of funky URLs to get passed on, where I can route the request. One new problem, now, is that when handling URLs that end with an #anchor reference, the anchor name is lost. For example, with /Nov/26#this_is_some_item the path_info has '/Nov/26' but nothing in @request seems to have the complete URL or path or the anchor name ('this_is_some_item' . Ideas? Thanks, James From george.moschovitis at gmail.com Sun Jan 22 04:11:12 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 22 Jan 2006 11:11:12 +0200 Subject: [Nitro] Outputting the XML decl In-Reply-To: <43D1C592.9030407@neurogami.com> References: <43D1C592.9030407@neurogami.com> Message-ID: Hmm... Let me investigate this. In the meantime, you could add a simple compiler AFTER the template compiler that just adds the declaration (or anything else you need). regards, George On 1/21/06, James Britt wrote: > My templates have the xml declaration at the top > > > > But it gets stripped someplace before getting sent to the browser. > > How can I get Nitro to emit the markup I designate? > > Thanks, > > > > James > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Jan 22 05:02:51 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 22 Jan 2006 12:02:51 +0200 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: <43D1A6DA.4020903@neurogami.com> References: <43D14E4A.4020401@neurogami.com> <43D1A6DA.4020903@neurogami.com> Message-ID: > This doesn't really solve my problem. I have assorted code that emits > XML using Builder, and I simply want to use it in other places. > I do not want to have to learn and use two similar but > not-really-the-same libraries; one is quite enough. > (Indeed, I wonder why Nitro doesn't just use Jim's Builder rather than > reinventing the wheel.) Hello James, I just thought that my version of builder was *better* for my needs. BTW it works a bit like tha MARKABY code presented lately by why. Anyway, I agree that this is problematic and If noone has any objection I will rename Glue builder slightly to avoid the colision. As Glue::Builder is used indirectly I dont think there will be a problem with current nitro apps. BTW have a look at how, Glue builder works, perhaps you will like it. You can use it in non-Nitro applications too. regards, George. > > I've managed to get around the issue by copying the Builder::XmlMarkup > lib and renaming things, and using my munged version. > > It's cheesy, but for the moment all I want to do is get a site finished. > > Thanks, > > > James > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Jan 22 05:19:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 22 Jan 2006 12:19:15 +0200 Subject: [Nitro] Questions on Element, Control and rendering In-Reply-To: <20060121205123.GA7840@blah> References: <43CE4368.5050209@gmail.com> <20060121205123.GA7840@blah> Message-ID: thanks ;-) I will have a look. -g. On 1/21/06, Joshua Hoke wrote: > (Resent with the correct From address.) > > On Wed, Jan 18, 2006 at 03:50:54PM +0200, George Moschovitis wrote: > > > As an example, I want to code a generic calendar that I can use > > > everywhere I need/want. > > > > funny, i was working on this too ;-) > > > This is what I use Nitro for (to generate a calendar of events.) I don't > know how much you have worked out already, but attached is some code > that might be helpful to generate the calendar. You should be able to > use it like this: > > make_month_table(2006, 1) { |date| > response = "#{date.mday}" > # You could also add events or whatever content you want to go > # in the cell for this day. > > return response > } > > I guess it's up to you how to integrate it with what you're doing. > > Joshua Hoke > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Jan 22 05:25:02 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 22 Jan 2006 12:25:02 +0200 Subject: [Nitro] Mysterious behavior when Nitro is given a URL with '.' in it In-Reply-To: <43D3359D.3010504@neurogami.com> References: <43D32B21.9000601@neurogami.com> <43D3359D.3010504@neurogami.com> Message-ID: James, thanks a lot of the suggestion, I will have to go to the office to fix this, but I will probably add something like what you describe. About the anchor thing, again I cannot test this now, will have to go to the office. Expect a fix in the repo version real soon. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Sun Jan 22 10:24:33 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 22 Jan 2006 08:24:33 -0700 Subject: [Nitro] Outputting the XML decl In-Reply-To: References: <43D1C592.9030407@neurogami.com> Message-ID: <43D3A3B1.7040304@neurogami.com> George Moschovitis wrote: > Hmm... Let me investigate this. > > In the meantime, you could add a simple compiler AFTER the template > compiler that just adds the declaration (or anything else you need). I'll look into that. Thanks, James From james_b at neurogami.com Sun Jan 22 10:26:38 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 22 Jan 2006 08:26:38 -0700 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: References: <43D14E4A.4020401@neurogami.com> <43D1A6DA.4020903@neurogami.com> Message-ID: <43D3A42E.3020202@neurogami.com> George Moschovitis wrote: >>This doesn't really solve my problem. I have assorted code that emits >>XML using Builder, and I simply want to use it in other places. >>I do not want to have to learn and use two similar but >>not-really-the-same libraries; one is quite enough. >>(Indeed, I wonder why Nitro doesn't just use Jim's Builder rather than >>reinventing the wheel.) > > > Hello James, > > I just thought that my version of builder was *better* for my needs. > BTW it works a bit like tha MARKABY code presented lately by why. Yes, that caught my eye after reading about Markaby. Anyway, the issue for me is not so much which is better (I haven't done anything thing with the Nitro Builder) but a desire to reuse code fragments. Thanks, James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From Aleksi.Niemela at cs.helsinki.fi Sun Jan 22 10:56:49 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Sun, 22 Jan 2006 17:56:49 +0200 Subject: [Nitro] Nitro 0.27 troubles Message-ID: <43D3AB41.20702@cs.helsinki.fi> Hello, I want to see if there's anyone else with troubling Nitro 0.27. My app worked well with 0.25. Then I updated to 0.27 and it stopped working. Client won't get even the first page. Nitro says it has compiled the xhtml-file but then gives out nothing to the client. Now, I've been able to make simple script with same behavior. If I tell Og to Foo.find_by_bar() directly everything works out well. If the same is done inside Prototype controller it hangs. George wasn't able to pin down the reason for this, so I wonder if anyone has bumped into it and maybe even solved it. If no one else has this behavior I suspect there's something very wrong with my setup. I installed gems through gem update. I'll remove all Nitro/Og/Glue installations and see if fresh install makes it work. Besides that I'm clueless how to go forward. - Aleksi I'm running this on Win XP + Cygwin, ruby-1.8.3, Nitro&rest 0.27 installed from gems automatically (not manually fetched and installed), Postgres-pr 0.4.0. Here's the code: #!/usr/bin/env ruby require 'nitro' require 'og' class Foo property :bar, String def initialize(bar) @bar = bar end end class Configuration attr_accessor :db, :webserver def initialize @db = { :address => "localhost", :destroy => false, :name => "devel_foobar", :store => "psql", :user => "foo", :password => "foobar", :connection_count => 1 } end end config = Configuration.new puts "Setting up connection to ### #{config.db[:address]}:#{config.db[:name]}" Og.setup(config.db) class Proto def foo puts "finding" foo = Foo.find_by_bar("bar") puts "found #{foo.oid}" %{

#{foo.bar}

} end end if $0 == __FILE__ if ARGV.shift == "og" Foo.create("bar") p Foo.find_by_bar("bar") else Nitro.run(Proto) end end ################# ################# And here're the outputs, first with just Og: $ ruby problematic_run.rb og Setting up connection to ### localhost:devel_centerpiece I, [2006-01-22T17:51:45.722000 #4520] INFO -- : Og uses the Psql store. I, [2006-01-22T17:51:46.575000 #4520] INFO -- : Created table 'ogfoo'. D, [2006-01-22T17:51:46.637000 #4520] DEBUG -- : PostgreSQL processing foreign key constraints D, [2006-01-22T17:51:46.646000 #4520] DEBUG -- : PostgreSQL finished setting constraints. No action was taken in 0.00 se conds. # $ ruby problematic_run.rb Setting up connection to ### localhost:devel_centerpiece I, [2006-01-22T17:52:00.825125 #5152] INFO -- : Og uses the Psql store. D, [2006-01-22T17:52:01.421125 #5152] DEBUG -- : Table ogfoo already exists D, [2006-01-22T17:52:01.480125 #5152] DEBUG -- : PostgreSQL processing foreign key constraints D, [2006-01-22T17:52:01.480125 #5152] DEBUG -- : PostgreSQL finished setting constraints. No action was taken in 0.00 se conds. ==> Setup for debug mode ==> Listening at 0.0.0.0:9999. ==> Press Ctrl-C to shutdown; Run with --help for options. [2006-01-22 17:52:01] INFO WEBrick 1.3.1 [2006-01-22 17:52:01] INFO ruby 1.8.3 (2005-09-21) [i386-cygwin] [2006-01-22 17:52:01] INFO WEBrick::HTTPServer#start: pid=5152 port=9999 D, [2006-01-22T17:52:02.355125 #5152] DEBUG -- : Rendering '/foo'. D, [2006-01-22T17:52:02.356125 #5152] DEBUG -- : Compiling action 'Proto#foo' finding From Aleksi.Niemela at cs.helsinki.fi Sun Jan 22 11:06:31 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Sun, 22 Jan 2006 18:06:31 +0200 Subject: [Nitro] Nitro 0.27 troubles In-Reply-To: <43D3AB41.20702@cs.helsinki.fi> References: <43D3AB41.20702@cs.helsinki.fi> Message-ID: <43D3AD87.10908@cs.helsinki.fi> Aleksi Niemela kirjoitti: > I want to see if there's anyone else with troubling Nitro 0.27. There probably is someone with these problems if anyone else is doing the same as I was when setting up Og as in my example code. After rereading my post after I sent it, I occurred me "how about testing with multiple connections, maybe just first is failing". So I did: The code in my previous mail with :connection_count => 5 worked fine even with Nitro. Now, I don't know what has changed but I suspect Nitro issues Og to check something extra at Og.setup or after that and that some thing doesn't return the connection it's using. Therefore with only one connection we're bound to wait eternally to get a free connection. And only one connection is permanently consumed away from the pool as with two the code runs just ok. Well this started out as a frustrated call for help but ended up being a bug report. :) And I was fighting with this a week! Uh, that was time well spent :). - Aleksi From james_b at neurogami.com Mon Jan 23 00:26:27 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 22 Jan 2006 22:26:27 -0700 Subject: [Nitro] Another site powered by Nitro Message-ID: <43D46903.9080807@neurogami.com> I still have a few issues handling old URLs and links to static content, but overall the site looks better and runs faster: http://www.ruby-doc.org/ James Britt -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From m.fellinger at gmail.com Mon Jan 23 02:16:01 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Mon, 23 Jan 2006 16:16:01 +0900 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D46903.9080807@neurogami.com> References: <43D46903.9080807@neurogami.com> Message-ID: <200601231616.01840.manveru@weez.co.jp> Now that's what i would call a showcase for nitro :) at least everyone who knows ruby will run over that page once in a while - neat layout btw - only the rdoc doesn't really fit into that :| however, congratulations and keep your engine running on nitro ^^ ~~~~manveru Am Monday 23 January 2006 14:26 schrieb James Britt: > I still have a few issues handling old URLs and links to static content, > but overall the site looks better and runs faster: > > http://www.ruby-doc.org/ > > James Britt From george.moschovitis at gmail.com Mon Jan 23 04:23:01 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 11:23:01 +0200 Subject: [Nitro] Cannot require 'builder' in a Nitro app In-Reply-To: <43D3A42E.3020202@neurogami.com> References: <43D14E4A.4020401@neurogami.com> <43D1A6DA.4020903@neurogami.com> <43D3A42E.3020202@neurogami.com> Message-ID: > Anyway, the issue for me is not so much which is better (I haven't done > anything thing with the Nitro Builder) but a desire to reuse code fragments. I understand that, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 23 04:04:10 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 11:04:10 +0200 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D46903.9080807@neurogami.com> References: <43D46903.9080807@neurogami.com> Message-ID: > I still have a few issues handling old URLs and links to static content, > but overall the site looks better and runs faster: > > http://www.ruby-doc.org/ Just f*ckin' incredible ;-) Great work James ;-) BTW, If you would like to send me the source (privately) I could find the time and offer you some advice on some Nitro best practices and how to optimize this for performance. best regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 23 04:19:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 11:19:28 +0200 Subject: [Nitro] Nitro 0.27 troubles In-Reply-To: <43D3AD87.10908@cs.helsinki.fi> References: <43D3AB41.20702@cs.helsinki.fi> <43D3AD87.10908@cs.helsinki.fi> Message-ID: > The code in my previous mail with > > :connection_count => 5 :connection_count => 1 is wrong, this causes thread starvation if you are running with Webrick (ie Og in multithread mode). If I remembet correctly I had a comment somewhere to warn agains this. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From lasso at lassoweb.nu Mon Jan 23 05:34:36 2006 From: lasso at lassoweb.nu (Lars Olsson) Date: Mon, 23 Jan 2006 11:34:36 +0100 (CET) Subject: [Nitro] Og - Unexspected results when using two Sqlite3 stores Message-ID: <29165.192.176.230.1.1138012476.squirrel@www.scorpionshops.com> Hi all, I recently discovered Og and started playing around with it. Very cool stuff! However, when trying to work with two Sqlite3 stores in the same program I ran into some unexspected trouble. After reading through an example on the website (http://repo.nitrohq.com/og/examples/mysql_to_psql.rb) I wanted to try creating something similar myself. I came up with the following: # Turn on Og debugging $DBG = true # Require necessary modules require 'rubygems' require 'og' # Set up stores db1 = Og.setup(:destroy => true, :name => 'db1', :store => 'sqlite') db2 = Og.setup(:destroy => true, :name => 'db2', :store => 'sqlite') # Define example class class Foo property :bar, String property :baz, Fixnum def initialize(bar, baz) @bar = bar @baz = baz end end # Let the first store manage Foo objects db1.manage(Foo) # Create some Foo objects Foo.create('Ten', 10) Foo.create('Twenty', 20) Foo.create('Thirty', 30) Foo.create('Forty', 40) # Fetch all Foo objects from the first store coll = Foo.all # Don't let the first store manage Foo objects anymore db1.unmanage_class(Foo) # Let the second store manage Foo objects db2.manage(Foo) # Print out the classes managed by each store puts "Classes managed by db1: #{db1.managed_classes}" puts "Classes managed by db2: #{db2.managed_classes}" # Save all Foo objects in the second store # This doesn't work! Og updates the first store, not the second! coll.each do |f| f.save end The program generates the following output: I, [2006-01-21T12:36:54.953000 #1820] INFO -- : Og uses the Sqlite store. I, [2006-01-21T12:36:55.015000 #1820] INFO -- : Cannot drop 'db1'! D, [2006-01-21T12:36:55.046000 #1820] DEBUG -- : Og manageable classes: [] I, [2006-01-21T12:36:55.046000 #1820] INFO -- : Og uses the Sqlite store. I, [2006-01-21T12:36:55.046000 #1820] INFO -- : Cannot drop 'db2'! D, [2006-01-21T12:36:55.062000 #1820] DEBUG -- : Og manageable classes: [] I, [2006-01-21T12:36:55.078000 #1820] INFO -- : Created table 'ogfoo'. D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Ten',10,NULL) D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Twenty',20,NULL) D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Thirty',30,NULL) D, [2006-01-21T12:36:55.093000 #1820] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Forty',40,NULL) D, [2006-01-21T12:36:55.093000 #1820] DEBUG -- : SELECT * FROM ogfoo e:/program/ruby/lib/ruby/gems/1.8/gems/og-0.27.0/lib/og/store/sql.rb:314: warning: already initialized constant OGTABLE D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : Table already exists Classes managed by db1: Classes managed by db2: Foo D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET bar='Ten', baz=10 WHERE oid=1 D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET bar='Twenty', baz=20 WHERE oid=2 D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET bar='Thirty', baz=30 WHERE oid=3 D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET bar='Forty', baz=40 WHERE oid=4 The problem is that even if db2 is managing Foo object, Og still updates db1. db2 just ends up empty. I'm not entirely sure whether this is a bug or by design, but it sure is confusing. Can anyone please clarify this for me? Am I doing something wrong or is this a bug? Kindly /Lars -- ________________________________________ Lars Olsson lasso at lassoweb.nu http://www.lassoweb.nu/ -- ________________________________________ Lars Olsson lasso at lassoweb.nu http://www.lassoweb.nu/ From george.moschovitis at gmail.com Mon Jan 23 06:49:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 13:49:15 +0200 Subject: [Nitro] Og - Unexspected results when using two Sqlite3 stores In-Reply-To: <29165.192.176.230.1.1138012476.squirrel@www.scorpionshops.com> References: <29165.192.176.230.1.1138012476.squirrel@www.scorpionshops.com> Message-ID: Lars, first of all welcome to the list. About your problem, I plan to have a look to the multiple backend feature of Og for the next version, so I will most probably have a detailed look at your problem in the following days. So please be patient. In the meantime perhaps you will get some help form another one on this friendly list ;-) regards, George. On 1/23/06, Lars Olsson wrote: > > Hi all, > > I recently discovered Og and started playing around with it. Very cool > stuff! > > However, when trying to work with two Sqlite3 stores in the same program > I ran into some unexspected trouble. After reading through an example on > the website (http://repo.nitrohq.com/og/examples/mysql_to_psql.rb) I > wanted to try creating something similar myself. I came up with the > following: > > > # Turn on Og debugging > $DBG = true > > # Require necessary modules > require 'rubygems' > require 'og' > > # Set up stores > db1 = Og.setup(:destroy => true, :name => 'db1', :store => 'sqlite') > db2 = Og.setup(:destroy => true, :name => 'db2', :store => 'sqlite') > > # Define example class > class Foo > property :bar, String > property :baz, Fixnum > > def initialize(bar, baz) > @bar = bar > @baz = baz > end > end > > # Let the first store manage Foo objects > db1.manage(Foo) > > # Create some Foo objects > Foo.create('Ten', 10) > Foo.create('Twenty', 20) > Foo.create('Thirty', 30) > Foo.create('Forty', 40) > > # Fetch all Foo objects from the first store > coll = Foo.all > > # Don't let the first store manage Foo objects anymore > db1.unmanage_class(Foo) > > # Let the second store manage Foo objects > db2.manage(Foo) > > # Print out the classes managed by each store > puts "Classes managed by db1: #{db1.managed_classes}" > puts "Classes managed by db2: #{db2.managed_classes}" > > # Save all Foo objects in the second store > # This doesn't work! Og updates the first store, not the second! > coll.each do |f| > f.save > end > > > The program generates the following output: > > > I, [2006-01-21T12:36:54.953000 #1820] INFO -- : Og uses the Sqlite store. > I, [2006-01-21T12:36:55.015000 #1820] INFO -- : Cannot drop 'db1'! > D, [2006-01-21T12:36:55.046000 #1820] DEBUG -- : Og manageable classes: [] > I, [2006-01-21T12:36:55.046000 #1820] INFO -- : Og uses the Sqlite store. > I, [2006-01-21T12:36:55.046000 #1820] INFO -- : Cannot drop 'db2'! > D, [2006-01-21T12:36:55.062000 #1820] DEBUG -- : Og manageable classes: [] > I, [2006-01-21T12:36:55.078000 #1820] INFO -- : Created table 'ogfoo'. > D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo > (bar,baz,oid) VALUES ('Ten',10,NULL) > D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo > (bar,baz,oid) VALUES ('Twenty',20,NULL) > D, [2006-01-21T12:36:55.078000 #1820] DEBUG -- : INSERT INTO ogfoo > (bar,baz,oid) VALUES ('Thirty',30,NULL) > D, [2006-01-21T12:36:55.093000 #1820] DEBUG -- : INSERT INTO ogfoo > (bar,baz,oid) VALUES ('Forty',40,NULL) > D, [2006-01-21T12:36:55.093000 #1820] DEBUG -- : SELECT * FROM ogfoo > e:/program/ruby/lib/ruby/gems/1.8/gems/og-0.27.0/lib/og/store/sql.rb:314: > warning: already initialized constant OGTABLE > D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : Table already exists > Classes managed by db1: > Classes managed by db2: Foo > D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET > bar='Ten', baz=10 WHERE oid=1 > D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET > bar='Twenty', baz=20 WHERE oid=2 > D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET > bar='Thirty', baz=30 WHERE oid=3 > D, [2006-01-21T12:36:55.109000 #1820] DEBUG -- : UPDATE ogfoo SET > bar='Forty', baz=40 WHERE oid=4 > > > The problem is that even if db2 is managing Foo object, Og still updates > db1. db2 just ends up empty. I'm not entirely sure whether this is a bug > or by design, but it sure is confusing. Can anyone please clarify this > for me? Am I doing something wrong or is this a bug? > > > Kindly > > /Lars > > -- > ________________________________________ > Lars Olsson > lasso at lassoweb.nu > http://www.lassoweb.nu/ > > > > > -- > ________________________________________ > Lars Olsson > lasso at lassoweb.nu > http://www.lassoweb.nu/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Mon Jan 23 08:27:24 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 23 Jan 2006 14:27:24 +0100 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D46903.9080807@neurogami.com> References: <43D46903.9080807@neurogami.com> Message-ID: <43D4D9BC.30505@gmail.com> James Britt wrote: >I still have a few issues handling old URLs and links to static content, >but overall the site looks better and runs faster: > >http://www.ruby-doc.org/ > >James Britt > > > Hi James, Well done, the site is very nice and much more readable now. Any chances that rdog gets used on your site ? The ruby community definately needs something like php's comments. Also the following url returns a 500 code : http://www.ruby-doc.org/docbar/toc_tut.html Cheers, Jonas Pfenniger From chris.burnley at gmail.com Mon Jan 23 08:38:19 2006 From: chris.burnley at gmail.com (Chris Burnley) Date: Mon, 23 Jan 2006 13:38:19 +0000 Subject: [Nitro] wrong number of arguments (8 for 7) Kirby Message-ID: <76205f0b0601230538h57804ff5u4d1a80ff157c3179@mail.gmail.com> Hi, I'm running the blog example (examples-0.27.0), but instead of using mysql, I'm using Kirbybase (2.5.2) and I get the following error: ERROR -- : wrong number of arguments (8 for 7) /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in 'kb_create' /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in 'create_result_rec' /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3174:in 'get_matches' This seems to be on the list method, as the insert into the db looks ok ( from looking at the text files that Kirby creates ). I've also seen the same error on the "todo" tutorial ( can't remember who wrote that though). I'm a r00b, so I could be completely off here, but is it that the numbers of columns returned from Kirby into the enchanted class are different to what is expected ? If I look at the database files that kirby creates, I notice that recno:Integer is listed twice. regards, Chris Burnley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060123/c36c1661/attachment.html From zimba.tm at gmail.com Mon Jan 23 09:59:54 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 23 Jan 2006 15:59:54 +0100 Subject: [Nitro] [bug] Corrected spark's < > in Message-ID: <43D4EF6A.1030803@gmail.com> You remember the bug in Spark with > and <'s ? Here is the patch. It's a one-liner. Cheers, Jonas Pfenniger -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tgz Type: application/octet-stream Size: 3846 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060123/53f3f425/attachment.obj From george.moschovitis at gmail.com Mon Jan 23 09:06:35 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 16:06:35 +0200 Subject: [Nitro] [bug] Corrected spark's < > in In-Reply-To: <43D4EF6A.1030803@gmail.com> References: <43D4EF6A.1030803@gmail.com> Message-ID: Nice timing, I am in the middle of updating the nitrohq.com server... -g. On 1/23/06, Jonas Pfenniger wrote: > You remember the bug in Spark with > and <'s ? > > Here is the patch. It's a one-liner. > > > Cheers, > Jonas Pfenniger > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 23 10:13:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 Jan 2006 17:13:24 +0200 Subject: [Nitro] nitrohq.com update Message-ID: Dear devs, I updated the nitrohq.com to the latest version of spark. I used sparks load/dump so the recent changes pages has many ..changes ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Mon Jan 23 10:56:26 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 23 Jan 2006 08:56:26 -0700 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D4D9BC.30505@gmail.com> References: <43D46903.9080807@neurogami.com> <43D4D9BC.30505@gmail.com> Message-ID: <43D4FCAA.2010801@neurogami.com> Jonas Pfenniger wrote: > James Britt wrote: > >> I still have a few issues handling old URLs and links to static >> content, but overall the site looks better and runs faster: >> >> http://www.ruby-doc.org/ >> >> James Britt >> >> >> > Hi James, > > Well done, the site is very nice and much more readable now. > > Any chances that rdog gets used on your site ? The ruby community > definitely needs something like php's comments. I would love to get rdog running. I agree that having doc comments would be sweet. > > Also the following url returns a 500 code : > http://www.ruby-doc.org/docbar/toc_tut.html Ug. OK, I'll take a look. Still some issues with static pages. James -- http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Mon Jan 23 13:39:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 23 Jan 2006 10:39:36 -0800 Subject: [Nitro] wrong number of arguments (8 for 7) Kirby In-Reply-To: <76205f0b0601230538h57804ff5u4d1a80ff157c3179@mail.gmail.com> References: <76205f0b0601230538h57804ff5u4d1a80ff157c3179@mail.gmail.com> Message-ID: Hi, tis a bug. Could you try the attached patch? On 1/23/06, Chris Burnley wrote: > > Hi, I'm running the blog example (examples-0.27.0), but instead of using > mysql, I'm using Kirbybase (2.5.2) and I get the following error: > > ERROR -- : wrong number of arguments (8 for 7) > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in > 'kb_create' > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in > 'create_result_rec' > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3174:in > 'get_matches' > > This seems to be on the list method, as the insert into the db looks ok ( > from looking at the text files that Kirby creates ). > > I've also seen the same error on the "todo" tutorial ( can't remember who > wrote that though). > > I'm a r00b, so I could be completely off here, but is it that the numbers > of columns returned from Kirby into the enchanted class are different to > what is expected ? > > If I look at the database files that kirby creates, I notice that > recno:Integer is listed twice. > > regards, > > Chris Burnley > > _______________________________________________ > 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/20060123/500eb69a/attachment.html -------------- next part -------------- --- lib/og/store/kirby.rb~ 2006-01-23 10:33:10.000000000 -0800 +++ lib/og/store/kirby.rb 2006-01-23 10:33:29.000000000 -0800 @@ -68,14 +68,14 @@ klass.send :alias_method, :recno, :oid klass.send :alias_method, :recno=, :oid= - unless klass.properties.include? :recno - klass.property :recno, Fixnum - end +# unless klass.properties.include? :recno +# klass.property :recno, Fixnum +# end symbols = klass.properties.keys klass.module_eval %{ - def self.kb_create(#{symbols.join(', ')}) + def self.kb_create(recno, #{symbols.join(', ')}) obj = self.allocate obj.recno = recno #{ symbols.map { |s| "obj.#{s} = #{s}; "} } From zimba.tm at gmail.com Mon Jan 23 14:48:39 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 23 Jan 2006 20:48:39 +0100 Subject: [Nitro] BUG: undefined method 'index' for nil:NilClass Message-ID: <43D53317.2070403@gmail.com> Nitro was trying to find the index of a non-existent parameter in the query_string. It occured when I tried to use scaffold for example. It was pretty long to find because that part is evaled. Follows the patch. Cheers, Jonas Pfenniger -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tgz Type: application/octet-stream Size: 3897 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060123/2b4e10a5/attachment.obj From bryan.a.soto at gmail.com Mon Jan 23 14:05:02 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 23 Jan 2006 11:05:02 -0800 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D46903.9080807@neurogami.com> References: <43D46903.9080807@neurogami.com> Message-ID: On 1/22/06, James Britt wrote: > > I still have a few issues handling old URLs and links to static content, > but overall the site looks better and runs faster: > > http://www.ruby-doc.org/ > > James Britt > > Hi James, I really like the design. Nice work! Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060123/b4b368ba/attachment.html From james_b at neurogami.com Mon Jan 23 14:14:36 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 23 Jan 2006 12:14:36 -0700 Subject: [Nitro] Another site powered by Nitro In-Reply-To: References: <43D46903.9080807@neurogami.com> Message-ID: <43D52B1C.9090506@neurogami.com> Bryan Soto wrote: > On 1/22/06, James Britt wrote: > >>I still have a few issues handling old URLs and links to static content, >>but overall the site looks better and runs faster: >> >>http://www.ruby-doc.org/ >> >>James Britt >> >> > > Hi James, > > I really like the design. Nice work! Thanks! You can thank Dan Ritz, one of my partners at 30 Second Rule, for all the good-looking stuff. There are a few things that need tweaking, but we hoe to get it all in shape over the next few days. -- James Britt "Blanket statements are over-rated" From zimba.tm at gmail.com Mon Jan 23 15:48:32 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Mon, 23 Jan 2006 21:48:32 +0100 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules In-Reply-To: References: <43C67C09.7060208@gmail.com> Message-ID: <43D54120.5040900@gmail.com> Hi George, I created a small patch for this. It's not quite it. I have redefined String.underscore to escape :: to _ . It's a bit ugly but it works. George Moschovitis wrote: >Zimb, > >ok will check this! > >-g. > >On 1/12/06, Jonas Pfenniger wrote: > > >>module Test >> class Item >> property :name >> end >>end >> >>Og creates an ogtest_item table which contains the items. >> >>When trying to access it in the AdminController, it generates a link >>called http://localhost:9999/admin/test::item/list which doesn't exist. >> >>It would be nice to have a link like >>http://localhost:9999/admin/test/item/list instead. I wish I could do >>this, but Nitro has too much magic that I don't understand. >> >> >>Cheers, >> zimba >>_______________________________________________ >>Nitro-general mailing list >>Nitro-general at rubyforge.org >>http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.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: bundle.tgz Type: application/octet-stream Size: 3955 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060123/d6953ce1/attachment.obj From aidan at yoyo.org Mon Jan 23 17:06:13 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Tue, 24 Jan 2006 09:06:13 +1100 Subject: [Nitro] Another site powered by Nitro In-Reply-To: <43D46903.9080807@neurogami.com> References: <43D46903.9080807@neurogami.com> Message-ID: <89AD73BA-7D7B-4929-88D5-63494915B966@yoyo.org> Nicely done James, and very high profile for Nitro. I'd like to get http://www.infurious.com powered by Nitro, but I don't have control over the web server (it's apache), so I only have regular CGI ruby access, which is a royal pain. Having said that, files with the .fcgi extension also seem to execute, but I've no real notion of how FastCGI works, so no idea if this means it's running :-) Anyway, that was a digression. Nice new look to ruby-doc.org :-) Aidan On 23/01/2006, at 4:26 PM, James Britt wrote: > I still have a few issues handling old URLs and links to static > content, > but overall the site looks better and runs faster: > > http://www.ruby-doc.org/ > > James Britt > > -- > > http://www.ruby-doc.org - Ruby Help & Documentation > http://www.artima.com/rubycs/ - The Journal By & For Rubyists > http://www.rubystuff.com - The Ruby Store for Ruby Stuff > http://www.jamesbritt.com - Playing with Better Toys > http://www.30secondrule.com - Building Better Tools > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From chris.burnley at gmail.com Mon Jan 23 18:02:12 2006 From: chris.burnley at gmail.com (Chris Burnley) Date: Mon, 23 Jan 2006 23:02:12 +0000 Subject: [Nitro] wrong number of arguments (8 for 7) Kirby In-Reply-To: References: <76205f0b0601230538h57804ff5u4d1a80ff157c3179@mail.gmail.com> Message-ID: <76205f0b0601231502h1ae0a600l11d16c5fcb4e6617@mail.gmail.com> Cool, thinks works. Many thanks, Chris On 1/23/06, Bryan Soto wrote: > > Hi, tis a bug. Could you try the attached patch? > > On 1/23/06, Chris Burnley wrote: > > > Hi, I'm running the blog example (examples-0.27.0), but instead of using > > mysql, I'm using Kirbybase (2.5.2) and I get the following error: > > > > ERROR -- : wrong number of arguments (8 for 7) > > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in > > 'kb_create' > > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3125:in > > 'create_result_rec' > > /usr/lib/ruby/gems/1.8/gems/KirbyBase-2.5.2/lib/kirbybase.rb:3174:in > > 'get_matches' > > > > This seems to be on the list method, as the insert into the db looks ok > > ( from looking at the text files that Kirby creates ). > > > > I've also seen the same error on the "todo" tutorial ( can't remember > > who wrote that though). > > > > I'm a r00b, so I could be completely off here, but is it that the > > numbers of columns returned from Kirby into the enchanted class are > > different to what is expected ? > > > > If I look at the database files that kirby creates, I notice that > > recno:Integer is listed twice. > > > > regards, > > > > Chris Burnley > > > > _______________________________________________ > > 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/20060123/20e59de2/attachment.html From bryan.a.soto at gmail.com Mon Jan 23 18:22:06 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 23 Jan 2006 15:22:06 -0800 Subject: [Nitro] PATCH: bugfix_kirby_store Message-ID: Attached removes recno from properties. Makes Kirby store work again. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060123/e2cdfa5d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bugfix_kirby_store Type: application/octet-stream Size: 11688 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060123/e2cdfa5d/attachment.obj From bryan.a.soto at gmail.com Mon Jan 23 19:19:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 23 Jan 2006 16:19:07 -0800 Subject: [Nitro] Og - Unexspected results when using two Sqlite3 stores In-Reply-To: <29165.192.176.230.1.1138012476.squirrel@www.scorpionshops.com> References: <29165.192.176.230.1.1138012476.squirrel@www.scorpionshops.com> Message-ID: Hi, On 1/23/06, Lars Olsson wrote: > > > Hi all, > > I recently discovered Og and started playing around with it. Very cool > stuff! > > However, when trying to work with two Sqlite3 stores in the same program > I ran into some unexspected trouble. After reading through an example on > the website (http://repo.nitrohq.com/og/examples/mysql_to_psql.rb) I > wanted to try creating something similar myself. I came up with the > following: > > > # Turn on Og debugging > $DBG = true > > # Require necessary modules > require 'rubygems' > require 'og' # Added Og.thread_safe = false # So Og doesn't pool the first setup. # Set up stores > db1 = Og.setup(:destroy => true, :name => 'db1', :store => 'sqlite') > db2 = Og.setup(:destroy => true, :name => 'db2', :store => 'sqlite') > > # Define example class > class Foo > property :bar, String > property :baz, Fixnum > > def initialize(bar, baz) > @bar = bar > @baz = baz > end > end > > # Let the first store manage Foo objects > db1.manage(Foo) > > # Create some Foo objects > Foo.create('Ten', 10) > Foo.create('Twenty', 20) > Foo.create('Thirty', 30) > Foo.create('Forty', 40) > > # Fetch all Foo objects from the first store > coll = Foo.all > > # Don't let the first store manage Foo objects anymore > db1.unmanage_class(Foo) > > # Let the second store manage Foo objects > db2.manage(Foo) > > # Print out the classes managed by each store > puts "Classes managed by db1: #{db1.managed_classes}" > puts "Classes managed by db2: #{db2.managed_classes}" > > # Save all Foo objects in the second store > # This doesn't work! Og updates the first store, not the second! > coll.each do |f| f.insert # changed to this from # f.save end > > > The program generates the following output: > > I, [2006-01-23T15:59:50.417551 #6085] INFO -- : Og uses the Sqlite store. D, [2006-01-23T15:59:50.866242 #6085] DEBUG -- : Og manageable classes: [] I, [2006-01-23T15:59:50.866801 #6085] INFO -- : Og uses the Sqlite store. D, [2006-01-23T15:59:50.875152 #6085] DEBUG -- : Og manageable classes: [] I, [2006-01-23T15:59:51.639264 #6085] INFO -- : Created table 'ogfoo'. D, [2006-01-23T15:59:51.861332 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Ten',10,NULL) D, [2006-01-23T15:59:52.222801 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Twenty',20,NULL) D, [2006-01-23T15:59:52.578944 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Thirty',30,NULL) D, [2006-01-23T15:59:52.913715 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Forty',40,NULL) D, [2006-01-23T15:59:53.220872 #6085] DEBUG -- : SELECT * FROM ogfoo /usr/lib/ruby/gems/1.8/gems/og-0.27.0/lib/og/store/sql.rb:314: warning: already initialized constant OGTABLE I, [2006-01-23T15:59:53.709571 #6085] INFO -- : Created table 'ogfoo'. Classes managed by db1: Classes managed by db2: Foo D, [2006-01-23T15:59:53.713887 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Ten',10,1) D, [2006-01-23T15:59:54.177731 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Twenty',20,2) D, [2006-01-23T15:59:54.483771 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Thirty',30,3) D, [2006-01-23T15:59:55.231459 #6085] DEBUG -- : INSERT INTO ogfoo (bar,baz,oid) VALUES ('Forty',40,4) Hope that helps, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060123/c29ee985/attachment.html From m.fellinger at gmail.com Mon Jan 23 20:08:00 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Tue, 24 Jan 2006 10:08:00 +0900 Subject: [Nitro] [bug] Corrected spark's < > in In-Reply-To: References: <43D4EF6A.1030803@gmail.com> Message-ID: <9c00d3e00601231708t1f4579fam@mail.gmail.com> Thx for that patch Jonas, i never seemed to get this down to onesimple line so it disappeared (no, i'm sure it wasn't because georgeprefers red- over bluecloth, i'm entirely sure ^^)However, also thx to you george, this is one of the main-buggers thatwas scaring some people off (i mean, a wiki for a web-dev-frameworkthat doesn't display source correctly is not too convincing) Now, with nitrohq up and better than ever - let's start celebrating!(i serve free beer in the channel ;) ~~~~manveru 2006/1/23, George Moschovitis :> Nice timing,>> I am in the middle of updating the nitrohq.com server...>> -g.>> On 1/23/06, Jonas Pfenniger wrote:> > You remember the bug in Spark with > and <'s ?> >> > Here is the patch. It's a one-liner.> >> >> > Cheers,> > Jonas Pfenniger> >> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From james_b at neurogami.com Tue Jan 24 02:01:17 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 24 Jan 2006 00:01:17 -0700 Subject: [Nitro] How do I get started with RDog? Message-ID: <43D5D0BD.9000806@neurogami.com> My apologies if this is off-topic, but what do I need to do to start getting RDoc serving Ruby API docs off of ruby-doc? Thanks! -- James Britt "Blanket statements are over-rated" From james_b at neurogami.com Tue Jan 24 02:04:01 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 24 Jan 2006 00:04:01 -0700 Subject: [Nitro] How do I get started with RDog? In-Reply-To: <43D5D0BD.9000806@neurogami.com> References: <43D5D0BD.9000806@neurogami.com> Message-ID: <43D5D161.3060203@neurogami.com> James Britt wrote: > My apologies if this is off-topic, but what do I need to do to start > getting RDoc serving Ruby API docs off of ruby-doc? --------- RDog. Not rdoc. (I need to pay closer attention when running the spell checker.) James From george.moschovitis at gmail.com Tue Jan 24 03:17:29 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 24 Jan 2006 10:17:29 +0200 Subject: [Nitro] BUG: undefined method 'index' for nil:NilClass In-Reply-To: <43D53317.2070403@gmail.com> References: <43D53317.2070403@gmail.com> Message-ID: Is allready fixed in the repo version, thanks though ;-) -g. On 1/23/06, Jonas Pfenniger wrote: > Nitro was trying to find the index of a non-existent parameter in the > query_string. > > It occured when I tried to use scaffold for example. It was pretty long > to find because that part is evaled. > > Follows the patch. > > > Cheers, > Jonas Pfenniger > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 24 03:18:09 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 24 Jan 2006 10:18:09 +0200 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules In-Reply-To: <43D54120.5040900@gmail.com> References: <43C67C09.7060208@gmail.com> <43D54120.5040900@gmail.com> Message-ID: I thought I have *fixed* it... have you tried it before submitting this patch? -g. On 1/23/06, Jonas Pfenniger wrote: > Hi George, > > I created a small patch for this. It's not quite it. I have redefined > String.underscore to escape :: to _ . It's a bit ugly but it works. > > George Moschovitis wrote: > > >Zimb, > > > >ok will check this! > > > >-g. > > > >On 1/12/06, Jonas Pfenniger wrote: > > > > > >>module Test > >> class Item > >> property :name > >> end > >>end > >> > >>Og creates an ogtest_item table which contains the items. > >> > >>When trying to access it in the AdminController, it generates a link > >>called http://localhost:9999/admin/test::item/list which doesn't exist. > >> > >>It would be nice to have a link like > >>http://localhost:9999/admin/test/item/list instead. I wish I could do > >>this, but Nitro has too much magic that I don't understand. > >> > >> > >>Cheers, > >> zimba > >>_______________________________________________ > >>Nitro-general mailing list > >>Nitro-general at rubyforge.org > >>http://rubyforge.org/mailman/listinfo/nitro-general > >> > >> > >> > > > > > >-- > >http://www.gmosx.com > >http://www.navel.gr > >http://www.nitrohq.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 > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 24 03:19:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 24 Jan 2006 10:19:34 +0200 Subject: [Nitro] PATCH: bugfix_kirby_store In-Reply-To: References: Message-ID: thanks -g. On 1/24/06, Bryan Soto wrote: > Attached removes recno from properties. Makes Kirby store work again. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From m.fellinger at gmail.com Tue Jan 24 06:53:53 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Tue, 24 Jan 2006 20:53:53 +0900 Subject: [Nitro] How do I get started with RDog? In-Reply-To: <43D5D161.3060203@neurogami.com> References: <43D5D0BD.9000806@neurogami.com> <43D5D161.3060203@neurogami.com> Message-ID: <200601242053.53659.manveru@weez.co.jp> Ok, that's not easy to answer. First of all, rdog is quite experimental, and you might experience some problems, but i guess you're prepared for that after longer nitro-use :) Next: go to rubyforge and download rdog - i've written some basic instructions in the README - but i'm not sure it will work with 0.27 - my last upgrade was done before moving to japan... However, next thing - rdog needs a 'hacked' version of rdoc, that fills the database - you simple run it with rdoc-devel -f og rdoc-devel in this case is a link to the hacked rdoc, to avoid killing the original rdoc-functionality. also make sure to adjust your rdoc.rb to point to the correct database - after doing all that, you can use the model of rdog to query all the stuff :) I hope it doesn't turn out too difficult, but it has been much than that in the past ;) In case you need some help, don't hesitate to mail here... i know there is lot of stuff i still have to point out... also - this was one of my first ruby-programs - don't laugh about the code ^^ ~~~~manveru Am Tuesday 24 January 2006 16:04 schrieb James Britt: > James Britt wrote: > > My apologies if this is off-topic, but what do I need to do to start > > getting RDoc serving Ruby API docs off of ruby-doc? > > --------- RDog. Not rdoc. > > (I need to pay closer attention when running the spell checker.) > > > James > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nusgnaf at gmail.com Tue Jan 24 08:13:51 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Tue, 24 Jan 2006 08:13:51 -0500 Subject: [Nitro] Two liner patch for Spark 0.9 Message-ID: <716700c90601240513x353fd7eek4e4f08383b842945@mail.gmail.com> After the introduction of revisable mixin in Og, the revision class is autogenerated on revisable class as BaseClass::Revision, the attached patch make spark 0.9 to work with it. -------------- next part -------------- A non-text attachment was scrubbed... Name: revision.patch Type: application/octet-stream Size: 1529 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060124/c1e93330/attachment.obj From nusgnaf at gmail.com Tue Jan 24 08:18:32 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Tue, 24 Jan 2006 08:18:32 -0500 Subject: [Nitro] Two liner patch for Spark 0.9 In-Reply-To: <716700c90601240513x353fd7eek4e4f08383b842945@mail.gmail.com> References: <716700c90601240513x353fd7eek4e4f08383b842945@mail.gmail.com> Message-ID: <716700c90601240518u1a8c2e3fqb0fa54acf98d593e@mail.gmail.com> Sorry for the noise in the patch. Regenerated patch again the src/ subdirectory. -------------- next part -------------- A non-text attachment was scrubbed... Name: revision.patch Type: application/octet-stream Size: 880 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060124/d103cdb9/attachment.obj From james_b at neurogami.com Tue Jan 24 09:14:52 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 24 Jan 2006 07:14:52 -0700 Subject: [Nitro] How do I get started with RDog? In-Reply-To: <200601242053.53659.manveru@weez.co.jp> References: <43D5D0BD.9000806@neurogami.com> <43D5D161.3060203@neurogami.com> <200601242053.53659.manveru@weez.co.jp> Message-ID: <43D6365C.5030500@neurogami.com> Michael Fellinger wrote: > Ok, that's not easy to answer. > First of all, rdog is quite experimental, and you might experience some > problems, but i guess you're prepared for that after longer nitro-use :) Indeed! OK, I'll give this a shot ans let you know how it goes. Thanks, James > Next: go to rubyforge and download rdog - i've written some basic instructions > in the README - but i'm not sure it will work with 0.27 - my last upgrade was > done before moving to japan... > However, next thing - rdog needs a 'hacked' version of rdoc, that fills the > database - you simple run it with > rdoc-devel -f og > rdoc-devel in this case is a link to the hacked rdoc, to avoid killing the > original rdoc-functionality. > also make sure to adjust your rdoc.rb to point to the correct database - after > doing all that, you can use the model of rdog to query all the stuff :) > I hope it doesn't turn out too difficult, but it has been much than that in > the past ;) > In case you need some help, don't hesitate to mail here... i know there is lot > of stuff i still have to point out... > also - this was one of my first ruby-programs - don't laugh about the code ^^ > > ~~~~manveru > > > Am Tuesday 24 January 2006 16:04 schrieb James Britt: > >>James Britt wrote: >> >>>My apologies if this is off-topic, but what do I need to do to start >>>getting RDoc serving Ruby API docs off of ruby-doc? >> >>--------- RDog. Not rdoc. >> >>(I need to pay closer attention when running the spell checker.) >> >> >>James >>_______________________________________________ >>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 > -- James Britt "Blanket statements are over-rated" From zimba.tm at gmail.com Tue Jan 24 11:33:25 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 24 Jan 2006 17:33:25 +0100 Subject: [Nitro] [bug] AdminController doesn't support Og Entities in modules In-Reply-To: References: <43C67C09.7060208@gmail.com> <43D54120.5040900@gmail.com> Message-ID: <43D656D5.2020706@gmail.com> Yes, there was two problems. * In the scaffolding the methods for classes where generated without the module's name. So you could have name clashes. * In part admin the index page gives urls like /admin/modulename::classname(plural)/list My patch corrects all that but is not perfect. You can still have name clashes between Module::Class and ModuleClass because :: should be translated to __ (double underscore) in the action and / in the url. George Moschovitis wrote: >I thought I have *fixed* it... have you tried it before submitting this patch? > >-g. > >On 1/23/06, Jonas Pfenniger wrote: > > >>Hi George, >> >>I created a small patch for this. It's not quite it. I have redefined >>String.underscore to escape :: to _ . It's a bit ugly but it works. >> >>George Moschovitis wrote: >> >> >> >>>Zimb, >>> >>>ok will check this! >>> >>>-g. >>> >>>On 1/12/06, Jonas Pfenniger wrote: >>> >>> >>> >>> >>>>module Test >>>> class Item >>>> property :name >>>> end >>>>end >>>> >>>>Og creates an ogtest_item table which contains the items. >>>> >>>>When trying to access it in the AdminController, it generates a link >>>>called http://localhost:9999/admin/test::item/list which doesn't exist. >>>> >>>>It would be nice to have a link like >>>>http://localhost:9999/admin/test/item/list instead. I wish I could do >>>>this, but Nitro has too much magic that I don't understand. >>>> >>>> >>>>Cheers, >>>> zimba >>>>_______________________________________________ >>>>Nitro-general mailing list >>>>Nitro-general at rubyforge.org >>>>http://rubyforge.org/mailman/listinfo/nitro-general >>>> >>>> >>>> >>>> >>>> >>>-- >>>http://www.gmosx.com >>>http://www.navel.gr >>>http://www.nitrohq.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 >> >> >> >> >> > > >-- >http://www.gmosx.com >http://www.navel.gr >http://www.nitrohq.com > >_______________________________________________ >Nitro-general mailing list >Nitro-general at rubyforge.org >http://rubyforge.org/mailman/listinfo/nitro-general > > > From bryan.a.soto at gmail.com Wed Jan 25 02:32:55 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 24 Jan 2006 23:32:55 -0800 Subject: [Nitro] PATCH: Og Testsuite, Kirby store fixes Message-ID: Hey list, Apologies for the long post, but if you use multiple stores in your code, please check out the first item, if nothing else. Zip archive contains: * og_manager_fix: Adds checks so that Og managers don't try to enchant an already enchanted class. Regarding my earlier post (see http://rubyforge.org/pipermail/nitro-general/2006-January/002511.html where I reported that, due to multiple enchantments of a class, we were attempting to create a subclass with the same name as it's superclass, i.e. class Object < Object; end) , I decided that the real problem was that Og was managing classes that were being managed already and so, added this check. This does change Og's behaviour, but I'm not sure if this is something people would even notice. So, if anyone uses multiple stores in your code, you might want to test this and give some feedback. All I can say is, it worked with the test suite. ;) ~~~~~ These fixes were implied by the tests. * glue_taggable_fix: Fixes taggable to account for modules when adding a tag. * legacy_fix Ensures the find_[all|by]_* methods work for legacy databases by retrieving the field name from the classes properties. ~~~~~ For testing purposes only. * og_test_config_fix Makes config responsible for setting up stores. Changes logger if debug is false so that logger doesn't dump to stdout. As a consequence of the above changes, you might need to ensure rubygems is required during test runs if you don't already. * og_test_suite_fix Changes the test suite to use global store configs $og1 and $og2 set up in CONFIG.rb. All test suites just call manage classes, which ignore's its arguments for some reason. Moves all class definitions to within the TestCase subclass definition to ensure that all managed classes have their own table. Various test case fixes, including: Changing module names from Og to Glue. tc_hierarchical tc_optimistic_locking tc_orderable Fixed some asserts to actually pass. tc_taggable tc_multi_validations Added a file multi_validations_model Commented out some tests that just don't work. tc_kirby tc_filesys * rakefile_fix Fixes include directories in test task. ~~~~~ Separately attached is: * og_store_kirby_fix Adds a couple of missing lines to eval_og_insert. ~~~~~ With all the above fixes applied to a clean repository, rake test runs and completes on Linux2.6 (x86) and WinXP using Mysql, Sqlite and Kirby. By default now, it will run silently. If you want the logger info to print to screen, simply change CONFIG.rb debug flag to true. My advice, is to leave $og2 set to Mysql or Postgres. One of the test cases needs to execute sql which doesn't seem to work with Sqlite, if I remember correctly. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060125/177e0fdf/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: og_tests_fixes.zip Type: application/zip Size: 28415 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060125/177e0fdf/attachment.zip -------------- next part -------------- A non-text attachment was scrubbed... Name: og_store_kirby_fix Type: application/octet-stream Size: 11706 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060125/177e0fdf/attachment.obj From chris at motionpath.com Wed Jan 25 06:06:44 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Wed, 25 Jan 2006 11:06:44 +0000 Subject: [Nitro] [PATCH] Small optimization for HasMany family of controls Message-ID: current implementation caused many repeated SQL SELECT/Lookup queries when only one was necessary. Very noticeable with complex models and many relations. Chris Farmiloe Design & Development. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060125/b70b62f3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hasmany.patch.gz Type: application/x-gzip Size: 13829 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060125/b70b62f3/attachment.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060125/b70b62f3/attachment-0001.html From rob at motionpath.com Wed Jan 25 12:04:34 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 25 Jan 2006 17:04:34 +0000 Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). In-Reply-To: <43D14E4A.4020401@neurogami.com> References: <43D14E4A.4020401@neurogami.com> Message-ID: <1138208674.20305.23.camel@robs-p4> I have also come across this problem because Nitro wrongly relies on Glue existing in Object's name space which was preventing me from using the ruby breakpoint debugger. I have made a patch that removes Nitro's reliance on having Glue included in the default name space (I think it is wrong that Glue does this by default but that's another matter). This patch is for use at your own risk and I'm sure there are a couple of minor problems with it but it should be eventually worked into Nitro IMHO. You will also need to set: $GLUE_DONT_INCLUDE = true Before loading Glue/Nitro. On Fri, 2006-01-20 at 13:55 -0700, James Britt wrote: > I'm trying to use Jim Wierich's XML Builder library in Nitro to create > atom and rss feeds. I cannot call "require 'builder'" without errors. > > This is with Nitro 0.27 on winxp with Ruby 1.8.2 > > rubygems automagically included by way of RUBYOPTS > > > If I run this bare script: > > require 'builder' > > It runs fine. > > But as soon as I add nitro to the mix, I get assorted errors > > This: > > require 'builder' > require 'nitro' > > > Gives this: > > C:\WINDOWS\system32\cmd.exe /c c:/ruby/bin/ruby build.rb > c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:90:in > `bind': singleton method called for a different object (TypeError) > from > c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:90:in > `method_added' > from > c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/basicobject.rb:89:in > `method_added' > from > c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/openobject.rb:56 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' > from > c:/ruby/lib/ruby/gems/1.8/gems/facets-2005.10.30/lib/mega/annotation.rb:53 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' > ... 6 levels... > from c:/ruby/lib/ruby/gems/1.8/gems/nitro-0.27.0/lib/nitro.rb:11 > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:25:in `require__' > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:25:in `require' > from build.rb:2 > shell returned 1 > > > > And this: > > require 'nitro' > require 'builder > > Gives this: > > C:\WINDOWS\system32\cmd.exe /c c:/ruby/bin/ruby build.rb > c:/ruby/lib/ruby/gems/1.8/gems/builder-1.2.4/lib/builder/blankslate.rb:11: > Builder is not a module (TypeError) > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require__' > from > c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:18:in `require' > from > c:/ruby/lib/ruby/gems/1.8/gems/builder-1.2.4/lib/builder/xmlbase.rb:3 > > > Are there special libraries that cannot be used wth Nitro? > > Is there a trick to including certain libraries? > > > > Thanks, > > > James > _______________________________________________ > 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: dont-rely-on-glue.patch.bz2 Type: application/x-bzip Size: 5978 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060125/54a495d7/attachment.bin From rob at motionpath.com Wed Jan 25 12:11:58 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 25 Jan 2006 17:11:58 +0000 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store Message-ID: <1138209119.20305.32.camel@robs-p4> Recently (I am not sure when) our programs were broken by a Glycerin patch (unfortunately I haven't been able to work out which) that caused Og.thread_safe to be true and for Og.manager.store to not exist. I notice there is some code in the adapters/fastcgi.rb that is supposed to turn this off but it never appears to run even though ENV["NITRO_INVOKE"]=>"fcgi_proc". The quick fix is to to put this line directly before Nitro.run in your projects: Og.thread_safe = false But that's hardly ideal. I spent most of the time I should have spent fixing this working out how to get an in-process irb shell within running fast-cgi processes so perhaps someone else can look at this (and find this helpful if they start experiencing this odd problem too). From bryan.a.soto at gmail.com Wed Jan 25 13:18:15 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 25 Jan 2006 10:18:15 -0800 Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). In-Reply-To: <1138208674.20305.23.camel@robs-p4> References: <43D14E4A.4020401@neurogami.com> <1138208674.20305.23.camel@robs-p4> Message-ID: On 1/25/06, Rob Pitt wrote: > > I have also come across this problem because Nitro wrongly relies on > Glue existing in Object's name space which was preventing me from using > the ruby breakpoint debugger. I have made a patch that removes Nitro's > reliance on having Glue included in the default name space (I think it > is wrong that Glue does this by default but that's another matter). > > This patch is for use at your own risk and I'm sure there are a couple > of minor problems with it but it should be eventually worked into Nitro > IMHO. > > Thank you for beating me to this. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060125/30e7a863/attachment.html From zimba.tm at gmail.com Wed Jan 25 16:58:57 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 25 Jan 2006 22:58:57 +0100 Subject: [Nitro] on_load in og ? Message-ID: <43D7F4A1.2020701@gmail.com> Hi list, does somebody know if Og calls a particular method when and object is loaded form the database ? Cheers, Jonas From bryan.a.soto at gmail.com Wed Jan 25 18:06:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 25 Jan 2006 15:06:00 -0800 Subject: [Nitro] on_load in og ? In-Reply-To: <43D7F4A1.2020701@gmail.com> References: <43D7F4A1.2020701@gmail.com> Message-ID: On 1/25/06, Jonas Pfenniger wrote: > > Hi list, > > does somebody know if Og calls a particular method when and object is > loaded form the database ? > > Perhaps og_read is what you're looking for? From og/lib/og/store/sql.rb # Compile the og_read method for the class. This method is # used to read (deserialize) the given class from the store. # In order to allow for changing field/attribute orders a # field mapping hash is used. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060125/b0f43684/attachment.html From bryan.a.soto at gmail.com Thu Jan 26 03:10:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 26 Jan 2006 00:10:09 -0800 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: <1138209119.20305.32.camel@robs-p4> References: <1138209119.20305.32.camel@robs-p4> Message-ID: Hi, On 1/25/06, Rob Pitt wrote: > > Recently (I am not sure when) our programs were broken by a Glycerin > patch (unfortunately I haven't been able to work out which) that caused > Og.thread_safe to be true and for Og.manager.store to not exist. It seems Og.thread_safe = true is the default now in og/lib/og.rb. Perusing bundles since late December doesn't show this changed. Nor anything really having to do with Og itself actually. And Og.manager.store looks as though it should work, even with a Pool. I don't suppose you have a backtrace or maybe could describe how things broke? I notice there is some code in the adapters/fastcgi.rb that is supposed > to turn this off but it never appears to run even though > ENV["NITRO_INVOKE"]=>"fcgi_proc". I don't think this would do anything since it's called through Nitro.runafter the pertinent code in Manager#initialize is run. The quick fix is to to put this line directly before Nitro.run in your > projects: > > Og.thread_safe = false I'm actually surprised that works. Looking at og/manager.rb initialize, it checks for the value of Og.thread_safe when creating the manager, typically when Og.setup is called. Or perhaps you don't structure your run.rb file the conventional way? But that's hardly ideal. I spent most of the time I should have spent > fixing this working out how to get an in-process irb shell within > running fast-cgi processes so perhaps someone else can look at this (and > find this helpful if they start experiencing this odd problem too). I ran into some odd threading issues while working on the test suite, but can't remember exactly what I did to cause them. The only line from the backtrace I remeber now was a call to synchronize, which is how I knew it was a threading issue. Is that what you're experiencing? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060126/865e906b/attachment.html From george.moschovitis at gmail.com Thu Jan 26 04:03:44 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 Jan 2006 11:03:44 +0200 Subject: [Nitro] How do I get started with RDog? In-Reply-To: <43D6365C.5030500@neurogami.com> References: <43D5D0BD.9000806@neurogami.com> <43D5D161.3060203@neurogami.com> <200601242053.53659.manveru@weez.co.jp> <43D6365C.5030500@neurogami.com> Message-ID: > > problems, but i guess you're prepared for that after longer nitro-use :) hmmm ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Jan 26 04:12:48 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 Jan 2006 11:12:48 +0200 Subject: [Nitro] PATCH: Og Testsuite, Kirby store fixes In-Reply-To: References: Message-ID: Thanks Bryan, you *rock* ! -g. On 1/25/06, Bryan Soto wrote: > Hey list, > > Apologies for the long post, but if you use multiple stores in your code, > please check out the first item, if nothing else. > > Zip archive contains: > > * og_manager_fix: > Adds checks so that Og managers don't try to enchant an already enchanted > class. > > Regarding my earlier post (see > http://rubyforge.org/pipermail/nitro-general/2006-January/002511.html > where I reported that, due to multiple enchantments of a class, we were > attempting to create a subclass with the same name as it's superclass, i.e. > class Object < Object; end) , I decided that the real problem was that Og > was managing classes that were being managed already and so, added this > check. > > This does change Og's behaviour, but I'm not sure if this is something > people would even notice. So, if anyone uses multiple stores in your code, > you might want to test this and give some feedback. All I can say is, it > worked with the test suite. ;) > > ~~~~~ > > These fixes were implied by the tests. > > * glue_taggable_fix: > Fixes taggable to account for modules when adding a tag. > > * legacy_fix > Ensures the find_[all|by]_* methods work for legacy databases by retrieving > the field name from the classes properties. > > ~~~~~ > > For testing purposes only. > > * og_test_config_fix > Makes config responsible for setting up stores. Changes logger if debug is > false so that logger doesn't dump to stdout. > As a consequence of the above changes, you might need to ensure rubygems is > required during test runs if you don't already. > > * og_test_suite_fix > Changes the test suite to use global store configs $og1 and $og2 set up in > CONFIG.rb. All test suites just call manage classes, which ignore's its > arguments for some reason. > > Moves all class definitions to within the TestCase subclass definition to > ensure that all managed classes have their own table. > > Various test case fixes, including: > Changing module names from Og to Glue. > tc_hierarchical > tc_optimistic_locking > tc_orderable > Fixed some asserts to actually pass. > tc_taggable > tc_multi_validations > Added a file > multi_validations_model > Commented out some tests that just don't work. > tc_kirby > tc_filesys > > * rakefile_fix > Fixes include directories in test task. > > ~~~~~ > > Separately attached is: > > * og_store_kirby_fix > Adds a couple of missing lines to eval_og_insert. > > ~~~~~ > > With all the above fixes applied to a clean repository, rake test runs and > completes on Linux2.6 (x86) and WinXP using Mysql, Sqlite and Kirby. By > default now, it will run silently. If you want the logger info to print to > screen, simply change CONFIG.rb debug flag to true. My advice, is to leave > $og2 set to Mysql or Postgres. One of the test cases needs to execute sql > which doesn't seem to work with Sqlite, if I remember correctly. > > bryan > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From chris at motionpath.com Thu Jan 26 04:15:39 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Thu, 26 Jan 2006 09:15:39 +0000 Subject: [Nitro] on_load in og ? In-Reply-To: References: <43D7F4A1.2020701@gmail.com> Message-ID: <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> yeah use a nice aspect in your model like pre :call_this, :on => :og_read def call_this # do some stuff @somevar = "this" end chrisfarms On 25 Jan 2006, at 23:06, Bryan Soto wrote: > On 1/25/06, Jonas Pfenniger wrote: > Hi list, > > does somebody know if Og calls a particular method when and object is > loaded form the database ? > > > Perhaps og_read is what you're looking for? > > From og/lib/og/store/sql.rb > > # Compile the og_read method for the class. This method is > # used to read (deserialize) the given class from the store. > # In order to allow for changing field/attribute orders a > # field mapping hash is used. > > bryan > _______________________________________________ > 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/20060126/3d79318b/attachment.html From george.moschovitis at gmail.com Thu Jan 26 04:23:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 Jan 2006 11:23:30 +0200 Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). In-Reply-To: <1138208674.20305.23.camel@robs-p4> References: <43D14E4A.4020401@neurogami.com> <1138208674.20305.23.camel@robs-p4> Message-ID: > the ruby breakpoint debugger. I have made a patch that removes Nitro's > reliance on having Glue included in the default name space (I think it > is wrong that Glue does this by default but that's another matter). hmm... I *really* like Glue included by default though :( But if everyone feels *stongly* about this, then ok we can remove this. For the moment I will not apply this patch, though. Let's think about this a little bit better please. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Jan 26 04:27:03 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 Jan 2006 11:27:03 +0200 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: References: <1138209119.20305.32.camel@robs-p4> Message-ID: I fixed some newly introduced Og/FCGI problems some days ago. Do you still see the problem in the latest glycerin version? -g. On 1/26/06, Bryan Soto wrote: > Hi, > > On 1/25/06, Rob Pitt wrote: > > Recently (I am not sure when) our programs were broken by a Glycerin > > patch (unfortunately I haven't been able to work out which) that caused > > Og.thread_safe to be true and for Og.manager.store to not exist. > > > It seems Og.thread_safe = true is the default now in og/lib/og.rb. Perusing > bundles since late December doesn't show this changed. Nor anything really > having to do with Og itself actually. And Og.manager.store looks as though > it should work, even with a Pool. I don't suppose you have a backtrace or > maybe could describe how things broke? > > > I notice there is some code in the adapters/fastcgi.rb that is supposed > > to turn this off but it never appears to run even though > > ENV["NITRO_INVOKE"]=>"fcgi_proc". > > I don't think this would do anything since it's called through Nitro.run > after the pertinent code in Manager#initialize is run. > > > > The quick fix is to to put this line directly before Nitro.run in your > > projects: > > > > Og.thread_safe = false > > I'm actually surprised that works. Looking at og/manager.rb initialize, it > checks for the value of Og.thread_safe when creating the manager, typically > when Og.setup is called. Or perhaps you don't structure your run.rb file the > conventional way? > > > But that's hardly ideal. I spent most of the time I should have spent > > fixing this working out how to get an in-process irb shell within > > running fast-cgi processes so perhaps someone else can look at this (and > > find this helpful if they start experiencing this odd problem too). > > > I ran into some odd threading issues while working on the test suite, but > can't remember exactly what I did to cause them. The only line from the > backtrace I remeber now was a call to synchronize, which is how I knew it > was a threading issue. Is that what you're experiencing? > > Bryan > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Jan 26 04:28:49 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 Jan 2006 11:28:49 +0200 Subject: [Nitro] on_load in og ? In-Reply-To: <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> References: <43D7F4A1.2020701@gmail.com> <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> Message-ID: > yeah use a nice aspect in your model like > > pre :call_this, :on => :og_read or before :call_this, :on => og_read or before 'my ruby code here', :on => og_read or before { my ruby code }, :on => og_read etc etc... > > def call_this > # do some stuff > @somevar = "this" > end > > > chrisfarms > > > > On 25 Jan 2006, at 23:06, Bryan Soto wrote: > > On 1/25/06, Jonas Pfenniger wrote: > > Hi list, > > > > does somebody know if Og calls a particular method when and object is > > loaded form the database ? > > > > > > Perhaps og_read is what you're looking for? > > From og/lib/og/store/sql.rb > > # Compile the og_read method for the class. This method is > # used to read (deserialize) the given class from the store. > # In order to allow for changing field/attribute orders a > # field mapping hash is used. > > bryan > _______________________________________________ > 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://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rob at motionpath.com Thu Jan 26 04:52:04 2006 From: rob at motionpath.com (Rob Pitt) Date: Thu, 26 Jan 2006 09:52:04 +0000 Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). In-Reply-To: References: <43D14E4A.4020401@neurogami.com> <1138208674.20305.23.camel@robs-p4> Message-ID: <1138269125.20305.46.camel@robs-p4> I don't feel strongly about the default inclusion behaviour. I do feel quite strongly that you should be able to disable it (which you can) and Nitro shouldn't rely on it happening (which it currently does) so that devs can set $GLUE_DONT_INCLUDE to true whilst using Nitro to use other libraries without having to re-write them. That patch shouldn't be applied as it is, I was not very careful making it (it was automated with a bunch of find/sed/grep commands and checked while doing darcs record) supposing I could fix problems that arose as they did. It was more for a talking point/start for someone else to clean up/aid to those in the same position as me. On Thu, 2006-01-26 at 11:23 +0200, George Moschovitis wrote: > > the ruby breakpoint debugger. I have made a patch that removes Nitro's > > reliance on having Glue included in the default name space (I think it > > is wrong that Glue does this by default but that's another matter). > > hmm... I *really* like Glue included by default though :( But if > everyone feels *stongly* about this, then ok we can remove this. For > the moment I will not apply this patch, though. Let's think about this > a little bit better please. > > regards, > George. > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Thu Jan 26 04:56:02 2006 From: rob at motionpath.com (Rob Pitt) Date: Thu, 26 Jan 2006 09:56:02 +0000 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: References: <1138209119.20305.32.camel@robs-p4> Message-ID: <1138269362.20305.51.camel@robs-p4> Og.manager.store returned nil causing lots of Og functions to stop working. Using irb from a separate thread in the same process revealed @store_class and @options were setup OK (and store really was nil). I could get a backtrace later, where do you want a backtrace from, from the part of the code that generates the connection pool? On Thu, 2006-01-26 at 00:10 -0800, Bryan Soto wrote: > Hi, > > On 1/25/06, Rob Pitt wrote: > Recently (I am not sure when) our programs were broken by a > Glycerin > patch (unfortunately I haven't been able to work out which) > that caused > Og.thread_safe to be true and for Og.manager.store to not > exist. > > It seems Og.thread_safe = true is the default now in og/lib/og.rb. > Perusing bundles since late December doesn't show this changed. Nor > anything really having to do with Og itself actually. And > Og.manager.store looks as though it should work, even with a Pool. I > don't suppose you have a backtrace or maybe could describe how things > broke? > From rob at motionpath.com Thu Jan 26 04:56:26 2006 From: rob at motionpath.com (Rob Pitt) Date: Thu, 26 Jan 2006 09:56:26 +0000 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: References: <1138209119.20305.32.camel@robs-p4> Message-ID: <1138269386.20305.52.camel@robs-p4> Yes including a pristine clean glycerin without any of our local modifications. On Thu, 2006-01-26 at 11:27 +0200, George Moschovitis wrote: > I fixed some newly introduced Og/FCGI problems some days ago. Do you > still see the problem > in the latest glycerin version? > > -g. From lasso at lassoweb.nu Thu Jan 26 11:39:15 2006 From: lasso at lassoweb.nu (Lars Olsson) Date: Thu, 26 Jan 2006 17:39:15 +0100 Subject: [Nitro] Og - Unexspected results when using two Sqlite3 stores Message-ID: <43D8FB33.9020906@lassoweb.nu> Cool. with your additions my code works just fine. I really don't understand WHY though. The thread_safe property doesn't seem to be documented anywhere and I don't quite understand why one has to use EntityMixin.insert instead of EntityMixin.save when "recycling" Og managed objects. Any pointers on where to find more documentation on this? Thanks for helping out! /Lars -- ________________________________________ Lars Olsson lasso at lassoweb.nu http://www.lassoweb.nu/ From transfire at gmail.com Thu Jan 26 12:30:20 2006 From: transfire at gmail.com (TRANS) Date: Thu, 26 Jan 2006 12:30:20 -0500 Subject: [Nitro] Re-doing parts of Nitro in C In-Reply-To: References: <1137751884.9014.43.camel@robs-p4> Message-ID: <4b6f054f0601260930w5b2d61f2i8b84454b0baf8d91@mail.gmail.com> Although I think it would be better to save this kind of optimization work for post 1.0 release. From bryan.a.soto at gmail.com Thu Jan 26 19:26:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 26 Jan 2006 16:26:42 -0800 Subject: [Nitro] Og - Unexspected results when using two Sqlite3 stores In-Reply-To: <43D8FB33.9020906@lassoweb.nu> References: <43D8FB33.9020906@lassoweb.nu> Message-ID: On 1/26/06, Lars Olsson wrote: > > Cool. with your additions my code works just fine. I really don't > understand WHY though. The thread_safe property doesn't seem to be > documented anywhere and I don't quite understand why one has to use > EntityMixin.insert instead of EntityMixin.save when "recycling" Og > managed objects. Any pointers on where to find more documentation on this? > > Thanks for helping out! > > /Lars > Hey Lars, Sorry to be so terse last time. I didn't want to leave you stuck, but didn't have time for a proper response. :) The Og.thread_safe (documented in og/lib/og.rb) basically controls whether or not a pool of db connections is made. Without it, your program errored out. The EntityMixin#insert portion, I agree with you with. I think it should have worked the way you coded it there as well. As for documentation, that's really a weak point around here. Currently, the best resources are the code itself, it's generated Rdoc and this list. Also, I might be wrong, but I'm not aware of anyone "recycling" Og managed objects like you are. So you might be pioneering new territory with all the inherent danger that implies. ;) At the very least, you've given us two bugs to work on. So, as I've a curious nature too, hopefully you won't mind me asking what exactly are you doing? :) Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060126/f2381c6e/attachment.html From bryan.a.soto at gmail.com Thu Jan 26 20:38:05 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 26 Jan 2006 17:38:05 -0800 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: <1138269362.20305.51.camel@robs-p4> References: <1138209119.20305.32.camel@robs-p4> <1138269362.20305.51.camel@robs-p4> Message-ID: On 1/26/06, Rob Pitt wrote: > > Og.manager.store returned nil causing lots of Og functions to stop > working. Using irb from a separate thread in the same process revealed > @store_class and @options were setup OK (and store really was nil). > > I could get a backtrace later, where do you want a backtrace from, from > the part of the code that generates the connection pool? > > I was just trying to understand what the problem was. I guess a backtrace wouldn't be useful if it's just no method errors. It looks like you could be getting nil as store if you're running a multi-threaded app running more than five threads. Specifically, the line in og/lib/manager.rb:83 st = @pool.pop() Array#pop, which Pool subclasses, returns nil from an empty array. If that's the case, it looks like you should set :connection_count (og/lib/og/manager.rb:66) in the Og.setup hash to something higher than 5 or add calls to Og::Manager#put_store from the thread when you're done with it. If that's not the case, then maybe you're running into errors connecting to your database? If you're not running a multi-threaded app, could you try disabling the auto-reload of files? That runs in a separate thread, and if you're reloading the file containing Og#setup, that might be what's taking all your pooled connections. George, should Og.thread_safe really default to true? Please note that in Manager#get_store, Thread.current is retrieved and a thread local variable, og_store, is set. In a single-threaded app, this would have the affect of only allowing a single connection for the entire app which is the problem Lars was running into in http://rubyforge.org/pipermail/nitro-general/2006-January/002568.html bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060126/92a0e669/attachment.html From m.fellinger at gmail.com Fri Jan 27 00:01:36 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Fri, 27 Jan 2006 14:01:36 +0900 Subject: [Nitro] schema_inheritance - the neverending story... Message-ID: <200601271401.36696.manveru@weez.co.jp> Hi list, hey george, We've found a problem/bug with schema_inheritance while upgrading from 0.25 to 0.27. Now, i don't really have an idea what exactly is going different now, but the main-problem seems to be that evolve_schema seems to cause problems. After a bit of playing around and trying to find out what is going wrong, we found that evolve_schema first drops the useless fields of the Class that will later be inherited - that looks like that: class Foo property :bar schema_inheritance end class Bar < Foo property :foo end class FooBar < Foo property :foobar end Og.setup(evolve_schema => true) produces a table that first looks like ogfoo |oid|bar| now the inheritance kicks in and it becomes ogfoo |oid|bar|foo|foobar|ogtype| but... the problem is that when you store data in there like: ogfoo |oid|foo|bar |foobar|ogtype| |0 |1 |NULL|NULL |foo | |1 |1 |1 |NULL |bar | |2 |1 |NULL|1 |foobar| it will be rebuilt on a restart, looking like that, at first: ogfoo |oid|foo|ogtype| |0 |1 |foo | |1 |1 |bar | |2 |1 |foobar| and after inheritance kicks in - evolves to: ogfoo |oid|foo|bar |foobar|ogtype| |0 |1 |NULL|NULL |foo | |1 |1 |NULL|NULL |bar | |2 |1 |NULL|NULL |foobar| so, we loose all our data of these two object-specific fields, wich is _very_ bad, and i'm glad i found that bug before we upgraded our main tree... However, i have no idea how to solve it... maybe some og-guru can help me out there. The store i'm using is psql - not yet tested with anything else because this is where our data is stored - so if psql doesn't work we hit a wall... Thx in prev, ~~~~manveru From bryan.a.soto at gmail.com Fri Jan 27 01:46:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 26 Jan 2006 22:46:51 -0800 Subject: [Nitro] schema_inheritance - the neverending story... In-Reply-To: <200601271401.36696.manveru@weez.co.jp> References: <200601271401.36696.manveru@weez.co.jp> Message-ID: On 1/26/06, Michael Fellinger wrote: > > Hi list, hey george, Hey manveru, how's Japan? :) We've found a problem/bug with schema_inheritance while upgrading from 0.25to > 0.27. > Now, i don't really have an idea what exactly is going different now, but > the > main-problem seems to be that evolve_schema seems to cause problems. > After a bit of playing around and trying to find out what is going wrong, > we > found that evolve_schema first drops the useless fields of the Class that > will later be inherited - that looks like that: I've attached a script to duplicate your problem. And a patch, which seems to make it do what you want. The store i'm using is psql - not yet tested with anything else because this > is where our data is stored - so if psql doesn't work we hit a wall... > > It would actually affect all of them as it's a bug in their super class. Oh, I'm on my WIndows box, so you might need to run dos2unix on the attached files. Hope I got it right. I've never used Single Table Inheritance before. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060127/543f3436/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: schema_inheritance.patch Type: text/x-patch Size: 430 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060127/543f3436/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: foo-test.rb Type: application/x-ruby Size: 400 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060127/543f3436/attachment-0001.bin From m.fellinger at gmail.com Fri Jan 27 03:03:14 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Fri, 27 Jan 2006 17:03:14 +0900 Subject: [Nitro] schema_inheritance - the neverending story... In-Reply-To: References: <200601271401.36696.manveru@weez.co.jp> Message-ID: <200601271703.15145.manveru@weez.co.jp> Hey Bryan, Thx a lot for the patch, will try it later... In every case we'll need the testcase for schema_inheritance, since it broke far too often in the past. You will hear from me how it works Am Friday 27 January 2006 15:46 schrieb Bryan Soto: > On 1/26/06, Michael Fellinger wrote: > > Hi list, hey george, > > Hey manveru, how's Japan? :) > > We've found a problem/bug with schema_inheritance while upgrading from > 0.25to > > > 0.27. > > Now, i don't really have an idea what exactly is going different now, but > > the > > main-problem seems to be that evolve_schema seems to cause problems. > > After a bit of playing around and trying to find out what is going wrong, > > we > > found that evolve_schema first drops the useless fields of the Class that > > will later be inherited - that looks like that: > > I've attached a script to duplicate your problem. And a patch, which seems > to make it do what you want. > > The store i'm using is psql - not yet tested with anything else because > this > > > is where our data is stored - so if psql doesn't work we hit a wall... > > It would actually affect all of them as it's a bug in their super class. > Oh, I'm on my WIndows box, so you might need to run dos2unix on the > attached files. Hope I got it right. I've never used Single Table > Inheritance before. > > > Bryan From george.moschovitis at gmail.com Fri Jan 27 04:13:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 27 Jan 2006 11:13:34 +0200 Subject: [Nitro] Scaffold patch Message-ID: Dear devs, I would like to ask the developer that added scaffold_all in the repo to contact me privately, as I have some problems with this patch. thanks in advance, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rob at motionpath.com Fri Jan 27 04:28:10 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 27 Jan 2006 09:28:10 +0000 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: References: <1138209119.20305.32.camel@robs-p4> <1138269362.20305.51.camel@robs-p4> Message-ID: <1138354090.2932.5.camel@robs-p4> There was no error connecting to the database (I used set_trace_proc to log exceptions while starting it up a couple of days ago). There were no files being reloaded. I see what you mean about popping from the array, I imagine it must be that for some reason other than their being a connection error none of the connections are ever opened. I will investigate this later... thanks. On Thu, 2006-01-26 at 17:38 -0800, Bryan Soto wrote: > On 1/26/06, Rob Pitt wrote: > Og.manager.store returned nil causing lots of Og functions to > stop > working. Using irb from a separate thread in the same process > revealed > @store_class and @options were setup OK (and store really was > nil). > > I could get a backtrace later, where do you want a backtrace > from, from > the part of the code that generates the connection pool? > > > I was just trying to understand what the problem was. I guess a > backtrace wouldn't be useful if it's just no method errors. > > It looks like you could be getting nil as store if you're running a > multi-threaded app running more than five threads. Specifically, the > line in og/lib/manager.rb:83 > > st = @pool.pop() > > Array#pop, which Pool subclasses, returns nil from an empty array. > > If that's the case, it looks like you should set :connection_count > (og/lib/og/manager.rb:66) in the Og.setup hash to something higher > than 5 or add calls to Og::Manager#put_store from the thread when > you're done with it. > > If that's not the case, then maybe you're running into errors > connecting to your database? If you're not running a multi-threaded > app, could you try disabling the auto-reload of files? That runs in a > separate thread, and if you're reloading the file containing Og#setup, > that might be what's taking all your pooled connections. > > George, should Og.thread_safe really default to true? Please note that > in Manager#get_store, Thread.current is retrieved and a thread local > variable, og_store, is set. In a single-threaded app, this would have > the affect of only allowing a single connection for the entire app > which is the problem Lars was running into in > > http://rubyforge.org/pipermail/nitro-general/2006-January/002568.html > > bryan > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Fri Jan 27 06:23:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 27 Jan 2006 13:23:18 +0200 Subject: [Nitro] Mongrel adapter for Nitro Message-ID: Dear devs, In case anyone has some free time this weekend here is a nice little project: write a Mongrel (Webrick alternative) adapter for Nitro. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From chris at motionpath.com Fri Jan 27 08:15:42 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Fri, 27 Jan 2006 13:15:42 +0000 Subject: [Nitro] [BUG] bryan's og_manager_fix Message-ID: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> Hi guys: Just pulled down latest bits from repo and found some trouble with the og_manager_fix that adds the Manager.managed? methods when combined with STI (may only show up with psql adaptor or others that enforce constraints. the following Nitro app should illustrate the problem (get your Cut&Paste on) --------------------------- #!/opt/local/bin/ruby require 'rubygems' require 'nitro' require 'og' include Nitro class Thing property :name end class ClassOne property :name, String end class ClassTwo < ClassOne property :this, String has_many :things, Thing end Og.setup ( :store => :psql, :address => 'xx', :name => 'xx', :user => 'xx', :password => 'xx', :destroy_tables => true, :evolve_schema => true, :evolve_schema_cautious => false ) # start nitro Nitro.run --------------------------------- First thought was that STI subentities were somehow inheriting managed? but this is NOT the case, dont have time to take a look at this right now, so shall just unpull my patch and report this. Chris Farmiloe Design & Development. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060127/806df2fd/attachment.html From rob at motionpath.com Fri Jan 27 09:26:52 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 27 Jan 2006 14:26:52 +0000 Subject: [Nitro] [PATCH] Stop autoreload missing files Message-ID: <1138372012.2932.24.camel@robs-p4> Autoreload missed files that were required with facet's require_local so I made this to fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: autoreload-fix.patch.bz2 Type: application/x-bzip Size: 4824 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060127/1bd16574/attachment.bin From rob at motionpath.com Fri Jan 27 09:36:06 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 27 Jan 2006 14:36:06 +0000 Subject: [Nitro] [PATCH] Entity copying methods Message-ID: <1138372566.2932.34.camel@robs-p4> I noticed a lot of people asked for this in the past and today I too needed it so I made these set of patches (which probably need refactoring but are working). Adds a .og_clone method to every entity which passes any arguments you supply onto the .new constructor when making the cloned object. The cloned object contains copies of all properties and all relations except HasMany which is impossible to copy as it involves modifying other objects BelongsTo relation, breaking the original relationship. BelongsTo/RefersTo etc (the inferior half of the relationship) will all copy ok, as will joins. Added the following methods onto Og::Entity to support the clone function (could be called directly too if you needed more selective usage): def copy_properties(source,destination,ignore = [],use_setter_method = false) Takes a source object (model instance/record), a destination, an array of property symbols to ignore. Copies properties from source to destination. Use_setter_method can be either false (in which case the copy is done by setting destinations class variables) or true (in which case it's done by using property= setter methods). def copy_inferior_relations(source,destination,ignore = []) As above but copies refers_to, belongs_to and has_one relationships instead of properties. def copy_equal_relations(source,destination,ignore = []) As above but copies joins_many and many_to_many relationships. def copy_relations(source,destination,ignore = []) Calls the previous two methods. def clone(source,*args) Makes a new object by calling source.class.new(*args) and calling the copy_properties and copy_relations on it. Returns the new object (saved, because you must save for join table copying to work). None of the other methods save. -------------- next part -------------- A non-text attachment was scrubbed... Name: entity_copying_methods.patch.bz2 Type: application/x-bzip Size: 5598 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060127/9e6827b2/attachment.bin From george.moschovitis at gmail.com Fri Jan 27 09:52:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 27 Jan 2006 16:52:07 +0200 Subject: [Nitro] Repo Message-ID: Dear devs, as I am making consideralble changes to convert to facets 1.0.1 and I have to work with Trans to fix some problems I will not update the repo for the following days. Please continue sending me patches, I will add them to my local version and upload everything on Monday (or something) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From vseguip at gmail.com Fri Jan 27 10:58:01 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Fri, 27 Jan 2006 16:58:01 +0100 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: <1138372566.2932.34.camel@robs-p4> References: <1138372566.2932.34.camel@robs-p4> Message-ID: Hi Robb, I was one of the requesters so thanks for your work! Some comments follow. > Adds a .og_clone method to every entity which passes any arguments you > supply onto the .new constructor when making the cloned object. > > The cloned object contains copies of all properties and all relations > except HasMany which is impossible to copy as it involves modifying > other objects BelongsTo relation, breaking the original relationship. > Wouldn't it be possible to recursively copy/clone the weak entity (optionally)? That would make this patch perfect for my needs. > BelongsTo/RefersTo etc (the inferior half of the relationship) will all > copy ok, as will joins. Do joins made through another Class also copy the join data? For example class A joins_many B, :through =>C end class B joins_many A, :through =>C end class C end Will this also copy the join data contained in C? A lot of thanks for your work Rob! Cheers, V. Segui From vseguip at gmail.com Fri Jan 27 11:25:56 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Fri, 27 Jan 2006 17:25:56 +0100 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: References: <1138372566.2932.34.camel@robs-p4> Message-ID: Asnwering myself, > Wouldn't it be possible to recursively copy/clone the weak entity > (optionally)? That would make this patch perfect for my needs. > As the patch says this is probably unnecessary, just use a joins_many. Cheers, V.Segu? From rob at motionpath.com Fri Jan 27 11:45:14 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 27 Jan 2006 16:45:14 +0000 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: References: <1138372566.2932.34.camel@robs-p4> Message-ID: <1138380314.2932.40.camel@robs-p4> On Fri, 2006-01-27 at 16:58 +0100, vseguip at gmail.com wrote: > Hi Robb, > I was one of the requesters so thanks for your work! Some comments follow. > > > > Adds a .og_clone method to every entity which passes any arguments you > > supply onto the .new constructor when making the cloned object. > > > > The cloned object contains copies of all properties and all relations > > except HasMany which is impossible to copy as it involves modifying > > other objects BelongsTo relation, breaking the original relationship. > > > Wouldn't it be possible to recursively copy/clone the weak entity > (optionally)? That would make this patch perfect for my needs. I see you changed your mind after reading my code comments but it would be a small change to make this happen and I will do it on Monday. > > > BelongsTo/RefersTo etc (the inferior half of the relationship) will all > > copy ok, as will joins. > > Do joins made through another Class also copy the join data? For example > > class A > joins_many B, :through =>C > end > > class B > joins_many A, :through =>C > end > > class C > end > > Will this also copy the join data contained in C? No I was not aware this even existed, I will look at changing it when I make the other modification. > > A lot of thanks for your work Rob! > > Cheers, > V. Segui > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Fri Jan 27 15:40:23 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 27 Jan 2006 12:40:23 -0800 Subject: [Nitro] [BUG] bryan's og_manager_fix In-Reply-To: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> References: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> Message-ID: Hi Chris, On 1/27/06, Chris Farmiloe wrote: > > > Hi guys: > > Just pulled down latest bits from repo and found some trouble with the > og_manager_fix that adds the Manager.managed? methods when combined with > STI (may only show up with psql adaptor or others that enforce > constraints. > > the following Nitro app should illustrate the problem (get your Cut&Paste > on) > > --------------------------- > #!/opt/local/bin/ruby > > require 'rubygems' > > require 'nitro' > require 'og' > include Nitro > > > > class Thing > property :name > belongs_two :ClassTwo # Add this here otherwise the join table won't be created. end > > > > class ClassOne > property :name, String > end > > class ClassTwo < ClassOne > property :this, String > has_many :things, Thing > end > > Og.setup ( > :store => :psql, > :address => 'xx', > :name => 'xx', > :user => 'xx', > :password => 'xx', > :destroy_tables => true, > :evolve_schema => true, > :evolve_schema_cautious => false > ) > > # start nitro > > Nitro.run > --------------------------------- > I finally caved and installed Postgres. I, [2006-01-27T12:38:38.161476 #11080] INFO -- : Og uses the Psql store. D, [2006-01-27T12:38:38.397137 #11080] DEBUG -- : Dropped database table ogclassone D, [2006-01-27T12:38:38.434824 #11080] DEBUG -- : Dropped database table ogthing D, [2006-01-27T12:38:38.458815 #11080] DEBUG -- : Dropped database table ogclasstwo D, [2006-01-27T12:38:38.502542 #11080] DEBUG -- : Og manageable classes: [ClassTwo, ClassOne, Thing] NOTICE: CREATE TABLE will create implicit sequence "ogclassone_oid_seq" for serial column "ogclassone.oid" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ogclassone_pkey" for table "ogclassone" I, [2006-01-27T12:38:38.691184 #11080] INFO -- : Created table 'ogclassone'. NOTICE: CREATE TABLE will create implicit sequence "ogclasstwo_oid_seq" for serial column "ogclasstwo.oid" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ogclasstwo_pkey" for table "ogclasstwo" I, [2006-01-27T12:38:38.773345 #11080] INFO -- : Created table 'ogclasstwo'. NOTICE: CREATE TABLE will create implicit sequence "ogthing_oid_seq" for serial column "ogthing.oid" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "ogthing_pkey" for table "ogthing" I, [2006-01-27T12:38:38.889331 #11080] INFO -- : Created table 'ogthing'. D, [2006-01-27T12:38:38.897719 #11080] DEBUG -- : PostgreSQL processing foreign key constraints D, [2006-01-27T12:38:38.982985 #11080] DEBUG -- : PostgreSQL finished setting constraints. 1 constraints were added in 0.08 seconds. My patch is innocent. ;) bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060127/168aabd4/attachment.html From bryan.a.soto at gmail.com Fri Jan 27 15:57:22 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 27 Jan 2006 12:57:22 -0800 Subject: [Nitro] [BUG] bryan's og_manager_fix In-Reply-To: References: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> Message-ID: Just to be sure, this is the error you were getting, right? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D, [2006-01-27T12:55:18.445983 #11232] DEBUG -- : PostgreSQL processing foreign key constraints E, [2006-01-27T12:55:18.447358 #11232] ERROR -- : PostgreSQL connection returned an error for query ALTER TABLE ogthing ADD CONSTRAINT ogc_ogthing_class_two_oid FOREIGN KEY (class_two_oid) REFERENCES ogclasstwo(oid) ON UPDATE SET NULL ON DELETE SET NULL E, [2006-01-27T12:55:18.447539 #11232] ERROR -- : Og.setup had problems: PGError => ERROR: column "class_two_oid" referenced in foreign key constraint does not exist E, [2006-01-27T12:55:18.447618 #11232] ERROR -- : # E, [2006-01-27T12:55:18.447682 #11232] ERROR -- : ./og/lib/og/store/psql.rb:522:in `exec' ./og/lib/og/store/psql.rb:522:in `create_constraints' ./og/lib/og/store/psql.rb:519:in `create_constraints' ./og/lib/og/store/psql.rb:593:in `post_setup' ./og/lib/og/manager.rb:226:in `post_setup' ./og/lib/og.rb:129:in `setup' chris-test.rb:23 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060127/baaa1d04/attachment.html From george.moschovitis at gmail.com Sat Jan 28 05:36:00 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 28 Jan 2006 12:36:00 +0200 Subject: [Nitro] Glycerin (more dangerous) Message-ID: Dear devs, I just pushed some dangerous stuff in the repository (facets 1.0.1). Don't use in production applications. However, please pull the repo in a separate directory and give me comments abou the new generalized caching infrastructure (still under heavy development). In order to run the code you need: facets 1.0.1 replace the facet version of paramix.rb with paramx_fixed.rb you can find in the root dir. Again, do NOT pull this code to use in production applications. Hopefully, the code will be cleaned on Monday (with Trans help). regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From nitro at tap.homeip.net Sat Jan 28 12:21:12 2006 From: nitro at tap.homeip.net (Joshua Hoke) Date: Sat, 28 Jan 2006 12:21:12 -0500 Subject: [Nitro] [PATCH?] Mongrel adapter for Nitro In-Reply-To: References: Message-ID: <20060128172112.GA683@blah> On Fri, Jan 27, 2006 at 01:23:18PM +0200, George Moschovitis wrote: > In case anyone has some free time this weekend here is a nice little project: > > write a Mongrel (Webrick alternative) adapter for Nitro. Here is my rather simple attempt. It handles at least /index.xhtml and /test.txt (in the public/ directory), I didn't test it with anything more complex. I'm sure it would need more work to support a sophisticated application but I don't really have any of those lying around to test. :) I based it heavily off the webrick adapter under Nitro 0.26.0. Joshua Hoke -------------- next part -------------- require 'mongrel' require 'stringio' require 'glue/flexob' require 'nitro/cgi' require 'nitro/context' require 'nitro/dispatcher' # Speeds things up, more comaptible with OSX. Socket.do_not_reverse_lookup = true module Mongrel class HttpRequest def method_missing(name, *args) if @params.has_key?(name.to_s.upcase) return @params[name.to_s.upcase] elsif name.to_s =~ /\A(.*)=\Z/ && @params.has_key?($1.upcase) @params[$1.upcase] = args[0] else super end end end end module Nitro class Mongrel class << self attr_accessor :mongrel # Start the Webrick adapter. def start(server) # TODO add logging. mongrel_options = server.options.dup mongrel_options.update( :BindAddress => server.address, :Port => server.port, :DocumentRoot => server.public_root ) @mongrel = ::Mongrel::HttpServer.new(mongrel_options[:BindAddress], mongrel_options[:Port]) trap('INT') { stop } # will this work? @mongrel.register('/', MongrelAdapter.new(server)) initialize_mongrel(server) @mongrel_thread = @mongrel.run @mongrel_thread.join end # Stop the Mongrel adapter. def stop @mongrel_thread.kill end # Override this method to perform customized mongrel # initialization. def initialize_mongrel(server) end end end # A special handler for Xhtml files. #class XhtmlFileHandler < WEBrick::HTTPServlet::DefaultFileHandler # def do_GET(req, res) # res['content-type'] = 'text/html' # res.body = 'Permission denied' # end #end # A Mongrel Adapter for Nitro. class MongrelAdapter < ::Mongrel::HttpHandler attr_accessor :server STATUS_CODES = {200 => "OK", "304" => "Not Modified", "404" => "Not found", "500" => "Server Error"} def initialize(server) @server = server end def process(req, res) handle(req, res) end # Handle a static file. Also handles cached pages. def handle_file(req, res) begin rewrite(req) # TODO handle If-Modified-Since and add Last-Modified headers filename = [@server.public_root, req.path_info].join("/") File.open(filename, "r") { |f| # TODO look up mime type # TODO check whether path circumvents public_root directory? size = File.size(filename) res.socket << "HTTP/1.1 200 OK\r\n" res.socket << "Content-type: text/plain\r\n" res.socket << "Content-length: #{size}\r\n" res.socket << "\r\n" res.socket << f.read # XXX inefficient for large files, may cause leaks } return true rescue Object => ex return false ensure unrewrite(req) end end # Handle the request. def handle(req, res) unless handle_file(req, res) path = req.script_name unless path =~ /\./ begin context = Context.new(@server) context.in = StringIO.new(req.body || "") context.headers = {} req.params.each { |h, v| if h =~ /\AHTTP_(.*)\Z/ context.headers[$1.gsub("_", "-")] = v end context.headers[h] = v } # context.headers.update(req.meta_vars) context.headers['REQUEST_URI'] = context.headers['SCRIPT_NAME'] context.headers['REQUEST_URI'] = '/' unless context.headers['REQUEST_URI'].length > 0 # gmosx: make compatible with fastcgi. #context.headers['REQUEST_URI'].slice!(/http:\/\/(.*?)\//) # context.headers['REQUEST_URI'] << '/' context.headers['REQUEST_URI'] = '/' + context.headers['REQUEST_URI'] Cgi.parse_params(context) Cgi.parse_cookies(context) context.render(path) res.socket << "HTTP/1.1 #{context.status.to_s} " if STATUS_CODES.has_key? context.status res.socket << STATUS_CODES[context.status] else res.socket << "Unknown Status Code" end res.socket << "\r\n" headers = context.response_headers headers["Content-length"] = context.out.size headers.each { |h,v| res.socket << "#{h}: #{v}\r\n" } res.socket << "\r\n" # TODO handle setting cookies res.socket << context.out context.close ensure Og.manager.put_store if defined?(Og) and Og.respond_to?(:manager) end end end end def rewrite(req) if req.path_info == '/' || req.path_info == '' req.path_info = '/index.html' elsif req.path_info =~ /^([^.]+)$/ req.path_info = '#{$1}/index.html' end end # Rewrite back to the original path. def unrewrite(req) if req.path_info == '/index.html' req.path_info = '/' elsif req.path_info =~ /^([^.]+)\/index.html$/ req.path_info = $1 end end end end # * George Moschovitis # * Guillaume Pierronnet # * Bryan Soto # * Joshua Hoke -------------- next part -------------- --- /usr/local/lib/ruby/gems/1.8/gems/nitro-0.26.0/lib/nitro/server/runner.rb 2006-01-28 10:52:40.000000000 -0500 +++ nitro/server/runner.rb 2006-01-28 11:31:59.000000000 -0500 @@ -144,6 +144,11 @@ @server = :cgi Logger.set(Logger.new('log/app.log')) end + + opts.on('-m', '--mongrel', 'Use the Mongrel Ruby server.') do + @server = :mongrel + # XXX handle logging + end opts.on('-C', '--console', 'Start a console attached to an instance of the application.') do if RUBY_PLATFORM =~ /mswin32/ @@ -296,6 +301,13 @@ puts "==> Press Ctrl-C to shutdown; Run with --help for options.\n\n" Webrick.start(server) + when :mongrel + require 'nitro/adapter/mongrel' + puts "==> Listening at #{server.address}:#{server.port}." + puts "==> Press Ctrl-C to shutdown; Run with --help for options.\n\n" + + Mongrel.start(server) + when :lhttpd require 'nitro/adapter/fastcgi' puts "==> Launching lighttpd (FastCGI)." From aidan at yoyo.org Sun Jan 29 06:28:17 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Sun, 29 Jan 2006 22:28:17 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: Bryan, Did you ever figure out why to_yaml was complaining? I still get this error, even with the latest version of the repository. Aidan On 20/01/2006, at 8:30 AM, Bryan Soto wrote: >> Strange bug part 2. >> >> Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in >> `to_yaml': can't dump anonymous class Class (TypeError) >> >> Anyone? :-) > > > You make me glad I think I've figured out why the Og unit tests > aren't running ;) Will, hopefully, follow up with a patch and/or > explanation today. > > bryan From aidan at yoyo.org Sun Jan 29 16:57:56 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 30 Jan 2006 08:57:56 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: In answer to my own question, I've figured this out. HasManyCollection has an instance variable @member_class which stores the Class of whatever this particular collection contains as members. to_yaml doesn't know how to dump a Class object, and so raises an exception. One possible solution to this is for Collection to overwrite the to_yaml method. Another possible solution is for Collection to store its member_class as a string, which, when used later, gets converted to the appropriate class type. I'm not sure which is the right approach to take, or whether there is a 3rd (better) approach. Any advice appreciated. This particular bug is a blocker for me, so I will fix it as soon as I get direction from the powers that be :-) Aidan On 29/01/2006, at 10:28 PM, Aidan Rogers wrote: > Bryan, > > Did you ever figure out why to_yaml was complaining? I still get > this error, even with the latest version of the repository. > > Aidan > > On 20/01/2006, at 8:30 AM, Bryan Soto wrote: > >>> Strange bug part 2. >>> >>> Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in >>> `to_yaml': can't dump anonymous class Class (TypeError) >>> >>> Anyone? :-) >> >> >> You make me glad I think I've figured out why the Og unit tests >> aren't running ;) Will, hopefully, follow up with a patch and/or >> explanation today. >> >> bryan > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From aidan at yoyo.org Sun Jan 29 18:13:31 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 30 Jan 2006 10:13:31 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: Message-ID: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> Eh, got fed up and went with option two - it was only a few lines of code in the end. I've submitted the patch using darcs, but I've blogged it for those who might need it. http://www.infurious.com/blogs/index.php/aidan/2006/01/29/ yaml_bug_in_og_0_27_0 Aidan On 30/01/2006, at 8:57 AM, Aidan Rogers wrote: > In answer to my own question, I've figured this out. > > HasManyCollection has an instance variable @member_class which stores > the Class of whatever this particular collection contains as > members. to_yaml doesn't know how to dump a Class object, and so > raises an exception. > > One possible solution to this is for Collection to overwrite the > to_yaml method. Another possible solution is for Collection to store > its member_class as a string, which, when used later, gets converted > to the appropriate class type. > > I'm not sure which is the right approach to take, or whether there is > a 3rd (better) approach. Any advice appreciated. This particular > bug is a blocker for me, so I will fix it as soon as I get direction > from the powers that be :-) > > Aidan > > On 29/01/2006, at 10:28 PM, Aidan Rogers wrote: > >> Bryan, >> >> Did you ever figure out why to_yaml was complaining? I still get >> this error, even with the latest version of the repository. >> >> Aidan >> >> On 20/01/2006, at 8:30 AM, Bryan Soto wrote: >> >>>> Strange bug part 2. >>>> >>>> Yaml complains with /usr/local/lib/ruby/1.8/yaml/rubytypes.rb:9:in >>>> `to_yaml': can't dump anonymous class Class (TypeError) >>>> >>>> Anyone? :-) >>> >>> >>> You make me glad I think I've figured out why the Og unit tests >>> aren't running ;) Will, hopefully, follow up with a patch and/or >>> explanation today. >>> >>> bryan >> >> _______________________________________________ >> 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 > From bryan.a.soto at gmail.com Mon Jan 30 00:30:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 29 Jan 2006 21:30:10 -0800 Subject: [Nitro] PATCH: Outstanding as of Jan. 30, 2006 Message-ID: In the hopes of keeping people aware, here is a summary of outstanding patches. Format is: patch name: * Short summary of thread where Pending means no comments. If you've applied and tested, please speak up :) link for download of patch from Rubyforge. Order is oldest to newest. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RELEASES rdoc fix: * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html Schema Inheritance * George is investigating. http://rubyforge.org/pipermail/nitro-general/2006-January/002424.html Nitro scgi support * Aleksi tested on Windows with success. http://rubyforge.org/pipermail/nitro-general/2006-January/002472.html (patch) http://rubyforge.org/pipermail/nitro-general/2006-January/002473.html (bundle) Nitro Testcases should require 'rubygems' * George asked for opinions on whether or not test cases should explicitly require rubygems. http://rubyforge.org/pipermail/nitro-general/2006-January/002517.html Nitro shouldn't pollute the name space with Glue. * George is requesting feedback. http://rubyforge.org/pipermail/nitro-general/2006-January/002594.html Entity copying methods * Submitted to fanfare and a threat of further enhancements. http://rubyforge.org/pipermail/nitro-general/2006-January/002609.html Mongrel adaptor * Submitted with a question mark. ;) http://rubyforge.org/pipermail/nitro-general/2006-January/002617.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/143674cf/attachment.html From bryan.a.soto at gmail.com Mon Jan 30 00:50:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 29 Jan 2006 21:50:21 -0800 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> Message-ID: Hi Aidan, You've been busy :) I don't know much about Yaml to be honest. So with this patch, does the collection actually get represented properly as a list or other collection? Although, I suppose I should just sit down and try it out. ;) Bryan On 1/29/06, Aidan Rogers wrote: > > Eh, got fed up and went with option two - it was only a few lines of > code in the end. I've submitted the patch using darcs, but I've > blogged it for those who might need it. > > http://www.infurious.com/blogs/index.php/aidan/2006/01/29/ > yaml_bug_in_og_0_27_0 > > Aidan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/d57b62c8/attachment.html From bryan.a.soto at gmail.com Mon Jan 30 00:53:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 29 Jan 2006 21:53:53 -0800 Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). In-Reply-To: <1138269125.20305.46.camel@robs-p4> References: <43D14E4A.4020401@neurogami.com> <1138208674.20305.23.camel@robs-p4> <1138269125.20305.46.camel@robs-p4> Message-ID: Okay, I too think you should be able to control it. I'll consider myself in the "someone else to clean up" category and thank you for the head start. :) On 1/26/06, Rob Pitt wrote: > > I don't feel strongly about the default inclusion behaviour. I do feel > quite strongly that you should be able to disable it (which you can) and > Nitro shouldn't rely on it happening (which it currently does) so that > devs can set $GLUE_DONT_INCLUDE to true whilst using Nitro to use other > libraries without having to re-write them. > > That patch shouldn't be applied as it is, I was not very careful making > it (it was automated with a bunch of find/sed/grep commands and checked > while doing darcs record) supposing I could fix problems that arose as > they did. It was more for a talking point/start for someone else to > clean up/aid to those in the same position as me. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/da8891d5/attachment.html From bryan.a.soto at gmail.com Mon Jan 30 01:35:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 29 Jan 2006 22:35:36 -0800 Subject: [Nitro] BUG: schema_inheritance - the neverending story... Message-ID: Hey George, The problem outlined by manveru is the same problem Aidan submitted a patch ( http://rubyforge.org/pipermail/nitro-general/2006-January/002424.html ) for and exists in glycerin currently. Basically, the problem is in og/lib/og/store/sql.rb, search for "def fields_for_class". During the check for schema inheritance, only the classes descendants are iterated over, not the full inheritance chain. This causes schema evolution to kick in with fields being dropped and added and data potentially being lost as manveru outlined. Aidan's patch is at available at http://rubyforge.org/pipermail/nitro-general/attachments/20060109/5f8a7531/og_schema_inheritance.obj Mine is at http://rubyforge.org/pipermail/nitro-general/attachments/20060126/543f3436/schema_inheritance.bin Unless we didn't stumble on the correct solution, perhaps one of these should be applied to glycerin? If so, let me know which and I'll submit the bundle. Thanks, bryan On 1/27/06, Michael Fellinger wrote: > > Hey Bryan, > > Thx a lot for the patch, will try it later... > In every case we'll need the testcase for schema_inheritance, since it > broke > far too often in the past. > > You will hear from me how it works > > Am Friday 27 January 2006 15:46 schrieb Bryan Soto: > > On 1/26/06, Michael Fellinger wrote: > > > Hi list, hey george, > > > > Hey manveru, how's Japan? :) > > > > We've found a problem/bug with schema_inheritance while upgrading from > > 0.25to > > > > > 0.27. > > > Now, i don't really have an idea what exactly is going different now, > but > > > the > > > main-problem seems to be that evolve_schema seems to cause problems. > > > After a bit of playing around and trying to find out what is going > wrong, > > > we > > > found that evolve_schema first drops the useless fields of the Class > that > > > will later be inherited - that looks like that: > > > > I've attached a script to duplicate your problem. And a patch, which > seems > > to make it do what you want. > > > > The store i'm using is psql - not yet tested with anything else because > > this > > > > > is where our data is stored - so if psql doesn't work we hit a wall... > > > > It would actually affect all of them as it's a bug in their super class. > > Oh, I'm on my WIndows box, so you might need to run dos2unix on the > > attached files. Hope I got it right. I've never used Single Table > > Inheritance before. > > > > > > Bryan > _______________________________________________ > 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/20060130/3e8f5635/attachment.html From aidan at yoyo.org Mon Jan 30 01:36:00 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 30 Jan 2006 17:36:00 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> Message-ID: <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> Hi Bryan, The collection has been and still is YAMLised as a Ruby object - that means I can serialise/de-serialise using YAML and the correct object type gets created. All that I've done is modify the member_class variable so that it YAMLises as a string. I've modified the behaviour of Og::Collection to understand that member_class is now initialised as a String as opposed to a Class. This does not change the behaviour of Og::Collection as far as Og is concerned (it's all encapsulated), but when YAML kicks in, it now works. Here's a pseudo- unit test (you'll need to ensure Foo and Bar are managed by Og). Note, I've not tested this verbatim :-) require 'og' class Foo property :foo_prop, String has_many :bars, Bar end class Bar property :bar_prop, String belongs_to :foo, Foo end bar = Bar.create foo = Foo.create foo.bars << bar assert_equal foo, YAML::load( foo.to_yaml ) This should barf. Apply my fix, it should work. Aidan On 30/01/2006, at 4:50 PM, Bryan Soto wrote: > Hi Aidan, > > You've been busy :) > > I don't know much about Yaml to be honest. So with this patch, does > the collection actually get represented properly as a list or other > collection? Although, I suppose I should just sit down and try it > out. ;) > > Bryan > > > On 1/29/06, Aidan Rogers wrote: Eh, got fed up and > went with option two - it was only a few lines of > code in the end. I've submitted the patch using darcs, but I've > blogged it for those who might need it. > > http://www.infurious.com/blogs/index.php/aidan/2006/01/29/ > yaml_bug_in_og_0_27_0 > From vseguip at gmail.com Mon Jan 30 05:31:27 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Mon, 30 Jan 2006 11:31:27 +0100 Subject: [Nitro] Camel Case does not work for join tables Message-ID: I attach a simple test case that demonstrates a bug when using camel case as class names in joins_many relationships. here is the output I get /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/errors.rb:94:in `check': table ogtc_join_articletocategory has no column named articlecamelcase_oid (SQLite3::SQLException) from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/statement.rb:70:in `initialize' from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:183:in `prepare' from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/database.rb:274:in `query' from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/lib/og/store/sqlite.rb:91:in `exec' from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/lib/og/store/sql.rb:487:in `join' from (eval):26:in `add_category' from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/lib/og/collection.rb:123:in `push' from test_join_psql.rb:55:in `test_all' ... 11 levels... from /usr/lib/ruby/1.8/test/unit/autorunner.rb:200:in `run' from /usr/lib/ruby/1.8/test/unit/autorunner.rb:13:in `run' from /usr/lib/ruby/1.8/test/unit.rb:285 from /usr/lib/ruby/1.8/test/unit.rb:283 -------------- next part -------------- A non-text attachment was scrubbed... Name: test_join_psql.rb Type: application/x-ruby Size: 1363 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060130/f585a7b5/attachment.bin From aidan at yoyo.org Mon Jan 30 06:01:19 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 30 Jan 2006 22:01:19 +1100 Subject: [Nitro] Camel Case does not work for join tables In-Reply-To: References: Message-ID: <801BECEF-CFB7-4702-8C96-64F15452A3EC@yoyo.org> Simple patch, as found by vseguip himself - he asked me to post as he was short of time. --- sql.rb 2006-01-30 21:54:55.000000000 +1100 +++ old.sql.rb 2006-01-30 21:59:59.000000000 +1100 @@ -156,7 +156,7 @@ def join_table_key(klass) klass = klass.schema_inheritance_root_class if klass.schema_inheritance_child? - "#{klass.to_s.split('::').last.underscore.downcase}_oid" + "#{klass.to_s.split('::').last.downcase}_oid" end def join_table_keys(class1, class2) Aidan On 30/01/2006, at 9:31 PM, wrote: > I attach a simple test case that demonstrates a bug when using camel > case as class names in joins_many relationships. > > > here is the output I get > > > > /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/sqlite3/ > errors.rb:94:in > `check': table ogtc_join_articletocategory has no column named > articlecamelcase_oid (SQLite3::SQLException) > from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/ > sqlite3/statement.rb:70:in > `initialize' > from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/ > sqlite3/database.rb:183:in > `prepare' > from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.1.0/lib/ > sqlite3/database.rb:274:in > `query' > from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/ > lib/og/store/sqlite.rb:91:in > `exec' > from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/ > lib/og/store/sql.rb:487:in > `join' > from (eval):26:in `add_category' > from /home/vseguip/Proyectos/og-clean/repo.nitrohq.com/og/ > lib/og/collection.rb:123:in > `push' > from test_join_psql.rb:55:in `test_all' > ... 11 levels... > from /usr/lib/ruby/1.8/test/unit/autorunner.rb:200:in `run' > from /usr/lib/ruby/1.8/test/unit/autorunner.rb:13:in `run' > from /usr/lib/ruby/1.8/test/unit.rb:285 > from /usr/lib/ruby/1.8/test/unit.rb:283 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From vseguip at gmail.com Mon Jan 30 06:02:19 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Mon, 30 Jan 2006 12:02:19 +0100 Subject: [Nitro] Camel Case does not work for join tables In-Reply-To: References: Message-ID: Prevoius testcase will fail regardless of the bug. Attach new test case. Cheers, V.segu? -------------- next part -------------- A non-text attachment was scrubbed... Name: test_join_psql.rb Type: application/x-ruby Size: 1373 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060130/3456ff1d/attachment.bin From george.moschovitis at gmail.com Mon Jan 30 06:08:54 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 30 Jan 2006 13:08:54 +0200 Subject: [Nitro] PATCH: Outstanding as of Jan. 30, 2006 In-Reply-To: References: Message-ID: Thanks Bryan, As I said on my blog (www.gmosx.com), I just got a new laptop, and I have not found the time to setup my deve environment. So I will go thorugh those patches a bit later ;-) regards, George. On 1/30/06, Bryan Soto wrote: > In the hopes of keeping people aware, here is a summary of outstanding > patches. Format is: > > patch name: > * Short summary of thread where Pending means no comments. If you've > applied and tested, please speak up :) > link for download of patch from Rubyforge. > > Order is oldest to newest. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~ > > RELEASES rdoc fix: > * Pending. > > http://rubyforge.org/pipermail/nitro-general/2006-January/002365.html > > > Schema Inheritance > * George is investigating. > > http://rubyforge.org/pipermail/nitro-general/2006-January/002424.html > > > Nitro scgi support > * Aleksi tested on Windows with success. > > http://rubyforge.org/pipermail/nitro-general/2006-January/002472.html > (patch) > http://rubyforge.org/pipermail/nitro-general/2006-January/002473.html > (bundle) > > > Nitro Testcases should require 'rubygems' > * George asked for opinions on whether or not test cases should explicitly > require rubygems. > > http://rubyforge.org/pipermail/nitro-general/2006-January/002517.html > > > Nitro shouldn't pollute the name space with Glue. > * George is requesting feedback. > http://rubyforge.org/pipermail/nitro-general/2006-January/002594.html > > > Entity copying methods > * Submitted to fanfare and a threat of further enhancements. > http://rubyforge.org/pipermail/nitro-general/2006-January/002609.html > > > Mongrel adaptor > * Submitted with a question mark. ;) > http://rubyforge.org/pipermail/nitro-general/2006-January/002617.html > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Jan 30 06:41:36 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 30 Jan 2006 13:41:36 +0200 Subject: [Nitro] Nitro Core Development team Message-ID: Dear devs, >From February 15th and for at least 1 month I will not be able to devote time on the Nitro project. However, as now there are quite a number of people using Nitro and/or Og, I am sure we can find an appropriate solution to keep this project alive. I am not sure which is the best way to proceed and I would certainly like to hear your opinion on this. In the meantime here are my thoughts: We could take advantage of this fact to stabilize the current version of Nitro and build a Core development team. After 0.28.0 gets released (about Feb 10th) and for about one month we should try to stabilize Nitro, fixing bugs and vastly improving the RDoc documentation. Perhaps creating some more screen casts and examples. We should setup a Core developer team of about 3 people to be responsible with the integration of patches and the release of this cleanup version (0.29.0). I would like to propose the MotionPath guys, Bryan Sotto and Guill for the Core development team. Perhaps the MotionPath guys could donate their darcs repository where the patches will be temporarily integrated. And once per week they could send a bigger patch bundle to drak at navel.gr where Tasos Koutoumanos (an associate) can grab it and apply it to the official repository for other people to grab. Alternatively, I would have to find a way to provide access to our server to the core team members. I would prefer the first solution though. As I said, I would like you opinion on all this. I really hope that everyone on this list agrees that Nitro is an important project, worth keeping alive. I trully believe that this is a great opportunity to stabilize the current code base AND build a more decentralized team of core developers. regards, George. PS: I *will* be back to continue improving Nitro and Og. There are sooo many things to add, the journay has just started! -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From chris at motionpath.com Mon Jan 30 07:40:31 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Mon, 30 Jan 2006 12:40:31 +0000 Subject: [Nitro] [BUG] bryan's og_manager_fix In-Reply-To: References: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> Message-ID: <293F6D58-3865-4E41-B75F-A36E1826FEC6@motionpath.com> Hiya Bryan: Sorry my quick example may have been a little slapdash. Here is a slightly neater version. the error is the postgres error: Og.setup had problems: RuntimeError => ERROR C42P01 Mrelation "ogclasstwo" does not existFnamespace.c L201 RRangeVarGetRelid ogclasstwo obveously shouldn't exist since it should be using table 'ogclassone' works without patch, not with. Thanx ? Chris Farmiloe Design & Development. On 27 Jan 2006, at 20:57, Bryan Soto wrote: > Just to be sure, this is the error you were getting, right? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > D, [2006-01-27T12:55:18.445983 #11232] DEBUG -- : PostgreSQL > processing foreign key constraints > E, [2006-01-27T12:55:18.447358 #11232] ERROR -- : PostgreSQL > connection returned an error for query ALTER TABLE ogthing ADD > CONSTRAINT ogc_ogthing_class_two_oid FOREIGN KEY (class_two_oid) > REFERENCES ogclasstwo(oid) ON UPDATE SET NULL ON DELETE SET NULL > E, [2006-01-27T12:55:18.447539 #11232] ERROR -- : Og.setup had > problems: PGError => ERROR: column "class_two_oid" referenced in > foreign key constraint does not exist > > E, [2006-01-27T12:55:18.447618 #11232] ERROR -- : # ERROR: column "class_two_oid" referenced in foreign key constraint > does not exist > > > E, [2006-01-27T12:55:18.447682 #11232] ERROR -- : ./og/lib/og/store/ > psql.rb:522:in `exec' > ./og/lib/og/store/psql.rb:522:in `create_constraints' > ./og/lib/og/store/psql.rb:519:in `create_constraints' > ./og/lib/og/store/psql.rb:593:in `post_setup' > ./og/lib/og/manager.rb:226:in `post_setup' > ./og/lib/og.rb:129:in `setup' > chris-test.rb:23 > > > _______________________________________________ > 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/20060130/e6b3dfed/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: sti_issue.rb.gz Type: application/x-gzip Size: 304 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060130/e6b3dfed/attachment.gz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/e6b3dfed/attachment-0001.html From rainhead at gmail.com Mon Jan 30 11:26:28 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Mon, 30 Jan 2006 10:26:28 -0600 Subject: [Nitro] Nitro Core Development team In-Reply-To: References: Message-ID: <542EF9E4-9037-46EB-B198-70970349C313@gmail.com> George, all, Though your presence will be sorely missed, I think that this will do a lot of good for the development of the project into a truly open project. Enjoy your time! Cheers, Peter On Jan 30, 2006, at 5:41 AM, George Moschovitis wrote: > Dear devs, > >> From February 15th and for at least 1 month I will not be able to > devote time on the Nitro project. However, as now there are quite a > number of people using Nitro and/or Og, I am sure we can find an > appropriate solution to keep this project alive. I am not sure which > is the best way to proceed and I would certainly like to hear your > opinion on this. In the meantime here are my thoughts: > > We could take advantage of this fact to stabilize the current version > of Nitro and build a Core development team. After 0.28.0 gets released > (about Feb 10th) and for about one month we should try to stabilize > Nitro, fixing bugs and vastly improving the RDoc documentation. > Perhaps creating some more screen casts and examples. We should setup > a Core developer team of about 3 people to be responsible with the > integration of patches and the release of this cleanup version > (0.29.0). > > I would like to propose the MotionPath guys, Bryan Sotto and Guill for > the Core development team. Perhaps the MotionPath guys could donate > their darcs repository where the patches will be temporarily > integrated. And once per week they could send a bigger patch bundle to > drak at navel.gr where Tasos Koutoumanos (an associate) can grab it and > apply it to the official repository for other people to grab. > Alternatively, I would have to find a way to provide access to our > server to the core team members. I would prefer the first solution > though. > > As I said, I would like you opinion on all this. I really hope that > everyone on this list agrees that Nitro is an important project, worth > keeping alive. I trully believe that this is a great opportunity to > stabilize the current code base AND build a more decentralized team of > core developers. > > regards, > George. > > > PS: I *will* be back to continue improving Nitro and Og. There are > sooo many things to add, the journay has just started! > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Mon Jan 30 12:02:03 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 30 Jan 2006 19:02:03 +0200 Subject: [Nitro] Nitro Core Development team In-Reply-To: <542EF9E4-9037-46EB-B198-70970349C313@gmail.com> References: <542EF9E4-9037-46EB-B198-70970349C313@gmail.com> Message-ID: > I think that this will do > a lot of good for the development of the project into a truly open > project. I think (and hope) so too ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Mon Jan 30 14:03:06 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 30 Jan 2006 11:03:06 -0800 Subject: [Nitro] PATCH: Outstanding as of Jan. 30, 2006 In-Reply-To: References: Message-ID: On 1/30/06, George Moschovitis wrote: > > Thanks Bryan, > > As I said on my blog (www.gmosx.com), I just got a new laptop, and I > have not found the time to setup my deve environment. So I will go What, no WinXP? ;) thorugh those patches a bit later ;-) > > Just trying to make sure they don't get lost and forgotten. No pressure. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/b3efffff/attachment.html From james_b at neurogami.com Mon Jan 30 15:09:05 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 30 Jan 2006 13:09:05 -0700 Subject: [Nitro] Nitro creating invalid XML Message-ID: <43DE7261.2@neurogami.com> The ruby-doc home page has this bit of XHTML: Thongs & boxers Raw ampersands are not allowed in XML, and so are disallowed in XHTML as well. Hence the use of the entity reference. But the rendered page gives me "Thongs & boxers", replacing the entity with the raw ampersand. This is a Bad Thing. I tried doubling up: "Thongs &amp; boxers" but something in the rendering code is far more clever than me, as it *still* emits the raw '&' How do I tell Nitro (which I gather is using REXML under the hood) to emit correct XML? This does not appear to be the default behavior of REXML, so I'm guessing that Nitro is telling the parser to do this. (I think in the meantime I'll be using 'and' in place of the nicer '&' ) Thanks -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Mon Jan 30 19:44:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 30 Jan 2006 16:44:25 -0800 Subject: [Nitro] [BUG] bryan's og_manager_fix In-Reply-To: <293F6D58-3865-4E41-B75F-A36E1826FEC6@motionpath.com> References: <16967460-490D-4B8E-B7CD-CA4FC6E82BDA@motionpath.com> <293F6D58-3865-4E41-B75F-A36E1826FEC6@motionpath.com> Message-ID: On 1/30/06, Chris Farmiloe wrote: > > > > Hiya Bryan: > > Sorry my quick example may have been a little slapdash. > > Here is a slightly neater version. the error is the postgres error: > > Og.setup had problems: RuntimeError => ERROR C42P01 Mrelation > "ogclasstwo" does not existFnamespace.c L201 RRangeVarGetRelid > > > ogclasstwo obveously shouldn't exist since it should be using table > 'ogclassone' > > works without patch, not with. > > Thanx > > Hi, I get it know; sorry for being dense. Problem is: # og/lib/og/entity.rb #-- # farms/rp: is there not another way to access the root class? #++ def schema_inheritance_root_class klass = self - until !Og.manager.manageable?(klass) or klass.schema_inheritance_root? + until klass.schema_inheritance_root? klass = klass.superclass end return klass end #manageable? was being used to find classes to manage. To prevent Og from managing already managed classes, I modified it to exclude classes already managed. Hence the problem. I made this change to accomodate multiple stores. The way Og worked, it tried to enchant everything it could, even if it was already managed. I'm thinking the above change should be fine. It passes your test anyway. ;) Seriously though, it doesn't appear to change a whole lot: $ grep -R schema_inheritance_root_class * | grep -v '~' | grep -v def og/store/sql.rb: klass = klass.schema_inheritance_root_class if klass.schema_inheritance_child? og/store/sql.rb: owner_class = owner_class.schema_inheritance_root_class if owner_class.schema_inheritance_child? og/store/sql.rb: target_class = target_class.schema_inheritance_root_class if target_class.schema_inheritance_child? og/store/sql.rb: klass.const_set 'OGTABLE', table( klass.schema_inheritance_root_class) og/store/psql.rb: klass.const_set 'OGSEQ', "#{table( klass.schema_inheritance_root_class)}_oid_seq" $ grep -R manageable? * | grep -v '~' | grep -v def og/manager.rb: manage(klass.superclass) if manageable?(klass.superclass) og/manager.rb: if manageable?(c) og/entity.rb: until !Og.manager.manageable?(klass) or klass.schema_inheritance_root? I note you and Rob are listed in the above code, so what do you two think? I'm new to STI and I've already broken it, so I'll humbly leave it to the two of you. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060130/af6b1548/attachment.html From george.moschovitis at gmail.com Tue Jan 31 05:47:52 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 31 Jan 2006 12:47:52 +0200 Subject: [Nitro] [PATCH?] Mongrel adapter for Nitro In-Reply-To: <20060128172112.GA683@blah> References: <20060128172112.GA683@blah> Message-ID: Thanks, will try this now. Hope it works with Mongrel 0.2.0 too... -g. On 1/28/06, Joshua Hoke wrote: > On Fri, Jan 27, 2006 at 01:23:18PM +0200, George Moschovitis wrote: > > In case anyone has some free time this weekend here is a nice little project: > > > > write a Mongrel (Webrick alternative) adapter for Nitro. > > Here is my rather simple attempt. It handles at least /index.xhtml > and /test.txt (in the public/ directory), I didn't test it with anything > more complex. I'm sure it would need more work to support a > sophisticated application but I don't really have any of those lying > around to test. :) > > I based it heavily off the webrick adapter under Nitro 0.26.0. > > Joshua Hoke > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Jan 31 07:22:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 31 Jan 2006 14:22:15 +0200 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> Message-ID: Hello Aidan, to_yaml is of course useful, but I dont like your solution much. Does anyone have a better idea? regards, George. > > require 'og' > > class Foo > property :foo_prop, String > has_many :bars, Bar > end > > class Bar > property :bar_prop, String > belongs_to :foo, Foo > end > > bar = Bar.create > foo = Foo.create > foo.bars << bar > assert_equal foo, YAML::load( foo.to_yaml ) > > This should barf. Apply my fix, it should work. > > Aidan > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From aidan at yoyo.org Tue Jan 31 07:40:45 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Tue, 31 Jan 2006 23:40:45 +1100 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> Message-ID: I don't like my solution much either, but I need working code :-) If someone can fix it more elegantly, please do. Aidan On 31/01/2006, at 11:22 PM, George Moschovitis wrote: > Hello Aidan, > > to_yaml is of course useful, but I dont like your solution much. Does > anyone have a better idea? From chris.burnley at gmail.com Tue Jan 31 08:41:28 2006 From: chris.burnley at gmail.com (Chris Burnley) Date: Tue, 31 Jan 2006 13:41:28 +0000 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> Message-ID: <76205f0b0601310541v2ca70b9dm58d9ebb2431b1564@mail.gmail.com> How about this : create an open class to define to_yaml on the member_class --- /usr/lib/ruby/gems/1.8/gems/og-0.27.0/lib/og/collection.rb 2006-01-31 13:32:18.000000000 +0000 +++ collection.rb 2006-01-31 13:36:35.000000000 +0000 @@ -56,11 +56,6 @@ count_proc = nil, find_options = {}) @owner = owner @member_class = member_class - class << @member_class - def to_yaml(arg) - to_s - end - end @insert_proc = insert_proc @remove_proc = remove_proc @find_proc = find_proc Chris On 1/31/06, Aidan Rogers wrote: > > I don't like my solution much either, but I need working code :-) If > someone can fix it more elegantly, please do. > > Aidan > > On 31/01/2006, at 11:22 PM, George Moschovitis wrote: > > > Hello Aidan, > > > > to_yaml is of course useful, but I dont like your solution much. Does > > anyone have a better idea? > > _______________________________________________ > 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/20060131/1590289a/attachment.html From chris.burnley at gmail.com Tue Jan 31 09:26:13 2006 From: chris.burnley at gmail.com (Chris Burnley) Date: Tue, 31 Jan 2006 14:26:13 +0000 Subject: [Nitro] Possible BUG in lib/og/relation/has_many.rb (and possible fix) In-Reply-To: <76205f0b0601310541v2ca70b9dm58d9ebb2431b1564@mail.gmail.com> References: <7C48C830-61B1-464B-802F-C1453D6788FE@yoyo.org> <0B0C5EE0-DBE8-4377-9DC7-3E1FD3880EAD@yoyo.org> <76205f0b0601310541v2ca70b9dm58d9ebb2431b1564@mail.gmail.com> Message-ID: <76205f0b0601310626s278febcg6cf9ef7e440df6ac@mail.gmail.com> oops, did the diff around the wrong way, but you get the picture ;) On 1/31/06, Chris Burnley wrote: > > How about this : create an open class to define to_yaml on the > member_class > > --- /usr/lib/ruby/gems/1.8/gems/og-0.27.0/lib/og/collection.rb > 2006-01-31 13:32:18.000000000 +0000 > +++ collection.rb 2006-01-31 13:36:35.000000000 +0000 > @@ -56,11 +56,6 @@ > count_proc = nil, find_options = {}) > @owner = owner > @member_class = member_class > - class << @member_class > - def to_yaml(arg) > - to_s > - end > - end > @insert_proc = insert_proc > @remove_proc = remove_proc > @find_proc = find_proc > > > > > Chris > > > On 1/31/06, Aidan Rogers wrote: > > > > I don't like my solution much either, but I need working code :-) If > > someone can fix it more elegantly, please do. > > > > Aidan > > > > On 31/01/2006, at 11:22 PM, George Moschovitis wrote: > > > > > Hello Aidan, > > > > > > to_yaml is of course useful, but I dont like your solution much. Does > > > anyone have a better idea? > > > > _______________________________________________ > > 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/20060131/6ba2bdd9/attachment.html From transfire at gmail.com Tue Jan 31 14:21:09 2006 From: transfire at gmail.com (TRANS) Date: Tue, 31 Jan 2006 14:21:09 -0500 Subject: [Nitro] Nitro Core Development team In-Reply-To: References: <542EF9E4-9037-46EB-B198-70970349C313@gmail.com> Message-ID: <4b6f054f0601311121k6b130eedn7114999ac74eb8a5@mail.gmail.com> Use the time to give some deeper considerations to the project. Probably a good thing to have a step back and look at the big picture. T. From bryan.a.soto at gmail.com Tue Jan 31 19:59:17 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 31 Jan 2006 16:59:17 -0800 Subject: [Nitro] [PATCH?] Mongrel adapter for Nitro In-Reply-To: References: <20060128172112.GA683@blah> Message-ID: Just tried with Mongrel 0.2.0 gem on Linux with Flare and it worked. I did notice that Firefox doesn't seem happy with css which seems to be sent as text/plain. MS's IE6 was a bit more accepting. Not sure if that would be a Mongrel "feature" or not though. On 1/31/06, George Moschovitis wrote: > > Thanks, > > will try this now. Hope it works with Mongrel 0.2.0 too... > > -g. > > On 1/28/06, Joshua Hoke wrote: > > On Fri, Jan 27, 2006 at 01:23:18PM +0200, George Moschovitis wrote: > > > In case anyone has some free time this weekend here is a nice little > project: > > > > > > write a Mongrel (Webrick alternative) adapter for Nitro. > > > > Here is my rather simple attempt. It handles at least /index.xhtml > > and /test.txt (in the public/ directory), I didn't test it with anything > > more complex. I'm sure it would need more work to support a > > sophisticated application but I don't really have any of those lying > > around to test. :) > > > > I based it heavily off the webrick adapter under Nitro 0.26.0. > > > > Joshua Hoke > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > 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/20060131/b0a1bc75/attachment.html From bryan.a.soto at gmail.com Tue Jan 31 20:36:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 31 Jan 2006 17:36:52 -0800 Subject: [Nitro] [PATCH?] Mongrel adapter for Nitro In-Reply-To: References: <20060128172112.GA683@blah> Message-ID: Works on WinXP too with some hoop-jumping. Mongrel fun though, not Nitro. On 1/31/06, Bryan Soto wrote: > > Just tried with Mongrel 0.2.0 gem on Linux with Flare and it worked. I did > notice that Firefox doesn't seem happy with css which seems to be sent as > text/plain. MS's IE6 was a bit more accepting. > > Not sure if that would be a Mongrel "feature" or not though. > > On 1/31/06, George Moschovitis < george.moschovitis at gmail.com> wrote: > > > > Thanks, > > > > will try this now. Hope it works with Mongrel 0.2.0 too... > > > > -g. > > > > On 1/28/06, Joshua Hoke wrote: > > > On Fri, Jan 27, 2006 at 01:23:18PM +0200, George Moschovitis wrote: > > > > In case anyone has some free time this weekend here is a nice little > > project: > > > > > > > > write a Mongrel (Webrick alternative) adapter for Nitro. > > > > > > Here is my rather simple attempt. It handles at least /index.xhtml > > > and /test.txt (in the public/ directory), I didn't test it with > > anything > > > more complex. I'm sure it would need more work to support a > > > sophisticated application but I don't really have any of those lying > > > around to test. :) > > > > > > I based it heavily off the webrick adapter under Nitro 0.26.0. > > > > > > Joshua Hoke > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > 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/20060131/c8b2ce3b/attachment.html From epiperak at softlab.ece.ntua.gr Tue Jan 31 20:55:47 2006 From: epiperak at softlab.ece.ntua.gr (Emmanuel Piperakis) Date: Wed, 1 Feb 2006 03:55:47 +0200 (EET) Subject: [Nitro] Nitro Core Development team In-Reply-To: References: Message-ID: > PS: I *will* be back to continue improving Nitro and Og. There are > sooo many things to add, the journay has just started! The journey has just begun for you my friend! For over the misty mountains cold To dungeons deep and caverns old, We must away ere break of day, To claim our long-forgotten Og. Emmanouil Piperakis (epiperak at cs.ntua.gr) {To explore is Human, to Create is Devine, To teach is Primal, to Rule is Sin}