From george.moschovitis at gmail.com Sun Apr 1 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Mon, 2 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070402000501.E514B8707@reizu.com> >From rmela.myopenid.com Date: Sun Apr 01 01:07:11 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/a6fxwU3DSr27NzeJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/br-uQW3-0r27Z_eJeZaaqU Patch attached, I hope. Whittled it down to the create_tbody? fix, since the xml-simple seems unsettled, and the glycerin include should probably be left a comment ( with some additional notes ) >From gmosx.myopenid.com Date: Sun Apr 01 09:07:15 UTC 2007 Subject: Polymorphic relations Message-ID: http://www.nitroproject.org/fora/posts/view/bIxv4i4dar27Z_eJeZaaqU Dear devs, I am wondering, does anyone use the polymorphic relations feature of Og? I was looking over this yesterday, and I am not sure it's usefulness justifies the extra complexity in Og's source code. What do you think? regards, -g. >From gmosx.myopenid.com Date: Sun Apr 01 09:05:09 UTC 2007 Subject: RE: Message-ID: http://www.nitroproject.org/fora/posts/view/axHaGu4dar27Z_eJeZaaqU Ok, got it... -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From george.moschovitis at gmail.com Tue Apr 3 04:41:20 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Tue, 3 Apr 2007 08:41:20 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070403084120.4BB1B8705@reizu.com> >From rmela.myopenid.com Date: Mon Apr 02 00:55:49 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/bIxv4i4dar27Z_eJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/dMckJM4lqr27Z_eJeZaaqU Could you point me to the source files and intended uses? >From rmela.myopenid.com Date: Mon Apr 02 01:45:07 UTC 2007 Subject: Double inserts in admin/og/controller Message-ID: http://www.nitroproject.org/fora/posts/view/dju_Ju4lSr27Z_eJeZaaqU < true) 96 else 97 obj = klass.create ##### invokes save on obj before returning obj to caller #### 98 obj.assign(request, :assign_relations => true) 99 end 100 101 unless obj.valid? 102 flash.concat :ERRORS, obj.errors 103 redirect_to_referer 104 end 105 106 obj.save ### but obj was already saved in klass.create (and if oid is null????) #### 107 108 redirect :list, :name, obj.class 109 end >From rmela.myopenid.com Date: Mon Apr 02 02:12:29 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/dju_Ju4lSr27Z_eJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/cB8j124l8r27Z_eJeZaaqU
One more note, after trying the same code in mysql instead of sqlite. Any save of a new object to datastore will result in a new oid for the object. Should the in-memory copy of the object should be updated with the OID? My initial thought is that it should. If so, is that the responsibility of the adapter?
-- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From george.moschovitis at gmail.com Tue Apr 3 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Wed, 4 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070404000501.C8DDB8705@reizu.com> >From gmosx.myopenid.com Date: Tue Apr 03 23:01:39 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/dju_Ju4lSr27Z_eJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/bhSGcw4JCr277deJeZaaqU If you don't want the object to be saved just use .new instead of .create. I cannot really understand your problem. Maybe it is better to read your post again tommorow, after a good sleep ;-) -g. -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From transfire at gmail.com Tue Apr 3 20:06:58 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Wed, 04 Apr 2007 00:06:58 -0000 Subject: [Nitro] cherry rather the simple Message-ID: <1175645218.297448.186800@l77g2000hsb.googlegroups.com> cherry xml might be useful in place of xml-simple. it's more like e4x and hpricot in usage, but it can use either rexml of libxml as a back- end. cherry's hasn't gotten a lot of use yet, so I'm sure it still needs polish. but I have used on some side projects with good results. T. From george.moschovitis at gmail.com Wed Apr 4 02:26:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 Apr 2007 09:26:39 +0300 Subject: [Nitro] cherry rather the simple In-Reply-To: <1175645218.297448.186800@l77g2000hsb.googlegroups.com> References: <1175645218.297448.186800@l77g2000hsb.googlegroups.com> Message-ID: Ok, I will check this out in the nest days. I am trying to put the finishing touches on a new section of np.org at the moment. -g. On 4/4/07, transfire at gmail.com wrote: > cherry xml might be useful in place of xml-simple. it's more like e4x > and hpricot in usage, but it can use either rexml of libxml as a back- > end. cherry's hasn't gotten a lot of use yet, so I'm sure it still > needs polish. but I have used on some side projects with good results. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Apr 4 08:13:45 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 Apr 2007 15:13:45 +0300 Subject: [Nitro] Nitro Blog Message-ID: Dear devs, today I updated the np.org site and added a new blog: http://nitroproject.org/blog I would like to hear about bugs and your suggestions. As always I have already found a few problems that will be in tommorows update. check it out ;-) -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From dan at tastapod.com Wed Apr 4 10:27:33 2007 From: dan at tastapod.com (Dan North) Date: Wed, 04 Apr 2007 15:27:33 +0100 Subject: [Nitro] cherry rather the simple In-Reply-To: <1175645218.297448.186800@l77g2000hsb.googlegroups.com> References: <1175645218.297448.186800@l77g2000hsb.googlegroups.com> Message-ID: <4613B5D5.5060505@tastapod.com> Can you post some examples of cherry-picked xml, so I can see how it's different from the current libraries? I'm very interested in an intuitive, fast, simple xml api. Thanks, Dan transfire at gmail.com wrote: > cherry xml might be useful in place of xml-simple. it's more like e4x > and hpricot in usage, but it can use either rexml of libxml as a back- > end. cherry's hasn't gotten a lot of use yet, so I'm sure it still > needs polish. but I have used on some side projects with good results. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From james.britt at gmail.com Wed Apr 4 17:37:53 2007 From: james.britt at gmail.com (James Britt) Date: Wed, 04 Apr 2007 14:37:53 -0700 Subject: [Nitro] Nitro Blog In-Reply-To: References: Message-ID: <46141AB1.7030001@gmail.com> George Moschovitis wrote: > Dear devs, > > today I updated the np.org site and added a new blog: > > http://nitroproject.org/blog > > I would like to hear about bugs and your suggestions. As always I have > already found a few problems that will be in tommorows update. > > check it out ;-) Neat! Three things: * Consider adding a element to the header that links to the atom feed so that tools such as BLoglines can automagically find it: * The current atom feed seems broken. * Add link to download the blog source code. :) -- James Britt "Design depends largely on constraints." - Charles Eames From george.moschovitis at gmail.com Wed Apr 4 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Thu, 5 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070405000501.E03768741@reizu.com> >From rmela.myopenid.com Date: Wed Apr 04 22:21:13 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/dju_Ju4lSr27Z_eJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/dmfenI4VOr24weeJeZaaqU But I'm not the one using create --- you are!!! This is a bug report!!! ;) However, you've provided some insight into the fix. I can delete line 106 ( above ) from OgAdminController.save and send the patch to you. >From gmosx.myopenid.com Date: Wed Apr 04 08:18:21 UTC 2007 Subject: Check out the new Blog Message-ID: http://www.nitroproject.org/fora/posts/view/amZ-ZI4Our27L2eJeZaaqU Dear devs, I just addes a blog to this site. As always, I would like to hear bug reports and comments. thanks, -g. -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From george.moschovitis at gmail.com Thu Apr 5 02:12:49 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 5 Apr 2007 09:12:49 +0300 Subject: [Nitro] Nitro Blog In-Reply-To: <46141AB1.7030001@gmail.com> References: <46141AB1.7030001@gmail.com> Message-ID: > * Consider adding a element to the header that links to the > atom feed so that tools such as BLoglines can automagically find it: > > href="http://www.nitroproject.org/blog.atom" /> ah, nice idea... > * The current atom feed seems broken. I ve seen that, will fix. > * Add link to download the blog source code. will provide the source to a similar blog. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Thu Apr 5 08:12:38 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 05 Apr 2007 15:12:38 +0300 Subject: [Nitro] HTTP verbs and headers In-Reply-To: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> References: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> Message-ID: Hi, sorry for the long delay. :) > The program just requests 'http://localhost/' using different HTTP verbs > and prints the returned status codes. All requests return '200 OK'. > According to the HTTP specs I should get a '405 Method Not Allowed' when > using 'unallowed' verbs. I'm not actually sure if Nitro is responsible > for the headers (might be set by webrick/mongrel), but maybe it is > fixable. > (For 'correct' behaviour, please test against 'www.w3.org'). > > Any comments or suggestions? Yes, Nitro is responsible for that, as it would have to treat 'PUT' differently from 'POST', but not disallow 'POST' (like w3.org) on the spot. Nitro would have to check for every action if the action 'accepts' post/put/get/head, which isn't really all too great (some meta- data would have to be used). So, that it just returns 200 for all is ok in my eyes. (Unless there's an error in my reasoning here....) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Thu Apr 5 08:12:34 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 05 Apr 2007 15:12:34 +0300 Subject: [Nitro] Nitro Blog In-Reply-To: References: Message-ID: Hi, > today I updated the np.org site and added a new blog: > > http://nitroproject.org/blog > > I would like to hear about bugs and your suggestions. As always I have > already found a few problems that will be in tommorows update. < References: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> Message-ID: <461524BC.4010403@lassoweb.se> Hi, I'm quite sure no current Nitro code is affected in any way by the current behaviour (returning 200 OK on all requests), it's just a question about how Nitro wants to intepret the HTTP spec(1). My original test case came about after reading some articles about REST (and WebDAV). I was curious about how Nitro handled stuff like PUT and DELETE. Even if Nitro in its current form is heavily geared towards 'normal' browsing, there really is a lot of other stuff based on HTTP going on. Whether Nitro should support 'other stuff' than normal browsing is of course open to discussion. > Yes, Nitro is responsible for that, as it would have to treat 'PUT' > differently from 'POST', but not disallow 'POST' (like w3.org) on the > spot. Nitro would have to check for every action if the action > 'accepts' post/put/get/head, which isn't really all too great (some meta- > data would have to be used). What do you mean by meta data? The HTTP verb is readily available from the web server (HttpRequest.request_method when using Webrick, I'm pretty sure Mongrel has something similar). > So, that it just returns 200 for all is ok in my eyes. (Unless there's > an error in my reasoning here....) It's OK depending on how you interpret the spec :) 200 OK means that the request was accepted and processed acording to the spec. Since this isn't the case, Nitro is lying to the client connecting to the server. My suggestion is to reject all HTTP verbs other than GET and POST (405 Method Not Allowed) until (if ever) Nitro has the capabilty to respond to other verbs. Sincerely /lasso (1) The spec I keep rambling on about can be found at: http://tools.ietf.org/html/rfc2068 From george.moschovitis at gmail.com Fri Apr 6 02:37:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 6 Apr 2007 09:37:09 +0300 Subject: [Nitro] HTTP verbs and headers In-Reply-To: <461524BC.4010403@lassoweb.se> References: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> <461524BC.4010403@lassoweb.se> Message-ID: > WebDAV). I was curious about how Nitro handled stuff like PUT and DELETE. The latest version of Nitro specially handles PUT, DELETE etc as it provides an automatic REST interface. > Whether Nitro should support 'other stuff' than normal browsing is of > course open to discussion. As I said, the repo version of Nitro already supports web services. > My suggestion is to reject all HTTP verbs other than GET and POST > (405 Method Not Allowed) until (if ever) Nitro has the capabilty to > respond to other verbs. I will consider this, thanks for reporting. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Fri Apr 6 02:41:30 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 6 Apr 2007 09:41:30 +0300 Subject: [Nitro] HTTP verbs and headers In-Reply-To: References: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> <461524BC.4010403@lassoweb.se> Message-ID: > The latest version of Nitro specially handles PUT, DELETE etc as it > provides an automatic REST interface. I will post a short article on this to the blog, stay tuned. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Fri Apr 6 04:26:08 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 06 Apr 2007 11:26:08 +0300 Subject: [Nitro] HTTP verbs and headers In-Reply-To: <461524BC.4010403@lassoweb.se> References: <46527.192.176.230.1.1175159041.squirrel@webmail.lassoweb.se> <461524BC.4010403@lassoweb.se> Message-ID: Hi, > I'm quite sure no current Nitro code is affected in any way by the > current behaviour (returning 200 OK on all requests), it's just a > question about how Nitro wants to intepret the HTTP spec(1). My original > test case came about after reading some articles about REST (and > WebDAV). I was curious about how Nitro handled stuff like PUT and DELETE. > > Even if Nitro in its current form is heavily geared towards 'normal' > browsing, there really is a lot of other stuff based on HTTP going on. > Whether Nitro should support 'other stuff' than normal browsing is of > course open to discussion. Oh yes, like George said in his reply, the new REST like functions included in the latest repo version are geared towards the non-browser stuff. My mind is just always centered around the repo version, so I thought that Nitro already interpreted PUT/DELETE. (And I'm almost sure it did so since at least 0.29). >> Yes, Nitro is responsible for that, as it would have to treat 'PUT' >> differently from 'POST', but not disallow 'POST' (like w3.org) on the >> spot. Nitro would have to check for every action if the action >> 'accepts' post/put/get/head, which isn't really all too great (some meta- >> data would have to be used). > > What do you mean by meta data? The HTTP verb is readily available from > the web server (HttpRequest.request_method when using Webrick, I'm > pretty sure Mongrel has something similar). This was in relation to how 405 was returned by w3.org. (slightly modified version of your script) jo:~/test john$ ./reterr.rb www.w3.org/ GET www.w3.org/...200 OK HEAD www.w3.org/...200 OK POST www.w3.org/...405 Method Not Allowed PUT www.w3.org/...302 Found DELETE www.w3.org/...405 Method Not Allowed jo:~/test john$ ./reterr.rb www.w3.org/Search/Mail/Public/search GET www.w3.org/Search/Mail/Public/search...200 OK HEAD www.w3.org/Search/Mail/Public/search...200 OK POST www.w3.org/Search/Mail/Public/search...200 OK PUT www.w3.org/Search/Mail/Public/search...302 Found DELETE www.w3.org/Search/Mail/Public/search...200 OK Which means, the POST verb is not forbidden on all requests, but is somehow specified within the 'action'. (meta data) (well, of course this could be and probably is a complete different backend to the index page, but still) >> So, that it just returns 200 for all is ok in my eyes. (Unless there's >> an error in my reasoning here....) > > It's OK depending on how you interpret the spec :) 200 OK means that the > request was accepted and processed acording to the spec. Since this > isn't the case, Nitro is lying to the client connecting to the server. > > My suggestion is to reject all HTTP verbs other than GET and POST > (405 Method Not Allowed) until (if ever) Nitro has the capabilty to > respond to other verbs. class MyController def index if request.post? elsif request.get? elsif request.delete? end end end I think that this nitro controller would also work in earlier versions. (Untested though) And that it would also 'handle' PUT requests. Just not quite adhering to the RFC out of the box. In my mind, if someone makes a DELETE request here, the delete? branch would (now) have to create the correct return code and just 'behave' like DELETE should. But basically Nitro also handles all unknown verbs in the action as well, the user (controller writer) just didn't handle it explicitly. This is what I mean with 'meta data'. class MyController def index end ann :index, :handle => [:get, :post] end or globally Dispatcher.handle_http_verbs = [:get, :post, :head] Otherwise Nitro has no idea how to handle 'unknown' verbs and defers that decision to the user of the framework. So, you're right about the Nitro not adhering to the official specs, but atm only because the user didn't implement his actions 'correctly'. Note that this email is all purely theoretical and might be awfully off track. :) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Fri Apr 6 04:58:55 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 06 Apr 2007 11:58:55 +0300 Subject: [Nitro] [PATCH] many to many rich association handling non saved records Message-ID: Hi, sorry for the delay! > Which is an interesting point: Yes, this is interesting indeed. > Is there a policy level decision on how to treat unsaved objects? > Should they be silently saved whenever we need an oid for them? The current policy would be: save whenever we require an oid. (at least the relation code seems to tell me so) > My gut reaction is that it's not the right behavior. It's confusing, > and as Og settles and matures, I'd lay odds that it becomes the most > frequent source of frustration for new and old hands. I think I never found it frustrating from the programmers point of view, as it just never 'fails' per se. What it could create, is wasting roundtrips to the database, because the relationship object is getting saved by the user later again. > A possibility that presents itself: adapt sequences from postgres to > autoincrement-only dbs (just a table with an auto-increment column), > and if we need an oid for an unsaved model object (and here, I want to > call them entities...) grab the next_sequence for that table, and > stick it in the oid. Sidenote: This brings a age old idea from me back. It is about Og storing meta information about itself in the database. What now `create_field_map(klass)` does (ordering of the fields in a table, available fields etc, used for example by Evolution for updating the tables) could be cached in the database. class Model attr_accessor :name, String attr_accessor :ogtable, String, :primary_key => true attr_accessor :fields, Array attr_accessor :primary_key, String # emulate Postgresql sequences when mysql/sqlite attr_accessor :seq_last_value, Fixnum end Then use `Og.create_schema = true` to create this table and its contentents. This would speed up the startup time quite some I would imagine (with many models, this can be a pain). I'm just not sure about the safety of using such a method on mysql, would an access to the sequence have to be protected by a transaction? > Off the top of my head, one consequence would be that any > relation-following would need an adaptor class to find unsaved > destinations, so there's some complexity to not silently saving. Or: class Og::NotSavedError < Og::Error; end so, wherever a .save right now is in the code, just raise the error. I'm not yet clear if that is the right path to take, but it would be a possibility. But like I said, I don't really see a problem with the current approach, as it 'just works'. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Fri Apr 6 05:08:37 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 06 Apr 2007 12:08:37 +0300 Subject: [Nitro] injecting Og functionality Message-ID: Hi, sorry for not taking part in the orgiginal discussion, just trying to wrap it up. :P >> > It might be worth talking about whether it makes sense to fail fast on >> > missing Og::Model inclusions, and when to do that. >> Yes. I think it pretty trivial to add "is Model" to a class. >> >> In either case, I feel those should be the only two ways to do it. B/c >> it is efficient, not overly magical, and serves all use cases. The >> attr magic is neat, but I've always felt it complicates things >> unnecessarily. >Ok, give me a day or two to finalize the forum stuff on np.org (and > maybe work a bit on georgeandstella.com, remember, I am getting > married ;-)) and then I will make Og work more or less as you suggest So, the new Og will look like: class MyModel is Og::Model attr_accessor :foo, Bar end With no other 'enchanting' method allowed? Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Fri Apr 6 06:36:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 6 Apr 2007 13:36:44 +0300 Subject: [Nitro] injecting Og functionality In-Reply-To: References: Message-ID: > > class MyModel > is Og::Model > > attr_accessor :foo, Bar > end > yeap, Og tries to automagically include the Og::Model mixin where appropriate. All further 'enchanting' is done by including more modules (mixins). -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Fri Apr 6 16:07:50 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 06 Apr 2007 23:07:50 +0300 Subject: [Nitro] injecting Og functionality In-Reply-To: References: Message-ID: Hi, >> With no other 'enchanting' method allowed? > yeap, Og tries to automagically include the Og::Model mixin where > appropriate. All further 'enchanting' is done by including more > modules (mixins). This is kind of contradictory. :P My question was, will the automagical inclusion and the subclassing enchanting methods be removed? Some time ago I compiled a list on how to enchant an Og model: http://oxyliquit.de/tip/33 The rules are pretty much clear (to me) and I see no real advantage (other than nitro internal code simplification) to change the current behaviour. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Fri Apr 6 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Sat, 7 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070407000501.957878741@reizu.com> -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From john at oxyliquit.de Sat Apr 7 02:04:26 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 07 Apr 2007 09:04:26 +0300 Subject: [Nitro] [NP.ORG] Nitro/Og Fora daily diggest In-Reply-To: <20070407000501.957878741@reizu.com> References: <20070407000501.957878741@reizu.com> Message-ID: Hi, bug report, maybe don't send empty digests? ;) Oh yeah, and a small typo I didn't catch until now, subject: diggest Jo On Sat, 07 Apr 2007 03:05:01 +0300, wrote: > > > > -- > This mail is automatically generated from the http://nitroproject.org/fora > digest robot. It presents the discussions in the fora during the last 24 hours. > Do not reply to this email. -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Apr 7 02:58:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 Apr 2007 09:58:39 +0300 Subject: [Nitro] [NP.ORG] Nitro/Og Fora daily diggest In-Reply-To: References: <20070407000501.957878741@reizu.com> Message-ID: heh ok ;-) On 4/7/07, Jonathan Buch wrote: > Hi, > > bug report, maybe don't send empty digests? ;) > Oh yeah, and a small typo I didn't catch until now, subject: diggest > > Jo > > On Sat, 07 Apr 2007 03:05:01 +0300, wrote: > > > > > > > > > -- > > This mail is automatically generated from the http://nitroproject.org/fora > > digest robot. It presents the discussions in the fora during the last 24 hours. > > Do not reply to this email. > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Sat Apr 7 04:23:19 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 Apr 2007 11:23:19 +0300 Subject: [Nitro] [PATCH] many to many rich association handling non saved records In-Reply-To: References: Message-ID: > This brings a age old idea from me back. It is about Og storing > meta information about itself in the database. What now hmm, this sounds interesting, let me think about it some more. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Sat Apr 7 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Sun, 8 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070408000501.A2C168704@reizu.com> >From gmosx.myopenid.com Date: Sat Apr 07 08:18:46 UTC 2007 Subject: Changes in Taggable Message-ID: http://www.nitroproject.org/fora/posts/view/cBbvma5oar24IzeJeZaaqU Dear devs, I am going to change the behaviour of Taggable. The new separator will be ',' or ';' and it will accept tags with spaces. If anyone sees any problem, let me know. -g. -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From george.moschovitis at gmail.com Sun Apr 8 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Mon, 9 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070409000501.E825C8704@reizu.com> -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From rob at robmela.com Sun Apr 8 21:25:37 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 08 Apr 2007 21:25:37 -0400 Subject: [Nitro] "Invalid Captcha" when posting patch; OgAdminController fix In-Reply-To: References: Message-ID: <46199611.5040608@robmela.com> I've tried over the past few days to save the attached patch to fora. I type my post, the attach the file, and then get "invalid captcha". Is there a captcha bug that happens only when trying to attach files to the post? Anyhow, the simple patch ( change klass.create to klass.new in OgAdminController.save in admin part ) is attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix_double_commit_in_og_controller_save Url: http://rubyforge.org/pipermail/nitro-general/attachments/20070408/1ee5c4be/attachment-0001.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070408/1ee5c4be/attachment-0001.vcf From rmela at rcn.com Sun Apr 8 21:45:36 2007 From: rmela at rcn.com (Robert Mela) Date: Sun, 08 Apr 2007 21:45:36 -0400 Subject: [Nitro] TextArea and DateTime controls Message-ID: <46199AC0.8040301@rcn.com> Two questions: 1) The DateTime control ( raw/lib/raw/view/control/attribute/datetime.rb ) is not implemented. If I'm feeling ambitious and have the time, does anyone have ideas on how they'd like to see it implemented, or are there partial implementations laying around just waiting to be finished? 2) I've specified a textarea control for one of the attributes of a model: attr_accessor :content, String, :control => :textarea How do I modify that to set row and col attributes for the textarea? And one random idea: Someone sent me a link to a utility that compiles rails apps to native UI applications: http://joyeur.com/2007/03/22/joyent-slingshot I can envision doing the same thing with Nitro. Assuming there existed a parallel set of controls that generates native UI components instead of HTML, it'd be neat if there were some global switch that could be flipped to switch between the two. -------------- next part -------------- A non-text attachment was scrubbed... Name: rmela.vcf Type: text/x-vcard Size: 160 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070408/7f750367/attachment.vcf From george.moschovitis at gmail.com Mon Apr 9 02:44:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Apr 2007 09:44:21 +0300 Subject: [Nitro] "Invalid Captcha" when posting patch; OgAdminController fix In-Reply-To: <46199611.5040608@robmela.com> References: <46199611.5040608@robmela.com> Message-ID: please, zip the patch and then send to the mailing list (the same is true for the fora). My mailer corrupts the patch if it is attached as plain text. -g. On 4/9/07, Robert Mela wrote: > I've tried over the past few days to save the attached patch to fora. > I type my post, the attach the file, and then get "invalid captcha". > > Is there a captcha bug that happens only when trying to attach files to > the post? > > Anyhow, the simple patch ( change klass.create to klass.new in > OgAdminController.save in admin part ) is attached. > > > > > New patches: > > [fix_double_commit_in_og_controller_save > rmela at rcn.com**20070409005142 > > 'Save' method in Og controller in admin part saved two records instead of one, > the first being a blank. "klass.create" instantiates an og object and > writes it to DB, in this, as invoked from 'save', no fields were populated. > The object was then returned to the 'save' method, which populated the > objects attributes, then invoked 'obj.save', thus saving a second record > to the DB ( this time populated ). > > If 'save' is to populate the record then there's no point in calling > 'klass.create'. > > ] { > hunk ./nitro/lib/nitro/part/admin/og/controller.rb 97 > - obj = klass.create > + obj = klass.new > } > > Context: > > [More fixes to make polymorphic relations work. The implementation is a piece of crap :( > George Moschovitis **20070401094904] > [Some cleanup in Og polymorphic relations, now works with :polymorphic => true (along with the old version (, Object)). Added spec. Also fixed a nasty oid on insert bug. > George Moschovitis **20070331214542] > [Fix mysql quote of nil values. > George Moschovitis **20070328111637] > [Made custom_pk.rb spec pass [jonathan]. > George Moschovitis **20070328102915] > [Fix conflict in helper > George Moschovitis **20070328101205] > [POLS when using Og::VarChar() > Jonathan Buch **20070327061024 > * add new annotation :sql_type so VarChar doesn't have to use :sql > attr_accessor :name, VarChar(20), :unique => true > works now > * added annotation :null, so NotNull also doesn't use :sql > * 3 :control => :none in Revisable > * use glycerin setup script in spec/helper.rb instead of path unshift to Og > * make join-table creation less noisy > ] > [More fixes to make general primary keys work, fixed insert bug [jonathan]. > George Moschovitis **20070327224835] > [Quote primary key in og_delete. > George Moschovitis **20070327210121] > [HelloWorld_Should_Always_Work > rmela**20050117145850] > [Handle xml/yaml/json post data, some cleanups in cgi.rb (many more to come). > George Moschovitis **20070327194110] > [More fixes to support arbitraty promary keys (and UUID in particular). > George Moschovitis **20070326114037] > [Fix and #store as #get_store aliaas. > George Moschovitis **20070326100204] > [<< helper for manager, useful for writing db change scripts. > George Moschovitis **20070326100038] > [Initial version of the UUID mixin. > George Moschovitis **20070326100003] > [Some changes to Og to prepare for UUID support. > George Moschovitis **20070326095900] > [sql.rb changes > Jonathan Buch **20070320104410 > * remove duplicated write_attrs > * made write_attr_boolean return 'f' instead of NULL > * fix require in tc_timestamped > * add :extra_condition to .find (for use with set_find_options()) > i.e. set_find_options(:extra_condition => 'time_deleted IS NULL') > * fix validate_format > ] > [Pad nice parameter in dispatcher. > George Moschovitis **20070323204529] > [Implemented CSSFormat for dynamically generated css files. Adapted output caching to make more reusable. > George Moschovitis **20070320222239] > [Moved ormsupport from facets to og/util/inflect. better organization of the og dir. > George Moschovitis **20070320094108] > [Minor fixes. > George Moschovitis **20070319190835] > [fixes: compartmentalizing fixture classes - 6/63 > Judson Lester **20070319080512] > [Fixes for new API > Judson Lester **20070318031650] > [Cleaned up sti.rb, moved into model, better interface. Moved unmanageable into model (and into Og::mixin) > George Moschovitis **20070317165215] > [Cleaned up og/model.rb a little bit. > George Moschovitis **20070317162317] > [Unified many_to_many and joins_many specs > Judson Lester **20070313234146 > Until there's a useful distinction between m2m and jm, I can't see a reason to maintain seperate spec files > ] > [Og::Exception > Judson Lester **20070313224726 > Added Og::Exception to og.rb and Og::Deleted to store. Added a spec on Model for Og::Deleted's use, and > added code to SqlStore to fulfill it. > ] > [validation: uniques really work > Judson Lester **20070314212512 > Worth noting: the sense of the block to Validation::add_validation has been reversed. It makes more sense > to me to return "true" if the validation passes. > > Also, I realize now that I have no idea what "validate_related" is supposed to do. > ] > [validation: unique nulls and numbers > Judson Lester **20070314205044] > [validation: fixed null value unique colision > Judson Lester **20070314204037 > As it was, two null values both counted as unique. As I understand it, that's wrong, in a SQL sense. > If you want that behavior, add a validate_value as well. > Also exposed by this fix: null values come back as empty strings. Correct behavior? > ] > [Minor stuff. > George Moschovitis **20070316114101] > [Misc fixes. > George Moschovitis **20070314204706] > [quote column > Guilherme Antoniolo **20070314172025] > [store: fixes 1 > Judson Lester **20070314185220] > [Converted more service formats. > George Moschovitis **20070313101306] > [Validation fix > Judson Lester **20070312224433 > Not sure how, but "Validation::add_validation" got changed to "self.class.add_validation" which is incorrect. > ] > [respect user defined :foreign_key annotation > Jonathan Buch **20070313081503] > [Fix in admin part, refactored code in 'service' formats, made more flexible. > George Moschovitis **20070312180410] > [Fixed nasty cache cleanup bug. > George Moschovitis **20070311103449] > [Cookie expires, use -rubygems in nitro and more. > George Moschovitis **20070311102657] > [Fix stupid Application error that forced the Webrick adapter. > George Moschovitis **20070310171958] > [Call redirects on POST method (+ spec) > George Moschovitis **20070310093821] > [Updated CONTRIBUTORS. > George Moschovitis **20070310080222] > [many_to_many spec > Brian Davis **20070309233521 > Added a spec outlining proper multiple many_to_many relation behavior. Currently, this spec fails and fails hard. > ] > [Fix in util/markup.rb + spec. > George Moschovitis **20070309124538] > [Minor changes to the validation patch. > George Moschovitis **20070309110137] > [spec: cleanup, add validations > Judson Lester **20070309024700] > [ New implementation of Og Validations, unfinished. > George Moschovitis **20070308164651] > [spec: merge with Og changes > Judson Lester **20070308021223] > [spec: store specifications split out > Judson Lester **20070308015556 > Interestingly enough, there are 5 failures out of 35 specs. > ] > [sql: Accounting for custom primary keys in PSQL > Judson Lester **20070306095837] > [sql: cleanup OGTABLE + specs work better > Judson Lester **20070306015638] > [sql: cleanup - OGTABLE & oids > Judson Lester **20070306012512] > [Slightly improved Validation::Errors. > George Moschovitis **20070308122857] > [Added tidy helper. It seems to fuckup some htmls though. > George Moschovitis **20070308122103] > [Simple ATOM dumper/loader. > George Moschovitis **20070308122032] > [Added temp_dir option in application, optimized updated!/touched! in Timestamped. > George Moschovitis **20070307201235] > [Improvements to the generated RDoc. > George Moschovitis **20070306150611] > [Some fixes in Og test cases. Many more are needed. > George Moschovitis **20070306114103] > [Fix in encode_uri > George Moschovitis **20070306112833] > [Cleverly use Ruby's autoload to make the code more flexible. > George Moschovitis **20070306094200] > [sql: removing psql comment > Judson Lester **20070306013102] > [sql: postgres and threadsafe oids > Judson Lester **20070306012957] > [spec: resolved some existing specs > Judson Lester **20070304071444 > Switched spec/store.rb and spec/sti_relation.rb over to isolated specifications. > As a result, discovered a couple of bugs in store.sql. > ] > [spec: Isolated specifications, silenced psql > Judson Lester **20070303085152] > [spec: adding spec-helper > Judson Lester **20070303014330 > The first of several patches to add specs to Og. Specifically trying to isolate spefications from each other, and > break them down into small chunks. > ] > [Minor. > George Moschovitis **20070305073132] > [The reloader detects element include file changes. > George Moschovitis **20070304205121] > [Misc fixes and updates. > George Moschovitis **20070304204733] > [Ensure log/.temp dirs extis, create temp files (like pids) in .temp, dont start a state server by default (made this an command line option --stateserver). Used the CookieSessionStore instead. > George Moschovitis **20070303180413] > [Much better implementation of CookieSessionStore. Sends a separate cookie for the client. > George Moschovitis **20070303170319] > [Reimplemented DrbStore. By looking to the drbstore source it is easy to convert the rest of the stores. > George Moschovitis **20070303085841] > [Fixed reloader. > George Moschovitis **20070303085305] > [Implemented hybrid JSON/Marshal CookieSessionStore, partly readable at the client (!!!!!!!). A-M-A-Z-I-N-G. > George Moschovitis **20070302222151] > [Added experimental JSONCookieSessionStore, don't use yet. > George Moschovitis **20070302140252] > [Improved new sessions implementation, re-added memory store. > George Moschovitis **20070302135407] > [Totaly reimplementation of session system. Also introduced a new cookie based session store (will be the default). > George Moschovitis **20070302114529] > [request[] accepts symbols as keys. > George Moschovitis **20070301114609] > [Misc fixes > George Moschovitis **20070301114529] > [STI Relations again > Judson Lester **20070228201315] > [Misc fixes. > George Moschovitis **20070228074617] > [Cool changes: the dispatcher mounter handles models, the old model scaffold code is now just a mixin, simplified the blog example. > George Moschovitis **20070227203420] > [Added again to og/spec dir. > George Moschovitis **20070227191037] > [Further cleaned up the directory structure of the raw ad og projects. > George Moschovitis **20070227190957] > [Misc Og stuff. > George Moschovitis **20070227111912] > [sti reference > Judson Lester **20070227103047 > References from STI child classes now point across to other entities, including other STI children. > There's two questionable lines in Relation::enchant that strike me as ugly - but the refactoring to > make them unnecessary would be quite serious for a mere aesthetic point > ] > [sti-relations: failing spec > Judson Lester **20070227020622 > Added a spec for a feature that I want: for relationships of STI children to function properly. > Moreoever, I'd like for relationships to STI children to function properly as well. Right now the > spec fails, which means I'm allowed to write some code! > ] > [More Og cleanup and fixes. > George Moschovitis **20070227110806] > [Renamed Og::Entity to Og::Model, to be more consistent with the rest of Nitro and easier for newcomers with AR / MVC experience. > George Moschovitis **20070227105616] > [with_store fixes > Judson Lester **20070226213256 > Added some explicit local variables to account for the with_store blocks. SHould write some spec for > this... Or at least update tests. > > Oh, and cleaned up some of the STI comment-outs > ] > [Some cleanups, removed more glue files. > George Moschovitis **20070226123929] > [Reimplemented Og's multithreaded strategy, should also fix the reported memory leak. [jonathan] > George Moschovitis **20070226110315] > [Misc fixes. > George Moschovitis **20070225194136] > [Created sti.rb > Judson Lester **20070224231100] > [STI Refactoring > Judson Lester **20070224230929 > Moving schema inheritance conditionals into the SchemaInheritance module > ] > [questionable-sti > Judson Lester **20070222190520] > [Converted all refs from Nitro to Raw. (Big patch ;-)) > George Moschovitis **20070225115142] > [Moved raw/lib/nitro to raw/lib/raw > George Moschovitis **20070225105824] > [Moved glue dirs to nitro/mixin and og/mixn, use Nitro::Mixin and Og::Mixin namespaces. > George Moschovitis **20070225105440] > [Use debug/info/error as shortcuts for debugger, cleaner code and allows for customization. Response keeps the output buffer, added some info text when running the console (nitro console) > George Moschovitis **20070224212830] > [Worked a bit more on the blog example. > George Moschovitis **20070224191429] > [At last, #render uses encode_uri, so does caching. The sweeper reuses the Caching code and has a better interface. POLS rules ;-) > George Moschovitis **20070224102731] > [nitro command pass over unrecognized parameters to the application. > George Moschovitis **20070224093901] > [Added simple rdoc script, minor cleanup to improve rdocs. a lot more is needed. > George Moschovitis **20070223215539] > [Fix in attr utils. > George Moschovitis **20070223195942] > [Make spec output more readable. > George Moschovitis **20070223102419] > [Rearanged some docs. > George Moschovitis **20070223101248] > [Aspects preserver arity, this fixes a nasty encode_uri bug, added encode_uri spec. > George Moschovitis **20070223100555] > [Cleaned up argument/env parsing and nitro command. Script/Console adapter works again. > George Moschovitis **20070222205615] > [state.rb use facets/daemonize. > George Moschovitis **20070222145031] > [Use application instead of server everywhere. > George Moschovitis **20070222144803] > [Worked more on aspects, still not happy with it. > George Moschovitis **20070222140104] > [Minor > George Moschovitis **20070222121517] > [Aspects apply to local methods if no target is provided, fixed some small bugs. > George Moschovitis **20070222121322] > [Added nitro specs, simple spec for aspects. Fixed nasty aspects bug, the block is instance_evaled now. > George Moschovitis **20070222113445] > [Introduced spec dir. First spec (Publishable) helps identify a faster implementation of action_methods. > George Moschovitis **20070222103352] > [Fixing postgresql > Judson Lester **20070221100539] > [Moved appserver to nitro, renamed to application. > George Moschovitis **20070221212957] > [Fix in flash. > George Moschovitis **20070221202512] > [Make aspects more flexible, fixed action_methods, improved format callbacks. > George Moschovitis **20070221172955] > [Converted the codebase to use the new safer (and more elegant, though slightly slower) aspects implementation. > George Moschovitis **20070221122616] > [Changed many "property"s to "attr_accessor"s for consistency. > George Moschovitis **20070221083245] > [Important fix in dispatcher, added RSS format. > George Moschovitis **20070220153918] > [Removed simple example. Caching check ann(:action, :cache) annotation. > George Moschovitis **20070220123112] > [Removed runner.rb, add argument parsing to server, temp solution. > George Moschovitis **20070220112630] > [More cleanup, removed some obsolete code. > George Moschovitis **20070219210048] > [Mailer works again, added MailTemplate. Needs some more cleanup though. > George Moschovitis **20070219201817] > [Some temp hack fixes. Moved mailer from glue to nitro. > George Moschovitis **20070219185629] > [Converted mongrel adapter to latest. > George Moschovitis **20070219180130] > [Refactored some more common code to adapter.rb > George Moschovitis **20070219175323] > [Separated Context from Render (at last). > George Moschovitis **20070219173055] > [Reorganized some files, cleanup. > George Moschovitis **20070219164826] > [Misc fixes and small improvements, trying to make cull.gr run again. > George Moschovitis **20070219152031] > [Mongrel adapter works again, cleaned up webrick and mongrel adapters, more to come. > George Moschovitis **20070218213433] > [New super simple output caching system and some source files reorganization. > George Moschovitis **20070218205255] > [Use ___super instead of ___control. > George Moschovitis **20070218172628] > [Minor fixes to make it run with latest facets. The source code extraction on error was buggy, so I removed it for the moment, better implementation is comming. > George Moschovitis **20070218112949] > [Some fixes to make compatible with facets 1.8.49 and daemonized support using the facets daemonized method to get rid of one more dependency. > George Moschovitis **20070218111351] > [Removed old prototype/scriptaculous helpers and morphers. > George Moschovitis **20070218101117] > [Renamed gen to raw > George Moschovitis **20070218100113] > [New implementation of source extraction from errors. > George Moschovitis **20070216213800] > [Small reloader optimisation. > George Moschovitis **20070216100510] > [Misc stuff. > George Moschovitis **20070216093053] > [Introduced new reloader: elegant, orthogonal to the dispatcher, monitors include files and just works ;-) > George Moschovitis **20070216091347] > [Organized new Nitro directory. > George Moschovitis **20070215122253] > [Introduced new nitro directory. A super-framework that integrates gen, og and facets. > George Moschovitis **20070215114034] > [Renamed nitro dir to gen. > George Moschovitis **20070215113953] > [Moved glycerin into script > George Moschovitis **20070215112139] > [Removed service.rb will be replaced by Nitro's new implicit web service capabilities. > George Moschovitis **20070215104516] > [Removed buggy squeeze filter and misc stuff. > George Moschovitis **20070215102211] > [Organized context related files in the context directory for better source code structure. > George Moschovitis **20070215092131] > [Improved format system, now defines filter_templat and before_action/after_action for extra delivery. new implementation of auto serialization to atom/json etc... under construction. > George Moschovitis **20070214182218] > [Added some more filters. > George Moschovitis **20070214165937] > [Simple example that demonstrates how Nitro can be used like php for quick and dirty web apps. > George Moschovitis **20070214163135] > [Initial test for auto json, ignore. > George Moschovitis **20070214163112] > [Set correct content_type for formats. > George Moschovitis **20070214143238] > [Reintroduced the hello world example. > George Moschovitis **20070214093958] > [Improved blog example. > George Moschovitis **20070214093938] > [Fix in aspects, and some improvemnts in the blog example. > George Moschovitis **20070214093905] > [Support action with parameters, support template override, fixes to make admin part work again. > George Moschovitis **20070213133102] > [Minor. > George Moschovitis **20070213124013] > [Moved action/template checkers to publishable, some fixes. > George Moschovitis **20070213123604] > [Minor > George Moschovitis **20070213113501] > [Change in request.path calculation, fix in dispatcher. > George Moschovitis **20070213081419] > [Minor. > George Moschovitis **20070213071906] > [Added some skin files to the new blog example. > George Moschovitis **20070213071806] > [Addded Judson's STI patch. [judson] > George Moschovitis **20070213071717] > [Added elements filter (slightly improved from old version), worked on the new blog example. > George Moschovitis **20070212230931] > [Added some more files from the new example, under construction. > George Moschovitis **20070212143319] > [Adapted proto dir. > George Moschovitis **20070212141755] > [Reimplemented / cleaned up morpher to make compatible with the new system. > George Moschovitis **20070212141116] > [Use Compiler Filters as instances (more flexible, canuse custom version of the filters). > George Moschovitis **20070212123128] > [Cleanup and Cookie helper. > George Moschovitis **20070212104536] > [Improved format, dispatcher, converted some more of the old compiler filters. > George Moschovitis **20070211200630] > [New Compiler filter architecture. > George Moschovitis **20070211172527] > [Resource Representation Formats (allow for customized handling of resources, in progress) > George Moschovitis **20070211172434] > [Added new blog example. > George Moschovitis **20070211172405] > [Big changes (in progress). Removed all old examples. Introduced brand new Compiler architecture. Clean efficient code and initiali support for REST. > George Moschovitis **20070211172242] > [Use the old hacky autoreload code in the new dispatcher. Will have to revisit this hack later. > George Moschovitis **20070210130725] > [Use consistently URI instead of URL throughout hte source code. > George Moschovitis **20070210125452] > [Misc fixes to make code work with latest changes. > George Moschovitis **20070210122747] > [Optimized cookie to_s. > George Moschovitis **20070210114028] > [Use facets/settings instead of glue/configuration. > George Moschovitis **20070209101458] > [Started refactoring the nitro adapters, initial changes in webrick/mongrel. > George Moschovitis **20070208222404] > [Renamed caching to cache. > George Moschovitis **20070208182229] > [Minor fixes. > George Moschovitis **20070208180613] > [New implementation of AppServer, do not use the crappy Runner class, improvements in Dispatcher/Router. Still under construction. > George Moschovitis **20070208111757] > [Improved dispatcher, refactored dispatcher/mounter (now the preferred way to mount controllers). > George Moschovitis **20070207185157] > [Introduced new implementation for Router, simplified. > George Moschovitis **20070206204508] > [No cross-refs between Context/Server/Dispatcher. > George Moschovitis **20070206080104] > [Enforced some consistency rules. > George Moschovitis **20070205225344] > [Added coding conventions text. > George Moschovitis **20070205205845] > [Minor. > George Moschovitis **20070205205808] > [Introduced judson's eval-less version of sql.rb/mysql.rb. Needs fix in facets/more/aspects to work [judson]. > George Moschovitis **20070205201027] > [New tc_dispatcher.rb > George Moschovitis **20070204114558] > [Removed unused emitter functionality from render. > George Moschovitis **20070204105203] > [Use consistent require paths for Facets libraries. > George Moschovitis **20070203193118] > [Minor > George Moschovitis **20070202224838] > [Introduced brand new clean and restful dispatcher. In its early stages but seems to work. Better integration to come. > George Moschovitis **20070202224313] > [Better proto dir. > George Moschovitis **20070202135708] > [Render.redirect_on_empty == true by default, nitro automatically injects redirect_to_referer when the output buffer is empty! > George Moschovitis **20070202135414] > [Improved proto dir, small fixes here and there. > George Moschovitis **20070202121359] > [missed an inspect... > Judson Lester **20070201235628] > [evald string roundup > Judson Lester **20070201234916 > All of the eval_og_ methods have been pushed up into some mixed in modules that > get included into enchanted classes. There may still be some orphaned methods etc, > but on the whole this looks a lot more manageable. > ] > [resolving repo pull > Judson Lester **20070201204635] > [Mixin_enchant_sketch > Judson Lester **20070201015234 > This is the beginnings of a change from eval'd strings for enchantment and mixins with > a smidge of dynamic code. Honestly, there's plenty of eval'd strings in Facets, which > is out of the scope of this attempt > ] > [Fix in include_as_property. > George Moschovitis **20070201222701] > [Moved attributeutils to nitro/util. > George Moschovitis **20070201180155] > [Moved autoreload to nitro/util > George Moschovitis **20070201175601] > [Removed glue/html. > George Moschovitis **20070201133616] > [More fixes to make more examples run again. > George Moschovitis **20070201113941] > [Some fixes to make more tests pass. > George Moschovitis **20070201102019] > [Use daemons 1.0.4 [pistos] > George Moschovitis **20070131123211] > [Minor. > George Moschovitis **20070131123051] > [Update to make compatible with facets 1.8.8 > George Moschovitis **20070131122951] > [Removed gen project. > George Moschovitis **20070130213755] > [Removed nitro/version.rb > George Moschovitis **20070130213303] > [Added the --create myapp option to the nitro command. > George Moschovitis **20070130212817] > [Bumped version, use >= for external dependencies in gemspec files. > George Moschovitis **20070130190409] > [Small fix in mail. > George Moschovitis **20070130133455] > [This is a BIG patch. Many many changes to make Nitro compatible with the latest version of Facets. The new annotation (and ann_attr.rb) implementation is used now. Not fully tested yet. > George Moschovitis **20070129175454] > [Made encode_url much more flexible with some shortcuts: R(User, :login) == R(User::Controller, :login), user = User[1]; R(user, :delete) == R(User::Controller, :delete, :oid, user.oid). Updated test case. > George Moschovitis **20070124235748] > [Small changes on the previous patch. > George Moschovitis **20070124174909] > [cache_pstore_v2 > lasso at lassoweb.se**20070123181625] > [Added option to include a text file in an element template, useful to reuse .xinc templates inside elements. > George Moschovitis **20070123234701] > [Show entity oids in admin screen. > George Moschovitis **20070117100117] > [Use a flag to skip sweepers (hack implementation, rethink). > George Moschovitis **20070117100049] > [Don't overwrite create_time when inserting a timestamped object. > George Moschovitis **20070115110125] > [Fix in sql indices creation. > George Moschovitis **20070114234655] > [proto fcgi.rb -> dispatch.fcgi > Fabian Buch **20070111140200 > and changed shebang to #!/usr/bin/env ruby > ] > [Minor stuff. > George Moschovitis **20070112085957] > [f.attribute appends "_ctl" to the id. label now too [Malte] > Jonathan Buch **20070111135608] > [bumped 2006 to 2007, bumped version to 0.42.0 > George Moschovitis **20070109090930] > [logger fix, print argument error when $DBG > Jonathan Buch **20070105125305 > Also adds a testcase to tc controller params, thanks Kartesus. > Since any ArgumentError triggered the 'Wrong parameter count' error, > we better use $DBG to make the old error available when developing. > ] > [Moved call/answer in separate file, slightly improved. > George Moschovitis **20070102173659] > [Removed old sanitize code + html tokenizer from glue directory. > George Moschovitis **20061231175707] > [don't override sequence in psql adapter > Jonathan Buch **20061229232529] > [Make mysql escape a little safer (investigate this). > George Moschovitis **20061231150128] > [Better rendering of checkbox control. > George Moschovitis **20061231150112] > [Set content_type / charset in outgoing emails. > George Moschovitis **20061231150048] > [Better error reporting in form attributes. > George Moschovitis **20061228174034] > [Fix in compiler. > George Moschovitis **20061228174022] > [Full error reporting in live mode. > George Moschovitis **20061228125612] > [Added create_on_insert test case. > George Moschovitis **20061228112250] > [Added option :create_on_insert in has_one relations, to automatically create the target class by default. For example: > George Moschovitis **20061228111740] > [Convienience helper in scaffold, automatically enchants all entities. > George Moschovitis **20061228111706] > [Updated TODO. > George Moschovitis **20061228111650] > [Updated html_filter. > George Moschovitis **20061227214552] > [some sti fixes, minor other stuff > Jonathan Buch **20061227161104] > [WITHOUT OIDS for psql, psql < 8.0 add oid column without that > Jonathan Buch **20061227145633] > [set force_boolean for populate_object (.assign) to true as default > Jonathan Buch **20061213110710] > [fix nasty sti bug > Jonathan Buch **20061213110312 > it wanted the 'ogtype' field always as the first field. Fix to not rely on > that. > ] > [sqlite enhancements > Jonathan Buch **20061213110215] > [Fix for sql.rb create_field map to make it even more general > Jonathan Buch **20061213105840 > also some minor enhancements in tcs > ] > [split method_missing in entity.rb > Jonathan Buch **20061209123335 > move functionality to 2 extra methods, find_by_() and find_or_create_by_() > ] > [oracle fixes, resolve_limit_options works > Jonathan Buch **20061208194811] > [sql.rb split create_table, oracle fixes > Jonathan Buch **20061208181706] > [Fix some bugs that prevernted admin to work. > George Moschovitis **20061224122801] > [Security: auto html_filter all string parameters in request.fill. Use a new whitelist based version fo html filtering. > George Moschovitis **20061224122639] > [use ',' as tags separator by defautl as well. > George Moschovitis **20061222121519] > [Dont pass resource uris to Nitro and don't try to handle Nitro uris with Webricks FileHandler. > George Moschovitis **20061220154108] > [Made the Template transformation pluggable (and not added by default at the end of the transformation pipeline. This way alternative template engines may be used. [manveru] > George Moschovitis **20061220151314] > [Moved markup.rb to util/markup.rb > George Moschovitis **20061220105332] > [Removed old, unused scaffolding code. > George Moschovitis **20061220104601] > [Moved spark and flare into example to cleanup the dir structure. > George Moschovitis **20061220101826] > [Fixed a @params bug. > George Moschovitis **20061220101632] > [Moved sanitize into nitro/utils. > George Moschovitis **20061220101609] > [Fixed admin part sitepath bug [rayman]. > George Moschovitis **20061220100514] > [support :psql again as store... it's nicer to type and doesn't break the old tutorials/configs anymore > manveru at weez-int.com**20061218160439] > [Some more fixes to make get/post params work. > George Moschovitis **20061218112234] > [Remove post/get params fix. > George Moschovitis **20061218111227] > [FeedHelper Atom with html content > Fabian Buch **20061215110619 > Atom can contain html, but only if marked as that. This patch sets > the markup type of content to be always html (doesn't hurt if non-markup > text is provided). With this change it looks much nicer in many FeedReaders. > ATTENTION: changes API: provide markuped content to FeedHelper, it makes no > sense that the FeedHelper calls the markup() method, since not everyone > uses RedCloth for his/her markup (e.g. Oxy uses BlueCloth). > ] > [Some changes to the error handling code to return correct status codes. I am not happy with this at the moment, anyone can improve this? > George Moschovitis **20061218105923] > [WebFile: use more useful controls > Fabian Buch **20061214134538] > [Fix in taggable to_s, separate to_s_safe method (move this to greek.rb ?) > George Moschovitis **20061213092136] > [TAG 0.41.0 > George Moschovitis **20061213092116] > Patch bundle hash: > a562d72a0f4953bfbeb1b7b155427fbaddfd9436 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Mon Apr 9 02:50:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Apr 2007 09:50:26 +0300 Subject: [Nitro] TextArea and DateTime controls In-Reply-To: <46199AC0.8040301@rcn.com> References: <46199AC0.8040301@rcn.com> Message-ID: > 1) The DateTime control ( raw/lib/raw/view/control/attribute/datetime.rb > ) is not implemented. If I'm feeling ambitious and have the time, does > anyone have ideas on how they'd like to see it implemented, or are there > partial implementations laying around just waiting to be finished? I would expect 3 combos (year, month, day) > 2) I've specified a textarea control for one of the attributes of a model: > > attr_accessor :content, String, :control => :textarea There must be a :style attribute or something, check out the source code, I don't remember exactly. > And one random idea: > I can envision doing the same thing with Nitro. Assuming there existed > a parallel set of controls that generates native UI components instead > of HTML, it'd be neat if there were some global switch that could be > flipped to switch between the two. this sounds nice, but it is out of my scope for the moment. If anyone wants to try this, be my guest. -g. PS: back to some rather cool nitro-jquery coding ;-) -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Mon Apr 9 03:20:24 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 09 Apr 2007 10:20:24 +0300 Subject: [Nitro] TextArea and DateTime controls In-Reply-To: <46199AC0.8040301@rcn.com> References: <46199AC0.8040301@rcn.com> Message-ID: Hi, > 1) The DateTime control ( raw/lib/raw/view/control/attribute/datetime.rb > ) is not implemented. If I'm feeling ambitious and have the time, does > anyone have ideas on how they'd like to see it implemented, or are there > partial implementations laying around just waiting to be finished? A DateTime control would be very nice (to go with a DateTime aware Og DB type). (I have implementation of that here, just not for mysql/sqlite) What I'd rather see instead of 3+ fields (year, month, day, hour, minute), .. I think it'd be nicer to have a single field... Or only 2, one date, one time. I find multi-fields more difficult to handle from the backend and less pleasent to look at.. Sidenote: George, I see you had removed the custom POST param parsing code. Was there anything wrong with it? > 2) I've specified a textarea control for one of the attributes of a model: > > attr_accessor :content, String, :control => :textarea > > How do I modify that to set row and col attributes for the textarea? You modify either per CSS, or per overriding the control. Raw::TextareaControl.style = 'width:....' Or: class Raw::TextareaControl < Raw::AttributeControl setting :rowcols, :default => nil, :doc => 'Define Rows and Cols' def render %{ #{emit_label} } end end Raw::TextareaControl.rowcols = 'cols="50" rows="10"' > And one random idea: > > Someone sent me a link to a utility that compiles rails apps to native > UI applications: > > I can envision doing the same thing with Nitro. Assuming there existed > a parallel set of controls that generates native UI components instead > of HTML, it'd be neat if there were some global switch that could be > flipped to switch between the two. Well, Nitro can deliver any type of document, you just have to modify the compiler pipeline if you don't want the templating. And you also could use the templates to generate... well, xml? for the user interface. Just the 'delivering' the the app would be the problem, if it doesn't use http then Nitro is definitly the wrong tool (right now). Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Apr 9 03:34:53 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 Apr 2007 10:34:53 +0300 Subject: [Nitro] TextArea and DateTime controls In-Reply-To: References: <46199AC0.8040301@rcn.com> Message-ID: > George, I see you had removed the custom POST param parsing code. Was there > anything wrong with it? this is temporarily removed. The openid plugin breaks with xxx.yyy parameters (it uses openid.yyy parameters and doesn't like the generated hash). When I find out a workaround I will revisit this code. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Mon Apr 9 11:18:49 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 09 Apr 2007 18:18:49 +0300 Subject: [Nitro] TextArea and DateTime controls In-Reply-To: References: <46199AC0.8040301@rcn.com> Message-ID: Hi, >> George, I see you had removed the custom POST param parsing code. Was there >> anything wrong with it? > > this is temporarily removed. The openid plugin breaks with xxx.yyy > parameters (it uses openid.yyy parameters and doesn't like the > generated hash). When I find out a workaround I will revisit this > code. I propose then not reacting on 'xxx.yy', only on 'xx[yy]'. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Mon Apr 9 20:05:02 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Tue, 10 Apr 2007 00:05:02 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070410000502.4C8248741@reizu.com> >From gmosx.myopenid.com Date: Mon Apr 09 07:11:50 UTC 2007 Subject: Facets fetch bug Message-ID: http://www.nitroproject.org/fora/posts/view/cwz6Q25MKr26i9eJeZaaqU Tom, I have posted about this before, I have the feeling that Facets override Hash#fetch() somewhere in the code to accept one parameter instead of two (and thus breaks some valid ruby code). Does that ring any bell for you? thanks, -g. >From gmosx.myopenid.com Date: Mon Apr 09 07:10:06 UTC 2007 Subject: JSON load/dump aliases Message-ID: http://www.nitroproject.org/fora/posts/view/bykvXY5MKr24IzeJeZaaqU Tom, may I suggest that you add JSON.load / JSON.dump as aliases to JSON.parse / JSON.unparse. This will make the JSON parser more consistent with the YAML parser. thanks, -g. >From jonathan-buch.de Date: Mon Apr 09 06:42:10 UTC 2007 Subject: RE: In-Reply-To: http://www.nitroproject.org/fora/posts/view/cBbvma5oar24IzeJeZaaqU Message-ID: http://www.nitroproject.org/fora/posts/view/bXrlCa5Mur26i9eJeZaaqU no problem with that here. -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From rob at robmela.com Mon Apr 9 20:52:49 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 09 Apr 2007 20:52:49 -0400 Subject: [Nitro] "Invalid Captcha" when posting patch; OgAdminController fix In-Reply-To: <46199611.5040608@robmela.com> References: <46199611.5040608@robmela.com> Message-ID: <461ADFE1.2000408@robmela.com> Trying again -- this time gzipped. Robert Mela wrote: > I've tried over the past few days to save the attached patch to > fora. I type my post, the attach the file, and then get "invalid > captcha". > > Is there a captcha bug that happens only when trying to attach files > to the post? > > Anyhow, the simple patch ( change klass.create to klass.new in > OgAdminController.save in admin part ) is attached. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_double_commit_in_og_controller_save.gz Type: application/x-gzip Size: 10640 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070409/19d8e256/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070409/19d8e256/attachment-0001.vcf From george.moschovitis at gmail.com Tue Apr 10 02:24:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 10 Apr 2007 09:24:55 +0300 Subject: [Nitro] TextArea and DateTime controls In-Reply-To: References: <46199AC0.8040301@rcn.com> Message-ID: > I propose then not reacting on 'xxx.yy', only on 'xx[yy]'. yeah, something like that will work... -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Tue Apr 10 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Wed, 11 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_diggest?= Message-ID: <20070411000501.378328741@reizu.com> -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From rob at robmela.com Tue Apr 10 21:10:11 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 10 Apr 2007 21:10:11 -0400 Subject: [Nitro] [NP.ORG] Nitro/Og Fora daily diggest In-Reply-To: <20070411000501.378328741@reizu.com> References: <20070411000501.378328741@reizu.com> Message-ID: <461C3573.5040604@robmela.com> Is anyone else getting these empty digests? I'm using Thunderbird 1.5 on a PPC Mac and all I see is the footer ( "-- This mail is automatically...."). View source shows no content. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070410/d404d6fa/attachment.vcf From john at oxyliquit.de Wed Apr 11 01:30:32 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 11 Apr 2007 08:30:32 +0300 Subject: [Nitro] [NP.ORG] Nitro/Og Fora daily diggest In-Reply-To: <461C3573.5040604@robmela.com> References: <20070411000501.378328741@reizu.com> <461C3573.5040604@robmela.com> Message-ID: Hi, > Is anyone else getting these empty digests? yes, it's just that noone wrote in the forum that day, I already reported that to G, he just didn't fix it yet. :) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Wed Apr 11 01:47:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 Apr 2007 08:47:41 +0300 Subject: [Nitro] [NP.ORG] Nitro/Og Fora daily diggest In-Reply-To: References: <20070411000501.378328741@reizu.com> <461C3573.5040604@robmela.com> Message-ID: i have fixed it, i just haven't uploaded the new version ;-) will do it later today. -g. On 4/11/07, Jonathan Buch wrote: > Hi, > > > Is anyone else getting these empty digests? > > yes, it's just that noone wrote in the forum that day, I already > reported that to G, he just didn't fix it yet. :) > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Wed Apr 11 20:05:01 2007 From: george.moschovitis at gmail.com (george.moschovitis at gmail.com) Date: Thu, 12 Apr 2007 00:05:01 +0000 (UTC) Subject: [Nitro] =?utf-8?q?=5BNP=2EORG=5D_Nitro/Og_Fora_daily_digest?= Message-ID: <20070412000501.960838741@reizu.com> >From gmosx.myopenid.com Date: Wed Apr 11 06:18:34 UTC 2007 Subject: Fixed a couple of annoying np.org bugs. Message-ID: http://www.nitroproject.org/fora/posts/view/b6bxwM5_qr25wXeJeZaaqU I (hope I) have fixed two annoying bugs that manifestated as spam: - The fora bot sending empty digest emails - The blog syndication containing invalid updated==Time.now fields let me know if you see more problems. -g. -- This mail is automatically generated from the http://nitroproject.org/fora digest robot. It presents the discussions in the fora during the last 24 hours. Do not reply to this email. From john at oxyliquit.de Thu Apr 12 10:46:20 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 12 Apr 2007 17:46:20 +0300 Subject: [Nitro] Roadmap 0.50 Message-ID: Hi devs, George and I agreed on a Roadmap to Nitro 0.50 on #irc (and I think everyone will agree to it :P) Release date: ~ 20th May (shortly after Gs marriage). Roadmap: * Convert all Unit::Tests to Specs * Make all specs go green * Release I pestered George a bit and we agreed to put all other stuff behind and make a new stable release as fast as possible, as 0.41 isn't really 'satisfactory' to some. Judson Lester: I hope you aren't yet fed up with Nitro and are still with us to help with that issue. The spec/test ratio is a little frightening right now and myself I'm not yet fully comfortable with specs. Btw, what was the reason to call use a destroying launch_og configuration? My guess is, that you feared clashes between classes. At one time I dedicated quite some time to make all tests run 'together'. This is done by using a different 'namespace' for each test. This greatly reduces the time the tests take (I loathe too long useless testing/starting times, which is why also a :classes option for Og.start exists). ## spec/store.rb context "A store" setup do module SpecStore class User Would this structure be ok to use for all specs and could the quick_setup be revised to reuse a single Og connection? I very much liked the 2 stores in the test/CONFIG.rb which were reused. Everyone, please make Nitro go green, before George gets ideas for the 'next cool feature' and delays the relase! ;) I'm willing to review any spec when you want me to. Just send me the files, new people are very much welcome to try their code-foo! :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Thu Apr 12 11:03:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 12 Apr 2007 18:03:18 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: Message-ID: > Roadmap: > > * Convert all Unit::Tests to Specs > * Make all specs go green > * Release One addition that I will handle: * Finish the new blog example. > Everyone, please make Nitro go green, before George gets ideas for the > 'next cool feature' and delays the relase! ;) no cool new features. The only thing I would like to have is get rid of Glue, but I cannot do this without Tom's help. But be assured, this will not be a showstopper. I will release Nitro even with Glue. > I'm willing to review any spec when you want me to. Just send me the > files, new people are very much welcome to try their code-foo! :) Ok, I will try to work on some specs as well. thanks, -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Thu Apr 12 11:28:17 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Thu, 12 Apr 2007 18:28:17 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: Message-ID: Hi, one further addendum: How about retaining the tc_ prefix for all specs? Or at least use spec_. Real test files and helpers are easier to spot that way. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From rob at robmela.com Thu Apr 12 21:13:39 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 12 Apr 2007 21:13:39 -0400 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: Message-ID: <461ED943.1060902@robmela.com> If glue is going to go away in future releases, will its inclusion be transparent in 0.50, such that, when it does disappear, users need not change their code? As for specs, if I run across a bug and want to make a test case for it, do I just follow the examples in "find . -name 'tc_*' " ? George Moschovitis wrote: > no cool new features. The only thing I would like to have is get rid > of Glue, but I cannot do this without Tom's help. But be assured, this > will not be a showstopper. I will release Nitro even with Glue. > >> I'm willing to review any spec when you want me to. Just send me the >> files, new people are very much welcome to try their code-foo! :) >> > > Ok, I will try to work on some specs as well. > > thanks, > -g. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070412/412c2fb8/attachment.vcf From nyarly at gmail.com Fri Apr 13 00:31:34 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 12 Apr 2007 21:31:34 -0700 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: Message-ID: <8905c87a0704122131x27f0b15aka4d39203afb6ec63@mail.gmail.com> On 4/12/07, Jonathan Buch wrote: > Judson Lester: I hope you aren't yet fed up with Nitro and are still > with us to help with that issue. The spec/test ratio is a little > frightening right now and myself I'm not yet fully comfortable with > specs. Not fed up. Just absorbed on other projects. I'm still around, and Og especially is high on my list of projects. > Btw, what was the reason to call use a destroying launch_og configuration? > My guess is, that you feared clashes between classes. At one time I > dedicated quite some time to make all tests run 'together'. This is > done by using a different 'namespace' for each test. This greatly > reduces the time the tests take (I loathe too long useless > testing/starting > times, which is why also a :classes option for Og.start exists). I was destroying the db after each test in order to make sure that each spec is independent. The classes are one thing, entries in the db are another. ## spec/store.rb > context "A store" > setup do > module SpecStore > class User > > Would this structure be ok to use for all specs Yes, this'll successfully restrict the class defs to the context they're part of. and could the quick_setup > be revised to reuse a single Og connection? Maybe, but: the real problem, IMO, is that storing stuff to a database is necessarily a stateful operation. So, if the DB isn't destroyed between specs, the specification isn't really valid, you know? One possibility that I like would be to use SQLite in memory mode, since that'd be blazing to setup and teardown - except that SQLite doesn't seem to like to drop and database unless all the connections on it are properly closed. I'm pretty sure that it could be made to work, but just swapping in SQLite with a :memory option results in a failures because the DB doesn't get dropped. If that can't be worked, maybe separate dbs could be created by threads and made available in order? That's probably a little baroque. Judson -- Q: How does a hacker escape handcuffs? A: Backslashes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070412/81cf28ec/attachment-0001.html From john at oxyliquit.de Fri Apr 13 03:16:07 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 13 Apr 2007 10:16:07 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: <8905c87a0704122131x27f0b15aka4d39203afb6ec63@mail.gmail.com> References: <8905c87a0704122131x27f0b15aka4d39203afb6ec63@mail.gmail.com> Message-ID: Hi, > Not fed up. Just absorbed on other projects. I'm still around, and Og > especially is high on my list of projects. thats good! > I was destroying the db after each test in order to make sure that each > spec is independent. The classes are one thing, entries in the db are > another. > Yes, this'll successfully restrict the class defs to the context they're > part of. > >> and could the quick_setup be revised to reuse a single Og connection? > > Maybe, but: the real problem, IMO, is that storing stuff to a database is > necessarily a stateful operation. So, if the DB isn't destroyed between > specs, the specification isn't really valid, you know? Which is why many old test cases only use one big test_ method. I agree that this goes against the principle of making tests as small as possible and only touch one 'concern'. Allright, I give up for now, lets only make specs and not complicate them further. :P > One possibility that I like would be to use SQLite in memory mode, since > that'd be blazing to setup and teardown - except that SQLite doesn't > seem to like to drop and database unless all the connections on it are > properly closed. One more thing to take care of, but also nothing which would prevent the next release... Reminds me to go look at the postgres drop db, I think there were some problems.. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Fri Apr 13 03:16:06 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 13 Apr 2007 10:16:06 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: <461ED943.1060902@robmela.com> References: <461ED943.1060902@robmela.com> Message-ID: Hi, > If glue is going to go away in future releases, will its inclusion be > transparent in 0.50, such that, when it does disappear, users need not > change their code? yes, I guess the transition will be smooth, as most of the user-visible stuff is in glue/ folders within nitro/og anyway (which I don't think will be going away anytime soon). > As for specs, if I run across a bug and want to make a test case for it, > do I just follow the examples in "find . -name 'tc_*' " ? No, have a look inside the {raw,og,...}spec/ folder. But anyway, like I said, can we prefix the specs with tc_ as well? George? Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Fri Apr 13 03:18:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Apr 2007 10:18:38 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: <461ED943.1060902@robmela.com> Message-ID: > yes, I guess the transition will be smooth, as most of the user-visible > stuff is in glue/ folders within nitro/og anyway (which I don't think > will be going away anytime soon). I have already removed these dirs. Nitro/Og related glue files are now nicely organixed in the respective dirs. However there are still some uncategorized files in the glue dir. > But anyway, like I said, can we prefix the specs with tc_ as well? George? I would like to avoid this please. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From john at oxyliquit.de Fri Apr 13 03:38:51 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 13 Apr 2007 10:38:51 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: <461ED943.1060902@robmela.com> Message-ID: Hi, >> But anyway, like I said, can we prefix the specs with tc_ as well? >> George? > > I would like to avoid this please. reason please? * `ruby spec/tc_*.rb` * `ls spec/tc_` * Is spec/helper.rb just a helper or are there specs in it? Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Fri Apr 13 04:20:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 13 Apr 2007 11:20:31 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: <461ED943.1060902@robmela.com> Message-ID: have a look at og/spec everything is a spec, except what lies in the setup dir. It is an issue of aesthetics, but we can revisit this before release. -g. On 4/13/07, Jonathan Buch wrote: > Hi, > > >> But anyway, like I said, can we prefix the specs with tc_ as well? > >> George? > > > > I would like to avoid this please. > > reason please? > > * `ruby spec/tc_*.rb` > * `ls spec/tc_` > * Is spec/helper.rb just a helper or are there specs in it? > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From lionel.orry at gmail.com Fri Apr 13 05:06:05 2007 From: lionel.orry at gmail.com (Lionel ORRY) Date: Fri, 13 Apr 2007 11:06:05 +0200 Subject: [Nitro] About syntax highlighting on np.org Message-ID: Hi everybody, and especially George. first, congratulations for the new website. (I'm a bit late, but anyway...) I noticed that you were recently more and more interested in jQuery (and for cause, it is an excellent library). And since nitroproject.org uses jQuery, I had a suggestion to make the syntax highlighting less obtrusive (no more thousands of spans in the html): a jQuery extension called Chili. Here is the link: http://www.mondotondo.com/aercolino/noteslog/?page_id=79 Have a look, it is a very interesting piece of software. I am aware that there is no support for Ruby code for now, but it would be quite easy to add (a few regexp and that's done) and would be a kind of contribution to Chili. Unfortunately I am too busy to take the initiative and implement the ruby code regexp, but I thought it was worth introducing this library. Now it's up to you. regards, Lionel From nyarly at gmail.com Fri Apr 13 18:29:55 2007 From: nyarly at gmail.com (Judson Lester) Date: Fri, 13 Apr 2007 15:29:55 -0700 Subject: [Nitro] Roadmap 0.50 In-Reply-To: References: <461ED943.1060902@robmela.com> Message-ID: <8905c87a0704131529yfb8accdj4ee7774e8fa65ae9@mail.gmail.com> Yeah - I wanted spec/helper to live at the Og root, but George didn't like that either. Judson On 4/13/07, George Moschovitis wrote: > > have a look at og/spec > > everything is a spec, except what lies in the setup dir. It is an > issue of aesthetics, but we can revisit this before release. > > -g. > > On 4/13/07, Jonathan Buch wrote: > > Hi, > > > > >> But anyway, like I said, can we prefix the specs with tc_ as well? > > >> George? > > > > > > I would like to avoid this please. > > > > reason please? > > > > * `ruby spec/tc_*.rb` > > * `ls spec/tc_` > > * Is spec/helper.rb just a helper or are there specs in it? > > > > Jo > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://georgeandstella.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- Q: How does a hacker escape handcuffs? A: Backslashes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070413/ce256158/attachment.html From john at oxyliquit.de Sat Apr 14 02:37:09 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 14 Apr 2007 09:37:09 +0300 Subject: [Nitro] Roadmap 0.50 In-Reply-To: <8905c87a0704131529yfb8accdj4ee7774e8fa65ae9@mail.gmail.com> References: <461ED943.1060902@robmela.com> <8905c87a0704131529yfb8accdj4ee7774e8fa65ae9@mail.gmail.com> Message-ID: Hi, >> have a look at og/spec >> >> everything is a spec, except what lies in the setup dir. I also did have a look at og/spec, and the spec/helper.rb was not a spec, which is why I brought it up in my list. :) >> It is an issue of aesthetics, but we can revisit this before release. With _not_ everything in spec/ being a spec, I would argue that this is not purely an issue of aesthetics but simply of more practical reasons. > Yeah - I wanted spec/helper to live at the Og root, but George didn't > like that either. Well, it imo does belong somewhere inside the spec/ folder, to wrap up all testing stuff nicely. It just has to be distinguishable what is a test and what is just simple extra code. IMO anyway. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Wed Apr 18 08:13:20 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 Apr 2007 15:13:20 +0300 Subject: [Nitro] About syntax highlighting on np.org In-Reply-To: References: Message-ID: > Unfortunately I am too busy to take the initiative and implement the > ruby code regexp, but I thought it was worth introducing this library. > Now it's up to you. Sorry for the late reply, as you may know I am getting married in a few days, so that explains the delay ;-) I will have a look at this library. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From nyarly at gmail.com Thu Apr 19 18:00:04 2007 From: nyarly at gmail.com (Judson Lester) Date: Thu, 19 Apr 2007 15:00:04 -0700 Subject: [Nitro] Module name change Message-ID: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Did I miss the email where SchemaTableInheritence became SingleTableInheritence? I mean, I much prefer the new name, but given that we already dropped the schema_inheritence method, changing the module name is kinda breaky. -- Q: How does a hacker escape handcuffs? A: Backslashes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070419/353d912c/attachment.html From george.moschovitis at gmail.com Fri Apr 20 04:08:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 Apr 2007 11:08:36 +0300 Subject: [Nitro] Module name change In-Reply-To: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> References: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Message-ID: On 4/20/07, Judson Lester wrote: > > Did I miss the email where SchemaTableInheritence became > SingleTableInheritence? I think I have announced this (probaly to the forum though) If I remember correctly it is SingleTableInherited btw... -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070420/87a614c8/attachment-0001.html From john at oxyliquit.de Fri Apr 20 04:10:55 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 20 Apr 2007 11:10:55 +0300 Subject: [Nitro] Module name change In-Reply-To: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> References: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Message-ID: Hi, > Did I miss the email where SchemaTableInheritence became > SingleTableInheritence? > > I mean, I much prefer the new name, but given that we already dropped the > schema_inheritence method, changing the module name is kinda breaky. well, if we break stuff, then we can also just 'pull through' and make the breakages as consistent as possible. :P Actually the real one is `SingleTableInherited` now. I talked with George about this on the channel, but I couldn't drive him away from that. I will try again now. class A is SingleTableInherited end class B < A end Lets look at the relation between parent and child first. `A` is not actually inherited, in the event of `B` not being around. This makes no sense in and of itself in the most cases, but it's nontheless true. `B` inherits from A, so it _inherited_ its capabilities. Does that mean that `B` is 'single table inherited'? I may be picking on something 'fluid' here, but I think, that inheritance is not a property of the parent, but only of the child. (Think .ancestors, there is no way to find child classes from the parent.) I talked with Rayman shortly about this, and he came to the same conclusion. His idea of a better name for that module: `STIParent`. I like that choice, as it's a description of what 'pattern' is used here (STI) and in which position it is in this pattern. So, George, please consider not using Inherited (even if it nicely abbriviates to STI). Thank you for listening, Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Sat Apr 21 03:31:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 21 Apr 2007 10:31:31 +0300 Subject: [Nitro] Module name change In-Reply-To: References: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Message-ID: I still think that Inherited is right in this context. But we can do the following: - rename the alias to SingleTableInheritance and provide two aliases, SingleTableInherited and SingleTableParent. counld you provide this patch? thanks, -g. On 4/20/07, Jonathan Buch wrote: > > Hi, > > > Did I miss the email where SchemaTableInheritence became > > SingleTableInheritence? > > > > I mean, I much prefer the new name, but given that we already dropped > the > > schema_inheritence method, changing the module name is kinda breaky. > > well, if we break stuff, then we can also just 'pull through' and make the > breakages as consistent as possible. :P > > Actually the real one is `SingleTableInherited` now. I talked with George > about this on the channel, but I couldn't drive him away from that. > I will try again now. > > class A > is SingleTableInherited > end > > class B < A > end > > Lets look at the relation between parent and child first. `A` is not > actually > inherited, in the event of `B` not being around. This makes no sense in > and of > itself in the most cases, but it's nontheless true. > `B` inherits from A, so it _inherited_ its capabilities. Does that mean > that > `B` is 'single table inherited'? > > I may be picking on something 'fluid' here, but I think, that inheritance > is > not a property of the parent, but only of the child. (Think .ancestors, > there > is no way to find child classes from the parent.) > > I talked with Rayman shortly about this, and he came to the same > conclusion. > His idea of a better name for that module: `STIParent`. I like that > choice, > as it's a description of what 'pattern' is used here (STI) and in which > position > it is in this pattern. > > So, George, please consider not using Inherited (even if it nicely > abbriviates > to STI). > > Thank you for listening, > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070421/1bb77146/attachment.html From george.moschovitis at gmail.com Sat Apr 21 03:32:03 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 21 Apr 2007 10:32:03 +0300 Subject: [Nitro] Module name change In-Reply-To: References: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Message-ID: > > - rename the alias rename the module i mean. -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070421/6a0cc10c/attachment.html From james.britt at gmail.com Sat Apr 21 20:26:54 2007 From: james.britt at gmail.com (James Britt) Date: Sat, 21 Apr 2007 17:26:54 -0700 Subject: [Nitro] rspec for Nitro controlers Message-ID: <462AABCE.9010706@gmail.com> I've been moving towards using rspec in my projects, and see that it's in use in the nitro/raw darcs repo. Model testing seems straightforward. Has anyone used rspec to test the controllers in their nitro apps? Thanks, -- James Britt From manveru at weez-int.com Sun Apr 22 22:41:28 2007 From: manveru at weez-int.com (Michael Fellinger) Date: Mon, 23 Apr 2007 11:41:28 +0900 Subject: [Nitro] About syntax highlighting on np.org In-Reply-To: References: Message-ID: On Fri, 13 Apr 2007 18:06:05 +0900, Lionel ORRY wrote: > Hi everybody, and especially George. > > first, congratulations for the new website. (I'm a bit late, but > anyway...) > I noticed that you were recently more and more interested in jQuery > (and for cause, it is an excellent library). And since > nitroproject.org uses jQuery, I had a suggestion to make the syntax > highlighting less obtrusive (no more thousands of spans in the html): > a jQuery extension called Chili. Here is the link: > > http://www.mondotondo.com/aercolino/noteslog/?page_id=79 > > Have a look, it is a very interesting piece of software. I am aware > that there is no support for Ruby code for now, but it would be quite > easy to add (a few regexp and that's done) and would be a kind of > contribution to Chili. > > Unfortunately I am too busy to take the initiative and implement the > ruby code regexp, but I thought it was worth introducing this library. > Now it's up to you. I hope you are aware of how difficult it is to parse and highlight Ruby :) Seems like a cool library though. > regards, > Lionel > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From john at oxyliquit.de Mon Apr 23 08:48:09 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 23 Apr 2007 15:48:09 +0300 Subject: [Nitro] Og UUIDs Message-ID: Hi, (This post is mostly for George and Lester) I've now upgraded Og (well, the last 25 outstanding patches) where Og is now UUID enabled. Now some questions. The new hook `:create_primary_key`, This behaves like `last_insert_id` for PostgreSQL used to behave. Unfortunately the new behaviour of that area isn't as 'obvious' as it used to be (to me). Could this create_primary_key be expanded to be the normal case? It would execute nextval(), save the key and then go on to: ## sql.rb def og_insert # THINK: investigate why this is needed. pk_new = store.insert(self.class, inserts) pk = pk_new unless pk George, I think this is merely the 'standard case'. When create_p_k was not executed, the .pk will always be empty and thus needs to be replaced by the oid of the actual INSERT. I'm just not sure where to put this `create_primary_key` so it only gets included into the model when the specific model is backed by psql. Where would that go to? (also so that it also can get easily be replaced by a custom create_p_k like UUID does.) Next question: Why create a special module for UUIDs? (except the reason that create_p_k has to be available). The first thing that came to my mind on how to use UUIDs: class MyModel attr_accessor :oid, UUID, :primary_key => true end And Og handling the rest via the typemap. Together with a `autoload :UUID, 'uuidtools'` somewhere in Og... Ah, and I absolutely hate the to 22 encoder, it doesn't preserve the orderability of the time-uuids. ;/ But I guess that's the price you pay for not using more bytes.. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Mon Apr 23 08:48:08 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 23 Apr 2007 15:48:08 +0300 Subject: [Nitro] Module name change In-Reply-To: References: <8905c87a0704191500h524da0bbl4349d1b102e97a01@mail.gmail.com> Message-ID: Hi, > I still think that Inherited is right in this context. But we can do the > following: > > - rename the alias to SingleTableInheritance and provide two aliases, > SingleTableInherited and SingleTableParent. > > could you provide this patch? still thinking about this. Not yet befriended with the alias approach to make everyone happy... Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Tue Apr 24 13:04:59 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 24 Apr 2007 20:04:59 +0300 Subject: [Nitro] Facets Annotations, Og startup speed Message-ID: Hi, I did some profiling of a starting Og application, this is the raw startup, table creation and ObjectSpace search shut off. Fields from left to right (see attached image): %Total | %Self | Total | Self | Children | Calls | Name This is for 41 Models, and needed 90 seconds for my little machine to start. (This is actually after my first round of optimization, it was ~23500 calls before.) (I shocked Kirk Haines with the 90 second startup, him asking if I was running a Pentium2 and having 3000 tables :P) I've gotten that down to 30 seconds now (and only a little over 5000 calls to ann()). This clearly shows that annotations are really a bottleneck for Og at that point. I haven't done any profiling running queries yet, so there might be some 'air' for improvement as well. Can we do anything to speed annotations up? Or is it just the number of times it gets called. (5000 is still huge) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -------------- next part -------------- A non-text attachment was scrubbed... Name: Bild 1.png Type: image/png Size: 21651 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070424/fdc87385/attachment-0001.png From john at oxyliquit.de Tue Apr 24 17:40:42 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 25 Apr 2007 00:40:42 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: Hi, just for the interested, by fixing up some more stuff and also going into facets, number's down to ~2200 and 16 second boot time. [00:17] allright, 2200 and only 16 seconds :) [00:20] 2200? [00:21] you remember the startup time of 90 seconds? [00:22] that was with ~23000 calls to facets [00:22] Ah. [00:22] Much better. [00:23] yes, much better :) [00:23] 16 still seems like a long time, but 90 is just plain stupid. :) [00:24] I agree, that's why I took the whole day off, profiling ;/ [00:24] like I wrote on ML, this was with just 41 Models (~ 50 tables) [00:26] Wow. Decent hardware? [00:26] old iBook :) [00:27] so not quite slow, but certainly not the fastest [00:27] but really, the 90 seconds really annoyed me then... [00:30] Kansas does the 134 table db i just tested in about a second.... ;) [00:31] figures :) [00:31] can I quote that? just to annoy George :P No, not really to annoy George, but I certainly feel to be quite the laughingstock by using Og ;) With that, good night everyone. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Tue Apr 24 17:57:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 25 Apr 2007 00:57:33 +0300 Subject: [Nitro] Og UUIDs In-Reply-To: References: Message-ID: Hi, it is a bit difficult to follow (and reply to) emails these days, but let me try... Next question: > > Why create a special module for UUIDs? (except the reason that > create_p_k has to be available). The first thing that came to my > mind on how to use UUIDs: > > class MyModel > attr_accessor :oid, UUID, :primary_key => true > end > > And Og handling the rest via the typemap. > Together with a `autoload :UUID, 'uuidtools'` somewhere in Og... One of the ideas of the new versionof Nitro/Og is to reuse standard Ruby idioms (like modules). There is an Og option that automatically includes the UUID mixin to your classes (this is what I use). But i think: class MyModel include UUIDPrimaryKey end is very readable. I could handle the notation you suggest but I don't really see the point to add this custom behaviour when the standard ruby idiom is more than enough. Ah, and I absolutely hate the to 22 encoder, it doesn't preserve > the orderability of the time-uuids. ;/ But I guess that's the > price you pay for not using more bytes.. you have a point here, but I *really* love the uuids. If someone can suggest a better encoder I would like to hear about it. -g (enjoying his last few 'free' days ;-)) -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070425/ef671bd8/attachment.html From george.moschovitis at gmail.com Tue Apr 24 18:01:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 25 Apr 2007 01:01:28 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: > > I've gotten that down to 30 seconds now (and only a little over 5000 > calls to ann()). This clearly shows that annotations are really a > bottleneck for Og at that point. I haven't done any profiling running > queries yet, so there might be some 'air' for improvement as well. > What kind of optimizations are you referring too? Should we expect a patch? ;-) I will have a look at the Og startup code next week. (but you can still remind me about that) -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070425/5b8bc4fe/attachment.html From george.moschovitis at gmail.com Tue Apr 24 18:03:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 25 Apr 2007 01:03:58 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: > > just for the interested, by fixing up some more stuff and also going > into facets, number's down to ~2200 and 16 second boot time. > what exactly have you fixed? -g. -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070425/a19c8675/attachment.html From george.moschovitis at gmail.com Tue Apr 24 18:21:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 25 Apr 2007 01:21:01 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: And if you have any idea where the excesisve calls into facets reside, let me know as well. -g. On 4/25/07, George Moschovitis wrote: > > just for the interested, by fixing up some more stuff and also going > > into facets, number's down to ~2200 and 16 second boot time. > > > > what exactly have you fixed? > > -g. > > -- > http://georgeandstella.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070425/7c219079/attachment.html From transfire at gmail.com Wed Apr 25 00:01:34 2007 From: transfire at gmail.com (transfire at gmail.com) Date: Wed, 25 Apr 2007 04:01:34 -0000 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: <1177473694.614076.186240@r3g2000prh.googlegroups.com> On Apr 24, 1:04 pm, "Jonathan Buch" wrote: > Hi, > > I did some profiling of a starting Og application, this is the raw startup, > table creation and ObjectSpace search shut off. > > Fields from left to right (see attached image): > %Total | %Self | Total | Self | Children | Calls | Name > > This is for 41 Models, and needed 90 seconds for my little machine > to start. (This is actually after my first round of optimization, it was > ~23500 calls before.) > (I shocked Kirk Haines with the 90 second startup, him asking if I was > running a Pentium2 and having 3000 tables :P) > > I've gotten that down to 30 seconds now (and only a little over 5000 > calls to ann()). This clearly shows that annotations are really a > bottleneck for Og at that point. I haven't done any profiling running > queries yet, so there might be some 'air' for improvement as well. > > Can we do anything to speed annotations up? Or is it just the number > of times it gets called. (5000 is still huge) What version of Nitro/Facets? T. From john at oxyliquit.de Wed Apr 25 02:07:41 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 25 Apr 2007 09:07:41 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: <1177473694.614076.186240@r3g2000prh.googlegroups.com> References: <1177473694.614076.186240@r3g2000prh.googlegroups.com> Message-ID: Hi, >> Can we do anything to speed annotations up? Or is it just the number >> of times it gets called. (5000 is still huge) > > What version of Nitro/Facets? A copy of facets-1.8.51 and the latest Nitro glycerin. (1.8.54 seems to be the latest version, but I had a quick glance and the annotation code didn't seem to be different.) One change I made to ann_attr.rb in facets: 86: ann(a,harg) if !harg.empty? bacause I cought attr_accessor call ann() with no hash arguments. Is this change valid, and if it is, could this go into the next facets? Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Apr 25 02:21:30 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 25 Apr 2007 09:21:30 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: Hi, >> I've gotten that down to 30 seconds now (and only a little over 5000 >> calls to ann()). This clearly shows that annotations are really a >> bottleneck for Og at that point. I haven't done any profiling running >> queries yet, so there might be some 'air' for improvement as well. >> > > What kind of optimizations are you referring too? Should we expect a > patch? ;-) Yes, we should expect a patch. :P It's just the problem that this is my works' repo and there are many other changes in it, like postgresql array types, refers_many (a has_many/refers_to hybrid with psql arrays) and other stuff I've already forgotten. > I will have a look at the Og startup code next week. (but you can still > remind me about that) A working test suite is more important at this point, as I made quite some changes the chances are good that I messed up somewhere. I would've tested it, but now with rspec and test::unit I don't know how to start the unit tests anymore and if they're still valid.. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Apr 25 04:16:45 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 25 Apr 2007 11:16:45 +0300 Subject: [Nitro] Og UUIDs In-Reply-To: References: Message-ID: Hi, > it is a bit difficult to follow (and reply to) emails these days, but > let me try... sure, concentrate on your wedding, real decisions can wait. :) > One of the ideas of the new version of Nitro/Og is to reuse standard Ruby > idioms (like modules). There is an Og option that automatically includes > the UUID mixin to your classes (this is what I use). But i think: > > class MyModel > include UUIDPrimaryKey > end > > is very readable. I could handle the notation you suggest but I don't > really see the point to add this custom behaviour when the standard > ruby idiom is more than enough. Well, but this custom behaviour is the foundation of Og, no? :) Even class MyModel attr_accessor :oid, UUID end would work, because :oid is the standard primary key. But anyway, that issue is pretty much not major. :) This is just a 'goal' for me to make Og useable without having to look up any API and make similar operations look similar. a) how do I define a different primary key? b) attr_accessor :foo, String, :primary_key => true a) how about UUID primary keys? b) oh yeah, for that it's different, you need to include... I'd also need to expand my 'by what methods you can enchant an Og model' by the option "Special Primary Key modifer modules". >> Ah, and I absolutely hate the to 22 encoder, it doesn't preserve >> the orderability of the time-uuids. ;/ But I guess that's the >> price you pay for not using more bytes.. > > you have a point here, but I *really* love the uuids. If someone can > suggest a better encoder I would like to hear about it. Actually I think the encoder is just fine, it's just that it's initialized a little 'off'. Using @@chars64=['-'] + ('0'..'9').to_a + ('A'..'Z').to_a + ['_'] + ('a'..'z').to_a instead of the stock one could do the trick. (Right now I'm not using timestamped ones, only hashed, so I kinda avoided that issue..) And of course I'm not sure how backwards compatible that change would be. From the DB side this would be ok, since none of the primary keys actually change.... can it happen that new keys conflict with old ones due to the encoding? So maybe this change should go in while 0.50 is not yet out so it doesn't break afterwards. I hope you could cope with this? Your apps are all running on that, so you'd always need to keep the old one... Or some kind of 're-encoder' for old uuids.. > -g (enjoying his last few 'free' days ;-)) Enjoy! :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Apr 25 06:15:27 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 25 Apr 2007 13:15:27 +0300 Subject: [Nitro] Facets Annotations, Og startup speed In-Reply-To: References: Message-ID: Hi, >>> just for the interested, by fixing up some more stuff and also going >>> into facets, number's down to ~2200 and 16 second boot time. >> what exactly have you fixed? > And if you have any idea where the excessive calls into facets reside, > let me know as well. the general gist is, that there are ann() calls all over the place, many of them in loops, some of them aggregating information which can be cached, then for example the :text_key annotation, but it's mostly about avoiding to call methods which call annotations. Og::Manager#enchant spawned a good part of them, serializeable_attributes is very costly, Klass.primary_key, Module#attr_callback and many more. Even now I'm not quite sure where it really spends the rest of the time in, only 16% is used for DB connection + queries. This tells me that there should be some more air to optimize, without removing needed functionality. But I'm ok for the moment with 16 seconds. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Sun Apr 29 04:16:47 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 29 Apr 2007 11:16:47 +0300 Subject: [Nitro] [PATCH] Og patches Message-ID: Hi, as promised, the speed patch. Sun Apr 29 10:40:53 EEST 2007 Jonathan Buch * Startup speed patch, removes many unnecessary calls to ann() See thread: http://rubyforge.org/pipermail/nitro-general/2007-April/007605.html 2 Buffixes Sun Apr 29 10:50:49 EEST 2007 Jonathan Buch * small fix in refers_to, wasn't saving self correctly. Sun Apr 29 10:59:56 EEST 2007 Jonathan Buch * bugfix, integer oids werent saved correctly anymore And more features. You can stay away from those for the moment. Anyone who wants to try them though, just go ahaid, they work well but should be tested. Sun Apr 29 10:19:07 EEST 2007 Jonathan Buch * small glue format validation fix This removes the nil checking from validate_format, should use validate_value for that. Also don't use .source on the regex. Sun Apr 29 10:25:57 EEST 2007 Jonathan Buch * Og StringArrays for psql + DateTime as timestamp with timezone Sun Apr 29 10:49:55 EEST 2007 Jonathan Buch * Add optional options to joins_many .count Sun Apr 29 10:52:40 EEST 2007 Jonathan Buch * Add refers_many, uses psql arrays to make a hybrid refers_to/has_many This saves the foreign keys in a psql StringArray. Using this you can avoid creating more join tables. Current restriction: it only works for string keys, so only use it with uuids or custom ones. Sun Apr 29 10:57:43 EEST 2007 Jonathan Buch * Add preliminary detection of join table classes Sun Apr 29 11:01:00 EEST 2007 Jonathan Buch * Enable custom aggregation queries This patches allows the overriding of the :select option, this is also needed for the refers_many relation. -- Feel the love http://pinkjuice.com/pics/ruby.png -------------- next part -------------- A non-text attachment was scrubbed... Name: ogstuff.bundle.tar.bz2 Type: application/bzip2 Size: 14004 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070429/8a8b775e/attachment.bin From john at oxyliquit.de Mon Apr 30 06:52:08 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 30 Apr 2007 13:52:08 +0300 Subject: [Nitro] [PATCH] make aggregations and :include work together Message-ID: Hi, Mon Apr 30 13:47:47 EEST 2007 Jonathan Buch * make aggregations and :include work together This bug prevented Klass.count(:include => ['rel']) from working. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -------------- next part -------------- A non-text attachment was scrubbed... Name: aggr_include.bundle Type: application/octet-stream Size: 39083 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070430/e906ff12/attachment-0001.obj From george.moschovitis at gmail.com Mon Apr 30 13:21:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 30 Apr 2007 20:21:27 +0300 Subject: [Nitro] [PATCH] make aggregations and :include work together In-Reply-To: References: Message-ID: Hello Jonathan, thanks for your patches. I am now married, so please allow me 1-2 days to get up to speed again ;-) ;-) -g. PS: they have some *crazy* marriage traditions in Cyprus ;-) On 4/30/07, Jonathan Buch wrote: > > Hi, > > Mon Apr 30 13:47:47 EEST 2007 Jonathan Buch > * make aggregations and :include work together > > This bug prevented Klass.count(:include => ['rel']) from working. > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://georgeandstella.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070430/0d395e32/attachment.html From brian.william.davis at gmail.com Mon Apr 30 13:27:32 2007 From: brian.william.davis at gmail.com (Brian Davis) Date: Mon, 30 Apr 2007 10:27:32 -0700 Subject: [Nitro] [PATCH] make aggregations and :include work together In-Reply-To: References: Message-ID: <20070430102732.65b50c2c@localhost.localdomain> Congratulations G! As a recent newlywed myself, let me be the first guy to tell you that marriage is much cooler than most people let on. Relax and relish the moment with your new bride. Nitro can wait (just not too long... :). Way to go, Brian P.S. I got married to a Croatian, so I didn't even understand half the ceremony (but the food and liquor were amazing). On Mon, 30 Apr 2007 20:21:27 +0300 "George Moschovitis" wrote: > Hello Jonathan, > > thanks for your patches. I am now married, so please allow me 1-2 > days to get up to speed again ;-) ;-) > > -g. > > PS: they have some *crazy* marriage traditions in Cyprus ;-) > > > On 4/30/07, Jonathan Buch wrote: > > > > Hi, > > > > Mon Apr 30 13:47:47 EEST 2007 Jonathan Buch > > * make aggregations and :include work together > > > > This bug prevented Klass.count(:include => ['rel']) from working. > > > > -- > > Using Opera's revolutionary e-mail client: > > http://www.opera.com/mail/ > > _______________________________________________ Nitro-general > > mailing list Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > From john at oxyliquit.de Mon Apr 30 14:03:09 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 30 Apr 2007 21:03:09 +0300 Subject: [Nitro] [PATCH] make aggregations and :include work together In-Reply-To: References: Message-ID: Hi, > thanks for your patches. I am now married, so please allow me 1-2 days to > get up to speed again ;-) ;-) congratulations! But of course, the patches can wait. :) > PS: they have some *crazy* marriage traditions in Cyprus ;-) Haha, I guess every nation has its quirks there. :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/