From george.moschovitis at gmail.com Wed Feb 1 03:09:21 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 10:09:21 +0200 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. I have bug fixed some problems in the repo. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Feb 1 03:11:20 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 10:11:20 +0200 Subject: [Nitro] Nitro Core Development team In-Reply-To: <4b6f054f0601311121k6b130eedn7114999ac74eb8a5@mail.gmail.com> References: <542EF9E4-9037-46EB-B198-70970349C313@gmail.com> <4b6f054f0601311121k6b130eedn7114999ac74eb8a5@mail.gmail.com> Message-ID: > 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. Will do... In the meantime, what about rethiking your involvement in the Nitro project? I would *love* to see *you* on board ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Feb 1 04:16:13 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 11:16:13 +0200 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: <1138380314.2932.40.camel@robs-p4> References: <1138372566.2932.34.camel@robs-p4> <1138380314.2932.40.camel@robs-p4> Message-ID: Rob, if you have a new version of this patch please resend it, I would like to attempt to integrate this. thanks in advance, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From rob at motionpath.com Wed Feb 1 05:18:53 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 01 Feb 2006 10:18:53 +0000 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: References: <1138372566.2932.34.camel@robs-p4> <1138380314.2932.40.camel@robs-p4> Message-ID: <1138789134.4872.22.camel@robs-p4> Sorry I haven't had chance the office has been a bit of a war zone these past couple of days and I've had to focus on our core projects. The patch does work as is, the only thing it lacks is the cloning options I said I would provide and the ability to copy "join through" information (and still will do hopefully sometime this week). You can go ahead and integrate this the cloning option can wait until the next version. I also note you have contacted Chris in regards to us hosting a DARCS repository for Glycerin which we would be happy to do on one of our servers in Telehouse Docklands. When does this process need completion? On Wed, 2006-02-01 at 11:16 +0200, George Moschovitis wrote: > Rob, > > if you have a new version of this patch please resend it, I would > like to attempt to integrate this. > > thanks in advance, > 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 Feb 1 05:22:49 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 12:22:49 +0200 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: <1138789134.4872.22.camel@robs-p4> References: <1138372566.2932.34.camel@robs-p4> <1138380314.2932.40.camel@robs-p4> <1138789134.4872.22.camel@robs-p4> Message-ID: > I also note you have contacted Chris in regards to us hosting a DARCS > repository for Glycerin which we would be happy to do on one of our > servers in Telehouse Docklands. When does this process need completion? After Nitro 0.28.0 gets released (probably early next week). I will contact you to work out the details. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Feb 1 05:24:29 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 12:24:29 +0200 Subject: [Nitro] jsmin Message-ID: Dear devs, I would like to present a nice nitro - bounty: http://www.crockford.com/javascript/jsmin.html Is there any developer with some time to port the php version of this into a nice Nitro helper or compiler? regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Feb 1 06:05:54 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 13:05:54 +0200 Subject: [Nitro] [PATCH] Entity copying methods In-Reply-To: <1138789134.4872.22.camel@robs-p4> References: <1138372566.2932.34.camel@robs-p4> <1138380314.2932.40.camel@robs-p4> <1138789134.4872.22.camel@robs-p4> Message-ID: Rob, one other important thing. Please try to follow the coding conventiosn a bit closer. thanks in advance, -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Feb 1 06:18:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 13:18:28 +0200 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: <43DE7261.2@neurogami.com> References: <43DE7261.2@neurogami.com> Message-ID: > 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 dont think Nitro does this. This is possibly REXML's fault, but I will investigate this. Anyone can help here? -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From guillaume.pierronnet at gmail.com Wed Feb 1 10:23:51 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Wed, 1 Feb 2006 16:23:51 +0100 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: References: <43DE7261.2@neurogami.com> Message-ID: <6a7d49ca0602010723x64ac4805r@mail.gmail.com> I can investigate this. 2006/2/1, George Moschovitis : > > 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 dont think Nitro does this. This is possibly REXML's fault, but I > will investigate this. > Anyone can help here? > > -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 george.moschovitis at gmail.com Wed Feb 1 10:45:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 1 Feb 2006 17:45:07 +0200 Subject: [Nitro] My blog... Message-ID: Shameless plug: Check out my blog, I would like to see your comments to my ramblings ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Wed Feb 1 11:00:15 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 01 Feb 2006 09:00:15 -0700 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: References: <43DE7261.2@neurogami.com> Message-ID: <43E0DB0F.7040205@neurogami.com> George Moschovitis wrote: >>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 dont think Nitro does this. This is possibly REXML's fault, but I > will investigate this. Before posting, I tried a mall REXML app that simply read in and spit back some XML< and the ampersands were fine. I believe there is a way t tell REXML to not do certain character escaping (or to autoescape text when added) though, and perhaps there is something in Nitro doing this. > Anyone can help here? If no one knows offhand, I might be able to take a look. -- James Britt "Programs must be written for people to read, and only incidentally for machines to execute." - H. Abelson and G. Sussman (in "The Structure and Interpretation of Computer Programs) From bryan.a.soto at gmail.com Wed Feb 1 11:22:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 1 Feb 2006 08:22:47 -0800 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: <43E0DB0F.7040205@neurogami.com> References: <43DE7261.2@neurogami.com> <43E0DB0F.7040205@neurogami.com> Message-ID: On 2/1/06, James Britt wrote: > > George Moschovitis wrote: > >>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 dont think Nitro does this. This is possibly REXML's fault, but I > > will investigate this. > > Before posting, I tried a mall REXML app that simply read in and spit > back some XML< and the ampersands were fine. I believe there is a way t > tell REXML to not do certain character escaping (or to autoescape text > when added) though, and perhaps there is something in Nitro doing this. > > > Anyone can help here? > > If no one knows offhand, I might be able to take a look. Hi James, You can see what Nitro does if you look at nitro/lib/nitro/compiler/morphing.rb. Nitro calls REXML:: Document.parse_stream which converts the & to & and then calls the text callback, which simply adds it to the buffer. Perhaps we should be doing some entity escaping in the text callback? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060201/e0049cc7/attachment.html From james_b at neurogami.com Wed Feb 1 11:33:00 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 01 Feb 2006 09:33:00 -0700 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: References: <43DE7261.2@neurogami.com> <43E0DB0F.7040205@neurogami.com> Message-ID: <43E0E2BC.1070007@neurogami.com> Bryan Soto wrote: > Hi James, > > You can see what Nitro does if you look at > nitro/lib/nitro/compiler/morphing.rb. Nitro calls > REXML::Document.parse_stream which converts the & to & and then > calls the text callback, which simply adds it to the buffer. Perhaps we > should be doing some entity escaping in the text callback? Yes. '<' and '&' in plain text, where the ampersand is not part of some entity reference. -- James Britt "Blanket statements are over-rated" From bryan.a.soto at gmail.com Wed Feb 1 14:26:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 1 Feb 2006 11:26:58 -0800 Subject: [Nitro] FastCGI is broken because of Og.thread_safe not having an Og.manager.store In-Reply-To: <1138354090.2932.5.camel@robs-p4> References: <1138209119.20305.32.camel@robs-p4> <1138269362.20305.51.camel@robs-p4> <1138354090.2932.5.camel@robs-p4> Message-ID: dev-nitro/og/lib $ grep -R get_store * og/manager.rb: def get_store og/manager.rb: alias_method :store, :get_store og/manager.rb: alias_method :conn, :get_store dev-nitro/og/lib $ grep -R store * | more og/entity.rb: self.class.ogmanager.store.save(self, options) og/entity.rb: self.class.ogmanager.store.force_save(self, options) og/entity.rb: self.class.ogmanager.store.insert(self) og/entity.rb: self.class.ogmanager.store.update(self, options) og/entity.rb: self.class.ogmanager.store.update(self, :only => properties) og/entity.rb: self.class.ogmanager.store.update_by_sql(self, set) og/entity.rb: # Reload this entity instance from the store. og/entity.rb: self.class.ogmanager.store.reload(self, self.pk) og/entity.rb: # Delete this entity instance from the store. og/entity.rb: self.class.ogmanager.store.delete(self, self.class, cascade) og/entity.rb: self.class.ogmanager.store.transaction(&block) og/entity.rb: self.class.ogmanager.store.quote(obj) og/entity.rb: ogmanager.store.save(obj) og/entity.rb: ogmanager.store.save(obj) og/entity.rb: ogmanager.store.load(pk, self) og/entity.rb: # store. og/entity.rb: ogmanager.store.update_by_sql(self, set, options) og/entity.rb: # Unlike the lower level store.find method it accepts og/entity.rb: ogmanager.store.find(options) og/entity.rb: ogmanager.store.find_one(options) og/entity.rb: ogmanager.store.select(sql, self) og/entity.rb: ogmanager.store.select_one(sql, self) og/entity.rb: ogmanager.store.count(options) og/entity.rb: ogmanager.store.delete(obj_or_pk, self, cascade) og/entity.rb: ogmanager.store.delete_all(self) og/entity.rb: ogmanager.store.send :destroy, self og/entity.rb: ogmanager.store.escape(str) og/entity.rb: ogmanager.store.transaction(&block) og/entity.rb: # Return the store (connection) for this class. og/entity.rb: def ogstore og/entity.rb: ogmanager.store og/entity.rb: # on this managed class. The scope options are stored og/entity.rb: %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{ogmanager.store.quote(value)}| og/entity.rb: return ogmanager.store.send(finder, options) dev-nitro/og/lib $ grep -R put_store * og/manager.rb: def put_store og/manager.rb: store.enchant(klass, self); put_store It seems some more calls to #put_store are necessary or that #get_store should create more connections rather than return nil. In the meantime, Og.thread_safe should probably default to false. Bryan On 1/27/06, Rob Pitt wrote: > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060201/5039404c/attachment.html From bryan.a.soto at gmail.com Wed Feb 1 20:50:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 1 Feb 2006 17:50:36 -0800 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: <43E0E2BC.1070007@neurogami.com> References: <43DE7261.2@neurogami.com> <43E0DB0F.7040205@neurogami.com> <43E0E2BC.1070007@neurogami.com> Message-ID: On 2/1/06, James Britt wrote: > > Bryan Soto wrote: > > > Hi James, > > > > You can see what Nitro does if you look at > > nitro/lib/nitro/compiler/morphing.rb. Nitro calls > > REXML::Document.parse_stream which converts the & to & and then > > calls the text callback, which simply adds it to the buffer. Perhaps we > > should be doing some entity escaping in the text callback? > > Yes. '<' and '&' in plain text, where the ampersand is not part of > some entity reference. Hi James, Nitro apparently does handle this. In your .xhtml file, place "Thongs %amp; boxers". It will be converted to "Thongs & boxers" before it's sent to the browser. Hope that's acceptable. Bryan P.S. For the interested, it's located in glue/lib/glue/template.rb. Search for %nbsp. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060201/509255a5/attachment.html From bryan.a.soto at gmail.com Wed Feb 1 21:07:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 1 Feb 2006 18:07:46 -0800 Subject: [Nitro] [PATCH?] Mongrel adapter for Nitro In-Reply-To: References: <20060128172112.GA683@blah> Message-ID: On 2/1/06, George Moschovitis 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. > > > I have bug fixed some problems in the repo. > > -g. > Hey, This is running against glycerin with latest changes. I'll see if I can check it out tonight. Probably just needs to map content type to the file extension or something. Invasion is on out here though... ;) bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060201/7e01cd28/attachment.html From james_b at neurogami.com Wed Feb 1 21:46:06 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 01 Feb 2006 19:46:06 -0700 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: References: <43DE7261.2@neurogami.com> <43E0DB0F.7040205@neurogami.com> <43E0E2BC.1070007@neurogami.com> Message-ID: <43E1726E.1030507@neurogami.com> Bryan Soto wrote: > > Hi James, > > Nitro apparently does handle this. In your .xhtml file, place "Thongs > %amp; boxers". It will be converted to "Thongs & boxers" before it's > sent to the browser. !!! > > Hope that's acceptable. Hardly. It's a fugly hack. At some recent version, Nitro started to break if template files were not proper XML. Annoying in some ways (and a bad idea perhaps, as I would rather a production site render an invalid XHTML page than *no* page, at least until I fix it), but OK, I can live with it. Enforces good markup, etc. The least I would expect, then, is that I can actually provide Nitro a proper XML file and not have problems. If I'm working with XML then I want to use XML tools, and I want to be able to correctly validate my XML as XML. I don't want to have to learn some other almost-XML syntax. This also means that if I'm processing XML from other sources, it isn't enough for them to be merely valid; they need special-case Nitro-escaping as well. The real value of using XML is that is well-understood and saves people the repeated effort of inventing and dealing with one-off, ad-hoc markup for every application. I suppose this means I'll be looking through the source code ... -- 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 aidan at yoyo.org Wed Feb 1 19:44:52 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 2 Feb 2006 11:44:52 +1100 Subject: [Nitro] 1.0 (revisited) Message-ID: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> All, I think the Nitro community to date has been very focused on functionality and in getting stuff out there. This is why I've mentioned 1.0 in the past. For Nitro to become more mainstream, it needs a face lift. Compare http://www.nitrohq.com, http://www.rubyonrails.com, http:// www.djangoproject.com - if you didn't care between Ruby and Python, and were researching web app development frameworks, Nitro would not go on your list of choices. (In fact, most sites with have Google ads on them automatically get less attention from some people). Rails has a bunch of problems, which is probably why all of us are on this list. What is it they say in Robots? "See a need, fill a need." Nitro has the potential to allow simple creation of extremely powerful and very attractive web sites, without needing in depth knowledge of: 1) HTML/CSS 2) JavaScript 3) SQL If I were in charge of this project, I would set a goal to reach that state. Create some milestones saying "We need to be able to provide X, Y, Z functionality." Throw them out to this community and get feedback, and then set the direction based on those milestones. I've been using Og for developing a web-service application, and this app also needs some web-based front-end work. However, my business partner has been questioning my choice of technology - he _does_ the comparison between Rails and Nitro, and on the surface Nitro comes up short. I'm happy to contribute my time and resources (whether that be materials or money) to getting Nitro to the level where it is a serious competitor to Rails. I've started a business that needs to use a framework like Og/Nitro or Rails. I don't want to be forced down the Railway Track :-) Aidan p.s. Apologies if this comes across as a rant From ffsnoopy at gmail.com Wed Feb 1 22:04:11 2006 From: ffsnoopy at gmail.com (Mitchell Foral) Date: Wed, 1 Feb 2006 22:04:11 -0500 Subject: [Nitro] Og and SQLite Message-ID: <379ea2750602011904g63e01a5ew75d69efe937d23c4@mail.gmail.com> In the API doc, Og says it supports only SQLite3. Is there any chance Og will support SQLite(2)? Thanks, -Mitchell; From transfire at gmail.com Wed Feb 1 22:13:26 2006 From: transfire at gmail.com (TRANS) Date: Wed, 1 Feb 2006 22:13:26 -0500 Subject: [Nitro] 1.0 (revisited) In-Reply-To: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: <4b6f054f0602011913u2649aad0k95e605c3a1d209b@mail.gmail.com> I have to agree. It's very important that Nitro/Og start focusing almost exclusively on cleaning up the over all design, stablizing the API and improving documentation. Along those lines I think this page should be give strong consideration for bettering Og: http://www.nitrohq.com/view/OgRevisited. T. From james_b at neurogami.com Thu Feb 2 00:02:26 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 01 Feb 2006 22:02:26 -0700 Subject: [Nitro] 1.0 (revisited) In-Reply-To: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: <43E19262.7050203@neurogami.com> Aidan Rogers wrote: > All, > > I think the Nitro community to date has been very focused on > functionality and in getting stuff out there. This is why I've > mentioned 1.0 in the past. For Nitro to become more mainstream, it > needs a face lift. Agreed > > Compare http://www.nitrohq.com, http://www.rubyonrails.com, http:// > www.djangoproject.com - if you didn't care between Ruby and Python, > and were researching web app development frameworks, Nitro would not > go on your list of choices. (In fact, most sites with have Google > ads on them automatically get less attention from some people). Maybe. It depends on how in-your-face are the ads. But the pint is well taken. If you have ads, the rest of the site has to rise a little higher. (I just put the Google ads back on ruby-doc.org, and I'm less than thrilled, but the occasional check from Google comes in handy.) > > Rails has a bunch of problems, which is probably why all of us are on > this list. What is it they say in Robots? > > "See a need, fill a need." Oh, very much so. And, while there are similarities, they are different enough, with different strengths, that people should not see them as either/or choices. > > Nitro has the potential to allow simple creation of extremely > powerful and very attractive web sites, without needing in depth > knowledge of: > > 1) HTML/CSS > 2) JavaScript > 3) SQL But, and this is important, using Nitro should not trip you up when you want to go do all that stuff by hand. > > If I were in charge of this project, I would set a goal to reach that > state. Create some milestones saying "We need to be able to provide > X, Y, Z functionality." Throw them out to this community and get > feedback, and then set the direction based on those milestones. > > I've been using Og for developing a web-service application, and this > app also needs some web-based front-end work. However, my business > partner has been questioning my choice of technology - he _does_ the > comparison between Rails and Nitro, and on the surface Nitro comes up > short. I'm happy to contribute my time and resources (whether that > be materials or money) to getting Nitro to the level where it is a > serious competitor to Rails. > I've done a few Rails apps, and at least two live Nitro apps, and it is not uncommon that, while struggling with some ill-documented or poorly-named or bizarrely-magical counter-intuitive Rails thing that I think, "This would go so much smoother with Nitro." But I have partners who also need to run with the code, and truthfully it is easier for them to get up to speed with Rails than Nitro. > I've started a business that needs to use a framework like Og/Nitro > or Rails. I don't want to be forced down the Railway Track :-) > The biggest headache I had with Nitro was that, just when I thought I was getting my head around it, the API would change. And change. And change. That seems to have settled down, and when the API becomes truly stable it will be a great deal easier to use, document, and promote to others via blogs, magazine articles, conference presentations, and the like. > Aidan > > p.s. Apologies if this comes across as a rant I think it was right on target. -- James Britt From vseguip at gmail.com Thu Feb 2 02:58:14 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Thu, 2 Feb 2006 08:58:14 +0100 Subject: [Nitro] on_load in og ? In-Reply-To: References: <43D7F4A1.2020701@gmail.com> <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> Message-ID: On 1/26/06, George Moschovitis wrote: > > 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... > > Is this implemented and working? If so is it documented? It certainly would be a nice feature. Cheers, V. Segu? From george.moschovitis at gmail.com Thu Feb 2 04:33:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 11:33:18 +0200 Subject: [Nitro] Nitro creating invalid XML In-Reply-To: <43E1726E.1030507@neurogami.com> References: <43DE7261.2@neurogami.com> <43E0DB0F.7040205@neurogami.com> <43E0E2BC.1070007@neurogami.com> <43E1726E.1030507@neurogami.com> Message-ID: > At some recent version, Nitro started to break if template files were > not proper XML. Annoying in some ways (and a bad idea perhaps, as I You can change this, just remove the compilers that depend on REXML. I thought it would be best to use a full compiler pipeline by default. > The real value of using XML is that is well-understood and saves people > the repeated effort of inventing and dealing with one-off, ad-hoc markup > for every application. Hmm... will have a look when I find a bit of time. Thanks for the report and the suggestions. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Feb 2 04:34:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 11:34:15 +0200 Subject: [Nitro] Og and SQLite In-Reply-To: <379ea2750602011904g63e01a5ew75d69efe937d23c4@mail.gmail.com> References: <379ea2750602011904g63e01a5ew75d69efe937d23c4@mail.gmail.com> Message-ID: Perhaps you could write (and donate) the sqlite2 adapter. It is not that hard. Perhaps another user will provide this, be patient. regards, George. On 2/2/06, Mitchell Foral wrote: > In the API doc, Og says it supports only SQLite3. Is there any chance > Og will support SQLite(2)? > > Thanks, > -Mitchell; > > _______________________________________________ > 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 Feb 2 04:42:57 2006 From: chris at motionpath.com (Chris Farmiloe) Date: Thu, 2 Feb 2006 09:42:57 +0000 Subject: [Nitro] on_load in og ? In-Reply-To: References: <43D7F4A1.2020701@gmail.com> <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> Message-ID: <623919AA-A4EE-41C1-93FD-0C18F5C408F4@motionpath.com> Yip, you can use code like that in your Og managed models and on your Nitro controllers. Chris Farmiloe Design & Development. Motionpath Digital Media Ltd. St Georges road, Brighton, BN2 1ED. Office: 01273 608708 | Mobile: 07791 179481 On 2 Feb 2006, at 07:58, wrote: > On 1/26/06, George Moschovitis wrote: >>> 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... >> >> > Is this implemented and working? If so is it documented? It certainly > would be a nice feature. > > > Cheers, > V. Segu? > > _______________________________________________ > 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/20060202/b7b66ddc/attachment.html From george.moschovitis at gmail.com Thu Feb 2 05:07:13 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 12:07:13 +0200 Subject: [Nitro] 1.0 (revisited) In-Reply-To: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: Hello Aidan, I more or less agree with you. As I said in an earlier post, I personally will not be able to work on Nitro for 1-2 months starting from February 13th. For this reason we will setup a 'stabilization' repository with help for the MotionPath guys. The idea is during the next 1-2 months to stabilize the current version of Nitro: - cleanup the source code. - write more docs and example. - improve the website. But the community should really step up and help in this. There is a saying: 'put your money where your mouth is' Ie, if you really want to help improve Nitro in the way you describe please coordinate with Bryan Sotto, Guillaume and Chris/Rob who agreed to help in this stabilization project. Or you can follow the example of Emanuel Piperakis who 'sponsored' some Nitro features like WebFile, Og accumulator and more with a donation. Or you can contribute a more concrete 'Business' plan for version 1.0. Or start evangelising nitro to attract some more people who could help here. Now, speaking about me. Please note that I do not have infinite time, and I have to work to earn money. I am developing Nitro not to take over the world, but to learn something, use it in my own projects, and contribute something back to the great Ruby community. About the documentation, I would like to write a book about Nitro/Og. Perhaps with the help of someone from our community (James Britt?) or as a Navel project or something. Let me close this post be restating: Nitro is here to stay. I like to parallelize Nitro-Rails with Ruby-Python/Perl. Python/Perl were better documented initially, had more users, and accused Ruby of copying ideas. But Ruby was introducing important differences in the mix, and eventually got the missing ingredients (docs, people). I suggest to stay on the Nitro camp, and help even more to improve the things that need improvement. best regards, George. PS: Lets hear some more people's opinion here. Lets here solutions, and practical ideas how we can make Nitro more a community project. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Feb 2 05:08:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 12:08:08 +0200 Subject: [Nitro] on_load in og ? In-Reply-To: References: <43D7F4A1.2020701@gmail.com> <54A5B045-8EA0-40E5-B618-64C794AA1737@motionpath.com> Message-ID: > Is this implemented and working? If so is it documented? It certainly > would be a nice feature. Of course it is working. Nitro supports full Aspect Oriented Programming. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From ffsnoopy at gmail.com Thu Feb 2 07:12:56 2006 From: ffsnoopy at gmail.com (Mitchell Foral) Date: Thu, 2 Feb 2006 07:12:56 -0500 Subject: [Nitro] Og and SQLite Message-ID: <379ea2750602020412m566739fma8a40072f4c7df0d@mail.gmail.com> >Perhaps you could write (and donate) the sqlite2 adapter. It is not >that hard. >Perhaps another user will provide this, be patient. >regards, >George. Sure, I'll look into it and give it a shot. I was just wondering if it had already been done is all ;) Thanks, -- -Mitchell; From george.moschovitis at gmail.com Thu Feb 2 07:17:38 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 14:17:38 +0200 Subject: [Nitro] Og and SQLite In-Reply-To: <379ea2750602020412m566739fma8a40072f4c7df0d@mail.gmail.com> References: <379ea2750602020412m566739fma8a40072f4c7df0d@mail.gmail.com> Message-ID: > Sure, I'll look into it and give it a shot. I was just wondering if it > had already been done is all ;) It's not on my plans, and I don't know of anyone attempting this. I would love to see your attempt ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From nitro at tap.homeip.net Thu Feb 2 08:57:17 2006 From: nitro at tap.homeip.net (Joshua Hoke) Date: Thu, 02 Feb 2006 08:57:17 -0500 Subject: [Nitro] Mongrel adapter for Nitro In-Reply-To: References: <20060128172112.GA683@blah> Message-ID: <20060202135717.GA11070@blah> On Tue, Jan 31, 2006 at 05:36:52PM -0800, Bryan Soto wrote: > Works on WinXP too with some hoop-jumping. Mongrel fun though, not Nitro. Here is a bit of an explanation about Mongrel vs. Webrick (I could be wrong, I am certainly not an expert in either): Mongrel, at the moment, seems to be only a socket-listener along with a C extension to parse HTTP requests. It does not interpret requests at all that I know of, but leaves that to the application. Therefore, the adapter for Nitro has to pick up the slack... probably a lot of the missing features could be borrowed from Webrick code, but I don't know how many you can add before Mongrel starts to lose its speed advantage. :) I don't know what changes George made, but the code I wrote did not really support looking up MIME types (just defaulted to text/plain, hence the problem you saw). It also did not support If-Modified-Since/Last-modified headers (allows the browser to cache unmodified pages), partial content requests (e.g., resuming downloads), or persistent (keep-alive) connections. I don't even know if the latter is possible with Mongrel, actually. It might also blow up when things don't go the way it expects (a socket closed, error in Ruby code, invalid HTTP request, etc.); I don't know how many errors are trapped in Nitro. In short, because Mongrel has almost no features, all these parts of the standard have to be implemented in the Mongrel adapter. Joshua Hoke From george.moschovitis at gmail.com Thu Feb 2 09:03:02 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 2 Feb 2006 16:03:02 +0200 Subject: [Nitro] Ruby as an Og query language Message-ID: Dear devs, I added some experimental support for Caboose/EZ in the repo version of Og. This allows you to use Ruby as the query language for Og. Here is an example: user = User.ez_find { |user| user.age > 10 user.any { name == 'George' name == 'Stella' } } # => SELECT * FROM oguser WHERE (oguser.age > 10 AND (oguser.name = 'George' OR oguser.name = 'Stella')) Eventually this will be a standard option for find (I dont like ez_find). This is still early code and I will work with Ezra (the original author of EZ) to better integrate this with Og. I would like to hear your additional suggestions. For example I would like a suggestion for naming this feature. I plan to use 'natural' as in 'Og natural querying'. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Thu Feb 2 11:07:46 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 2 Feb 2006 17:07:46 +0100 Subject: [Nitro] Ruby as an Og query language In-Reply-To: References: Message-ID: <200602021707.46169.zimba.tm@gmail.com> On Thursday 02 February 2006 15:03, George Moschovitis wrote: > Dear devs, > > I added some experimental support for Caboose/EZ in the repo version of Og. > This allows you to use Ruby as the query language for Og. Here is an > example: > > user = User.ez_find { |user| > user.age > 10 > user.any { > name == 'George' > name == 'Stella' > } > } > > # => SELECT * FROM oguser WHERE (oguser.age > 10 AND (oguser.name = > 'George' OR oguser.name = 'Stella')) I like the idea of havind a Ruby DSL for SQL queries. Is there a source where we can get the code ? RubyForge didn't have any published. Is it possible to use the find options as selectors ? Like User.find(:name, :surname) { |user| user.age < 20 user.surname.any = ['George', 'Stella'] ['Moschovitis'].include? user.name } Is it possible to do generic queries ? Og.select(User.name, Message.body) { where { User.name < 20 and Message.body.length > 0 } join { Message.user = User } } Is it possible to use the OR operator and sub-conditions like (x AND y) OR (z OR r) ? > Eventually this will be a standard option for find (I dont like ez_find). Is it possible to have both available on find ? I think find doesn't use a block yet. > This is still early code and I will work with Ezra (the original > author of EZ) to better integrate this with Og. I would like to hear > your additional suggestions. For example I would like a suggestion for > naming this feature. I plan to use 'natural' as in 'Og natural > querying'. > > 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 zimba.tm at gmail.com Thu Feb 2 12:42:23 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 2 Feb 2006 18:42:23 +0100 Subject: [Nitro] Ruby as an Og query language In-Reply-To: <200602021707.46169.zimba.tm@gmail.com> References: <200602021707.46169.zimba.tm@gmail.com> Message-ID: <200602021842.23988.zimba.tm@gmail.com> Replying to myself... Ez is in Nitro's darcs repository. If you intend to use ez as a ruby DSL to SQL, why not call it 'og/query' ? On Thursday 02 February 2006 17:07, zimba.tm wrote: > On Thursday 02 February 2006 15:03, George Moschovitis wrote: > > Dear devs, > > > > I added some experimental support for Caboose/EZ in the repo version of > > Og. This allows you to use Ruby as the query language for Og. Here is an > > example: > > > > user = User.ez_find { |user| > > user.age > 10 > > user.any { > > name == 'George' > > name == 'Stella' > > } > > } > > > > # => SELECT * FROM oguser WHERE (oguser.age > 10 AND (oguser.name = > > 'George' OR oguser.name = 'Stella')) > > I like the idea of havind a Ruby DSL for SQL queries. Is there a source > where we can get the code ? RubyForge didn't have any published. > > Is it possible to use the find options as selectors ? Like > > User.find(:name, :surname) { |user| > user.age < 20 > user.surname.any = ['George', 'Stella'] > ['Moschovitis'].include? user.name > } > > Is it possible to do generic queries ? > > Og.select(User.name, Message.body) { > where { > User.name < 20 and Message.body.length > 0 > } > join { Message.user = User } > } > > Is it possible to use the OR operator and sub-conditions like (x AND y) OR > (z OR r) ? > > > Eventually this will be a standard option for find (I dont like ez_find). > > Is it possible to have both available on find ? I think find doesn't use a > block yet. > > > This is still early code and I will work with Ezra (the original > > author of EZ) to better integrate this with Og. I would like to hear > > your additional suggestions. For example I would like a suggestion for > > naming this feature. I plan to use 'natural' as in 'Og natural > > querying'. > > > > 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 From rob at motionpath.com Thu Feb 2 13:07:48 2006 From: rob at motionpath.com (Rob Pitt) Date: Thu, 02 Feb 2006 18:07:48 +0000 Subject: [Nitro] Broken Net::HTTP in ruby 1.8.3+ [slightly OT] Message-ID: <1138903668.4872.43.camel@robs-p4> I think I mentioned this a long time ago but was silly enough to install 1.8.4 somewhere critical again, this fix was sufficient to fix my problems with this library under the new version so I provide it here in case anyone else was being given headaches by it. --- ../net2/http.rb Tue Sep 13 17:27:02 2005 +++ http.rb Thu Feb 2 17:57:08 2006 @@ -1158,7 +1158,7 @@ @header.delete key.downcase return val end - @header[key.downcase] = Array(val).map {|s| s.to_str } + @header[key.downcase] = [val.to_str.dup] end # [Ruby 1.8.3] @@ -1178,9 +1178,9 @@ # def add_field(key, val) if @header.key?(key.downcase) - @header[key.downcase].concat Array(val) + @header[key.downcase].concat [val.dup] else - @header[key.downcase] = Array(val).dup + @header[key.downcase] = [val.dup] end end From zimba.tm at gmail.com Thu Feb 2 15:48:01 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 2 Feb 2006 21:48:01 +0100 Subject: [Nitro] [PATCH] admin/part changed to sort System configuration by name Message-ID: <200602022148.01979.zimba.tm@gmail.com> Small patch as decribed in the subject. Cheers, Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_admin_sort.tgz Type: application/x-tgz Size: 5696 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060202/1c8f4580/attachment.bin From ffsnoopy at gmail.com Thu Feb 2 17:13:55 2006 From: ffsnoopy at gmail.com (Mitchell Foral) Date: Thu, 2 Feb 2006 17:13:55 -0500 Subject: [Nitro] Og and SQLite Message-ID: <379ea2750602021413x188c7f01sb531fa1dd8f51e41@mail.gmail.com> >It's not on my plans, and I don't know of anyone attempting this. >I would love to see your attempt ;-) >regards, >George. Here is an Og store for SQLite2. I'm not sure how to fully test it, but I didn't see any potential SQL syntax incompatibilities from the SQLite3 store. It seems to work well with Nitro's Flare application, but again, I'm not sure of Flare's full capability. The store can be used by doing something like Og.setup( :store => :sqlite2, :name => 'database.db' ) As you will see, the transition was extremely smooth, as just a few 'sqlite3' replacements with 'sqlite' and 'sqlite2' were necessary. This also brings up the point that since the sqlite3 and sqlite2 stores are so similar, could there be a way to merge the two appropriately? Unfortunately my knowledge of Og API and internals is quite limited and I'm not sure of the best approach to this. Hope this helps, -- -Mitchell; -------------- next part -------------- A non-text attachment was scrubbed... Name: sqlite2.rb Type: application/x-ruby Size: 4947 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060202/f62bbb34/attachment.bin From zimba.tm at gmail.com Thu Feb 2 21:16:01 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 3 Feb 2006 03:16:01 +0100 Subject: [Nitro] [PATCH] Made Control.transformers selectably by controller Message-ID: <200602030316.02055.zimba.tm@gmail.com> Compiler.transformers : Added ability to select transformers in the controller. * property :transformers [StaticInclude, Morphing, ...] * only Template is mendatory * StaticInclude now uses the controller's template_root if available * moved a line in render.rb:119 when no controller is detected Cheers, Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: transformer_patch.tgz Type: application/x-tgz Size: 6335 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060202/aad9b638/attachment.bin From george.moschovitis at gmail.com Fri Feb 3 04:09:53 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 3 Feb 2006 11:09:53 +0200 Subject: [Nitro] Ruby as an Og query language In-Reply-To: <200602021707.46169.zimba.tm@gmail.com> References: <200602021707.46169.zimba.tm@gmail.com> Message-ID: > Is it possible to have both available on find ? I think find doesn't use a > block yet. find will accept an optional block.. in the repo version allready accepts string, array and the traditional hash. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Feb 3 04:10:44 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 3 Feb 2006 11:10:44 +0200 Subject: [Nitro] Og and SQLite In-Reply-To: <379ea2750602021413x188c7f01sb531fa1dd8f51e41@mail.gmail.com> References: <379ea2750602021413x188c7f01sb531fa1dd8f51e41@mail.gmail.com> Message-ID: thanks will have a look at this ;-) -g. On 2/3/06, Mitchell Foral wrote: > >It's not on my plans, and I don't know of anyone attempting this. > >I would love to see your attempt ;-) > > >regards, > >George. > > Here is an Og store for SQLite2. I'm not sure how to fully test it, > but I didn't see any potential SQL syntax incompatibilities from the > SQLite3 store. It seems to work well with Nitro's Flare application, > but again, I'm not sure of Flare's full capability. The store can be > used by doing something like > Og.setup( :store => :sqlite2, :name => 'database.db' ) > > As you will see, the transition was extremely smooth, as just a few > 'sqlite3' replacements with 'sqlite' and 'sqlite2' were necessary. > This also brings up the point that since the sqlite3 and sqlite2 > stores are so similar, could there be a way to merge the two > appropriately? Unfortunately my knowledge of Og API and internals is > quite limited and I'm not sure of the best approach to this. > > Hope this helps, > -- > -Mitchell; > > > _______________________________________________ > 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 Feb 3 09:02:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 3 Feb 2006 16:02:15 +0200 Subject: [Nitro] Me missing... Message-ID: Dear devs, things changed a little bit. I will not be able to participate on Nitro development from February 7th, instead of 13th. So the plan is to release Nitro 0.28.0 this Monday. If you have any patches comments etc for this version let me know. From tuesday your patches and suggestions will be handled by Chris, Rob, Bryan, Guill and Tasos. during the weekend I will upload my latest changes to the repo, so please try to grab the changes and verify compatibility with your apps. regards, George. PS: Bryan, an email about the outstanding patches will be useful ;-) -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Fri Feb 3 11:42:08 2006 From: transfire at gmail.com (TRANS) Date: Fri, 3 Feb 2006 11:42:08 -0500 Subject: [Nitro] Me missing... In-Reply-To: References: Message-ID: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> Is 0.28 working with the latest Facets (1.0.1) now? T. From bryan.a.soto at gmail.com Fri Feb 3 18:40:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 15:40:25 -0800 Subject: [Nitro] 1.0 (revisited) In-Reply-To: References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: Hello all, Please forgive the lateness of response. Aside from the day job, there was quite a bit to digest in this thread. I think about Nitro and Og a lot. To me, they're fun to use They're flexible and fit well with Ruby in general. They take care of details so I can concentrate on my programming. And so I've invested a lot of time because I want them to reach their full potential. I consider them to be my project. I take bug reports as a personal failure, because once it's in the repository, I consider it to be my code. No matter where the code originally came from. Basically, I care about it and take pride in it. I don't think I'm alone in that. As far as 1.0 goes, we all have different visions of what it will be. So please everybody, talk about your ideas and contribute time to help Nitro and Og reach them. Not all ideas will make the final cut, but Nitro and Og will be better off for it. The only contribution I can make to that vision currently is that the code base needs some refactoring to make it more amenable to future changes. Overall, I think Nitro is in good shape, but needs some good docs. Og though, I think, has some catching up to do. Aidan, I personally thank you for your offer of assistance. I hope more people will join in. George has been the heart and soul of this project, but now we need to get along without him for awhile. That leaves a big void that will have to be filled for Nitro and Og to thrive. I hope people will step up to fill that void. At this point, I think there is plenty of room for people to define their own role in the community. So you saying, "If I were in charge of this project" becomes quite plausible. One simply has to get others to follow to become a leader. Of course, that's also the hard part. ;) As far as milestones go, I'm happy to contribute my current to do list. Some are little bug fixes, some are big changes. If anyone is looking for a way to start helping, there might be something on this list for you. Hopefully others will expand on this and we can start prioritizing and accomplishing. My take is the bug fixes first, then the Og stores. I haven't really prioritized the rest as of yet. It's not a mission statement or grand vision (probably a good thing), but I think these are steps on the path to our mythical 1.0. The order is not relevant in any way. * All Og stores should be (relatively) interchangeable. Currently the Postgres adaptor is the only store that handles constraints and I know the Mysql db can. Kirby doesn't currently handle join tables at all, so relationships don't work. I don't think it's necessary to emulate features that the underlying store doesn't support though. * When that's accomplished, articles and tutorials. As things currently stand, you have to use Postgres to put Og in it's best light which kind of defeats the purpose of what Og is supposed to do. * Og refactoring. Store adaptors should be just that, adaptors. Things like constraints, schema evolution, etc. should all be handled in the SqlStore super class. The way things currently are, every single adaptor has the schema evolution code cut and pasted in. * Web site overhaul. The wiki is functional and should probably be linked to, but it just doesn't impress. George's videos should probably be featured more prominently as well. * Nitro should respect the $GLUE_DONT_INCLUDE flag, i.e. Aspect in code should be referred to as Glue::Aspect. As it is now, you get errors trying to run a Nitro app with this flag set. Besides, when our name space is clean, we can interact with other libraries better, e.g. Builder. * Better support for YAML. * More tests in the test suite. * Nitro should generate proper XML. This might require another transform in the compiler pipeline. * Better support for multiple stores. The Og test suite not running was a symptom of this. * Schema inheritance has two currently outstanding bugs. * Og.thread_safe not properly respected. When pooling, connections aren't returned to the pool. Anyway, I hope this sparks some conversation and interest. I hope to work with all of you in improving Nitro and Og. Bryan On 2/2/06, George Moschovitis wrote: > > Hello Aidan, > > I more or less agree with you. As I said in an earlier post, I > personally will not be able to work on Nitro for 1-2 months starting > from February 13th. For this reason we will setup a 'stabilization' > repository with help for the MotionPath guys. The idea is during the > next 1-2 months to stabilize the current version of Nitro: > > - cleanup the source code. > - write more docs and example. > - improve the website. > > But the community should really step up and help in this. There is a > saying: > > 'put your money where your mouth is' > > Ie, if you really want to help improve Nitro in the way you describe > please coordinate with Bryan Sotto, Guillaume and Chris/Rob who agreed > to help in this stabilization project. Or you can follow the example > of Emanuel Piperakis who 'sponsored' some Nitro features like WebFile, > Og accumulator and more with a donation. Or you can contribute a more > concrete 'Business' plan for version 1.0. Or start evangelising nitro > to attract some more people who could help here. > > Now, speaking about me. Please note that I do not have infinite time, > and I have to work to earn money. I am developing Nitro not to take > over the world, but to learn something, use it in my own projects, and > contribute something back to the great Ruby community. > > About the documentation, I would like to write a book about Nitro/Og. > Perhaps with the help of someone from our community (James Britt?) or > as a Navel project or something. > > Let me close this post be restating: Nitro is here to stay. I like to > parallelize Nitro-Rails with Ruby-Python/Perl. Python/Perl were better > documented initially, had more users, and accused Ruby of copying > ideas. But Ruby was introducing important differences in the mix, and > eventually got the missing ingredients (docs, people). > > I suggest to stay on the Nitro camp, and help even more to improve the > things that need improvement. > > > best regards, > George. > > > PS: Lets hear some more people's opinion here. Lets here solutions, > and practical ideas how we can make Nitro more a community project. > > > > -- > 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/20060203/1bc05985/attachment.html From bryan.a.soto at gmail.com Fri Feb 3 20:28:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 17:28:24 -0800 Subject: [Nitro] PATCH: Outstanding as of Feb. 03, 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Schema Inheritance * George is investigating. http://rubyforge.org/pipermail/nitro-general/2006-January/002424.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 Nitro shouldn't pollute the name space with Glue. * George is requesting feedback. http://rubyforge.org/pipermail/nitro-general/2006-January/002594.html admin/part changed to sort system configuration by name. * Pending http://rubyforge.org/pipermail/nitro-general/2006-February/002680.html Made Control.transformers selectable by controller. * Pending http://rubyforge.org/pipermail/nitro-general/2006-February/002682.html Og Sqlite2 adaptor. * George is having a look. http://rubyforge.org/pipermail/nitro-general/2006-February/002681.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060203/07f10825/attachment.html From bryan.a.soto at gmail.com Fri Feb 3 20:48:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 17:48:42 -0800 Subject: [Nitro] Me missing... In-Reply-To: References: Message-ID: On 2/3/06, George Moschovitis wrote: > > Dear devs, > > things changed a little bit. I will not be able to participate on > Nitro development from February 7th, instead of 13th. So the plan is > to release Nitro 0.28.0 this Monday. If you have any patches comments > etc for this version let me know. From tuesday your patches and > suggestions will be handled by Chris, Rob, Bryan, Guill and Tasos. Is the plan to wait for any further releases pending your return, or will incremental bugfix releases be okay, i.e. 0.28.1, etc.? Also, a few bugs to be aware of: * Two issues with schema inheritance, here http://rubyforge.org/pipermail/nitro-general/2006-January/002636.html and http://rubyforge.org/pipermail/nitro-general/2006-January/002624.html I haven't heard from Chris or Rob, so it might have to be your call. * Errors due to pool emptying when Og.thread_safe is true. http://rubyforge.org/pipermail/nitro-general/2006-February/002659.html By the way, any word on Trac? during the weekend I will upload my latest changes to the repo, so > please try to grab the changes > and verify compatibility with your apps. Sounds good. regards, > George. > > PS: Bryan, an email about the outstanding patches will be useful ;-) > > Already done. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060203/abaa4403/attachment.html From bryan.a.soto at gmail.com Fri Feb 3 20:51:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 17:51:08 -0800 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> Message-ID: On 2/3/06, TRANS wrote: > > Is 0.28 working with the latest Facets (1.0.1) now? > > T. > We'll probably find out this weekend. ;) By the way, for those who haven't yet and would like to help test, # gem install facets -y --version=1.0.1 gem update doesn't seem to pick it up because of the change in versioning. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060203/92b6bc4e/attachment.html From bryan.a.soto at gmail.com Fri Feb 3 20:52:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 17:52:51 -0800 Subject: [Nitro] PATCH: Outstanding as of Feb. 03, 2006 In-Reply-To: References: Message-ID: Missed one as it wasn't prefixed with PATCH. Camel case does not work for join tables. * Pending. http://rubyforge.org/pipermail/nitro-general/2006-January/002627.html * Add test case. http://rubyforge.org/pipermail/nitro-general/2006-January/002628.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060203/7bdff5db/attachment.html From bryan.a.soto at gmail.com Fri Feb 3 20:55:45 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 3 Feb 2006 17:55:45 -0800 Subject: [Nitro] Me missing... In-Reply-To: References: Message-ID: On 2/3/06, Bryan Soto wrote: > > By the way, any word on Trac? > > Just in case that isn't an option anymore, can you add me to admin the bug tracker on Rubyforge. I'd like to have something as an option. Username is bsoto. Thanks, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060203/499f5d5c/attachment.html From james_b at neurogami.com Fri Feb 3 21:02:05 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 03 Feb 2006 19:02:05 -0700 Subject: [Nitro] 1.0 (revisited) In-Reply-To: References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: <43E40B1D.6080105@neurogami.com> George Moschovitis wrote: ... > > Now, speaking about me. Please note that I do not have infinite time, > and I have to work to earn money. I am developing Nitro not to take > over the world, but to learn something, use it in my own projects, and > contribute something back to the great Ruby community. > > About the documentation, I would like to write a book about Nitro/Og. > Perhaps with the help of someone from our community (James Britt?) or > as a Navel project or something. > Intriguing idea. -- 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.30secondrule.com - Building Better Tools From george.moschovitis at gmail.com Sat Feb 4 04:51:20 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 4 Feb 2006 11:51:20 +0200 Subject: [Nitro] Me missing... In-Reply-To: References: Message-ID: Ok will do ;-) On 2/4/06, Bryan Soto wrote: > On 2/3/06, Bryan Soto wrote: > > > > > > By the way, any word on Trac? > > > > > > Just in case that isn't an option anymore, can you add me to admin the bug > tracker on Rubyforge. I'd like to have something as an option. Username is > bsoto. > > Thanks, > > 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 Sat Feb 4 04:52:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 4 Feb 2006 11:52:15 +0200 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> Message-ID: It works with a single fix, will try your updated gem later today...if it works correct;y I will remove the custom paramix.rb and *please* rerelease this as 1.0.2 thanks, George. On 2/3/06, TRANS wrote: > Is 0.28 working with the latest Facets (1.0.1) now? > > T. > > _______________________________________________ > 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 Feb 4 04:53:35 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 4 Feb 2006 11:53:35 +0200 Subject: [Nitro] 1.0 (revisited) In-Reply-To: <43E40B1D.6080105@neurogami.com> References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> <43E40B1D.6080105@neurogami.com> Message-ID: > > About the documentation, I would like to write a book about Nitro/Og. > > Perhaps with the help of someone from our community (James Britt?) or > > as a Navel project or something. > > Intriguing idea. This will have to wait for a month or two, but we can discuss this afterwards ;-) best regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Feb 4 04:58:32 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 4 Feb 2006 11:58:32 +0200 Subject: [Nitro] Og tests Message-ID: Bryan, there seem to be some problems with the unit tests for Og. I think you made some changes, can you please verify that everything works correctly? -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Feb 4 05:22:04 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 4 Feb 2006 12:22:04 +0200 Subject: [Nitro] 1.0 (revisited) In-Reply-To: References: <6B0C1A0B-9F6F-4C33-8A21-66FABC2AE048@yoyo.org> Message-ID: > I think about Nitro and Og a lot. To me, they're fun to use They're > flexible and fit well with Ruby in general. They take care of details so I > ... > I'm alone in that. nice to hear ;-) > * All Og stores should be (relatively) interchangeable. Currently the > that the underlying store doesn't support though. agreed. > * Og refactoring. Store adaptors should be just that, adaptors. Things like > constraints, schema evolution, etc. should all be handled in the SqlStore > super class. The way things currently are, every single adaptor has the > schema evolution code cut and pasted in. I totally agree with this. I would really prefer to defer this refactoring for month or so, so that I would be able to participate in this, but If anynone was to tried he may go ahead and do it. it is an open source project after all. But I really have some specific ideas on this, and I believe the community will like the changes I plan to do as I am thinking about them for a lot of time. > * Nitro should respect the $GLUE_DONT_INCLUDE flag, i.e. Aspect in code > should be referred to as Glue::Aspect. As it is now, you get errors trying > to run a Nitro app with this flag set. Besides, when our name space is > clean, we can interact with other libraries better, e.g. Builder. Even, If I don't fully agree with this, if the rest of the core developers think it is necessary, then go ahead and do it ;-) > * More tests in the test suite. This is certainly something I would *love* to be improved during february. It is extremely important. > * Nitro should generate proper XML. This might require another transform in > the compiler pipeline. > * Better support for multiple stores. The Og test suite not running was a > symptom of this. I wanted to tackle this in time for 0.28.0 but saddly I do not have the time now :( > * Og.thread_safe not properly respected. When pooling, connections aren't > returned to the pool. there are some fixes about this in 0.28.0 regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Sat Feb 4 11:02:19 2006 From: transfire at gmail.com (TRANS) Date: Sat, 4 Feb 2006 11:02:19 -0500 Subject: [Nitro] Me missing... In-Reply-To: References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> Message-ID: <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> OKya, if it doesn;t work correctly let me know what's up so I can fix, and then I can release as 1.0.2. T. On 2/4/06, George Moschovitis wrote: > It works with a single fix, will try your updated gem later today...if > it works correct;y I will remove the custom paramix.rb and *please* > rerelease this as 1.0.2 > > thanks, > George. > > On 2/3/06, TRANS wrote: > > Is 0.28 working with the latest Facets (1.0.1) now? > > > > T. > > > > _______________________________________________ > > 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 > -- ( o- ??? went BOOM // trans. / / transfire at gmail.com From bryan.a.soto at gmail.com Sat Feb 4 14:00:34 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 4 Feb 2006 11:00:34 -0800 Subject: [Nitro] Og tests In-Reply-To: References: Message-ID: On 2/4/06, George Moschovitis wrote: > > Bryan, there seem to be some problems with the unit tests for Og. > I think you made some changes, can you please verify that everything > works correctly? > > Basically, some new tests were added to the suite with Og.setup calls. Attached patch fixes that, moves some class definitions to inside the test case namespace to ensure unique tables are created for each test. Multiple Og.setup calls don't work very well which is why I moved them to CONFIG.rb to ensure they only happened once. Most of the current errors come from tc_orderable.rb. It seems as though the self.include_with_params call in og/lib/glue/orderable.rb:11 isn't executed. I tried to put a breakpoint and some puts statements in it which never ran. More paramix.rb problems? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060204/ee8e7384/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: refix_og_test_suite.zip Type: application/zip Size: 6737 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060204/ee8e7384/attachment.zip From bryan.a.soto at gmail.com Sat Feb 4 14:06:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 4 Feb 2006 11:06:52 -0800 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> Message-ID: On 2/4/06, TRANS wrote: > > OKya, if it doesn;t work correctly let me know what's up so I can fix, > and then I can release as 1.0.2. > > T. > > I think this may be facets related, so I'm going to point it out to you just in case. Please see http://rubyforge.org/pipermail/nitro-general/2006-February/002700.html If I can, I'll try to dig in a little deeper. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060204/6c62e26d/attachment.html From transfire at gmail.com Sat Feb 4 17:00:34 2006 From: transfire at gmail.com (TRANS) Date: Sat, 4 Feb 2006 17:00:34 -0500 Subject: [Nitro] Og tests In-Reply-To: References: Message-ID: <4b6f054f0602041400x6a86bb78yf6cecaf34b8bf543@mail.gmail.com> On 2/4/06, Bryan Soto wrote: > On 2/4/06, George Moschovitis wrote: > > Bryan, there seem to be some problems with the unit tests for Og. > > I think you made some changes, can you please verify that everything > > works correctly? > > > > > > Basically, some new tests were added to the suite with Og.setup calls. > Attached patch fixes that, moves some class definitions to inside the test > case namespace to ensure unique tables are created for each test. > > Multiple Og.setup calls don't work very well which is why I moved them to > CONFIG.rb to ensure they only happened once. > > Most of the current errors come from tc_orderable.rb. It seems as though the > self.include_with_params call in og/lib/glue/orderable.rb:11 isn't executed. > I tried to put a breakpoint and some puts statements in it which never ran. The callback method is #included_with_parameters, one should use include as one normally does, but just add the parameters. For example: module M def self.included_with_parameters( base, parms ) base.class_eval do define_method :check do parms end end end end class C include M, :p => "check" end T. From bryan.a.soto at gmail.com Sun Feb 5 02:45:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 4 Feb 2006 23:45:35 -0800 Subject: [Nitro] Og tests In-Reply-To: <4b6f054f0602041400x6a86bb78yf6cecaf34b8bf543@mail.gmail.com> References: <4b6f054f0602041400x6a86bb78yf6cecaf34b8bf543@mail.gmail.com> Message-ID: On 2/4/06, TRANS wrote: > > On 2/4/06, Bryan Soto wrote: > > Basically, some new tests were added to the suite with Og.setup calls. > > Attached patch fixes that, moves some class definitions to inside the > test > > case namespace to ensure unique tables are created for each test. > > > > Multiple Og.setup calls don't work very well which is why I moved them > to > > CONFIG.rb to ensure they only happened once. > > > > Most of the current errors come from tc_orderable.rb. It seems as though > the > > self.include_with_params call in og/lib/glue/orderable.rb:11 isn't > executed. > > I tried to put a breakpoint and some puts statements in it which never > ran. > > The callback method is #included_with_parameters, one should use > include as one normally does, but just add the parameters. For > example: > > module M > def self.included_with_parameters( base, parms ) > base.class_eval do > define_method :check do > parms > end > end > end > end > > class C > include M, :p => "check" > end > > T. > Thanks for the explanation. Attached makes the change per Trans' direction. Still some errors, but it's progress. I'll check out whatever you don't get to in the morning. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060205/2b2dc570/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: more_og_test_suite_fixes.zip Type: application/zip Size: 5839 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060205/2b2dc570/attachment.zip From george.moschovitis at gmail.com Sun Feb 5 05:47:19 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 5 Feb 2006 12:47:19 +0200 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> Message-ID: Trans, please re-release your fixed version as facets 1.0.2. Because if someone has allready the old 1.0.1 in his system, nitro will not work. thanks, George. On 2/4/06, TRANS wrote: > OKya, if it doesn;t work correctly let me know what's up so I can fix, > and then I can release as 1.0.2. > > T. > > On 2/4/06, George Moschovitis wrote: > > It works with a single fix, will try your updated gem later today...if > > it works correct;y I will remove the custom paramix.rb and *please* > > rerelease this as 1.0.2 > > > > thanks, > > George. > > > > On 2/3/06, TRANS wrote: > > > Is 0.28 working with the latest Facets (1.0.1) now? > > > > > > T. > > > > > > _______________________________________________ > > > 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 > > > > > -- > ( o- ??? went BOOM > // trans. > / / transfire at gmail.com > _______________________________________________ > 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 Sun Feb 5 10:22:24 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 5 Feb 2006 16:22:24 +0100 Subject: [Nitro] [wiki] Graphist needed Message-ID: <200602051622.25304.zimba.tm@gmail.com> Hello, Is somebody interested in producing some graphs for nitrohq.com ? It would be nice to have 3 different graphs at least : * Shema showing the place of each building block : Facets, Glue, Nitro, Og, Breakpoint.. * Shema showing the different parts of Og. * Shema showing the different Nitro parts * Shema showing the workflow of Nitro (transformers, ...) If somebody is interested, I will give more details about it. Cheers, Jonas Pfenniger From transfire at gmail.com Sun Feb 5 10:34:28 2006 From: transfire at gmail.com (TRANS) Date: Sun, 5 Feb 2006 15:34:28 +0000 Subject: [Nitro] Me missing... In-Reply-To: References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> Message-ID: <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> On 2/5/06, George Moschovitis wrote: > Trans, please re-release your fixed version as facets 1.0.2. Because > if someone has allready the old 1.0.1 in his system, nitro will not > work. Okay. Any one have any other needed changes to Facets before I release this? T. From manveru at weez.co.jp Sun Feb 5 23:39:19 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Mon, 6 Feb 2006 13:39:19 +0900 Subject: [Nitro] [wiki] Graphist needed In-Reply-To: <200602051622.25304.zimba.tm@gmail.com> References: <200602051622.25304.zimba.tm@gmail.com> Message-ID: <200602061339.19374.manveru@weez.co.jp> Hey zimba.tm :) Would be interested in doing something like that - it would definitly help everyone to see the flow of nitro/og. However, it might take a time and needs some very detailed information about all the parts - so we could meet in irc sometime or just mail us the informations. I think you've got more insight in the working between the different parts, however i like to do a bit of UML-modelling and gfx-work, so let's work together for the greater good of humanity ^^ (i must sound like one of these japanese already...) I'll try to get a grasp at how the parts of nitro|og|glue|facets|breakpoint| redcloth|daemons work together. It just deems to me that we could sometime get rid of the redcloth-dependecy. Also a goal, wich might be a bit offtopic here: making gems out of spark/flare and let them become mature projects of their own. I think there's a lot of power to unleash in these - also the simpler examples could be polished up a bit, kind of deluxe edition with pretty CSS and one or two additional functions. for example - extending the gallery with an ability to delete images and doing other fancy stuff (also making the layout a bit nicer - i rewrote most of the example already for the CMS i'm doing - might mail it to the list sometime later. Now that was a bit offtopic, but i guess everyone is reading it despite of that fact... However, i'd like to help with the generation of some pretty stuff to make nitro looking better and to give people who don't have a deep insight to get a grasp on what's going on in there. ~~~~manveru Am Monday 06 February 2006 00:22 schrieb zimba.tm: > Hello, > > Is somebody interested in producing some graphs for nitrohq.com ? > > It would be nice to have 3 different graphs at least : > > * Shema showing the place of each building block : Facets, Glue, Nitro, > Og, Breakpoint.. > > * Shema showing the different parts of Og. > > * Shema showing the different Nitro parts > > * Shema showing the workflow of Nitro (transformers, ...) > > If somebody is interested, I will give more details about it. > > Cheers, > Jonas Pfenniger > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Mon Feb 6 01:55:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 5 Feb 2006 22:55:48 -0800 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> Message-ID: On 2/5/06, TRANS wrote: > > On 2/5/06, George Moschovitis wrote: > > Trans, please re-release your fixed version as facets 1.0.2. Because > > if someone has allready the old 1.0.1 in his system, nitro will not > > work. > > Okay. > > Any one have any other needed changes to Facets before I release this? > > How about macros in the Lisp facet? ;) Seriously though, the only problem I've found is that gem considers the older version 2005.10.30 to be a higher version number than 1.0.1. I don't know if it's possible, but if so, it might be a good idea to remove it from the gems index and maybe leave the archives available as a download otherwise gem updates will actually downgrade the facets version. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060206/6f1f56a0/attachment.html From zimba.tm at gmail.com Mon Feb 6 04:47:56 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 6 Feb 2006 10:47:56 +0100 Subject: [Nitro] [wiki] Graphist needed In-Reply-To: <200602061339.19374.manveru@weez.co.jp> References: <200602051622.25304.zimba.tm@gmail.com> <200602061339.19374.manveru@weez.co.jp> Message-ID: <200602061047.56900.zimba.tm@gmail.com> Here is the general picture of Nitro with Og in png and svg version. Please let me know what you think of it. I don't mean graphically but technically. Cheers, Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro_organisation.png Type: image/png Size: 111604 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060206/7a44e528/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro_organisation.svg Type: image/svg+xml Size: 17977 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060206/7a44e528/attachment.bin From george.moschovitis at gmail.com Mon Feb 6 04:48:50 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 11:48:50 +0200 Subject: [Nitro] Me missing... In-Reply-To: References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> Message-ID: > Seriously though, the only problem I've found is that gem considers the > older version 2005.10.30 to be a higher version number than 1.0.1. I don't > know if it's possible, but if so, it might be a good idea to remove it from > the gems index and maybe leave the archives available as a download > otherwise gem updates will actually downgrade the facets version. But do not remove before 0.28.0 is released, as 0.27.0 depends on that method. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Feb 6 04:58:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 11:58:08 +0200 Subject: [Nitro] [wiki] Graphist needed In-Reply-To: <200602061047.56900.zimba.tm@gmail.com> References: <200602051622.25304.zimba.tm@gmail.com> <200602061339.19374.manveru@weez.co.jp> <200602061047.56900.zimba.tm@gmail.com> Message-ID: Erm... I dont think facets should enclose everything ;-) -g. On 2/6/06, zimba.tm wrote: > Here is the general picture of Nitro with Og in png and svg version. > > Please let me know what you think of it. I don't mean graphically but > technically. > > Cheers, Jonas > > > _______________________________________________ > 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 Feb 6 05:00:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 12:00:34 +0200 Subject: [Nitro] Facets Message-ID: Because I am running out of time, I will probably make a custom version of paramix in glue and link against 1.0.1. If Tom releases a bug fixed version in time I will use that instead. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From m.fellinger at gmail.com Mon Feb 6 05:25:18 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Mon, 6 Feb 2006 19:25:18 +0900 Subject: [Nitro] Facets In-Reply-To: References: Message-ID: <9c00d3e00602060225m22f035c2t@mail.gmail.com> good, i think a lot of people are waiting for that...still i'm not sure if paramix is causing the errors for me: goes like no such file to load -- facets/nullclass running on latest stuff from everything... 2006/2/6, George Moschovitis :> Because I am running out of time, I will probably make a custom> version of paramix> in glue and link against 1.0.1. If Tom releases a bug fixed version in> time I will use that instead.>> 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 zimba.tm at gmail.com Mon Feb 6 08:31:29 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 6 Feb 2006 14:31:29 +0100 Subject: [Nitro] [FIX] Bug with session.rb where 30:Fixnum doesn't have "minutes" defined Message-ID: <200602061431.29536.zimba.tm@gmail.com> ^^ Cheers, Jonas -------------- next part -------------- A non-text attachment was scrubbed... Name: sessions_time_patch.tgz Type: application/x-tgz Size: 6282 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060206/a707d193/attachment.bin From transfire at gmail.com Mon Feb 6 10:23:15 2006 From: transfire at gmail.com (TRANS) Date: Mon, 6 Feb 2006 15:23:15 +0000 Subject: [Nitro] Facets In-Reply-To: <9c00d3e00602060225m22f035c2t@mail.gmail.com> References: <9c00d3e00602060225m22f035c2t@mail.gmail.com> Message-ID: <4b6f054f0602060723n73876149j2731d3984935a594@mail.gmail.com> "facets/nullclass" do you mean facet/nullclass ? If not there is one problem. Where is that coming from. Well, I'll grep and see. T. On 2/6/06, Michael Fellinger wrote: > good, i think a lot of people are waiting for that...still i'm not sure if paramix is causing the errors for me: goes like > no such file to load -- facets/nullclass > running on latest stuff from everything... > 2006/2/6, George Moschovitis :> Because I am running out of time, I will probably make a custom> version of paramix> in glue and link against 1.0.1. If Tom releases a bug fixed version in> time I will use that instead.>> 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 > -- ( o- ??? went BOOM // trans. / / transfire at gmail.com From george.moschovitis at gmail.com Mon Feb 6 10:34:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 17:34:08 +0200 Subject: [Nitro] Facets In-Reply-To: <9c00d3e00602060225m22f035c2t@mail.gmail.com> References: <9c00d3e00602060225m22f035c2t@mail.gmail.com> Message-ID: Uninstall facets and reinstall 1.0.1 then try the *latest* glycerin -g. On 2/6/06, Michael Fellinger wrote: > good, i think a lot of people are waiting for that...still i'm not sure if paramix is causing the errors for me: goes like > no such file to load -- facets/nullclass > running on latest stuff from everything... > 2006/2/6, George Moschovitis :> Because I am running out of time, I will probably make a custom> version of paramix> in glue and link against 1.0.1. If Tom releases a bug fixed version in> time I will use that instead.>> 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 > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Mon Feb 6 10:57:08 2006 From: transfire at gmail.com (TRANS) Date: Mon, 6 Feb 2006 15:57:08 +0000 Subject: [Nitro] [wiki] Graphist needed In-Reply-To: References: <200602051622.25304.zimba.tm@gmail.com> <200602061339.19374.manveru@weez.co.jp> <200602061047.56900.zimba.tm@gmail.com> Message-ID: <4b6f054f0602060757q2104c12agae95a41cf2a93208@mail.gmail.com> On 2/6/06, George Moschovitis wrote: > Erm... > > I dont think facets should enclose everything ;-) It sort of makes sense if you enclose all of that by Ruby itself. But it's not really set theory here. Block diagrams might be better. Ruby ------------------. V | Facets --- Glue | V V Nitro ---------------------- Og Rough but you get the idea. Or perhaps reverse it, so that ruby is in the center, facets next, then glue ... T. From transfire at gmail.com Mon Feb 6 11:00:08 2006 From: transfire at gmail.com (TRANS) Date: Mon, 6 Feb 2006 16:00:08 +0000 Subject: [Nitro] [wiki] Graphist needed In-Reply-To: <4b6f054f0602060757q2104c12agae95a41cf2a93208@mail.gmail.com> References: <200602051622.25304.zimba.tm@gmail.com> <200602061339.19374.manveru@weez.co.jp> <200602061047.56900.zimba.tm@gmail.com> <4b6f054f0602060757q2104c12agae95a41cf2a93208@mail.gmail.com> Message-ID: <4b6f054f0602060800s8ecc0bbt13156abeba864a4@mail.gmail.com> Also I should point out that Glue is like the "Mega/Calibre/More" part of Facets, but where Facets is kept complety general purpose, Glue is specifically geared torward Nitro/Og. T. From riku.raisanen at walkingwoods.com Mon Feb 6 19:28:04 2006 From: riku.raisanen at walkingwoods.com (Riku =?iso-8859-1?q?R=E4is=E4nen?=) Date: Mon, 6 Feb 2006 18:28:04 -0600 Subject: [Nitro] Dynamic Elements Message-ID: <200602061828.04928.riku.raisanen@walkingwoods.com> First of all, I've managed not to post to ML for this long. I'm Riku R?is?nen (Rayman), a Ruby user from Finland. Now about the idea of dynamic elements: I like the idea of elements. Classes callable in HTML with XHTML. What I don't like, is the fact that the Elements are rendered in compile time ie. they're static. Good for performance, but limits their usage a lot. Currently, elements are meant to - as far as I can tell - to stuff the repeated static HTML parts aside and make them easy to render. Example: <% here_be_dynamic_data %> Now while this is cool, I'd like to make far better use of elemets.. Let's start with an example: Here's the default content, overwritten if Content Element finds some better content from the Models.. umm.. yeah. Can't express myself better :f DynamicMenu and ShoppingCart classes / 'dynamic elements' would be somewhat stand-alone parts of the application. Plugin modules? I don't know the terms that well. At least my dynamic elements would fetch data from Models and possibly over-ride default behaviour according to instance variables set inside Controllers. Other usages: This can be done with elements as they currently are by stuffing ruby code inside the def render of the element: Class ShoppingCart < Nitro::Element def render %~ <% Cart.get_contents.each { .. } %> <% end %> ~ end end However, I've experienced lots of problems with variables not being in Elements scope.. It could be that I'm wrong about this. Since they all reside in Nitro module? (I'm new on most of this stuff.. which is why I'm writing such a long mail and maybe somewhat with a better grasp on nitro and or ruby can help me out). IIRC, session is not in the scope of Element. Elements can access Models. I'm not sure of controllers instance variables.. I think they're accessible as well. IIRC, however, they're all only accessible in def render. Once again, I could be wrong. And probably am. :) (I think it was something like Elements only evaling the ._text property of an Element, meaning the stuff inside of %~~ or any other output. Right?) Now to the main problem: In order to use elements for dynamic content, you basically need to stuff all the logic/code inside of the single def render method. With complex logic in place, the code becomes horrid. And I'd rather use basic ruby syntax and not the <% %> etc. So.. I'd like to have elements with access to session and controllers instance variables both OUTSIDE of def render. This way one could stuff all the logic of, say, a shopping cart inside the element itself. Thus implementing and removing the shopping cart from an application would be very easy. Now.. I could be totally lost here and trying to do something stupid. If this is the case, please point me in a right direction. Any ideas of similar implementation ( the shopping cart etc) are welcome. Yours, Riku R?is?nen From george.moschovitis at gmail.com Mon Feb 6 12:17:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 19:17:30 +0200 Subject: [Nitro] 0.28.0 preview Message-ID: dear devs, in the repository you can find the release candidate of nitro. As this is an important version, please have a look at this and report any final bugs. I will upload the gems to rubyforge, tommorow morning. best regards, George. PS: facets 1.0.2 or 1.0.1 is needed. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Feb 6 13:17:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 6 Feb 2006 20:17:37 +0200 Subject: [Nitro] Nitro + Og 0.28.0: Cacheable, Ruby Query Language, Mongrel, Og cloning 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: A snapshot of the latest developments. As always, cool new features were added, the code is refactored, the security increased and reported bugs fixed. Most notable changes: * New generalized caching system. The caching code is refactored in a new Glue system. At the moment, caches in memory, DRb, filesystem and Og are provided. A memcache version will be available in the near future. The new caching system is used to implement Session stores, Og caching, Fragment caching, and Application scoped parameters. A useful DRb cache management script is provided to manage multiple DRb caches. * Introduced a new Og Cacheable mixin. By including this mixin in your classes you make them eligible to Og caching. Here comes an example: class User is Cachable property :name, String property :age, Fixnum end Cacheable reuses the new generalized caching system to provide various options for distributed caching. At the moment entities (instances of managed classes) are cached by their primary key. * Og now advanced quering using Ruby as the data query language to complement the usage of Ruby as a data definition language and provide an end-to-end Ruby solution. At the moment only supported for the SQL based adapters. Here comes an example: users = User.find do |user| user.age > 10 user.any { name == 'George' name == 'Stella' } end # => SELECT * FROM oguser WHERE (oguser.age > 10 AND (oguser.name = 'George' OR oguser.name = 'Stella')) This feature uses the Caboose/EZ code by Ezra Zygmuntowicz. Pure magic! * Og find now supports prepared statement like syntax: User.find :condition => ['name LIKE ? and create_time > ?', 'g%', Time.now] The interpolated values are automatically escaped to avoid SQL injection attacks. Some additional forms of find are supported: User.find [['name = ? and create_time > ?', 'gmosx', Time.now] User.find "name = 'gmosx'" and more. * Added experimental support for deep copying (cloning) of Og managed objects. This mechanism handles properties (annotated attributes) and some relation types. * Integration of Facets 1.0.1. The new library features a better API and better implementation of various features. * Introduced experimental Mongrel adapter, just use: ruby myapp.rb --mongrel * Fixes in the SCGI/FCGI adapters. * Added schema evolution support to the SQLite adapter. All major Og adapter support automatic schema evolution, ie Og detects common types of changes in your Ruby code to automatically alter the underlying schema for you. * Introduced Og SQLite2 (legacy SQLite) adapter. * Added more test cases, and improved RDoc comments throughout the code. * Many, many bug fixes. 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 + Nitro Development Team -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Mon Feb 6 13:48:15 2006 From: transfire at gmail.com (TRANS) Date: Mon, 6 Feb 2006 18:48:15 +0000 Subject: [Nitro] Nitro + Og 0.28.0: Cacheable, Ruby Query Language, Mongrel, Og cloning In-Reply-To: References: Message-ID: <4b6f054f0602061048w3cef6d77r9f05d8f16234d603@mail.gmail.com> Congrats! On 2/6/06, George Moschovitis wrote: > 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: > > A snapshot of the latest developments. As always, cool new > features were added, the code is refactored, the security increased > and reported bugs fixed. > > Most notable changes: > > * New generalized caching system. The caching code is refactored > in a new Glue system. At the moment, caches in memory, DRb, > filesystem and Og are provided. A memcache version will be available > in the near future. The new caching system is used to implement > Session stores, Og caching, Fragment caching, and Application scoped > parameters. A useful DRb cache management script is provided to > manage multiple DRb caches. > > * Introduced a new Og Cacheable mixin. By including this mixin > in your classes you make them eligible to Og caching. Here comes > an example: > > class User > is Cachable > property :name, String > property :age, Fixnum > end > > Cacheable reuses the new generalized caching system to provide > various options for distributed caching. At the moment entities > (instances of managed classes) are cached by their primary key. > > * Og now advanced quering using Ruby as the data query language > to complement the usage of Ruby as a data definition language > and provide an end-to-end Ruby solution. At the moment only > supported for the SQL based adapters. Here comes an example: > > users = User.find do |user| > user.age > 10 > user.any { > name == 'George' > name == 'Stella' > } > end > > # => SELECT * FROM oguser WHERE (oguser.age > 10 AND (oguser.name = > 'George' OR oguser.name = 'Stella')) > > This feature uses the Caboose/EZ code by Ezra Zygmuntowicz. > Pure magic! > > * Og find now supports prepared statement like syntax: > > User.find :condition => ['name LIKE ? and create_time > ?', 'g%', Time.now] > > The interpolated values are automatically escaped to avoid > SQL injection attacks. > > Some additional forms of find are supported: > > User.find [['name = ? and create_time > ?', 'gmosx', Time.now] > User.find "name = 'gmosx'" > > and more. > > * Added experimental support for deep copying (cloning) of Og > managed objects. This mechanism handles properties (annotated > attributes) and some relation types. > > * Integration of Facets 1.0.1. The new library features a better > API and better implementation of various features. > > * Introduced experimental Mongrel adapter, just use: > > ruby myapp.rb --mongrel > > * Fixes in the SCGI/FCGI adapters. > > * Added schema evolution support to the SQLite adapter. All major > Og adapter support automatic schema evolution, ie Og detects common > types of changes in your Ruby code to automatically alter the > underlying schema for you. > > * Introduced Og SQLite2 (legacy SQLite) adapter. > > * Added more test cases, and improved RDoc comments throughout > the code. > > * Many, many bug fixes. > > > 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 + Nitro Development Team > > > -- > 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 > -- ( o- ??? went BOOM // trans. / / transfire at gmail.com From james_b at neurogami.com Mon Feb 6 14:14:27 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 06 Feb 2006 12:14:27 -0700 Subject: [Nitro] Nitro + Og 0.28.0: Cacheable, Ruby Query Language, Mongrel, Og cloning In-Reply-To: References: Message-ID: <43E7A013.3060802@neurogami.com> George Moschovitis wrote: > 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: > > A snapshot of the latest developments. As always, cool new > features were added, the code is refactored, the security increased > and reported bugs fixed. Outstanding work, George! A big thanks to you and the Og/Nitro dev team. -- 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 Feb 6 20:38:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 6 Feb 2006 17:38:51 -0800 Subject: [Nitro] Bug tracking. Message-ID: Hi all, Pending Trac, how does everyone feel about using the bug tracker on Rubyforge? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060206/62aaed57/attachment.html From bryan.a.soto at gmail.com Mon Feb 6 21:30:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 6 Feb 2006 18:30:47 -0800 Subject: [Nitro] Documentation Survey Message-ID: Hi list, I know everyone can agree that we need docs. So, to figure out what was most important to begin documenting and what type would be most useful, I came up with this. Hope it isn't too weird. In a poker game, as part of the pot you win one hour of a Nitro/Og/Glue developers time. We'll refer to this developer as GM. ;) You decide to have GM spend that 60 minutes writing documentation. Now how would you budget GM's time on the documentation that's most important to you? And what type of docs would you have GM write? As an example, Apache configuration, 15 minutes, examples Aspects, 15 minutes, article Og Relationships, 15 minutes, tutorial Nitro helpers, 15 minutes, RDocs Feel free to add whatever form of documentation you can think of. I only ask that you list each documentation form separately, as Apache configuration, 15 minutes, examples Apache configuration, 15 minutes, article And minutes only please, we don't want to micro-manage him down to the second ;) The premise is, I hope, simple. You don't want to tell GM just to document Nitro, because GM, not knowing any better, will document what he thinks is important, not necessarily what would help you most. You might want GM to spend the full 60 minutes on Apache configuration, for example, to get really good docs on that. I'd like people to reply on the list because I hope people will revise their answers based off of other people responses so we can find out where we'll get the biggest return on our efforts. Anyway, as I said. I hope it isn't too weird an idea. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060206/08c208e8/attachment.html From james_b at neurogami.com Mon Feb 6 22:18:40 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 06 Feb 2006 20:18:40 -0700 Subject: [Nitro] Documentation Survey In-Reply-To: References: Message-ID: <43E81190.6060901@neurogami.com> Nitro templating, 30 minutes, tutorial Og relationships, 30 minutes, tutorial -- James Britt ?Design depends largely on constraints.? ? Charles Eames From riku.raisanen at walkingwoods.com Tue Feb 7 09:44:01 2006 From: riku.raisanen at walkingwoods.com (Riku =?iso-8859-1?q?R=E4is=E4nen?=) Date: Tue, 7 Feb 2006 08:44:01 -0600 Subject: [Nitro] Documentation Survey Message-ID: <200602070844.01510.riku.raisanen@walkingwoods.com> Nitro templating, 20 minutes, RDocs Nitro templating, 10 minutes, examples Default directory/file lookup routes, 10 minutes, article Extending nitro, 10 minutes, examples Nitro helpers, 10 minutes, article -Riku R?is?nen From zimba.tm at gmail.com Tue Feb 7 02:52:45 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 7 Feb 2006 08:52:45 +0100 Subject: [Nitro] scaffolding and part/admin support managed classes in modules Message-ID: <200602070852.45696.zimba.tm@gmail.com> ^^ who will integrate this patch in the repo ? -- Cheers, zimba.tm weblog : http://zimba.oree.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tgz Type: application/x-tgz Size: 6816 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060207/1356646b/attachment.bin From george.moschovitis at gmail.com Tue Feb 7 03:07:00 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 7 Feb 2006 10:07:00 +0200 Subject: [Nitro] BRB, Message-ID: Dear devs, as I have already told you, I will be offline for some time. I tried my best to release 0.28.0 before I leave but there should be some problems. Anyway, the community was quick to provide patches in the past and I am sure everything will work out this time too. I really hope that people like Bryan, Chris, Guill and the rest will stand up and drive the project to even more maturity and maybe some new features. I would like to see the proposed patches integrated in a new 'unofficial' repository so that I can integrate them later to the official repository (as described in earlier posts). If that doesnt work out, we can find another solution. But, most importantly, I would love to be surprised by new developments on this project. Remember, Nitro is an open/free project, we all make it what it is. Moreover, now is a great time to work on issues like: - RDocs - Tutorials - Tests, tests , tests - Small refactorings - Better integration with facets - More examples It was a pleasure working with you, and I am looking forward to be back on this list really soon :) I hope we will have a great new community-powered version to release till then. best regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Feb 7 03:12:25 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 7 Feb 2006 10:12:25 +0200 Subject: [Nitro] More stuff... Message-ID: For anything related to: www.nitrohq.com, the darcs repository, rubyforge etc, or anything else nitro related please contact: Tasos Koutoumanos: drak at navel.gr best regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Feb 7 03:14:12 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 7 Feb 2006 10:14:12 +0200 Subject: [Nitro] Documentation Survey In-Reply-To: References: Message-ID: Oh that poor GM guy ;-) Anyway, Bryan this is a *great* idea. thanks, George. On 2/7/06, Bryan Soto wrote: > Hi list, > > I know everyone can agree that we need docs. So, to figure out what was > most important to begin documenting and what type would be most useful, I > came up with this. Hope it isn't too weird. > > > In a poker game, as part of the pot you win one hour of a Nitro/Og/Glue > developers time. We'll refer to this developer as GM. ;) > > You decide to have GM spend that 60 minutes writing documentation. Now how > would you budget GM's time on the documentation that's most important to > you? And what type of docs would you have GM write? As an example, > > Apache configuration, 15 minutes, examples > > Aspects, 15 minutes, article > > Og Relationships, 15 minutes, tutorial > > Nitro helpers, 15 minutes, RDocs > > > Feel free to add whatever form of documentation you can think of. I only > ask that you list each documentation form separately, as > > Apache configuration, 15 minutes, examples > > Apache configuration, 15 minutes, article > > > And minutes only please, we don't want to micro-manage him down to the > second ;) > > > The premise is, I hope, simple. You don't want to tell GM just to document > Nitro, because GM, not knowing any better, will document what he thinks is > important, not necessarily what would help you most. You might want GM to > spend the full 60 minutes on Apache configuration, for example, to get > really good docs on that. > > I'd like people to reply on the list because I hope people will revise > their answers based off of other people responses so we can find out where > we'll get the biggest return on our efforts. > > Anyway, as I said. I hope it isn't too weird an idea. > > 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 Tue Feb 7 03:15:21 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 7 Feb 2006 10:15:21 +0200 Subject: [Nitro] scaffolding and part/admin support managed classes in modules In-Reply-To: <200602070852.45696.zimba.tm@gmail.com> References: <200602070852.45696.zimba.tm@gmail.com> Message-ID: Chris + Rob ;-) Alternatively you can contact: drak at navel.gr he can integrat this in the official repo. But I would really prefer a separate unofficial repo for your patches. regards, George. On 2/7/06, zimba.tm wrote: > ^^ > > who will integrate this patch in the repo ? > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > > > _______________________________________________ > 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 Tue Feb 7 03:38:47 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 7 Feb 2006 09:38:47 +0100 Subject: [Nitro] BRB, In-Reply-To: References: Message-ID: <200602070938.48106.zimba.tm@gmail.com> On Tuesday 07 February 2006 09:07, George Moschovitis wrote: > Dear devs, > > as I have already told you, I will be offline for some time. I tried > my best to release 0.28.0 before I leave but there should be some > problems. Anyway, the community was quick to provide patches in the > past and I am sure everything will work out this time too. Good luck for what you have to do. How to see you soon :) > I really hope that people like Bryan, Chris, Guill and the rest will > stand up and drive the project to even more maturity and maybe some > new features. I would like to see the proposed patches integrated in a > new 'unofficial' repository so that I can integrate them later to the > official repository (as described in earlier posts). If that doesnt > work out, we can find another solution. But, most importantly, I > would love to be surprised by new developments on this project. > Remember, Nitro is an open/free project, we all make it what it is. I will setup a repository on nitro.oree.ch later today. Is it ok for everyone ? > Moreover, now is a great time to work on issues like: > > - RDocs > - Tutorials > - Tests, tests , tests > - Small refactorings > - Better integration with facets > - More examples I'm going to work on a dynamic Element in contrast to the actual elements which are compiled once. > It was a pleasure working with you, and I am looking forward to be > back on this list really soon :) > I hope we will have a great new community-powered version to release till > then. CU George :) > > best 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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From mneumann at ntecs.de Tue Feb 7 07:20:32 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Tue, 7 Feb 2006 13:20:32 +0100 Subject: [Nitro] (no subject) Message-ID: Hi all, I wanted to try out the newest nitro/og version, but it doesn't work. I always get og/lib/og/entity.rb:434:in `method_missing': undefined local variable or method 'ogmanager' for User:Class. The ogmanger method seems to be no more defined for managed classes. The latest Nitro/Og looks *very* promising. Regards, Michael From reid.thompson at ateb.com Tue Feb 7 08:54:30 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Tue, 07 Feb 2006 08:54:30 -0500 Subject: [Nitro] Documentation Survey In-Reply-To: References: Message-ID: <43E8A696.1090803@ateb.com> George Moschovitis wrote: > Oh that poor GM guy ;-) Anyway, Bryan this is a *great* idea. > > thanks, > George. > > Ditto on the great idea. I've not used vnc2swf, so I'm not sure how much trouble/distraction it is to use, but I think being able to view the development process and usage of Nitro/Og/etc components is very informative ( ala the short vids already on the website). For those that have a good understanding of Nitro/Og/etc, but can't stand to write a doc or tutorial, producing your own video might not be such a terrible task??? Anyway, thanks to all on the list. I'm really impressed by what I'm seeing. reid From mico at docsis.ru Tue Feb 7 09:08:04 2006 From: mico at docsis.ru (Mikhail Shevchuk) Date: Tue, 07 Feb 2006 20:08:04 +0600 Subject: [Nitro] Nitro 0.28 and dependencies Message-ID: <1139321284.8309.6.camel@localhost.localdomain> I just want to know how Nitro community looks at at structure of Nitro as framework. I've noticed that there are 2 new gems (facets_core, facets_more) in it. Is it good or not to make nitro high dependable? From transfire at gmail.com Tue Feb 7 09:32:49 2006 From: transfire at gmail.com (TRANS) Date: Tue, 7 Feb 2006 14:32:49 +0000 Subject: [Nitro] BRB, In-Reply-To: References: Message-ID: <4b6f054f0602070632i59e62f75u2f59ff5a450b39e6@mail.gmail.com> BRB -- Does that stand for Be Right Back? ;-) Enjoy yourself George. T. From transfire at gmail.com Tue Feb 7 09:42:08 2006 From: transfire at gmail.com (TRANS) Date: Tue, 7 Feb 2006 14:42:08 +0000 Subject: [Nitro] Nitro 0.28 and dependencies In-Reply-To: <1139321284.8309.6.camel@localhost.localdomain> References: <1139321284.8309.6.camel@localhost.localdomain> Message-ID: <4b6f054f0602070642n5cc63672qd806964d3e50566a@mail.gmail.com> On 2/7/06, Mikhail Shevchuk wrote: > I just want to know how Nitro community looks at at structure of Nitro > as framework. I've noticed that there are 2 new gems (facets_core, > facets_more) in it. Is it good or not to make nitro high dependable? Actually that should just be one dependency, facets. But Facets itself has two parts. RubyGems was acting up so to get 0.28 out George put just used to the tow parts. I will make an integrated all-in-one Facets release for the next version. Organizing Facets has proven a real pain. One the one hand I have these classes, modules and microframeworks, any of which could be seen as it's own, albeit small, project. And on the other hand I have the vast collection of core method extensions. I have yet to find a way to fit that this together in a wholey satisfactory way, that works with both setup.rb and Rubygems and is suitable to Darcs and the developer-friendly. The facets_core and facets_more is what has thus far come out of working on this. T. From transfire at gmail.com Tue Feb 7 09:43:31 2006 From: transfire at gmail.com (TRANS) Date: Tue, 7 Feb 2006 14:43:31 +0000 Subject: [Nitro] Nitro 0.28 and dependencies In-Reply-To: <4b6f054f0602070642n5cc63672qd806964d3e50566a@mail.gmail.com> References: <1139321284.8309.6.camel@localhost.localdomain> <4b6f054f0602070642n5cc63672qd806964d3e50566a@mail.gmail.com> Message-ID: <4b6f054f0602070643y6f5fb1cdpbb2229127bcfa7b5@mail.gmail.com> s/put just used to the tow parts/just used the two parts/ Honestly I don't know how my words get so screwed up sometimes! T. From zimba.tm at gmail.com Tue Feb 7 10:06:20 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 7 Feb 2006 16:06:20 +0100 Subject: [Nitro] Darcs repo Message-ID: <200602071606.20354.zimba.tm@gmail.com> Hello devs, I have setup a temporary darcs repo while gmosx is away at s http://oree.ch/nitro. Please let me know if you need anything else. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From guillaume.pierronnet at gmail.com Tue Feb 7 10:28:05 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Tue, 7 Feb 2006 16:28:05 +0100 Subject: [Nitro] (no subject) In-Reply-To: References: Message-ID: <6a7d49ca0602070728x33160199u@mail.gmail.com> yes, i have the same problem and i am investigating. Webrick and SCGI works for me but not fastcgi on apache. 2006/2/7, Michael Neumann : > Hi all, > > I wanted to try out the newest nitro/og version, but it doesn't work. > I always get og/lib/og/entity.rb:434:in `method_missing': undefined > local variable or method 'ogmanager' for User:Class. > > The ogmanger method seems to be no more defined for managed classes. > > The latest Nitro/Og looks *very* promising. > > Regards, > > Michael > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From rob at motionpath.com Tue Feb 7 10:51:04 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 07 Feb 2006 15:51:04 +0000 Subject: [Nitro] (no subject) In-Reply-To: <6a7d49ca0602070728x33160199u@mail.gmail.com> References: <6a7d49ca0602070728x33160199u@mail.gmail.com> Message-ID: <1139327464.17039.17.camel@robs-p4> Before calling Nitro.run do: Og.thread_safe = false if ENV['NITRO_INVOKE'] == 'fcgi_proc' On Tue, 2006-02-07 at 16:28 +0100, guillaume pierronnet wrote: > yes, i have the same problem and i am investigating. Webrick and SCGI > works for me but not fastcgi on apache. > > > 2006/2/7, Michael Neumann : > > Hi all, > > > > I wanted to try out the newest nitro/og version, but it doesn't work. > > I always get og/lib/og/entity.rb:434:in `method_missing': undefined > > local variable or method 'ogmanager' for User:Class. > > > > The ogmanger method seems to be no more defined for managed classes. > > > > The latest Nitro/Og looks *very* promising. > > > > Regards, > > > > Michael > > _______________________________________________ > > 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 reid.thompson at ateb.com Tue Feb 7 11:08:18 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Tue, 07 Feb 2006 11:08:18 -0500 Subject: [Nitro] BRB, In-Reply-To: <4b6f054f0602070632i59e62f75u2f59ff5a450b39e6@mail.gmail.com> References: <4b6f054f0602070632i59e62f75u2f59ff5a450b39e6@mail.gmail.com> Message-ID: <43E8C5F2.4050501@ateb.com> TRANS wrote: > BRB -- Does that stand for Be Right Back? ;-) > > Enjoy yourself George. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > naaahhh , stands for "Bring Reid Beer" reid From mneumann at ntecs.de Tue Feb 7 11:55:09 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Tue, 7 Feb 2006 17:55:09 +0100 Subject: [Nitro] (no subject) In-Reply-To: <1139327464.17039.17.camel@robs-p4> References: <6a7d49ca0602070728x33160199u@mail.gmail.com> <1139327464.17039.17.camel@robs-p4> Message-ID: <69F90338-B824-4E66-8DF9-EBCC5ACC1686@ntecs.de> Sorry, I found my error. I didn't noticed that the Og managed classes must be defined before calling Og.setup. Now everything (hopefully) works. Regards, Michael Am 07.02.2006 um 16:51 schrieb Rob Pitt: > Before calling Nitro.run do: > > Og.thread_safe = false if ENV['NITRO_INVOKE'] == 'fcgi_proc' > > On Tue, 2006-02-07 at 16:28 +0100, guillaume pierronnet wrote: >> yes, i have the same problem and i am investigating. Webrick and SCGI >> works for me but not fastcgi on apache. >> >> >> 2006/2/7, Michael Neumann : >>> Hi all, >>> >>> I wanted to try out the newest nitro/og version, but it doesn't >>> work. >>> I always get og/lib/og/entity.rb:434:in `method_missing': undefined >>> local variable or method 'ogmanager' for User:Class. >>> >>> The ogmanger method seems to be no more defined for managed classes. >>> >>> The latest Nitro/Og looks *very* promising. >>> >>> Regards, >>> >>> Michael From guillaume.pierronnet at gmail.com Tue Feb 7 12:06:05 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Tue, 7 Feb 2006 18:06:05 +0100 Subject: [Nitro] (no subject) In-Reply-To: <69F90338-B824-4E66-8DF9-EBCC5ACC1686@ntecs.de> References: <6a7d49ca0602070728x33160199u@mail.gmail.com> <1139327464.17039.17.camel@robs-p4> <69F90338-B824-4E66-8DF9-EBCC5ACC1686@ntecs.de> Message-ID: <6a7d49ca0602070906o3240185ci@mail.gmail.com> btw, are you using fastcgi, acgi or plain cgi ? it seems like there is a bug when changing thread_safe mode 2006/2/7, Michael Neumann : > Sorry, I found my error. I didn't noticed that the Og managed classes > must be defined before calling Og.setup. > Now everything (hopefully) works. > > Regards, > > Michael > > Am 07.02.2006 um 16:51 schrieb Rob Pitt: > > Before calling Nitro.run do: > > > > Og.thread_safe = false if ENV['NITRO_INVOKE'] == 'fcgi_proc' > > > > On Tue, 2006-02-07 at 16:28 +0100, guillaume pierronnet wrote: > >> yes, i have the same problem and i am investigating. Webrick and SCGI > >> works for me but not fastcgi on apache. > >> > >> > >> 2006/2/7, Michael Neumann : > >>> Hi all, > >>> > >>> I wanted to try out the newest nitro/og version, but it doesn't > >>> work. > >>> I always get og/lib/og/entity.rb:434:in `method_missing': undefined > >>> local variable or method 'ogmanager' for User:Class. > >>> > >>> The ogmanger method seems to be no more defined for managed classes. > >>> > >>> The latest Nitro/Og looks *very* promising. > >>> > >>> Regards, > >>> > >>> Michael > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From bryan.a.soto at gmail.com Tue Feb 7 13:18:50 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 7 Feb 2006 10:18:50 -0800 Subject: [Nitro] Darcs repo In-Reply-To: <200602071606.20354.zimba.tm@gmail.com> References: <200602071606.20354.zimba.tm@gmail.com> Message-ID: On 2/7/06, zimba.tm wrote: > > Hello devs, > > I have setup a temporary darcs repo while gmosx is away at s > http://oree.ch/nitro. > > Please let me know if you need anything else. > > Thanks for doing that. :) So what procedure would you like to follow with regards to applying bundles? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060207/70c7767e/attachment.html From bryan.a.soto at gmail.com Tue Feb 7 13:40:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 7 Feb 2006 10:40:36 -0800 Subject: [Nitro] Me missing... In-Reply-To: References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> Message-ID: On 2/5/06, Bryan Soto wrote: > > On 2/5/06, TRANS wrote: > > > > On 2/5/06, George Moschovitis wrote: > > > Trans, please re-release your fixed version as facets 1.0.2. Because > > > if someone has allready the old 1.0.1 in his system, nitro will not > > > work. > > > > Okay. > > > > Any one have any other needed changes to Facets before I release this? > > > > > How about macros in the Lisp facet? ;) > > Seriously though, the only problem I've found is that gem considers the > older version 2005.10.30 to be a higher version number than 1.0.1. I don't > know if it's possible, but if so, it might be a good idea to remove it from > the gems index and maybe leave the archives available as a download > otherwise gem updates will actually downgrade the facets version. > > Hi Trans, Sorry to reply to myself, but there is also a facets version 2005.10.15. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060207/1af3337c/attachment.html From transfire at gmail.com Tue Feb 7 14:09:30 2006 From: transfire at gmail.com (TRANS) Date: Tue, 7 Feb 2006 19:09:30 +0000 Subject: [Nitro] Me missing... In-Reply-To: References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> Message-ID: <4b6f054f0602071109i4994f7d1gb8db583ecdb8781b@mail.gmail.com> On 2/7/06, Bryan Soto wrote: > > Seriously though, the only problem I've found is that gem considers the > older version 2005.10.30 to be a higher version number than 1.0.1. I don't > know if it's possible, but if so, it might be a good idea to remove it from > the gems index and maybe leave the archives available as a download > otherwise gem updates will actually downgrade the facets version. > > > > > > Hi Trans, > > Sorry to reply to myself, but there is also a facets version 2005.10.15. Oh, thanks. I thought that was gone. Hmmm...I wonder if a couple others are still lurking. I'll make sure their all gone. Thanks, T. From aidan at yoyo.org Tue Feb 7 15:13:34 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Wed, 8 Feb 2006 07:13:34 +1100 Subject: [Nitro] Bug tracking (and Documentation Survey) In-Reply-To: References: Message-ID: <010C79FA-E326-45E3-8152-094991C1BC64@yoyo.org> OK - putting my money where my mouth is :-) Over the next week I'm going to take time out from active development of the product I'm working on to write an issue tracker in Og/Nitro. Nitro needs one, my company also happens to need one and it gives me an opportunity to learn Nitro at the same time (I already know Og). Why does this apply to the documentation survey? Well, I'm going to document it all as one big step-by-step tutorial, complete with online and inline docs. If anyone has time to help out, let me know, either by mail or on IRC. I'm 'five' on #nitro on irc.freenode.net, and I'll be using the folks there for reference for Nitro commands. I'll be getting started as soon as this mail is gone. I anticipate taking a week or so to get something that is both usable and a useful tutorial and introduction: it makes for a good alternative to the shopping cart that all the books seem to use. I'll probably use Hieraki to document for now (as used by docs.rubygems.org for instance). In return for taking the time out of product development, I'd really like for my company to be listed on NitroHQ as a proud sponsor of the product - this is how I justify the time away from developing what actually makes the dollars. We can talk about that after I've done the work tho ;-) Aidan http://www.infurious.com On 07/02/2006, at 12:38 PM, Bryan Soto wrote: > Hi all, > > Pending Trac, how does everyone feel about using the bug tracker on > Rubyforge? > > Bryan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From reid.thompson at ateb.com Tue Feb 7 16:27:57 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Tue, 07 Feb 2006 16:27:57 -0500 Subject: [Nitro] Bug tracking (and Documentation Survey) In-Reply-To: <010C79FA-E326-45E3-8152-094991C1BC64@yoyo.org> References: <010C79FA-E326-45E3-8152-094991C1BC64@yoyo.org> Message-ID: <43E910DD.1040306@ateb.com> Aidan Rogers wrote: > OK - putting my money where my mouth is :-) > > Over the next week I'm going to take time out from active development > of the product I'm working on to write an issue tracker in Og/Nitro. > Nitro needs one, my company also happens to need one and it gives me > an opportunity to learn Nitro at the same time (I already know Og). > > Why does this apply to the documentation survey? Well, I'm going to > document it all as one big step-by-step tutorial, complete with > online and inline docs. If anyone has time to help out, let me know, > either by mail or on IRC. I'm 'five' on #nitro on irc.freenode.net, > and I'll be using the folks there for reference for Nitro commands. > > I'll be getting started as soon as this mail is gone. I anticipate > taking a week or so to get something that is both usable and a useful > tutorial and introduction: it makes for a good alternative to the > shopping cart that all the books seem to use. I'll probably use > Hieraki to document for now (as used by docs.rubygems.org for instance). > > In return for taking the time out of product development, I'd really > like for my company to be listed on NitroHQ as a proud sponsor of the > product - this is how I justify the time away from developing what > actually makes the dollars. We can talk about that after I've done > the work tho ;-) > > Aidan > http://www.infurious.com > > Very cool. Looking forward to this. From transfire at gmail.com Tue Feb 7 16:55:45 2006 From: transfire at gmail.com (TRANS) Date: Tue, 7 Feb 2006 21:55:45 +0000 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602071109i4994f7d1gb8db583ecdb8781b@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> <4b6f054f0602071109i4994f7d1gb8db583ecdb8781b@mail.gmail.com> Message-ID: <4b6f054f0602071355p4b041fffgb483a8eac7f8e763@mail.gmail.com> On 2/7/06, TRANS wrote: > Oh, thanks. I thought that was gone. Hmmm...I wonder if a couple > others are still lurking. I'll make sure their all gone. Just got word. They should be all gone now. T. From bryan.a.soto at gmail.com Tue Feb 7 21:02:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 7 Feb 2006 18:02:09 -0800 Subject: [Nitro] Bug tracking (and Documentation Survey) In-Reply-To: <010C79FA-E326-45E3-8152-094991C1BC64@yoyo.org> References: <010C79FA-E326-45E3-8152-094991C1BC64@yoyo.org> Message-ID: On 2/7/06, Aidan Rogers wrote: > > OK - putting my money where my mouth is :-) > > Over the next week I'm going to take time out from active development > of the product I'm working on to write an issue tracker in Og/Nitro. > Nitro needs one, my company also happens to need one and it gives me > an opportunity to learn Nitro at the same time (I already know Og). > > Why does this apply to the documentation survey? Well, I'm going to > document it all as one big step-by-step tutorial, complete with > online and inline docs. If anyone has time to help out, let me know, > either by mail or on IRC. I'm 'five' on #nitro on irc.freenode.net, > and I'll be using the folks there for reference for Nitro commands. > > I'll be getting started as soon as this mail is gone. I anticipate > taking a week or so to get something that is both usable and a useful > tutorial and introduction: it makes for a good alternative to the > shopping cart that all the books seem to use. I'll probably use > Hieraki to document for now (as used by docs.rubygems.org for instance). > > In return for taking the time out of product development, I'd really > like for my company to be listed on NitroHQ as a proud sponsor of the > product - this is how I justify the time away from developing what > actually makes the dollars. We can talk about that after I've done > the work tho ;-) > > Aidan > http://www.infurious.com > > Thanks for doing this Aidan. I look forward to seeing what you come up with. :) Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060207/ec7b799e/attachment.html From zimba.tm at gmail.com Wed Feb 8 03:22:53 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 8 Feb 2006 09:22:53 +0100 Subject: [Nitro] Darcs repo In-Reply-To: References: <200602071606.20354.zimba.tm@gmail.com> Message-ID: <200602080922.53033.zimba.tm@gmail.com> On Tuesday 07 February 2006 19:18, Bryan Soto wrote: > On 2/7/06, zimba.tm wrote: > > Hello devs, > > > > I have setup a temporary darcs repo while gmosx is away at s > > http://oree.ch/nitro. > > > > Please let me know if you need anything else. > > Thanks for doing that. :) > > So what procedure would you like to follow with regards to applying > bundles? > > Bryan I don't know darcs enough to know how to give commit access over http. If you have any knowledge in this it is highly appreciated. In the meanwhile, just send me your patches trough to this list or directly. Like you want. Any suggestions ? -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Wed Feb 8 15:53:07 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 8 Feb 2006 21:53:07 +0100 Subject: [Nitro] [oree.ch] Patchset #1 Message-ID: <200602082153.07684.zimba.tm@gmail.com> Hello devs, I have put some changes in my own nitro repo at http://oree.ch/nitro. Here are the changes : * part/admin : sorting of managed classes and system configuration Self explanatory I think. * scaffolding and part/admin support managed classes in modules Scaffolding had some problems with classes that are in modules. Now you can scaffold eg. Video::Stream without problem. TODO : there is still a problem if you have a root Video for example. Because then video/stream looks for streams that are in Video relation and not the Video::Stream class. (look in the spark admin, WikiPage::Revision has a problem because WikiPage is also there) FIXME : some links are in the form of wiki_page__revisions instead of wiki_page/revisions * Implemented a new Control system : Form Control moved in Nitro::Form, added a Controls transformer, Nitro::Action is a generic action = Make your own controls : class MyControl < Nitro::Control def template %~~ end end = In your template : the value is evaled in the controller, so you can import your own values = Build dynamic controls : class Test def to_s "heyhey" end end Nitro::DynamicControl.map[Test] = MyControl = In your action @test = Test.new = In your template = Gives THE_END inputs are welcom :) -- Cheers, zimba.tm weblog : http://zimba.oree.ch From bryan.a.soto at gmail.com Wed Feb 8 16:25:45 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 8 Feb 2006 13:25:45 -0800 Subject: [Nitro] Darcs repo In-Reply-To: <200602080922.53033.zimba.tm@gmail.com> References: <200602071606.20354.zimba.tm@gmail.com> <200602080922.53033.zimba.tm@gmail.com> Message-ID: On 2/8/06, zimba.tm wrote: > > On Tuesday 07 February 2006 19:18, Bryan Soto wrote: > > On 2/7/06, zimba.tm wrote: > > > Hello devs, > > > > > > I have setup a temporary darcs repo while gmosx is away at s > > > http://oree.ch/nitro. > > > > > > Please let me know if you need anything else. > > > > Thanks for doing that. :) > > > > So what procedure would you like to follow with regards to applying > > bundles? > > > > Bryan > > I don't know darcs enough to know how to give commit access over http. If > you > have any knowledge in this it is highly appreciated. I think you can do it via email. I don't know how. I'm new to darcs. In the meanwhile, just send me your patches trough to this list or directly. > Like you want. > > Any suggestions ? Let's just stick with the list for now then. Might be fun to have more than one repository. Motionpath can host the stable bugfix version and you can host the real glycerin. :) -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > 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/20060208/0cd2f8b2/attachment.html From bryan.a.soto at gmail.com Wed Feb 8 16:28:41 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 8 Feb 2006 13:28:41 -0800 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602082153.07684.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> Message-ID: So you liked Rayman's idea of dynamic controls to. I'll be interested in trying these out. Good work! Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060208/53232e21/attachment.html From zimba.tm at gmail.com Wed Feb 8 16:33:54 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 8 Feb 2006 22:33:54 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> Message-ID: <200602082233.54686.zimba.tm@gmail.com> On Wednesday 08 February 2006 22:28, Bryan Soto wrote: > So you liked Rayman's idea of dynamic controls to. I'll be interested in > trying these out. > > Good work! > > Bryan Yes it was an interesting approach between wee and nitro's templating system. I still have to mesure the impact on the performances but I think it's pretty good. BTW : The repo is down for a while because of system upgrades. It will be back in 2-3 hours. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From bryan.a.soto at gmail.com Wed Feb 8 16:38:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 8 Feb 2006 13:38:08 -0800 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602082233.54686.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602082233.54686.zimba.tm@gmail.com> Message-ID: On 2/8/06, zimba.tm wrote: > > Yes it was an interesting approach between wee and nitro's templating > system. > I still have to mesure the impact on the performances but I think it's > pretty > good. > > BTW : > > The repo is down for a while because of system upgrades. It will be back > in > 2-3 hours. > Glad I updated right after I read your email then. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060208/289fc8bd/attachment.html From zimba.tm at gmail.com Wed Feb 8 18:16:52 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 9 Feb 2006 00:16:52 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> <200602082233.54686.zimba.tm@gmail.com> Message-ID: <200602090016.52647.zimba.tm@gmail.com> On Wednesday 08 February 2006 22:38, Bryan Soto wrote: > On 2/8/06, zimba.tm wrote: > > Yes it was an interesting approach between wee and nitro's templating > > system. > > I still have to mesure the impact on the performances but I think it's > > pretty > > good. > > > > BTW : > > > > The repo is down for a while because of system upgrades. It will be back > > in > > 2-3 hours. > > Glad I updated right after I read your email then. ;) Heh :-) repo is back -- Cheers, zimba.tm weblog : http://zimba.oree.ch From mico at docsis.ru Wed Feb 8 18:53:59 2006 From: mico at docsis.ru (Mikhail Shevchuk) Date: Thu, 09 Feb 2006 05:53:59 +0600 Subject: [Nitro] AJAX examples Message-ID: <1139442839.13977.8.camel@localhost.localdomain> It is said here http://www.nitrohq.com/view/Nitro_Examples that there is an examples/ajax. But there is no one in examples-0.28 From bryan.a.soto at gmail.com Wed Feb 8 18:53:49 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 8 Feb 2006 15:53:49 -0800 Subject: [Nitro] AJAX examples In-Reply-To: <1139442839.13977.8.camel@localhost.localdomain> References: <1139442839.13977.8.camel@localhost.localdomain> Message-ID: On 2/8/06, Mikhail Shevchuk wrote: > > It is said here http://www.nitrohq.com/view/Nitro_Examples that there is > an examples/ajax. But there is no one in examples-0.28 > > Hi, That's out of date. Thanks for catching. I believe the flickr example is the new Ajax example. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060208/506aec3e/attachment.html From m.fellinger at gmail.com Wed Feb 8 20:19:23 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 9 Feb 2006 10:19:23 +0900 Subject: [Nitro] AJAX examples In-Reply-To: References: <1139442839.13977.8.camel@localhost.localdomain> Message-ID: <9c00d3e00602081719w690350bck@mail.gmail.com> yeah, there is no AJAX-example anymore, it was replaced by theflickr-example wich shows all of the AJAX-features that were in theold example and a little bit more (most outstanding is the niceexample of using the RPC-requests).However, i will update the wiki to reflect that, thanks for pointing it out. ~~~~manveru 2006/2/9, Bryan Soto :> On 2/8/06, Mikhail Shevchuk wrote:> > It is said here> http://www.nitrohq.com/view/Nitro_Examples that there is> > an examples/ajax. But there is no one in examples-0.28> >> >>> Hi,>> That's out of date. Thanks for catching. I believe the flickr example is> the new Ajax example.>> Bryan>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general>> From m.fellinger at gmail.com Wed Feb 8 21:15:33 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 9 Feb 2006 11:15:33 +0900 Subject: [Nitro] AJAX examples In-Reply-To: <9c00d3e00602081719w690350bck@mail.gmail.com> References: <1139442839.13977.8.camel@localhost.localdomain> <9c00d3e00602081719w690350bck@mail.gmail.com> Message-ID: <9c00d3e00602081815u68d86436s@mail.gmail.com> ok, it looks like we have got some problems to keep the wiki up to date.editing the page doesn't affect the original pagehttp://www.nitrohq.com/view/Nitro_Examples buthttp://www.nitrohq.com/view/Nitro+Examples - however, i cannot changeNitro_Examples to link to the other one, so we always have a wrongversion flying around.It seems like there's a problem with the cgi-en/decoding. Somebody hasto fix that.Another thing i noticed is that it might have been a side-effect ofprevious porting to a new version of spark.I think we should get all the content off of the page, upgrade Sparkproperly again and reinput everything. one way or another, we have tomake the page working again. ~~~~manveru 2006/2/9, Michael Fellinger :> yeah, there is no AJAX-example anymore, it was replaced by the> flickr-example wich shows all of the AJAX-features that were in the> old example and a little bit more (most outstanding is the nice> example of using the RPC-requests).> However, i will update the wiki to reflect that, thanks for pointing it out.>> ~~~~manveru>> 2006/2/9, Bryan Soto :> > On 2/8/06, Mikhail Shevchuk wrote:> > > It is said here> > http://www.nitrohq.com/view/Nitro_Examples that there is> > > an examples/ajax. But there is no one in examples-0.28> > >> > >> >> > Hi,> >> > That's out of date. Thanks for catching. I believe the flickr example is> > the new Ajax example.> >> > Bryan> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> From mico at docsis.ru Wed Feb 8 21:25:53 2006 From: mico at docsis.ru (Mikhail Shevchuk) Date: Thu, 09 Feb 2006 08:25:53 +0600 Subject: [Nitro] example/gallery Message-ID: <1139451954.13977.16.camel@localhost.localdomain> I tried to run gallery example but I caught internal server error: undefined method `put_store' for nil:NilClass on webrick starting I there is some errors in log: ... E, [2006-02-09T08:15:31.308383 #21115] ERROR -- : Ruby-Sqlite3 bindings are not installed! E, [2006-02-09T08:15:31.308656 #21115] ERROR -- : no such file to load -- sqlite3 (LoadError) ... I am using Ubuntu and installed sqlite-ruby through packet manager. When I install sqlite3-ruby gem I got this error: extconf.rb:1:in `require': no such file to load -- mkmf (LoadError) from extconf.rb:1 How can I fix it? From m.fellinger at gmail.com Wed Feb 8 21:29:54 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 9 Feb 2006 11:29:54 +0900 Subject: [Nitro] example/gallery In-Reply-To: <1139451954.13977.16.camel@localhost.localdomain> References: <1139451954.13977.16.camel@localhost.localdomain> Message-ID: <9c00d3e00602081829h739e30ebj@mail.gmail.com> that's a common problem, just do sudo apt-get install ruby1.8-dev libsqlite3-dev swigsudo gem install sqlite3-ruby this should give you a fully working sqlite3-binding on ubuntu, theswig is neccecary to avoid a really nasty problem with segfaults... ~~~~manveru 2006/2/9, Mikhail Shevchuk :> I tried to run gallery example but I caught internal server error:>> undefined method `put_store' for nil:NilClass>> on webrick starting I there is some errors in log:> ...> E, [2006-02-09T08:15:31.308383 #21115] ERROR -- : Ruby-Sqlite3 bindings> are not installed!> E, [2006-02-09T08:15:31.308656 #21115] ERROR -- : no such file to load> -- sqlite3 (LoadError)> ...>> I am using Ubuntu and installed sqlite-ruby through packet manager. When> I install sqlite3-ruby gem I got this error:> extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)> from extconf.rb:1> How can I fix it?>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From transfire at gmail.com Wed Feb 8 21:46:13 2006 From: transfire at gmail.com (TRANS) Date: Thu, 9 Feb 2006 02:46:13 +0000 Subject: [Nitro] Facets #use Message-ID: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> In the previous version of Facets thought to offer a more robust way of loading facet methods. Eg. require 'facets' Time.use Facets, :stamp That didn't seem to go over so well with some people. So I left it out this version and stuck to the original way: require 'facet/time/stamp' Someones asked about. What are others take on this? Thanks, T. From guillaume.pierronnet at gmail.com Thu Feb 9 08:43:10 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Thu, 9 Feb 2006 14:43:10 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602090016.52647.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602082233.54686.zimba.tm@gmail.com> <200602090016.52647.zimba.tm@gmail.com> Message-ID: <6a7d49ca0602090543h25e6358fk@mail.gmail.com> hi zimba, i got some fixes for nitro, would you like to include them into your repo, in order to synchronize the patches ? thanks! 2006/2/9, zimba.tm : > On Wednesday 08 February 2006 22:38, Bryan Soto wrote: > > On 2/8/06, zimba.tm wrote: > > > Yes it was an interesting approach between wee and nitro's templating > > > system. > > > I still have to mesure the impact on the performances but I think it's > > > pretty > > > good. > > > > > > BTW : > > > > > > The repo is down for a while because of system upgrades. It will be back > > > in > > > 2-3 hours. > > > > Glad I updated right after I read your email then. ;) > > Heh :-) > > repo is back > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > 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.gz Type: application/x-gzip Size: 7003 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060209/dda8d54d/attachment.gz From zimba.tm at gmail.com Thu Feb 9 13:26:07 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 9 Feb 2006 19:26:07 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <6a7d49ca0602090543h25e6358fk@mail.gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602090016.52647.zimba.tm@gmail.com> <6a7d49ca0602090543h25e6358fk@mail.gmail.com> Message-ID: <200602091926.07216.zimba.tm@gmail.com> Hi Guillaume, Sure. Can you make a description of your patches for the list ? In the meanwhile, I will commit them tomorrow. Btw. Does somebody know why the official wiki doesn't change ? I have modified the repo page but I don't get the html update. On Thursday 09 February 2006 14:43, guillaume pierronnet wrote: > hi zimba, > > i got some fixes for nitro, would you like to include them into your > repo, in order to synchronize the patches ? > > thanks! > > 2006/2/9, zimba.tm : > > On Wednesday 08 February 2006 22:38, Bryan Soto wrote: > > > On 2/8/06, zimba.tm wrote: > > > > Yes it was an interesting approach between wee and nitro's templating > > > > system. > > > > I still have to mesure the impact on the performances but I think > > > > it's pretty > > > > good. > > > > > > > > BTW : > > > > > > > > The repo is down for a while because of system upgrades. It will be > > > > back in > > > > 2-3 hours. > > > > > > Glad I updated right after I read your email then. ;) > > > > Heh :-) > > > > repo is back > > > > -- > > Cheers, > > zimba.tm > > > > weblog : http://zimba.oree.ch > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general -- Cheers, zimba.tm weblog : http://zimba.oree.ch From bryan.a.soto at gmail.com Thu Feb 9 13:30:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 9 Feb 2006 10:30:24 -0800 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602091926.07216.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602090016.52647.zimba.tm@gmail.com> <6a7d49ca0602090543h25e6358fk@mail.gmail.com> <200602091926.07216.zimba.tm@gmail.com> Message-ID: On 2/9/06, zimba.tm wrote: > > Hi Guillaume, > > Sure. Can you make a description of your patches for the list ? In the > meanwhile, I will commit them tomorrow. > > Btw. Does somebody know why the official wiki doesn't change ? I have > modified > the repo page but I don't get the html update. > > I don't know. Manveru noticed that also. We'll probably have to contact Tazos(sp?) through Navel on that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060209/a441e68a/attachment.html From guillaume.pierronnet at gmail.com Thu Feb 9 14:26:53 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Thu, 9 Feb 2006 20:26:53 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> <200602090016.52647.zimba.tm@gmail.com> <6a7d49ca0602090543h25e6358fk@mail.gmail.com> <200602091926.07216.zimba.tm@gmail.com> Message-ID: <6a7d49ca0602091126la808372p@mail.gmail.com> here is a summary of my bundle of patches: Thu Feb 9 14:18:00 CET 2006 Guillaume Pierronnet * security fixes on ./og/lib/og/store/sql.rb Thu Feb 9 14:17:40 CET 2006 Guillaume Pierronnet * littles improvements on nitro/helper/table.rb Thu Feb 9 14:15:40 CET 2006 Guillaume Pierronnet * bugfix: autoreload messages sent to Logger instead of STDERR Wed Feb 8 13:35:28 CET 2006 Guillaume Pierronnet * supplementary check on calling Og.thread_safe Tue Feb 7 17:56:46 CET 2006 Guillaume Pierronnet * bugfix: on-the-fly Og.thread_safe mode changing 2006/2/9, Bryan Soto : > On 2/9/06, zimba.tm wrote: > > Hi Guillaume, > > > > Sure. Can you make a description of your patches for the list ? In the > > meanwhile, I will commit them tomorrow. > > > > Btw. Does somebody know why the official wiki doesn't change ? I have > modified > > the repo page but I don't get the html update. > > > > > > I don't know. Manveru noticed that also. We'll probably have to contact > Tazos(sp?) through Navel on that. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From aidan at yoyo.org Thu Feb 9 17:47:43 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 10 Feb 2006 09:47:43 +1100 Subject: [Nitro] Reviewers needed Message-ID: Hi all, As I mentioned earlier in the week, I'm writing a tutorial for Og/ Nitro. This has actually turned into something more resembling a book, so I'd like a few volunteers to review and give me feedback as I go. If you're interested, drop me a mail off-list, and I'll send you the zip file after each iteration for comments. In this way, I can get constant feedback as I go, rather than getting it all at the end. Thanks, Aidan From bryan.a.soto at gmail.com Thu Feb 9 20:49:38 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 9 Feb 2006 17:49:38 -0800 Subject: [Nitro] Documentation Survey In-Reply-To: <43E8A696.1090803@ateb.com> References: <43E8A696.1090803@ateb.com> Message-ID: Hi, If anyone has an entry to make or would like to revise, please do. I'd like to run this for another 24 hours or so. Results so far: Nitro Development - Screencasts 33.33% Nitro Templating - Tutorial, Rdocs, Examples 33.33% Og Relationships - Tutorial 16.67% File Lookup routes - Article 5.56% Extending Nitro - Examples 5.56% Nitro Helpers - Article 5.56% -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060209/52f78d1c/attachment.html From transfire at gmail.com Thu Feb 9 21:18:38 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 02:18:38 +0000 Subject: [Nitro] Og Revisted Message-ID: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> I'd like work on improving Og according to some of the ideas here: http://www.nitrohq.com/view/OgRevisited The first part is to change the way a class gets enchanted ("ogified"). Right now a class in _usually_ enchanted when the #property method is used. There are a few draw backs to this. Firstly, it is inefficent b/c every time the property method is called it has to first check to see if the class is already enchanted or not. Also, it's not 100% consistant because some people have reported cases when a class needs to be enchanted though the #property method hasn't been used. And though it's nice when things seem automatic, in this case being explict about which class are enchanted is a much better thing, making it easier to maintain the code. Also it will greatly reduce some complexity in parts of the Og code and improve run times a bit. So what do others think? Also, what alternatives, modifications, or other suggestions with regard to this (the Setup section on the wiki page) does anyone have? T. From rainhead at gmail.com Thu Feb 9 23:04:08 2006 From: rainhead at gmail.com (Peter Abrahamsen) Date: Thu, 9 Feb 2006 22:04:08 -0600 Subject: [Nitro] Documentation Survey In-Reply-To: References: Message-ID: Sorry, I guess I missed this. Nitro API / helpers, 30 minutes, good rdocs Javascript library integration, 10 minutes, examples Apache config, 5 minutes, examples Og relationships, 15 minutes, examples / diagrams / generated SQL This is enough for people to get enough of a grip on Nitro/Og to become part of the documentation workforce, while also making sure we keep attracting new people to the project. 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/20060209/a5e1f5d2/attachment.bin From manveru at weez.co.jp Thu Feb 9 23:14:55 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Fri, 10 Feb 2006 13:14:55 +0900 Subject: [Nitro] Og Revisted In-Reply-To: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> Message-ID: <200602101314.56362.manveru@weez.co.jp> Hey Trans, Well, changing enchanting is really a big deal. I have got used to the magic nitro does - on the other hand it might be better to make everything a bit more stable - it's an opportunity to get back to attr_accessor and making classes more generic and useable for other ruby-programs to use. The ideal is, as always, a compromise between both. I understand that enchanting has some real drawbacks in performance and also the endless checking if the classes are enchantet already influenced the readability of the og-code in a bad way. Still it is one thing less to think about while working with og, you just make a class - restart and voila, there you go. So, how about following: def require_og_models(*models) snapshot_pre = [] snapshot_post = [] ObjectSpace.each_object{|o| snapshot_pre << o} models.each{|m| require(m)} ObjectSpace.each_object{|o| snapshot_post << o} enchant(snapshot_post-snapshot_pre) end require_og_models "model.rb" i think this is a really elegant way to handle it. We could check the objectspace before and afterwards - enchanting the classes that came in after the wrap of require. I'm not sure everybody likes it, but it looks like this could be a way to do everything more elegant (code in og, code in the app), getting rid of 'property' (an issue for some people who use it with glib), and getting a real performance-boost as well. This is of course only some random code - i don't think it's as easy as that - but it would be nice if it was :) additional this gives us the option to manually enchant them, using require 'model.rb' enchant(Foo, Bar, FooBar) wich makes a nice reuse of the (not yet existent) enchant-method... Now, please click on your reply-buttons and critizise that idea down to something that really works - this was only an idea i had :) ~~~~manveru Am Friday 10 February 2006 11:18 schrieb TRANS: > I'd like work on improving Og according to some of the ideas here: > > http://www.nitrohq.com/view/OgRevisited > > The first part is to change the way a class gets enchanted > ("ogified"). Right now a class in _usually_ enchanted when the > #property method is used. There are a few draw backs to this. Firstly, > it is inefficent b/c every time the property method is called it has > to first check to see if the class is already enchanted or not. Also, > it's not 100% consistant because some people have reported cases when > a class needs to be enchanted though the #property method hasn't been > used. And though it's nice when things seem automatic, in this case > being explict about which class are enchanted is a much better thing, > making it easier to maintain the code. Also it will greatly reduce > some complexity in parts of the Og code and improve run times a bit. > > So what do others think? Also, what alternatives, modifications, or > other suggestions with regard to this (the Setup section on the wiki > page) does anyone have? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From manveru at weez.co.jp Thu Feb 9 23:18:31 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Fri, 10 Feb 2006 13:18:31 +0900 Subject: [Nitro] Documentation Survey In-Reply-To: References: Message-ID: <200602101318.33659.manveru@weez.co.jp> Oh, didn't post here, just prepared to do it... so here's my wishlist :) Simple Wiki (model, scaffolding, templates, redcloth...), 50 minutes, tutorial Lighttpd config, 10 minutes, examples not much, but it would cover everything we (aehm, i) need. ~~~~manveru Am Tuesday 07 February 2006 11:30 schrieb Bryan Soto: > Hi list, > > I know everyone can agree that we need docs. So, to figure out what was > most important to begin documenting and what type would be most useful, I > came up with this. Hope it isn't too weird. > > > In a poker game, as part of the pot you win one hour of a Nitro/Og/Glue > developers time. We'll refer to this developer as GM. ;) > > You decide to have GM spend that 60 minutes writing documentation. Now how > would you budget GM's time on the documentation that's most important to > you? And what type of docs would you have GM write? As an example, > > Apache configuration, 15 minutes, examples > > Aspects, 15 minutes, article > > Og Relationships, 15 minutes, tutorial > > Nitro helpers, 15 minutes, RDocs > > > Feel free to add whatever form of documentation you can think of. I only > ask that you list each documentation form separately, as > > Apache configuration, 15 minutes, examples > > Apache configuration, 15 minutes, article > > > And minutes only please, we don't want to micro-manage him down to the > second ;) > > > The premise is, I hope, simple. You don't want to tell GM just to document > Nitro, because GM, not knowing any better, will document what he thinks is > important, not necessarily what would help you most. You might want GM to > spend the full 60 minutes on Apache configuration, for example, to get > really good docs on that. > > I'd like people to reply on the list because I hope people will revise > their answers based off of other people responses so we can find out where > we'll get the biggest return on our efforts. > > Anyway, as I said. I hope it isn't too weird an idea. > > Bryan From aidan at yoyo.org Fri Feb 10 00:08:24 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 10 Feb 2006 16:08:24 +1100 Subject: [Nitro] Documentation Survey In-Reply-To: <200602101318.33659.manveru@weez.co.jp> References: <200602101318.33659.manveru@weez.co.jp> Message-ID: <0AA234E4-D693-4B26-86C4-4509B6AC72E3@yoyo.org> Does it have to be a Wiki? I'm writing a bug tracker for the tutorial :-) my 60 minutes would be spent thusly: - Nitro Quick Start, 30 mins, tutorial/example (i.e. show how Nitro is as rapid or more rapid than rails) - Ajax features, 30 mins, tutorial/example (the Flickr video was an appetite whetter, this is more information along those lines) I've been reading the "Agile Web Development with Rails" book by the two Daves, and I'm pretty sure I/we could produce something of equal quality and quantity for Nitro. Aidan --- http://www.infurious.com On 10/02/2006, at 3:18 PM, Michael Fellinger wrote: > Simple Wiki (model, scaffolding, templates, redcloth...), 50 > minutes, tutorial > Lighttpd config, 10 minutes, examples From rob at motionpath.com Fri Feb 10 03:58:53 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 10 Feb 2006 08:58:53 +0000 Subject: [Nitro] Facets #use In-Reply-To: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> Message-ID: <1139561933.3009.26.camel@robs-p4> I like the original way. On Thu, 2006-02-09 at 02:46 +0000, TRANS wrote: > In the previous version of Facets thought to offer a more robust way > of loading facet methods. Eg. > > require 'facets' > > Time.use Facets, :stamp > > That didn't seem to go over so well with some people. So I left it out > this version and stuck to the original way: > > require 'facet/time/stamp' > > Someones asked about. What are others take on this? > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Fri Feb 10 04:25:07 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 10 Feb 2006 09:25:07 +0000 Subject: [Nitro] Og Revisted In-Reply-To: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> Message-ID: <1139563507.3009.39.camel@robs-p4> I do not like those ideas at all. I do not agree that by default instance variables used in the constructor should be database driven. I do not think the automated enchanting of property creates too much of a CPU drain, much worse are things like the pre-compiling of scaffold templates (what is the point?). I am not a fan of annotations either but I recognise I may be alone in this last point. If you want to reduce the complexity of the code, it wouldn't be hard to do this within the existing syntax as a framework. If you wish to have a way of explicitly specifying which classes to enchant (ignoring the obvious that property as a keyword is an explicit way of specifying a class to be managed), I would suggest something more like: class Address include Og::Model og_property :address_1, String og_related :belongs_to, Employee end On Fri, 2006-02-10 at 02:18 +0000, TRANS wrote: > I'd like work on improving Og according to some of the ideas here: > > http://www.nitrohq.com/view/OgRevisited > > The first part is to change the way a class gets enchanted > ("ogified"). Right now a class in _usually_ enchanted when the > #property method is used. There are a few draw backs to this. Firstly, > it is inefficent b/c every time the property method is called it has > to first check to see if the class is already enchanted or not. Also, > it's not 100% consistant because some people have reported cases when > a class needs to be enchanted though the #property method hasn't been > used. And though it's nice when things seem automatic, in this case > being explict about which class are enchanted is a much better thing, > making it easier to maintain the code. Also it will greatly reduce > some complexity in parts of the Og code and improve run times a bit. > > So what do others think? Also, what alternatives, modifications, or > other suggestions with regard to this (the Setup section on the wiki > page) does anyone have? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From zimba.tm at gmail.com Fri Feb 10 05:29:00 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 10 Feb 2006 11:29:00 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <6a7d49ca0602091126la808372p@mail.gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <6a7d49ca0602091126la808372p@mail.gmail.com> Message-ID: <200602101129.00488.zimba.tm@gmail.com> Thank you, patch applied On Thursday 09 February 2006 20:26, guillaume pierronnet wrote: > here is a summary of my bundle of patches: > > Thu Feb 9 14:18:00 CET 2006 Guillaume Pierronnet > > * security fixes on ./og/lib/og/store/sql.rb > > Thu Feb 9 14:17:40 CET 2006 Guillaume Pierronnet > > * littles improvements on nitro/helper/table.rb > > Thu Feb 9 14:15:40 CET 2006 Guillaume Pierronnet > > * bugfix: autoreload messages sent to Logger instead of STDERR > > Wed Feb 8 13:35:28 CET 2006 Guillaume Pierronnet > > * supplementary check on calling Og.thread_safe > > Tue Feb 7 17:56:46 CET 2006 Guillaume Pierronnet > > * bugfix: on-the-fly Og.thread_safe mode changing > > 2006/2/9, Bryan Soto : > > On 2/9/06, zimba.tm wrote: > > > Hi Guillaume, > > > > > > Sure. Can you make a description of your patches for the list ? In the > > > meanwhile, I will commit them tomorrow. > > > > > > Btw. Does somebody know why the official wiki doesn't change ? I have > > > > modified > > > > > the repo page but I don't get the html update. > > > > I don't know. Manveru noticed that also. We'll probably have to contact > > Tazos(sp?) through Navel on that. > > > > _______________________________________________ > > 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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From epiperak at gmail.com Fri Feb 10 05:49:59 2006 From: epiperak at gmail.com (Emmanouil Piperakis) Date: Fri, 10 Feb 2006 19:49:59 +0900 Subject: [Nitro] Og Revisted In-Reply-To: <1139563507.3009.39.camel@robs-p4> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> <1139563507.3009.39.camel@robs-p4> Message-ID: I am not the web devel expert, but let me put just a small piece of advice... I believe Nitro/Og should stay as is, conceptually for the moment. George had/has an idea and a lot of reason for this idea. He should be advised for any large scale changes. Additions should be welcomed as long as they do not de-RAIL Nitro/Og (hehe... nice) from its original purpose. The major disadvantage (I do not need to mention the tones of advantages, they are obvious) of having many developers working on the same idea is that rarely a complete consensus on the idea is reached. In that case a hierarchy in the decission process always helps. I suggest that we / you / everyone plan new changes / upgrades for Nitro/Og and even implement them, but let George decide what should be incorperated. :-/ Just my opinion... E.P. On 2/10/06, Rob Pitt wrote: > > I do not like those ideas at all. I do not agree that by default > instance variables used in the constructor should be database driven. I > do not think the automated enchanting of property creates too much of a > CPU drain, much worse are things like the pre-compiling of scaffold > templates (what is the point?). I am not a fan of annotations either but > I recognise I may be alone in this last point. > > If you want to reduce the complexity of the code, it wouldn't be hard to > do this within the existing syntax as a framework. If you wish to have a > way of explicitly specifying which classes to enchant (ignoring the > obvious that property as a keyword is an explicit way of specifying a > class to be managed), I would suggest something more like: > > class Address > include Og::Model > og_property :address_1, String > og_related :belongs_to, Employee > end > > On Fri, 2006-02-10 at 02:18 +0000, TRANS wrote: > > I'd like work on improving Og according to some of the ideas here: > > > > http://www.nitrohq.com/view/OgRevisited > > > > The first part is to change the way a class gets enchanted > > ("ogified"). Right now a class in _usually_ enchanted when the > > #property method is used. There are a few draw backs to this. Firstly, > > it is inefficent b/c every time the property method is called it has > > to first check to see if the class is already enchanted or not. Also, > > it's not 100% consistant because some people have reported cases when > > a class needs to be enchanted though the #property method hasn't been > > used. And though it's nice when things seem automatic, in this case > > being explict about which class are enchanted is a much better thing, > > making it easier to maintain the code. Also it will greatly reduce > > some complexity in parts of the Og code and improve run times a bit. > > > > So what do others think? Also, what alternatives, modifications, or > > other suggestions with regard to this (the Setup section on the wiki > > page) does anyone have? > > > > T. > > > > _______________________________________________ > > 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/20060210/e359a58a/attachment.html From transfire at gmail.com Fri Feb 10 08:50:13 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 13:50:13 +0000 Subject: [Nitro] Og Revisted In-Reply-To: <1139563507.3009.39.camel@robs-p4> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> <1139563507.3009.39.camel@robs-p4> Message-ID: <4b6f054f0602100550n25714c6dy11a24d3e2a2a518d@mail.gmail.com> On 2/10/06, Rob Pitt wrote: > I do not like those ideas at all. I do not agree that by default > instance variables used in the constructor should be database driven. I agree with that. I should have beem more clear about that. At this time I'm not advocating any idea there excapet the enchant property issue. (i.e. take each item one at a time and decided about it) > I do not think the automated enchanting of property creates too much of a > CPU drain, It' not _just_ that though. That just one factor among a others. While it ceratinly not a major CPU drain, it another contributing factor. > much worse are things like the pre-compiling of scaffold > templates (what is the point?). I am not a fan of annotations either but > I recognise I may be alone in this last point. How do propose we specify meta-info without annotations? > If you want to reduce the complexity of the code, it wouldn't be hard to > do this within the existing syntax as a framework. If you wish to have a > way of explicitly specifying which classes to enchant (ignoring the > obvious that property as a keyword is an explicit way of specifying a > class to be managed), I would suggest something more like: > > class Address > include Og::Model > og_property :address_1, String > og_related :belongs_to, Employee > end Yes, #include is the traditional way to do it. And in effect that's exactly what happens. But I think the idea presented on the wiki page for being able to do it from the outseide is better b/c it allows the class to stay clean, which is in the spirit of Og. And it allows a very nice convience for enchanting many classes at once via a module container. T. From transfire at gmail.com Fri Feb 10 08:58:02 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 13:58:02 +0000 Subject: [Nitro] Og Revisted In-Reply-To: References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> <1139563507.3009.39.camel@robs-p4> Message-ID: <4b6f054f0602100558o47c73360webb3a552eed3dedd@mail.gmail.com> On 2/10/06, Emmanouil Piperakis wrote: > I am not the web devel expert, but let me put just a small piece of > advice... > I believe Nitro/Og should stay as is, conceptually for the moment. George > had/has an idea and a lot of reason for this idea. He should be advised for > any large scale changes. Additions should be welcomed > as long as they do not de-RAIL Nitro/Og (hehe... nice) from its original > purpose. > > The major disadvantage (I do not need to mention the tones of advantages, > they are obvious) of having many developers working on the same idea is that > rarely a complete consensus on the idea is reached. In that case a hierarchy > in the decission process always helps. I suggest that we / you / everyone > plan new changes / upgrades for Nitro/Og and even implement them, but let > George decide what should be incorperated. Fair enough. I should make a point that the reason I am looking at this now is because I'm about to create an application which would use Og. I've worked on Og before and saw how some of the code really could use improvements and this is one of them. To be very clear what changes for the end-user is basically: class SomeClass property :aprop, Sting end becomes class SomeClass property :aprop, Sting end Og.enchant(SomeClass) or if you prefer traditional Ruby way of doing such things, like: class SomeClass is Enchanted property :aprop, Sting end Nothing more. T. From itsme213 at hotmail.com Fri Feb 10 09:08:54 2006 From: itsme213 at hotmail.com (itsme213) Date: Fri, 10 Feb 2006 08:08:54 -0600 Subject: [Nitro] Og Revisted References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com><1139563507.3009.39.camel@robs-p4> <4b6f054f0602100558o47c73360webb3a552eed3dedd@mail.gmail.com> Message-ID: > To be very clear what > changes for the end-user is basically: > > class SomeClass > property :aprop, Sting > end > > becomes > > class SomeClass > property :aprop, Sting > end > > Og.enchant(SomeClass) Is your intention that property ... leave an explicit structure representing the property (e.g. via annotation) so that Og.enchant ... can do its thing? (Also, does it currently do so?) If so, I definitely support it. From zimba.tm at gmail.com Fri Feb 10 09:29:20 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 10 Feb 2006 15:29:20 +0100 Subject: [Nitro] Og Revisted In-Reply-To: <4b6f054f0602100558o47c73360webb3a552eed3dedd@mail.gmail.com> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> <4b6f054f0602100558o47c73360webb3a552eed3dedd@mail.gmail.com> Message-ID: <200602101529.20261.zimba.tm@gmail.com> On Friday 10 February 2006 14:58, TRANS wrote: > On 2/10/06, Emmanouil Piperakis wrote: > > I am not the web devel expert, but let me put just a small piece of > > advice... > > I believe Nitro/Og should stay as is, conceptually for the moment. George > > had/has an idea and a lot of reason for this idea. He should be advised > > for any large scale changes. Additions should be welcomed > > as long as they do not de-RAIL Nitro/Og (hehe... nice) from its original > > purpose. > > > > The major disadvantage (I do not need to mention the tones of advantages, > > they are obvious) of having many developers working on the same idea is > > that rarely a complete consensus on the idea is reached. In that case a > > hierarchy in the decission process always helps. I suggest that we / you > > / everyone plan new changes / upgrades for Nitro/Og and even implement > > them, but let George decide what should be incorperated. > > Fair enough. I should make a point that the reason I am looking at > this now is because I'm about to create an application which would use > Og. I've worked on Og before and saw how some of the code really could > use improvements and this is one of them. To be very clear what > changes for the end-user is basically: > > class SomeClass > property :aprop, Sting > end > > becomes > > class SomeClass > property :aprop, Sting > end > > Og.enchant(SomeClass) > > or if you prefer traditional Ruby way of doing such things, like: > > class SomeClass > is Enchanted > property :aprop, Sting > end > > Nothing more. I would also like a module enchant like : module Model class SomeClass; property :my_prop; end end Og.enchant Model -- Cheers,e zimba.tm weblog : http://zimba.oree.ch From george.moschovitis at gmail.com Fri Feb 10 10:42:17 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 10 Feb 2006 17:42:17 +0200 Subject: [Nitro] Me missing... In-Reply-To: <4b6f054f0602071355p4b041fffgb483a8eac7f8e763@mail.gmail.com> References: <4b6f054f0602030842k3d8cd2eerbecc6aa0ee874e7f@mail.gmail.com> <4b6f054f0602040802o1a797180w137b2c78e5a71975@mail.gmail.com> <4b6f054f0602050734k5429885ap53fa3a9829c02654@mail.gmail.com> <4b6f054f0602071109i4994f7d1gb8db583ecdb8781b@mail.gmail.com> <4b6f054f0602071355p4b041fffgb483a8eac7f8e763@mail.gmail.com> Message-ID: Dear devs, I will have some limited access to the net over the following days so I will be able to help with problems. There are lotsa mails to read though ;-) -g. On 2/7/06, TRANS wrote: > On 2/7/06, TRANS wrote: > > Oh, thanks. I thought that was gone. Hmmm...I wonder if a couple > > others are still lurking. I'll make sure their all gone. > > Just got word. They should be all gone now. > > T. > > _______________________________________________ > 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 Feb 10 10:44:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 10 Feb 2006 17:44:08 +0200 Subject: [Nitro] BRB, In-Reply-To: <43E8C5F2.4050501@ateb.com> References: <4b6f054f0602070632i59e62f75u2f59ff5a450b39e6@mail.gmail.com> <43E8C5F2.4050501@ateb.com> Message-ID: Naah it stands for be right back ;-) -g. On 2/7/06, Reid Thompson wrote: > TRANS wrote: > > BRB -- Does that stand for Be Right Back? ;-) > > > > Enjoy yourself George. > > > > T. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > naaahhh , stands for "Bring Reid Beer" > > reid > _______________________________________________ > 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 Feb 10 10:47:16 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 10 Feb 2006 17:47:16 +0200 Subject: [Nitro] (no subject) In-Reply-To: <69F90338-B824-4E66-8DF9-EBCC5ACC1686@ntecs.de> References: <6a7d49ca0602070728x33160199u@mail.gmail.com> <1139327464.17039.17.camel@robs-p4> <69F90338-B824-4E66-8DF9-EBCC5ACC1686@ntecs.de> Message-ID: On 2/7/06, Michael Neumann wrote: > Sorry, I found my error. I didn't noticed that the Og managed classes > must be defined before calling Og.setup. Exactly, or you can manually call: Og.manage_classes or something like that ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Fri Feb 10 10:53:04 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 10 Feb 2006 17:53:04 +0200 Subject: [Nitro] Og Revisted In-Reply-To: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> References: <4b6f054f0602091818v4dd5a44ayeaedb3e339fbd933@mail.gmail.com> Message-ID: > I'd like work on improving Og according to some of the ideas here: Oh, please not now :( > #property method is used. There are a few draw backs to this. Firstly, > it is inefficent b/c every time the property method is called it has > to first check to see if the class is already enchanted or not. Its not called at the applicatrion run time, so its absolutely now problem. hmm.. will write an email about the suggesgted changes tommorow... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Fri Feb 10 11:57:17 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 16:57:17 +0000 Subject: [Nitro] Facets More & Glue Message-ID: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> Well, since George is around. I'm going to go ahead and put this out there. This whole ordeal with Facets Core/More/Nano/Mega/Carats/Calibre crap has just taken its toll on me. I have spent months trying to firgure out a resaonble solution. There doesn't seem to be one. The mess arises out of a complex mixture of circumstance, namely the fundamental distiction between the natures of the core and more parts, plus the way Ruby itself handles libraries, plus how setup.rb works to distribute them, and how RubyGems works to do the same. Taken all together it makes for a very ugly organization requiring extra special Rakefile tasks and/or Gemspecs to weave things together properly depending on the chosen dev layout. I have tried many posibilites over the last few months, and I think they all suck. I've even wrote a script that would change how Ruby requires libraries in light of it, but I realize that's an utterly worthless endevor*. So George wants to me to move Facets into the Nitro repository and make it an offical part of the Nitro project. I'm all for it. But I hesitate to do so until the problem is satisfactorily resolved. But as I've said I no longer think there is a solution. That leaves only the possiblity that core and more should be two separate projects. I never wanted that, but I don't see any way around it. But I also don't wan't to to introduce another dependency into Nitro (not least of which reasons is b/c no name for said project has ever been satisfactory either). So right now I'm thinking the solution is to take the More part of Facets and merge it into Glue. Then Facets itself would just be the core extension methods. The only problem I have with that is that ideally these classes, modules and frameworks should be completely _generic_ (i.e usable without Nitro/Og), but some of the stuff in Glue currently only works in conjuction with Nitro/Og. Maybe that's not really a big deal, but it should at least be given consideration. T. *Politics within the Ruby community being what they are. From manveru at weez.co.jp Fri Feb 10 12:38:55 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Sat, 11 Feb 2006 02:38:55 +0900 Subject: [Nitro] Facets More & Glue In-Reply-To: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> Message-ID: <200602110238.56363.manveru@weez.co.jp> Hey Trans, Well, i'm not happy about the idea of having Glue (wich should be exactly what the name is - the glue between nitro/og/facets) being used for that. It sounds more like an idea that will force us later to remove them again and to outsource what not really fits in there. However, we all also followed the various attempts to get facets in a nice shape, with the main-problem being that nobody wants to have a big dependency but on the other side as much as possible around when it becomes neccesary, on the other hand you also never want to require something you don't need, just because it has something you need. based on that many changes have been made so far - making everyone stumbling upon yet-another-concept of how facets works. I don't say it was bad, but far from optimal - not blaming you, because you just tried to figure the best way out, despite of many attacks on ruby-lang. Now, the best thing we can do is finding a final solution - basically splitting it into two projects doesn't seem like a bad idea... this is how i saw it from the very beginning and how i thought of it. i am on the other hand not fond of having even more dependencies - how nice gems that might handle - at the moment we have: nitro, og, glue, facets, facets_core, facets_more, gen, glue, breakpoint, daemons, (sqlite3, psql, mysql, kirbybase, mongrel, redcloth) the last ones are of course optional, and i'm not sure about daemons anymore, they were neccesary a while ago. Now, splitting facets into two projects would _decrease_ the number of dependencies by one! :) So, the last thing is that they should have a twinny, rhyming name, facets_core facets_more doesn't sound bad - but the names don't say anything about what they contain... Right now i cannot come up with something better, but i'm sure other people can do it. Also i'm sorry about that lengthy post, i am a fan of summaries and just wanted to complete the picture a bit. ~~~~manveru Am Saturday 11 February 2006 01:57 schrieb TRANS: > Well, since George is around. I'm going to go ahead and put this out there. > > This whole ordeal with Facets Core/More/Nano/Mega/Carats/Calibre crap > has just taken its toll on me. I have spent months trying to firgure > out a resaonble solution. There doesn't seem to be one. The mess > arises out of a complex mixture of circumstance, namely the > fundamental distiction between the natures of the core and more parts, > plus the way Ruby itself handles libraries, plus how setup.rb works to > distribute them, and how RubyGems works to do the same. Taken all > together it makes for a very ugly organization requiring extra special > Rakefile tasks and/or Gemspecs to weave things together properly > depending on the chosen dev layout. I have tried many posibilites over > the last few months, and I think they all suck. I've even wrote a > script that would change how Ruby requires libraries in light of it, > but I realize that's an utterly worthless endevor*. > > So George wants to me to move Facets into the Nitro repository and > make it an offical part of the Nitro project. I'm all for it. But I > hesitate to do so until the problem is satisfactorily resolved. But > as I've said I no longer think there is a solution. That leaves only > the possiblity that core and more should be two separate projects. I > never wanted that, but I don't see any way around it. But I also don't > wan't to to introduce another dependency into Nitro (not least of > which reasons is b/c no name for said project has ever been > satisfactory either). So right now I'm thinking the solution is to > take the More part of Facets and merge it into Glue. Then Facets > itself would just be the core extension methods. The only problem I > have with that is that ideally these classes, modules and frameworks > should be completely _generic_ (i.e usable without Nitro/Og), but some > of the stuff in Glue currently only works in conjuction with Nitro/Og. > Maybe that's not really a big deal, but it should at least be given > consideration. > > T. > > *Politics within the Ruby community being what they are. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From zimba.tm at gmail.com Fri Feb 10 13:06:24 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 10 Feb 2006 19:06:24 +0100 Subject: [Nitro] Facets More & Glue In-Reply-To: <200602110238.56363.manveru@weez.co.jp> References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> <200602110238.56363.manveru@weez.co.jp> Message-ID: <200602101906.24450.zimba.tm@gmail.com> I'm favorable to include all the facet in nitro's repository because it's the only project I know that uses it. It will also allow use to make facet and nitro fit together well. Then I wish that we move facet_core to facet and facet_more to calibre, integrate the generic parts of glue into calibre and non-generic in each project (nitro or og). According to the glue source code it doesn't seem too complicated to do. I'm thinking of "property" and "configuration" for example. I also think that the Gen package is a good idea but that we don't have the time to develop it. So while it's in beta, we could just leave it in the repo but remove the dependency and use nitrogen instead. On Friday 10 February 2006 18:38, Michael Fellinger wrote: > Hey Trans, > > Well, i'm not happy about the idea of having Glue (wich should be exactly > what the name is - the glue between nitro/og/facets) being used for that. > It sounds more like an idea that will force us later to remove them again > and to outsource what not really fits in there. > > However, we all also followed the various attempts to get facets in a nice > shape, with the main-problem being that nobody wants to have a big > dependency but on the other side as much as possible around when it becomes > neccesary, on the other hand you also never want to require something you > don't need, just because it has something you need. > based on that many changes have been made so far - making everyone > stumbling upon yet-another-concept of how facets works. > I don't say it was bad, but far from optimal - not blaming you, because you > just tried to figure the best way out, despite of many attacks on > ruby-lang. > > Now, the best thing we can do is finding a final solution - basically > splitting it into two projects doesn't seem like a bad idea... this is how > i saw it from the very beginning and how i thought of it. > i am on the other hand not fond of having even more dependencies - how nice > gems that might handle - at the moment we have: > > nitro, og, glue, facets, facets_core, facets_more, gen, glue, breakpoint, > daemons, (sqlite3, psql, mysql, kirbybase, mongrel, redcloth) > > the last ones are of course optional, and i'm not sure about daemons > anymore, they were neccesary a while ago. > Now, splitting facets into two projects would _decrease_ the number of > dependencies by one! :) > So, the last thing is that they should have a twinny, rhyming name, > facets_core facets_more doesn't sound bad - but the names don't say > anything about what they contain... > Right now i cannot come up with something better, but i'm sure other people > can do it. > > Also i'm sorry about that lengthy post, i am a fan of summaries and just > wanted to complete the picture a bit. > > ~~~~manveru > > Am Saturday 11 February 2006 01:57 schrieb TRANS: > > Well, since George is around. I'm going to go ahead and put this out > > there. > > > > This whole ordeal with Facets Core/More/Nano/Mega/Carats/Calibre crap > > has just taken its toll on me. I have spent months trying to firgure > > out a resaonble solution. There doesn't seem to be one. The mess > > arises out of a complex mixture of circumstance, namely the > > fundamental distiction between the natures of the core and more parts, > > plus the way Ruby itself handles libraries, plus how setup.rb works to > > distribute them, and how RubyGems works to do the same. Taken all > > together it makes for a very ugly organization requiring extra special > > Rakefile tasks and/or Gemspecs to weave things together properly > > depending on the chosen dev layout. I have tried many posibilites over > > the last few months, and I think they all suck. I've even wrote a > > script that would change how Ruby requires libraries in light of it, > > but I realize that's an utterly worthless endevor*. > > > > So George wants to me to move Facets into the Nitro repository and > > make it an offical part of the Nitro project. I'm all for it. But I > > hesitate to do so until the problem is satisfactorily resolved. But > > as I've said I no longer think there is a solution. That leaves only > > the possiblity that core and more should be two separate projects. I > > never wanted that, but I don't see any way around it. But I also don't > > wan't to to introduce another dependency into Nitro (not least of > > which reasons is b/c no name for said project has ever been > > satisfactory either). So right now I'm thinking the solution is to > > take the More part of Facets and merge it into Glue. Then Facets > > itself would just be the core extension methods. The only problem I > > have with that is that ideally these classes, modules and frameworks > > should be completely _generic_ (i.e usable without Nitro/Og), but some > > of the stuff in Glue currently only works in conjuction with Nitro/Og. > > Maybe that's not really a big deal, but it should at least be given > > consideration. > > > > T. > > > > *Politics within the Ruby community being what they are. > > > > _______________________________________________ > > 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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From mneumann at ntecs.de Fri Feb 10 14:35:54 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Fri, 10 Feb 2006 20:35:54 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602082153.07684.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> Message-ID: Am 08.02.2006 um 21:53 schrieb zimba.tm: > Hello devs, > > I have put some changes in my own nitro repo at http://oree.ch/ > nitro. Here are I've appended a minor patch which makes SQL generation a bit simpler (add NULL constraints as well as VARCHAR(xx)). property :name, String, :limit => 25, :nullable => false # => name VARCHAR(25) NOT NULL Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 21020 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060210/11a00add/attachment.obj From bryan.a.soto at gmail.com Fri Feb 10 15:25:59 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 12:25:59 -0800 Subject: [Nitro] Facets #use In-Reply-To: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> Message-ID: On 2/8/06, TRANS wrote: > > In the previous version of Facets thought to offer a more robust way > of loading facet methods. Eg. > > require 'facets' > > Time.use Facets, :stamp > > That didn't seem to go over so well with some people. So I left it out > this version and stuck to the original way: > > require 'facet/time/stamp' > > Someones asked about. What are others take on this? > > How about Facets.for Time, :stamp I like the way that reads. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/ed68b660/attachment.html From bryan.a.soto at gmail.com Fri Feb 10 15:38:39 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 12:38:39 -0800 Subject: [Nitro] PATCH: Og, Tests Message-ID: * test_suite_cleanup Some moves, some deletes, one fix and a modification to a Rakefile to make the filelist it generates match the rest. * dont_manage_already_managed_classes Modifies the ObjectSpace selection so that classes already managed aren't selected. * sti_bugfix Fixes STI bug where tables where evolved (fields dropped!). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/ab326924/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 20996 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060210/ab326924/attachment.zip From bryan.a.soto at gmail.com Fri Feb 10 15:56:44 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 12:56:44 -0800 Subject: [Nitro] PATCH: Bump version to 0.29.0 Message-ID: Bumps version number for Glue, Nitro and Og. Not for release purposes. Just so that p Nitro::Version, etc. show we're running against glycerin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/50f1b976/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bump_to_0.29.0.zip Type: application/zip Size: 6733 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060210/50f1b976/attachment.zip From transfire at gmail.com Fri Feb 10 16:01:25 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 21:01:25 +0000 Subject: [Nitro] Facets More & Glue In-Reply-To: <200602101906.24450.zimba.tm@gmail.com> References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> <200602110238.56363.manveru@weez.co.jp> <200602101906.24450.zimba.tm@gmail.com> Message-ID: <4b6f054f0602101301o7e5c2848v5954d7daf3e1cf09@mail.gmail.com> Well, dang if my whinny-ass email didn't finally have some pay off! ;-) I've uploaded 1.0.3 of facets which is a completely integrated version, and yet nothing too tricky about it. Please give it a whirl and see if plays nice. If it doesn't fly then I will once again go with splitting the two parts up in some fahsion. :-/ But if this does work then... woohoo! Nightmare over! T. From transfire at gmail.com Fri Feb 10 16:08:48 2006 From: transfire at gmail.com (TRANS) Date: Fri, 10 Feb 2006 21:08:48 +0000 Subject: [Nitro] Facets #use In-Reply-To: References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> Message-ID: <4b6f054f0602101308s65df7d82u4ba89a78c4c8c568@mail.gmail.com> On 2/10/06, Bryan Soto wrote: > How about > > Facets.for Time, :stamp > > I like the way that reads. Hmm....not bad. Actually, you can do: require 'facets' Facets.require 'time/stamp' That was the go between method that #use called, and I left it in. So I can easily add Facets.for in the same manner. FYI, for those unsure why this is even considered, there are two things that the regular require method can't do. It can't seach superclasses for a core method if not found in the given class and it can't substitute for punctuational method names. T. From bryan.a.soto at gmail.com Fri Feb 10 17:02:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 14:02:47 -0800 Subject: [Nitro] Facets More & Glue In-Reply-To: <4b6f054f0602101301o7e5c2848v5954d7daf3e1cf09@mail.gmail.com> References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> <200602110238.56363.manveru@weez.co.jp> <200602101906.24450.zimba.tm@gmail.com> <4b6f054f0602101301o7e5c2848v5954d7daf3e1cf09@mail.gmail.com> Message-ID: On 2/10/06, TRANS wrote: > > Well, dang if my whinny-ass email didn't finally have some pay off! > ;-) I've uploaded 1.0.3 of facets which is a completely integrated > version, and yet nothing too tricky about it. Please give it a whirl > and see if plays nice. If it doesn't fly then I will once again go with splitting the two > parts up in some fahsion. :-/ But if this does work then... woohoo! > Nightmare over! > > T. > On Linux, it installed fine. On Windows, (Errno::EINVAL) Invalid argument - packages/core/dev/array/**.rb So what was the solution. Oh, and hopefully not being a pain, would it be possible to have it install RDocs? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/c27eb001/attachment.html From bryan.a.soto at gmail.com Fri Feb 10 17:11:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 14:11:35 -0800 Subject: [Nitro] Dynamic Elements In-Reply-To: <200602061828.04928.riku.raisanen@walkingwoods.com> References: <200602061828.04928.riku.raisanen@walkingwoods.com> Message-ID: On 2/6/06, Riku R?is?nen wrote: > > First of all, I've managed not to post to ML for this long. I'm Riku > R?is?nen > (Rayman), a Ruby user from Finland. > > Now about the idea of dynamic elements: > > Hi Riku, Just wanted to make sure you knew, in case you missed it. Jonas actually did implement this idea after you posted. It's available via the darcs repository at http://oree.ch/nitro if you'd like to give it a try. # darcs get http://oree.ch/nitro Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/9dd5198a/attachment.html From bryan.a.soto at gmail.com Fri Feb 10 17:15:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 10 Feb 2006 14:15:26 -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? > > Hi Rob, did you ever discover anything about this? I ask because, after Guill's Og.thread_safe patch and my patch of today to make the og test suite run again, running rake test from the og directory causes these errors you were talking about. It's probably something we'd be able to debug regardless since it's now consistent, but if you have any info to give a head start with, that'd be nice too. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060210/723c1cc4/attachment.html From transfire at gmail.com Sat Feb 11 00:03:20 2006 From: transfire at gmail.com (TRANS) Date: Sat, 11 Feb 2006 05:03:20 +0000 Subject: [Nitro] Facets More & Glue In-Reply-To: References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> <200602110238.56363.manveru@weez.co.jp> <200602101906.24450.zimba.tm@gmail.com> <4b6f054f0602101301o7e5c2848v5954d7daf3e1cf09@mail.gmail.com> Message-ID: <4b6f054f0602102103n2cc13e56qeabe13617e9d03f1@mail.gmail.com> On 2/10/06, Bryan Soto wrote: > On 2/10/06, TRANS wrote: > > Well, dang if my whinny-ass email didn't finally have some pay off! > > ;-) I've uploaded 1.0.3 of facets which is a completely integrated > > version, and yet nothing too tricky about it. Please give it a whirl > > and see if plays nice. > > If it doesn't fly then I will once again go with splitting the two > > parts up in some fahsion. :-/ But if this does work then... woohoo! > > Nightmare over! > > > > T. > > > > On Linux, it installed fine. > > On Windows, (Errno::EINVAL) Invalid argument - > packages/core/dev/array/**.rb Ah, thanks. I'll fix. > So what was the solution. > > Oh, and hopefully not being a pain, would it be possible to have it install > RDocs? No pain. I'll work on it. T. From george.moschovitis at gmail.com Sat Feb 11 07:20:26 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 11 Feb 2006 14:20:26 +0200 Subject: [Nitro] Facets #use In-Reply-To: <4b6f054f0602101308s65df7d82u4ba89a78c4c8c568@mail.gmail.com> References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> <4b6f054f0602101308s65df7d82u4ba89a78c4c8c568@mail.gmail.com> Message-ID: I like the require 'facets/xxx' method... -g. On 2/10/06, TRANS wrote: > On 2/10/06, Bryan Soto wrote: > > > How about > > > > Facets.for Time, :stamp > > > > I like the way that reads. > > Hmm....not bad. Actually, you can do: > > require 'facets' > > Facets.require 'time/stamp' > > That was the go between method that #use called, and I left it in. So > I can easily add Facets.for in the same manner. > > FYI, for those unsure why this is even considered, there are two > things that the regular require method can't do. It can't seach > superclasses for a core method if not found in the given class and it > can't substitute for punctuational method names. > > T. > > _______________________________________________ > 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 Feb 11 07:28:13 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 11 Feb 2006 14:28:13 +0200 Subject: [Nitro] Reviewers needed In-Reply-To: References: Message-ID: I would like to have a look at your work in progress, can you email it to me? -g. On 2/10/06, Aidan Rogers wrote: > Hi all, > > As I mentioned earlier in the week, I'm writing a tutorial for Og/ > Nitro. This has actually turned into something more resembling a > book, so I'd like a few volunteers to review and give me feedback as > I go. If you're interested, drop me a mail off-list, and I'll send > you the zip file after each iteration for comments. In this way, I > can get constant feedback as I go, rather than getting it all at the > end. > > 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 Sat Feb 11 07:34:39 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 11 Feb 2006 14:34:39 +0200 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> <200602090016.52647.zimba.tm@gmail.com> <6a7d49ca0602090543h25e6358fk@mail.gmail.com> <200602091926.07216.zimba.tm@gmail.com> Message-ID: Contact Tasos Koutoumanos at: drak at navel.gr -g. On 2/9/06, Bryan Soto wrote: > On 2/9/06, zimba.tm wrote: > > Hi Guillaume, > > > > Sure. Can you make a description of your patches for the list ? In the > > meanwhile, I will commit them tomorrow. > > > > Btw. Does somebody know why the official wiki doesn't change ? I have > modified > > the repo page but I don't get the html update. > > > > > > I don't know. Manveru noticed that also. We'll probably have to contact > Tazos(sp?) through Navel on that. > > _______________________________________________ > 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 Feb 11 07:36:53 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 11 Feb 2006 14:36:53 +0200 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: > * dont_manage_already_managed_classes > Modifies the ObjectSpace selection so that classes already managed aren't > selected. you have submitted this patche aerlier but caused problems with the admin part. (Didn't display any managed classes...) Please be careful if this new code works. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Sat Feb 11 08:33:16 2006 From: transfire at gmail.com (TRANS) Date: Sat, 11 Feb 2006 13:33:16 +0000 Subject: [Nitro] Facets #use In-Reply-To: References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> <4b6f054f0602101308s65df7d82u4ba89a78c4c8c568@mail.gmail.com> Message-ID: <4b6f054f0602110533i43e2a89cy49b0a11c10b3e668@mail.gmail.com> On 2/11/06, George Moschovitis wrote: > I like the require 'facets/xxx' method... Right. We'll stick with that, but are you suggesting (or perhaps accidently so) that it change to 'facets/' instead of 'facet/'? T. From transfire at gmail.com Sat Feb 11 08:35:13 2006 From: transfire at gmail.com (TRANS) Date: Sat, 11 Feb 2006 13:35:13 +0000 Subject: [Nitro] Facets More & Glue In-Reply-To: <4b6f054f0602102103n2cc13e56qeabe13617e9d03f1@mail.gmail.com> References: <4b6f054f0602100857g7ba741e6g3a59a033f2d48ab3@mail.gmail.com> <200602110238.56363.manveru@weez.co.jp> <200602101906.24450.zimba.tm@gmail.com> <4b6f054f0602101301o7e5c2848v5954d7daf3e1cf09@mail.gmail.com> <4b6f054f0602102103n2cc13e56qeabe13617e9d03f1@mail.gmail.com> Message-ID: <4b6f054f0602110535k304850fand49176251db5fda5@mail.gmail.com> Okay, I released v1.0.3 without the dev/ directory. So everything should work now. T. On 2/11/06, TRANS wrote: > On 2/10/06, Bryan Soto wrote: > > On 2/10/06, TRANS wrote: > > > Well, dang if my whinny-ass email didn't finally have some pay off! > > > ;-) I've uploaded 1.0.3 of facets which is a completely integrated > > > version, and yet nothing too tricky about it. Please give it a whirl > > > and see if plays nice. > > > If it doesn't fly then I will once again go with splitting the two > > > parts up in some fahsion. :-/ But if this does work then... woohoo! > > > Nightmare over! > > > > > > T. > > > > > > > On Linux, it installed fine. > > > > On Windows, (Errno::EINVAL) Invalid argument - > > packages/core/dev/array/**.rb > > Ah, thanks. I'll fix. > > > So what was the solution. > > > > Oh, and hopefully not being a pain, would it be possible to have it install > > RDocs? > > No pain. I'll work on it. > > T. > -- ( o- ??? went BOOM // trans. / / transfire at gmail.com From george.moschovitis at gmail.com Sat Feb 11 10:38:35 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 11 Feb 2006 17:38:35 +0200 Subject: [Nitro] Facets #use In-Reply-To: <4b6f054f0602110533i43e2a89cy49b0a11c10b3e668@mail.gmail.com> References: <4b6f054f0602081846x3f662e84q39a37488231c8992@mail.gmail.com> <4b6f054f0602101308s65df7d82u4ba89a78c4c8c568@mail.gmail.com> <4b6f054f0602110533i43e2a89cy49b0a11c10b3e668@mail.gmail.com> Message-ID: > Right. We'll stick with that, but are you suggesting (or perhaps > accidently so) that it change to 'facets/' instead of 'facet/'? no, facet is ok ;-) I just prefer to keep the standard ruby way... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From matt at kiatoa.com Sat Feb 11 22:37:09 2006 From: matt at kiatoa.com (Matthew Welland) Date: Sat, 11 Feb 2006 20:37:09 -0700 Subject: [Nitro] Nitro gem seems not to install properly on ubuntu Message-ID: <200602112037.10671.matt@kiatoa.com> I started the email message below but soon realized that gems is broken on ubuntu/debian. Manual install of all the dependancies is not working (yet). Consider this an FYI and a request for advice on an easy way to get ruby + gems + nitro and dependancies working on ubuntu. ================================== Nitro is somehow not quite setup properly. matt at xena:~/tmp/examples-0.28.0/hello$ sudo gem install nitro Attempting local installation of 'nitro' Local gem file not found: nitro*.gem Attempting remote installation of 'nitro' Successfully installed nitro-0.28.0 matt at xena:~/tmp/examples-0.28.0/hello$ ruby run.rb run.rb:1:in `require': no such file to load -- nitro (LoadError) from run.rb:1 matt at xena:~/tmp/examples-0.28.0/hello$ From manveru at weez.co.jp Sat Feb 11 23:53:01 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Sun, 12 Feb 2006 13:53:01 +0900 Subject: [Nitro] Nitro gem seems not to install properly on ubuntu In-Reply-To: <200602112037.10671.matt@kiatoa.com> References: <200602112037.10671.matt@kiatoa.com> Message-ID: <200602121353.03649.manveru@weez.co.jp> Hey Matthew, Here i try to describe the prefect installation of ruby/rubygems/nitro/sqlite (sqlite only for having some kind of database - it's not really needed) for ubuntu # let's change to root, i don't like to type sudo all the time sudo -i apt-get install ruby irb ri ruby1.8-dev libyaml-ruby libzlib-ruby wget http://rubyforge.org/frs/download.php/5207/rubygems-0.8.11.tgz tar xfvz rubygems-0.8.11.tgz cd rubygems-0.8.11 ruby setup.rb # you need this only in some months, when a new rubygems-version comes out # and this mail might not be accurate anymore gem update --system gem install nitro -y # that's it... now on to installing sqlite (swig is needed for preventing some # malicious segaults) apt-get install libsqlite3-dev swig gem install sqlite3-ruby # leave sudo-mode and set the rubyopt in your .bashrc exit echo "export RUBYOPT=rubygems" >> ~/.bashrc # now close the shell, open a new one, and everything should work perfect :) that's it... you have ruby, irb, ri, rubygems and nitro&friends up and running optional you can install the gems 'ruby-breakpoint', wich gives you some nice debugging-features and 'redcloth' for all the highlighting you'll ever need. tell me if that works for you, most was written out of memory ~~~~manveru On Sunday 12 February 2006 12:37, Matthew Welland wrote: > I started the email message below but soon realized that gems is broken on > ubuntu/debian. Manual install of all the dependancies is not working (yet). > > Consider this an FYI and a request for advice on an easy way to get ruby + > gems + nitro and dependancies working on ubuntu. > > ================================== > Nitro is somehow not quite setup properly. > > matt at xena:~/tmp/examples-0.28.0/hello$ sudo gem install nitro > Attempting local installation of 'nitro' > Local gem file not found: nitro*.gem > Attempting remote installation of 'nitro' > Successfully installed nitro-0.28.0 > matt at xena:~/tmp/examples-0.28.0/hello$ ruby run.rb > run.rb:1:in `require': no such file to load -- nitro (LoadError) > from run.rb:1 > matt at xena:~/tmp/examples-0.28.0/hello$ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Sun Feb 12 00:16:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 11 Feb 2006 21:16:25 -0800 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: On 2/11/06, George Moschovitis wrote: > > > * dont_manage_already_managed_classes > > Modifies the ObjectSpace selection so that classes already managed > aren't > > selected. > > you have submitted this patche aerlier but caused problems with the > admin part. (Didn't display any managed classes...) Please be careful > if this new code works. > > Thanks for pointing that out. I always forget to grep in nitro/src. By the way, is there a reason part/ isn't a subdirectory of lib/? nitro/lib/part/admin/*? Rather than nitro/src/part/admin. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060212/ab5ab3cb/attachment.html From bryan.a.soto at gmail.com Sun Feb 12 00:17:31 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 11 Feb 2006 21:17:31 -0800 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: On 2/10/06, Bryan Soto wrote: > > * dont_manage_already_managed_classes > Modifies the ObjectSpace selection so that classes already managed > aren't selected. Please disregard this patch. I'll redo so it doesn't break anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060212/d9a58f56/attachment.html From zimba.tm at gmail.com Sun Feb 12 09:35:27 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 12 Feb 2006 15:35:27 +0100 Subject: [Nitro] PATCH: Bump version to 0.29.0 In-Reply-To: References: Message-ID: <200602121535.27513.zimba.tm@gmail.com> Applied On Friday 10 February 2006 21:56, Bryan Soto wrote: > Bumps version number for Glue, Nitro and Og. Not for release purposes. Just > so that p Nitro::Version, etc. show we're running against glycerin. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Sun Feb 12 09:37:48 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 12 Feb 2006 15:37:48 +0100 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: <200602121537.48604.zimba.tm@gmail.com> On Friday 10 February 2006 21:38, Bryan Soto wrote: > * test_suite_cleanup > Some moves, some deletes, one fix and a modification to a Rakefile to > make the filelist it generates match the rest. Applied > > * dont_manage_already_managed_classes > Modifies the ObjectSpace selection so that classes already managed aren't > selected. Ignored as requested > * sti_bugfix > Fixes STI bug where tables where evolved (fields dropped!). Applied -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Sun Feb 12 09:45:06 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 12 Feb 2006 15:45:06 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> Message-ID: <200602121545.06456.zimba.tm@gmail.com> On Friday 10 February 2006 20:35, Michael Neumann wrote: > Am 08.02.2006 um 21:53 schrieb zimba.tm: > > Hello devs, > > > > I have put some changes in my own nitro repo at http://oree.ch/ > > nitro. Here are > > I've appended a minor patch which makes SQL generation a bit simpler > (add NULL constraints as > well as VARCHAR(xx)). > > property :name, String, :limit => 25, :nullable => false > # => name VARCHAR(25) NOT NULL > > Regards, > > Michael Hi manveru, wouldn't :length be more precise than :limit ? Also is it still possible to define it's own type definition, like CHAR(25) ? -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Sun Feb 12 10:18:02 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 12 Feb 2006 16:18:02 +0100 Subject: [Nitro] Patchset #2 Message-ID: <200602121618.02603.zimba.tm@gmail.com> Fri Feb 10 19:09:13 CET 2006 Jonas Pfenniger * Controls : fix for the controls options Additional attributes where broken Fri Feb 10 19:12:52 CET 2006 Jonas Pfenniger * Element transformer : avoid interpreting unknown elements so that controls can take care of it Now the transformer won't raise an error if a didn't have any corresponding Control or Element. Is this bad ? Sun Feb 12 15:56:35 CET 2006 Jonas Pfenniger * Controls : moved the transorm order with Element Now Controls are interpreted after Elements Sun Feb 12 15:56:57 CET 2006 Jonas Pfenniger * Controller : made template_root assignable Now you can use MyController.template_root = "/new_template" if you want to assign a template instead of defining the method. Should I use a setting instead ? Right now there could be some problems concerning inheritance. Sun Feb 12 16:14:01 CET 2006 Jonas Pfenniger * [test fix] Dispatcher test fixed ... -- Cheers, zimba.tm weblog : http://zimba.oree.ch From transfire at gmail.com Sun Feb 12 11:47:16 2006 From: transfire at gmail.com (TRANS) Date: Sun, 12 Feb 2006 16:47:16 +0000 Subject: [Nitro] PATCH: Bump version to 0.29.0 In-Reply-To: <200602121535.27513.zimba.tm@gmail.com> References: <200602121535.27513.zimba.tm@gmail.com> Message-ID: <4b6f054f0602120847i42302dffp3b5b4805142a3aa2@mail.gmail.com> Be sure to change 0.29's dependencies on Facets to facets-1.0.3 instead of facets_core-1.0.2 and facets_more-1.0.2. T. On 2/12/06, zimba.tm wrote: > Applied > > On Friday 10 February 2006 21:56, Bryan Soto wrote: > > Bumps version number for Glue, Nitro and Og. Not for release purposes. Just > > so that p Nitro::Version, etc. show we're running against glycerin. > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From transfire at gmail.com Sun Feb 12 12:08:49 2006 From: transfire at gmail.com (TRANS) Date: Sun, 12 Feb 2006 17:08:49 +0000 Subject: [Nitro] Og Revisted Message-ID: <4b6f054f0602120908x342290baq910588850be69d82@mail.gmail.com> > def require_og_models(*models) > snapshot_pre = [] > snapshot_post = [] > ObjectSpace.each_object{|o| snapshot_pre << o} > models.each{|m| require(m)} > ObjectSpace.each_object{|o| snapshot_post << o} > enchant(snapshot_post-snapshot_pre) > end > > require_og_models "model.rb" While interesting, it doesn't really cover all that is required. Enchanting a class is inherintly "mixin". It is not just something that happens to a class post definition. Enchanting adds methods availalbe in the design of the class, such as the relation methonds, the aspect methods. (Also looping through all of object space, twice, is pretty time consuming.) T. From transfire at gmail.com Sun Feb 12 12:24:20 2006 From: transfire at gmail.com (TRANS) Date: Sun, 12 Feb 2006 17:24:20 +0000 Subject: [Nitro] Og Revisted In-Reply-To: <4b6f054f0602120908x342290baq910588850be69d82@mail.gmail.com> References: <4b6f054f0602120908x342290baq910588850be69d82@mail.gmail.com> Message-ID: <4b6f054f0602120924r64f85c51s37a8abeaf780cdeb@mail.gmail.com> > Is your intention that > property ... > leave an explicit structure representing the property (e.g. via annotation) > so that > Og.enchant ... > can do its thing? (Also, does it currently do so?) > > If so, I definitely support it. Yes, that is the case. See, it would be nice if all classes could be enchanted by default, then it would be completely transparent, but as it is enchantment is too heavy for that. But if we split "enchantment" up into two parts then the first part could be light weight mixin front-end that just allows one to establishes the structure --this could then be part of all classes. The the second part would then use that structure to do all the grunt work at runtime. Does that make sense? T. From matt at kiatoa.com Sun Feb 12 16:54:00 2006 From: matt at kiatoa.com (Matthew Welland) Date: Sun, 12 Feb 2006 14:54:00 -0700 Subject: [Nitro] Nitro gem seems not to install properly on ubuntu In-Reply-To: <200602121353.03649.manveru@weez.co.jp> References: <200602112037.10671.matt@kiatoa.com> <200602121353.03649.manveru@weez.co.jp> Message-ID: <200602121454.01027.matt@kiatoa.com> Worked great! Thanks. Now on to getting cgi.rb working. On Saturday 11 February 2006 21:53, Michael Fellinger wrote: > Hey Matthew, > > Here i try to describe the prefect installation of > ruby/rubygems/nitro/sqlite (sqlite only for having some kind of database - > it's not really needed) for ubuntu > > # let's change to root, i don't like to type sudo all the time > sudo -i > apt-get install ruby irb ri ruby1.8-dev libyaml-ruby libzlib-ruby > wget http://rubyforge.org/frs/download.php/5207/rubygems-0.8.11.tgz > tar xfvz rubygems-0.8.11.tgz > cd rubygems-0.8.11 > ruby setup.rb > # you need this only in some months, when a new rubygems-version comes out > # and this mail might not be accurate anymore > gem update --system > gem install nitro -y > # that's it... now on to installing sqlite (swig is needed for preventing > some # malicious segaults) > apt-get install libsqlite3-dev swig > gem install sqlite3-ruby > # leave sudo-mode and set the rubyopt in your .bashrc > exit > echo "export RUBYOPT=rubygems" >> ~/.bashrc > # now close the shell, open a new one, and everything should work perfect > :) > > that's it... you have ruby, irb, ri, rubygems and nitro&friends up and > running optional you can install the gems 'ruby-breakpoint', wich gives you > some nice debugging-features and 'redcloth' for all the highlighting you'll > ever need. > > tell me if that works for you, most was written out of memory > ~~~~manveru > > On Sunday 12 February 2006 12:37, Matthew Welland wrote: > > I started the email message below but soon realized that gems is broken > > on ubuntu/debian. Manual install of all the dependancies is not working > > (yet). > > > > Consider this an FYI and a request for advice on an easy way to get ruby > > + gems + nitro and dependancies working on ubuntu. > > > > ================================== > > Nitro is somehow not quite setup properly. > > > > matt at xena:~/tmp/examples-0.28.0/hello$ sudo gem install nitro > > Attempting local installation of 'nitro' > > Local gem file not found: nitro*.gem > > Attempting remote installation of 'nitro' > > Successfully installed nitro-0.28.0 > > matt at xena:~/tmp/examples-0.28.0/hello$ ruby run.rb > > run.rb:1:in `require': no such file to load -- nitro (LoadError) > > from run.rb:1 > > matt at xena:~/tmp/examples-0.28.0/hello$ > > _______________________________________________ > > 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 mneumann at ntecs.de Sun Feb 12 17:51:39 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Sun, 12 Feb 2006 23:51:39 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602121545.06456.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602121545.06456.zimba.tm@gmail.com> Message-ID: <8AD77E98-189B-4984-9287-4AB81908DC25@ntecs.de> Am 12.02.2006 um 15:45 schrieb zimba.tm: > On Friday 10 February 2006 20:35, Michael Neumann wrote: >> Am 08.02.2006 um 21:53 schrieb zimba.tm: >>> Hello devs, >>> >>> I have put some changes in my own nitro repo at http://oree.ch/ >>> nitro. Here are >> >> I've appended a minor patch which makes SQL generation a bit simpler >> (add NULL constraints as >> well as VARCHAR(xx)). >> >> property :name, String, :limit => 25, :nullable => false >> # => name VARCHAR(25) NOT NULL >> >> Regards, >> >> Michael > > Hi manveru, > > wouldn't :length be more precise than :limit ? Also is it still > possible to > define it's own type definition, like CHAR(25) ? Hehe, :limit is what Rails migrations use :). We could define :sql_type or just :type, so you could write: property :name, String, :length => 25, :sql_type => "CHAR", :nullable => true It would be very simple to implement. Regards, Michael From matt at kiatoa.com Sun Feb 12 19:20:36 2006 From: matt at kiatoa.com (Matthew Welland) Date: Sun, 12 Feb 2006 17:20:36 -0700 Subject: [Nitro] Trying to get cgi to work - am I on the right track? Message-ID: <200602121720.37096.matt@kiatoa.com> I need a kick start (or just a kick) with nitro and cgi. The examples run using: ruby -rubygems run.rb However I couldn't get cgi.rb to invoke run.rb from the hello example so I thought I'd try combining them to make an extremely simple starting point. I trimmed the example cgi.rb script from the blog example and added hello/run.rb to get the following: ==============cgi.rb============== #!/home/kiatoaco/software/bin/ruby ENV['NITRO_INVOKE'] = 'cgi_proc' #$NITRO_NO_INVOKE = true require 'rubygems' require 'nitro' require 'glue/logger' Logger.set Logger.new('log/app.log') class HelloWorld def index 'Hello, World' end def math(val1, val2) "result = #{val1.to_i * 2}, another = #{val2 * 3}" end end require 'nitro/adapter/cgi' Nitro.run(HelloWorld) ============end of cgi.rb============ I get: ============the apache log errors============ D, [2006-02-12T17:13:23.101834 #698] DEBUG -- : Using Memory sessions. /home/kiatoaco/software/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/adapter/cgi.rb:21: undefined method `thread_safe=' for Og:Module (NoMethodError) from /home/kiatoaco/software/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__' from /home/kiatoaco/software/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from cgi.rb:23 [Sun Feb 12 17:13:23 2006] [error] [client 130.13.218.203] Premature end of script headers: /home/kiatoaco/public_html/cgi-bin/cgi.rb From aidan at yoyo.org Sun Feb 12 21:41:06 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Mon, 13 Feb 2006 13:41:06 +1100 Subject: [Nitro] part/admin b0rken? Message-ID: Hi all, In writing the Og/Nitro tutorial, I started using part/admin. Has anyone else noticed it is broken in the current 0.28.0 release? I'm getting numerous errors. It works on the surface, but when you give it a model which has anything resembling a real-life app, there are issues. Anyone else seen these? If so, please let me know. I'm aiming to track them down and supply fixes, but don't want to duplicate effort. It therefore goes without saying (but I'll say it anyway) if you're working on fixes for this, please let me know :-) Aidan --- http://www.infurious.com From zimba.tm at gmail.com Mon Feb 13 03:39:37 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 09:39:37 +0100 Subject: [Nitro] PATCH: Bump version to 0.29.0 In-Reply-To: <4b6f054f0602120847i42302dffp3b5b4805142a3aa2@mail.gmail.com> References: <200602121535.27513.zimba.tm@gmail.com> <4b6f054f0602120847i42302dffp3b5b4805142a3aa2@mail.gmail.com> Message-ID: <200602130939.37380.zimba.tm@gmail.com> On Sunday 12 February 2006 17:47, TRANS wrote: > Be sure to change 0.29's dependencies on Facets to facets-1.0.3 > instead of facets_core-1.0.2 and facets_more-1.0.2. Done > > T. > > On 2/12/06, zimba.tm wrote: > > Applied > > > > On Friday 10 February 2006 21:56, Bryan Soto wrote: > > > Bumps version number for Glue, Nitro and Og. Not for release purposes. > > > Just so that p Nitro::Version, etc. show we're running against > > > glycerin. > > > > -- > > Cheers, > > zimba.tm > > > > weblog : http://zimba.oree.ch > > _______________________________________________ > > 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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Mon Feb 13 03:43:07 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 09:43:07 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <8AD77E98-189B-4984-9287-4AB81908DC25@ntecs.de> References: <200602082153.07684.zimba.tm@gmail.com> <200602121545.06456.zimba.tm@gmail.com> <8AD77E98-189B-4984-9287-4AB81908DC25@ntecs.de> Message-ID: <200602130943.07482.zimba.tm@gmail.com> On Sunday 12 February 2006 23:51, Michael Neumann wrote: > Am 12.02.2006 um 15:45 schrieb zimba.tm: > > On Friday 10 February 2006 20:35, Michael Neumann wrote: > >> Am 08.02.2006 um 21:53 schrieb zimba.tm: > >>> Hello devs, > >>> > >>> I have put some changes in my own nitro repo at http://oree.ch/ > >>> nitro. Here are > >> > >> I've appended a minor patch which makes SQL generation a bit simpler > >> (add NULL constraints as > >> well as VARCHAR(xx)). > >> > >> property :name, String, :limit => 25, :nullable => false > >> # => name VARCHAR(25) NOT NULL > >> > >> Regards, > >> > >> Michael > > > > Hi manveru, > > > > wouldn't :length be more precise than :limit ? Also is it still > > possible to > > define it's own type definition, like CHAR(25) ? > > Hehe, :limit is what Rails migrations use :). We could > define :sql_type or > just :type, so you could write: > > property :name, String, :length => 25, :sql_type => > "CHAR", :nullable => true > > It would be very simple to implement. How about additional keywords that are dependent of the database, like mysql's auto_incerment or UNSIGNED ? > > Regards, > > Michael > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Mon Feb 13 03:53:41 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 09:53:41 +0100 Subject: [Nitro] part/admin b0rken? In-Reply-To: References: Message-ID: <200602130953.41167.zimba.tm@gmail.com> On Monday 13 February 2006 03:41, Aidan Rogers wrote: > Hi all, > > In writing the Og/Nitro tutorial, I started using part/admin. Has > anyone else noticed it is broken in the current 0.28.0 release? I'm > getting numerous errors. It works on the surface, but when you give > it a model which has anything resembling a real-life app, there are > issues. Anyone else seen these? Hum. If you use my repo at http://oree.ch/nitro I had broken something by playing with the Controls. Now it should work of. on Feb 13 09:50:34 CET 2006 Jonas Pfenniger * [fix glue] Changed Nitro::Control to Nitro::Form::Control. I had forgetted this one. > > If so, please let me know. I'm aiming to track them down and supply > fixes, but don't want to duplicate effort. It therefore goes without > saying (but I'll say it anyway) if you're working on fixes for this, > please let me know :-) > > Aidan > --- > http://www.infurious.com > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Cheers, zimba.tm weblog : http://zimba.oree.ch From guillaume.pierronnet at gmail.com Mon Feb 13 04:30:33 2006 From: guillaume.pierronnet at gmail.com (guillaume pierronnet) Date: Mon, 13 Feb 2006 10:30:33 +0100 Subject: [Nitro] Trying to get cgi to work - am I on the right track? In-Reply-To: <200602121720.37096.matt@kiatoa.com> References: <200602121720.37096.matt@kiatoa.com> Message-ID: <6a7d49ca0602130130id67574ay@mail.gmail.com> did you try the glycerin repository at http://oree.ch/nitro ? There are some fixes in it. regards 2006/2/13, Matthew Welland : > I need a kick start (or just a kick) with nitro and cgi. The examples run > using: > > ruby -rubygems run.rb > > However I couldn't get cgi.rb to invoke run.rb from the hello example so I > thought I'd try combining them to make an extremely simple starting point. I > trimmed the example cgi.rb script from the blog example and added > hello/run.rb to get the following: > > ==============cgi.rb============== > #!/home/kiatoaco/software/bin/ruby > > ENV['NITRO_INVOKE'] = 'cgi_proc' > #$NITRO_NO_INVOKE = true > > require 'rubygems' > require 'nitro' > > require 'glue/logger' > Logger.set Logger.new('log/app.log') > > class HelloWorld > def index > 'Hello, World' > end > > def math(val1, val2) > "result = #{val1.to_i * 2}, another = #{val2 * 3}" > end > > end > > require 'nitro/adapter/cgi' > Nitro.run(HelloWorld) > ============end of cgi.rb============ > > I get: > > ============the apache log errors============ > D, [2006-02-12T17:13:23.101834 #698] DEBUG -- : Using Memory > sessions. /home/kiatoaco/software/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/adapter/cgi.rb:21: > undefined method `thread_safe=' for Og:Module (NoMethodError) > from /home/kiatoaco/software/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require__' > from /home/kiatoaco/software/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require' from cgi.rb:23 [Sun Feb 12 17:13:23 2006] [error] [client > 130.13.218.203] Premature end of script > headers: /home/kiatoaco/public_html/cgi-bin/cgi.rb > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From mneumann at ntecs.de Mon Feb 13 06:26:28 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Mon, 13 Feb 2006 12:26:28 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: <200602130943.07482.zimba.tm@gmail.com> References: <200602082153.07684.zimba.tm@gmail.com> <200602121545.06456.zimba.tm@gmail.com> <8AD77E98-189B-4984-9287-4AB81908DC25@ntecs.de> <200602130943.07482.zimba.tm@gmail.com> Message-ID: Am 13.02.2006 um 09:43 schrieb zimba.tm: > On Sunday 12 February 2006 23:51, Michael Neumann wrote: > How about additional keywords that are dependent of the database, > like mysql's > auto_incerment or UNSIGNED ? I guess this can be done with the existing implementation using :extra_sql (I don't remember the correct keyword). With :sql_type, you could write: property :age, Integer, :sql_type => "UNSIGNED INT" Or auto_increment: property :myid, Integer, :extra_sql => 'auto_increment' Even with :sql_type, we wouldn't need :length or :limit at all as we could write: property :name, String, :sql_type => "VARCHAR(256)" But then, we could do everything directly with: property :name, String, :sql => "VARCHAR(256) DEFAULT '' NOT NULL" Regards, Michael From george.moschovitis at gmail.com Mon Feb 13 07:10:52 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 13 Feb 2006 14:10:52 +0200 Subject: [Nitro] part/admin b0rken? In-Reply-To: References: Message-ID: > In writing the Og/Nitro tutorial, I started using part/admin. Has > anyone else noticed it is broken in the current 0.28.0 release? I'm > getting numerous errors. It works on the surface, but when you give > it a model which has anything resembling a real-life app, there are > issues. Anyone else seen these? I believe the admin interface works correctly in 0.28.0 -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Feb 13 07:14:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 13 Feb 2006 14:14:28 +0200 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: > By the way, is there a reason part/ isn't a subdirectory of lib/? > nitro/lib/part/admin/*? Rather than nitro/src/part/admin. There is a reason, but I am still thinking at the bes place for parts and I dont have the time for a full anwser at the moment. Please remind me of this before the release of Nitro 0.29.0 (planned for the beginning of March) so we can decide a final position... regards, George -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Mon Feb 13 07:31:01 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 13:31:01 +0100 Subject: [Nitro] [oree.ch] Patchset #1 In-Reply-To: References: <200602082153.07684.zimba.tm@gmail.com> <200602130943.07482.zimba.tm@gmail.com> Message-ID: <200602131331.01406.zimba.tm@gmail.com> On Monday 13 February 2006 12:26, Michael Neumann wrote: > Am 13.02.2006 um 09:43 schrieb zimba.tm: > > On Sunday 12 February 2006 23:51, Michael Neumann wrote: > > How about additional keywords that are dependent of the database, > > like mysql's > > auto_incerment or UNSIGNED ? > > I guess this can be done with the existing implementation using > > :extra_sql (I don't remember the correct keyword). > > With :sql_type, you could write: > > property :age, Integer, :sql_type => "UNSIGNED INT" > > Or auto_increment: > > property :myid, Integer, :extra_sql => 'auto_increment' > > Even with :sql_type, we wouldn't need :length or :limit at all as we > could write: > > property :name, String, :sql_type => "VARCHAR(256)" > > But then, we could do everything directly with: > > property :name, String, :sql => "VARCHAR(256) DEFAULT '' NOT NULL" > > Regards, > > Michael > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general So what is the best ? If you have to know some SQL, why not learn all of it instead of a ruby DSL ? Aren't we loosing the pure-ruby approach there ? Also what happens if you change your store. Will you have to rewrite all your SQL for it ? To answer all those questions, I have implemented TypeCast. It is now integrated in the latest facets. Let me show you how it works : require 'facet/typecast' class SqlType class << self def from_string "VARCHAR(255)" end end end Now you should be able to cast your string to an SqlType with "my_string".cast_to(SqlType) the `cast_to` method looks for a `to_sql_type` method in the instance and then a `from_string` method in the passed class. Right now it doesn't support additional parameters and I'm not sure if it's a good idea to do this. Plus I didn't had a sactisfactional implementation for this. Using this library, you could extend SqlType for any particular store. Now you can use the generic conversion and add the store-specific changes to it. Look a little at the library and let me know what you think. In the meanwhile, I'm still working on this. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Mon Feb 13 07:32:48 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 13:32:48 +0100 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: References: Message-ID: <200602131332.48648.zimba.tm@gmail.com> On Monday 13 February 2006 13:14, George Moschovitis wrote: > > By the way, is there a reason part/ isn't a subdirectory of lib/? > > nitro/lib/part/admin/*? Rather than nitro/src/part/admin. > > There is a reason, but I am still thinking at the bes place for parts > and I dont have the time for a full anwser at the moment. Please > remind me of this before the release of Nitro 0.29.0 (planned for the > beginning of March) so we can decide a final position... I think it's nice to consider part/admin as a standalone application that you plug in your existing framework. I wish we could build various other buidling blocks like this. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From itsme213 at hotmail.com Mon Feb 13 09:15:12 2006 From: itsme213 at hotmail.com (itsme213) Date: Mon, 13 Feb 2006 08:15:12 -0600 Subject: [Nitro] Og Revisted References: <4b6f054f0602120908x342290baq910588850be69d82@mail.gmail.com> <4b6f054f0602120924r64f85c51s37a8abeaf780cdeb@mail.gmail.com> Message-ID: > See, it would be nice if all classes could be enchanted by default, > then it would be completely transparent, but as it is enchantment is > too heavy for that. But if we split "enchantment" up into two parts > then the first part could be light weight mixin front-end that just > allows one to establishes the structure --this could then be part of > all classes. The the second part would then use that structure to do > all the grunt work at runtime. > > Does that make sense? +1 Makes perfect sense to me. From zimba.tm at gmail.com Mon Feb 13 11:34:05 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Mon, 13 Feb 2006 17:34:05 +0100 Subject: [Nitro] [oree.ch] Patchset #3 Message-ID: <200602131734.05225.zimba.tm@gmail.com> Mon Feb 13 17:30:31 CET 2006 Jonas Pfenniger * Nitro::Action now import the controller's instance_vars unless a variable was already defined Nitro::Action is a generalized action that is not in the form of a method like controller's actions. This allows more flexibility for some cases. The new Nitro::Control uses this to build separate action that can be executed by other. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From rob at motionpath.com Mon Feb 13 11:58:20 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 13 Feb 2006 16:58:20 +0000 Subject: [Nitro] [PATCH] Fixes to finder method Message-ID: <1139849901.3009.46.camel@robs-p4> Fix to finder so you can pass objects to find_all_by_a_and_b for relations and so that find conditions such as set_order are honoured. P.S. Sorry for my lack of comms here lately hopefully I'll have more time soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-to-finder.patch.bz2 Type: application/x-bzip Size: 4679 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060213/ea22f8f3/attachment.bin From george.moschovitis at gmail.com Mon Feb 13 12:12:20 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 13 Feb 2006 19:12:20 +0200 Subject: [Nitro] PATCH: Og, Tests In-Reply-To: <200602131332.48648.zimba.tm@gmail.com> References: <200602131332.48648.zimba.tm@gmail.com> Message-ID: > I think it's nice to consider part/admin as a standalone application that you > plug in your existing framework. I wish we could build various other buidling > blocks like this. Exactly, in my 'plasma' framework (a high level web framework i am building on top of nitro) there is the concept of a 'root' application. Ie you can 'inherit' and 'include' webapps in your webapp like you include/inherit classes/modules in ruby classes. Will explain this better in a future mail, and i propose we staart a proper discussion about the best place to put parts then. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Mon Feb 13 16:41:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 13 Feb 2006 13:41:48 -0800 Subject: [Nitro] PATCHSET Message-ID: * dispatch_test_case Adds test for NoActionError to tc_dispatch. * prevent_multi_enchantments This patch changes _no_ external behaviour. It only rejects classes already managed in Og::Manager#manage_classes from the collection returned from Og::Manager#manageable_classes. Also adds a method Og::Manager.managed_classes which returns all classes actually managed by Og, as opposed to Og::Manager.manageable_classes which returns all classes that are capable of being managed. A subtle difference perhaps, but it bugged me. * og_thread_safe_fixes Cleans up some further problems with Og.thread_safe. Og.thread_safe is global and Og::Manager changes behaviour based off the global setting, but wasn't properly adapting to the change. As an example, if Og.thread_safe is true when a manager is created, it will create a store. If Og.thread_safe is later changed to false, it ignores the pool to use the @store instance variable that was never assigned to returning nil. This should probably be a per manager setting, where managers store the value of Og.thread_safe at the time of creation and use it for their lifetime. This would allow you to mix managers, though I don't know if anyone actually needs that. --- prevent_multi_enchantments should be clean. I checked both with both Chris' STI test and against part/admin.rb. Og test suite runs again. Rob, you might want to check out og_thread_safe_fixes. Guill's bundle made the errors I think you were getting very consistent. My bundle fixes the problem, but there's probably a better solution. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060213/41b26049/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 22138 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060213/41b26049/attachment.zip From bryan.a.soto at gmail.com Mon Feb 13 19:34:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 13 Feb 2006 16:34:21 -0800 Subject: [Nitro] part/admin b0rken? In-Reply-To: References: Message-ID: On 2/12/06, Aidan Rogers wrote: > > Hi all, > > In writing the Og/Nitro tutorial, I started using part/admin. Has > anyone else noticed it is broken in the current 0.28.0 release? I'm > getting numerous errors. It works on the surface, but when you give > it a model which has anything resembling a real-life app, there are > issues. Anyone else seen these? > > If so, please let me know. I'm aiming to track them down and supply > fixes, but don't want to duplicate effort. It therefore goes without > saying (but I'll say it anyway) if you're working on fixes for this, > please let me know :-) The only issue I'm aware of is with converting names to plural which I've logged on the Rubyforge bug tracker. Basically, the :plural_name option wasn't respected by the scaffolding. If you do find issues you can't fix or don't have time for, could you log them there or send them to the list? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060213/d50fb941/attachment.html From bryan.a.soto at gmail.com Mon Feb 13 19:42:17 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 13 Feb 2006 16:42:17 -0800 Subject: [Nitro] Bug tracking Message-ID: I know we have Aidan working on bug tracking software (Thanks Aidan!), but pending that (He's using it as the basis for documentation and writing is tough), I'd like to ask everyone to please use the bug tracking software on Rubyfoge: http://rubyforge.org/tracker/?atid=1670&group_id=418&func=browse If you are developing and plan to fix the bug yourself later, please log it there. We all forget things. Besides, you might get the pleasant surprise of finding the bug already fixed when you pull the latest changes :) If you don't develop and find a bug, it let's us know it's there and gives us a chance to fix it. Or if you'd like to help, maybe you can find something there to do. :) Many thanks, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060213/91763726/attachment.html From bryan.a.soto at gmail.com Mon Feb 13 19:58:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 13 Feb 2006 16:58:01 -0800 Subject: [Nitro] Task for the interested: No experience required :) Message-ID: Greetings, If you're interested in running Nitro, the first place you'd start is with the examples, Spark and Flare. If you're interested in helping, perhaps you can tell us if there are any problems? For example, running the blog example gives an error when trying to post a comment. That's not a good introduction. :( If anyone has the time and the interest to give the examples a good workout, please do! If you can fix it, I usually learn best by debugging, patches are cheerfully accepted. If you can't, then please log it at the rubyforge bug tracker or post it here. Thanks, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060213/a86fd886/attachment.html From zimba.tm at gmail.com Tue Feb 14 02:40:49 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 14 Feb 2006 08:40:49 +0100 Subject: [Nitro] Bug tracking In-Reply-To: References: Message-ID: <200602140840.50226.zimba.tm@gmail.com> On Tuesday 14 February 2006 01:42, Bryan Soto wrote: > I know we have Aidan working on bug tracking software (Thanks Aidan!), but > pending that (He's using it as the basis for documentation and writing is > tough), I'd like to ask everyone to please use the bug tracking software on > Rubyfoge: http://rubyforge.org/tracker/?atid=1670&group_id=418&func=browse I wish there was an rss feed for the bugs -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Tue Feb 14 02:47:08 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 14 Feb 2006 08:47:08 +0100 Subject: [Nitro] PATCHSET In-Reply-To: References: Message-ID: <200602140847.08944.zimba.tm@gmail.com> All applied On Monday 13 February 2006 22:41, Bryan Soto wrote: > * dispatch_test_case > Adds test for NoActionError to tc_dispatch. > > > * prevent_multi_enchantments > This patch changes _no_ external behaviour. It only rejects classes > already managed in Og::Manager#manage_classes from the collection returned > from Og::Manager#manageable_classes. > > Also adds a method Og::Manager.managed_classes which returns all classes > actually managed by Og, as opposed to Og::Manager.manageable_classes which > returns all classes that are capable of being managed. A subtle difference > perhaps, but it bugged me. It Og::Manager a singleton class ? Normally Og supports multiple database connections. Does it instanciate a new store or a new manager for each database ? I hope your patch doesn't break this. > * og_thread_safe_fixes [snip] -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Tue Feb 14 02:47:25 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Tue, 14 Feb 2006 08:47:25 +0100 Subject: [Nitro] [PATCH] Fixes to finder method In-Reply-To: <1139849901.3009.46.camel@robs-p4> References: <1139849901.3009.46.camel@robs-p4> Message-ID: <200602140847.25976.zimba.tm@gmail.com> Applied On Monday 13 February 2006 17:58, Rob Pitt wrote: > Fix to finder so you can pass objects to find_all_by_a_and_b for > relations and so that find conditions such as set_order are honoured. > > P.S. Sorry for my lack of comms here lately hopefully I'll have more > time soon. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From rob at motionpath.com Tue Feb 14 06:43:47 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 14 Feb 2006 11:43:47 +0000 Subject: [Nitro] [PATCH] Improvement to HTML error output Message-ID: <1139917427.3009.73.camel@robs-p4> Displays full source code extractions when your code explodes. Indenting is scruffy (I did it slap-dash) but I've been wanting this for ages so I figure you guys will like it too. Chris Farms has threatened to add links later so TextMate users can click on them to open the appropriate file in the editor at the correct line and if your editors can do this, I suggest you add links for those too! -------------- next part -------------- A non-text attachment was scrubbed... Name: html-errors.patch.bz2 Type: application/x-bzip Size: 6083 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060214/22211207/attachment.bin From george.moschovitis at gmail.com Tue Feb 14 07:14:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 14 Feb 2006 14:14:37 +0200 Subject: [Nitro] Improvement to HTML error output In-Reply-To: <1139917427.3009.73.camel@robs-p4> References: <1139917427.3009.73.camel@robs-p4> Message-ID: Great! was on my todo list for so long! Will have to investigate the change though when I am back. -g. On 2/14/06, Rob Pitt wrote: > Displays full source code extractions when your code explodes. Indenting > is scruffy (I did it slap-dash) but I've been wanting this for ages so I > figure you guys will like it too. Chris Farms has threatened to add > links later so TextMate users can click on them to open the appropriate > file in the editor at the correct line and if your editors can do this, > I suggest you add links for those too! > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Feb 14 07:22:44 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 14 Feb 2006 14:22:44 +0200 Subject: [Nitro] PATCHSET In-Reply-To: <200602140847.08944.zimba.tm@gmail.com> References: <200602140847.08944.zimba.tm@gmail.com> Message-ID: Og::Manager is not a singleton class... -g. On 2/14/06, zimba.tm wrote: > All applied > > On Monday 13 February 2006 22:41, Bryan Soto wrote: > > * dispatch_test_case > > Adds test for NoActionError to tc_dispatch. > > > > > > * prevent_multi_enchantments > > This patch changes _no_ external behaviour. It only rejects classes > > already managed in Og::Manager#manage_classes from the collection returned > > from Og::Manager#manageable_classes. > > > > Also adds a method Og::Manager.managed_classes which returns all classes > > actually managed by Og, as opposed to Og::Manager.manageable_classes which > > returns all classes that are capable of being managed. A subtle difference > > perhaps, but it bugged me. > > It Og::Manager a singleton class ? Normally Og supports multiple database > connections. Does it instanciate a new store or a new manager for each > database ? > > I hope your patch doesn't break this. > > > * og_thread_safe_fixes > [snip] > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > 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 Tue Feb 14 07:44:05 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 14 Feb 2006 12:44:05 +0000 Subject: [Nitro] [PATCH] Fixes to finder method In-Reply-To: <200602140847.25976.zimba.tm@gmail.com> References: <1139849901.3009.46.camel@robs-p4> <200602140847.25976.zimba.tm@gmail.com> Message-ID: <1139921045.3009.75.camel@robs-p4> I have found a problem with this patch, for some reason it breaks .all. I am looking into it now. On Tue, 2006-02-14 at 08:47 +0100, zimba.tm wrote: > Applied > > On Monday 13 February 2006 17:58, Rob Pitt wrote: > > Fix to finder so you can pass objects to find_all_by_a_and_b for > > relations and so that find conditions such as set_order are honoured. > > > > P.S. Sorry for my lack of comms here lately hopefully I'll have more > > time soon. > From rob at motionpath.com Tue Feb 14 08:01:11 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 14 Feb 2006 13:01:11 +0000 Subject: [Nitro] [PATCH] Fixes to finder method In-Reply-To: <1139921045.3009.75.camel@robs-p4> References: <1139849901.3009.46.camel@robs-p4> <200602140847.25976.zimba.tm@gmail.com> <1139921045.3009.75.camel@robs-p4> Message-ID: <1139922072.3009.77.camel@robs-p4> Was missing a dup - whoops. Apply this on top of the older one and all is well. On Tue, 2006-02-14 at 12:44 +0000, Rob Pitt wrote: > I have found a problem with this patch, for some reason it breaks .all. > I am looking into it now. > > On Tue, 2006-02-14 at 08:47 +0100, zimba.tm wrote: > > Applied > > > > On Monday 13 February 2006 17:58, Rob Pitt wrote: > > > Fix to finder so you can pass objects to find_all_by_a_and_b for > > > relations and so that find conditions such as set_order are honoured. > > > > > > P.S. Sorry for my lack of comms here lately hopefully I'll have more > > > time soon. > > > > _______________________________________________ > 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: finder-fix-2.patch.bz2 Type: application/x-bzip Size: 4486 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060214/fe421c81/attachment.bin From rob at motionpath.com Tue Feb 14 09:01:19 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 14 Feb 2006 14:01:19 +0000 Subject: [Nitro] [PATCH] Allow finder method to accept arrays Message-ID: <1139925679.3009.84.camel@robs-p4> I had a project where I was doing a lot of: NavigationLink.find_all_by_url('/a') So I tried to reduct the queries by doing: NavigationLink.find_all_by_url(['/a','/b']) Passing it an array where it can select multiple results. This exploded and I didn't think it should so I made this patch and you can now do this. I notice the MySQL store redefines quote (mass file search) but didn't change it so this will still explode with the MySQL store. Since nothing is lost by this, I submit the patch anyway in the knowledge the eminently capable Bryan Soto will probably sort this out in MySQL ;) Includes my earlier fix to my first patch as it hasn't appeared in glycerin yet and darcs forced me to submit it again. -------------- next part -------------- A non-text attachment was scrubbed... Name: finder-arrays.patch.bz2 Type: application/x-bzip Size: 4946 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060214/d44e52fc/attachment.bin From james_b at neurogami.com Tue Feb 14 10:58:23 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 14 Feb 2006 08:58:23 -0700 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <1139917427.3009.73.camel@robs-p4> References: <1139917427.3009.73.camel@robs-p4> Message-ID: <43F1FE1F.80303@neurogami.com> Rob Pitt wrote: > Displays full source code extractions when your code explodes. Indenting > is scruffy (I did it slap-dash) but I've been wanting this for ages so I > figure you guys will like it too. Chris Farms has threatened to add > links later so TextMate users can click on them to open the appropriate > file in the editor at the correct line and if your editors can do this, > I suggest you add links for those too! What do those links look like when the error is displayed, and is this useful or distracting for people not using TextMate? -- James Britt ?Design depends largely on constraints.? ? Charles Eames From rob at motionpath.com Tue Feb 14 11:36:40 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 14 Feb 2006 16:36:40 +0000 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <43F1FE1F.80303@neurogami.com> References: <1139917427.3009.73.camel@robs-p4> <43F1FE1F.80303@neurogami.com> Message-ID: <1139935000.3009.86.camel@robs-p4> They're not in there yet. Apply the patch and see what has changed so far. My idea of how it should work is there should be a list of icons to the right of every step of the stack trace (no text, just small icons) and if you click on the icon for your editor, it opens up the document at the correct point. I myself don't use TextMate (I use Eclipse) so if they were horrible I'd not want them either. On Tue, 2006-02-14 at 08:58 -0700, James Britt wrote: > Rob Pitt wrote: > > Displays full source code extractions when your code explodes. Indenting > > is scruffy (I did it slap-dash) but I've been wanting this for ages so I > > figure you guys will like it too. Chris Farms has threatened to add > > links later so TextMate users can click on them to open the appropriate > > file in the editor at the correct line and if your editors can do this, > > I suggest you add links for those too! > > What do those links look like when the error is displayed, and is this > useful or distracting for people not using TextMate? > > From bryan.a.soto at gmail.com Tue Feb 14 13:13:15 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 14 Feb 2006 10:13:15 -0800 Subject: [Nitro] PATCHSET In-Reply-To: <200602140847.08944.zimba.tm@gmail.com> References: <200602140847.08944.zimba.tm@gmail.com> Message-ID: On 2/13/06, zimba.tm wrote: > > All applied > > On Monday 13 February 2006 22:41, Bryan Soto wrote: > > * dispatch_test_case > > Adds test for NoActionError to tc_dispatch. > > > > > > * prevent_multi_enchantments > > This patch changes _no_ external behaviour. It only rejects classes > > already managed in Og::Manager#manage_classes from the collection > returned > > from Og::Manager#manageable_classes. > > > > Also adds a method Og::Manager.managed_classes which returns all > classes > > actually managed by Og, as opposed to Og::Manager.manageable_classeswhich > > returns all classes that are capable of being managed. A subtle > difference > > perhaps, but it bugged me. > > It Og::Manager a singleton class ? Normally Og supports multiple database > connections. Does it instanciate a new store or a new manager for each > database ? No, it's not a singleton. Each call to Og.setup creates a new manager and defines the way it persists objects. It then walks object space and manages every single class it can. So currently, if you want multiple stores, you have to define them in order: 1) Define classes for store #1. 2) Define store #1. 3) Define classes for store #2. 4) Define store #2. 5) Repeat as necessary. This is how it's worked since I got involved with Nitro/Og. I hope your patch doesn't break this. Not at all. :) It's based off of Og::Manager.managers which just walks object space to find instances of itself. It then collects the managed classes from each manager and returns the flattened array. Trust me, I value multiple stores and I've been trying to make them work well. The Og test suite wasn't running for a while because it used multiple stores. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060214/2e064224/attachment.html From james_b at neurogami.com Tue Feb 14 15:53:36 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 14 Feb 2006 13:53:36 -0700 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <1139935000.3009.86.camel@robs-p4> References: <1139917427.3009.73.camel@robs-p4> <43F1FE1F.80303@neurogami.com> <1139935000.3009.86.camel@robs-p4> Message-ID: <43F24350.1000307@neurogami.com> Rob Pitt wrote: > They're not in there yet. Apply the patch and see what has changed so > far. My idea of how it should work is there should be a list of icons to > the right of every step of the stack trace (no text, just small icons) > and if you click on the icon for your editor, it opens up the document > at the correct point. Oh, OK, this is an optional patch then. It's not like everyone has to have this cluttering their debugging info, correct? Only those who elect to apply the patch. -- James Britt From aidan at yoyo.org Tue Feb 14 17:03:16 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Wed, 15 Feb 2006 09:03:16 +1100 Subject: [Nitro] Og tutorial (part one) Message-ID: Hi all, In writing the Nitro tutorial, it quickly became obvious to me that my knowledge of Nitro isn't sufficient for the task as yet. However, my knowledge of Og is pretty good, so I've just modified the work I've done so far to be a gentle introduction to Og. (I've decided it ain't going to be a book!) http://www.infurious.com/blogs/index.php/aidan/2006/02/14/ og_tutorial_part_one Feedback appreciated. Specifically, I'd like requests as to what you'd like me to write about next :-) My current intention is to move onto more advanced settings in Og.setup (schema evolution, for example) and to introduce schema_inheritance. Aidan From rob at motionpath.com Tue Feb 14 18:02:24 2006 From: rob at motionpath.com (rob) Date: Tue, 14 Feb 2006 23:02:24 +0000 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <43F24350.1000307@neurogami.com> References: <1139917427.3009.73.camel@robs-p4> <43F1FE1F.80303@neurogami.com> <1139935000.3009.86.camel@robs-p4> <43F24350.1000307@neurogami.com> Message-ID: Consider the icons idea as a separate suggestion to this patch. I would be extremely surprised if anyone who tried this patch (not the icons) did not think it should be in Nitro but if this is the case, it doesn't alter the API or core so I'm relaxed about the general public using it - or not. If you already were referring to the just the icons, the way I envision them would not be intrusive. If this separate icons patch ever materializes, should you disagree and after seeing how they sit in the template and found their implementation to be intrusive, we would add an option to enable/disable them (with the default state being drawn from general consensus). On 14 Feb 2006, at 20:53, James Britt wrote: > Rob Pitt wrote: >> They're not in there yet. Apply the patch and see what has changed so >> far. My idea of how it should work is there should be a list of >> icons to >> the right of every step of the stack trace (no text, just small >> icons) >> and if you click on the icon for your editor, it opens up the >> document >> at the correct point. > > Oh, OK, this is an optional patch then. > > It's not like everyone has to have this cluttering their debugging > info, correct? Only those who elect to apply the patch. > > > > -- > James Britt > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Tue Feb 14 18:10:46 2006 From: rob at motionpath.com (rob) Date: Tue, 14 Feb 2006 23:10:46 +0000 Subject: [Nitro] Test-based development Message-ID: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> A valuable feature rails has that Nitro does not is support for unit tests that act like a user browsing the site. I started to construct this facility for Nitro some time ago but haven't had much time to work on it lately. If anyone (Bryan??? *g*) would like to help with this please drop me an e-mail. From rob at motionpath.com Tue Feb 14 18:14:17 2006 From: rob at motionpath.com (rob) Date: Tue, 14 Feb 2006 23:14:17 +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: <81533DC1-B3F7-4EE6-AAAE-F551D0853E32@motionpath.com> Only what I've already said, I added two methods (Nitro.live? and Nitro.fast_cgi?) to our local repo then put in my projects: Og.thread_safe = not Nitro.fast_cgi? Before doing Nitro.run as a work-around and didn't investigate it further. On 10 Feb 2006, at 22:15, 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? > > > Hi Rob, did you ever discover anything about this? I ask because, > after Guill's Og.thread_safe patch and my patch of today to make > the og test suite run again, running rake test from the og > directory causes these errors you were talking about. It's probably > something we'd be able to debug regardless since it's now > consistent, but if you have any info to give a head start with, > that'd be nice too. :) > > > _______________________________________________ > 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/20060214/3561388e/attachment.html From rob at motionpath.com Tue Feb 14 18:22:28 2006 From: rob at motionpath.com (rob) Date: Tue, 14 Feb 2006 23:22:28 +0000 Subject: [Nitro] Re-doing parts of Nitro in C In-Reply-To: References: <1137751884.9014.43.camel@robs-p4> Message-ID: <9EEF9B3B-E34B-4CF8-BEA4-55E200F340AC@motionpath.com> Sorry for the huge delay in replying to this... At the time I could not complete a run of nitro with profiler but have since realised this is probably due to the auto-reload thread hogging too much CPU when using set_trace_func (I've noticed this behavior when using our own custom tracer). I noticed the scaffold compilers use excessive CPU (one our larger projects they can often take over a minute to pre-compile at startup) and one of our very large Nitro projects hangs for a good 40 seconds on start-up on a 3 ghz zeon with 2 gig of RAM even with this disabled so there are clearly some other areas that could be improved. I suspect the PostgreSQL adapter also uses more CPU than it should since it's quite a nasty mess of patches to patches and could do with being re-done from scratch (maybe someday :)) I haven't looked too closely at the others. One idea I have had for improving template compile times is the compile could be cached, i.e the resulting code dumped to a file before evaluating it and the files updated as appropriate when the pertinent source files mtimes change. I will at some point get profiler running inside of that project (or make a different profiler...) and post you results. On 20 Jan 2006, at 11:22, George Moschovitis wrote: > 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 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From aidan at yoyo.org Tue Feb 14 18:28:11 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Wed, 15 Feb 2006 10:28:11 +1100 Subject: [Nitro] Test-based development In-Reply-To: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> Message-ID: <1D1DB62C-7348-46C3-9773-6B4F48A3DBE1@yoyo.org> Pick me! I'm a TDD nut. --- http://www.infurious.com On 15/02/2006, at 10:10 AM, rob wrote: > A valuable feature rails has that Nitro does not is support for unit > tests that act like a user browsing the site. I started to construct > this facility for Nitro some time ago but haven't had much time to > work on it lately. If anyone (Bryan??? *g*) would like to help with > this please drop me an e-mail. > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From itsme213 at hotmail.com Tue Feb 14 22:37:03 2006 From: itsme213 at hotmail.com (itsme213) Date: Tue, 14 Feb 2006 21:37:03 -0600 Subject: [Nitro] Og tutorial (part one) References: Message-ID: This is really nicely written and very helpful. Thanks so much! One question: how does the rule for naming join tables handle the case when one has more than one many_to_many relation between the same 2 classes (using different attribute names). ----- Original Message ----- From: "Aidan Rogers" To: "General discussion about Nitro" Sent: Tuesday, February 14, 2006 4:03 PM Subject: [Nitro] Og tutorial (part one) > Hi all, > > In writing the Nitro tutorial, it quickly became obvious to me that > my knowledge of Nitro isn't sufficient for the task as yet. However, > my knowledge of Og is pretty good, so I've just modified the work > I've done so far to be a gentle introduction to Og. (I've decided it > ain't going to be a book!) > > http://www.infurious.com/blogs/index.php/aidan/2006/02/14/ > og_tutorial_part_one > > Feedback appreciated. Specifically, I'd like requests as to what > you'd like me to write about next :-) My current intention is to > move onto more advanced settings in Og.setup (schema evolution, for > example) and to introduce schema_inheritance. > > Aidan > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From itsme213 at hotmail.com Tue Feb 14 22:41:06 2006 From: itsme213 at hotmail.com (itsme213) Date: Tue, 14 Feb 2006 21:41:06 -0600 Subject: [Nitro] [PATCH] Improvement to HTML error output References: <1139917427.3009.73.camel@robs-p4> <43F1FE1F.80303@neurogami.com><1139935000.3009.86.camel@robs-p4> <43F24350.1000307@neurogami.com> Message-ID: > If you already were referring to the just the icons, the way I > envision them would not be intrusive. If this separate icons patch > ever materializes, should you disagree and after seeing how they sit > in the template and found their implementation to be intrusive, we > would add an option to enable/disable them Just CSS might suffice. Though I doubt anyone would want to disable this. From zimba.tm at gmail.com Wed Feb 15 05:13:04 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 15 Feb 2006 11:13:04 +0100 Subject: [Nitro] [PATCH] Allow finder method to accept arrays In-Reply-To: <1139925679.3009.84.camel@robs-p4> References: <1139925679.3009.84.camel@robs-p4> Message-ID: <200602151113.05207.zimba.tm@gmail.com> Applied On Tuesday 14 February 2006 15:01, Rob Pitt wrote: > I had a project where I was doing a lot of: > > NavigationLink.find_all_by_url('/a') > > So I tried to reduct the queries by doing: > > NavigationLink.find_all_by_url(['/a','/b']) > > Passing it an array where it can select multiple results. This exploded > and I didn't think it should so I made this patch and you can now do > this. > > I notice the MySQL store redefines quote (mass file search) but didn't > change it so this will still explode with the MySQL store. Since nothing > is lost by this, I submit the patch anyway in the knowledge the > eminently capable Bryan Soto will probably sort this out in MySQL ;) > > Includes my earlier fix to my first patch as it hasn't appeared in > glycerin yet and darcs forced me to submit it again. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Wed Feb 15 05:13:14 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 15 Feb 2006 11:13:14 +0100 Subject: [Nitro] [PATCH] Fixes to finder method In-Reply-To: <1139922072.3009.77.camel@robs-p4> References: <1139849901.3009.46.camel@robs-p4> <1139921045.3009.75.camel@robs-p4> <1139922072.3009.77.camel@robs-p4> Message-ID: <200602151113.14051.zimba.tm@gmail.com> Applied On Tuesday 14 February 2006 14:01, Rob Pitt wrote: > Was missing a dup - whoops. Apply this on top of the older one and all > is well. > > On Tue, 2006-02-14 at 12:44 +0000, Rob Pitt wrote: > > I have found a problem with this patch, for some reason it breaks .all. > > I am looking into it now. > > > > On Tue, 2006-02-14 at 08:47 +0100, zimba.tm wrote: > > > Applied > > > > > > On Monday 13 February 2006 17:58, Rob Pitt wrote: > > > > Fix to finder so you can pass objects to find_all_by_a_and_b for > > > > relations and so that find conditions such as set_order are honoured. > > > > > > > > P.S. Sorry for my lack of comms here lately hopefully I'll have more > > > > time soon. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Wed Feb 15 05:13:20 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 15 Feb 2006 11:13:20 +0100 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <1139917427.3009.73.camel@robs-p4> References: <1139917427.3009.73.camel@robs-p4> Message-ID: <200602151113.20658.zimba.tm@gmail.com> Applied On Tuesday 14 February 2006 12:43, Rob Pitt wrote: > Displays full source code extractions when your code explodes. Indenting > is scruffy (I did it slap-dash) but I've been wanting this for ages so I > figure you guys will like it too. Chris Farms has threatened to add > links later so TextMate users can click on them to open the appropriate > file in the editor at the correct line and if your editors can do this, > I suggest you add links for those too! -- Cheers, zimba.tm weblog : http://zimba.oree.ch From eduardorochabr at gmail.com Wed Feb 15 07:07:02 2006 From: eduardorochabr at gmail.com (Eduardo Rocha) Date: Wed, 15 Feb 2006 09:07:02 -0300 Subject: [Nitro] Test-based development In-Reply-To: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> Message-ID: Is that really like a user browsing the site? Actually, I am not that fan of Rails controller testing, because it can only tests the controller receive the parameters, like post :update, :person => {:name => 'John', :age => '34'} and it does not take into account the real page that contains the form. The frameworks that act like a user browsing the site are Watir and Selenium, that are appart from Rails. Am I missing something? 2006/2/14, rob : > A valuable feature rails has that Nitro does not is support for unit > tests that act like a user browsing the site. I started to construct > this facility for Nitro some time ago but haven't had much time to > work on it lately. If anyone (Bryan??? *g*) would like to help with > this please drop me an e-mail. > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From kashia at vfemail.net Wed Feb 15 07:56:16 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 15 Feb 2006 13:56:16 +0100 Subject: [Nitro] Test-based development In-Reply-To: References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> Message-ID: Hi, > Is that really like a user browsing the site? I don't know how Watir/Selenium/Rails works in case of testing sites, but maybe one could use WWW::Mechanize to hack some web-page testing/traversing utility together. Mechanize works with the html, no "fake sending" of forms, you "fill 'em" like you normally would. http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc and some additional Info for working with it: http://www.adras.com/web-testing-with-Ruby.t37-48-1.html http://www.zenspider.com/pipermail/ruby/2005-July/002068.html There doesn't seem so much information about it at all, but someone might be interested :) Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From zimba.tm at gmail.com Wed Feb 15 08:57:54 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Wed, 15 Feb 2006 14:57:54 +0100 Subject: [Nitro] [oree.ch] New patch Message-ID: <200602151457.54374.zimba.tm@gmail.com> Fed Feb 15 14:44:04 CET 2006 Jonas Pfenniger * Taggable: Moved the Tag class in the Glue namespace I wanted to avoid name collisions (with Narf::Mechanize). I also corrected spark so make sure to backup your database before upgrading. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From kashia at vfemail.net Wed Feb 15 09:08:43 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 15 Feb 2006 15:08:43 +0100 Subject: [Nitro] Og conflicts with Narf (Mechanize) Message-ID: Hello, Tag vs Tag in Narf: web/tagparser.rb So you can't run Mechanize/Narf with a Nitro/Og application with an "is Taggable" class. I ran into Zimba on the IRC channel and he did a quick fix for me, he just moved the Tag class into the Glue namespace. This now prevents those two from clashing, but I'm not entirely convinced that this is the correct way, since this changes the database table name from ogtag to ogglue_tag. I don't know how many applications that would break (although it can be fixed easily) [14:55] also, for your table problem, you should be able to set it by hand. [14:56] you just have to reopen the Glue::Tag class and set the table_name what do you think about the issue? Zimba pointed out that it's not good idea to pollute the global namespace, which I agree to. Kash -- Feel the love http://pinkjuice.com/pics/ruby.png From rob at motionpath.com Wed Feb 15 10:18:52 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 15 Feb 2006 15:18:52 +0000 Subject: [Nitro] Og conflicts with Narf (Mechanize) In-Reply-To: References: Message-ID: <1140016732.28528.1.camel@robs-p4> I've mentioned this before (polluting the global namespace) and even provided a patch to remove Glue from the global namespace. I agree it's a bad idea, but George really likes it and my final position is it should be an option (enabled by default, but you may disable, which my patch provided for and has been running here in production with no issues so far). On Wed, 2006-02-15 at 15:08 +0100, Kashia Buch wrote: > Hello, > > Tag vs Tag > > in Narf: web/tagparser.rb > > So you can't run Mechanize/Narf with a Nitro/Og application with an "is Taggable" class. > > I ran into Zimba on the IRC channel and he did a quick fix for me, he just moved the Tag class into the Glue namespace. > This now prevents those two from clashing, but I'm not entirely convinced that this is the correct way, since this changes the database table name from ogtag to ogglue_tag. > I don't know how many applications that would break (although it can be fixed easily) > > [14:55] also, for your table problem, you should be able to set it by hand. > [14:56] you just have to reopen the Glue::Tag class and set the table_name > > what do you think about the issue? > Zimba pointed out that it's not good idea to pollute the global namespace, which I agree to. > > Kash > From rob at motionpath.com Wed Feb 15 10:23:56 2006 From: rob at motionpath.com (Rob Pitt) Date: Wed, 15 Feb 2006 15:23:56 +0000 Subject: [Nitro] Test-based development In-Reply-To: References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> Message-ID: <1140017036.28528.7.camel@robs-p4> I prefer the "fake sending" of forms and such as you can easily read session, request, etc to see if everything went as it should. No doubt mechanize could be hacked to do this, but I do not see the detraction of only sending POST data as a method (Eduardo mentioned it's not taking into account the real page) because you can visually very easily see if a page doesn't look like it should and would quickly notice incorrectly named fields (this isn't an error I've made before). On the other hand, it would be possible to create a "supervisor" process that managed both the app and mechanize or a thread within the app that ran mechanized on itself. I do not see there is a great benefit considering the extra complexity, it's a small benefit but is it worth the extra trouble to implement it like this? Would like more opinions here. On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote: > Hi, > > > Is that really like a user browsing the site? > > I don't know how Watir/Selenium/Rails works in case of testing sites, but maybe one could use WWW::Mechanize to hack some web-page testing/traversing utility together. > Mechanize works with the html, no "fake sending" of forms, you "fill 'em" like you normally would. > > http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc > > and some additional Info for working with it: > http://www.adras.com/web-testing-with-Ruby.t37-48-1.html > http://www.zenspider.com/pipermail/ruby/2005-July/002068.html > > There doesn't seem so much information about it at all, but someone might be interested :) > > > Kash > From eduardorochabr at gmail.com Wed Feb 15 10:59:27 2006 From: eduardorochabr at gmail.com (Eduardo Rocha) Date: Wed, 15 Feb 2006 12:59:27 -0300 Subject: [Nitro] Test-based development In-Reply-To: <1140017036.28528.7.camel@robs-p4> References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> <1140017036.28528.7.camel@robs-p4> Message-ID: 2006/2/15, Rob Pitt : > I prefer the "fake sending" of forms and such as you can easily read > session, request, etc to see if everything went as it should. No doubt > mechanize could be hacked to do this, but I do not see the detraction of > only sending POST data as a method (Eduardo mentioned it's not taking > into account the real page) because you can visually very easily see if > a page doesn't look like it should and would quickly notice incorrectly > named fields (this isn't an error I've made before). > I don't know if I understand you correctly, but I often fall into the mistake of passing the controller test (in Rails) and then I get an error testing in the browser, just because the form field names were diferent from the test. And yet I can do visually, I think it breaks the idea of TDD and automated tests. > On the other hand, it would be possible to create a "supervisor" process > that managed both the app and mechanize or a thread within the app that > ran mechanized on itself. I do not see there is a great benefit > considering the extra complexity, it's a small benefit but is it worth > the extra trouble to implement it like this? > Concerning Watir/Selenium/Mechanize, my opinion is that features from Mechanize are very similar to Watir/Selenium, but are run outside the browser. I think this is not better or worse, because some people would prefer running this kind of test before running in browser. But with Mechanize you are using HTTP to test your app, which can slow down test (if one is that paranoic :) and it is not "that" pure. In Rails, for example, instead of passing parameters directly, it would be nice if we could start from the page (instead of a URL, in the case of Mechanize), and we associate the form fields with values (like Mechanize does, as well as Watir/Selenium). > Would like more opinions here. > > On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote: > > Hi, > > > > > Is that really like a user browsing the site? > > > > I don't know how Watir/Selenium/Rails works in case of testing sites, but maybe one could use WWW::Mechanize to hack some web-page testing/traversing utility together. > > Mechanize works with the html, no "fake sending" of forms, you "fill 'em" like you normally would. > > > > http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc > > > > and some additional Info for working with it: > > http://www.adras.com/web-testing-with-Ruby.t37-48-1.html > > http://www.zenspider.com/pipermail/ruby/2005-July/002068.html > > > > There doesn't seem so much information about it at all, but someone might be interested :) > > > > > > Kash > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From bryan.a.soto at gmail.com Wed Feb 15 14:45:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 11:45:21 -0800 Subject: [Nitro] Og conflicts with Narf (Mechanize) In-Reply-To: <1140016732.28528.1.camel@robs-p4> References: <1140016732.28528.1.camel@robs-p4> Message-ID: On 2/15/06, Rob Pitt wrote: > > I've mentioned this before (polluting the global namespace) and even > provided a patch to remove Glue from the global namespace. I agree it's > a bad idea, but George really likes it and my final position is it > should be an option (enabled by default, but you may disable, which my > patch provided for and has been running here in production with no > issues so far). > > Just to be clear to everyone, all the patch does is make Nitro/Og work when $GLUE_DONT_INCLUDE is set to true, correct? Right now I believe you get errors because all the library code assumes Glue is in the global namespace, i.e. refers to Aspect rather than Glue::Aspect. It doesn't change the default behaviour, it just fixes a bug where Nitro and Og didn't work correctly when that global was true. I have the original email and patch. I'll see if it applies cleanly, and if so, resend it for inclusion. I'll also re-send a patch from Michael Neuman which seems to have been missed. bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/c2ef0d8d/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 14:55:04 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 11:55:04 -0800 Subject: [Nitro] Test-based development In-Reply-To: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> Message-ID: On 2/14/06, rob wrote: > > A valuable feature rails has that Nitro does not is support for unit > tests that act like a user browsing the site. I started to construct > this facility for Nitro some time ago but haven't had much time to > work on it lately. If anyone (Bryan??? *g*) would like to help with > this please drop me an e-mail. > Sure, I'd like to help. Do you have a public repo for the code? Or are you still in the design over beer stage? :) bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/b0e7311e/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 15:19:39 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 12:19:39 -0800 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <1139917427.3009.73.camel@robs-p4> References: <1139917427.3009.73.camel@robs-p4> Message-ID: On 2/14/06, Rob Pitt wrote: > > Displays full source code extractions when your code explodes. Indenting > is scruffy (I did it slap-dash) but I've been wanting this for ages so I For what it's worth, I like it. For those who haven't tried it, It makes the error page clearer as it actually shows the relevant sections of code where your error occurs. I'll see if I can get a screenshot today. figure you guys will like it too. Chris Farms has threatened to add > links later so TextMate users can click on them to open the appropriate > file in the editor at the correct line and if your editors can do this, > I suggest you add links for those too! > Rather than editor links, how about popping up a new browser window with the file contents in a text area. For simple fixes like typos, it'd be cool to just save and refresh the page. Then we can just proceed, step by step, to being able to do everything in the web browser like Avi's Seaside... ;) bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/861dd47c/attachment.html From mischa.kroon at gmail.com Wed Feb 15 15:25:35 2006 From: mischa.kroon at gmail.com (Mischa Kroon) Date: Wed, 15 Feb 2006 21:25:35 +0100 Subject: [Nitro] [PATCH] Improvement to HTML error output References: <1139917427.3009.73.camel@robs-p4> Message-ID: <004a01c6326d$fcec5a90$0a01a8c0@mischabak> ----- Original Message ----- Rather than editor links, how about popping up a new browser window with the file contents in a text area. For simple fixes like typos, it'd be cool to just save and refresh the page. Then we can just proceed, step by step, to being able to do everything in the web browser like Avi's Seaside... ;) bryan Wow that sounds extremely cool :) And maybe indeed it can be a config driven setting to set up the error page linking to texteditor of choice. Allthough you might want to restrict this setting to local ip address only by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/5f6065ab/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 15:28:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 12:28:24 -0800 Subject: [Nitro] [PATCH] Allow finder method to accept arrays In-Reply-To: <1139925679.3009.84.camel@robs-p4> References: <1139925679.3009.84.camel@robs-p4> Message-ID: On 2/14/06, Rob Pitt wrote: > > I notice the MySQL store redefines quote (mass file search) but didn't > change it so this will still explode with the MySQL store. Since nothing > is lost by this, I submit the patch anyway in the knowledge the > eminently capable Bryan Soto will probably sort this out in MySQL ;) After being described like that, how can I refuse. :P Unless I'm missing something, the definition of quote in MysqlUtils was a copy of what was in SqlUtils. So I'm thinking to just let it use what's defined in SqlUtils. Do you have a test case perhaps so I can make sure that's not a bad decision before I send in a patch? bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/c7a41852/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 15:43:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 12:43:52 -0800 Subject: [Nitro] [PATCH] Improvement to HTML error output In-Reply-To: <004a01c6326d$fcec5a90$0a01a8c0@mischabak> References: <1139917427.3009.73.camel@robs-p4> <004a01c6326d$fcec5a90$0a01a8c0@mischabak> Message-ID: On 2/15/06, Mischa Kroon wrote: > > > > ----- Original Message ----- > > Rather than editor links, how about popping up a new browser window with > the file contents in a text area. For simple fixes like typos, it'd be cool > to just save and refresh the page. Then we can just proceed, step by step, > to being able to do everything in the web browser like Avi's Seaside... ;) > > bryan > > > Wow that sounds extremely cool :) > Benefits of Smalltalk being image based rather than file based, I guess, though I don't believe it's used very much. I suppose since you already have access to the Smalltalk environment, why bother using anything else. :) > And maybe indeed it can be a config driven setting to set up the error > page linking to texteditor of choice. Allthough you might want to restrict > this setting to local ip address only by default. > First, you'd have to get Chris to follow through on the threat and write it in the first place. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/d74578f9/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 16:08:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 13:08:56 -0800 Subject: [Nitro] [Resend] [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: This patch applies cleanly against current repository. Tests fail when $GLUE_DONT_INCLUDE = true. Basically, things like class User is Orderable end need to be changed to class User is Glue::Orderable end because 'is' acts like an alias to include. So, from a user perspective, this won't break anything as it doesn't change the default. If you do need to set the flag, you will either need to specify the full namespace in the is method, or include Glue::Orderable in your namespace. Again, this doesn't change anything *unless* you set $GLUE_DONT_INCLUDE to true before requiring glue. Any comments? Bryan ---------- Forwarded message ---------- From: Rob Pitt Date: Jan 25, 2006 9:04 AM Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's name space (fixes XML Builder name clash problems, etc). To: General discussion about Nitro 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 _______________________________________________ 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/20060215/b50d9865/attachment.html -------------- 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/20060215/b50d9865/attachment.bin From bryan.a.soto at gmail.com Wed Feb 15 16:23:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 13:23:52 -0800 Subject: [Nitro] Re-doing parts of Nitro in C In-Reply-To: <9EEF9B3B-E34B-4CF8-BEA4-55E200F340AC@motionpath.com> References: <1137751884.9014.43.camel@robs-p4> <9EEF9B3B-E34B-4CF8-BEA4-55E200F340AC@motionpath.com> Message-ID: On 2/14/06, rob wrote: > > Sorry for the huge delay in replying to this... > > At the time I could not complete a run of nitro with profiler but > have since realised this is probably due to the auto-reload thread > hogging too much CPU when using set_trace_func (I've noticed this > behavior when using our own custom tracer). I noticed the scaffold > compilers use excessive CPU (one our larger projects they can often > take over a minute to pre-compile at startup) and one of our very > large Nitro projects hangs for a good 40 seconds on start-up on a 3 > ghz zeon with 2 gig of RAM even with this disabled so there are > clearly some other areas that could be improved. Useless speculation makes me think that's probably walking object space for manageable classes and checks against the database for schema evolution purposes. That's probably a big cost for you since, I recall, some of your apps have 30+ tables? Of course, the first rule of optimizing without hard numbers is, 'Whatever you're thinking is wrong'. ;) I suspect the PostgreSQL adapter also uses more CPU than it should > since it's quite a nasty mess of patches to patches and could do with > being re-done from scratch (maybe someday :)) I haven't looked too > closely at the others. They could all do with a rewrite, yes. :) Or at least some refactoring. A lot of things can be pushed up to the superclass. One idea I have had for improving template compile times is the > compile could be cached, i.e the resulting code dumped to a file > before evaluating it and the files updated as appropriate when the > pertinent source files mtimes change. Interesting thought. I wonder how much of a gain that would get you... I will at some point get profiler running inside of that project (or > make a different profiler...) and post you results. > > On 20 Jan 2006, at 11:22, George Moschovitis wrote: > > > 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 > > > > _______________________________________________ > > 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/20060215/976a5431/attachment.html From bryan.a.soto at gmail.com Wed Feb 15 16:28:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 15 Feb 2006 13:28:08 -0800 Subject: [Nitro] Fwd: [ nitro-Bugs-3556 ] part/admin does not respond well to array controls In-Reply-To: <200602140102.k1E12W08017326@rubyforge.org> References: <200602140102.k1E12W08017326@rubyforge.org> Message-ID: Not quite an RSS feed. :/ zimbu, Chris, what do you think? I believe you guys did some work on the controls? bryan ---------- Forwarded message ---------- From: noreply at rubyforge.org Date: Feb 13, 2006 5:02 PM Subject: [ nitro-Bugs-3556 ] part/admin does not respond well to array controls To: noreply at rubyforge.org Bugs item #3556, was opened at 2006-02-13 20:02 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3556&group_id=418 Category: Nitro Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: part/admin does not respond well to array controls Initial Comment: Steps to reproduce: 1. Create a model which has an Array property 2. Require 'nitro', 'og' and 'part/admin' 3. Start your web server 4. Go to the /admin and click on your model 5. Try to create a new instance of your model class, and you should get this error: undefined local variable or method `emit_container_start' for # /usr/local/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/helper/form/controls.rb:170:in `render' Patch to fix might be (someone needs to sanity check) --- /usr/local/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/helper/form/controls.rb 2006-02-14 11:55:21.000000000 +1100 +++ - 2006-02-14 12:05:57.000000000 +1100 @@ -192,6 +192,14 @@ } end + def emit_container_start + %{
} + end + + def emit_container_end + %{
} + end + def emit_js %{ } The second part of the patch is because the remove array element button didn't activate due to the off by one error. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3556&group_id=418 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/4a484487/attachment.html From rob at motionpath.com Wed Feb 15 16:39:07 2006 From: rob at motionpath.com (rob) Date: Wed, 15 Feb 2006 21:39:07 +0000 Subject: [Nitro] [Resend] [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: People using those include aliases is a good argument for keeping the default as it is (including glue into default namespace). I know everyone loves syntactic maple-syrup ;) I would recommend the tests do get changed (since it works in both situations with the second example) but examples do not. Possibly the whole test should be run with the $GLUE_DONT_INCLUDE global in both states now and again to see it's all working correctly? I would like to see this change in general Glycerin/Nitro as it makes it co-exist with other libraries much better (something I can remember at least two complaints of - GTK/XML Builder, in addition to my own problems). If at this stage it is an issue, imagine what a PITA it would be if/when Nitro is more mainstream. Even though we've been running it in a couple of production projects since shortly after I came up with it, I'm still not convinced a patch generated with sed commands does't need further testing by clever people before it does (hopefully) become part of Nitro... On 15 Feb 2006, at 21:08, Bryan Soto wrote: > This patch applies cleanly against current repository. > > Tests fail when $GLUE_DONT_INCLUDE = true. Basically, things like > class User > is Orderable > end > > need to be changed to > > class User > is Glue::Orderable > end > > because 'is' acts like an alias to include. > > So, from a user perspective, this won't break anything as it > doesn't change the default. If you do need to set the flag, you > will either need to specify the full namespace in the is method, or > include Glue::Orderable in your namespace. > > Again, this doesn't change anything *unless* you set > $GLUE_DONT_INCLUDE to true before requiring glue. > > Any comments? > > Bryan > > ---------- Forwarded message ---------- > From: Rob Pitt > Date: Jan 25, 2006 9:04 AM > Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in > Object's name space (fixes XML Builder name clash problems, etc). > To: General discussion about Nitro > > 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 > > > _______________________________________________ > 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/20060215/00de3a34/attachment.html From aidan at yoyo.org Wed Feb 15 16:57:38 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 16 Feb 2006 08:57:38 +1100 Subject: [Nitro] Test-based development In-Reply-To: References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> <1140017036.28528.7.camel@robs-p4> Message-ID: <711CA5E4-DB51-48C7-9230-5F93533C5EC1@yoyo.org> Lots of things to respond to in this thread, but I think overall you guys are talking about 2 different levels of testing. Rob is talking about unit testing the controller code; Eduardo is talking about functional/integration testing. Both are valid and necessary forms of testing, and are not mutually exclusive. For example, I recently wrote a Rails app as part of my day job, and wrote unit tests for the model and controllers. One of our testers then did the functional/integration (pick your favourite term in this case - everyone interprets test types as different things on different days in different projects) testing which involved the actual browser and pointing and clicking. I think it would be really useful to create an automated way to unit test both models and controllers. I think it would be as valuable to integrate with Selenium in some way, not only to create the ability to functionally test Nitro apps, but also so I can evangelise Nitro to all the Selenium guys at ThoughtWorks - these guys are the sorts of people with enough community clout to start generating real press for Nitro. Aidan --- http://www.infurious.com On 16/02/2006, at 2:59 AM, Eduardo Rocha wrote: > 2006/2/15, Rob Pitt : >> I prefer the "fake sending" of forms and such as you can easily read >> session, request, etc to see if everything went as it should. No >> doubt >> mechanize could be hacked to do this, but I do not see the >> detraction of >> only sending POST data as a method (Eduardo mentioned it's not taking >> into account the real page) because you can visually very easily >> see if >> a page doesn't look like it should and would quickly notice >> incorrectly >> named fields (this isn't an error I've made before). >> > > I don't know if I understand you correctly, but I often fall into the > mistake of passing the controller test (in Rails) and then I get an > error testing in the browser, just because the form field names were > diferent from the test. And yet I can do visually, I think it breaks > the idea of TDD and automated tests. > >> On the other hand, it would be possible to create a "supervisor" >> process >> that managed both the app and mechanize or a thread within the app >> that >> ran mechanized on itself. I do not see there is a great benefit >> considering the extra complexity, it's a small benefit but is it >> worth >> the extra trouble to implement it like this? >> > > Concerning Watir/Selenium/Mechanize, my opinion is that features from > Mechanize are very similar to Watir/Selenium, but are run outside the > browser. I think this is not better or worse, because some people > would prefer running this kind of test before running in browser. But > with Mechanize you are using HTTP to test your app, which can slow > down test (if one is that paranoic :) and it is not "that" pure. > > In Rails, for example, instead of passing parameters directly, it > would be nice if we could start from the page (instead of a URL, in > the case of Mechanize), and we associate the form fields with values > (like Mechanize does, as well as Watir/Selenium). > >> Would like more opinions here. >> >> On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote: >>> Hi, >>> >>>> Is that really like a user browsing the site? >>> >>> I don't know how Watir/Selenium/Rails works in case of testing >>> sites, but maybe one could use WWW::Mechanize to hack some web- >>> page testing/traversing utility together. >>> Mechanize works with the html, no "fake sending" of forms, you >>> "fill 'em" like you normally would. >>> >>> http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc >>> >>> and some additional Info for working with it: >>> http://www.adras.com/web-testing-with-Ruby.t37-48-1.html >>> http://www.zenspider.com/pipermail/ruby/2005-July/002068.html >>> >>> There doesn't seem so much information about it at all, but >>> someone might be interested :) >>> >>> >>> Kash >>> >> >> _______________________________________________ >> 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 eduardorochabr at gmail.com Wed Feb 15 17:29:16 2006 From: eduardorochabr at gmail.com (Eduardo Rocha) Date: Wed, 15 Feb 2006 19:29:16 -0300 Subject: [Nitro] Test-based development In-Reply-To: <711CA5E4-DB51-48C7-9230-5F93533C5EC1@yoyo.org> References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> <1140017036.28528.7.camel@robs-p4> <711CA5E4-DB51-48C7-9230-5F93533C5EC1@yoyo.org> Message-ID: 2006/2/15, Aidan Rogers : > Lots of things to respond to in this thread, but I think overall you > guys are talking about 2 different levels of testing. > > Rob is talking about unit testing the controller code; Eduardo is > talking about functional/integration testing. Both are valid and > necessary forms of testing, and are not mutually exclusive. Aidan, actually I am talking mostly about unit testing the controller, which Rails itself calls functional test. > For example, I recently wrote a Rails app as part of my day job, and > wrote unit tests for the model and controllers. One of our testers > then did the functional/integration (pick your favourite term in this > case - everyone interprets test types as different things on > different days in different projects) testing which involved the > actual browser and pointing and clicking. In fact, this different names of testing confuses every one! Particularly, I would call Rails controller tests as integration tests, and Watir/Selenium functional tests. The problem with Rails tests is that it ignores the view with the form, which can only be tested manually or with tools like Watir/Selenium. > > I think it would be really useful to create an automated way to unit > test both models and controllers. I think it would be as valuable to > integrate with Selenium in some way, not only to create the ability > to functionally test Nitro apps, but also so I can evangelise Nitro > to all the Selenium guys at ThoughtWorks - these guys are the sorts > of people with enough community clout to start generating real press > for Nitro. > My opinion here is that Selenium can stay appart from Nitro, as a functional test tool, knowing nothing about Nitro code. Nitro test framework could improve on Rails using the view as a way of inputing parameters, but also not using HTTP. > Aidan > --- > http://www.infurious.com > > > On 16/02/2006, at 2:59 AM, Eduardo Rocha wrote: > > > 2006/2/15, Rob Pitt : > >> I prefer the "fake sending" of forms and such as you can easily read > >> session, request, etc to see if everything went as it should. No > >> doubt > >> mechanize could be hacked to do this, but I do not see the > >> detraction of > >> only sending POST data as a method (Eduardo mentioned it's not taking > >> into account the real page) because you can visually very easily > >> see if > >> a page doesn't look like it should and would quickly notice > >> incorrectly > >> named fields (this isn't an error I've made before). > >> > > > > I don't know if I understand you correctly, but I often fall into the > > mistake of passing the controller test (in Rails) and then I get an > > error testing in the browser, just because the form field names were > > diferent from the test. And yet I can do visually, I think it breaks > > the idea of TDD and automated tests. > > > >> On the other hand, it would be possible to create a "supervisor" > >> process > >> that managed both the app and mechanize or a thread within the app > >> that > >> ran mechanized on itself. I do not see there is a great benefit > >> considering the extra complexity, it's a small benefit but is it > >> worth > >> the extra trouble to implement it like this? > >> > > > > Concerning Watir/Selenium/Mechanize, my opinion is that features from > > Mechanize are very similar to Watir/Selenium, but are run outside the > > browser. I think this is not better or worse, because some people > > would prefer running this kind of test before running in browser. But > > with Mechanize you are using HTTP to test your app, which can slow > > down test (if one is that paranoic :) and it is not "that" pure. > > > > In Rails, for example, instead of passing parameters directly, it > > would be nice if we could start from the page (instead of a URL, in > > the case of Mechanize), and we associate the form fields with values > > (like Mechanize does, as well as Watir/Selenium). > > > >> Would like more opinions here. > >> > >> On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote: > >>> Hi, > >>> > >>>> Is that really like a user browsing the site? > >>> > >>> I don't know how Watir/Selenium/Rails works in case of testing > >>> sites, but maybe one could use WWW::Mechanize to hack some web- > >>> page testing/traversing utility together. > >>> Mechanize works with the html, no "fake sending" of forms, you > >>> "fill 'em" like you normally would. > >>> > >>> http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc > >>> > >>> and some additional Info for working with it: > >>> http://www.adras.com/web-testing-with-Ruby.t37-48-1.html > >>> http://www.zenspider.com/pipermail/ruby/2005-July/002068.html > >>> > >>> There doesn't seem so much information about it at all, but > >>> someone might be interested :) > >>> > >>> > >>> Kash > >>> > >> > >> _______________________________________________ > >> 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 > From zimba.tm at gmail.com Thu Feb 16 02:32:34 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 16 Feb 2006 08:32:34 +0100 Subject: [Nitro] [Resend] [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: <200602160832.34636.zimba.tm@gmail.com> Applied This looks like a reasonable patch to start with. We could also change the "is" method to look in the Glue namespace when a symbol is passed. I don't like that the Glue namespace is used to put anything inside it. We should try to part the classes in other namespaces. On Wednesday 15 February 2006 22:08, Bryan Soto wrote: > This patch applies cleanly against current repository. > > Tests fail when $GLUE_DONT_INCLUDE = true. Basically, things like > class User > is Orderable > end > > need to be changed to > > class User > is Glue::Orderable > end > > because 'is' acts like an alias to include. > > So, from a user perspective, this won't break anything as it doesn't change > the default. If you do need to set the flag, you will either need to > specify the full namespace in the is method, or include Glue::Orderable in > your namespace. > > Again, this doesn't change anything *unless* you set $GLUE_DONT_INCLUDE to > true before requiring glue. > > Any comments? > > Bryan > > ---------- Forwarded message ---------- > From: Rob Pitt > Date: Jan 25, 2006 9:04 AM > Subject: [Nitro] [PATCH] Nitro shouldn't rely on Glue being in Object's > name space (fixes XML Builder name clash problems, etc). > To: General discussion about Nitro > > 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:5 > >6 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:5 > >3 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 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Cheers, zimba.tm weblog : http://zimba.oree.ch From george.moschovitis at gmail.com Thu Feb 16 07:51:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 16 Feb 2006 14:51:23 +0200 Subject: [Nitro] Test-based development In-Reply-To: References: <753694DF-100C-43D1-90E9-AA198A939D9D@motionpath.com> <1140017036.28528.7.camel@robs-p4> <711CA5E4-DB51-48C7-9230-5F93533C5EC1@yoyo.org> Message-ID: Nitro supports test driven development. In fact it 'borrows' testing ideas from Rails. Have a look at: lib/nitro/test lib/og/test Also have a look at spark/test to see how to use these features. Of course the testing features could be improved. So send in your patches. -g. On 2/16/06, Eduardo Rocha wrote: > 2006/2/15, Aidan Rogers : > > Lots of things to respond to in this thread, but I think overall you > > guys are talking about 2 different levels of testing. > > > > Rob is talking about unit testing the controller code; Eduardo is > > talking about functional/integration testing. Both are valid and > > necessary forms of testing, and are not mutually exclusive. > > Aidan, actually I am talking mostly about unit testing the controller, > which Rails itself calls functional test. > > > For example, I recently wrote a Rails app as part of my day job, and > > wrote unit tests for the model and controllers. One of our testers > > then did the functional/integration (pick your favourite term in this > > case - everyone interprets test types as different things on > > different days in different projects) testing which involved the > > actual browser and pointing and clicking. > > In fact, this different names of testing confuses every one! > Particularly, I would call Rails controller tests as integration > tests, and Watir/Selenium functional tests. The problem with Rails > tests is that it ignores the view with the form, which can only be > tested manually or with tools like Watir/Selenium. > > > > > I think it would be really useful to create an automated way to unit > > test both models and controllers. I think it would be as valuable to > > integrate with Selenium in some way, not only to create the ability > > to functionally test Nitro apps, but also so I can evangelise Nitro > > to all the Selenium guys at ThoughtWorks - these guys are the sorts > > of people with enough community clout to start generating real press > > for Nitro. > > > > My opinion here is that Selenium can stay appart from Nitro, as a > functional test tool, knowing nothing about Nitro code. Nitro test > framework could improve on Rails using the view as a way of inputing > parameters, but also not using HTTP. > > > Aidan > > --- > > http://www.infurious.com > > > > > > On 16/02/2006, at 2:59 AM, Eduardo Rocha wrote: > > > > > 2006/2/15, Rob Pitt : > > >> I prefer the "fake sending" of forms and such as you can easily read > > >> session, request, etc to see if everything went as it should. No > > >> doubt > > >> mechanize could be hacked to do this, but I do not see the > > >> detraction of > > >> only sending POST data as a method (Eduardo mentioned it's not taking > > >> into account the real page) because you can visually very easily > > >> see if > > >> a page doesn't look like it should and would quickly notice > > >> incorrectly > > >> named fields (this isn't an error I've made before). > > >> > > > > > > I don't know if I understand you correctly, but I often fall into the > > > mistake of passing the controller test (in Rails) and then I get an > > > error testing in the browser, just because the form field names were > > > diferent from the test. And yet I can do visually, I think it breaks > > > the idea of TDD and automated tests. > > > > > >> On the other hand, it would be possible to create a "supervisor" > > >> process > > >> that managed both the app and mechanize or a thread within the app > > >> that > > >> ran mechanized on itself. I do not see there is a great benefit > > >> considering the extra complexity, it's a small benefit but is it > > >> worth > > >> the extra trouble to implement it like this? > > >> > > > > > > Concerning Watir/Selenium/Mechanize, my opinion is that features from > > > Mechanize are very similar to Watir/Selenium, but are run outside the > > > browser. I think this is not better or worse, because some people > > > would prefer running this kind of test before running in browser. But > > > with Mechanize you are using HTTP to test your app, which can slow > > > down test (if one is that paranoic :) and it is not "that" pure. > > > > > > In Rails, for example, instead of passing parameters directly, it > > > would be nice if we could start from the page (instead of a URL, in > > > the case of Mechanize), and we associate the form fields with values > > > (like Mechanize does, as well as Watir/Selenium). > > > > > >> Would like more opinions here. > > >> > > >> On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote: > > >>> Hi, > > >>> > > >>>> Is that really like a user browsing the site? > > >>> > > >>> I don't know how Watir/Selenium/Rails works in case of testing > > >>> sites, but maybe one could use WWW::Mechanize to hack some web- > > >>> page testing/traversing utility together. > > >>> Mechanize works with the html, no "fake sending" of forms, you > > >>> "fill 'em" like you normally would. > > >>> > > >>> http://www.ntecs.de/blog/Blog/WWW-Mechanize.rdoc > > >>> > > >>> and some additional Info for working with it: > > >>> http://www.adras.com/web-testing-with-Ruby.t37-48-1.html > > >>> http://www.zenspider.com/pipermail/ruby/2005-July/002068.html > > >>> > > >>> There doesn't seem so much information about it at all, but > > >>> someone might be interested :) > > >>> > > >>> > > >>> Kash > > >>> > > >> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > 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 Feb 16 07:57:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 16 Feb 2006 14:57:08 +0200 Subject: [Nitro] [oree.ch] New patch In-Reply-To: <200602151457.54374.zimba.tm@gmail.com> References: <200602151457.54374.zimba.tm@gmail.com> Message-ID: Please, do NOT change Nitro names so easily to avoid conflicts with obscure libraries like narf. regards, George. On 2/15/06, zimba.tm wrote: > Fed Feb 15 14:44:04 CET 2006 Jonas Pfenniger > * Taggable: Moved the Tag class in the Glue namespace > > I wanted to avoid name collisions (with Narf::Mechanize). > > I also corrected spark so make sure to backup your database before upgrading. > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > 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 Thu Feb 16 10:02:45 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 16 Feb 2006 08:02:45 -0700 Subject: [Nitro] [oree.ch] New patch In-Reply-To: References: <200602151457.54374.zimba.tm@gmail.com> Message-ID: <43F49415.4030207@neurogami.com> George Moschovitis wrote: > Please, do NOT change Nitro names so easily to avoid conflicts with obscure > libraries like narf. Hello, Pot? This is Kettle ... :) Obscurity is relative, and I imagine there are people who consider Nitro obscure. Narf is not obscure to fans of Mechanize. -- 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.30secondrule.com - Building Better Tools From rob at motionpath.com Thu Feb 16 10:43:38 2006 From: rob at motionpath.com (Rob Pitt) Date: Thu, 16 Feb 2006 15:43:38 +0000 Subject: [Nitro] [oree.ch] New patch In-Reply-To: <43F49415.4030207@neurogami.com> References: <200602151457.54374.zimba.tm@gmail.com> <43F49415.4030207@neurogami.com> Message-ID: <1140104619.24540.1.camel@robs-p4> Is it not good practise to keep all library classes inside modules, and not rely on them being in default namespace (regardless of if examples direct people to include them)? I think it is... On Thu, 2006-02-16 at 08:02 -0700, James Britt wrote: > George Moschovitis wrote: > > Please, do NOT change Nitro names so easily to avoid conflicts with obscure > > libraries like narf. > > Hello, Pot? This is Kettle ... > > :) > > > Obscurity is relative, and I imagine there are people who consider Nitro > obscure. > > Narf is not obscure to fans of Mechanize. > > > > From james_b at neurogami.com Thu Feb 16 10:56:26 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 16 Feb 2006 08:56:26 -0700 Subject: [Nitro] New Nitro Site Message-ID: <43F4A0AA.1040406@neurogami.com> I tried to add a new site to the list http://www.nitrohq.com/view/Nitro_in_the_real_world but it never seems to appear after saving the edit. Refreshing Cities http://www.refreshingcities.org/ -- James Britt "A principle or axiom is of no value without the rules for applying it." - Len Bullard From zimba.tm at gmail.com Thu Feb 16 11:59:48 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 16 Feb 2006 17:59:48 +0100 Subject: [Nitro] New Nitro Site In-Reply-To: <43F4A0AA.1040406@neurogami.com> References: <43F4A0AA.1040406@neurogami.com> Message-ID: <200602161759.49437.zimba.tm@gmail.com> Hi James, this is a known problem. I have been in contact with navel but they didn't have time to correct it yet. The problem is the translation of the whitespaces which is not coherent. Try replacing the underscores with plus signs or %20 and you should see your new page. On Thursday 16 February 2006 16:56, James Britt wrote: > I tried to add a new site to the list > > http://www.nitrohq.com/view/Nitro_in_the_real_world > > but it never seems to appear after saving the edit. > > Refreshing Cities > http://www.refreshingcities.org/ -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Thu Feb 16 12:04:30 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 16 Feb 2006 18:04:30 +0100 Subject: [Nitro] [oree.ch] New patch In-Reply-To: References: <200602151457.54374.zimba.tm@gmail.com> Message-ID: <200602161804.30432.zimba.tm@gmail.com> Hi George, i think that all classes or at least the ones with a generic name like Tag should be in modules. Naturally, all the changes are stored on my own repo so you can only import what you are interested in. I hope I'm not causing too much trouble, it's not my intent to take over the development. http://oree.ch/nitro should be considered semi-stable until you are back from vacation. After that, after you merged all the patches you're interested in, I will use it for experimental features. On Thursday 16 February 2006 13:57, George Moschovitis wrote: > Please, do NOT change Nitro names so easily to avoid conflicts with obscure > libraries like narf. > > regards, > George. > > On 2/15/06, zimba.tm wrote: > > Fed Feb 15 14:44:04 CET 2006 Jonas Pfenniger > > * Taggable: Moved the Tag class in the Glue namespace > > > > I wanted to avoid name collisions (with Narf::Mechanize). > > > > I also corrected spark so make sure to backup your database before > > upgrading. > > > > -- > > Cheers, > > zimba.tm > > > > weblog : http://zimba.oree.ch > > _______________________________________________ > > 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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Thu Feb 16 12:06:31 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 16 Feb 2006 18:06:31 +0100 Subject: [Nitro] Fwd: [ nitro-Bugs-3556 ] part/admin does not respond well to array controls In-Reply-To: References: <200602140102.k1E12W08017326@rubyforge.org> Message-ID: <200602161806.31543.zimba.tm@gmail.com> Hi Bryan, is it possible to give me a patch which is in sync with my own repo ? I don't have much time to look after that piece of code but it looks good. On Wednesday 15 February 2006 22:28, Bryan Soto wrote: > Not quite an RSS feed. :/ > > zimbu, Chris, what do you think? I believe you guys did some work on the > controls? > > bryan > > ---------- Forwarded message ---------- > From: noreply at rubyforge.org > Date: Feb 13, 2006 5:02 PM > Subject: [ nitro-Bugs-3556 ] part/admin does not respond well to array > controls > To: noreply at rubyforge.org > > Bugs item #3556, was opened at 2006-02-13 20:02 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3556&group_id=418 > > Category: Nitro > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Nobody (None) > Assigned to: Nobody (None) > Summary: part/admin does not respond well to array controls > > Initial Comment: > Steps to reproduce: > > 1. Create a model which has an Array property > 2. Require 'nitro', 'og' and 'part/admin' > 3. Start your web server > 4. Go to the /admin and click on your model > 5. Try to create a new instance of your model class, and you should get > this error: > > undefined local variable or method `emit_container_start' for > # > > /usr/local/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/helper/form/contro >ls.rb:170:in `render' > > > Patch to fix might be (someone needs to sanity check) > > --- > /usr/local/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/helper/form/contro >ls.rb 2006-02-14 > 11:55:21.000000000 +1100 > +++ - 2006-02-14 12:05:57.000000000 +1100 > @@ -192,6 +192,14 @@ > } > end > > + def emit_container_start > + %{
} > + end > + > + def emit_container_end > + %{
} > + end > + > def emit_js > %{ > > } > > The second part of the patch is because the remove array element button > didn't activate due to the off by one error. > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3556&group_id=418 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From george.moschovitis at gmail.com Thu Feb 16 13:02:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 16 Feb 2006 20:02:18 +0200 Subject: [Nitro] [oree.ch] New patch In-Reply-To: <200602161804.30432.zimba.tm@gmail.com> References: <200602151457.54374.zimba.tm@gmail.com> <200602161804.30432.zimba.tm@gmail.com> Message-ID: > i think that all classes or at least the ones with a generic name like Tag > should be in modules. Naturally, all the changes are stored on my own repo so > you can only import what you are interested in. I hope I'm not causing too > much trouble, it's not my intent to take over the development. Ok Tag should be in a namespace module. I just didn't like the reasoning: to make ...narf work. It is not the aim of Nitro to work with every library in existance. About your repository. I am sure the community is really greatful for this. I will be back in about 8 days to work with all of you for the release of Nitro/Og 0.29.0 I have some great features in mind, which I am sure will bring a smile to everyone's faces ;-) regards, George. PS: In the meantime, I really love to see patches coming ;-) -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Feb 16 13:10:10 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 16 Feb 2006 20:10:10 +0200 Subject: [Nitro] New Nitro Site In-Reply-To: <200602161759.49437.zimba.tm@gmail.com> References: <43F4A0AA.1040406@neurogami.com> <200602161759.49437.zimba.tm@gmail.com> Message-ID: I talked with Tasos, he is really busy at the moment, but hopefully he will be able to fix this during the weekend. Please email him again. thanks, George. On 2/16/06, zimba.tm wrote: > Hi James, > > this is a known problem. I have been in contact with navel but they didn't > have time to correct it yet. > > The problem is the translation of the whitespaces which is not coherent. Try > replacing the underscores with plus signs or %20 and you should see your new > page. > > On Thursday 16 February 2006 16:56, James Britt wrote: > > I tried to add a new site to the list > > > > http://www.nitrohq.com/view/Nitro_in_the_real_world > > > > but it never seems to appear after saving the edit. > > > > Refreshing Cities > > http://www.refreshingcities.org/ > > -- > Cheers, > zimba.tm > > weblog : http://zimba.oree.ch > _______________________________________________ > 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 bryan.a.soto at gmail.com Thu Feb 16 14:02:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 16 Feb 2006 11:02:08 -0800 Subject: [Nitro] New Nitro Site In-Reply-To: <43F4A0AA.1040406@neurogami.com> References: <43F4A0AA.1040406@neurogami.com> Message-ID: On 2/16/06, James Britt wrote: > > I tried to add a new site to the list > > http://www.nitrohq.com/view/Nitro_in_the_real_world > > but it never seems to appear after saving the edit. It sounds suspiciously like a caching problem... Refreshing Cities > http://www.refreshingcities.org/ I'd love to see it, but for some reason it doesn't resolve correctly for me. :( bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060216/0cdc2a4b/attachment.html From james_b at neurogami.com Thu Feb 16 14:49:50 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 16 Feb 2006 12:49:50 -0700 Subject: [Nitro] New Nitro Site In-Reply-To: References: <43F4A0AA.1040406@neurogami.com> Message-ID: <43F4D75E.3050404@neurogami.com> Bryan Soto wrote: > On 2/16/06, *James Britt* > wrote: > > I tried to add a new site to the list > > http://www.nitrohq.com/view/Nitro_in_the_real_world > > but it never seems to appear after saving the edit. > > > It sounds suspiciously like a caching problem... > > Refreshing Cities > http://www.refreshingcities.org/ You see that in a browser? Or in the edit pane? Neither IE nor FF shows the new text in the rendered page, only in the edit area. I cleared the cache for IE, but still see no changes. (And I doubt IE would have had a previous version, because those f*cking access keys in the wiki are too damn annoying for browsing the site in IE. I've had to turn access keys off in FF becuase they are so often poorly applied. ) > > > > I'd love to see it, but for some reason it doesn't resolve correctly for > me. :( First I've heard of any DNS issues. -- James Britt "You harmonize; then you customize." - Wilson Pickett From bryan.a.soto at gmail.com Thu Feb 16 16:23:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 16 Feb 2006 13:23:52 -0800 Subject: [Nitro] New Nitro Site In-Reply-To: <43F4D75E.3050404@neurogami.com> References: <43F4A0AA.1040406@neurogami.com> <43F4D75E.3050404@neurogami.com> Message-ID: On 2/16/06, James Britt wrote: > > Bryan Soto wrote: > > On 2/16/06, *James Britt* > > wrote: > > > > I tried to add a new site to the list > > > > http://www.nitrohq.com/view/Nitro_in_the_real_world > > > > but it never seems to appear after saving the edit. > > > > > > It sounds suspiciously like a caching problem... > > > > Refreshing Cities > > http://www.refreshingcities.org/ > > You see that in a browser? Or in the edit pane? > > > Neither IE nor FF shows the new text in the rendered page, only in the > edit area. I cleared the cache for IE, but still see no changes. (And > I doubt IE would have had a previous version, because those f*cking > access keys in the wiki are too damn annoying for browsing the site in > IE. I've had to turn access keys off in FF becuase they are so often > poorly applied. ) Sorry, I meant caching with the wiki itself. Seems like it's not properly updating the cached version of the page on changes as I do see the changes in the edit area after a save. Just a guess though. > I'd love to see it, but for some reason it doesn't resolve correctly for > > me. :( > > First I've heard of any DNS issues. I didn't bother complaining as I (probably correctly) assumed it was a problem with my setup. I first noticed it when I couldn't read your blog via Planet Ruby last week (Feb. 10). I keep forgetting to try from home though to confirm that was the case. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060216/0adb1a14/attachment.html From james_b at neurogami.com Thu Feb 16 17:15:25 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 16 Feb 2006 15:15:25 -0700 Subject: [Nitro] New Nitro Site In-Reply-To: References: <43F4A0AA.1040406@neurogami.com> <43F4D75E.3050404@neurogami.com> Message-ID: <43F4F97D.1030100@neurogami.com> Bryan Soto wrote: .. > > Sorry, I meant caching with the wiki itself. Seems like it's not > properly updating the cached version of the page on changes as I do see > the changes in the edit area after a save. Just a guess though. Ah. Anyway, the Proper Authorities have been alerted. > > > I'd love to see it, but for some reason it doesn't resolve > correctly for > > me. :( > > First I've heard of any DNS issues. > > > I didn't bother complaining as I (probably correctly) assumed it was a > problem with my setup. I first noticed it when I couldn't read your blog > via Planet Ruby last week (Feb. 10). I keep forgetting to try from home > though to confirm that was the case. They're on the same machine (along with ruby-doc.org and a number of other sites), so if you have issues please let me know. There was a brief time when some network issues borked the DNS, but otherwise they should be up and available to all. Thanks, James Britt From zimba.tm at gmail.com Fri Feb 17 05:50:57 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 17 Feb 2006 11:50:57 +0100 Subject: [Nitro] [oree.ch] New patch In-Reply-To: References: <200602151457.54374.zimba.tm@gmail.com> <200602161804.30432.zimba.tm@gmail.com> Message-ID: <200602171150.57851.zimba.tm@gmail.com> On Thursday 16 February 2006 19:02, George Moschovitis wrote: > > i think that all classes or at least the ones with a generic name like > > Tag should be in modules. Naturally, all the changes are stored on my own > > repo so you can only import what you are interested in. I hope I'm not > > causing too much trouble, it's not my intent to take over the > > development. > > Ok Tag should be in a namespace module. I just didn't like the > reasoning: to make ...narf work. It is not the aim of Nitro to work > with every library in existance. I totally agree. We know both that Narf should also take care of it's namespace pollution. Especially because it is a library, which nitro is not. So in what module should we put Tag ? Right now it is in Glue::Tag. > About your repository. I am sure the community is really greatful for > this. I will be back in about 8 days to work with all of you for the > release of Nitro/Og 0.29.0 I have some great features in mind, which I > am sure will bring a smile to everyone's faces ;-) Nice :-) I hope we can collaborate more in the future. What was putting of for submitting patches before, is that some didn't get applied, got lost and that I didn't know where you want to take Nitro/Og. So all the work I would do would be the contrary of useful. The recurring subject is to setup Trac so that we have a nice community tool. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From rob at motionpath.com Fri Feb 17 08:20:02 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 13:20:02 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) Message-ID: <1140182402.24540.30.camel@robs-p4> WARNING: This patch causes join tables to be created with different names and will require you to manually copy join table data into newly named tables if applied to a project you are already using. Why would I make a patch that requires this? Not having this requirement (i.e. doing it in an automated fashion) would be fairly complicated and a big drain on CPU. This patch still needs to be implemented at some point because it enables a desirable behaviour, and we are at 0.2 so we should make changes with big impacts like this now rather than later. This is a very minor modification so that a model like this behaves as it should: Class Article property :title, String joins_many :first_join, Category joins_many :second_join, Category joins_many Category def initialize(title) @title = title end end Without this patch, items you push into .first_join are visible in .second_join and the .categories join (all other combinations of this are also true). This is wrong, and this patch corrects this. -------------- next part -------------- A non-text attachment was scrubbed... Name: join-tables.patch.bz2 Type: application/x-bzip Size: 5499 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060217/c9e8c33d/attachment.bin From rob at motionpath.com Fri Feb 17 08:39:08 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 13:39:08 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140182402.24540.30.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> Message-ID: <1140183548.24540.33.camel@robs-p4> I have not tested this with anything but SQLite store either, I will do PostgreSQL now and make appropriate changes (and a migration script so you can seamlessly upgrade old projects to use this new method without losing data). I hope you all agree this is a good idea and it would be very cool if it doesn't work with your favoured store of choice (MySQL) if you let me know since I only have PostgreSQL and SQLite at the moment to play with. On Fri, 2006-02-17 at 13:20 +0000, Rob Pitt wrote: > WARNING: This patch causes join tables to be created with different > names and will require you to manually copy join table data into newly > named tables if applied to a project you are already using. > > Why would I make a patch that requires this? Not having this requirement > (i.e. doing it in an automated fashion) would be fairly complicated and > a big drain on CPU. > > This patch still needs to be implemented at some point because it > enables a desirable behaviour, and we are at 0.2 so we should make > changes with big impacts like this now rather than later. > > This is a very minor modification so that a model like this behaves as > it should: > > Class Article > property :title, String > > joins_many :first_join, Category > joins_many :second_join, Category > joins_many Category > > def initialize(title) > @title = title > end > end > > Without this patch, items you push into .first_join are visible > in .second_join and the .categories join (all other combinations of this > are also true). > > This is wrong, and this patch corrects this. > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Fri Feb 17 08:44:33 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 13:44:33 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140183548.24540.33.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> <1140183548.24540.33.camel@robs-p4> Message-ID: <1140183874.24540.36.camel@robs-p4> Typical me jumping the gun :) This patch currently does not work with PostgreSQL store, I think it should work with the others as they do not directly reference the modified function. I am fixing it so PostgreSQL works properly with it now. (We needed this behaviour in a hurry... as usual less haste, more speed would have been prudent). On Fri, 2006-02-17 at 13:39 +0000, Rob Pitt wrote: > I have not tested this with anything but SQLite store either, I will do > PostgreSQL now and make appropriate changes (and a migration script so > you can seamlessly upgrade old projects to use this new method without > losing data). > > I hope you all agree this is a good idea and it would be very cool if it > doesn't work with your favoured store of choice (MySQL) if you let me > know since I only have PostgreSQL and SQLite at the moment to play with. > > On Fri, 2006-02-17 at 13:20 +0000, Rob Pitt wrote: > > WARNING: This patch causes join tables to be created with different > > names and will require you to manually copy join table data into newly > > named tables if applied to a project you are already using. > > > > Why would I make a patch that requires this? Not having this requirement > > (i.e. doing it in an automated fashion) would be fairly complicated and > > a big drain on CPU. > > > > This patch still needs to be implemented at some point because it > > enables a desirable behaviour, and we are at 0.2 so we should make > > changes with big impacts like this now rather than later. > > > > This is a very minor modification so that a model like this behaves as > > it should: > > > > Class Article > > property :title, String > > > > joins_many :first_join, Category > > joins_many :second_join, Category > > joins_many Category > > > > def initialize(title) > > @title = title > > end > > end > > > > Without this patch, items you push into .first_join are visible > > in .second_join and the .categories join (all other combinations of this > > are also true). > > > > This is wrong, and this patch corrects 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 From rob at motionpath.com Fri Feb 17 08:54:25 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 13:54:25 +0000 Subject: [Nitro] [PATCH] Fix to join table patch earlier today so it works with PostgreSQL store Message-ID: <1140184466.24540.41.camel@robs-p4> Here is the fix to make it work with the PostgreSQL store. Please see the other patch for information on what it does (it must be applied only with that patch). I can't see anywhere else that uses this method so it's safe to assume it will work with all stores (I know it works with SQLite and PostgreSQL). Of course, please do try it before applying it... :P -------------- next part -------------- A non-text attachment was scrubbed... Name: join-tables-patch-postgresql-fix.patch.bz2 Type: application/x-bzip Size: 4794 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060217/c1a879ec/attachment.bin From george.moschovitis at gmail.com Fri Feb 17 10:57:33 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 17 Feb 2006 17:57:33 +0200 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140183874.24540.36.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> <1140183548.24540.33.camel@robs-p4> <1140183874.24540.36.camel@robs-p4> Message-ID: This is a great patch, In fact I needed this in one of my projects, and planned to work on this when I get back. On the other hand, the Og low level code needs again some refactoring, so this is my first Og related priority when I get back. thanks, George. On 2/17/06, Rob Pitt wrote: > Typical me jumping the gun :) > > This patch currently does not work with PostgreSQL store, I think it > should work with the others as they do not directly reference the > modified function. I am fixing it so PostgreSQL works properly with it > now. > > (We needed this behaviour in a hurry... as usual less haste, more speed > would have been prudent). > > On Fri, 2006-02-17 at 13:39 +0000, Rob Pitt wrote: > > I have not tested this with anything but SQLite store either, I will do > > PostgreSQL now and make appropriate changes (and a migration script so > > you can seamlessly upgrade old projects to use this new method without > > losing data). > > > > I hope you all agree this is a good idea and it would be very cool if it > > doesn't work with your favoured store of choice (MySQL) if you let me > > know since I only have PostgreSQL and SQLite at the moment to play with. > > > > On Fri, 2006-02-17 at 13:20 +0000, Rob Pitt wrote: > > > WARNING: This patch causes join tables to be created with different > > > names and will require you to manually copy join table data into newly > > > named tables if applied to a project you are already using. > > > > > > Why would I make a patch that requires this? Not having this requirement > > > (i.e. doing it in an automated fashion) would be fairly complicated and > > > a big drain on CPU. > > > > > > This patch still needs to be implemented at some point because it > > > enables a desirable behaviour, and we are at 0.2 so we should make > > > changes with big impacts like this now rather than later. > > > > > > This is a very minor modification so that a model like this behaves as > > > it should: > > > > > > Class Article > > > property :title, String > > > > > > joins_many :first_join, Category > > > joins_many :second_join, Category > > > joins_many Category > > > > > > def initialize(title) > > > @title = title > > > end > > > end > > > > > > Without this patch, items you push into .first_join are visible > > > in .second_join and the .categories join (all other combinations of this > > > are also true). > > > > > > This is wrong, and this patch corrects 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 > > _______________________________________________ > 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 Fri Feb 17 11:56:58 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 16:56:58 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140182402.24540.30.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> Message-ID: <1140195418.24540.56.camel@robs-p4> This script was tested on a project with many thousands of join relations involving multiple STI classes. Here is a command-line script (and steps for use below, please read if you use this) that you can run from the command line that *should* auto-magically migrate a project from an old join table system to the new one (with any store - it's pure Og calls.) Do apologise for the messy hackishness but it's only for one-off usage... If loading rubygems would interfere with your setup somehow you will need to remove require 'rubygems' from right at the top of the script (most people will need it). Help information (can be obtained by running the script with no options): Exports or imports the join data for a Nitro application (Works with glycerin as of date 17/02/2006) Usage: ./join-table-migrator.rb <[-i] [-e]> "" "" Export example (exports data from run.rb in curent directory to dump.bin): ./join-table-migrator.rb -e ./run.rb dump.bin Import example (Imports data from dump.bin to run.rb in current directory): ./join-table-migrator.rb -i ./run.rb dump.bin Steps to use: 1. Open a console window in the directory of your project. 2. Export data from a project ***BEFORE*** applying the patches (use darcs unpull to remove them if you have already applied them), i.e.: ./join-table-migrator.rb -e ./run.rb dump.bin 3. Apply the patches to your Glycerin repository. 4. Import the data back in again, i.e. ./join-table-migrator.rb -i ./run.rb dump.bin 5. Run your project and everything will appear to be the same (unless you examine the back-end database structure... :P) If you need to update multiple projects you will have to repeat these steps again (i.e. unpull the patches with darcs export, re-apply, import). - rp On Fri, 2006-02-17 at 13:20 +0000, Rob Pitt wrote: > WARNING: This patch causes join tables to be created with different > names and will require you to manually copy join table data into newly > named tables if applied to a project you are already using. > > Why would I make a patch that requires this? Not having this requirement > (i.e. doing it in an automated fashion) would be fairly complicated and > a big drain on CPU. > > This patch still needs to be implemented at some point because it > enables a desirable behaviour, and we are at 0.2 so we should make > changes with big impacts like this now rather than later. > > This is a very minor modification so that a model like this behaves as > it should: > > Class Article > property :title, String > > joins_many :first_join, Category > joins_many :second_join, Category > joins_many Category > > def initialize(title) > @title = title > end > end > > Without this patch, items you push into .first_join are visible > in .second_join and the .categories join (all other combinations of this > are also true). > > This is wrong, and this patch corrects this. > _______________________________________________ > 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: join-table-migrator.rb.bz2 Type: application/x-bzip Size: 1866 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060217/e3680972/attachment.bin From rob at motionpath.com Fri Feb 17 12:07:35 2006 From: rob at motionpath.com (Rob Pitt) Date: Fri, 17 Feb 2006 17:07:35 +0000 Subject: [Nitro] Problem with forgien key constraints Message-ID: <1140196056.24540.65.camel@robs-p4> The new patch that alters join table names has highlighted a problem with the foreign key constraints system. The problem is PostgreSQL doesn't like very long constraint names. This doesn't break any projects but if you have two long model names in a join table, the constraints will be incorrectly deleted upon startup (this doesn't alter the data). They will not function in this state (it will act like they don't exist, (which they don't on other stores) and will not cause you problems developing but I suggest you don't use this patch in production until I (or someone else) have constructed a new naming mechanism for the constraints (I have one in mind). I will make Og handle that transition automatically so no external scripts are needed. For people who don't understand what constraints are they are really a protection mechanism that cleans up data left behind when doing things like Model.delete_all by removing relationships with that model from other tables. Without them it is possible to end up with models at are incorrectly related to one another (but unlikely). From bryan.a.soto at gmail.com Fri Feb 17 15:29:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 17 Feb 2006 12:29:56 -0800 Subject: [Nitro] PATCHSET Message-ID: * part-admin_array_control_fix Adds #emit_container_start, #emit_container_end to ArrayControl. Change to #emit_js to fix off by one error in remove array element button. Credit to aidan ----- * tc_cacheable_test_fix Some fixes to make tc_cacheable pass. Partial fix for tc_hierarchical. At least it makes it error out a bit further along. ----- * more_glue_namespace_fixes Adds module name to a few more classes. Removes some unneeded requires of glue files. ----- Followup on part/admin from Aidan: The above "fix" is not a complete one. There are issues with saving: once you actually save an object it doesn't fill in useful values for the array in the database (in fact, it saves empty StringIO objects it seems). See http://rubyforge.org/tracker/index.php?func=detail&aid=3556&group_id=418&atid=1670 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060217/30f2ab76/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 24639 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060217/30f2ab76/attachment.zip From bryan.a.soto at gmail.com Fri Feb 17 15:48:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 17 Feb 2006 12:48:42 -0800 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140182402.24540.30.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> Message-ID: Just a quick note. After this is applied, there is a new test failure: 1) Failure: test_og(TCOgStore) [./test/og/tc_store.rb:263:in `features_test' ./test/og/tc_store.rb:76:in `test_og']: <1> expected but was <0>. I'll try and check it out later. On 2/17/06, Rob Pitt wrote: > > WARNING: This patch causes join tables to be created with different > names and will require you to manually copy join table data into newly > named tables if applied to a project you are already using. > > Why would I make a patch that requires this? Not having this requirement > (i.e. doing it in an automated fashion) would be fairly complicated and > a big drain on CPU. > > This patch still needs to be implemented at some point because it > enables a desirable behaviour, and we are at 0.2 so we should make > changes with big impacts like this now rather than later. > > This is a very minor modification so that a model like this behaves as > it should: > > Class Article > property :title, String > > joins_many :first_join, Category > joins_many :second_join, Category > joins_many Category > > def initialize(title) > @title = title > end > end > > Without this patch, items you push into .first_join are visible > in .second_join and the .categories join (all other combinations of this > are also true). > > This is wrong, and this patch corrects this. > > > _______________________________________________ > 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/20060217/62051794/attachment.html From bryan.a.soto at gmail.com Fri Feb 17 16:05:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 17 Feb 2006 13:05:48 -0800 Subject: [Nitro] nitrohq.com Message-ID: For what it's worth, creating a new page works correctly. After that, the page is not updated after edits. So, I really think that the problem is that Spark isn't updating it's cached pages properly. I've checked on Spark in the darcs repo and it doesn't seem to do that. I didn't dig really deep though. Perhaps the nitrohq.com version of Spark isn't the current 1.0 and is experiencing some conflicts with the latest Nitro? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060217/0d9dcd91/attachment.html From bryan.a.soto at gmail.com Fri Feb 17 16:30:49 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 17 Feb 2006 13:30:49 -0800 Subject: [Nitro] Fwd: [ nitro-Bugs-3573 ] Og schema_inheritance loosing data on restart In-Reply-To: References: <200602172114.k1HLEiT5026871@rubyforge.org> Message-ID: I think I know who this is, but just in case I'm wrong, I'll reply publically. :) I did get that patch applied to zimba's repo and I'll be sure it makes it into George's. I'll leave this open to ensure we remember. Thanks for reporting. Bryan On 2/17/06, noreply at rubyforge.org wrote: > > Bugs item #3573, was opened at 2006-02-15 23:36 > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3573&group_id=418 > > Category: Og > Group: None > Status: Open > Resolution: None > Priority: 3 > Submitted By: Nobody (None) > Assigned to: Nobody (None) > Summary: Og schema_inheritance loosing data on restart > > Initial Comment: > http://rubyforge.org/pipermail/nitro-general/2006-January/002601.html > > probably that patch can be applied? > > ---------------------------------------------------------------------- > > >Comment By: Bryan Soto (bsoto) > Date: 2006-02-17 13:14 > > Message: > This patch was applied to the temporary repo. I'll leave this open as a > reminder to ensure it gets applied to the official repo. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://rubyforge.org/tracker/?func=detail&atid=1670&aid=3573&group_id=418 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060217/2baf0446/attachment.html From bakki.kudva at gmail.com Fri Feb 17 17:01:03 2006 From: bakki.kudva at gmail.com (Bakki Kudva) Date: Fri, 17 Feb 2006 17:01:03 -0500 Subject: [Nitro] Some newbie questions. Message-ID: Hello all, I just installed nitro on a Debian Sarge box. I really like what I have seen so far. I like Og which I believe is the more natural way to persist ruby objects rather than the other way round in ActiveRecord. Needless to say I am coming to this from Rails. However I do have some questions which I couldn't find answers to on the web site. The welcome screen says... Before you move on, verify that the following conditions have been met: The log directory and the empty log files must be writable to the web server (chmod -R 666 log/*). Where is the log directory? I looked in the project (todo), home, /var/log etc. Am I to create this directory in the project folder? The shebang line in the ctl file must reference your Ruby installation. You might need to change it to #!/usr/bin/env ruby or point directly at the installation. Again same question here which ctl file? The only one I found was ../todo/script/scgi_ctl Have a look at the examples: examples/blog: A simple Blog, featuring a nice XSLT based template. examples/no_xsl_blog: The same example without using XSLT (easier to setup under Windows). examples/why_wiki: A conversion of why_'s wiki. examples/wee_style: A Wee-style (ruby code only) example. examples/ajax: Implement Google suggest-style functionality using ajax techniques. examples/tiny: A small example to verify your installation. Some of the examples ran fine (flickr after I installed the gem) and others give me errors like this one for wee D, [2006-02-17T17:20:01.924341 #12310] DEBUG -- : Using Memory sessions. /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': no such file to load -- wee/examples/calculator (LoadError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from run.rb:4 I could not find wee/examples/calculator Thank you, bakki From zimba.tm at gmail.com Fri Feb 17 17:02:44 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 17 Feb 2006 23:02:44 +0100 Subject: [Nitro] PATCHSET In-Reply-To: References: Message-ID: <200602172302.44312.zimba.tm@gmail.com> Thanks for the patches, applied On Friday 17 February 2006 21:29, Bryan Soto wrote: > * part-admin_array_control_fix > Adds #emit_container_start, #emit_container_end to ArrayControl. Change > to #emit_js to fix off by one error in remove array element button. > > Credit to aidan > > ----- > > * tc_cacheable_test_fix > Some fixes to make tc_cacheable pass. Partial fix for tc_hierarchical. At > least it makes it error out a bit further along. > > ----- > > * more_glue_namespace_fixes > Adds module name to a few more classes. Removes some unneeded requires of > glue files. > > ----- > > Followup on part/admin from Aidan: > > The above "fix" is not a complete one. There are issues > with saving: once you actually save an object it doesn't fill > in useful values for the array in the database (in fact, it saves > empty StringIO objects it seems). > > > See > http://rubyforge.org/tracker/index.php?func=detail&aid=3556&group_id=418&at >id=1670 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Fri Feb 17 17:14:12 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Fri, 17 Feb 2006 23:14:12 +0100 Subject: [Nitro] Some newbie questions. In-Reply-To: References: Message-ID: <200602172314.12167.zimba.tm@gmail.com> On Friday 17 February 2006 23:01, Bakki Kudva wrote: > Hello all, Hi Bakki, welcome to the Nitro community :) > Where is the log directory? I looked in the project (todo), home, > /var/log etc. Am I to create this directory in the project folder? The log file "has to be" under the file's folder where you have run Nitro.start. Typically, you would create a run.rb file which you use to start you application. The log folder would be in the same folder that run.rb > Again same question here which ctl file? The only one I found was > ../todo/script/scgi_ctl This is not well documented. I think it refers to the run.rb I was talking about earlier. > I could not find wee/examples/calculator Wee is another web framework. You need it for that example to run. -- Cheers, zimba.tm weblog : http://zimba.oree.ch From rob at motionpath.com Fri Feb 17 18:51:27 2006 From: rob at motionpath.com (rob) Date: Fri, 17 Feb 2006 23:51:27 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: References: <1140182402.24540.30.camel@robs-p4> Message-ID: <15B428E9-E2D7-400A-8EA4-DDFAFFEE7E67@motionpath.com> Thanks Bryan, I only ran the join test case and not the whole suite. Considering how minor the modification this patch makes is I suspect the problem isn't the patch itself (it took advantage of an unused argument already present in the join_table_info method). If you don't get time I will check this out myself on Monday. On 17 Feb 2006, at 20:48, Bryan Soto wrote: > Just a quick note. After this is applied, there is a new test failure: > > 1) Failure: > test_og(TCOgStore) > [./test/og/tc_store.rb:263:in `features_test' > ./test/og/tc_store.rb:76:in `test_og']: > <1> expected but was > <0>. > > I'll try and check it out later. > > On 2/17/06, Rob Pitt wrote: > WARNING: This patch causes join tables to be created with different > names and will require you to manually copy join table data into newly > named tables if applied to a project you are already using. > > Why would I make a patch that requires this? Not having this > requirement > (i.e. doing it in an automated fashion) would be fairly complicated > and > a big drain on CPU. > > This patch still needs to be implemented at some point because it > enables a desirable behaviour, and we are at 0.2 so we should make > changes with big impacts like this now rather than later. > > This is a very minor modification so that a model like this behaves as > it should: > > Class Article > property :title, String > > joins_many :first_join, Category > joins_many :second_join, Category > joins_many Category > > def initialize(title) > @title = title > end > end > > Without this patch, items you push into .first_join are visible > in .second_join and the .categories join (all other combinations of > this > are also true). > > This is wrong, and this patch corrects 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060217/65dc260f/attachment.html From itsme213 at hotmail.com Fri Feb 17 21:55:01 2006 From: itsme213 at hotmail.com (itsme213) Date: Fri, 17 Feb 2006 20:55:01 -0600 Subject: [Nitro] Problem with forgien key constraints References: <1140196056.24540.65.camel@robs-p4> Message-ID: > The new patch that alters join table names has highlighted a problem > with the foreign key constraints system. The problem is PostgreSQL > doesn't like very long constraint names. Standard library abbrev seems to give short unambiguous name prefixes. irb(main):003:0> require 'abbrev' => true irb(main):004:0> ['abc', 'abcde', 'pqr'].abbrev => {"pq"=>"pqr", "abc"=>"abc", "p"=>"pqr", "pqr"=>"pqr", "abcd"=>"abcde", "abcde"=>"abcde"} irb(main):005:0> Would that help? From m.fellinger at gmail.com Sat Feb 18 02:46:47 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sat, 18 Feb 2006 16:46:47 +0900 Subject: [Nitro] Localization Message-ID: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> Hey List, I've been playing around with localization now for a while and noticedsome, well, a bit annoying problems.First of all, Localization is not in the default-pipeline. I know thisdecision was made a while ago and just want to confirm that this isreally what everyone wants.IMHO localization is one of the important things every moderatly largeproject needs, although most of the nitro-pages are stillenglish-only, it might be a nice addition to all of them to have it athand when you need it.Well, i don't want to clutter the pipeline, but mine looks atm like that: Compiler.setup_template_transform do |template| template = StaticInclude.transform(template) template = Morphing.transform(template, self) template = Elements.transform(template, self) template = Markup.transform(template) template = ScriptCompiler.transform(template, self) template = Localization.transform(template) template = Cleanup.transform(template) template = Template.transform(template)end all of that only to get localization running... and everytime thedefault-pipline changes i have to reflect all the changes in here,making upgrades a bit tiresome...How large would be the overhead of having the localization in the default? Well, another thing is, i have made a nice little interface to updatethe localization on the fly, while the application is running. I addedthe controller and template below.My question is, could we integrate this one in the part/admin to beused only when the localization is included? i'm not sure how to checkfor that, so i would like to ask someone to give me a hint on that andif it is wanted at all - at least it's making the whole localization abit less tiresome - imagine having to restart the server all the timeto only change a word :)oh, and if you take a closer look at the template, it's a bit weirdbut the only way i could make this work... thx in prev~~~~manveru ###### controller.rb::edit_locales ###### def edit_locales if request.post? langs = {} $languages.each{|l| langs.merge!({l[0] => {}})} arr = Array.new(request.params.size/$languages.size){{}} request.params.each{|param| key = param[0].split('_') if key[1] == 'key' && !param[1].nil? $languages.each{|l| langs[l[0]].merge!({param[1] =>request.params["#{key[0]}_#{l[0]}"]}) } end } Glue::Localization.add(langs) langs.each_pair{|lang, vals| File.open("conf/#{lang}_locales.yaml", "w") {|fd| fd.write(YAML::dump(vals)) } } end redirect_to_referer end ###### localization.xhtml ######
#{head}
From m.fellinger at gmail.com Sat Feb 18 02:49:11 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sat, 18 Feb 2006 16:49:11 +0900 Subject: [Nitro] [Tracker:Bug] schema_inheritance Message-ID: <9c00d3e00602172349h2a533facu@mail.gmail.com> Hey list, I added a new bug that is around for a while now to the tracker.the original thread washttp://rubyforge.org/pipermail/nitro-general/2006-January/002601.html you can find it on the tracker:http://rubyforge.org/tracker/index.php?func=detail&aid=3573&group_id=418&atid=1670 thx in prev~~~~manveru From rob at motionpath.com Sat Feb 18 06:26:56 2006 From: rob at motionpath.com (rob) Date: Sat, 18 Feb 2006 11:26:56 +0000 Subject: [Nitro] Localization In-Reply-To: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> References: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> Message-ID: <5A919F09-D11E-4CFB-B557-6645D791DE6D@motionpath.com> Can you please zip up attachments to the list? They get mangled otherwise. I don't think Localization should be in the default pipe, it's very easy to change the pipeline if you need it and most of us don't need Localization in 90% of our projects. I am against it, but not strongly so as it is just as easy for me to remove it from the pipeline as it is for you to add it. On 18 Feb 2006, at 07:46, Michael Fellinger wrote: > Hey List, > I've been playing around with localization now for a while and > noticedsome, well, a bit annoying problems.First of all, > Localization is not in the default-pipeline. I know thisdecision > was made a while ago and just want to confirm that this isreally > what everyone wants.IMHO localization is one of the important > things every moderatly largeproject needs, although most of the > nitro-pages are stillenglish-only, it might be a nice addition to > all of them to have it athand when you need it.Well, i don't want > to clutter the pipeline, but mine looks atm like that: > Compiler.setup_template_transform do |template| template = > StaticInclude.transform(template) template = Morphing.transform > (template, self) template = Elements.transform(template, self) > template = Markup.transform(template) template = > ScriptCompiler.transform(template, self) template = > Localization.transform(template) template = Cleanup.transform > (template) template = Template.transform(template)end > all of that only to get localization running... and everytime > thedefault-pipline changes i have to reflect all the changes in > here,making upgrades a bit tiresome...How large would be the > overhead of having the localization in the default? > Well, another thing is, i have made a nice little interface to > updatethe localization on the fly, while the application is > running. I addedthe controller and template below.My question is, > could we integrate this one in the part/admin to beused only when > the localization is included? i'm not sure how to checkfor that, so > i would like to ask someone to give me a hint on that andif it is > wanted at all - at least it's making the whole localization abit > less tiresome - imagine having to restart the server all the timeto > only change a word :)oh, and if you take a closer look at the > template, it's a bit weirdbut the only way i could make this work... > thx in prev~~~~manveru > ###### controller.rb::edit_locales ###### > def edit_locales if request.post? langs = {} > $languages.each{|l| langs.merge!({l[0] => {}})} arr = Array.new > (request.params.size/$languages.size){{}} request.params.each{| > param| key = param[0].split('_') if key[1] == 'key' > && !param[1].nil? $languages.each{|l| langs[l > [0]].merge!({param[1] =>request.params["#{key[0]}_#{l > [0]}"]}) } end } Glue::Localization.add > (langs) langs.each_pair{|lang, vals| File.open("conf/# > {lang}_locales.yaml", "w") {|fd| fd.write(YAML::dump > (vals)) } } end redirect_to_referer end > ###### localization.xhtml ###### $languages.map{|x| x[1]}locales = @lc.map{|lc| lc }.sorti = 0? > >
head in header do ?> row in locales do ?> do ?>
#{head}
type="text" value="#{row[0]}"/>
value="[[save locales]]"/>
 > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Sat Feb 18 06:38:21 2006 From: rob at motionpath.com (rob) Date: Sat, 18 Feb 2006 11:38:21 +0000 Subject: [Nitro] Problem with forgien key constraints In-Reply-To: References: <1140196056.24540.65.camel@robs-p4> Message-ID: It isn't really important what the constraint names are as you can examine the constraint definitions to see what should and shouldn't be there, I tried to give them descriptive names in the same vein as the join table naming system (for people who care to meddle with the database manually) but it's not necessary, they could be named anything. Nice idea. On 18 Feb 2006, at 02:55, itsme213 wrote: > > >> The new patch that alters join table names has highlighted a problem >> with the foreign key constraints system. The problem is PostgreSQL >> doesn't like very long constraint names. > > Standard library abbrev seems to give short unambiguous name prefixes. > > irb(main):003:0> require 'abbrev' > => true > irb(main):004:0> ['abc', 'abcde', 'pqr'].abbrev > => {"pq"=>"pqr", "abc"=>"abc", "p"=>"pqr", "pqr"=>"pqr", > "abcd"=>"abcde", > "abcde"=>"abcde"} > irb(main):005:0> > > Would that help? > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From m.fellinger at gmail.com Sat Feb 18 07:27:49 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sat, 18 Feb 2006 21:27:49 +0900 Subject: [Nitro] Localization In-Reply-To: <5A919F09-D11E-4CFB-B557-6645D791DE6D@motionpath.com> References: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> <5A919F09-D11E-4CFB-B557-6645D791DE6D@motionpath.com> Message-ID: <9c00d3e00602180427i6ebd057ax@mail.gmail.com> sorry, i was in a hurry and didn't think properly - here is the stuff in a nice .tar.gz way :) 2006/2/18, rob : > Can you please zip up attachments to the list? They get mangled > otherwise. > > I don't think Localization should be in the default pipe, it's very > easy to change the pipeline if you need it and most of us don't need > Localization in 90% of our projects. I am against it, but not > strongly so as it is just as easy for me to remove it from the > pipeline as it is for you to add it. Well, here is the problem, every change to the pipeline needs a complete listing of a new pipeline you want to use. but, thinking more about it we could make a couple of default-pipelines, just choosing the current one as the real default and providing a _fully_loaded_ one as well as some other ones for common tasks like the localization or use of the javascript-compiler... should be pretty trivial to make, but spares some problems for some people, i'll take a stab at it later. The real problem with custom pipelines is that you have to figure out the correct order to put them in - in the case a compiler does not work properly it is a pain to find out wich one is causing the trouble and how to make it work properly without breaking other compilers at the same time. -------------- next part -------------- A non-text attachment was scrubbed... Name: buffer.tar.gz Type: application/x-gzip Size: 869 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060218/ce5727c1/attachment.gz From george.moschovitis at gmail.com Sat Feb 18 11:46:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 18 Feb 2006 18:46:23 +0200 Subject: [Nitro] Localization In-Reply-To: <9c00d3e00602180427i6ebd057ax@mail.gmail.com> References: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> <5A919F09-D11E-4CFB-B557-6645D791DE6D@motionpath.com> <9c00d3e00602180427i6ebd057ax@mail.gmail.com> Message-ID: > Well, here is the problem, every change to the pipeline needs a > complete listing of a new pipeline you want to use. I have some semi-working code that 'injects' compilers in the pipeline, to tackle this problem. be patient for this. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Feb 18 11:54:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 18 Feb 2006 18:54:23 +0200 Subject: [Nitro] [oree.ch] New patch In-Reply-To: <200602171150.57851.zimba.tm@gmail.com> References: <200602151457.54374.zimba.tm@gmail.com> <200602161804.30432.zimba.tm@gmail.com> <200602171150.57851.zimba.tm@gmail.com> Message-ID: > So in what module should we put Tag ? Right now it is in Glue::Tag. Glue::Tag is ok ;-) > Nice :-) I hope we can collaborate more in the future. What was putting of > ... > that we have a nice community tool. I think you are doing a great job with your repo.I will have more time to see tyhe changes and collaborate next week. regards. George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bakki.kudva at gmail.com Sat Feb 18 13:21:14 2006 From: bakki.kudva at gmail.com (Bakki Kudva) Date: Sat, 18 Feb 2006 13:21:14 -0500 Subject: [Nitro] Some newbie questions. In-Reply-To: <200602172314.12167.zimba.tm@gmail.com> References: <200602172314.12167.zimba.tm@gmail.com> Message-ID: Hi Zimba, Thank you for your prompt reply. I am going to lurk on the list for a while and code a bit and hopefully learn from all of you. I'd be happy to contribute to the docs as I start understanding. bakki On 2/17/06, zimba.tm wrote: > > > On Friday 17 February 2006 23:01, Bakki Kudva wrote: > > Hello all, > > Hi Bakki, > > welcome to the Nitro community :) > From zimba.tm at gmail.com Sun Feb 19 10:14:13 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 19 Feb 2006 16:14:13 +0100 Subject: [Nitro] Localization In-Reply-To: References: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> <9c00d3e00602180427i6ebd057ax@mail.gmail.com> Message-ID: <200602191614.13989.zimba.tm@gmail.com> Recently I have made a patch that externalized the pipeline to an array in a "setting" but I didn't submit it. The problem with that approach is that it didn't make clear in the code that the ordering is important. How would you build an ordered list differently, aboiding the "template = Compiler.transform(template)" sheme which makes it unflexible ? On Saturday 18 February 2006 17:46, George Moschovitis wrote: > > Well, here is the problem, every change to the pipeline needs a > > complete listing of a new pipeline you want to use. > > I have some semi-working code that 'injects' compilers in the > pipeline, to tackle this problem. be patient for this. > > -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 -- Cheers, zimba.tm weblog : http://zimba.oree.ch From zimba.tm at gmail.com Sun Feb 19 10:15:13 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Sun, 19 Feb 2006 16:15:13 +0100 Subject: [Nitro] [oree.ch] New patch In-Reply-To: References: <200602151457.54374.zimba.tm@gmail.com> <200602171150.57851.zimba.tm@gmail.com> Message-ID: <200602191615.13863.zimba.tm@gmail.com> On Saturday 18 February 2006 17:54, George Moschovitis wrote: > > So in what module should we put Tag ? Right now it is in Glue::Tag. > > Glue::Tag is ok ;-) ok :) > > Nice :-) I hope we can collaborate more in the future. What was putting > > of ... > > that we have a nice community tool. > > I think you are doing a great job with your repo.I will have more time > to see tyhe changes and collaborate next week. Thanks. This week I will be on vacation to Amsterdam. See you soon :) -- Cheers, zimba.tm weblog : http://zimba.oree.ch From bakki.kudva at gmail.com Sun Feb 19 23:17:44 2006 From: bakki.kudva at gmail.com (Bakki Kudva) Date: Sun, 19 Feb 2006 23:17:44 -0500 Subject: [Nitro] problems with require on Debian Sarge Message-ID: Hi, I was having trouble with require 'nitro' until I added RUBYOPT=rubygems to my env. Now I am following along with the video samples from the web site and everything was fine until I got to Og. Now I get... ./model.rb:11: uninitialized constant Og::Database (NameError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__' from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from demo.rb:4 which is the require 'model' line. I am trying to use pgsql and have added .. db = Og::Database.new( :database => 'mydb', :adapter => 'psql', :user => 'bakki', :password => '' ) It's late and I am not seeing straight...so thought I'd shoot this one at the list. Thanks in advance for helping. -bakki PS: Which is the best place for the db config code? In the demo.rb or the model? Can you have different models which connect to different databases? From rob at motionpath.com Mon Feb 20 06:39:19 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 11:39:19 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: References: <1140182402.24540.30.camel@robs-p4> Message-ID: <1140435560.28264.4.camel@robs-p4> Problem is I only tested it with one half of the join, i.e because the property name is used in the join table construction the other side of the join makes a different join table (based on it's property name). Attached is patch to join test-case to illustrate problem, (although tc_store already did, it's a join test so belongs in there). I am a little stumped over what to do. I figure that if you have only one join relationship, it should be assumed to work in the old manner, if you make multiples then you should need to add hints like :foreign_name => :foobar ala has_many? I really need this functionality so I'm giving it some thought. If anyone has ideas please post (or code) them! :) Test case patch requires earlier patches (unfortunately since the concept is incomplete...) On Fri, 2006-02-17 at 12:48 -0800, Bryan Soto wrote: > Just a quick note. After this is applied, there is a new test failure: > > 1) Failure: > test_og(TCOgStore) > [./test/og/tc_store.rb:263:in `features_test' > ./test/og/tc_store.rb:76:in `test_og']: > <1> expected but was > <0>. > > I'll try and check it out later. > > On 2/17/06, Rob Pitt wrote: > WARNING: This patch causes join tables to be created with > different > names and will require you to manually copy join table data > into newly > named tables if applied to a project you are already using. > > Why would I make a patch that requires this? Not having this > requirement > (i.e. doing it in an automated fashion) would be fairly > complicated and > a big drain on CPU. > > This patch still needs to be implemented at some point because > it > enables a desirable behaviour, and we are at 0.2 so we should > make > changes with big impacts like this now rather than later. > > This is a very minor modification so that a model like this > behaves as > it should: > > Class Article > property :title, String > > joins_many :first_join, Category > joins_many :second_join, Category > joins_many Category > > def initialize(title) > @title = title > end > end > > Without this patch, items you push into .first_join are > visible > in .second_join and the .categories join (all other > combinations of this > are also true). > > This is wrong, and this patch corrects 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: join-extra-test.patch Type: text/x-patch Size: 24705 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/256cc041/attachment.bin From rob at motionpath.com Mon Feb 20 07:01:20 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 12:01:20 +0000 Subject: [Nitro] [PATCH] Allow multiple joins_many style relationships between two classes (and relevent test case) In-Reply-To: <1140435560.28264.4.camel@robs-p4> References: <1140182402.24540.30.camel@robs-p4> <1140435560.28264.4.camel@robs-p4> Message-ID: <1140436881.28264.8.camel@robs-p4> Export of our whiteboard discussion, request for comments (am implementing this unless a better idea surfaces). On Mon, 2006-02-20 at 11:39 +0000, Rob Pitt wrote: > Problem is I only tested it with one half of the join, i.e because the > property name is used in the join table construction the other side of > the join makes a different join table (based on it's property name). > > Attached is patch to join test-case to illustrate problem, (although > tc_store already did, it's a join test so belongs in there). > > I am a little stumped over what to do. I figure that if you have only > one join relationship, it should be assumed to work in the old manner, > if you make multiples then you should need to add hints > like :foreign_name => :foobar ala has_many? > > I really need this functionality so I'm giving it some thought. If > anyone has ideas please post (or code) them! :) > > Test case patch requires earlier patches (unfortunately since the > concept is incomplete...) > > > > On Fri, 2006-02-17 at 12:48 -0800, Bryan Soto wrote: > > Just a quick note. After this is applied, there is a new test failure: > > > > 1) Failure: > > test_og(TCOgStore) > > [./test/og/tc_store.rb:263:in `features_test' > > ./test/og/tc_store.rb:76:in `test_og']: > > <1> expected but was > > <0>. > > > > I'll try and check it out later. > > > > On 2/17/06, Rob Pitt wrote: > > WARNING: This patch causes join tables to be created with > > different > > names and will require you to manually copy join table data > > into newly > > named tables if applied to a project you are already using. > > > > Why would I make a patch that requires this? Not having this > > requirement > > (i.e. doing it in an automated fashion) would be fairly > > complicated and > > a big drain on CPU. > > > > This patch still needs to be implemented at some point because > > it > > enables a desirable behaviour, and we are at 0.2 so we should > > make > > changes with big impacts like this now rather than later. > > > > This is a very minor modification so that a model like this > > behaves as > > it should: > > > > Class Article > > property :title, String > > > > joins_many :first_join, Category > > joins_many :second_join, Category > > joins_many Category > > > > def initialize(title) > > @title = title > > end > > end > > > > Without this patch, items you push into .first_join are > > visible > > in .second_join and the .categories join (all other > > combinations of this > > are also true). > > > > This is wrong, and this patch corrects 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 -------------- next part -------------- Solving the multiple join problem ================================= Problem ======= You should be able to join two models together multiple times, i.e. class Article property :title, String joins_many :first_join, Category, :through => ArticleToCategory joins_many :second_join, Category, :through => ArticleToCategory joins_many :third_join, Category joins_many :fourth_join, Category joins_many Category end class Category property :title, String joins_many Article def initialize(title) @title = title end end At present .third_join, .fourth_join and .categories all return the same result. First Solution ============== Add the property name to the join table construction, i.e.: * ogj_article_category becomes: * ogj_article_category_third_join * ogj_article_category_fourth_join * ogj_article_category_categories The problem with this soultion was category.articles then no longer returns the same as article.categories as it refers to a seperate join table: * ogj_article_category_articles Proposed solution: ================== No effective way of automatically determining the relationships could be determined. Hints must be provided by providing the join table name for extra joins: class Article property :title, String joins_many :first_join, Category, :through => ArticleToCategory joins_many :second_join, Category, :through => ArticleToCategory joins_many :third_join, Category, :table => :ogj_article_category_third joins_many :fourth_join, Category, :table => :ogj_article_category_fourth joins_many Category end class Category property :title, String joins_many Article joins_many :third_join, Article, :table => :ogj_article_category_third joins_many :fourth_join, Article, :table => :ogj_article_category_fourth def initialize(title) @title = title end end From rob at motionpath.com Mon Feb 20 07:43:55 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 12:43:55 +0000 Subject: [Nitro] [PATCH] Working backwards-compatible fix for the multiple join case. Message-ID: <1140439435.28264.14.camel@robs-p4> Adds option :table to joins relations. If set, this table is used in preference to an automatically generated one. This patch is completely independent of the patches I released on Friday to solve this (which should all be scrapped). Test suite ran OK for me here (with the 6 explosions it had before applying this patch). tc_store works ok now (postgresql). the expanded join test cases work demonstrating this feature (and highlighting the problem it solves). Sorry for Friday confusion. If this patch works with other stores (mysql) suggest for inclusion in glycerin. Note to devs: I changed join_table_info so it accepts a relation as argument not two classes. -------------- next part -------------- A non-text attachment was scrubbed... Name: join-tables-revised.patch.bz2 Type: application/x-bzip Size: 7552 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/91778a3c/attachment.bin From rob at motionpath.com Mon Feb 20 11:00:41 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 16:00:41 +0000 Subject: [Nitro] [PATCH] Unset integer properies should be nil not 0, which is a value. Message-ID: <1140451241.28264.16.camel@robs-p4> Empty integer properties should be nil not zero. Zero is valid number that you may wish to explicitly set, nil is unmistakably empty. -------------- next part -------------- A non-text attachment was scrubbed... Name: property-fix.patch.bz2 Type: application/x-bzip Size: 7145 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/fecada18/attachment.bin From nusgnaf at gmail.com Mon Feb 20 11:03:18 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Mon, 20 Feb 2006 16:03:18 +0000 Subject: [Nitro] Og bug? Message-ID: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> Hello, devs. I play with Og a little recently. I find that 'has_many' and 'belongs_to' relation doesn't work with dirctly defined class. For example see attached notwork.rb. It returns "notwork.rb:18: undefined method `belongs_to' for UserComment:Class (NoMethodError)" However, if I make a new class define the new table, and subclass it and define belongs_to there as following: ---------------------- class A property ... has_many WhatINeed end class B property a, String end class WhatINeed < B belongs_to A end ----------------- then everything works. Please see attatched work.rb for the working code Is it a bug? -------------- next part -------------- A non-text attachment was scrubbed... Name: notwork.rb Type: application/octet-stream Size: 454 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/45616bc1/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: work.rb Type: application/octet-stream Size: 481 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/45616bc1/attachment-0001.obj From rob at motionpath.com Mon Feb 20 11:15:27 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 16:15:27 +0000 Subject: [Nitro] [PATCH] Memory session in nitro needs the glue logger Message-ID: <1140452127.28264.18.camel@robs-p4> Self explanatory. -------------- next part -------------- A non-text attachment was scrubbed... Name: memory-session-needs-logger.patch.bz2 Type: application/x-bzip Size: 7121 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/4889875c/attachment.bin From rob at motionpath.com Mon Feb 20 11:17:29 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 16:17:29 +0000 Subject: [Nitro] Og bug? In-Reply-To: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> References: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> Message-ID: <1140452249.28264.21.camel@robs-p4> Add a property to WhatINeed (or it might work if you declare the class as): class WhatINeed < Og::Entity ... end This is a known issue and those are the easy work arounds (I usually do): class WhatINeed is Timestamped ... end Which adds some properties it and causes the class to become enchanted. On Mon, 2006-02-20 at 16:03 +0000, Fang Sun wrote: > Hello, devs. > I play with Og a little recently. I find that 'has_many' and > 'belongs_to' relation doesn't work with dirctly defined class. For > example see attached notwork.rb. It returns "notwork.rb:18: undefined > method `belongs_to' for UserComment:Class (NoMethodError)" > However, if I make a new class define the new table, and subclass it > and define belongs_to there as following: > ---------------------- > class A > property ... > has_many WhatINeed > end > > class B > property a, String > end > > class WhatINeed < B > belongs_to A > end > ----------------- > then everything works. > Please see attatched work.rb for the working code > Is it a bug? > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From rob at motionpath.com Mon Feb 20 11:58:36 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 16:58:36 +0000 Subject: [Nitro] [PATCH] Fixes to bugs caused by facets update Message-ID: <1140454716.28264.24.camel@robs-p4> You probably haven't noticed these because you have the old version of facets installed as well as the latest and ruby gems saves you but all these requires are broken. -------------- next part -------------- A non-text attachment was scrubbed... Name: facets-fixes.patch.bz2 Type: application/x-bzip Size: 7288 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/fc6b4b64/attachment.bin From rob at motionpath.com Mon Feb 20 12:32:56 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 17:32:56 +0000 Subject: [Nitro] [PATCH] Scaffold post aspect should be able to receive the oid of created object Message-ID: <1140456776.28264.26.camel@robs-p4> So now it does. -------------- next part -------------- A non-text attachment was scrubbed... Name: scaffold-aspects-patch.patch.bz2 Type: application/x-bzip Size: 7140 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060220/5d7f5647/attachment.bin From rob at motionpath.com Mon Feb 20 12:35:12 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 17:35:12 +0000 Subject: [Nitro] Localization In-Reply-To: <9c00d3e00602180427i6ebd057ax@mail.gmail.com> References: <9c00d3e00602172346v315b8d4bn@mail.gmail.com> <5A919F09-D11E-4CFB-B557-6645D791DE6D@motionpath.com> <9c00d3e00602180427i6ebd057ax@mail.gmail.com> Message-ID: <1140456912.28264.27.camel@robs-p4> We always spec out pipelines so I never considered this. Creating some default selectable pipelines is a great idea! On Sat, 2006-02-18 at 21:27 +0900, Michael Fellinger wrote: > sorry, i was in a hurry and didn't think properly - here is the stuff > in a nice .tar.gz way :) > > 2006/2/18, rob : > > Can you please zip up attachments to the list? They get mangled > > otherwise. > > > > I don't think Localization should be in the default pipe, it's very > > easy to change the pipeline if you need it and most of us don't need > > Localization in 90% of our projects. I am against it, but not > > strongly so as it is just as easy for me to remove it from the > > pipeline as it is for you to add it. > > Well, here is the problem, every change to the pipeline needs a > complete listing of a new pipeline you want to use. > but, thinking more about it we could make a couple of > default-pipelines, just choosing the current one as the real default > and providing a _fully_loaded_ one as well as some other ones for > common tasks like the localization or use of the > javascript-compiler... > should be pretty trivial to make, but spares some problems for some > people, i'll take a stab at it later. > The real problem with custom pipelines is that you have to figure out > the correct order to put them in - in the case a compiler does not > work properly it is a pain to find out wich one is causing the trouble > and how to make it work properly without breaking other compilers at > the same time. > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nusgnaf at gmail.com Mon Feb 20 12:46:46 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Mon, 20 Feb 2006 17:46:46 +0000 Subject: [Nitro] Og bug? In-Reply-To: <1140452249.28264.21.camel@robs-p4> References: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> <1140452249.28264.21.camel@robs-p4> Message-ID: <716700c90602200946g14caa02cyea6877cde1610144@mail.gmail.com> Thanks for your reply. From transfire at gmail.com Mon Feb 20 12:56:07 2006 From: transfire at gmail.com (TRANS) Date: Mon, 20 Feb 2006 17:56:07 +0000 Subject: [Nitro] Facets in Nitro Message-ID: <4b6f054f0602200956p3bf65412h4e702237a2b98392@mail.gmail.com> Alright, I'm ready to hand over Facets to the Nitro repository. Who will put it into the repository? Note, there is one outstanding issue with Facets that needs to be address right away. There are some configuration and shared data files, and RubyGems does not support these (like setup.rb does). This breaks units.rb and also effects Facets' meta-information. So this is one the first things that will need to be fixed. T. From rob at motionpath.com Mon Feb 20 13:04:35 2006 From: rob at motionpath.com (Rob Pitt) Date: Mon, 20 Feb 2006 18:04:35 +0000 Subject: [Nitro] Og bug? In-Reply-To: <716700c90602200946g14caa02cyea6877cde1610144@mail.gmail.com> References: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> <1140452249.28264.21.camel@robs-p4> <716700c90602200946g14caa02cyea6877cde1610144@mail.gmail.com> Message-ID: <1140458676.28264.30.camel@robs-p4> Did it help? I didn't read your original post too carefully and I notice you are trying to inherit from one class to the other without doing STI. If it didn't help, if you post a small application that I can run without changing anything that demonstrates the problem I will fix it for you. On Mon, 2006-02-20 at 17:46 +0000, Fang Sun wrote: > Thanks for your reply. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Mon Feb 20 14:47:32 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 20 Feb 2006 11:47:32 -0800 Subject: [Nitro] [Tracker:Bug] schema_inheritance In-Reply-To: <9c00d3e00602172349h2a533facu@mail.gmail.com> References: <9c00d3e00602172349h2a533facu@mail.gmail.com> Message-ID: I thought that was you :) I did get it into current repo and left your bug report open so we ensure it's applied to George's. Thanks for reporting. I hope your giving Nitro/Og a good workout and find more. :) Bryan On 2/17/06, Michael Fellinger wrote: > > Hey list, > I added a new bug that is around for a while now to the tracker.theoriginal thread > washttp://rubyforge.org/pipermail/nitro-general/2006-January/002601.html > you can find it on the tracker: > http://rubyforge.org/tracker/index.php?func=detail&aid=3573&group_id=418&atid=1670 > thx in prev~~~~manveru > _______________________________________________ > 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/20060220/f4607716/attachment.html From bryan.a.soto at gmail.com Mon Feb 20 17:59:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 20 Feb 2006 14:59:00 -0800 Subject: [Nitro] Facets in Nitro In-Reply-To: <4b6f054f0602200956p3bf65412h4e702237a2b98392@mail.gmail.com> References: <4b6f054f0602200956p3bf65412h4e702237a2b98392@mail.gmail.com> Message-ID: On 2/20/06, TRANS wrote: > > Alright, I'm ready to hand over Facets to the Nitro repository. Who > will put it into the repository? Do you have a repo or something or should we just use what's available via Rubyforge? Note, there is one outstanding issue with Facets that needs to be > address right away. There are some configuration and shared data > files, and RubyGems does not support these (like setup.rb does). > This breaks units.rb and also effects Facets' meta-information. So > this is one the first things that will need to be fixed. > > I hope this isn't a silly suggestion, but why not move them to facets-1.0.3/packages/[data|common]? Or maybe that becomes too ridiculous? Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060220/4b6cd0ac/attachment.html From bryan.a.soto at gmail.com Mon Feb 20 21:16:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 20 Feb 2006 18:16:09 -0800 Subject: [Nitro] problems with require on Debian Sarge In-Reply-To: References: Message-ID: Hi, On 2/19/06, Bakki Kudva wrote: > > Hi, > > I was having trouble with require 'nitro' until I added > RUBYOPT=rubygems to my env. > Now I am following along with the video samples from the web site and > everything was fine until I got to Og. Now I get... > ./model.rb:11: uninitialized constant Og::Database (NameError) > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require__' > from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in > `require' > from demo.rb:4 > which is the require 'model' line. > > I am trying to use pgsql and have added .. > db = Og::Database.new( > :database => 'mydb', > :adapter => 'psql', > :user => 'bakki', > :password => '' > ) Should be db = Og.setup( # different :name => 'mydb', # different :store => 'psql', # different :user => 'bakki', :password => '' ) I think you are reading this off the wiki? Unfortunately, that portion is out of date and it's not showing changes properly so we can't fix :( I think the rest is okay, so if you run into problems, please don't hesitate to ask. :) It's late and I am not seeing straight...so thought I'd shoot this one > at the list. > Thanks in advance for helping. > > -bakki > > PS: Which is the best place for the db config code? In the demo.rb or > the model? Can you have different models which connect to different > databases? Wherever you like actually. :) Though it's usually put it in a run.rb file (or in your case demo.rb) so it's with the rest of the configuration stuff. You can in theory. It was never used a whole lot so it has some quirks. If you need more info on that please let me know. Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060220/1d1d1792/attachment.html From nusgnaf at gmail.com Tue Feb 21 01:31:47 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Tue, 21 Feb 2006 06:31:47 +0000 Subject: [Nitro] Og bug? In-Reply-To: <1140458676.28264.30.camel@robs-p4> References: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> <1140452249.28264.21.camel@robs-p4> <716700c90602200946g14caa02cyea6877cde1610144@mail.gmail.com> <1140458676.28264.30.camel@robs-p4> Message-ID: <716700c90602202231sa5731abr8d2c0470d83cd6e8@mail.gmail.com> Yeah, inherit from Og::Entity works. Thanks. From nusgnaf at gmail.com Tue Feb 21 02:22:29 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Tue, 21 Feb 2006 07:22:29 +0000 Subject: [Nitro] Og bug? In-Reply-To: <716700c90602202231sa5731abr8d2c0470d83cd6e8@mail.gmail.com> References: <716700c90602200803l20586ab9te5413a6739f73847@mail.gmail.com> <1140452249.28264.21.camel@robs-p4> <716700c90602200946g14caa02cyea6877cde1610144@mail.gmail.com> <1140458676.28264.30.camel@robs-p4> <716700c90602202231sa5731abr8d2c0470d83cd6e8@mail.gmail.com> Message-ID: <716700c90602202322y255f4df5hd55eb6471d452541@mail.gmail.com> By the way. What does STI stands for? I cannot find related infomation from nitrohq.com. Does it mean helper og class that automatically defines properties like is (Orderable|Timestamped|...) ? From bryan.a.soto at gmail.com Tue Feb 21 02:49:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 20 Feb 2006 23:49:09 -0800 Subject: [Nitro] [PATCH] Fixes to bugs caused by facets update In-Reply-To: <1140454716.28264.24.camel@robs-p4> References: <1140454716.28264.24.camel@robs-p4> Message-ID: On 2/20/06, Rob Pitt wrote: > > You probably haven't noticed these because you have the old version of > facets installed as well as the latest and ruby gems saves you but all > these requires are broken. > Hi, Are you sure you did this one against facets 1.0.2+? It seems that the changes you made are to non-existent files in it. # from patch... hunk ./glue/lib/glue/fixture.rb 3 -require 'facet/ormsupport' +require 'facet/orm_support' C:\ruby\lib\ruby\gems\1.8\gems\facets_more-1.0.2\lib>ls facet\ormsupport.rb facet\ormsupport.rb C:\ruby\lib\ruby\gems\1.8\gems\facets_more-1.0.2\lib>ls facet\orm_support.rb ls: facet\orm_support.rb: No such file or directory C:\ruby\lib\ruby\gems\1.8\gems\facets-1.0.3\packages\more\lib>ls facet\ormsupport.rb facet\ormsupport.rb C:\ruby\lib\ruby\gems\1.8\gems\facets-1.0.3\packages\more\lib>ls facet\orm_support.rb ls: facet\orm_support.rb: No such file or directory Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060221/1e797859/attachment.html From rob at motionpath.com Tue Feb 21 04:22:55 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 21 Feb 2006 09:22:55 +0000 Subject: [Nitro] [PATCH] Fixes to bugs caused by facets update In-Reply-To: References: <1140454716.28264.24.camel@robs-p4> Message-ID: <1140513775.28264.33.camel@robs-p4> no your right, when you do gem cleanup it deletes facets 1.0.2 and keeps the older version... On Mon, 2006-02-20 at 23:49 -0800, Bryan Soto wrote: > On 2/20/06, Rob Pitt wrote: > You probably haven't noticed these because you have the old > version of > facets installed as well as the latest and ruby gems saves you > but all > these requires are broken. > > Hi, > > Are you sure you did this one against facets 1.0.2+? It seems that the > changes you made are to non-existent files in it. > > # from patch... > hunk ./glue/lib/glue/fixture.rb 3 > -require 'facet/ormsupport' > +require 'facet/orm_support' > > C:\ruby\lib\ruby\gems\1.8\gems\facets_more-1.0.2\lib>ls facet > \ormsupport.rb > facet\ormsupport.rb > > C:\ruby\lib\ruby\gems\1.8\gems\facets_more-1.0.2\lib>ls facet > \orm_support.rb > ls: facet\orm_support.rb: No such file or directory > > C:\ruby\lib\ruby\gems\1.8\gems\facets-1.0.3\packages\more\lib>ls facet > \ormsupport.rb > facet\ormsupport.rb > > C:\ruby\lib\ruby\gems\1.8\gems\facets-1.0.3\packages\more\lib>ls facet > \orm_support.rb > ls: facet\orm_support.rb: No such file or directory > > Bryan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nusgnaf at gmail.com Tue Feb 21 06:36:58 2006 From: nusgnaf at gmail.com (Fang Sun) Date: Tue, 21 Feb 2006 11:36:58 +0000 Subject: [Nitro] cache_ouput Message-ID: <716700c90602210336r1eafe161m5f9a948fc753c80b@mail.gmail.com> Hello, everyone. I run flare under live mode, using nitro 0.28 + Webrick adapter. Nitro will generate static page for cached_output actions. This improve the performance alot. However, because nitro/webrick will find static page first, this breaks paginated actions. urls like http://127.0.0.1:9999/?_page=2 doesn't invoke proper actions. nitro/webrick serve me the cached static page. Is it possiable let nitro to dispatch request invoke POST method to controller instead of server the cached page? Thanks in advance. From fabian at oggu.de Tue Feb 21 09:54:39 2006 From: fabian at oggu.de (Fabian Buch) Date: Tue, 21 Feb 2006 15:54:39 +0100 Subject: [Nitro] fastcgi without Og Message-ID: <5a811eb8372b9d54388f028293fcf520@oggu.de> hi, I just started writing a new app, which doesn't need a database yet, so I didn't require Og in my run.rb. That led to the following error: /usr/lib/ruby/gems/1.8/gems/nitro-0.28.0/lib/nitro/adapter/fastcgi.rb: 16: undefined method `thread_safe=' for Og:Module (NoMethodError) Of course I can just uncommend that or require Og anyway (which I did for now), but maybe a nitro-adapter shouldn't rely on Og being enabled. What would be the best way for the fastcgi-adapter to ask for whether og enabled? Fabian Buch From rob at motionpath.com Tue Feb 21 10:16:40 2006 From: rob at motionpath.com (Rob Pitt) Date: Tue, 21 Feb 2006 15:16:40 +0000 Subject: [Nitro] Stop compiler exploding if people put double slashes in URL Message-ID: <1140535000.28264.35.camel@robs-p4> You shouldn't do this, but it's not acceptable Nitro crashes, so now it doesn't. -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler-fix.patch.bz2 Type: application/x-bzip Size: 7199 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060221/e4921bb6/attachment.bin From fabian at oggu.de Tue Feb 21 10:42:54 2006 From: fabian at oggu.de (fabian at oggu.de) Date: Tue, 21 Feb 2006 16:42:54 +0100 Subject: [Nitro] small patch for xhtml-validity Message-ID: <20060221154254.GA20465@r1> Just made a small patch to the script compiler. Now it inserts the