From george.moschovitis at gmail.com Sat Apr 1 03:55:56 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 11:55:56 +0300 Subject: [Nitro] Patch bundle ... we're close now In-Reply-To: <4b6f054f0603291621x725ddefdjb851fc1af4bc1741@mail.gmail.com> References: <4b6f054f0603291621x725ddefdjb851fc1af4bc1741@mail.gmail.com> Message-ID: > got testing working better and it now plays nice with nitro. (Still > need to finish the deb and release tasks though.) you mean rubyforge release task? ;-) ;-) ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:19:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:19:08 +0300 Subject: [Nitro] [PATCH] Configuration + Og startup speedup In-Reply-To: References: Message-ID: yeah it was buggy, i removed it... -g. On 3/31/06, Bryan Soto wrote: > On 3/30/06, Bryan Soto wrote: > > Just as an fyi, this make some tests fail for some reason. I'll see if > > I can fix them up before applying. > > > > You added that evil clear_all_settings method back to > Glue::Configuration again in tc_configuration. Is there a reason for > that? It causes the test cases after that to fail when you run rake > test for glue. Or perhaps the problem is actually in tc_fixture since > it fails after the settings are cleared? > > 1) Error: > test_all(TestFixture): > NoMethodError: undefined method `[]' for nil:NilClass > (eval):3:in `root_dir' > ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' > ./test/glue/tc_fixture.rb:20:in `test_all' > > 2) Error: > test_global(TestFixture): > NoMethodError: undefined method `[]' for nil:NilClass > (eval):3:in `root_dir' > ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' > ./test/glue/../../lib/glue/fixture.rb:23:in `load' > ./test/glue/../../lib/glue/fixture.rb:22:in `load' > ./test/glue/tc_fixture.rb:38:in `test_global' > > 36 tests, 160 assertions, 0 failures, 2 errors > > Also some interesting errors in og: > > D, [2006-03-30T17:48:44.984370 #19873] DEBUG -- : Og manageable classes: [TC_OgI > nheritance::Document, TC_OgInheritance::User, TC_OgInheritance::Car, TC_OgInheri > tance::Article, TC_OgInheritance::Photo, TC_OgInheritance::Admin] > I, [2006-03-30T17:48:45.145249 #19873] INFO -- : Created table 'ogtc_oginherita > nce_user'. > D, [2006-03-30T17:48:45.150689 #19873] DEBUG -- : Created jointable 'ogj_tc_ogin > heritance_car_tc_oginheritance_user'. > I, [2006-03-30T17:48:45.183862 #19873] INFO -- : Created table 'ogtc_oginherita > nce_car'. > I, [2006-03-30T17:48:45.332084 #19873] INFO -- : WARNING: Table 'ogtc_oginherit > ance_user' is missing field 'car_oid integer' and :evolve_schema is not set to t > rue! > > Then later, > > 1) Error: > test_all(TC_OgInheritance): > Mysql::Error: Unknown column 'car_oid' in 'field list' > (eval):5:in `query' > (eval):5:in `og_insert' > /mnt/zip/nitro.repo/og/lib/og/store.rb:104:in `save' > /mnt/zip/nitro.repo/og/lib/og/entity.rb:125:in `create' > ./test/og/tc_inheritance.rb:105:in `test_all' > > Also, > > 9) Error: > test_related(TestFixes): > NoMethodError: undefined method `relations' for > # > ./test/og/tc_validation2.rb:197:in `test_related' > > 10) Error: > test_value_validation(TestFixes): > NoMethodError: undefined method `store' for nil:NilClass > /mnt/zip/nitro.repo/og/lib/og/entity.rb:32:in `save' > ./test/og/tc_validation2.rb:82:in `assert_saved_without_errors' > ./test/og/tc_validation2.rb:81:in `assert_saved_without_errors' > ./test/og/tc_validation2.rb:111:in `test_value_validation' > > The above occurs seven more times for different classes defined in > this particular test case... > > 11) Error: > test_all(TestOgRevisable): > NoMethodError: undefined method `article_oid=' for > # > (eval):26:in `add_revision' > /mnt/zip/nitro.repo/og/lib/og/collection.rb:123:in `<<' > /mnt/zip/nitro.repo/og/lib/glue/revisable.rb:87:in `revise' > ./test/glue/tc_revisable.rb:24:in `test_all' > > I'll see what I can figure out... > > Bryan > > > On 3/29/06, George Moschovitis wrote: > > > Yeah, > > > > > > here is the patch, please submit it ;-) > > > > > > -g. > > > > > > On 3/27/06, Bryan Soto wrote: > > > > Hey g, > > > > > > > > You forgot the patch. :) > > > > > > > > Thanks > > > > > > > > On 3/27/06, George Moschovitis wrote: > > > > > Bryan, can you add these to the stable repo? > > > > > > > > > > thanks, > > > > > -g. > > > > > > > > > > > > > > > Mon Mar 27 21:59:51 EEST 2006 George Moschovitis > > > > > * Startup optimization, don't search in ObjectSpace for managed classes. > > > > > > > > > > Mon Mar 27 21:43:44 EEST 2006 George Moschovitis > > > > > * Further improved configuration system, even added some ruby magic, > > > > > check out the rdocs and the updated test case. > > > > > > > > > > > > > > > > > > > > -- > > > > > http://www.gmosx.com > > > > > http://www.navel.gr > > > > > http://www.nitrohq.com > > > > > > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > -- > > > > "Never tell people how to do things. Tell them what to do and they > > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > -- > > > http://www.gmosx.com > > > http://www.navel.gr > > > http://www.nitrohq.com > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:22:39 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:22:39 +0300 Subject: [Nitro] [PATCH] query by example and more Message-ID: Bryan, Here is a new patch, I hope you can integrate this. http://www.gmosx.comMon Mar 27 21:43:44 EEST 2006 George Moschovitis * Further improved configuration system, even added some ruby magic, check out the rdocs and the updated test case. Shall I send this patch? (1/5) [ynWvpxqadjk], or ? for help: y Mon Mar 27 21:59:51 EEST 2006 George Moschovitis * Startup optimization, don't search in ObjectSpace for managed classes. Shall I send this patch? (2/5) [ynWvpxqadjk], or ? for help: y Thu Mar 30 10:40:23 EEST 2006 George Moschovitis * Removed og startup optimization, doesnt work. Shall I send this patch? (3/5) [ynWvpxqadjk], or ? for help: y Thu Mar 30 12:11:55 EEST 2006 George Moschovitis * Added query_by_example support in Og and the auto admin interface, minor improvements in form helper. Shall I send this patch? (4/5) [ynWvpxqadjk], or ? for help: y Thu Mar 30 13:05:18 EEST 2006 George Moschovitis * Bumped version number to 0.30.0 Shall I send this patch? (5/5) [ynWvpxqadjk], or ? for help: y -- http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:24:39 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:24:39 +0300 Subject: [Nitro] [PATCH] query by example and more In-Reply-To: References: Message-ID: I forgot the attachment, here you are, -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tgz Type: application/x-gzip Size: 16214 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060401/f7131176/attachment.tgz From george.moschovitis at gmail.com Sat Apr 1 04:26:06 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:26:06 +0300 Subject: [Nitro] About the new Control system In-Reply-To: References: <200603021258.39943.zimba.tm@gmail.com> <200603031850.10543.zimba.tm@gmail.com> <200603041527.09635.zimba.tm@gmail.com> <4E9828BE-2D68-4592-809D-8035039CEB77@ntecs.de> Message-ID: thanks for reminding, i will add this ;-) -g. On 3/31/06, Bryan Soto wrote: > Hi George, > > Did you ever uncover anything on this? :) > > On 3/5/06, George Moschovitis wrote: > > > > > > Maybe > > > > > > "#{var :target}" > > > > > > > *Interesting* idea! let me investigate this... > > > > thanks, > > -g. > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:27:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:27:37 +0300 Subject: [Nitro] Hiding a column from Og? In-Reply-To: References: Message-ID: This isnt possible at the moment, but it would be trivial to add. But I too am curious why you need this feature ;-) -g. On 3/31/06, Bryan Soto wrote: > On 3/29/06, Kashia Buch wrote: > > Hi, > > > > how do I create a column in a database which is not noticed by Og? > > > > I want to add an additional column to a table, and want to avoid Og messing with it or even noticing it, is that possible? > > > > http://oxyliquit.de/question/23 > > Kashia, could you explain a liitle on why you need this? Perhaps it > would help people get a feel for whether something like this should be > added. > > Or perhaps someone already has an idea on this? Or even an opinion on > whether this is a bug or a feature? > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:31:52 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:31:52 +0300 Subject: [Nitro] Admin improvements In-Reply-To: References: <200603061558.10912.zimba.tm@gmail.com> Message-ID: BTW, my latest patch adds advanced searc capability to the admin interface using Og's new query_by_example feature ;-) -g. On 3/31/06, Bryan Soto wrote: > Hi everyone, > > Any ideas here we should add to devlab as enhancements or that anyone > would like to work on? > > On 3/6/06, zimba.tm wrote: > > Hi list, > > > > the next thing I would to work on, is to improve the admin. Before I go on, > > here are the ideas I would like to implement : > > > > = Make settings changeable and storable > > > > * Use the caching system or Og to load/save settings > > * Make the settings modifiable in the web interface > > * Group the settings in different pages, according to their namespace to > > avoid a huge page > > > > = Use rubygems for components > > > > I don't know if it will be straignforward. > > > > * Use a nitro-specific settings for rubygems (store location, download > > location, ...) > > * Make rubygems (un)installable/uploadable from the web interface > > * Add the ability to instanciate components on specific web paths > > * Upgrade Og so that it supports table installing/upgrading on the fly > > (without relaunching nitro) > > > > = Standalone nitro > > > > Make a nitro executable that will launch nitro with the admin and custom > > options > > > > = Editable > > > > * Make sources and templates editable from the web interface > > > > -- > > Cheers, > > zimba.tm > > > > weblog : http://zimba.oree.ch > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 1 04:43:53 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Apr 2006 12:43:53 +0300 Subject: [Nitro] Discussion about setting relationships with unsaved objects In-Reply-To: References: <1140603804.28264.43.camel@robs-p4> <1140613941.2916.0.camel@robs-p4> Message-ID: Open the ticket please. -g. On 3/31/06, Bryan Soto wrote: > Did this one ever get resolved? If not, we should open a ticket. > > Thanks. > > Bryan > > On 2/22/06, Rob Pitt wrote: > > That's a better idea - OK I'll just patch my project to throw Exceptions > > until this is done. > > > > On Wed, 2006-02-22 at 14:14 +0200, George Moschovitis wrote: > > > Please don't make this change yet.I would like to add a 'build' mode > > > in collections. > > > Ie, You create an object, assign the relations and save in one go. > > > Will add this during next week, so be patient. > > > > > > -g. > > > > > > > > > On 2/22/06, Rob Pitt wrote: > > > > Currently in Og if you try and assign has many or joins many > > > > relationships to an unsaved object, the object is silently saved in the > > > > background (this is needed to make the relationship work), but if you do > > > > the same with refers_to/belongs_to/has_one, this does not happen, > > > > instead Og proceeds as if everything is fine essentially ignoring your > > > > request (and losing the relationship). > > > > > > > > I think all of these behaviours are wrong because you may not expect > > > > your object to have been saved in the has_many/joins_many case and you > > > > will not know why your code mysteriously breaks in the belongs_to case > > > > (this actually bit me while writing a unit test the other day and it > > > > took me a good five minutes to work out what was wrong). > > > > > > > > I believe that all of these cases should throw and exception as you > > > > should not be trying to assign relationships to unsaved objects, but > > > > before I make this happen I want to confirm with the list you agree this > > > > is the appropriate course of action. This way informs you that your code > > > > is broken and if you did want automatic saving all you'd need to do is: > > > > > > > > begin > > > > obj.relation = remote > > > > rescue UnsavedException > > > > obj.save! > > > > remote.save! > > > > retry > > > > end > > > > > > > > Of course, this is pretty silly since you should be doing: > > > > > > > > remote.save! > > > > obj.relation = remote > > > > obj.save! > > > > > > > > In your code anyway. > > > > > > > > At the very least, the refers_to/has_one/belongs_to relationships should > > > > have the same behaviour as the other relationships, be that auto-saving > > > > as they currently do, or as I believe, throwing exceptions. > > > > > > > > Comments? > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > -- > > > http://www.gmosx.com > > > http://www.navel.gr > > > http://www.nitrohq.com > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Sat Apr 1 05:47:54 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sat, 01 Apr 2006 12:47:54 +0200 Subject: [Nitro] Bounty: doap for Nitro Message-ID: Hi, just found the following in the ruby-talk ML. http://ruby.codezoo.com/pub/component/5261 That are 12! users which might have used Nitro if it wasn't so uberly outdated ;) So, even if that site probably isn't searched much, we could make it a bit less outdated which could probably attract at least some users, by committing a doap file there about Nitro. So, what I'd like you to do: make a Nitro::Controller with doap output, which I can then just plug into Oxyliquit. Then I (or someone else) can publish that Information to codezoo. Bounty pay: credits on Oxywtf "about" page for your work :) (If thats ok ;)) Documentation: [1] http://ruby.codezoo.com/about/doap_over_atom.csp [2] http://usefulinc.com/doap/ Thank you very much for listening, Kashia Snip, doap explanation from codezoo --------- CodeZoo spiders many sites to try to keep up to date on new releases and information about the components we list. Unfortunately, many sites use different formats to describe their projects, and those formats change over time; and sometimes the site from which we get information is not up to date itself. As a result, we don't always have the latest information, and we want it! To address this, CodeZoo has adopted an XML format called DOAP, which stands for ?Description of a Project.? This format was started by Edd Dumbill, and more information about it can be found at http://usefulinc.com/doap/. Using this format, component authors can describe their projects in a machine-readable format that the CodeZoo crawler can easily understand. A DOAP file describes a single release of a component. In order to track new releases as they come out, with Edd's advice, we've developed a DOAP-over-Atom format that provides a DOAP feed of releases. Information about the DOAP-over-Atom format is available here. Our hope is that component authors (and others) will adopt DOAP-over-Atom, so that all sites that list components can easily keep up to date on new releases of components, as well as component descriptions, authors, licenses, and other information. If you would like to make sure CodeZoo (and other sites) have the latest information about your work, please publish a DOAP-over-Atom feed, and enter the URL for your feed below. Thanks, and thanks for all of your work contributing to open source. -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sat Apr 1 05:56:52 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sat, 01 Apr 2006 12:56:52 +0200 Subject: [Nitro] Hiding a column from Og? In-Reply-To: References: Message-ID: Hi, > This isnt possible at the moment, but it would be trivial to add. But > I too am curious why you need this feature ;-) >> Kashia, could you explain a liitle on why you need this? Perhaps it >> would help people get a feel for whether something like this should be >> added. For both: I'm sure the current approach with :cautious set to 'true' is sufficient for everything. My usecase: I want to use TSearch2 in PostgreSQL to make the search in Oxyliquit even more effective. TSearch2 requires an additional field in the table (of type vector) and I don't want Og do mess with it :) Searching _should_ be one of the big features in Oxy (as it grows bigger) since the main pages are very limited with only 5-15 elements on it. Maybe I can get around that issue by using extra tables for just that column, but that seems kinda awkward to me. .... *think* >> Or perhaps someone already has an idea on this? Or even an opinion on >> whether this is a bug or a feature? A feature, not a bug :) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From news at stephan.walter.name Sat Apr 1 06:09:38 2006 From: news at stephan.walter.name (Stephan Walter) Date: Sat, 01 Apr 2006 13:09:38 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted Message-ID: Hi I started writing a new system for translating both models and views, similar to "Globalize" from RoR. Currently only model translations are supported, and it's not optimised at all. Also you have to enter the languages manually :-/ svn co http://84.16.238.99/svn/babel/ In your model you write: require 'babel/babel.rb' class Whisper property :text, String translate :text end in the controller you set the base language: Babel::Locale.set_base_language("en") and in your template: #{@whisper.text} which will automatically get the german translation (if there is no translation, you'll get it in the base language). The same goes for assigning values: Babel::Locale.set("fr") @whisper.text = "Bonjour" I plan to write a translator for views (perhaps this could be in the transformer pipeline?) Any suggestions or corrections are welcome! Also, I ran into a few problems: 1. I have two classes for storing the translations, which inherit from the same class: class Translation class ModelTranslation < Translation class ViewTranslation < Translation How do I prevent Og from making a db table for Translation? 2. as I am automagically translating the fields into the selected language, this interferes with the admin interface (i.e. the admin interface doesn't show the actual contents of the database, but the translations in the base language). Is there a simple way to distinguish if the admin interface or the normal web app is accessing the data? -Stephan From kashia at vfemail.net Sat Apr 1 06:26:47 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sat, 01 Apr 2006 13:26:47 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: Hi, [snip sweeet :D~ ] > 1. I have two classes for storing the translations, which inherit from the > same class: > > class Translation > class ModelTranslation < Translation > class ViewTranslation < Translation > > How do I prevent Og from making a db table for Translation? class Translation is Og::SchemaInheritanceBase end this now only creates the "ogtranslation" table, with an additional column called "type". Everything else works as expected. > 2. as I am automagically translating the fields into the selected > language, this interferes with the admin interface (i.e. the admin > interface doesn't show the actual contents of the database, but the > translations in the base language). Is there a simple way to distinguish > if the admin interface or the normal web app is accessing the data? Someone else has to answer this. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From news at stephan.walter.name Sat Apr 1 09:20:42 2006 From: news at stephan.walter.name (Stephan Walter) Date: Sat, 01 Apr 2006 16:20:42 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted References: Message-ID: Hi, On Sat, 01 Apr 2006 13:26:47 +0200, Kashia Buch wrote: >> How do I prevent Og from making a db table for Translation? > > class Translation > is Og::SchemaInheritanceBase > end > > this now only creates the "ogtranslation" table, with an additional column > called "type". Thanks a lot! However Og seems to have problems evolving the schema (evolve_schema_cautious is set to false): DEBUG -- : Field mismatch in 'ogbabel_translation'. Attempting to correct... WARN -- : Removing obsolete fields 'pluralization, tablename, item, fieldname, key' from 'ogbabel_translation'! ERROR -- : Og.setup had problems: SQLite3::SQLException => table ogbabel_translation_backup has 9 columns but 3 values were supplied When I set evolve_schema to false after that, it starts without errors. Why does Og want to remove the fields of the child classes? When accessing the translations, I get the following error: ERROR -- : undefined method `result' for # /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:1062:in `read_one' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:464:in `find_one' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:207:in `find_one' 1057: res_row = res.next 1058: 1059: # causes STI classes to come back as the correct child class 1060: # if accessed from the superclass. 1061: 1062: klass = Og::Entity::entity_from_string(res_row.result.flatten[res_row.fieldnum('ogtype')]) if klass.schema_inheritance? 1063: obj = klass.og_allocate(res_row, 0) 1064: 1065: if options and options[:select] 1066: read_row(obj, res, res_row, 0) 1067: else Am I doing something wrong, or is Og having trouble with SchemaInheritanceBase? -Stephan From aurelianocalvo at yahoo.com.ar Sat Apr 1 09:49:54 2006 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Sat, 1 Apr 2006 11:49:54 -0300 (ART) Subject: [Nitro] Newbie question Message-ID: <20060401144954.42111.qmail@web50406.mail.yahoo.com> Hi! I'm trying to do my first OG model. The source code is below: require 'og' database = Og.setup( :name => 'test_og', :store => :sqlite ) $DBG = true class Movement property :cash, Fixnum property :description, String end m = Movement.new m.cash = 5 m.description = "Sarasa" m.save When I run it, the following error ocurrs: I, [2006-04-01T11:44:54.893000 #3840] INFO -- : Og uses the Sqlite store. C:/ruby/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:477:in `method_missing': undefined method `ogmanager' for Movement:Class (NoMethodError) from C:/ruby/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' from C:/Documents and Settings/Aure/workspace/test_og/populate.rb:21 I've installed og using gems: > gem install og --include-dependencies Attempting local installation of 'og' Local gem file not found: og*.gem Attempting remote installation of 'og' Updating Gem source index for: http://gems.rubyforge.org Successfully installed og-0.29.0 Successfully installed glue-0.29.0 Successfully installed facets-1.0.3 Installing RDoc documentation for og-0.29.0... Installing RDoc documentation for glue-0.29.0... I'm running Ruby 1.8.2. under Windows XP using sqlite3 as the back-store. I've already connected to a sqlite3 database (i.e. a file) from non OG ruby code usign sqlite3-ruby. Can you tell me how can I correct my first try on OG? Thanks in advance, Aureliano. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar From transfire at gmail.com Sat Apr 1 13:07:52 2006 From: transfire at gmail.com (TRANS) Date: Sat, 1 Apr 2006 13:07:52 -0500 Subject: [Nitro] Newbie question In-Reply-To: <20060401144954.42111.qmail@web50406.mail.yahoo.com> References: <20060401144954.42111.qmail@web50406.mail.yahoo.com> Message-ID: <4b6f054f0604011007x2e9e44efq8bcd11ec80a4c94b@mail.gmail.com> Is the sqlite store the one for sqlite3? What about the sqlite2 store? T. From aurelianocalvo at yahoo.com.ar Sat Apr 1 13:40:55 2006 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Sat, 1 Apr 2006 15:40:55 -0300 (ART) Subject: [Nitro] Newbie question In-Reply-To: <4b6f054f0604011007x2e9e44efq8bcd11ec80a4c94b@mail.gmail.com> Message-ID: <20060401184055.51393.qmail@web50404.mail.yahoo.com> I've tried, same error. The sqlite file does not exist prior to this run, is this a problem? (I've understood from the tutorial at http://oxyliquit.de/tutorial/1 that is not required). > Is the sqlite store the one for sqlite3? What about > the sqlite2 store? > > T. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar From transfire at gmail.com Sat Apr 1 14:08:41 2006 From: transfire at gmail.com (TRANS) Date: Sat, 1 Apr 2006 14:08:41 -0500 Subject: [Nitro] Newbie question In-Reply-To: <20060401184055.51393.qmail@web50404.mail.yahoo.com> References: <4b6f054f0604011007x2e9e44efq8bcd11ec80a4c94b@mail.gmail.com> <20060401184055.51393.qmail@web50404.mail.yahoo.com> Message-ID: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> Think I figured it out. From a mail post in Feb: >From mneumann at ntecs.de Tue Feb 7 11:55:09 2006 From: mneumann at ntecs.de (Michael Neumann) Date: Tue, 7 Feb 2006 17:55:09 +0100 Subject: [Nitro] (no subject) In-Reply-To: <1139327464.17039.17.camel at robs-p4> References: <6a7d49ca0602070728x33160199u at mail.gmail.com> <1139327464.17039.17.camel at robs-p4> Message-ID: <69F90338-B824-4E66-8DF9-EBCC5ACC1686 at ntecs.de> Sorry, I found my error. I didn't noticed that the Og managed classes must be defined before calling Og.setup. Now everything (hopefully) works. Regards, Michael Am 07.02.2006 um 16:51 schrieb Rob Pitt: > Before calling Nitro.run do: > > Og.thread_safe = false if ENV['NITRO_INVOKE'] == 'fcgi_proc' > > On Tue, 2006-02-07 at 16:28 +0100, guillaume pierronnet wrote: >> yes, i have the same problem and i am investigating. Webrick and SCGI >> works for me but not fastcgi on apache. >> >> >> 2006/2/7, Michael Neumann : >>> Hi all, >>> >>> I wanted to try out the newest nitro/og version, but it doesn't >>> work. >>> I always get og/lib/og/entity.rb:434:in `method_missing': undefined >>> local variable or method 'ogmanager' for User:Class. >>> >>> The ogmanger method seems to be no more defined for managed classes. >>> >>> The latest Nitro/Og looks *very* promising. >>> >>> Regards, >>> >>> Michael From Aleksi.Niemela at cs.helsinki.fi Sat Apr 1 15:38:24 2006 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Sat, 01 Apr 2006 23:38:24 +0300 Subject: [Nitro] properties In-Reply-To: References: Message-ID: <442EE4C0.4080801@cs.helsinki.fi> Bryan Soto kirjoitti: > Perhaps the problem is that properties are generic, but not reusable. > As an example, for an Og enchanted class, perhaps field and fields > would be a better name than property and properties. > > I'm not sure if I have the same idea with Bryan but IMO instead of having static Domain Specific Language (DSL) we could end up having dynamically defined DSL for declaring properties, attributes or whatever would be great name for those. So by default Og would use "property" but Gtk users could say Og.dsl_keywords(:property => :my_own_foobar_keyword) class Foo # in which context #property would collide my_own_foobar_keyword :foo, String end - Aleksi From kashia at vfemail.net Sat Apr 1 17:14:23 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 02 Apr 2006 00:14:23 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: Hi, > ERROR -- : Og.setup had problems: SQLite3::SQLException => table ogbabel_translation_backup has 9 columns but 3 values were supplied hmm... I must admit I never tried this with sqlite though it actually should work without errors. different approach: module Translation property .... end class ViewTranslation include Translation # ... end This will avoid the ogtranslation table, and will only create the two other tables. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From aurelianocalvo at yahoo.com.ar Sat Apr 1 17:19:59 2006 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Sat, 1 Apr 2006 22:19:59 +0000 (GMT) Subject: [Nitro] Newbie question In-Reply-To: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> Message-ID: <20060401221959.91410.qmail@web50412.mail.yahoo.com> Thanks, I've tried to move the Og.setup after the enchanted class and it worked. Is it posible to modify Og to handle enchanted classes generated before and after the call of Og.setup? Thanks again, Aureliano. > Think I figured it out. From a mail post in Feb: > > >From mneumann at ntecs.de Tue Feb 7 11:55:09 2006 > From: mneumann at ntecs.de (Michael Neumann) > Date: Tue, 7 Feb 2006 17:55:09 +0100 > Subject: [Nitro] (no subject) > In-Reply-To: <1139327464.17039.17.camel at robs-p4> > References: > > <6a7d49ca0602070728x33160199u at mail.gmail.com> > <1139327464.17039.17.camel at robs-p4> > Message-ID: > <69F90338-B824-4E66-8DF9-EBCC5ACC1686 at ntecs.de> > > Sorry, I found my error. I didn't noticed that the > Og managed classes > must be defined before calling Og.setup. > Now everything (hopefully) works. > > Regards, > > Michael > > Am 07.02.2006 um 16:51 schrieb Rob Pitt: > > Before calling Nitro.run do: > > > > Og.thread_safe = false if ENV['NITRO_INVOKE'] == > 'fcgi_proc' > > > > On Tue, 2006-02-07 at 16:28 +0100, guillaume > pierronnet wrote: > >> yes, i have the same problem and i am > investigating. Webrick and SCGI > >> works for me but not fastcgi on apache. > >> > >> > >> 2006/2/7, Michael Neumann : > >>> Hi all, > >>> > >>> I wanted to try out the newest nitro/og version, > but it doesn't > >>> work. > >>> I always get og/lib/og/entity.rb:434:in > `method_missing': undefined > >>> local variable or method 'ogmanager' for > User:Class. > >>> > >>> The ogmanger method seems to be no more defined > for managed classes. > >>> > >>> The latest Nitro/Og looks *very* promising. > >>> > >>> Regards, > >>> > >>> Michael > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar From dylanb at digitalvalence.com Sat Apr 1 18:56:52 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Sat, 01 Apr 2006 17:56:52 -0600 Subject: [Nitro] nitro wiki/doc Message-ID: <442F1344.4050008@digitalvalence.com> Hi all, How do I get access to edit the Nitro wiki ? I applied an edit to one of the og pages and didn't seem to do anything. Is there an approval process or something ? Dylan From transfire at gmail.com Sat Apr 1 19:04:07 2006 From: transfire at gmail.com (TRANS) Date: Sat, 1 Apr 2006 19:04:07 -0500 Subject: [Nitro] Reap Release Message-ID: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> trans at upixie:~/Files/my/code/RUBY/reap$ reap release (in /cab/Home/trans/Files/my/code/RUBY/reap) Reap is preparing release ... Password for transami: ********** Added release -- 4.3.3 Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.tar.bz2 Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.gem Release complete! T. PS No, it's not an April Fools Joke :) From transfire at gmail.com Sat Apr 1 19:08:18 2006 From: transfire at gmail.com (TRANS) Date: Sat, 1 Apr 2006 19:08:18 -0500 Subject: [Nitro] Newbie question In-Reply-To: <20060401221959.91410.qmail@web50412.mail.yahoo.com> References: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> <20060401221959.91410.qmail@web50412.mail.yahoo.com> Message-ID: <4b6f054f0604011608q8c1139eg627715a7ec73eb70@mail.gmail.com> On 4/1/06, Aureliano Calvo wrote: > Thanks, > I've tried to move the Og.setup after the enchanted > class and it worked. > > Is it posible to modify Og to handle enchanted classes > generated before and after the call of Og.setup? Well, that's a good question. I say it is good that ability is quite indicative of what Og's future should be. T. From transfire at gmail.com Sat Apr 1 19:09:38 2006 From: transfire at gmail.com (TRANS) Date: Sat, 1 Apr 2006 19:09:38 -0500 Subject: [Nitro] nitro wiki/doc In-Reply-To: <442F1344.4050008@digitalvalence.com> References: <442F1344.4050008@digitalvalence.com> Message-ID: <4b6f054f0604011609o536af0a4y3db41069a68ba2fb@mail.gmail.com> On 4/1/06, Dylan Bruzenak wrote: > Hi all, > > How do I get access to edit the Nitro wiki ? I applied an edit to one > of the og pages and didn't seem to do anything. Is there an approval > process or something ? I beleive editing is broke. I don;t know why. And George is very busy with his Army duties so hasn't had the time to fix it :( Who else has access to work on it? What is the problem exactly? T. From dylanb at digitalvalence.com Sat Apr 1 20:12:24 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Sat, 01 Apr 2006 19:12:24 -0600 Subject: [Nitro] nitro wiki/doc In-Reply-To: <4b6f054f0604011609o536af0a4y3db41069a68ba2fb@mail.gmail.com> References: <442F1344.4050008@digitalvalence.com> <4b6f054f0604011609o536af0a4y3db41069a68ba2fb@mail.gmail.com> Message-ID: <442F24F8.1090807@digitalvalence.com> The edit button pulls up the correct screen, and after changing and hitting submit the original view screen displays without the changes. They are just lost. > On 4/1/06, Dylan Bruzenak wrote: > >> Hi all, >> >> How do I get access to edit the Nitro wiki ? I applied an edit to one >> of the og pages and didn't seem to do anything. Is there an approval >> process or something ? >> > > I beleive editing is broke. I don;t know why. And George is very busy > with his Army duties so hasn't had the time to fix it :( > > Who else has access to work on it? What is the problem exactly? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From m.fellinger at gmail.com Sun Apr 2 00:02:40 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sun, 2 Apr 2006 14:02:40 +0900 Subject: [Nitro] nitro wiki/doc In-Reply-To: <442F24F8.1090807@digitalvalence.com> References: <442F1344.4050008@digitalvalence.com> <4b6f054f0604011609o536af0a4y3db41069a68ba2fb@mail.gmail.com> <442F24F8.1090807@digitalvalence.com> Message-ID: <9c00d3e00604012102i13c6ebc0t8d12e36a57dd0974@mail.gmail.com> not lost, the caching has some problem, the text is stored in thedatabase but the cached pages are not invalidated (deleted) whichmeans that you always view the static file...I think i might just parse that stuff some day and fill it into a newspark or maybe to devlab - zimba, you listen? :) On 4/2/06, Dylan Bruzenak wrote:> The edit button pulls up the correct screen, and after changing and> hitting submit the original view screen displays without the changes.> They are just lost.> > On 4/1/06, Dylan Bruzenak wrote:> >> >> Hi all,> >>> >> How do I get access to edit the Nitro wiki ? I applied an edit to one> >> of the og pages and didn't seem to do anything. Is there an approval> >> process or something ?> >>> >> > I beleive editing is broke. I don;t know why. And George is very busy> > with his Army duties so hasn't had the time to fix it :(> >> > Who else has access to work on it? What is the problem exactly?> >> > T.> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From bryan.a.soto at gmail.com Sun Apr 2 01:52:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 1 Apr 2006 22:52:21 -0800 Subject: [Nitro] Newbie question In-Reply-To: <20060401221959.91410.qmail@web50412.mail.yahoo.com> References: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> <20060401221959.91410.qmail@web50412.mail.yahoo.com> Message-ID: On 4/1/06, Aureliano Calvo wrote: > Thanks, > I've tried to move the Og.setup after the enchanted > class and it worked. > > Is it posible to modify Og to handle enchanted classes > generated before and after the call of Og.setup? > > Thanks again, > Aureliano. > That depends on what you mean. :) Og.setup returns an Og::Manager object that you can then call manage_classes on: manager = Og.setup # define classes here manager.manage_classes If you mean something like, your classes get enchanted lazily when needed, that's kind of an interesting thought. You mean some kind of notification scheme? One problem I could see is it wouldn't work in context of multiple stores. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 01:52:54 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 1 Apr 2006 22:52:54 -0800 Subject: [Nitro] Newbie question In-Reply-To: <4b6f054f0604011608q8c1139eg627715a7ec73eb70@mail.gmail.com> References: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> <20060401221959.91410.qmail@web50412.mail.yahoo.com> <4b6f054f0604011608q8c1139eg627715a7ec73eb70@mail.gmail.com> Message-ID: On 4/1/06, TRANS wrote: > On 4/1/06, Aureliano Calvo wrote: > > Thanks, > > I've tried to move the Og.setup after the enchanted > > class and it worked. > > > > Is it posible to modify Og to handle enchanted classes > > generated before and after the call of Og.setup? > > Well, that's a good question. I say it is good that ability is quite > indicative of what Og's future should be. > I'm not quite sure what you mean... Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 01:55:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 1 Apr 2006 22:55:07 -0800 Subject: [Nitro] Reap Release In-Reply-To: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> References: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> Message-ID: Congrats on a long requested feature. :) On 4/1/06, TRANS wrote: > trans at upixie:~/Files/my/code/RUBY/reap$ reap release > (in /cab/Home/trans/Files/my/code/RUBY/reap) > Reap is preparing release ... > Password for transami: ********** > Added release -- 4.3.3 > Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.tar.bz2 > Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.gem > Release complete! > > T. > > > PS No, it's not an April Fools Joke :) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 03:16:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 1 Apr 2006 23:16:35 -0800 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: On 4/1/06, Stephan Walter wrote: > Thanks a lot! However Og seems to have problems evolving the schema > (evolve_schema_cautious is set to false): > > DEBUG -- : Field mismatch in 'ogbabel_translation'. Attempting to correct... > WARN -- : Removing obsolete fields 'pluralization, tablename, item, fieldname, key' from 'ogbabel_translation'! > ERROR -- : Og.setup had problems: SQLite3::SQLException => table ogbabel_translation_backup has 9 columns but 3 values were supplied > > When I set evolve_schema to false after that, it starts without errors. > Why does Og want to remove the fields of the child classes? > > When accessing the translations, I get the following error: > > ERROR -- : undefined method `result' for # > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:1062:in `read_one' > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:464:in `find_one' > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:207:in `find_one' > > 1057: res_row = res.next > 1058: > 1059: # causes STI classes to come back as the correct child class > 1060: # if accessed from the superclass. > 1061: > 1062: klass = Og::Entity::entity_from_string(res_row.result.flatten[res_row.fieldnum('ogtype')]) if klass.schema_inheritance? > 1063: obj = klass.og_allocate(res_row, 0) > 1064: > 1065: if options and options[:select] > 1066: read_row(obj, res, res_row, 0) > 1067: else > > Am I doing something wrong, or is Og having trouble with > SchemaInheritanceBase? > Good catch. It's a bug in the Sqlite3 store. Thanks for reporting. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 03:58:11 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 1 Apr 2006 23:58:11 -0800 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: On 4/1/06, Stephan Walter wrote: > Hi > > I started writing a new system for translating both models and views, > similar to "Globalize" from RoR. Currently only model translations are > supported, and it's not optimised at all. Also you have to enter the > languages manually :-/ > transformer pipeline?) Any suggestions or corrections are welcome! > First off, that's pretty cool. I'm looking forward to seeing where this goes. :) > 2. as I am automagically translating the fields into the selected > language, this interferes with the admin interface (i.e. the admin > interface doesn't show the actual contents of the database, but the > translations in the base language). Is there a simple way to distinguish > if the admin interface or the normal web app is accessing the data? > In the model you mean? Not really I think. Other than going through the call stack. Perhaps a new setting like 'raw' could be made that didn't do any translation? Then you could do something like class AdminController # The controller mounted by part/admin on /admin Babel::Locale.set_base_language("raw") end Not sure if this will work. I've pulled your code, but haven't had time to look it over. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 04:05:37 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 00:05:37 -0800 Subject: [Nitro] properties In-Reply-To: <442EE4C0.4080801@cs.helsinki.fi> References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: On 4/1/06, Aleksi Niemela wrote: > Bryan Soto kirjoitti: > > Perhaps the problem is that properties are generic, but not reusable. > > As an example, for an Og enchanted class, perhaps field and fields > > would be a better name than property and properties. > > > > > I'm not sure if I have the same idea with Bryan but IMO instead of > having static Domain Specific Language (DSL) we could end up having > dynamically defined DSL for declaring properties, attributes or whatever > would be great name for those. > > So by default Og would use "property" but Gtk users could say > > Og.dsl_keywords(:property => :my_own_foobar_keyword) > class Foo # in which context #property would collide > my_own_foobar_keyword :foo, String > end > That's pretty much it. In addition though, all the Og and Glue internal code would use my_own_foobar_keywords to access all the declared my_own_foobar_keyword items. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 04:10:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 00:10:58 -0800 Subject: [Nitro] Discussion about setting relationships with unsaved objects In-Reply-To: References: <1140603804.28264.43.camel@robs-p4> <1140613941.2916.0.camel@robs-p4> Message-ID: On 4/1/06, George Moschovitis wrote: > Open the ticket please. > > -g. Okay. http://devlab.oree.ch/trac/nitrohq/ticket/28 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 04:22:20 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 00:22:20 -0800 Subject: [Nitro] Bounty: doap for Nitro In-Reply-To: References: Message-ID: On 4/1/06, Kashia Buch wrote: > So, what I'd like you to do: make a Nitro::Controller with doap > output, which I can then just plug into Oxyliquit. > Then I (or someone else) can publish that Information to codezoo. > That's a good idea. :) I've been stuck on how to get all the recent info. Perhaps this is a job for reap? ;) From george.moschovitis at gmail.com Sun Apr 2 05:23:40 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 2 Apr 2006 12:23:40 +0300 Subject: [Nitro] properties In-Reply-To: <442EE4C0.4080801@cs.helsinki.fi> References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: > So by default Og would use "property" but Gtk users could say > > Og.dsl_keywords(:property => :my_own_foobar_keyword) > class Foo # in which context #property would collide > my_own_foobar_keyword :foo, String > end naah, this is too much... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 2 05:24:42 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 2 Apr 2006 12:24:42 +0300 Subject: [Nitro] Hiding a column from Og? In-Reply-To: References: Message-ID: > Maybe I can get around that issue by using extra tables for just that > column, but that seems kinda awkward to me. .... *think* ok, will add an option. -g. PS: btw, what is TSearch2 ? -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 2 05:25:45 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 2 Apr 2006 12:25:45 +0300 Subject: [Nitro] Reap Release In-Reply-To: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> References: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> Message-ID: You RULE ;-) Now can you help with updating Nitro/Og ProjectInfo's ;-) -g. On 4/2/06, TRANS wrote: > trans at upixie:~/Files/my/code/RUBY/reap$ reap release > (in /cab/Home/trans/Files/my/code/RUBY/reap) > Reap is preparing release ... > Password for transami: ********** > Added release -- 4.3.3 > Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.tar.bz2 > Added file -- ../DISTRIBUTION/reap-4.3.3/reap-4.3.3.gem > Release complete! > > T. > > > PS No, it's not an April Fools Joke :) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Sun Apr 2 08:00:05 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 02 Apr 2006 14:00:05 +0200 Subject: [Nitro] Hiding a column from Og? In-Reply-To: References: Message-ID: Hi, > ok, will add an option. nice, thanks :) > PS: btw, what is TSearch2 ? TSearch2 is for PostgreSQL. It creates searchable indexes, it is very fast and it has a built in querying language like Ferret. (good comparison btw). It also has the ability to weight the results and mark the searched word in the result. I'll use it for searching in Oxyliquit, search is important and has to be done right :) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From news at stephan.walter.name Sun Apr 2 08:39:21 2006 From: news at stephan.walter.name (Stephan Walter) Date: Sun, 02 Apr 2006 14:39:21 +0200 Subject: [Nitro] [FIX] find_or_create_by with relations Message-ID: Hi, Og currently has a problem with find_or_create_by_* if the object has relations. The find will execute correctly, but when no object is found, the creation of the new object will not include the relations. Made-up example: class A property :name belongs_to :b, B end class B end A.find_or_create_by_name_and_b("foo", @b) This will result in the correct SELECT statement: SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 If no object is found, the following INSERT statement will be wrong, the b_oid should not be NULL: INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However I am not sure if the patch does the right thing, and I have not tested it a lot. It'd be great if someone could look into this. -Stephan From news at stephan.walter.name Sun Apr 2 08:40:12 2006 From: news at stephan.walter.name (Stephan Walter) Date: Sun, 02 Apr 2006 14:40:12 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted References: Message-ID: On Sat, 01 Apr 2006 23:58:11 -0800, Bryan Soto wrote: > On 4/1/06, Stephan Walter wrote: >> 2. as I am automagically translating the fields into the selected >> language, this interferes with the admin interface (i.e. the admin >> interface doesn't show the actual contents of the database, but the >> translations in the base language). Is there a simple way to distinguish >> if the admin interface or the normal web app is accessing the data? >> >> > In the model you mean? Not really I think. Other than going through the > call stack. > > Perhaps a new setting like 'raw' could be made that didn't do any > translation? Then you could do something like > > class AdminController # The controller mounted by part/admin on /admin > Babel::Locale.set_base_language("raw") > end Uh sorry, I was confused. Of course the contents of the model is per definition in the base language. The problem is that Locale.set is global for the application, and setting a language in the AdminController only works until somewhere else you define a different Locale. From then on all the content will be in that language, which was my goal, but that isn't what I want for the admin interface. -Stephan From transfire at gmail.com Sun Apr 2 09:05:17 2006 From: transfire at gmail.com (TRANS) Date: Sun, 2 Apr 2006 09:05:17 -0400 Subject: [Nitro] Reap Release In-Reply-To: References: <4b6f054f0604011604j62eeb185g9f4d54845c4f4b90@mail.gmail.com> Message-ID: <4b6f054f0604020605n1fbcd1cfp987211dd90fda62a@mail.gmail.com> On 4/2/06, George Moschovitis wrote: > You RULE ;-) > Now can you help with updating Nitro/Og ProjectInfo's ;-) Easy peasy. RELEASE: host : rubyforge.org username : gmosx project : nitro groupid : 418 package : nitro dir : '../dist' I still need to do something about a template for release names --I use just the version, but others use package-version format. T. From transfire at gmail.com Sun Apr 2 09:28:04 2006 From: transfire at gmail.com (TRANS) Date: Sun, 2 Apr 2006 09:28:04 -0400 Subject: [Nitro] Newbie question In-Reply-To: References: <4b6f054f0604011108m6969e9cdq6dce7f8dd693e48d@mail.gmail.com> <20060401221959.91410.qmail@web50412.mail.yahoo.com> <4b6f054f0604011608q8c1139eg627715a7ec73eb70@mail.gmail.com> Message-ID: <4b6f054f0604020628i3f99932dk55b255773c2b68e7@mail.gmail.com> On 4/2/06, Bryan Soto wrote: > On 4/1/06, TRANS wrote: > > On 4/1/06, Aureliano Calvo wrote: > > > Thanks, > > > I've tried to move the Og.setup after the enchanted > > > class and it worked. > > > > > > Is it posible to modify Og to handle enchanted classes > > > generated before and after the call of Og.setup? > > > > Well, that's a good question. I say it is good that ability is quite > > indicative of what Og's future should be. > > > > I'm not quite sure what you mean... Well, why does it have to be one or the other? When certain Og related commands are called on an object, shouldn't it just lookup the relevant DB conneciton then? Why would I have to declare it in relation to the enchanted classes? Although you are right, if one's using multiple stores, the classes will need particular persistance settings. But the idea is a layer of passivity --activity only comes when needed. But I think that's just a sort of a guide for the future at this point --no need to go back and do a major overhall, just chip away at it over time, keeping this in mind. T. From transfire at gmail.com Sun Apr 2 09:56:10 2006 From: transfire at gmail.com (TRANS) Date: Sun, 2 Apr 2006 09:56:10 -0400 Subject: [Nitro] Bounty: doap for Nitro In-Reply-To: References: Message-ID: <4b6f054f0604020656j780f1b47j234a9760c7013172@mail.gmail.com> On 4/2/06, Bryan Soto wrote: > On 4/1/06, Kashia Buch wrote: > > So, what I'd like you to do: make a Nitro::Controller with doap > > output, which I can then just plug into Oxyliquit. > > Then I (or someone else) can publish that Information to codezoo. > > > > That's a good idea. :) > > I've been stuck on how to get all the recent info. Perhaps this is a > job for reap? ;) Well, it's easy enough for reap to generate the doap Project section. It will take a little more consideration to deal with Version sections --not sure yet how to approach this. One thing to know is that they don't seem to support Darcs. The Repository section is specific to CVS, SVN, Arch or BitKeeper. Anyone want to jump on their case about it? ;-) T. From aurelianocalvo at yahoo.com.ar Sun Apr 2 11:02:49 2006 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Sun, 2 Apr 2006 12:02:49 -0300 (ART) Subject: [Nitro] Newbie question In-Reply-To: Message-ID: <20060402150249.13953.qmail@web50410.mail.yahoo.com> > If you mean something like, your classes get > enchanted lazily when > needed, that's kind of an interesting thought. You > mean some kind of > notification scheme? One problem I could see is it > wouldn't work in > context of multiple stores. I believe that most of the projects have a single store. So the simple case should be to have one store only. I'm a OG newbie, so I really don't know the specifics of how this can be implemented in OG, even if it can be or not. But this schema might be posible: 1. Clases are automatically enchanted with the latest store set up (the latest datastore configured via Og.setup) if they have to (i.e. have OG properties declared on them). 2. If there are no datastore, clases are enchanted on the first OG.setup (just like right now). 3. There is a mechanism to manually relate classes with stores (to solve the tricky situations where points 1. and 2. would not work). Do you think them to be good ideas? Thanks for your time, Aureliano. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! ?Abr? tu cuenta ya! - http://correo.yahoo.com.ar From george.moschovitis at gmail.com Sun Apr 2 11:53:40 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 2 Apr 2006 17:53:40 +0200 Subject: [Nitro] [FIX] find_or_create_by with relations In-Reply-To: References: Message-ID: Thanks, i will review this shortly. -g. On 4/2/06, Stephan Walter wrote: > Hi, > > Og currently has a problem with find_or_create_by_* if the object has > relations. The find will execute correctly, but when no object is found, > the creation of the new object will not include the relations. > > Made-up example: > > class A > property :name > belongs_to :b, B > end > > class B > end > > A.find_or_create_by_name_and_b("foo", @b) > > This will result in the correct SELECT statement: > > SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 > > If no object is found, the following INSERT statement will be wrong, the > b_oid should not be NULL: > > INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) > > The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However > I am not sure if the patch does the right thing, and I have not tested it > a lot. It'd be great if someone could look into this. > > -Stephan > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Sun Apr 2 12:53:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 09:53:46 -0700 Subject: [Nitro] [FIX] find_or_create_by with relations In-Reply-To: References: Message-ID: Thanks for the patch Walter. I've created a ticket on devlab so we wouldn't lose track of this. http://devlab.oree.ch/trac/nitrohq/ticket/29 Bryan On 4/2/06, George Moschovitis wrote: > Thanks, i will review this shortly. > > -g. > > On 4/2/06, Stephan Walter wrote: > > Hi, > > > > Og currently has a problem with find_or_create_by_* if the object has > > relations. The find will execute correctly, but when no object is found, > > the creation of the new object will not include the relations. > > > > Made-up example: > > > > class A > > property :name > > belongs_to :b, B > > end > > > > class B > > end > > > > A.find_or_create_by_name_and_b("foo", @b) > > > > This will result in the correct SELECT statement: > > > > SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 > > > > If no object is found, the following INSERT statement will be wrong, the > > b_oid should not be NULL: > > > > INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) > > > > The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However > > I am not sure if the patch does the right thing, and I have not tested it > > a lot. It'd be great if someone could look into this. > > > > -Stephan > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 2 12:54:33 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 09:54:33 -0700 Subject: [Nitro] [FIX] find_or_create_by with relations In-Reply-To: References: Message-ID: I'm sorry. Thanks for the patch Stephan. :) On 4/2/06, Bryan Soto wrote: > Thanks for the patch Walter. I've created a ticket on devlab so we > wouldn't lose track of this. > > http://devlab.oree.ch/trac/nitrohq/ticket/29 > > Bryan > > On 4/2/06, George Moschovitis wrote: > > Thanks, i will review this shortly. > > > > -g. > > > > On 4/2/06, Stephan Walter wrote: > > > Hi, > > > > > > Og currently has a problem with find_or_create_by_* if the object has > > > relations. The find will execute correctly, but when no object is found, > > > the creation of the new object will not include the relations. > > > > > > Made-up example: > > > > > > class A > > > property :name > > > belongs_to :b, B > > > end > > > > > > class B > > > end > > > > > > A.find_or_create_by_name_and_b("foo", @b) > > > > > > This will result in the correct SELECT statement: > > > > > > SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 > > > > > > If no object is found, the following INSERT statement will be wrong, the > > > b_oid should not be NULL: > > > > > > INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) > > > > > > The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However > > > I am not sure if the patch does the right thing, and I have not tested it > > > a lot. It'd be great if someone could look into this. > > > > > > -Stephan > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From kashia at vfemail.net Sun Apr 2 13:05:42 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 02 Apr 2006 19:05:42 +0200 Subject: [Nitro] New (old) Tutorials on Oxyliquit Message-ID: Hi, for everyone who hasn't read "Nitro In Flames" or "Its All Greek To Me", with the permission of both the authors I copied both tutorials to Oxyliquit. News from Oxy: * tutorials can be called with their titles: http://oxyliquit.de/tutorial/Nitro+In+Flames * Tutorial: Nitro In Flames (manveru) * Tutorial: Nitro and Og, It's all Greek to me (eerieshadow) I contacted the CodeRay creator (thats the tool which makes the nice code highlighting :D) and he will implement html/xml/rhtml so expect even nicer code hightlighting in the near future :D Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Sun Apr 2 13:21:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 10:21:09 -0700 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: On 4/2/06, George Moschovitis wrote: > > So by default Og would use "property" but Gtk users could say > > > > Og.dsl_keywords(:property => :my_own_foobar_keyword) > > class Foo # in which context #property would collide > > my_own_foobar_keyword :foo, String > > end > > > naah, this is too much... > Just a thought. So we're back to the previous discussion of tracking down a good name. First, the exact problem is that every property defined in an Og model is stored in a hash that is accessed by using the name "properties". So strewn throughout the Glue and Og code are numerous calls to properties. Properties is also used by GTK to access the internal properties of a GLib object, so we are both using the same name and, depending on the order of require, one is replacing the other causing no end of headaches. The collision is that both Og and GTK are using "properties" internally. This is what's been suggested so far: graph_properties class_properties facet_properties facets Any other suggestions? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Sun Apr 2 13:35:55 2006 From: transfire at gmail.com (TRANS) Date: Sun, 2 Apr 2006 13:35:55 -0400 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: <4b6f054f0604021035vb02ce2fq55256c2027e9d926@mail.gmail.com> On 4/2/06, Bryan Soto wrote: > Just a thought. So we're back to the previous discussion of tracking > down a good name. > > First, the exact problem is that every property defined in an Og model > is stored in a hash that is accessed by using the name "properties". > So strewn throughout the Glue and Og code are numerous calls to > properties. Properties is also used by GTK to access the internal > properties of a GLib object, so we are both using the same name and, > depending on the order of require, one is replacing the other causing > no end of headaches. The collision is that both Og and GTK are using > "properties" internally. > > This is what's been suggested so far: > graph_properties > class_properties > facet_properties > facets > > Any other suggestions? I'm starting to lean toward the idea that was suggested earlier. Why do we just use modified forms of the attr_ methods? As long as their backward compatible, what does it really matter? T. From transfire at gmail.com Sun Apr 2 13:39:18 2006 From: transfire at gmail.com (TRANS) Date: Sun, 2 Apr 2006 13:39:18 -0400 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604021035vb02ce2fq55256c2027e9d926@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604021035vb02ce2fq55256c2027e9d926@mail.gmail.com> Message-ID: <4b6f054f0604021039g1d077f24oc78b3683ffcb1602@mail.gmail.com> BTW has anyone aske dthe GTK people to change their method's name? T. From bryan.a.soto at gmail.com Mon Apr 3 01:25:32 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 2 Apr 2006 22:25:32 -0700 Subject: [Nitro] [PATCH] query by example and more In-Reply-To: References: Message-ID: On 4/1/06, George Moschovitis wrote: > I forgot the attachment, here you are, > Hey George, I've applied to devlab. I still have that same question on the configuration patch. I copied and pasted from my previous email below. You added that evil clear_all_settings method back to Glue::Configuration again in tc_configuration. Is there a reason for that? It causes the test cases after that to fail when you run rake test for glue. Or perhaps the problem is actually in tc_fixture since it fails after the settings are cleared? 1) Error: test_all(TestFixture): NoMethodError: undefined method `[]' for nil:NilClass (eval):3:in `root_dir' ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' ./test/glue/tc_fixture.rb:20:in `test_all' 2) Error: test_global(TestFixture): NoMethodError: undefined method `[]' for nil:NilClass (eval):3:in `root_dir' ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' ./test/glue/../../lib/glue/fixture.rb:23:in `load' ./test/glue/../../lib/glue/fixture.rb:22:in `load' ./test/glue/tc_fixture.rb:38:in `test_global' 36 tests, 160 assertions, 0 failures, 2 errors -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From reid.thompson at ateb.com Mon Apr 3 11:43:05 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Mon, 03 Apr 2006 11:43:05 -0400 Subject: [Nitro] How do I use create_constraints Message-ID: <44314289.9070408@ateb.com> Provided I have an Og managed class: class Dbfile property :filename, String belongs_to :dbdir, Dbdirectory end How do I use create_constraints to create a unique constraint for (filename, dbdir)? From vseguip at gmail.com Mon Apr 3 11:47:04 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Mon, 3 Apr 2006 17:47:04 +0200 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: On 4/2/06, Bryan Soto wrote: > On 4/2/06, George Moschovitis wrote: > > > So by default Og would use "property" but Gtk users could say > > > > > > Og.dsl_keywords(:property => :my_own_foobar_keyword) > > > class Foo # in which context #property would collide > > > my_own_foobar_keyword :foo, String > > > end > > > > > > naah, this is too much... > > > > Just a thought. So we're back to the previous discussion of tracking > down a good name. > > First, the exact problem is that every property defined in an Og model > is stored in a hash that is accessed by using the name "properties". > So strewn throughout the Glue and Og code are numerous calls to > properties. Properties is also used by GTK to access the internal > properties of a GLib object, so we are both using the same name and, > depending on the order of require, one is replacing the other causing > no end of headaches. The collision is that both Og and GTK are using > "properties" internally. > > This is what's been suggested so far: > graph_properties > class_properties > facet_properties > facets > > Any other suggestions? > Maybe "properties_hash" "properties_table" "h_properties" Cheers, V. Segu? From transfire at gmail.com Mon Apr 3 13:31:59 2006 From: transfire at gmail.com (TRANS) Date: Mon, 3 Apr 2006 13:31:59 -0400 Subject: [Nitro] CascadingOpenObject Message-ID: <4b6f054f0604031031h5c5d520g2174b927a2cef1f9@mail.gmail.com> new class for facets. It the same as openobject but when a hash is the resulting lookup value it gets converted to another "CascadingOpenObject". Anyone got a better name? (code below) Btw I also added an interesting feature to both OpenObject and this new class. If @parent is set then a value not found in the current object will be searched for in the parent. This allows for inherited values. class CascadingOpenObject < OpenObject def method_missing( sym, *args ) type = sym.to_s[-1,1] name = sym.to_s.gsub(/[=!?]$/, '').to_sym if type == '=' @table[name] = args[0] elsif type == '!' and args.size > 0 @table[name] = args[0] self else if @table.key?(name) if Hash === @table[name] self.__class__.new( @table[name] ) else @table[name] end elsif @parent @parent.__send__(name) else nil # Kernel.null #@table[name] = instance.class.new end end end end From kashia at vfemail.net Mon Apr 3 15:38:18 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 03 Apr 2006 21:38:18 +0200 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: Hi, my comment on the whole issue: >> naah, this is too much... > Just a thought. So we're back to the previous discussion of tracking > down a good name. Like George once said, when that topic came up one day with Mechanize: Nitro does not have to work with every single library in existance. My proposition: If "property" can't be used, is "prop" still free? ;) If we take another name now.. how long does it take until the history repeats itself and some other library generates a conflict? Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Mon Apr 3 15:47:58 2006 From: transfire at gmail.com (TRANS) Date: Mon, 3 Apr 2006 15:47:58 -0400 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> On 4/3/06, Kashia Buch wrote: > Hi, > > my comment on the whole issue: > > >> naah, this is too much... > > Just a thought. So we're back to the previous discussion of tracking > > down a good name. > > Like George once said, when that topic came up one day with Mechanize: > Nitro does not have to work with every single library in existance. > > My proposition: > > If "property" can't be used, is "prop" still free? ;) > > If we take another name now.. how long does it take until the history > repeats itself and some other library generates a conflict? Ah.. another reason modified but backward compatible #attr methods are a safe bet. T. From bryan.a.soto at gmail.com Mon Apr 3 16:47:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 13:47:56 -0700 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> Message-ID: On 4/3/06, Kashia Buch wrote: > Hi, > > my comment on the whole issue: > > >> naah, this is too much... > > Just a thought. So we're back to the previous discussion of tracking > > down a good name. > > Like George once said, when that topic came up one day with Mechanize: > Nitro does not have to work with every single library in existance. > > My proposition: > > If "property" can't be used, is "prop" still free? ;) > Well, for the record, I don't believe "property" is the problem. It's that each "property" is stored and accessed via "properties" and that's where the collision is. > If we take another name now.. how long does it take until the history > repeats itself and some other library generates a conflict? > That's true. If this was for Nitro, we probably wouldn't be having this discussion. I think Og is supposed to be a general library and that's the only reason renaming is being entertained. I don't know that for sure though. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 3 16:56:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 13:56:07 -0700 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> Message-ID: On 4/3/06, TRANS wrote: > Ah.. another reason modified but backward compatible #attr methods are > a safe bet. > Yes, the Ruby community is very open to modifying core methods, don't you think? ;) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 3 16:58:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 13:58:00 -0700 Subject: [Nitro] How do I use create_constraints In-Reply-To: <44314289.9070408@ateb.com> References: <44314289.9070408@ateb.com> Message-ID: On 4/3/06, Reid Thompson wrote: > Provided I have an Og managed class: > > class Dbfile > property :filename, String > belongs_to :dbdir, Dbdirectory > end > > How do I use create_constraints to create a unique constraint for > (filename, dbdir)? > I think that if you use the postgres store that they are created automatically. I don't believe the other stores do, though I suppose Mysql could now. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 3 17:11:24 2006 From: transfire at gmail.com (TRANS) Date: Mon, 3 Apr 2006 17:11:24 -0400 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> Message-ID: <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> On 4/3/06, Bryan Soto wrote: > On 4/3/06, TRANS wrote: > > Ah.. another reason modified but backward compatible #attr methods are > > a safe bet. > > > > Yes, the Ruby community is very open to modifying core methods, don't > you think? ;) If it's "backward compatible" what's the difference? I don't really mind either way, I'm just saying. T. From kashia at vfemail.net Mon Apr 3 17:47:37 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 03 Apr 2006 23:47:37 +0200 Subject: [Nitro] How do I use create_constraints In-Reply-To: References: <44314289.9070408@ateb.com> Message-ID: Hi, >> class Dbfile >> property :filename, String >> belongs_to :dbdir, Dbdirectory >> end Single constraints like unique: class Dbfile property :filename, String, :unique => true # .. etc end >> How do I use create_constraints to create a unique constraint for >> (filename, dbdir)? I don't know about general constraint creation... But, keep in mind that you should handle errors as well: class Dbfile # props etc validate_unique :filename validate_unique :dbdir # maybe something like that too? validate_format :filename, :format => /[^\/]+/ end In controller: def create_dbfile(blabla) obj = Dbfile.new('asdf.pdf', Dbdirectory[1]) if obj.valid? obj.save! end # else do something end > I think that if you use the postgres store that they are created > automatically. I don't believe the other stores do, though I suppose > Mysql could now. Postgres for sure... not sure about mysql.. Hope that helps, Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Mon Apr 3 17:56:01 2006 From: kashia at vfemail.net (Kashia Buch) Date: Mon, 03 Apr 2006 23:56:01 +0200 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> Message-ID: Hi, > Ah.. another reason modified but backward compatible #attr methods are > a safe bet. I'm against that actually, since it enables me to just make a few attributes persistant, while I just want accessors for others. The options I see with attr, would be to redefine it ( attr :sym, String) or add more stuff (attr :sym; ann ......), which I both don't like very much. So I'm still for staying where we are :P Kashia PS: BSoto: I've read both your messages above about the "Self-join :trough =>" issue, I just can't seem to answer somehow, I pushed it further down the stack of "to do" items, I hope you can forgive me. -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Mon Apr 3 18:21:04 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 15:21:04 -0700 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> Message-ID: On 4/3/06, TRANS wrote: > On 4/3/06, Bryan Soto wrote: > > On 4/3/06, TRANS wrote: > > > Ah.. another reason modified but backward compatible #attr methods are > > > a safe bet. > > > > > > > Yes, the Ruby community is very open to modifying core methods, don't > > you think? ;) > > If it's "backward compatible" what's the difference? > > I don't really mind either way, I'm just saying. > It was just a joke. :) I was just trying to imagine what certain denizens of the mailing list would have had to say about that suggestion. ;) Seriously though, in the context of this thread, you'd still have the original problem of how do you access them with a name that's not properties. Besides, if we go that route, I'd prefer we just annotate. Hmm... That's a thought. Why not just store the properties as annotations? The prop_* methods and property could just be interfaces to the annotation system. I wonder if that would work... > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 3 18:23:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 15:23:07 -0700 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> Message-ID: On 4/3/06, Bryan Soto wrote: > It was just a joke. :) I was just trying to imagine what certain > denizens of the mailing list would have had to say about that The ruby-talk mailing list. > suggestion. ;) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 3 20:17:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 17:17:26 -0700 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: On 4/2/06, Bryan Soto wrote: > On 4/1/06, Stephan Walter wrote: > > Thanks a lot! However Og seems to have problems evolving the schema > > (evolve_schema_cautious is set to false): > > > > DEBUG -- : Field mismatch in 'ogbabel_translation'. Attempting to correct... > > WARN -- : Removing obsolete fields 'pluralization, tablename, item, fieldname, key' from 'ogbabel_translation'! > > ERROR -- : Og.setup had problems: SQLite3::SQLException => table ogbabel_translation_backup has 9 columns but 3 values were supplied > > > > When I set evolve_schema to false after that, it starts without errors. > > Why does Og want to remove the fields of the child classes? > > > > When accessing the translations, I get the following error: > > > > ERROR -- : undefined method `result' for # > > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:1062:in `read_one' > > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:464:in `find_one' > > /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:207:in `find_one' > > > > 1057: res_row = res.next > > 1058: > > 1059: # causes STI classes to come back as the correct child class > > 1060: # if accessed from the superclass. > > 1061: > > 1062: klass = Og::Entity::entity_from_string(res_row.result.flatten[res_row.fieldnum('ogtype')]) if klass.schema_inheritance? > > 1063: obj = klass.og_allocate(res_row, 0) > > 1064: > > 1065: if options and options[:select] > > 1066: read_row(obj, res, res_row, 0) > > 1067: else > > > > Am I doing something wrong, or is Og having trouble with > > SchemaInheritanceBase? > > > > Good catch. It's a bug in the Sqlite3 store. Thanks for reporting. > The problem was that Sqlite3 wasn't using the stock fields_for_class method in SqlStore that accounted for STI. I've fixed in the darcs repo. Many thanks for reporting. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 3 20:43:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 17:43:48 -0700 Subject: [Nitro] REPO updated. Message-ID: Mon Apr 3 16:57:27 PDT 2006 bryan.a.soto at gmail.com * og-sqlite-sti-fix Sqlite3 store was not using fields_for_class defined in SqlStore, so it was improperly handling single table inheritance. Mon Apr 3 16:59:47 PDT 2006 bryan.a.soto at gmail.com * og-sqlite-test-fix Config setting was keeping Og test suite from running when using the Sqlite3 store. This probably just masks the symptom more than anything else though. The real culprit probably lies lurking somewhere. ~~~ darcs pull http://devlab.oree.ch/darcs/nitrohq With the sqlite test fix, the Og test suite completes with Mysql and Sqlite. Postgres dies with this error: E, [2006-04-03T16:33:43.617072 #10799] ERROR -- : DB error ERROR: relation "ogj_tcogstore_category_tcogstore_newarticle" does not exist , [INSERT INTO ogj_tcogstore_category_tcogstore_newarticle (category_oid,newarticle_oid) VALUES (1, 1)] The problem seems to be that it is creating join tables in a different manner than the other stores. Where Mysql is using: if join_tables = klass.ann.self[:join_tables] Postgres does: join_tables = klass.relations.reject{|rel| !rel.join_table}.map{|rel| join_table_info(rel)} Changing that line makes the test suite fail later on in taggable. I don't know Postgres well enough to want to make the change though especially as I don't know where the code originated from, though I'm guessing probably Rob. I can only go by what the tests tell me. So, can anyone comment on this one? Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From Reid.Thompson at ateb.com Mon Apr 3 21:00:56 2006 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Mon, 03 Apr 2006 21:00:56 -0400 Subject: [Nitro] Errors with Og and existing table/data Message-ID: <4431C548.50204@ateb.com> given.. testexisting=# create table testtable(mytext text primary key, mynumber integer, yourtext text); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "testtable_pkey" for table "testtable" CREATE TABLE testexisting=# \d testtable; Table "public.testtable" Column | Type | Modifiers ----------+---------+----------- mytext | text | not null mynumber | integer | yourtext | text | Indexes: "testtable_pkey" PRIMARY KEY, btree (mytext) what am I missing in the program below that is causing the save to fail with error:/usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/connection.rb:115:in `query': ERROR C42601 Msyntax error at or near "new" P81 Fscan.l L761 Ryyerror (RuntimeError) from /usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/postgres-compat.rb:33:in `exec' from /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/psql.rb:307:in `sql_update' from (eval):6:in `og_update' from /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:102:in `save' from /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' from ogexisting.rb:35 ) ------------------------------------------- require 'og' class Testtable include Og::EntityMixin property :mytext, String, Og::NotNull property :mynumber, Fixnum property :yourtext, String set_table :testtable set_primary_key :mytext, String end og_psql = { :destroy_tables => false, # don't use this on a DB with tables that you DO NOT want to lose -- or set to false :store => :psql, :user => 'rthompso', :password => 'rthompso', :name => 'testexisting' } Og.table_prefix = '' # remove og generated table prefix db = Og.setup(og_psql) # if there are pre-existing recoreds, this DOES retrieve and print them mystore = db.store res = mystore.query("select * from testtable") res.each {|rec| puts rec } a=Testtable.new a.mynumber = 34 a.yourtext = 'some new your text' a.mytext ='my new text' a.save # failure here res = mystore.query("select * from testtable") res.each {|rec| puts rec } From james_b at neurogami.com Mon Apr 3 22:03:28 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 03 Apr 2006 19:03:28 -0700 Subject: [Nitro] gen - facet rubygems version hell Message-ID: <4431D3F0.2040008@neurogami.com> I just tried to create a Nitro app using gen, and got this: c:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:204:in `report_activate_error': RubyGem version error: facets(1.2.1 not = 1.0.3) (Gem::LoadError) Arrg! Not too long ago I was running something else and had dopey gem version noise regarding facets; I forget the details, but I noticed that the names and numbering of facets were inconsistent (some had obvious version numbers, others had what looked like dates). I cleared out facets, and installed the latest version fresh. Apparently, though, the gen installed with Nitro 0.29 does not care for the latest facets, insisting on a very specific version. OK, so I uninstall all gen gems, and reinstall, figuring it will also install the dependencies. Nope. It seems (I haven't looked) that the code demands a special version, but the gem spec does nothing to enforce this. Very bad. I also tried reinstall Nitro, figuring it would makes sure I had working arrangement of gen and facets. Nope. Now, I may have botched my set up someplace along the lines, but this is not the first time I've had issues with *exact* gem versions were needed for some part of Nitro, and code would not run. I believe that it is a bad idea to write a library that requires a fixed version, rather than some version or better, of another library. Otherwise it is too fragile and you get these problems. I certainly hope this gets sorted out soon. If libraries are so unstable, then should not be in gems; they should be directly bundled with the main distribution. Gem paths and file names should not be bouncing around from one version to the next. I'm wondering if all the code needed for Og/Nitro should just be package up into one gem, until Nitro reached version 1.0. And the the code can be refactored into subsections. Anyway, rant over; I'm going to finish dinner. -- James Britt "Blanket statements are over-rated" From transfire at gmail.com Mon Apr 3 23:09:41 2006 From: transfire at gmail.com (TRANS) Date: Mon, 3 Apr 2006 23:09:41 -0400 Subject: [Nitro] gen - facet rubygems version hell In-Reply-To: <4431D3F0.2040008@neurogami.com> References: <4431D3F0.2040008@neurogami.com> Message-ID: <4b6f054f0604032009k274b9b71q8baeadcabd1c8648@mail.gmail.com> Nitro/Og depend on a specific verison of Facets for good reason, and it has everything to do with stability. On installation Nitro 0.29 should install the correct version of Facets. If there are problems you can get the right version manually: gem install facets -v 1.0.3 If you have the lastest version of Facets installed (1.2.1), I'm guessing the problem arises b/c Nitro isn't activating the 1.0.3 gem and instead just loads the version automatically selected by Gems --which is alwasy the latest. To fix, try: require_gem 'facets', '= 1.0.3' before requiring any part of Nitro --I suppose in run.rb. I know it can be frustrating, but don't be to hard on Nitro or Facets on this. Taking into account RubyGems while also trying to maintain a proper manual distribution (Facets does, Nitro should) has driven me bonkers more than a few times. Try dealing with datadir for instance --a problem that's been talked about for two years without a solution. I finally came up with a work around and suggested it on gems mailing list --think I've heard a word about it yet? Not one. I ended up having to create a Gem Facet! I'll be honest with you I think Gems sucks. Which is why I created Rolls. But Rolls still needs some tweaking, and unfortunately I'm not sure when I'll be able to get to it. But also, Rolls is only half the issue. It handles library management and versioning. But it still needs a distribution/install mechinsim to go with it. I started a project for that too, based on setup.rb, but now I'm finding cracks in setup.rb and Minero is not reponding to my emails either! Frak, maybe they just don't like me. I don't know. I don't care. The bottom line is that Ruby's ditribution and lib management is for shit --despite the glitzy hype. IM(equally pissy)HO T. P.S. Anyone feel like re-writing setup.rb? If you do I'll build a very nifty distribution system around it. One that generates packages on the fly geared to your partciular OS. Anyone? From bryan.a.soto at gmail.com Tue Apr 4 02:41:03 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 3 Apr 2006 23:41:03 -0700 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly Message-ID: See http://devlab.oree.ch/trac/nitrohq/ticket/13 for info. Adds the test case and supplies a fix. Passes the test suite. Please review. I don't want to apply my fix if it causes problems. Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 25143 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060404/4f8195a2/attachment.zip From news at stephan.walter.name Tue Apr 4 05:47:25 2006 From: news at stephan.walter.name (Stephan Walter) Date: Tue, 04 Apr 2006 11:47:25 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted References: Message-ID: On Mon, 03 Apr 2006 17:17:26 -0700, Bryan Soto wrote: > The problem was that Sqlite3 wasn't using the stock fields_for_class > method in SqlStore that accounted for STI. I've fixed in the darcs repo. > > Many thanks for reporting. I tried it with the repo but it still does not work (or maybe it wasn't this error you were talking about. Evolving the schema works now): D, [2006-04-04T11:41:20.713415 #9158] DEBUG -- : Rendering '/admin/babel__model_translations/edit/1'. D, [2006-04-04T11:41:20.723878 #9158] DEBUG -- : SELECT * FROM ogbabel_translation WHERE oid=1 AND ogtype='Babel::ModelTranslation' E, [2006-04-04T11:41:20.725516 #9158] ERROR -- : Error while handling '/admin/babel__model_translations/edit/1'. E, [2006-04-04T11:41:20.725889 #9158] ERROR -- : undefined method `result' for # /home/i/ruby/nitro/nitrohq/og/lib/og/store/sql.rb:1092:in `read_one' /home/i/ruby/nitro/nitrohq/og/lib/og/store/sql.rb:389:in `load' /home/i/ruby/nitro/nitrohq/og/lib/og/entity.rb:149:in `[]' (eval):6:in `babel__model_translations__edit' (eval):15:in `babel__model_translations__edit_action' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/render.rb:126:in `render' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/adapter/webrick.rb:149:in `do_GET' /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib/ruby/1.8/webrick/server.rb:82:in `start' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/adapter/webrick.rb:54:in `start' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/server/runner.rb:333:in `invoke_server' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/server/runner.rb:295:in `invoke' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/server.rb:134:in `run' /home/i/ruby/nitro/nitrohq/nitro/lib/nitro.rb:77:in `run' ./run.rb:24 LOGGED FROM: /home/i/ruby/nitro/nitrohq/nitro/lib/nitro/render.rb:244:in `log_error' -Stephan From news at stephan.walter.name Tue Apr 4 07:38:38 2006 From: news at stephan.walter.name (Stephan Walter) Date: Tue, 04 Apr 2006 13:38:38 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted References: Message-ID: On Tue, 04 Apr 2006 11:47:25 +0200, Stephan Walter wrote: > I tried it with the repo but it still does not work (or maybe it wasn't > this error you were talking about. Evolving the schema works now): [snip] reported as #30, patch included: http://devlab.oree.ch/trac/nitrohq/ticket/30 -Stephan From james_b at neurogami.com Tue Apr 4 11:14:59 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 04 Apr 2006 08:14:59 -0700 Subject: [Nitro] gen - facet rubygems version hell In-Reply-To: <4b6f054f0604032009k274b9b71q8baeadcabd1c8648@mail.gmail.com> References: <4431D3F0.2040008@neurogami.com> <4b6f054f0604032009k274b9b71q8baeadcabd1c8648@mail.gmail.com> Message-ID: <44328D73.8010005@neurogami.com> TRANS wrote: > Nitro/Og depend on a specific verison of Facets for good reason, and > it has everything to do with stability. On installation Nitro 0.29 > should install the correct version of Facets. If there are problems > you can get the right version manually: > > gem install facets -v 1.0.3 I already had that installed, but gen was not loading it. > > If you have the lastest version of Facets installed (1.2.1), I'm > guessing the problem arises b/c Nitro isn't activating the 1.0.3 gem > and instead just loads the version automatically selected by Gems > --which is alwasy the latest. To fix, try: > > require_gem 'facets', '= 1.0.3' > > before requiring any part of Nitro --I suppose in run.rb. The problem this time was calling 'gen', not with running a Nitro app. But if one needs to add that line to run.rb to ensure that it works, then perhaps it should be built in to the code generator. It still strikes me as odd that later versions of a gem are presumed to break compatibility, though. It's as if each version of facets is a unique one-off library that just happens to have the same name. Why shouldn't 1.2.1 work? > > I know it can be frustrating, but don't be to hard on Nitro or Facets > on this. Taking into account RubyGems while also trying to maintain a > proper manual distribution (Facets does, Nitro should) has driven me > bonkers more than a few times. Try dealing with datadir for instance > --a problem that's been talked about for two years without a solution. > I finally came up with a work around and suggested it on gems mailing > list --think I've heard a word about it yet? Not one. I ended up > having to create a Gem Facet! I've no doubt that there are headaches with RubyGems, but I've only seen these sorts of troubles with the Og/Nitro family of gems. So I suspect that the library dependencies are more complicated than need be (but I see that people are addressing this). It's just extremely frustrating, and makes it very hard to encourage others to use Og/Nitro. Anyway, I've sorted things out by uninstalling all the associated gems and reinstalling Nitro. > > I'll be honest with you I think Gems sucks. Which is why I created > Rolls. > But Rolls still needs some tweaking, and unfortunately I'm not > sure when I'll be able to get to it. But also, Rolls is only half the > issue. It handles library management and versioning. But it still > needs a distribution/install mechinsim to go with it. I started a > project for that too, based on setup.rb, but now I'm finding cracks in > setup.rb and Minero is not reponding to my emails either! Frak, maybe > they just don't like me. I don't know. I don't care. The bottom line > is that Ruby's ditribution and lib management is for shit --despite > the glitzy hype. > Well, sucky or not, the reality is that gems has the Ruby community mind share and is almost certain to become a core part of the distribution. The options are to use it (and try to improve it), or stick to the hell of install.rb, or create Yet Another Installer/Packager/Versioning System. And if Nitro hooks itself to something other than gems, then it will have an even tougher time gathering attention and use. -- James Britt "You harmonize; then you customize." - Wilson Pickett From transfire at gmail.com Tue Apr 4 11:27:54 2006 From: transfire at gmail.com (TRANS) Date: Tue, 4 Apr 2006 11:27:54 -0400 Subject: [Nitro] gen - facet rubygems version hell In-Reply-To: <44328D73.8010005@neurogami.com> References: <4431D3F0.2040008@neurogami.com> <4b6f054f0604032009k274b9b71q8baeadcabd1c8648@mail.gmail.com> <44328D73.8010005@neurogami.com> Message-ID: <4b6f054f0604040827u36ac1426h1dbfb4bea2563db8@mail.gmail.com> > It's as if each version of facets is a unique one-off library that just happens to > have the same name. Why shouldn't 1.2.1 work? It probably would. But the whole point of versioning (and hence Gems) is to make sure that it does. T. From george.moschovitis at gmail.com Tue Apr 4 12:21:16 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 4 Apr 2006 19:21:16 +0300 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> Message-ID: > Ah.. another reason modified but backward compatible #attr methods are > a safe bet. I always wanted to convert to attr_ methods instead of prop, but am not really sure if this is possible... Will investigate this again... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 4 12:27:27 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 4 Apr 2006 19:27:27 +0300 Subject: [Nitro] [PATCH] ignore column Message-ID: to make kashia happy... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle Type: application/octet-stream Size: 42834 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060404/815bf1d2/attachment.obj From transfire at gmail.com Tue Apr 4 13:04:56 2006 From: transfire at gmail.com (TRANS) Date: Tue, 4 Apr 2006 13:04:56 -0400 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> Message-ID: <4b6f054f0604041004o3a4f9fa7t6723cbf5536f5a86@mail.gmail.com> On 4/4/06, George Moschovitis wrote: > > Ah.. another reason modified but backward compatible #attr methods are > > a safe bet. > > I always wanted to convert to attr_ methods instead of prop, but am > not really sure if this is possible... Will investigate this again... I know you can do it as long as they are passive. I.e. just adding in the extra annotation call. Right now I suspect #poperty is too dynamically active --though it may still be possible. T. From transfire at gmail.com Tue Apr 4 13:11:27 2006 From: transfire at gmail.com (TRANS) Date: Tue, 4 Apr 2006 13:11:27 -0400 Subject: [Nitro] properties In-Reply-To: References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> Message-ID: <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> On 4/3/06, Bryan Soto wrote: > It was just a joke. :) I was just trying to imagine what certain > denizens of the mailing list would have had to say about that > suggestion. ;) :-) I'm sure a lot of wonderful things if *I* brough it up ;-) > Seriously though, in the context of this thread, you'd still have the > original problem of how do you access them with a name that's not > properties. Besides, if we go that route, I'd prefer we just annotate. Well, certainly a fair way to do it, albiet it doubles line count. > Hmm... That's a thought. Why not just store the properties as > annotations? The prop_* methods and property could just be interfaces > to the annotation system. I wonder if that would work... It does actually. Except it also creates the attribute (Seems kind of a waste not to since the information is there), and of course it does that enchanting thing. T. From bryan.a.soto at gmail.com Tue Apr 4 13:41:55 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 10:41:55 -0700 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: On 4/4/06, Stephan Walter wrote: > On Tue, 04 Apr 2006 11:47:25 +0200, Stephan Walter wrote: > > > I tried it with the repo but it still does not work (or maybe it wasn't > > this error you were talking about. Evolving the schema works now): > > [snip] > > reported as #30, patch included: > > http://devlab.oree.ch/trac/nitrohq/ticket/30 Yeah, I was talking about schema evolution only. I must have missed the fact that there was another problem. Thanks for creating a ticket and patch. It's greatly appreciated. I'll check out as soon as I can. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From kashia at vfemail.net Tue Apr 4 13:41:55 2006 From: kashia at vfemail.net (Kashia Buch) Date: Tue, 04 Apr 2006 19:41:55 +0200 Subject: [Nitro] [PATCH] ignore column In-Reply-To: References: Message-ID: > to make kashia happy... LOL thank you very much :) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Tue Apr 4 13:48:41 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 10:48:41 -0700 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> References: <442EE4C0.4080801@cs.helsinki.fi> <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> Message-ID: On 4/4/06, TRANS wrote: > On 4/3/06, Bryan Soto wrote: > > Hmm... That's a thought. Why not just store the properties as > > annotations? The prop_* methods and property could just be interfaces > > to the annotation system. I wonder if that would work... > > It does actually. Except it also creates the attribute (Seems kind of > a waste not to since the information is there), and of course it does > that enchanting thing. It does? Hmm... I must be missing something... -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 4 16:09:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 13:09:09 -0700 Subject: [Nitro] PATCH: adds params to AJAX helper generated functions. In-Reply-To: <1143279160.3992.15.camel@nissl.mammuth> References: <1143279160.3992.15.camel@nissl.mammuth> Message-ID: If there are no objections, I'm going to apply this. On 3/25/06, Massimo Maria Ghisalberti wrote: > in my opinion, but this patch is mine ;) > > it is useful because I need to have the id of the element that send > click event (for dispatching to a single page method handler), but in > general a javascript event handler will must to have an object event as > first parameter, in special case for mozilla browser where the object > event is internal to event handler, not is the case of IE where exist a > global window.event. > > the right js generated will must be (pseudo): > > event_handler_function(event, param){ > > var Ev; > if (window.event) > Ev = event = window.event > else > Ev = event > ... > handler code > ... > } > > in the single param you can pass any sort of data... simple type or > complete object, obviously is you responsability to handle this right. > > ciao > > Massimo > > Il giorno sab, 25/03/2006 alle 00.06 -0800, Bryan Soto ha scritto: > > Adds code submitted via mailing list and a testcase. > > > > See http://rubyforge.org/pipermail/nitro-general/2006-March/003453.html > > for more info. > > > > I wanted to get some more opinions on this one. > > > > Thanks. > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > -- > Massimo Maria Ghisalberti > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 4 16:39:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 13:39:48 -0700 Subject: [Nitro] properties In-Reply-To: References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> Message-ID: On 4/4/06, Bryan Soto wrote: > On 4/4/06, TRANS wrote: > > On 4/3/06, Bryan Soto wrote: > > > Hmm... That's a thought. Why not just store the properties as > > > annotations? The prop_* methods and property could just be interfaces > > > to the annotation system. I wonder if that would work... > > > > It does actually. Except it also creates the attribute (Seems kind of > > a waste not to since the information is there), and of course it does > > that enchanting thing. > > It does? Hmm... I must be missing something... > I see. It uses both annotations *and* properties for storage. I meant just using annotations. Anyway, this thread has gotten really long and doesn't seem to have accomplished anything. I guess we'll leave the ticket open for now and log the suggestions we have received so far. Final outcome: Matz^H^H^H^HGeorge is open to renaming, but doesn't like any of the suggestions so far. Ever get that weird deja vu feeling? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Tue Apr 4 16:58:15 2006 From: transfire at gmail.com (TRANS) Date: Tue, 4 Apr 2006 16:58:15 -0400 Subject: [Nitro] properties In-Reply-To: References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> Message-ID: <4b6f054f0604041358o6d020aa5n767471b1e1870f23@mail.gmail.com> On 4/4/06, Bryan Soto wrote: > On 4/4/06, Bryan Soto wrote: > > On 4/4/06, TRANS wrote: > > > On 4/3/06, Bryan Soto wrote: > > > > Hmm... That's a thought. Why not just store the properties as > > > > annotations? The prop_* methods and property could just be interfaces > > > > to the annotation system. I wonder if that would work... > > > > > > It does actually. Except it also creates the attribute (Seems kind of > > > a waste not to since the information is there), and of course it does > > > that enchanting thing. > > > > It does? Hmm... I must be missing something... > > > > I see. It uses both annotations *and* properties for storage. I meant > just using annotations. I agree. That would be nice. > Final outcome: Matz^H^H^H^HGeorge is open to renaming, but doesn't > like any of the suggestions so far. Ever get that weird deja vu > feeling? :D From bryan.a.soto at gmail.com Wed Apr 5 01:32:49 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 22:32:49 -0700 Subject: [Nitro] Gem dependencies. Message-ID: Following up on James' complaint and Trans' comments re: gem installation noise, perhaps we should revamp our dependencies. So our correct dependencies are: Glue: Facets RedCloth Og: Glue Nitro: Gen Og Ruby-Breakpoint Daemons Gen: Nitro Somewhat cleaned up to try and eliminate the double glue install. I know we we're going to try and get rid of glue, but according to my chat log, George is looking to release this week, so I'm thinking we should delay that till after this release. Of these, what do we really need? In addition, to end our Ruby gem versioning problem, perhaps we should get away from exact requirements. Well, possibly excepting RedCloth. I've heard that 3.0.4 is buggy. So, in Ruby Gem constraint language: facets, '~> 1.2' # This assumes that anything that changes interface will be 2.0+ RedCloth, '= 3.0.3' # Assuming 3.0.4 is buggy daemons, '~> 0.4' # All the recent updates have been bug fixes ruby-breakpoint, '~> 0.5' # This one hasn't changed in over a year, but... The ~> tells gems that the releases should be backwards compatible. As an example, if the interface for facets changed in a way that broke old code, it expects the version number would bump to 2.0. As long as the code is backwards compatible all the way up to 2.0, this should prevent the errors James and others have reported in regards to facets. Comments? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 01:44:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 22:44:35 -0700 Subject: [Nitro] Errors with Og and existing table/data In-Reply-To: <4431C548.50204@ateb.com> References: <4431C548.50204@ateb.com> Message-ID: On 4/3/06, Reid Thompson wrote: > given.. > testexisting=# create table testtable(mytext text primary key, mynumber > integer, yourtext text); > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index > "testtable_pkey" for table "testtable" > CREATE TABLE > testexisting=# \d testtable; > Table "public.testtable" > Column | Type | Modifiers > ----------+---------+----------- > mytext | text | not null > mynumber | integer | > yourtext | text | > Indexes: > "testtable_pkey" PRIMARY KEY, btree (mytext) > > what am I missing in the program below that is causing the save to fail > with > error:/usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/connection.rb:115:in > `query': ERROR C42601 Msyntax error at or near "new" P81 > Fscan.l L761 Ryyerror (RuntimeError) > from > /usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/postgres-compat.rb:33:in > `exec' > from > /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/psql.rb:307:in > `sql_update' > from (eval):6:in `og_update' > from > /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:102:in `save' > from > /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' > from ogexisting.rb:35 > ) > ------------------------------------------- > require 'og' > > class Testtable > include Og::EntityMixin > > property :mytext, String, Og::NotNull > property :mynumber, Fixnum > property :yourtext, String > > set_table :testtable > set_primary_key :mytext, String > end > > og_psql = { > :destroy_tables => false, # don't use this on a DB with tables that > you DO NOT want to lose -- or set to false > :store => :psql, > :user => 'rthompso', > :password => 'rthompso', > :name => 'testexisting' > } > > Og.table_prefix = '' # remove og generated table prefix Could you add the line below and re-run? We might get better info if we see the sql that is generated. Unfortunately I'm not a postgres user, so I can't easily replicate this. Hopefully someone more familiar with it will chime in... $DBG = true > db = Og.setup(og_psql) > > # if there are pre-existing recoreds, this DOES retrieve and print them > mystore = db.store > res = mystore.query("select * from testtable") > res.each {|rec| > puts rec > } > > a=Testtable.new > a.mynumber = 34 > a.yourtext = 'some new your text' > a.mytext ='my new text' > a.save # failure here > > res = mystore.query("select * from testtable") > res.each {|rec| > puts rec > } > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 02:01:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 23:01:47 -0700 Subject: [Nitro] Ticket #14: setting :default is not available Message-ID: I've closed this ticket. Default is a reserved word in SQL syntax which is why trying to create a column with this name fails. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 02:06:20 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 23:06:20 -0700 Subject: [Nitro] Ticket #10: SEGFAULT with WebFile + .assign Message-ID: I haven't been able to reproduce this. If someone could supply a testcase or script that can replicate it, we could see what we can do. I'm assuming this is an RMagick problem, so that might not be much. Anyway, if we don't get anything, I'm going to go ahead and close this ticket. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 02:17:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 23:17:01 -0700 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604041358o6d020aa5n767471b1e1870f23@mail.gmail.com> References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> <4b6f054f0604041358o6d020aa5n767471b1e1870f23@mail.gmail.com> Message-ID: I've updated the ticket with everything. I hope anyway. Thanks. http://devlab.oree.ch/trac/nitrohq/ticket/12 On 4/4/06, TRANS wrote: > On 4/4/06, Bryan Soto wrote: > > On 4/4/06, Bryan Soto wrote: > > > On 4/4/06, TRANS wrote: > > > > On 4/3/06, Bryan Soto wrote: > > > > > Hmm... That's a thought. Why not just store the properties as > > > > > annotations? The prop_* methods and property could just be interfaces > > > > > to the annotation system. I wonder if that would work... > > > > > > > > It does actually. Except it also creates the attribute (Seems kind of > > > > a waste not to since the information is there), and of course it does > > > > that enchanting thing. > > > > > > It does? Hmm... I must be missing something... > > > > > > > I see. It uses both annotations *and* properties for storage. I meant > > just using annotations. > > I agree. That would be nice. > > > Final outcome: Matz^H^H^H^HGeorge is open to renaming, but doesn't > > like any of the suggestions so far. Ever get that weird deja vu > > feeling? > > :D > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 02:27:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 23:27:00 -0700 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: Do you have a simple script or test case to reproduce the problem? I'm curious as it seems to be a rather fundamental flaw. If it is a bug, we'd definitely want to add something to the test suite to catch it in the future. Many thanks. Bryan On 4/4/06, Bryan Soto wrote: > On 4/4/06, Stephan Walter wrote: > > On Tue, 04 Apr 2006 11:47:25 +0200, Stephan Walter wrote: > > > > > I tried it with the repo but it still does not work (or maybe it wasn't > > > this error you were talking about. Evolving the schema works now): > > > > [snip] > > > > reported as #30, patch included: > > > > http://devlab.oree.ch/trac/nitrohq/ticket/30 > > Yeah, I was talking about schema evolution only. I must have missed > the fact that there was another problem. Thanks for creating a ticket > and patch. It's greatly appreciated. I'll check out as soon as I can. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 02:36:12 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 4 Apr 2006 23:36:12 -0700 Subject: [Nitro] [FIX] find_or_create_by with relations In-Reply-To: References: Message-ID: I'm not sure if this is a bug or an enhancement. I don't think what Stephan was trying to do was supported by Og. What do you think? Is this a good enhancement? Any other opinions? See http://devlab.oree.ch/trac/nitrohq/ticket/29 Thanks, Bryan On 4/2/06, George Moschovitis wrote: > Thanks, i will review this shortly. > > -g. > > On 4/2/06, Stephan Walter wrote: > > Hi, > > > > Og currently has a problem with find_or_create_by_* if the object has > > relations. The find will execute correctly, but when no object is found, > > the creation of the new object will not include the relations. > > > > Made-up example: > > > > class A > > property :name > > belongs_to :b, B > > end > > > > class B > > end > > > > A.find_or_create_by_name_and_b("foo", @b) > > > > This will result in the correct SELECT statement: > > > > SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 > > > > If no object is found, the following INSERT statement will be wrong, the > > b_oid should not be NULL: > > > > INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) > > > > The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However > > I am not sure if the patch does the right thing, and I have not tested it > > a lot. It'd be great if someone could look into this. > > > > -Stephan > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 03:01:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 00:01:42 -0700 Subject: [Nitro] Controller resolution order In-Reply-To: References: <440C65DC.7090200@cataclysm-software.net> Message-ID: On 3/24/06, George Moschovitis wrote: > > Unless someone objects, I think we should create a ticket for this. > > Hello, there is a reason for this behaviour (at the moment it supports > the 'inteligent' dispatcher, ie auto nice urls and stuff). I do not > have the time to explain this at the moment. However I know how to > make the dispatcher even more intelligent to handle cases such as > this. I just havent needed it till now, so I didn't bother. > > Bryan, please create a ticket, and I will either improve this in the > next week or post a detailed explanation, with my tips how to improve > it so someone else can try it. > Just a reminder on this one. I had been thinking of just having it match the longest possible mount point. But I'd be interested in your explanation if you don't have time to write any code. Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From aglarond at gmail.com Wed Apr 5 03:29:45 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Wed, 5 Apr 2006 09:29:45 +0200 Subject: [Nitro] Gem dependencies. In-Reply-To: References: Message-ID: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> On 4/5/06, Bryan Soto wrote: > > So, in Ruby Gem constraint language: > facets, '~> 1.2' # This assumes that anything that changes > interface will be 2.0+ > RedCloth, '= 3.0.3' # Assuming 3.0.4 is buggy > daemons, '~> 0.4' # All the recent updates have been bug fixes > ruby-breakpoint, '~> 0.5' # This one hasn't changed in over a year, but... > > The ~> tells gems that the releases should be backwards compatible. As > an example, if the interface for facets changed in a way that broke > old code, it expects the version number would bump to 2.0. As long as > the code is backwards compatible all the way up to 2.0, this should > prevent the errors James and others have reported in regards to > facets. > > Comments? Sounds good to me. Can this be done for 0.30.0? - Dimitri From news at stephan.walter.name Wed Apr 5 04:47:25 2006 From: news at stephan.walter.name (Stephan Walter) Date: Wed, 05 Apr 2006 10:47:25 +0200 Subject: [Nitro] "babel": new translation system - suggestions&help wanted References: Message-ID: On Tue, 04 Apr 2006 23:27:00 -0700, Bryan Soto wrote: > Do you have a simple script or test case to reproduce the problem? I'm > curious as it seems to be a rather fundamental flaw. If it is a bug, we'd > definitely want to add something to the test suite to catch it in the > future. I added a simple test script to the ticket http://devlab.oree.ch/trac/nitrohq/attachment/ticket/30/test-ticket30.rb (run it with og from the current devlab.oree.ch repo) -Stephan From transfire at gmail.com Wed Apr 5 07:10:39 2006 From: transfire at gmail.com (TRANS) Date: Wed, 5 Apr 2006 07:10:39 -0400 Subject: [Nitro] Gem dependencies. In-Reply-To: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> Message-ID: <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> > facets, '~> 1.2' # This assumes that anything that changes > interface will be 2.0+ Hmm... it's not up to 1.3+? Well if not then I think make it facets, '~> 1.2.0' Tell me if you think I've misjudged on this, but my reasoning is that Facets has so many libs that any _one_ interface change in any _one_ of them requires a version jump and I don't want to be pushing version 5.0+ just b/c of four such changes. T. From transfire at gmail.com Wed Apr 5 13:32:41 2006 From: transfire at gmail.com (TRANS) Date: Wed, 5 Apr 2006 13:32:41 -0400 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> Message-ID: <4b6f054f0604051032m7c424efaq6f6ca7b66a77cd9d@mail.gmail.com> On 4/5/06, TRANS wrote: > > facets, '~> 1.2' # This assumes that anything that changes > > interface will be 2.0+ > > Hmm... it's not up to 1.3+? Well if not then I think make it > > facets, '~> 1.2.0' > > Tell me if you think I've misjudged on this, but my reasoning is that > Facets has so many libs that any _one_ interface change in any _one_ > of them requires a version jump and I don't want to be pushing version > 5.0+ just b/c of four such changes. Okay, there's two side to this coin. You want to loosen the constraint on Nitro's dependencies to allows Facets or other dependency to be updated and Nitro use the latest. Well, it's a tow edge sword. You may run into some issures now to make sure Nitro is picking up the right version, but you could also run into trouble later if something changes that effects Nitro adversely. Personally I lean towards George's opinion. Keep strict version control. T. From transfire at gmail.com Wed Apr 5 13:46:10 2006 From: transfire at gmail.com (TRANS) Date: Wed, 5 Apr 2006 13:46:10 -0400 Subject: [Nitro] gen - facet rubygems version hell In-Reply-To: <44328D73.8010005@neurogami.com> References: <4431D3F0.2040008@neurogami.com> <4b6f054f0604032009k274b9b71q8baeadcabd1c8648@mail.gmail.com> <44328D73.8010005@neurogami.com> Message-ID: <4b6f054f0604051046j385cbea1v42c159f7ed4d97a5@mail.gmail.com> > Well, sucky or not, the reality is that gems has the Ruby community mind > share and is almost certain to become a core part of the distribution. > The options are to use it (and try to improve it), or stick to the hell > of install.rb, or create Yet Another Installer/Packager/Versioning System. The problem is that Gems is causing additional hell. It is actually forcing the use of Gems for things to work properly. Right now there are conflicts between the manual installation of my wares and the Gem installs, which further require that I additional code in my scripts to correct. It also alienates other devleopers for using the reusable parts of my software (shared data) b/c they get squirrel away in a special repository. It also alienates OS specific packaging system --which btw are design to offer a universal managment of ones system, thus Gems reopens the wounds those systems are in many ways designed to fix. And further more Gems ties incode Ruby library version management to this particular distribution mechinism. T. From bryan.a.soto at gmail.com Wed Apr 5 13:59:16 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 10:59:16 -0700 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> Message-ID: On 4/5/06, TRANS wrote: > > facets, '~> 1.2' # This assumes that anything that changes > > interface will be 2.0+ > > Hmm... it's not up to 1.3+? Well if not then I think make it > I deleted a long explanation because I thought of a concise way to put it. The assumption is, If you have to change your tests or old code to make things work (excluding changes made to accommodate a bug), you should bump your major version. Basically, that dependency assumes that anything in the 1.x range will be backwards compatible in the interface. Not in the implementation or bug-wise. > facets, '~> 1.2.0' > > Tell me if you think I've misjudged on this, but my reasoning is that > Facets has so many libs that any _one_ interface change in any _one_ > of them requires a version jump and I don't want to be pushing version > 5.0+ just b/c of four such changes. > Perhaps it'd be best if you explain your version scheme in terms of backwards compatibility. Will 1.3 not be backwards compatible to 1.2? If that is the case, then you're probably right about 'facets ~> 1.2.0'. At least if you explain how you plan to version, we can figure out how to depend on it from there. Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 14:23:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 11:23:08 -0700 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604051032m7c424efaq6f6ca7b66a77cd9d@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> <4b6f054f0604051032m7c424efaq6f6ca7b66a77cd9d@mail.gmail.com> Message-ID: On 4/5/06, TRANS wrote: > On 4/5/06, TRANS wrote: > > > facets, '~> 1.2' # This assumes that anything that changes > > > interface will be 2.0+ > > > > Hmm... it's not up to 1.3+? Well if not then I think make it > > > > facets, '~> 1.2.0' > > > > Tell me if you think I've misjudged on this, but my reasoning is that > > Facets has so many libs that any _one_ interface change in any _one_ > > of them requires a version jump and I don't want to be pushing version > > 5.0+ just b/c of four such changes. > > Okay, there's two side to this coin. You want to loosen the constraint > on Nitro's dependencies to allows Facets or other dependency to be > updated and Nitro use the latest. Well, it's a tow edge sword. You may > run into some issures now to make sure Nitro is picking up the right > version, but you could also run into trouble later if something > changes that effects Nitro adversely. > In which case, we release new gems of our own to accomodate. Besides, George loves to "release early and release often". And if he's not available, I have access to the Rubyforge file release. I don't know how to use it, but I'm sure someone would be able to help me if I needed it. :) > Personally I lean towards George's opinion. Keep strict version control. > But then people aren't able to use the latest facet in their Nitro or Og apps without getting those pesky gem activation errors. There's the rub. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 16:50:34 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 13:50:34 -0700 Subject: [Nitro] "babel": new translation system - suggestions&help wanted In-Reply-To: References: Message-ID: On 4/5/06, Stephan Walter wrote: > On Tue, 04 Apr 2006 23:27:00 -0700, Bryan Soto wrote: > > > Do you have a simple script or test case to reproduce the problem? I'm > > curious as it seems to be a rather fundamental flaw. If it is a bug, we'd > > definitely want to add something to the test suite to catch it in the > > future. > > I added a simple test script to the ticket > http://devlab.oree.ch/trac/nitrohq/attachment/ticket/30/test-ticket30.rb > (run it with og from the current devlab.oree.ch repo) > That seems to be a bug all right. We'll need to double check the read_all method too as it looks like it isn't properly casting in STI. Thanks for the patch and test. I'll try and add them today. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 16:58:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 13:58:09 -0700 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly In-Reply-To: References: Message-ID: I've applied these and will close the ticket. On 4/3/06, Bryan Soto wrote: > See http://devlab.oree.ch/trac/nitrohq/ticket/13 for info. > > Adds the test case and supplies a fix. Passes the test suite. Please > review. I don't want to apply my fix if it causes problems. > > Thanks. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 17:02:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 14:02:21 -0700 Subject: [Nitro] PATCH: adds params to AJAX helper generated functions. In-Reply-To: References: <1143279160.3992.15.camel@nissl.mammuth> Message-ID: I've applied. Thanks for the patch Massimo. On 4/4/06, Bryan Soto wrote: > If there are no objections, I'm going to apply this. > > On 3/25/06, Massimo Maria Ghisalberti wrote: > > in my opinion, but this patch is mine ;) > > > > it is useful because I need to have the id of the element that send > > click event (for dispatching to a single page method handler), but in > > general a javascript event handler will must to have an object event as > > first parameter, in special case for mozilla browser where the object > > event is internal to event handler, not is the case of IE where exist a > > global window.event. > > > > the right js generated will must be (pseudo): > > > > event_handler_function(event, param){ > > > > var Ev; > > if (window.event) > > Ev = event = window.event > > else > > Ev = event > > ... > > handler code > > ... > > } > > > > in the single param you can pass any sort of data... simple type or > > complete object, obviously is you responsability to handle this right. > > > > ciao > > > > Massimo > > > > Il giorno sab, 25/03/2006 alle 00.06 -0800, Bryan Soto ha scritto: > > > Adds code submitted via mailing list and a testcase. > > > > > > See http://rubyforge.org/pipermail/nitro-general/2006-March/003453.html > > > for more info. > > > > > > I wanted to get some more opinions on this one. > > > > > > Thanks. > > > > > > -- > > > "Never tell people how to do things. Tell them what to do and they > > > will surprise you with their ingenuity." ?General George S. Patton > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > -- > > Massimo Maria Ghisalberti > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 5 17:09:37 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 14:09:37 -0700 Subject: [Nitro] REPO updated. In-Reply-To: References: Message-ID: I'm going to send this to the list as a patch to see if I can get some feedback. Although, if you've tried it out and can supply some, it'd be greatly appreciated as it'd save me some time. Thanks. On 4/3/06, Bryan Soto wrote: > With the sqlite test fix, the Og test suite completes with Mysql and > Sqlite. Postgres dies with this error: > > E, [2006-04-03T16:33:43.617072 #10799] ERROR -- : DB error ERROR: > relation "ogj_tcogstore_category_tcogstore_newarticle" does not exist > , [INSERT INTO ogj_tcogstore_category_tcogstore_newarticle > (category_oid,newarticle_oid) VALUES (1, 1)] > > The problem seems to be that it is creating join tables in a different > manner than the other stores. Where Mysql is using: > > if join_tables = klass.ann.self[:join_tables] > > Postgres does: > > join_tables = klass.relations.reject{|rel| !rel.join_table}.map{|rel| > join_table_info(rel)} > > Changing that line makes the test suite fail later on in taggable. I > don't know Postgres well enough to want to make the change though > especially as I don't know where the code originated from, though I'm > guessing probably Rob. I can only go by what the tests tell me. So, > can anyone comment on this one? > > Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Wed Apr 5 17:55:12 2006 From: transfire at gmail.com (TRANS) Date: Wed, 5 Apr 2006 17:55:12 -0400 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly In-Reply-To: References: Message-ID: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Not sure what your solution was. I notice the suggeston of using: "#{klass.to_s.demodulize.underscore.downcase}_oid" I think #demodulize is really a misnomer. It is just an alias for #basename (and was derived from Rails). So you loose the module namespace of the class. Perhaps that it's what it desired, but might it not be dangerous? class Red::Fish class Blue::Fish Will both map to table 'fish', yes? If that's not what is wanted, you might try: "#{klass.to_s.methodize}_oid" #methodize is actually the opposite of modulize --hence why I think demodulize is a misnomer. T. From bryan.a.soto at gmail.com Wed Apr 5 18:21:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 15:21:08 -0700 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly In-Reply-To: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> References: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Message-ID: My solution was merely to generate the names in a consistent way. Two different sections of code were arriving at a name in two different ways. I chose to copy the way the field name was being created. :) > "#{klass.to_s.demodulize.underscore.downcase}_oid" We really need to structure things better. There should be only one place names are created. Anyway, this is in regards to field names, not tables. I'm assuming this means losing the module info isn't an issue since past Og didn't use module names in fields. Though if someone can supply a test case or something to show this is wrong, I'll cheerfully pull the patch. This just happened to be the simplest thing I found to make the test case pass. Are there any other thoughts on this? Perhaps I arrived at the wrong solution? No one had any objections or comments, so I just went ahead and applied it since it fixed a bug and closed a ticket. Thanks, Bryan On 4/5/06, TRANS wrote: > Not sure what your solution was. I notice the suggeston of using: > > "#{klass.to_s.demodulize.underscore.downcase}_oid" > > I think #demodulize is really a misnomer. It is just an alias for > #basename (and was derived from Rails). So you loose the module > namespace of the class. Perhaps that it's what it desired, but might > it not be dangerous? > > class Red::Fish > > class Blue::Fish > > Will both map to table 'fish', yes? > > If that's not what is wanted, you might try: > > "#{klass.to_s.methodize}_oid" > > #methodize is actually the opposite of modulize --hence why I think > demodulize is a misnomer. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From james_b at neurogami.com Wed Apr 5 18:52:35 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 05 Apr 2006 15:52:35 -0700 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604051032m7c424efaq6f6ca7b66a77cd9d@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> <4b6f054f0604051032m7c424efaq6f6ca7b66a77cd9d@mail.gmail.com> Message-ID: <44344A33.3030204@neurogami.com> TRANS wrote: > On 4/5/06, TRANS wrote: > >>>facets, '~> 1.2' # This assumes that anything that changes >>>interface will be 2.0+ >> >>Hmm... it's not up to 1.3+? Well if not then I think make it >> >> facets, '~> 1.2.0' >> >>Tell me if you think I've misjudged on this, but my reasoning is that >>Facets has so many libs that any _one_ interface change in any _one_ >>of them requires a version jump and I don't want to be pushing version >>5.0+ just b/c of four such changes. > > > Okay, there's two side to this coin. You want to loosen the constraint > on Nitro's dependencies to allows Facets or other dependency to be > updated and Nitro use the latest. Well, it's a tow edge sword. You may > run into some issures now to make sure Nitro is picking up the right > version, but you could also run into trouble later if something > changes that effects Nitro adversely. > > Personally I lean towards George's opinion. Keep strict version control. That can work, but I think then the gem packaging may need some tightening up, because gen, for example, didn't force the installation of a specific facets gem, but it (or something in it's requirement chain) would complain when I ran it. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From transfire at gmail.com Wed Apr 5 20:05:48 2006 From: transfire at gmail.com (TRANS) Date: Wed, 5 Apr 2006 20:05:48 -0400 Subject: [Nitro] Gem dependencies. In-Reply-To: References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> Message-ID: <4b6f054f0604051705m3eb77e34ida08f7b6c4c478c2@mail.gmail.com> On 4/5/06, Bryan Soto wrote: > On 4/5/06, TRANS wrote: > > > facets, '~> 1.2' # This assumes that anything that changes > > > interface will be 2.0+ > > > > Hmm... it's not up to 1.3+? Well if not then I think make it > > > > I deleted a long explanation because I thought of a concise way to put > it. The assumption is, If you have to change your tests or old code to > make things work (excluding changes made to accommodate a bug), you > should bump your major version. > > Basically, that dependency assumes that anything in the 1.x range will > be backwards compatible in the interface. Not in the implementation or > bug-wise. > > > facets, '~> 1.2.0' > > > > Tell me if you think I've misjudged on this, but my reasoning is that > > Facets has so many libs that any _one_ interface change in any _one_ > > of them requires a version jump and I don't want to be pushing version > > 5.0+ just b/c of four such changes. > > > > Perhaps it'd be best if you explain your version scheme in terms of > backwards compatibility. Will 1.3 not be backwards compatible to 1.2? > If that is the case, then you're probably right about 'facets ~> > 1.2.0'. At least if you explain how you plan to version, we can figure > out how to depend on it from there. Yea, Facets is a little special b/c it is a large collection of lots of little libs. So it's less black-and-white when it comes to versioning. For instance, The lastest release had a method 'kernel/meta' which I tried changing to 'kernel/instance', but Ara astutely suggested I call it '__self__' which I will. So it's just one method and not a commonly used one either, but nontheless it consititutes an interface change. Because there so much in there it's just a lot more likely for there to be some sort of interface change for any given release.* B/c of this versioning for Facets I think needs to be: major for major interface change, minor for minor interface changes and teeny is no interface change. Does that sound reasonble? Hmm... I guess that means I need to bump to 1.3 for the next version. T. * This is also why I had flirted with date-based versions, btw. From bryan.a.soto at gmail.com Wed Apr 5 20:32:50 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 17:32:50 -0700 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604051705m3eb77e34ida08f7b6c4c478c2@mail.gmail.com> References: <55c107bf0604050029i33df00aavc797033b0655a51f@mail.gmail.com> <4b6f054f0604050410k798648o7b4a30076f428b50@mail.gmail.com> <4b6f054f0604051705m3eb77e34ida08f7b6c4c478c2@mail.gmail.com> Message-ID: On 4/5/06, TRANS wrote: > On 4/5/06, Bryan Soto wrote: > > On 4/5/06, TRANS wrote: > Yea, Facets is a little special b/c it is a large collection of lots > of little libs. So it's less black-and-white when it comes to > versioning. > > For instance, The lastest release had a method 'kernel/meta' which I > tried changing to 'kernel/instance', but Ara astutely suggested I call > it '__self__' which I will. So it's just one method and not a commonly > used one either, but nontheless it consititutes an interface change. > I see your point. I was thinking in terms of methods, but files are just as much a part of the interface. When I think of it like that, it makes more sense why you tried to get away from file requires a while back. > Because there so much in there it's just a lot more likely for there > to be some sort of interface change for any given release.* B/c of > this versioning for Facets I think needs to be: major for major > interface change, minor for minor interface changes and teeny is no > interface change. Does that sound reasonble? > That does. Given your description, you're probably right. So the dependency for facets, if we do change them, would be 'facets ~> 1.2.0'. > Hmm... I guess that means I need to bump to 1.3 for the next version. > Well, I suppose you could create a placeholder file and mark it as deprecated. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 6 01:22:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 22:22:07 -0700 Subject: [Nitro] [PATCH] og-postgres-join-tables Message-ID: * og-postgres-join-tables Patch modifies the way Postgres accesses join table info to match other stores. ~~~ Could you postgres people give this a whirl and see if it breaks anything? It makes the test suite run better so that's what I'm basing this off of. This is with postgres 8.1. Thanks in advance for any help. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-postgres-join-tables.zip Type: application/zip Size: 13388 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060406/b844dfbf/attachment.zip From bryan.a.soto at gmail.com Thu Apr 6 02:22:22 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 5 Apr 2006 23:22:22 -0700 Subject: [Nitro] Postgres failures in Og test suite. Message-ID: Because some of the tickets/patches we have are specifically for the Postgres store, I need the test suite running so I know if they break things. And so, I begin my new project. With the postgres join table patch I sent earlier, I get to here. E, [2006-04-05T22:23:56.328000 #4784] ERROR -- : DB error ERROR: column "o.title" must appear in the GROUP BY clause or be used in an aggregate function, [ SELECT o.* FROM ogglue_tag AS t, ogtestogtaggable_article as o, ogj_glue_tag_testogtaggable_article as j WHERE o.oid = j.article_oid AND t.oid = j.tag_oid AND (t.name in ('navel','gmosx')) GROUP BY j.article_oid HAVING COUNT(j.article_oid) = 2; ] Google explained to me that Postgres is a stickler and that it requires the o.* fields to be in the group by clause. I don't know that we have access to this info in taggable. That'll be the first way I try to solve this, but perhaps there is a trick to make this work one of you Postgres wizards know? A snippet of the backtrace from the above: E, [2006-04-05T23:08:14.000000 #6132] ERROR -- : K:/nitro.pristine/og/lib/og/sto re/psql.rb:293:in `exec' K:/nitro.pristine/og/lib/og/store/psql.rb:293:in `query' K:/nitro.pristine/og/lib/og/store/sql.rb:484:in `select' K:/nitro.pristine/og/lib/og/entity.rb:217:in `select' K:/nitro.pristine/og/lib/glue/taggable.rb:189:in `find_with_tags' ./test/og/mixin/tc_taggable.rb:48:in `test_all' I renamed the file to keep the test from running and then I got the suite to pass with the following results. 1) Error: test_all(TC_OgAggrCalc): NoMethodError: undefined method `to_f' for ["58"]:Array K:/nitro.pristine/og/lib/og/store/sql.rb:532:in `calculate' K:/nitro.pristine/og/lib/og/store/psql.rb:139:in `each_row' K:/nitro.pristine/og/lib/og/store/psql.rb:138:in `each_row' K:/nitro.pristine/og/lib/og/store/sql.rb:531:in `calculate' K:/nitro.pristine/og/lib/og/entity.rb:267:in `calculate' K:/nitro.pristine/og/lib/og/entity.rb:305:in `sum' ./test/og/tc_aggregations_calculations.rb:39:in `test_all' 2) Failure: test_all(TC_OgInheritance) [./test/og/tc_inheritance.rb:87]: expected but was . 3) Failure: test_sti_all(TC_Sti_OgType) [./test/og/store/tc_sti.rb:89]: <2> expected but was <0>. 4) Failure: test_all(TestMultiple) [./test/og/tc_multiple.rb:37]: is not true. 43 tests, 216 assertions, 3 failures, 1 errors The failure in number 4 is an incorrect test, in my opinion, and should be removed. But the rest aren't. Anyway, if someone has nothing to do, please help a postgres novice. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From zimba.tm at gmail.com Thu Apr 6 03:01:18 2006 From: zimba.tm at gmail.com (zimba.tm) Date: Thu, 6 Apr 2006 09:01:18 +0200 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly In-Reply-To: References: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Message-ID: <200604060901.18499.zimba.tm@gmail.com> On Thursday 06 April 2006 00:21, Bryan Soto wrote: > My solution was merely to generate the names in a consistent way. Two > different sections of code were arriving at a name in two different > ways. I chose to copy the way the field name was being created. :) > > > "#{klass.to_s.demodulize.underscore.downcase}_oid" > > We really need to structure things better. There should be only one > place names are created. I have created the methodize/modulize/pathize methods to allow building strings from class names and invertly in a consistant way. Eg. x = ThisIs::MyClass.to_s.methodize #=> this_is__my_class as you can see, every Upcase letter is prepended by a _ , this allows to rebuild the class name without loosing this information. For example URI.name.methodize would give "u_r_i". The first letter is always Upcased according to the ruby convension, so I didn't need to prepend it with the underscore character. You can then get the constant back by using facet/kernel/constant with #modulize, which allows to recusively get constants (with the full namespace). For now, those methods only transform class names to method names or unix paths. I could also add the support for method names like : "MyClass#my_method".methodize #=> ??? or "#{klass}#oid".methodize #=> ??? -- Cheers, zimba.tm weblog : http://zimba.oree.ch From vseguip at gmail.com Thu Apr 6 03:37:42 2006 From: vseguip at gmail.com (vseguip at gmail.com) Date: Thu, 6 Apr 2006 09:37:42 +0200 Subject: [Nitro] properties In-Reply-To: References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> Message-ID: > Final outcome: Matz^H^H^H^HGeorge is open to renaming, but doesn't > like any of the suggestions so far. Ever get that weird deja vu > feeling? > I think that if we are going to finally ditch the properties dictionary we might as well rename it to something else "properties_dict" meanwhile. It really doesn't matter that much because it will be aliased to "properties" anyway and we well end up ditching it. What do you think George? Cheers, V. Segu? From kashia at vfemail.net Thu Apr 6 03:47:35 2006 From: kashia at vfemail.net (Kashia Buch) Date: Thu, 06 Apr 2006 09:47:35 +0200 Subject: [Nitro] Postgres failures in Og test suite. In-Reply-To: References: Message-ID: On Thu, 06 Apr 2006 08:22:22 +0200, Bryan Soto wrote: > Because some of the tickets/patches we have are specifically for the > Postgres store, I need the test suite running so I know if they break > things. And so, I begin my new project. > > With the postgres join table patch I sent earlier, I get to here. > > E, [2006-04-05T22:23:56.328000 #4784] ERROR -- : DB error ERROR: > column "o.title" must appear in the GROUP BY clause or be used in an > aggregate function, [ > SELECT o.* > FROM > ogglue_tag AS t, > ogtestogtaggable_article as o, > ogj_glue_tag_testogtaggable_article as j > WHERE o.oid = j.article_oid > AND t.oid = j.tag_oid > AND (t.name in ('navel','gmosx')) > GROUP BY j.article_oid > HAVING COUNT(j.article_oid) = 2; > ] This must be from taggable, right?... I remember having to work around a problem there, but I wasn't sure weither that was the fault of this one or my DB layout. SELECT * FROM ogquestion WHERE ogquestion.oid IN (SELECT question_oid FROM ogglue_tag JOIN ogj_glue_tag_question ON tag_oid = ogglue_tag.oid WHERE (ogglue_tag.name IN (#{names}) ) GROUP BY question_oid HAVING COUNT(question_oid) = #{count}); now... how to integrate that into taggable? This approach works for me, but I'm not really sure weither this does exactly the same as the one above (although it should). It gets all "ogquestion" where the ogquestion oid is in the sub- query in which the join between the two tag tables happens. Basically the same as above... (I think), I'm just not good enough to be able to grok three joins at once it seems ^^; > Google explained to me that Postgres is a stickler and that it > requires the o.* fields to be in the group by clause. I don't know > that we have access to this info in taggable. That'll be the first way > I try to solve this, but perhaps there is a trick to make this work > one of you Postgres wizards know? no wizard here, I can only stick some queries together and make them work the way I want them to ^^; I wish I had some deeper insight.. I'll work on the cleaned version for taggable, give me an hour or so.. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From vagabond at cataclysm-software.net Thu Apr 6 09:44:25 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Thu, 06 Apr 2006 09:44:25 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... Message-ID: <44351B39.4020904@cataclysm-software.net> I've been trying to get a nitro app running on an apache server but NOT at the document root, I need something like www.example.com/myapp to be where you go to get into the application. I can't seem to find any docs on this, but Nitro::Dispatcher::ROOT looks like it might relate to what I need but I can't decide how exactly it works Basicially I need the dispatcher to do the following: Allow me to set the base path that nitro will always get in the URL (in this case /myapp). If you do a redirect, it'd add this to the beginning of the URL(? to make sure things match up, or make it so it doesn't matter) I've actually hacked something in that kinda does this, but nitro is having problems locating the template files... Is there a builtin way to do this already? Andrew From itsme213 at hotmail.com Thu Apr 6 09:44:27 2006 From: itsme213 at hotmail.com (itsme213) Date: Thu, 6 Apr 2006 08:44:27 -0500 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are nothandled correctly References: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Message-ID: "Bryan Soto" wrote in message > We really need to structure things better. There should be only one > place names are created. don't have in-depth knowledge of code base Would it not be be better if all the og macros simply recorded the meta-data without any database code decisions? The database (or other) code can be generated at the end. Name ambiguities, short names, inferrable names (e.g. inverses and foreign keys), etc. can all be done most effectively at that point. From kashia at vfemail.net Thu Apr 6 10:44:18 2006 From: kashia at vfemail.net (Kashia Buch) Date: Thu, 06 Apr 2006 16:44:18 +0200 Subject: [Nitro] Postgres failures in Og test suite. In-Reply-To: References: Message-ID: Hi, damn, I can't seem to be able to run the test-suite -_- sql = %{ SELECT * FROM #{info[:owner_table]} AS o WHERE o.oid IN ( SELECT j.#{info[:owner_key]} FROM #{info[:target_table]} AS t JOIN #{info[:table]} AS j ON t.oid = j.#{info[:target_key]} WHERE (t.name IN (#{names}) ) GROUP BY j.#{info[:owner_key]} } Here you go, I think that should work, could you test it (testsuite or with a real project), I can't test it right now. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From reid.thompson at ateb.com Thu Apr 6 12:10:20 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Thu, 06 Apr 2006 12:10:20 -0400 Subject: [Nitro] Errors with Og and existing table/data In-Reply-To: References: <4431C548.50204@ateb.com> Message-ID: <44353D6C.2040700@ateb.com> Bryan Soto wrote: > On 4/3/06, Reid Thompson wrote: > >> given.. >> testexisting=# create table testtable(mytext text primary key, mynumber >> integer, yourtext text); >> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index >> "testtable_pkey" for table "testtable" >> CREATE TABLE >> testexisting=# \d testtable; >> Table "public.testtable" >> Column | Type | Modifiers >> ----------+---------+----------- >> mytext | text | not null >> mynumber | integer | >> yourtext | text | >> Indexes: >> "testtable_pkey" PRIMARY KEY, btree (mytext) >> >> what am I missing in the program below that is causing the save to fail >> with >> error:/usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/connection.rb:115:in >> `query': ERROR C42601 Msyntax error at or near "new" P81 >> Fscan.l L761 Ryyerror (RuntimeError) >> from >> /usr/local/lib/ruby/gems/1.8/gems/postgres-pr-0.4.0/lib/postgres-pr/postgres-compat.rb:33:in >> `exec' >> from >> /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/psql.rb:307:in >> `sql_update' >> from (eval):6:in `og_update' >> from >> /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:102:in `save' >> from >> /usr/local/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' >> from ogexisting.rb:35 >> ) >> ------------------------------------------- >> require 'og' >> >> class Testtable >> include Og::EntityMixin >> >> property :mytext, String, Og::NotNull >> property :mynumber, Fixnum >> property :yourtext, String >> >> set_table :testtable >> set_primary_key :mytext, String >> end >> >> og_psql = { >> :destroy_tables => false, # don't use this on a DB with tables that >> you DO NOT want to lose -- or set to false >> :store => :psql, >> :user => 'rthompso', >> :password => 'rthompso', >> :name => 'testexisting' >> } >> >> Og.table_prefix = '' # remove og generated table prefix >> > > Could you add the line below and re-run? We might get better info if > we see the sql that is generated. Unfortunately I'm not a postgres > user, so I can't easily replicate this. Hopefully someone more > familiar with it will chime in... > > $DBG = true > > >> db = Og.setup(og_psql) >> >> # if there are pre-existing recoreds, this DOES retrieve and print them >> mystore = db.store >> res = mystore.query("select * from testtable") >> res.each {|rec| >> puts rec >> } >> >> a=Testtable.new >> a.mynumber = 34 >> a.yourtext = 'some new your text' >> a.mytext ='my new text' >> a.save # failure here >> >> res = mystore.query("select * from testtable") >> res.each {|rec| >> puts rec >> } >> >> > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > Hmm.. why is it attempting to do an update, rather than an insert? Using a pre-existing table does not restrict you to ONLY updating existing data does it???? And the where clause is not quoted.... I, [2006-04-06T12:04:46.426000 #2500] INFO -- : Og uses the Psql store. D, [2006-04-06T12:04:47.614000 #2500] DEBUG -- : Og manageable classes: [Testtable] D, [2006-04-06T12:04:47.629000 #2500] DEBUG -- : Table testtable already exists D, [2006-04-06T12:04:47.661000 #2500] DEBUG -- : PostgreSQL processing foreign key constraints D, [2006-04-06T12:04:47.661000 #2500] DEBUG -- : PostgreSQL finished setting constraints. No action was taken in 0.00 seconds. D, [2006-04-06T12:04:47.661000 #2500] DEBUG -- : select * from testtable D, [2006-04-06T12:04:47.661000 #2500] DEBUG -- : UPDATE testtable SET mynumber=34, yourtext='some new your text' WHERE mytext=my new text c:/ruby/lib/ruby/gems/1.8/gems/postgres-pr-0.3.6/lib/postgres-pr/connection.rb:115:in `query': ERROR C42601 Msyntax error at or near "new" P81 Fscan.l L761 Ryyerror (RuntimeError) from c:/ruby/lib/ruby/gems/1.8/gems/postgres-pr-0.3.6/lib/postgres-pr/postgres-compat.rb:32:in `exec' from c:/ruby/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/psql.rb:307:in `sql_update' from (eval):6:in `og_update' from c:/ruby/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:102:in `save' from c:/ruby/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' from C:/cygwin/home/rthompso/rbB1.tmp:36 Completed(1) From transfire at gmail.com Thu Apr 6 13:41:15 2006 From: transfire at gmail.com (TRANS) Date: Thu, 6 Apr 2006 13:41:15 -0400 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are nothandled correctly In-Reply-To: References: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Message-ID: <4b6f054f0604061041m2a5acd85j7b504ed941390846@mail.gmail.com> On 4/6/06, itsme213 wrote: > > "Bryan Soto" wrote in message > > > We really need to structure things better. There should be only one > > place names are created. > > don't have in-depth knowledge of code base > > Would it not be be better if all the og macros simply recorded the meta-data > without any database code decisions? > > The database (or other) code can be generated at the end. Name ambiguities, > short names, inferrable names (e.g. inverses and foreign keys), etc. can all > be done most effectively at that point. Well put. That's exaclty the direction I've been trying to encouge. T. From bryan.a.soto at gmail.com Thu Apr 6 15:29:13 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 12:29:13 -0700 Subject: [Nitro] [PATCH]: og-postgres-sti-fix Message-ID: 2) Failure: test_all(TC_OgInheritance) [./test/og/tc_inheritance.rb:87]: expected but was . 3) Failure: test_sti_all(TC_Sti_OgType) [./test/og/store/tc_sti.rb:89]: <2> expected but was <0>. Attached patch corrects these. The problem lay in psql.rb in eval_og_allocate. It was improperly checking to see if a class was STI. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-postgres-sti-fix.zip Type: application/zip Size: 13372 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060406/cc31e1ce/attachment.zip From bryan.a.soto at gmail.com Thu Apr 6 15:41:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 12:41:53 -0700 Subject: [Nitro] Postgres failures in Og test suite. In-Reply-To: References: Message-ID: On 4/6/06, Kashia Buch wrote: > Hi, > > damn, I can't seem to be able to run the test-suite -_- > Exactly ;) Seriously though, if you use the patches I've sent so far, the taggable test is the only thing stopping it from running. > sql = %{ > SELECT * > FROM #{info[:owner_table]} AS o > WHERE o.oid IN ( > SELECT j.#{info[:owner_key]} > FROM #{info[:target_table]} AS t > JOIN #{info[:table]} AS j > ON t.oid = j.#{info[:target_key]} > WHERE (t.name IN (#{names}) > ) > GROUP BY j.#{info[:owner_key]} > } > > Here you go, I think that should work, could you test it (testsuite > or with a real project), I can't test it right now. > A subselect, huh... I wonder how portable that is. I guess if we can't find something that works across all databases we'll have to make the query used conditional based off the store type... Thanks for the query. I'll see what I can do with it. Could a postgres user try my patches out? I don't have any Og projects in Postgres so I can't test them against an existing database. I just want to make sure they don't hurt anything if I apply them to the repo. I think I'm just fixing failing tests, but I can't verify that I'm not breaking things for Postgres users. Thanks -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From george.moschovitis at gmail.com Thu Apr 6 16:07:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Apr 2006 22:07:23 +0200 Subject: [Nitro] [PATCH][BUGFIX] Camel cases in class names are nothandled correctly In-Reply-To: References: <4b6f054f0604051455g162da012he7fced7f6ea5c796@mail.gmail.com> Message-ID: > don't have in-depth knowledge of code base > > Would it not be be better if all the og macros simply recorded the meta-data > without any database code decisions? > > The database (or other) code can be generated at the end. Name ambiguities, > short names, inferrable names (e.g. inverses and foreign keys), etc. can all > be done most effectively at that point. this is more or less how it works. Og 'enchanting' is a 2 phase process, first metadata is collected, then backend specific code is generated. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Apr 6 16:12:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Apr 2006 22:12:18 +0200 Subject: [Nitro] Controller resolution order In-Reply-To: References: <440C65DC.7090200@cataclysm-software.net> Message-ID: > Just a reminder on this one. I had been thinking of just having it > match the longest possible mount point. But I'd be interested in your > explanation if you don't have time to write any code. Will do this over the weekend (it matches the longest mount point as you say). -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Apr 6 16:19:04 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Apr 2006 22:19:04 +0200 Subject: [Nitro] Gem dependencies. In-Reply-To: References: Message-ID: > chat log, George is looking to release this week, so I'm thinking we > should delay that till after this release. Saddly not this week, lets aim for something like 15th April. I have to release a small nitro powered app over the weekend, plus I would like to work over those tickets and test a bit the repo version. I would also like to review Tom's glue->facets changes (this was useful and hard work). regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From aglarond at gmail.com Thu Apr 6 16:21:05 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Thu, 6 Apr 2006 22:21:05 +0200 Subject: [Nitro] STI a mistake in PostgreSQL? Message-ID: <55c107bf0604061321g623200e3r1bc8a06e749369f2@mail.gmail.com> Hi, Seeing all these errors pop-up w.r.t. patches and the PostgreSQL store, I ask myself if STI is really appropriate for a PostgreSQL database? PostgreSQL is one of (the few | the only?) relational database that I know of to actually support inheritance. I've used this in my legacy apps (which I've been meaning for a good long time now, to convert over to Nitro/Og...) without a problem. You can create a Person table with certain attributes. Then create a Customer table, with additional attributes, inheriting the ones already defined in Person. You can then do a select over all Customers, filtering on attributes defined in Person. Anyone else have experience here? Do you guys over at motionpath use the inheritance feature of PostgreSQL? Before I convert my legacy apps over, I'd like to see this kind of support in Og. And, yes, I know that patches are welcome. :) - Dimitri From george.moschovitis at gmail.com Thu Apr 6 16:22:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Apr 2006 22:22:23 +0200 Subject: [Nitro] PATCH: adds params to AJAX helper generated functions. In-Reply-To: References: <1143279160.3992.15.camel@nissl.mammuth> Message-ID: good... On 4/5/06, Bryan Soto wrote: > I've applied. Thanks for the patch Massimo. > > On 4/4/06, Bryan Soto wrote: > > If there are no objections, I'm going to apply this. > > > > On 3/25/06, Massimo Maria Ghisalberti wrote: > > > in my opinion, but this patch is mine ;) > > > > > > it is useful because I need to have the id of the element that send > > > click event (for dispatching to a single page method handler), but in > > > general a javascript event handler will must to have an object event as > > > first parameter, in special case for mozilla browser where the object > > > event is internal to event handler, not is the case of IE where exist a > > > global window.event. > > > > > > the right js generated will must be (pseudo): > > > > > > event_handler_function(event, param){ > > > > > > var Ev; > > > if (window.event) > > > Ev = event = window.event > > > else > > > Ev = event > > > ... > > > handler code > > > ... > > > } > > > > > > in the single param you can pass any sort of data... simple type or > > > complete object, obviously is you responsability to handle this right. > > > > > > ciao > > > > > > Massimo > > > > > > Il giorno sab, 25/03/2006 alle 00.06 -0800, Bryan Soto ha scritto: > > > > Adds code submitted via mailing list and a testcase. > > > > > > > > See http://rubyforge.org/pipermail/nitro-general/2006-March/003453.html > > > > for more info. > > > > > > > > I wanted to get some more opinions on this one. > > > > > > > > Thanks. > > > > > > > > -- > > > > "Never tell people how to do things. Tell them what to do and they > > > > will surprise you with their ingenuity." ?General George S. Patton > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > > > Massimo Maria Ghisalberti > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Thu Apr 6 17:00:40 2006 From: transfire at gmail.com (TRANS) Date: Thu, 6 Apr 2006 17:00:40 -0400 Subject: [Nitro] STI a mistake in PostgreSQL? In-Reply-To: <55c107bf0604061321g623200e3r1bc8a06e749369f2@mail.gmail.com> References: <55c107bf0604061321g623200e3r1bc8a06e749369f2@mail.gmail.com> Message-ID: <4b6f054f0604061400m6977570foe82af9a31a025cce@mail.gmail.com> I imagine supporting PostgreSQL's inheritance would require very strong S.O.C. in the stores. I'm not sure how hard it would be to implement, my guess is it would not be easy and would have effects on the rest of the stores too. But if it could be done (without being a hack) I bet it would make Og a much stronger ORM system on the whole. Just a thought, T. From transfire at gmail.com Thu Apr 6 17:10:00 2006 From: transfire at gmail.com (TRANS) Date: Thu, 6 Apr 2006 17:10:00 -0400 Subject: [Nitro] Gem dependencies. In-Reply-To: References: Message-ID: <4b6f054f0604061410w44cd0db8y78239ecce8be07b@mail.gmail.com> > (this was useful and hard work). Nah, I wouldn't call it "hard", but it was time consuming. ;-) Once the bulk transfer is complete, I can start moving pieces over to Facets a little at a time. That way there won't be numerous changes all at once and releases can continue to flow smoothly. T. From bryan.a.soto at gmail.com Thu Apr 6 17:56:27 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 14:56:27 -0700 Subject: [Nitro] Gem dependencies. In-Reply-To: <4b6f054f0604061410w44cd0db8y78239ecce8be07b@mail.gmail.com> References: <4b6f054f0604061410w44cd0db8y78239ecce8be07b@mail.gmail.com> Message-ID: On 4/6/06, TRANS wrote: > > (this was useful and hard work). > > Nah, I wouldn't call it "hard", but it was time consuming. ;-) > > Once the bulk transfer is complete, I can start moving pieces over to > Facets a little at a time. That way there won't be numerous changes > all at once and releases can continue to flow smoothly. > Since we're delaying the release, then, by all means, let's see if we can get this in. I'll try it out and see what it breaks. Trans, I hope you'll be around if I have questions. :) For you experienced darcs users out there, is something like this best done in one bundle or several small ones? For context, we're going to be removing glue. All the glue files will be moved to either og or nitro. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 6 19:00:42 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 16:00:42 -0700 Subject: [Nitro] Errors with Og and existing table/data In-Reply-To: <44353D6C.2040700@ateb.com> References: <4431C548.50204@ateb.com> <44353D6C.2040700@ateb.com> Message-ID: On 4/6/06, Reid Thompson wrote: > Hmm.. why is it attempting to do an update, rather than an insert? > Using a pre-existing table does not restrict you to ONLY updating > existing data does it???? > This one I'm not sure, but I suspect if you placed p a.saved?; exit before your call to a.save, you'd get an empty string which happens to evalutate to true in Ruby. This makes Og think it's a saved object and so it tries to update it. > And the where clause is not quoted.... > And this seems to be because eval_og_allocate assumes that the key is a number, not a string. I think I can duplicate this and create a test case. I doubt it's specific to Postgres either. For your sanity, I think these are both bugs. Thank you for finding and reporting. Now let's see if I can fix them... -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 6 19:19:16 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 16:19:16 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <44351B39.4020904@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> Message-ID: On 4/6/06, Andrew Thompson wrote: > I've been trying to get a nitro app running on an apache server but NOT > at the document root, I need something like www.example.com/myapp to be > where you go to get into the application. I can't seem to find any docs > on this, but Nitro::Dispatcher::ROOT looks like it might relate to what > I need but I can't decide how exactly it works > > Basicially I need the dispatcher to do the following: > > Allow me to set the base path that nitro will always get in the URL (in > this case /myapp). > If you do a redirect, it'd add this to the beginning of the URL(? to > make sure things match up, or make it so it doesn't matter) > With Apache, I ended up just using mod_rewrite and serving via a virtual host. Might you be able to share your hacking? :) > > I've actually hacked something in that kinda does this, but nitro is > having problems locating the template files... Is there a builtin way to > do this already? > I'm not sure, but perhaps what was outlined by Gergley might help? He manipulated a controller class instance variable called @template_root. See here for more info. http://rubyforge.org/pipermail/nitro-general/2006-March/003643.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Thu Apr 6 19:48:46 2006 From: transfire at gmail.com (TRANS) Date: Thu, 6 Apr 2006 19:48:46 -0400 Subject: [Nitro] Gem dependencies. In-Reply-To: References: <4b6f054f0604061410w44cd0db8y78239ecce8be07b@mail.gmail.com> Message-ID: <4b6f054f0604061648m3af99088u964c7afd8a586aba@mail.gmail.com> I'm here, ready and willing! T. From bryan.a.soto at gmail.com Thu Apr 6 20:01:28 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 17:01:28 -0700 Subject: [Nitro] STI a mistake in PostgreSQL? In-Reply-To: <4b6f054f0604061400m6977570foe82af9a31a025cce@mail.gmail.com> References: <55c107bf0604061321g623200e3r1bc8a06e749369f2@mail.gmail.com> <4b6f054f0604061400m6977570foe82af9a31a025cce@mail.gmail.com> Message-ID: On 4/6/06, TRANS wrote: > I imagine supporting PostgreSQL's inheritance would require very > strong S.O.C. in the stores. I'm not sure how hard it would be to > implement, my guess is it would not be easy and would have effects on > the rest of the stores too. But if it could be done (without being a > hack) I bet it would make Og a much stronger ORM system on the whole. > > Just a thought, > And a good thought. We just need to clean up the interface, move all the heavy lifting to sql.rb and make the adapters just do the database specific stuff. Currently, that's not exactly the case. Besides, a well defined interface would make it easier to add support for new databases like Oracle or MS Sql. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 6 21:02:04 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 18:02:04 -0700 Subject: [Nitro] Postgres failures in Og test suite. In-Reply-To: References: Message-ID: On 4/6/06, Bryan Soto wrote: > On 4/6/06, Kashia Buch wrote: > > sql = %{ > > SELECT * > > FROM #{info[:owner_table]} AS o > > WHERE o.oid IN ( > > SELECT j.#{info[:owner_key]} > > FROM #{info[:target_table]} AS t > > JOIN #{info[:table]} AS j > > ON t.oid = j.#{info[:target_key]} > > WHERE (t.name IN (#{names}) > > ) > > GROUP BY j.#{info[:owner_key]} > > } > > Thanks Kashia, I just needed to add a closing parenthesis. I'm going to see if subselects work with sqlite and mysql, if not I'm just going to make it conditional. One way or the other, I should be sending out a postgres patch tonight. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Thu Apr 6 21:04:41 2006 From: transfire at gmail.com (TRANS) Date: Thu, 6 Apr 2006 21:04:41 -0400 Subject: [Nitro] Up Dev Proc Message-ID: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> It would be interesting to try to "up" the whole developement process. What could be done to significantly boost project development? I'd like to hear others ideas irregardless of the idea I'm about to present --so if you have any notions in mind at this point STOP READING. Email them and then come back and finish. . . . . . . So here's my "crazy" idea. What do you think of turning development inside out. By, "inside out", which is especially apt with regard to Nitro, I mean why not make a sort of nitro-based develpoment wiki. Have all of the source available on this website where people can literally edit the code on the spot --right through the web interface. Now what would happen is that every person who signs-up gets their own darcs branch on the server. They can make changes and so forth and then record them as usual but through the web interface. (Of course you could still work on it the traditional way too and upload your changes if you want/need). You can also run the tests remotely. And even have them run automatically overnight. We could automate a lot of things. Then integrate changes to a master repo more easily. The idea is to really open up access to development. This could really improve involvement. And actually would be a nice demonstration of the power of Nitro. (Hell, it could even lead to some sort of real business model.) It could also help team development. Maybe using Ajax, pair coding would even be possible. And given that a Wordprocesser has actually been with Web 2.0, why not a code editor? And so on....I'm sure your imagination can fill in the plenty more. What do others think? T. From james_b at neurogami.com Thu Apr 6 23:15:11 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 06 Apr 2006 20:15:11 -0700 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> Message-ID: <4435D93F.9040701@neurogami.com> TRANS wrote: > > So here's my "crazy" idea. > > What do you think of turning development inside out. By, "inside out", > which is especially apt with regard to Nitro, I mean why not make a > sort of nitro-based develpoment wiki. Have all of the source available > on this website where people can literally edit the code on the spot > --right through the web interface. > ... I'm not sure I quite understand the set up, but I like it. :) Two things are appealing: Eating one's own dog food, and making it easier to run and poke at cutting-edge code, where others can poke at it, too. Quite educational. (Actually, it could be some sort of avant garde Og/Nitro Ning. Would be interesting if it could reasonably sandboxed a la Try Ruby, but not so it crippled core behavior. Web IDE + Nitro + darcs + user-mode Linux ... ) -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From reid.thompson at ateb.com Fri Apr 7 00:26:07 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Fri, 07 Apr 2006 00:26:07 -0400 Subject: [Nitro] Errors with Og and existing table/data In-Reply-To: References: <4431C548.50204@ateb.com> <44353D6C.2040700@ateb.com> Message-ID: <4435E9DF.9020700@ateb.com> Bryan Soto wrote: > On 4/6/06, Reid Thompson wrote: > >> Hmm.. why is it attempting to do an update, rather than an insert? >> Using a pre-existing table does not restrict you to ONLY updating >> existing data does it???? >> >> > > This one I'm not sure, but I suspect if you placed > > p a.saved?; exit > > before your call to a.save, you'd get an empty string which happens to > evalutate to true in Ruby. This makes Og think it's a saved object and > so it tries to update it. > I'll try to make time to verify this and respond > >> And the where clause is not quoted.... >> >> > > And this seems to be because eval_og_allocate assumes that the key is > a number, not a string. > that thought crossed my mind - I would be willing to re-test if it's needed. > I think I can duplicate this and create a test case. I doubt it's > specific to Postgres either. > > For your sanity, I think these are both bugs. Thank you for finding > and reporting. Now let's see if I can fix them... > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > From bryan.a.soto at gmail.com Fri Apr 7 01:41:14 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 22:41:14 -0700 Subject: [Nitro] [PATCH] tags Message-ID: This patch changes the sql query used for tag selection to the one suggested by Kashia. I've tested this patch with the test suite against these databases: sqlite - 3.2.1 Linux - 3.2.7 WinXP mysql - 4.1.14 Linux - 5.0.17 WinXP psql - 8.0.4 Linux - 8.1 WinXP and it passes the tests for tags. Could people give this patch a try against different versions of those databases if you have them and see if it works? And, if you have any apps with tags, could you try those out as well? Just in case the test case doesn't cover everything? If this works, were one step closer to all stores passing the tests. Thanks for any help. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-tags.zip Type: application/zip Size: 13587 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060407/0d8c7a23/attachment.zip From bryan.a.soto at gmail.com Fri Apr 7 02:00:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 6 Apr 2006 23:00:01 -0700 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> Message-ID: On 4/6/06, TRANS wrote: > So here's my "crazy" idea. > > What do you think of turning development inside out. By, "inside out", > which is especially apt with regard to Nitro, I mean why not make a > sort of nitro-based develpoment wiki. Have all of the source available > on this website where people can literally edit the code on the spot > --right through the web interface. > > Now what would happen is that every person who signs-up gets their own > darcs branch on the server. They can make changes and so forth and > then record them as usual but through the web interface. (Of course > you could still work on it the traditional way too and upload your > changes if you want/need). You can also run the tests remotely. And > even have them run automatically overnight. We could automate a lot of > things. Then integrate changes to a master repo more easily. > > The idea is to really open up access to development. This could really > improve involvement. And actually would be a nice demonstration of the > power of Nitro. (Hell, it could even lead to some sort of real > business model.) It could also help team development. Maybe using > Ajax, pair coding would even be possible. And given that a > Wordprocesser has actually been with Web 2.0, why not a code editor? > > And so on....I'm sure your imagination can fill in the plenty more. > > What do others think? > Wow. I'm happy getting test cases to pass and Trans is shifting paradigms... ;) Seriously, it sounds like a really interesting idea and if you're looking for volunteers, sign me up. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From aglarond at gmail.com Fri Apr 7 02:41:13 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Fri, 7 Apr 2006 08:41:13 +0200 Subject: [Nitro] STI a mistake in PostgreSQL? In-Reply-To: References: <55c107bf0604061321g623200e3r1bc8a06e749369f2@mail.gmail.com> <4b6f054f0604061400m6977570foe82af9a31a025cce@mail.gmail.com> Message-ID: <55c107bf0604062341p4e2db557qe55c755470305c69@mail.gmail.com> On 4/7/06, Bryan Soto wrote: > On 4/6/06, TRANS wrote: > > I bet it would make Og a much stronger ORM system on the whole. > > > > Just a thought, > > > > And a good thought. We just need to clean up the interface, move all > the heavy lifting to sql.rb and make the adapters just do the database > specific stuff. Currently, that's not exactly the case. Besides, a > well defined interface would make it easier to add support for new > databases like Oracle or MS Sql. Agreed. Maybe I could take a look at this in my copious free time. ;) - Dimitri From aglarond at gmail.com Fri Apr 7 02:50:35 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Fri, 7 Apr 2006 08:50:35 +0200 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> Message-ID: <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> On 4/7/06, TRANS wrote: > What do you think of turning development inside out. By, "inside out", > which is especially apt with regard to Nitro, I mean why not make a > sort of nitro-based develpoment wiki. Have all of the source available > on this website where people can literally edit the code on the spot > --right through the web interface. I'm actually already working on something very similar to this. It's one of the things that has been taking up my time. I haven't got anything presentable yet, but when I do, I'll definitely announce it. I was inspired while working on my web-based SpaceMerchant implementation, which is still not done because of this... - Dimitri From transfire at gmail.com Fri Apr 7 05:25:40 2006 From: transfire at gmail.com (TRANS) Date: Fri, 7 Apr 2006 05:25:40 -0400 Subject: [Nitro] Up Dev Proc In-Reply-To: <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> Message-ID: <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> On 4/7/06, Dimitri Aivaliotis wrote: > On 4/7/06, TRANS wrote: > > > What do you think of turning development inside out. By, "inside out", > > which is especially apt with regard to Nitro, I mean why not make a > > sort of nitro-based develpoment wiki. Have all of the source available > > on this website where people can literally edit the code on the spot > > --right through the web interface. > > I'm actually already working on something very similar to this. It's > one of the things that has been taking up my time. I haven't got > anything presentable yet, but when I do, I'll definitely announce it. Don;t you hate it when someone spouts out an idea you've been quietly working on? ;-) > I was inspired while working on my web-based SpaceMerchant > implementation, which is still not done because of this... Hmm.... Care to collaborate? I'm curious. Is it an Open source project? How far along are you? What features are you working on? And, you said "something very similar", how is it different? Thanks! T. From olle at olleolleolle.dk Fri Apr 7 05:33:03 2006 From: olle at olleolleolle.dk (Olle Jonsson) Date: Fri, 7 Apr 2006 11:33:03 +0200 Subject: [Nitro] How To Boost An Open-source Project? A Bunch of Personal Ideas In-Reply-To: <4b6f054f0604070218i39901909uaedc7cfdf2b9c1df@mail.gmail.com> References: <4b6f054f0604070218i39901909uaedc7cfdf2b9c1df@mail.gmail.com> Message-ID: On Apr 7, 2006, at 11:18 , TRANS wrote: > > Those are good ideas! You should lurk less ;-) I might. I just need that #2 done for me first; I need to migrate to Nitro from MVC in PHP and Rails. But, I need a good example, kind of App #1: "Sign up to receive an email when we launch our service" - take form input - validate its well-formedness - present a thank you page - sprinkle on some AJAX, optionally App #2: "The simplest CMS in the world" - CRUD for Pages - Textile for markup App #2, pt II: "Simplest CMS: Categories and tagging" - Categories of Pages - Tagging a Page I need to stuff like this to read/do to get my fingers dirty. > > In fact, mind if I post them to the list? Don't mind at all. In fact, thanks for recognizing these things. > > One of the nice things about these too is that they're readily doable. > We can work those into the wiki once it's fixed (I'm going to ge that > fixed, asap damn it!), then splatter this, ruby-talk and some PHPey :) > mailing lists with links to them. Very doable. Yeah, much of getting "success" in Open Source is talking the right way to people. > > Wow. This line of inquery has already prooved more successful than I > had expected. That's good. > > Thanks, > T. Olle Jonsson Prinsesse Charlottes Gade 40B, 3th 2200 K?benhavn N Denmark +45-2212 3703 olle at olleolleolle.dk From aglarond at gmail.com Fri Apr 7 06:11:26 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Fri, 7 Apr 2006 12:11:26 +0200 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> Message-ID: <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> On 4/7/06, TRANS wrote: > On 4/7/06, Dimitri Aivaliotis wrote: > Don;t you hate it when someone spouts out an idea you've been quietly > working on? ;-) :) > > I was inspired while working on my web-based SpaceMerchant > > implementation, which is still not done because of this... > > Hmm.... Care to collaborate? Sure. You'll have to wait on me, though. I'm not at the point yet where I have something workable. As soon as *something* works, I'll post to this list and ruby-talk. > I'm curious. Is it an Open source project? How far along are you? What > features are you working on? And, you said "something very similar", > how is it different? Where do I begin? It is an Open Source project. I'm not very far along yet - my ideas, just a basic layout, and spec-ing out the classes I'll need. Features? Basically a source-tracking community application that can be used to keep track of itself and integrate into the "hosted" project as well. Hmm.. that's not too clear. In terms of REST, the following URIs will be accessible under the domain where the app is located: /docs -> api documentation /book -> user manual /code -> source code /chat -> user forum /news -> announcements, etc. /auth -> authenticator Each URI will understand GET, PUT, DELETE, etc. and act appropriately. To change the app, /code would be edited; checkins don't happen unless all tests pass; AJAX highlights the failing sections. The source files are actually saved with rdoc and rubyweb comments to facilitate Literate Programming; /docs, /book, and /code are just different views of the same files. It's different from Trac or Rubyforge or similar things in that it is it's own RCS - not backed by CVS, SVN, Arch, Darcs, or anything else. I haven't worked all the details out yet, but strong cryptography and time-based editing sessions play a role. I'd be glad to discuss this more, but it may not be clear until I can get a demo ready. I'll see what I can get done this weekend - don't expect too much, though. It's a monumentous undertaking. Maybe I'll just have an introductory page up... - Dimitri From transfire at gmail.com Fri Apr 7 07:09:08 2006 From: transfire at gmail.com (TRANS) Date: Fri, 7 Apr 2006 07:09:08 -0400 Subject: [Nitro] Up Dev Proc In-Reply-To: <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> Message-ID: <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> On 4/7/06, Dimitri Aivaliotis wrote: > On 4/7/06, TRANS wrote: > > On 4/7/06, Dimitri Aivaliotis wrote: > > > Don;t you hate it when someone spouts out an idea you've been quietly > > working on? ;-) > > :) > > > > I was inspired while working on my web-based SpaceMerchant > > > implementation, which is still not done because of this... > > > > Hmm.... Care to collaborate? > > Sure. You'll have to wait on me, though. I'm not at the point yet > where I have something workable. As soon as *something* works, I'll > post to this list and ruby-talk. K. But don;t keep me waiting too long, b/c I'm tempted to start such a project myself --but I believe stongly in working together... > > I'm curious. Is it an Open source project? How far along are you? What > > features are you working on? And, you said "something very similar", > > how is it different? > > Where do I begin? It is an Open Source project. I'm not very far > along yet - my ideas, just a basic layout, and spec-ing out the > classes I'll need. Features? Basically a source-tracking community > application that can be used to keep track of itself and integrate > into the "hosted" project as well. Hmm.. that's not too clear. In > terms of REST, the following URIs will be accessible under the domain > where the app is located: > > /docs -> api documentation > /book -> user manual > /code -> source code > /chat -> user forum > /news -> announcements, etc. > /auth -> authenticator > > Each URI will understand GET, PUT, DELETE, etc. and act appropriately. > To change the app, /code would be edited; checkins don't happen > unless all tests pass; AJAX highlights the failing sections. Nice. I like what you're planning. > source files are actually saved with rdoc and rubyweb comments to > facilitate Literate Programming; /docs, /book, and /code are just > different views of the same files. Oh, I like that. Add test/ to that too btw (something I already do ;-). Although there also has to be room for independent docs/books/tests. > It's different from Trac or Rubyforge or similar things in that it is > it's own RCS - not backed by CVS, SVN, Arch, Darcs, or anything else. > I haven't worked all the details out yet, but strong cryptography and > time-based editing sessions play a role. Hmm... I encourage you not do this --at least not at first. It will be much easier and quicker to get running by using "off the shelf" tech here. A good RCS is not a simple thing to write (as least in my experience, I've flirted with coding one). Use Darcs preferably, but use one of these for the time being and come back to implementing your own RCS later on. > I'd be glad to discuss this more, but it may not be clear until I can > get a demo ready. I'll see what I can get done this weekend - don't > expect too much, though. It's a monumentous undertaking. Maybe I'll > just have an introductory page up... How about "bootstraping" the project. Start with the minimal functionality to get a working system: - user reg/auth - code browser - "wiki" code editor - automated testing - revision control For now we don't need views. Tests can be in '=begin test' comment blocks, and RDocs will quickly take care of themselves. It should be pretty easy to add views in later. Once these minimal requirements are in place, we can turn this very project on itself, and pull it up by it's bootstraps! When it's a bit more elaborate we'll turn it losse on Nitro and Og (by then I imagine they'll be two independent repos). How's that sound? T. From kashia at vfemail.net Fri Apr 7 07:32:04 2006 From: kashia at vfemail.net (Kashia Buch) Date: Fri, 07 Apr 2006 13:32:04 +0200 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: Whoa nice, totally :D > mysql > - 4.1.14 Linux This subselect even works with mysql 4? this is very good :) Thank you for all your hard work on Nitro and Og, you're so damn busy on it these days when I had some kind of company I'd actually pay you for working so hard XD Anyway, what I mean is, that I want to thank you so much for putting all that effort and time into this! Kashia PS: please wait some more on the Self join :through => issue, I'm too busy with C++ (*cry* T_T) at the moment to be able to work on that. -- Feel the love http://pinkjuice.com/pics/ruby.png From olle at olleolleolle.dk Fri Apr 7 07:50:08 2006 From: olle at olleolleolle.dk (Olle Jonsson) Date: Fri, 7 Apr 2006 13:50:08 +0200 Subject: [Nitro] How To Boost An Open-source Project? A Bunch of Personal Ideas Message-ID: <7A3278F0-3BCF-4994-B6CB-4C52B254CE3F@olleolleolle.dk> Hello again, I referred to some "ideas of mine" in my previous email. Here they are, unedited. > 1. Get more hackers: Create a "How To Become a Nitro Hacker" > document, which presents some low-hanging fruit for interested > developers. This is about making framework Users into Developers. > 2. Get more users: Write up a few post-mortems on simple (PHPey) > projects that represent low-hanging fruit for new Users that are > migrating from somewhere else. /Olle Jonsson From olleolleolle at home.se Fri Apr 7 07:53:06 2006 From: olleolleolle at home.se (Olle Jonsson) Date: Fri, 07 Apr 2006 13:53:06 +0200 Subject: [Nitro] How To Boost An Open-source Project? A Bunch of Personal Ideas Message-ID: <443652A2.2050104@home.se> I see that some of my wanted items are already there: the presentation of "what you can do" part. The video art from Nitro's website serves that purpose. Great stuff. Can't wait to scarf it all down. until then, Olle -- Olle Jonsson From aglarond at gmail.com Fri Apr 7 07:59:16 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Fri, 7 Apr 2006 13:59:16 +0200 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> Message-ID: <55c107bf0604070459t5fa18070k40c25a5e1543bf5b@mail.gmail.com> On 4/7/06, TRANS wrote: > On 4/7/06, Dimitri Aivaliotis wrote: > K. But don;t keep me waiting too long, b/c I'm tempted to start such a > project myself --but I believe stongly in working together... Just to be clear here: which project - the web-based SpaceMerchant or the web-based source-tracking community app? Or both? > Oh, I like that. Add test/ to that too btw (something I already do I actually thought of /test after posting. :) > ;-). Although there also has to be room for independent > docs/books/tests. What do you mean by "independent" docs/books/tests? Separate files? Unrelated URIs? > Hmm... I encourage you not do this --at least not at first. It will be > much easier and quicker to get running by using "off the shelf" tech > here. A good RCS is not a simple thing to write (as least in my > experience, I've flirted with coding one). Use Darcs preferably, but > use one of these for the time being and come back to implementing your > own RCS later on. Each RCS brings its own worldview with it. Controlling revisions in CVS is different than in Arch, is different than in Darcs. I'm trying a new approach here, with its own correspondingly new worldview. :) > How about "bootstraping" the project. Start with the minimal > functionality to get a working system: > > - user reg/auth > - code browser > - "wiki" code editor > - automated testing > - revision control > Once these minimal requirements are in place, we can turn this very > project on itself, and pull it up by it's bootstraps! Just what I was planning. ;) - Dimitri From vagabond at cataclysm-software.net Fri Apr 7 08:50:28 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Fri, 07 Apr 2006 08:50:28 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> Message-ID: <44366014.4080605@cataclysm-software.net> Bryan Soto wrote: > > With Apache, I ended up just using mod_rewrite and serving via a > virtual host. Might you be able to share your hacking? :) Well, that was the other possibility. My hacking was highly unqualified and I eventually gave up on it (paths for things like CSS files got all borked and the kludges to fix redirect and template lookup dirs was ugly). I'd be willing to help design and implement a real strategy for doing this though, but I don't know Nitro well enough to do it alone. >> > > I'm not sure, but perhaps what was outlined by Gergley might help? He > manipulated a controller class instance variable called > @template_root. See here for more info. > > http://rubyforge.org/pipermail/nitro-general/2006-March/003643.html No, that's not quite what I wanted, I wanted nitro ONLY running in a subdir, the DocumentRoot and other folders should/would be something totally different - rails or PHP or whatever. Andrew From george.moschovitis at gmail.com Fri Apr 7 11:49:50 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 7 Apr 2006 18:49:50 +0300 Subject: [Nitro] [PATCH] Some utilities Message-ID: Bryan, here is a small patch with some utilities, when you have some time, please apply! thanks in advance, -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 14159 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060407/123b4536/attachment.zip From george.moschovitis at gmail.com Fri Apr 7 12:02:17 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 7 Apr 2006 19:02:17 +0300 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: > Thank you for all your hard work on Nitro and Og, you're so damn > busy on it these days when I had some kind of company I'd actually > pay you for working so hard XD +1 Bryan totally rules ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From itsme213 at hotmail.com Fri Apr 7 20:31:59 2006 From: itsme213 at hotmail.com (itsme213) Date: Fri, 7 Apr 2006 19:31:59 -0500 Subject: [Nitro] In-memory Og Message-ID: Does Og work reliably for in-memory usage? I am considering using it simply for the convenience of its macros ... I'm tired of writing and debugging inverse-pointer code! Is this a sensible usage? Where to look this up? Of course, in some cases I might need to work in persistence. Thanks! From aidan at yoyo.org Fri Apr 7 21:09:02 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Sat, 8 Apr 2006 11:09:02 +1000 Subject: [Nitro] Up Dev Proc In-Reply-To: <55c107bf0604070459t5fa18070k40c25a5e1543bf5b@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> <55c107bf0604070459t5fa18070k40c25a5e1543bf5b@mail.gmail.com> Message-ID: Now to chip in with my "but I was thinking of doing this too!" I even have a name ;-) >> ;-). Although there also has to be room for independent >> docs/books/tests. > > What do you mean by "independent" docs/books/tests? Separate files? > Unrelated URIs? I think he means the ability to have doc, tests, etc. that are not directly related to source code files. > > >> Hmm... I encourage you not do this --at least not at first. It >> will be >> much easier and quicker to get running by using "off the shelf" tech >> here. A good RCS is not a simple thing to write (as least in my >> experience, I've flirted with coding one). Use Darcs preferably, but >> use one of these for the time being and come back to implementing >> your >> own RCS later on. > > Each RCS brings its own worldview with it. Controlling revisions in > CVS is different than in Arch, is different than in Darcs. I'm trying > a new approach here, with its own correspondingly new worldview. :) Agreed - I'd advise using rscm which abstracts the whole concept of source control, much like odbc does for databases. > >> How about "bootstraping" the project. Start with the minimal >> functionality to get a working system: >> >> - user reg/auth >> - code browser >> - "wiki" code editor >> - automated testing >> - revision control > >> Once these minimal requirements are in place, we can turn this very >> project on itself, and pull it up by it's bootstraps! > > Just what I was planning. ;) This sounds like something we should take off list. Perhaps we could set up a separate list to talk about this? Aidan From transfire at gmail.com Fri Apr 7 22:47:13 2006 From: transfire at gmail.com (TRANS) Date: Fri, 7 Apr 2006 22:47:13 -0400 Subject: [Nitro] Up Dev Proc In-Reply-To: References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> <55c107bf0604070459t5fa18070k40c25a5e1543bf5b@mail.gmail.com> Message-ID: <4b6f054f0604071947q14d5f347ob67f4ba9b7547673@mail.gmail.com> On 4/7/06, Aidan Rogers wrote: > This sounds like something we should take off list. Perhaps we could > set up a separate list to talk about this? Good idea. > Now to chip in with my "but I was thinking of doing this too!" I > even have a name ;-) So what's the name? T. From bryan.a.soto at gmail.com Sun Apr 9 02:04:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 8 Apr 2006 23:04:01 -0700 Subject: [Nitro] Up Dev Proc In-Reply-To: <4b6f054f0604071947q14d5f347ob67f4ba9b7547673@mail.gmail.com> References: <4b6f054f0604061804o20a4e120p52246b1784700b73@mail.gmail.com> <55c107bf0604062350o4ef3ci51f7d13a6a58c111@mail.gmail.com> <4b6f054f0604070225j1d55e640l4cbd7784267aef4b@mail.gmail.com> <55c107bf0604070311m288048cbkc31611f2e0bbd1c8@mail.gmail.com> <4b6f054f0604070409o259f5cd6mb68bb8b7c7b4e9d3@mail.gmail.com> <55c107bf0604070459t5fa18070k40c25a5e1543bf5b@mail.gmail.com> <4b6f054f0604071947q14d5f347ob67f4ba9b7547673@mail.gmail.com> Message-ID: On 4/7/06, TRANS wrote: > On 4/7/06, Aidan Rogers wrote: > > This sounds like something we should take off list. Perhaps we could > > set up a separate list to talk about this? > > Good idea. > I'd be interested in joining, if you'll have me. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 02:10:34 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 8 Apr 2006 23:10:34 -0700 Subject: [Nitro] In-memory Og In-Reply-To: References: Message-ID: On 4/7/06, itsme213 wrote: > Does Og work reliably for in-memory usage? I am considering using it simply > for the convenience of its macros ... I'm tired of writing and debugging > inverse-pointer code! > Well, there is an store set up for memory, but it's probably considered alpha, since it's stored in og/lib/og/store/alpha/memory.rb It also says it doesn't support all Og features, so it might not fit your needs. > Is this a sensible usage? Where to look this up? > > Of course, in some cases I might need to work in persistence. > That tends to be the general usage. Though, I'd imagine getting the memory store up to speed would be a nice addition. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 02:17:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 8 Apr 2006 23:17:46 -0700 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: On 4/7/06, Kashia Buch wrote: > Whoa nice, totally :D > It was your query. I just copied it from the email. :) > > mysql > > - 4.1.14 Linux > > This subselect even works with mysql 4? this is very good :) > Yeah, I was rather suprised at that too. > Thank you for all your hard work on Nitro and Og, you're so damn > busy on it these days when I had some kind of company I'd actually > pay you for working so hard XD > > Anyway, what I mean is, that I want to thank you so much for putting > all that effort and time into this! > Thank you for oxyliquit. We all do what we can. :) > Kashia > PS: please wait some more on the Self join :through => issue, I'm > too busy with C++ (*cry* T_T) at the moment to be able to work on > that. > I've toyed with C++, but I've never been able to use it for anything real. Is it really that bad? :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 02:27:03 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 8 Apr 2006 23:27:03 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <44366014.4080605@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> Message-ID: On 4/7/06, Andrew Thompson wrote: > Bryan Soto wrote: > > > > With Apache, I ended up just using mod_rewrite and serving via a > > virtual host. Might you be able to share your hacking? :) > > Well, that was the other possibility. My hacking was highly unqualified > and I eventually gave up on it (paths for things like CSS files got all > borked and the kludges to fix redirect and template lookup dirs was > ugly). I'd be willing to help design and implement a real strategy for > doing this though, but I don't know Nitro well enough to do it alone. > Well, let's open a ticket so I don't forget. I've got to finish up with bugs and patches, but this is something I'd like. If nobody else joins in, I'd be happy to help try. I'm not a Nitro expert, but perhaps between the two of us, we can figure it out. :) Bryan > >> > > > > I'm not sure, but perhaps what was outlined by Gergley might help? He > > manipulated a controller class instance variable called > > @template_root. See here for more info. > > > > http://rubyforge.org/pipermail/nitro-general/2006-March/003643.html > > No, that's not quite what I wanted, I wanted nitro ONLY running in a > subdir, the DocumentRoot and other folders should/would be something > totally different - rails or PHP or whatever. > > Andrew > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 02:49:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 8 Apr 2006 23:49:46 -0700 Subject: [Nitro] How To Boost An Open-source Project? A Bunch of Personal Ideas In-Reply-To: <7A3278F0-3BCF-4994-B6CB-4C52B254CE3F@olleolleolle.dk> References: <7A3278F0-3BCF-4994-B6CB-4C52B254CE3F@olleolleolle.dk> Message-ID: On 4/7/06, Olle Jonsson wrote: > Hello again, > > I referred to some "ideas of mine" in my previous email. Here they > are, unedited. > > > 1. Get more hackers: Create a "How To Become a Nitro Hacker" > > document, which presents some low-hanging fruit for interested > > developers. This is about making framework Users into Developers. > > 2. Get more users: Write up a few post-mortems on simple (PHPey) > > projects that represent low-hanging fruit for new Users that are > > migrating from somewhere else. > So, what would be the "low-hanging fruit" that would interest users and hackers? What makes Nitro different? I guess this question is more for everyone experienced with different web app frameworks. What do you miss from Nitro when you're not using it? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 03:24:55 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 00:24:55 -0700 Subject: [Nitro] Question for all you postgres users. Message-ID: I'm looking at the docs for postgres, and they say: => SELECT * FROM test1; x | y ---+--- a | 3 c | 2 b | 5 a | 1 (4 rows) => SELECT x FROM test1 GROUP BY x; x --- a b c (3 rows) Notice that when using group by, the x column is sorted. However, when I duplicate a query from a failing test: test=# select section, sum(age) from ogtc_ogaggrcalc_user group by section; section | sum ---------+----- c | 58 d | 67 a | 28 (3 rows) It's not sorted. Is sorting not guaranteed in postgres when using group by? It does for the other stores? Just curious cause there's a test failing because it assumes that the result will be sorted. If sorting isn't guaranteed, then it's not an issue. Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 03:52:29 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 00:52:29 -0700 Subject: [Nitro] [PATCH] og-psql-refactoring Message-ID: The attached bundle contains one patch that has some rather drastic changes to the postgres sql store. It passes the test suite except for one failure addressed in a different email. Could someone that has an existing app in postgres _please_ test this? I don't have a Postgres app, so I can verify that it's backwards compatible. I can check against Mysql and Sqlite, but not Postgres. I'd really appreciate if someone could give this a try. I'd rather throw away the last patch if it isn't backward compatible. Thanks for your help. Bryan ~~~~~ Patch modifies the way Postgres accesses join table info to match other stores. ~ Makes PsqlStore#eval_og_allocate use the same logic as SqlStore#eval_og_allocate when determining if a class is STI. ~ Modifies the query used for Tag selection. Uses subqueries. Passes tests on Mysql, Postgres and Sqlite. ~ In PGResult, makes next and each row match the interface used by the other stores so that SqlStore works properly when calling these methods for PsqlStore. Removes read_prop, eval_og_insert, eval_og_allocate and read_row methods from psql.rb in favor of the methods defined in the superclass SqlStore. Postgres doesn't appear to support autoincrement, so added a new method to SqlStore, generate_key. Postgres uses this to generate the oid value to be inserted. SqlStore defines this method as returning NULL which allows the other stores to autoincrement. This can possibly be extended to allow custom key generation for all the stores. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-psql-refactoring.zip Type: application/zip Size: 15048 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060409/495c6d89/attachment.zip From news at stephan.walter.name Sun Apr 9 06:40:29 2006 From: news at stephan.walter.name (Stephan Walter) Date: Sun, 09 Apr 2006 12:40:29 +0200 Subject: [Nitro] nitrohq.com Message-ID: Hi, the wiki has been broken for a long time now, and in the last few days some domain name company has hijacked nitrohq.com (somebody forgot to pay the fees?). I think there's no use talking about "low-hanging fruit" for developers if there isn't even a working website! I'll gladly help to get the wiki up and running again, if there's something I can do... -Stephan From transfire at gmail.com Sun Apr 9 07:42:41 2006 From: transfire at gmail.com (TRANS) Date: Sun, 9 Apr 2006 07:42:41 -0400 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: References: Message-ID: <4b6f054f0604090442y560579faycacbab24b0fede8e@mail.gmail.com> Hi Bryan, I tried running the test suite myself and get this: .dropdb: database removal failed: ERROR: database "test" does not exist dropdb: database removal failed: ERROR: database "test" does not exist .dropdb: database removal failed: ERROR: database "test" does not exist dropdb: database removal failed: ERROR: database "test" does not exist ./test/og/tc_delete_all.rb:26: undefined method `manage_classes' for nil:NilClass (NoMethodError) from -:14 But even prior to that, the testing suite should not run against install! Perhaps there is something I am not doing that takes care of this? But when one uses 'rake test' it does not do this. To fix I added a test section to the ProjectInfo file: TEST: libs: [ '../og/lib', '../glue/lib', '../nitro/lib', '../../../facets/lib/' ] And use 'reap test' instead. Note others will have to change or remove the last entry, as that points to my own development repo of Facets. T. P.S. There seems to be no more nitrohq repo. I had to 'darcs get' from devlab. From mischa.kroon at gmail.com Sun Apr 9 08:02:24 2006 From: mischa.kroon at gmail.com (Mischa Kroon) Date: Sun, 9 Apr 2006 14:02:24 +0200 Subject: [Nitro] nitrohq.com References: Message-ID: <002b01c65bcd$77471bd0$0a01a8c0@mischabak> Hey at least it's a nice looking front end :) ----- Original Message ----- From: "Stephan Walter" To: Sent: Sunday, April 09, 2006 12:40 PM Subject: [Nitro] nitrohq.com > Hi, > > the wiki has been broken for a long time now, and in the last few days > some domain name company has hijacked nitrohq.com (somebody forgot to pay > the fees?). I think there's no use talking about "low-hanging fruit" for > developers if there isn't even a working website! I'll gladly help to get > the wiki up and running again, if there's something I can do... > > -Stephan > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From kashia at vfemail.net Sun Apr 9 08:43:23 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 14:43:23 +0200 Subject: [Nitro] Community Related Message-ID: Hi, for everyone who doesn't read the ruby-talk ML: http://www.slash7.com/articles/2006/03/22/s-o-s-save-our-sanity and the real gem in there: http://www.slash7.com/pages/vampires Our community is still growing, so I think we can learn from our bigger brother :P Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Apr 9 08:46:13 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 14:46:13 +0200 Subject: [Nitro] Question for all you postgres users. In-Reply-To: References: Message-ID: Hi, sorting should _never_ be assumed, when a "SORT BY" is not given. Even if postgre seems to do some weird things there ;) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Apr 9 08:50:37 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 14:50:37 +0200 Subject: [Nitro] nitrohq.com In-Reply-To: References: Message-ID: Hi, thank you for that offer, but George said he'd fix everthing this week. (George, you better do now ;)) Other than that, manveru has had already the plan to replace the nitrohq wiki, if that situation doesn't change within the week. So, whatever happens, I surely hope that this mess gets fixed very soon :) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Apr 9 08:56:34 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 14:56:34 +0200 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: Hi, > Thank you for oxyliquit. We all do what we can. :) Sure, but you're my hero atm, right besides big G ;D > I've toyed with C++, but I've never been able to use it for anything > real. Is it really that bad? :) We can discuss whether (<< I keep writing this as "weither" -_-) lab assignments are useful/"real" :) And yes, it is bad. Part of that is because I'm throwing around with pointers, for speeds sake ;/ (and no, I don't do this voluntarily, our prof wants that) Enuff whinin'! Go for it, everyone (for nitro, not c++) ;D Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Apr 9 10:00:17 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 16:00:17 +0200 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: References: Message-ID: Hi, > I'd really appreciate if someone could give this a try. I'd rather > throw away the last patch if it isn't backward compatible. I still can't run test-suits, but I ran Oxyliquit on it. Works like before, so, I think that covers some of the tests :D > Postgres doesn't appear to support autoincrement, so added a new > method to SqlStore, generate_key. Postgres uses this to generate the > oid value to be inserted. SqlStore defines this method as returning > NULL which allows the other stores to autoincrement. This can possibly > be extended to allow custom key generation for all the stores. um.... look at this: CREATE TABLE tst ( oid SERIAL, title TEXT ) creates: oxytest=# \d tst Table "public.tst" Column | Type | Modifiers -----------+---------+---------------------------------------------------------------- oid | integer | not null default nextval('tst_oid_seq'::regclass) title | text | now, when inserting: INSERT INTO tst (oid, title) VALUES (NULL, 'asdf'); INSERT INTO tst (title) VALUES ('asdf2'); INSERT INTO tst VALUES (NULL, 'asdf3'); This is where the _default_ is jumping in. SELECT * FROM tst; oid | title --------+--------- 1 | asdf 2 | asdf2 3 | asdf3 so, SERIAL is the keyword here, and NULL gets inserted to get the next oid. Does that clarify things? Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From reid.thompson at ateb.com Sun Apr 9 12:36:11 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Sun, 09 Apr 2006 12:36:11 -0400 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: References: Message-ID: <443937FB.1070409@ateb.com> Bryan Soto wrote: > The attached bundle contains one patch that has some rather drastic > changes to the postgres sql store. It passes the test suite except for > one failure addressed in a different email. Could someone that has an > existing app in postgres _please_ test this? I don't have a Postgres > app, so I can verify that it's backwards compatible. I can check > against Mysql and Sqlite, but not Postgres. > > I'd really appreciate if someone could give this a try. I'd rather > throw away the last patch if it isn't backward compatible. > > Thanks for your help. > > Bryan > > ~~~~~ > Patch modifies the way Postgres accesses join table info to match other stores. > ~ > Makes PsqlStore#eval_og_allocate use the same logic as > SqlStore#eval_og_allocate when determining if a class is STI. > ~ > Modifies the query used for Tag selection. Uses subqueries. Passes > tests on Mysql, Postgres and Sqlite. > ~ > In PGResult, makes next and each row match the interface used by the > other stores so that SqlStore works properly when calling these > methods for PsqlStore. > > Removes read_prop, eval_og_insert, eval_og_allocate and read_row > methods from psql.rb in favor of the methods defined in the superclass > SqlStore. > > Postgres doesn't appear to support autoincrement, so added a new > method to SqlStore, generate_key. Postgres uses this to generate the > oid value to be inserted. SqlStore defines this method as returning > NULL which allows the other stores to autoincrement. This can possibly > be extended to allow custom key generation for all the stores. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general Perhaps i'm misunderstanding this comment ' Postgres doesn't appear to support autoincrement, so added a new method to SqlStore, generate_key.' But if by autoincrement you mean a db generated sequence, then Postgres does support this. http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-SERIAL Am I misunderstanding... From bryan.a.soto at gmail.com Sun Apr 9 12:48:11 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 09:48:11 -0700 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: <4b6f054f0604090442y560579faycacbab24b0fede8e@mail.gmail.com> References: <4b6f054f0604090442y560579faycacbab24b0fede8e@mail.gmail.com> Message-ID: On 4/9/06, TRANS wrote: > Hi Bryan, > > I tried running the test suite myself and get this: > > .dropdb: database removal failed: ERROR: database "test" does not exist > dropdb: database removal failed: ERROR: database "test" does not exist > .dropdb: database removal failed: ERROR: database "test" does not exist > dropdb: database removal failed: ERROR: database "test" does not exist > ./test/og/tc_delete_all.rb:26: undefined method `manage_classes' for > nil:NilClass (NoMethodError) > from -:14 > In the checked out repo, there is a file, og\test\og\CONFIG.rb that needs to be edited with your connection settings, username, password, etc. Perhaps that's the problem? > But even prior to that, the testing suite should not run against > install! Perhaps there is something I am not doing that takes care of > this? But when one uses 'rake test' it does not do this. To fix I > added a test section to the ProjectInfo file: > > TEST: > libs: [ '../og/lib', '../glue/lib', '../nitro/lib', '../../../facets/lib/' ] > Cool, I've been meaning to ask you what we'd need too. :) > And use 'reap test' instead. Note others will have to change or remove > the last entry, as that points to my own development repo of Facets. > > T. > > P.S. There seems to be no more nitrohq repo. I had to 'darcs get' from devlab. Devlab should be the repo now. I honestly didn't know repo.nitrohq.com was still around. George had mentioned previously that he was going to change the entry to point to devlab. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 12:54:43 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 09:54:43 -0700 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: References: Message-ID: On 4/9/06, Kashia Buch wrote: > Hi, > > > I'd really appreciate if someone could give this a try. I'd rather > > throw away the last patch if it isn't backward compatible. > > I still can't run test-suits, but I ran Oxyliquit on it. > Works like before, so, I think that covers some of the tests :D > Well, maybe my response to trans will help with the test suite, but I'm glad oxy ran. Insertions, deletions, etc. were all okay? > > > Postgres doesn't appear to support autoincrement, so added a new > > method to SqlStore, generate_key. Postgres uses this to generate the > > oid value to be inserted. SqlStore defines this method as returning > > NULL which allows the other stores to autoincrement. This can possibly > > be extended to allow custom key generation for all the stores. > so, SERIAL is the keyword here, and NULL gets inserted to get the next oid. > > Does that clarify things? > Very much so. My thanks to you and Reid. :) I was going by the code in the Psql adapter, which did this: res = store.conn.exec "SELECT nextval('#{klass::OGSEQ}')" @#{klass.pk_symbol} = res.getvalue(0, 0).to_i res.clear >From that explicit nextval and setting of the key, usually @oid, I just assumed that it didn't support it. I'll see if I can modify create_table to use serial then. Though I might leave that generate_key method in. I can see that it could be useful for people that need to do something special. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 12:59:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 09:59:46 -0700 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: On 4/9/06, Kashia Buch wrote: > Hi, > > > Thank you for oxyliquit. We all do what we can. :) > > Sure, but you're my hero atm, right besides big G ;D > > > I've toyed with C++, but I've never been able to use it for anything > > real. Is it really that bad? :) > > We can discuss whether (<< I keep writing this as "weither" -_-) lab > assignments are useful/"real" :) > And yes, it is bad. > Part of that is because I'm throwing around with pointers, for speeds > sake ;/ (and no, I don't do this voluntarily, our prof wants that) > Pointers aren't that bad. Just a different way of thinking. (Disclaimer: I'm a C programmer :) > Enuff whinin'! Go for it, everyone (for nitro, not c++) ;D > Well, do it for Nitro then. There was talk a while back of speeding things up by rewriting portions in C. Might be an investment in Nitro's future. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 9 13:06:43 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 10:06:43 -0700 Subject: [Nitro] Question for all you postgres users. In-Reply-To: References: Message-ID: On 4/9/06, Kashia Buch wrote: > Hi, > > sorting should _never_ be assumed, when a "SORT BY" is not given. > Even if postgre seems to do some weird things there ;) > That's a fair point. Hmm... so what should change then? The test or the aggregation code so that when you 'group by' a field it will also 'order by' that field as well unless overriden? I don't think that makes Og too smart because you can override it if you need to and it seems sensible to use that sort when you're grouping. Any opinions? Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Sun Apr 9 13:31:18 2006 From: transfire at gmail.com (TRANS) Date: Sun, 9 Apr 2006 13:31:18 -0400 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: References: <4b6f054f0604090442y560579faycacbab24b0fede8e@mail.gmail.com> Message-ID: <4b6f054f0604091031x57ca4acfie58eded4fae5d1e9@mail.gmail.com> On 4/9/06, Bryan Soto wrote: > On 4/9/06, TRANS wrote: > > Hi Bryan, > > > > I tried running the test suite myself and get this: > > > > .dropdb: database removal failed: ERROR: database "test" does not exist > > dropdb: database removal failed: ERROR: database "test" does not exist > > .dropdb: database removal failed: ERROR: database "test" does not exist > > dropdb: database removal failed: ERROR: database "test" does not exist > > ./test/og/tc_delete_all.rb:26: undefined method `manage_classes' for > > nil:NilClass (NoMethodError) > > from -:14 > > > > In the checked out repo, there is a file, og\test\og\CONFIG.rb that > needs to be edited with your connection settings, username, password, > etc. > > Perhaps that's the problem? Nah, I wrote CONFIG.rb ;-) Although, its' a bit hackish --certainly could use come improvements, the problem is Og.setup is returning nil for some reason. What would cause Og.setup to return nil, rather that raise an error? That seems odd. > Devlab should be the repo now. I honestly didn't know repo.nitrohq.com > was still around. George had mentioned previously that he was going to > change the entry to point to devlab. Ah, that's right. I think you mentioned something about that before. Cool. T. From kashia at vfemail.net Sun Apr 9 13:36:10 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 19:36:10 +0200 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: Hi, > Pointers aren't that bad. Just a different way of thinking. > (Disclaimer: I'm a C programmer :) Pointers are nice, in a perfect world ;) But things stop working nice, when something totally unrelated can break everything, just because I myself am not fully able to "feel the flow" of the C++ program. > Well, do it for Nitro then. There was talk a while back of speeding > things up by rewriting portions in C. Might be an investment in > Nitro's future. :) This is a good idea, and I thought about the same thing when I saw the Template compiling. Horrible! I almost broke into tears ;/ if you change the template string in tc_template.rb to: template = %q{ Hello #{user} dont forget the following ^ todo ^ items:
  • #{item}
    • " ?> #{"asdf \t...".to_s.squeeze("\s").gsub!(/<[^>]+?>/, '')} now this ..
    } There are at least 7 serious problems going on here, which all originate from template.rb, and not all are easyly spotted..... So, writing a real parser for the nhtml's (nitro xhtmls :P) would be a very beneficial task... (the current ... hacks? are.. I can't really describe it..) This post is not intended to hurt any feelings or to bash George for it. The current implementation works and is ok for now, but some day, some things will have to be done :) Maybe this will end in me writing something in C to address it, but that'll be in another lightyear or two (I'm aware that light- year is not used for time measurment ;)) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Sun Apr 9 13:38:53 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 09 Apr 2006 19:38:53 +0200 Subject: [Nitro] Question for all you postgres users. In-Reply-To: References: Message-ID: Hi, > That's a fair point. Hmm... so what should change then? The test or > the aggregation code so that when you 'group by' a field it will also > 'order by' that field as well unless overriden? I don't think that > makes Og too smart because you can override it if you need to and it > seems sensible to use that sort when you're grouping. Any opinions? In my opinion, the test case should be changed to be able to handle not sorted results, which is not guaranteed in any way. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Sun Apr 9 14:24:43 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 11:24:43 -0700 Subject: [Nitro] [PATCH] og-psql-refactoring In-Reply-To: <4b6f054f0604091031x57ca4acfie58eded4fae5d1e9@mail.gmail.com> References: <4b6f054f0604090442y560579faycacbab24b0fede8e@mail.gmail.com> <4b6f054f0604091031x57ca4acfie58eded4fae5d1e9@mail.gmail.com> Message-ID: On 4/9/06, TRANS wrote: > On 4/9/06, Bryan Soto wrote: > > On 4/9/06, TRANS wrote: > > > Hi Bryan, > > > > > > I tried running the test suite myself and get this: > > > > > > .dropdb: database removal failed: ERROR: database "test" does not exist > > > dropdb: database removal failed: ERROR: database "test" does not exist > > > .dropdb: database removal failed: ERROR: database "test" does not exist > > > dropdb: database removal failed: ERROR: database "test" does not exist > > > ./test/og/tc_delete_all.rb:26: undefined method `manage_classes' for > > > nil:NilClass (NoMethodError) > > > from -:14 > > > > > > > In the checked out repo, there is a file, og\test\og\CONFIG.rb that > > needs to be edited with your connection settings, username, password, > > etc. > > > > Perhaps that's the problem? > > Nah, I wrote CONFIG.rb ;-) Although, its' a bit hackish --certainly > could use come improvements, the problem is Og.setup is returning nil > for some reason. What would cause Og.setup to return nil, rather that > raise an error? That seems odd. > That's right. I forgot your name was in there... Hmm... Well, you could try setting debug to true, though I'm guessing it's all those errors about test not existing that's causing your problem. Does it work for other stores? Perhaps postgres needs to have the db created manually the first time around? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From zimba.tm at gmail.com Sun Apr 9 17:40:27 2006 From: zimba.tm at gmail.com (zimba-tm) Date: Sun, 9 Apr 2006 21:40:27 +0000 Subject: [Nitro] nitrohq.com In-Reply-To: References: Message-ID: <3ff63f9b0604091440k23207023j80a381812b6ca00@mail.gmail.com> nitrohq.ch is free. I can offer that if you want. --Cheers, zimba http://zimba.oree.ch From m.fellinger at gmail.com Sun Apr 9 19:54:13 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Mon, 10 Apr 2006 08:54:13 +0900 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: <9c00d3e00604091654l6ed7909of77c42e5a8172e25@mail.gmail.com> just wondering, but how exactly will having C in the repo work withpulling? do we have to compile it all again everytime... ? (and yes, ido hate compiling)I think before we are writing something in C we should first try tobenchmark nitro... I found this an impossible task due to thekernel#autoreload - it causes some really bad failures.However, if we could benchmark the whole application we could justsave us a bit of work and find out where exactly the problems arelurking, right? :) On 4/10/06, Kashia Buch wrote:> Hi,>> > Pointers aren't that bad. Just a different way of thinking.> > (Disclaimer: I'm a C programmer :)>> Pointers are nice, in a perfect world ;)> But things stop working nice, when something totally unrelated can> break everything, just because I myself am not fully able to "feel> the flow" of the C++ program.>> > Well, do it for Nitro then. There was talk a while back of speeding> > things up by rewriting portions in C. Might be an investment in> > Nitro's future. :)>> This is a good idea, and I thought about the same thing when I saw> the Template compiling.>> Horrible! I almost broke into tears ;/>> if you change the template string in tc_template.rb to:>> template = %q{> Hello #{user}>> dont forget the following ^ todo ^ items:>> >
  • #{item}
    • > >> " ?>> > #{"asdf \t...".to_s.squeeze("\s").gsub!(/<[^>]+?>/, '')}> now this ..
    > }>> There are at least 7 serious problems going on here, which all> originate from template.rb, and not all are easyly spotted.....>> So, writing a real parser for the nhtml's (nitro xhtmls :P) would> be a very beneficial task... (the current ... hacks? are.. I can't> really describe it..)>> This post is not intended to hurt any feelings or to bash George> for it. The current implementation works and is ok for now, but> some day, some things will have to be done :)> Maybe this will end in me writing something in C to address it,> but that'll be in another lightyear or two (I'm aware that light-> year is not used for time measurment ;))>> Kashia>> --> 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> From reid.thompson at ateb.com Sun Apr 9 23:13:59 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Sun, 09 Apr 2006 23:13:59 -0400 Subject: [Nitro] Question for all you postgres users. In-Reply-To: References: Message-ID: <4439CD77.4070407@ateb.com> Kashia Buch wrote: > Hi, > > >> That's a fair point. Hmm... so what should change then? The test or >> the aggregation code so that when you 'group by' a field it will also >> 'order by' that field as well unless overriden? I don't think that >> makes Og too smart because you can override it if you need to and it >> seems sensible to use that sort when you're grouping. Any opinions? >> > > In my opinion, the test case should be changed to be able to handle > not sorted results, which is not guaranteed in any way. > > Kashia > > I agree with Kashia, if you want sorted, it should be part of the request, not the default. From bryan.a.soto at gmail.com Mon Apr 10 01:42:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 22:42:10 -0700 Subject: [Nitro] Question for all you postgres users. In-Reply-To: <4439CD77.4070407@ateb.com> References: <4439CD77.4070407@ateb.com> Message-ID: On 4/9/06, Reid Thompson wrote: > Kashia Buch wrote: > > Hi, > > > > > >> That's a fair point. Hmm... so what should change then? The test or > >> the aggregation code so that when you 'group by' a field it will also > >> 'order by' that field as well unless overriden? I don't think that > >> makes Og too smart because you can override it if you need to and it > >> seems sensible to use that sort when you're grouping. Any opinions? > >> > > > > In my opinion, the test case should be changed to be able to handle > > not sorted results, which is not guaranteed in any way. > > > > Kashia > > > > > I agree with Kashia, if you want sorted, it should be part of the > request, not the default. All right then. Unless there are any good arguments to the contrary, I'll go with the two of you. Thanks for the input. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 10 02:15:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 9 Apr 2006 23:15:47 -0700 Subject: [Nitro] [PATCH] tags In-Reply-To: <9c00d3e00604091654l6ed7909of77c42e5a8172e25@mail.gmail.com> References: <9c00d3e00604091654l6ed7909of77c42e5a8172e25@mail.gmail.com> Message-ID: No worries, manveru. :) As I said, it was just something that came up on the list before. George liked the idea but, just as you, wanted to benchmark. From that I gather if it's done, it'd just be for hot spots. Bryan On 4/9/06, Michael Fellinger wrote: > just wondering, but how exactly will having C in the repo work withpulling? do we have to compile it all again everytime... ? (and yes, ido hate compiling)I think before we are writing something in C we should first try tobenchmark nitro... I found this an impossible task due to thekernel#autoreload - it causes some really bad failures.However, if we could benchmark the whole application we could justsave us a bit of work and find out where exactly the problems arelurking, right? :) > On 4/10/06, Kashia Buch wrote:> Hi,>> > Pointers aren't that bad. Just a different way of thinking.> > (Disclaimer: I'm a C programmer :)>> Pointers are nice, in a perfect world ;)> But things stop working nice, when something totally unrelated can> break everything, just because I myself am not fully able to "feel> the flow" of the C++ program.>> > Well, do it for Nitro then. There was talk a while back of speeding> > things up by rewriting portions in C. Might be an investment in> > Nitro's future. :)>> This is a good idea, and I thought about the same thing when I saw> the Template compiling.>> Horrible! I almost broke into tears ;/>> if you change the template string in tc_template.rb to:>> template = %q{> Hello #{user}>> dont forget the following ^ todo ^ items:>> >
  • #{item}
    • > >> " ?>> > #! > {"asdf \t...".to_s.squeeze("\s").gsub!(/<[^>]+?>/, '')}> now this ..
    > }>> There are at least 7 serious problems going on here, which all> originate from template.rb, and not all are easyly spotted.....>> So, writing a real parser for the nhtml's (nitro xhtmls :P) would> be a very beneficial task... (the current ... hacks? are.. I can't> really describe it..)>> This post is not intended to hurt any feelings or to bash George> for it. The current implementation works and is ok for now, but> some day, some things will have to be done :)> Maybe this will end in me writing something in C to address it,> but that'll be in another lightyear or two (I'm aware that light-> year is not used for time measurment ;))>> Kashia>> --> Feel the love> http://pinkjuice.com/pics/ruby.png> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 10 03:10:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 00:10:01 -0700 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: On 4/9/06, Kashia Buch wrote: > Hi, > > > Pointers aren't that bad. Just a different way of thinking. > > (Disclaimer: I'm a C programmer :) > > Pointers are nice, in a perfect world ;) > But things stop working nice, when something totally unrelated can > break everything, just because I myself am not fully able to "feel > the flow" of the C++ program. > You've obviously haven't had an aliasing problem yet. Why do you think Ruby has the freeze method. ;) > > Well, do it for Nitro then. There was talk a while back of speeding > > things up by rewriting portions in C. Might be an investment in > > Nitro's future. :) > > This is a good idea, and I thought about the same thing when I saw > the Template compiling. > > Horrible! I almost broke into tears ;/ > > if you change the template string in tc_template.rb to: > > template = %q{ > Hello #{user} > > dont forget the following ^ todo ^ items: > > >
  • #{item}
    • > > > " ?> > > #{"asdf \t...".to_s.squeeze("\s").gsub!(/<[^>]+?>/, '')} > now this ..
    > } > > There are at least 7 serious problems going on here, which all > originate from template.rb, and not all are easyly spotted..... > > So, writing a real parser for the nhtml's (nitro xhtmls :P) would > be a very beneficial task... (the current ... hacks? are.. I can't > really describe it..) > Are there really no unique ideas!? :) I've actually been pondering that one as well, though not in C. So much to do... :) Bryan > This post is not intended to hurt any feelings or to bash George > for it. The current implementation works and is ok for now, but > some day, some things will have to be done :) > Maybe this will end in me writing something in C to address it, > but that'll be in another lightyear or two (I'm aware that light- > year is not used for time measurment ;)) > > Kashia > > -- > 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 > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 10 03:59:37 2006 From: transfire at gmail.com (TRANS) Date: Mon, 10 Apr 2006 03:59:37 -0400 Subject: [Nitro] [PATCH] tags In-Reply-To: References: Message-ID: <4b6f054f0604100059k72e8de5dtc1e696149e44861@mail.gmail.com> On 4/10/06, Bryan Soto wrote: > > Are there really no unique ideas!? :) > > I've actually been pondering that one as well, though not in C. So > much to do... :) If you want speed and clean xml I recommend using libxml. T. From vagabond at cataclysm-software.net Mon Apr 10 08:20:29 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Mon, 10 Apr 2006 08:20:29 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> Message-ID: <443A4D8D.4000202@cataclysm-software.net> Bryan Soto wrote: > Well, let's open a ticket so I don't forget. I've got to finish up > with bugs and patches, but this is something I'd like. If nobody else > joins in, I'd be happy to help try. I'm not a Nitro expert, but > perhaps between the two of us, we can figure it out. :) > > Bryan Sounds good, I'm not familiar with trac but I can try to do a ticket if you'd prefer... Andrew From george.moschovitis at gmail.com Mon Apr 10 10:59:03 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 17:59:03 +0300 Subject: [Nitro] nitrohq.com In-Reply-To: <3ff63f9b0604091440k23207023j80a381812b6ca00@mail.gmail.com> References: <3ff63f9b0604091440k23207023j80a381812b6ca00@mail.gmail.com> Message-ID: Damn, the registration company fucked up :) I have selected auto-renewal but that just didnt happen. Anyway I have manually renewed the domain, hopefully this will be resolved in 1-2 days. -g. On 4/10/06, zimba-tm wrote: > nitrohq.ch is free. I can offer that if you want. > --Cheers, zimba > http://zimba.oree.ch > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Mon Apr 10 12:05:47 2006 From: transfire at gmail.com (TRANS) Date: Mon, 10 Apr 2006 12:05:47 -0400 Subject: [Nitro] Better than classinherit.rb! Message-ID: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Thanks to a couple of posts on Ruby-talk, especially one about using cattr in modules, I believe I've surpassed myself with this gem that should (unless I missed something) be able to usurp classinherit.rb. Thing is, once again I gotta come up with a beter name! require 'facets/core/module/basename' class Module def interlude( mod ) ext = Module.new # extension module const_set( "Ex#{mod.basename}", ext ) smethods = mod.singleton_methods smethods -= ['included'] if Class === mod smethods.each do |m| ext.class_eval do define_method(m, &(mod.method(m))) end end extend ext unless smethods.empty? include mod nil end end try it: module M def self.s ; 1 ; end def s ; 2 ; end end module Q interlude M end class R interlude Q end R.s #=> 1 R.new.s #=> 2 T. From zimba.tm at gmail.com Mon Apr 10 12:48:28 2006 From: zimba.tm at gmail.com (zimba-tm) Date: Mon, 10 Apr 2006 18:48:28 +0200 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Message-ID: <3ff63f9b0604100948i479ac6edg97beb8ab24527491@mail.gmail.com> oooh nice ! some name propositions :* class_include* include_all* singleton_include It should express that you include the class with it's singleton methods. Now the question arises : how do you note that a module in designed tobe included with it's singleton-class methods ? --Cheers, zimba http://zimba.oree.ch From george.moschovitis at gmail.com Mon Apr 10 12:58:09 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 19:58:09 +0300 Subject: [Nitro] Glue to facets plan Message-ID: As Tom proposed (and several other members of the community agreed upon) we are about to replace Glue with Facets. The idea is to extract the generally useful bits into Facets and put the rest into the nitro or og directories. Here is how I propose that we handle the Glue -> Facets transition: - Move the following files into Facets: accumulate.rb aspects.rb builder.rb builder/* configuration.rb on_included.rb property.rb settings.rb template.rb cache.rb cache/* logger.rb - Change the code to use equivalent Facets functionality instead of the following files: paramix.rb attribute.rb autoreload.rb expirable.rb flexob.rb sanitize.rb uri.rb html.rb - Move the following files in nitro dir: markup.rb mail.rb mailer.rb mailer/* localization.rb - Move the following files in og dir: validation.rb (merge with og/validation.rb) As I am short on time, may I propose that Tom and Bryan can work on this plan, and I can finish the job and make sure everything works afterwards? Especially I would like to ask Tom to move the requested files into facets. best regards, George. From george.moschovitis at gmail.com Mon Apr 10 13:00:04 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 20:00:04 +0300 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Message-ID: Wow ;-) -g. PS: funny name btw ;-) On 4/10/06, TRANS wrote: > Thanks to a couple of posts on Ruby-talk, especially one about using > cattr in modules, I believe I've surpassed myself with this gem that > should (unless I missed something) be able to usurp classinherit.rb. > > Thing is, once again I gotta come up with a beter name! > > > require 'facets/core/module/basename' > > class Module > > def interlude( mod ) > ext = Module.new # extension module > const_set( "Ex#{mod.basename}", ext ) > smethods = mod.singleton_methods > smethods -= ['included'] if Class === mod > smethods.each do |m| > ext.class_eval do > define_method(m, &(mod.method(m))) > end > end > extend ext unless smethods.empty? > include mod > nil > end > > end > > try it: > > module M > def self.s ; 1 ; end > def s ; 2 ; end > end > > module Q > interlude M > end > > class R > interlude Q > end > > R.s #=> 1 > R.new.s #=> 2 > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Mon Apr 10 13:09:58 2006 From: transfire at gmail.com (TRANS) Date: Mon, 10 Apr 2006 13:09:58 -0400 Subject: [Nitro] Glue to facets plan In-Reply-To: References: Message-ID: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> Yep. I can do that :-) Nice layout for the plan BTW. T. From george.moschovitis at gmail.com Mon Apr 10 13:13:14 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 20:13:14 +0300 Subject: [Nitro] Glue to facets plan In-Reply-To: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> References: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> Message-ID: > Nice layout for the plan BTW. Yeah I am learning a few organization tricks from Bryan ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Apr 10 13:24:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 20:24:34 +0300 Subject: [Nitro] [PATCH] Some new patches/features by me ;-) Message-ID: Dear devs, here are some new patches, hopefully Bryan can integrate them. More to come ;-) Mon Apr 10 13:58:55 EEST 2006 George Moschovitis * Moved top level repo scripts in script Mon Apr 10 13:56:45 EEST 2006 George Moschovitis * Cleaned up tabs. Mon Apr 10 13:26:23 EEST 2006 George Moschovitis * Updated AUTHORS. Mon Apr 10 13:21:55 EEST 2006 George Moschovitis * Add some simple options to the session vcr: --record session.yaml and --playback session .yaml, enjoy ;-) Mon Apr 10 13:08:42 EEST 2006 George Moschovitis * Keep the rendering level in the context to allow for conditional rendering on top_level actions (very useful ;-)). Mon Apr 10 12:01:44 EEST 2006 George Moschovitis * Small updates in docs. Sun Apr 9 12:23:08 EEST 2006 George Moschovitis * Cleaned up router implementation, added more intuitive 'global' setup (see rdocs). [jame s_b] Sun Apr 9 11:27:58 EEST 2006 George Moschovitis * Better error report when a relation uses a non-existant class as the target. Sat Apr 8 20:39:04 EEST 2006 George Moschovitis * Implemented absolutely magical record/playback functionality in the Webrick adapter to a llow for fully automatic webapp testing. Use your browser to 'record' your test run of the a pplication and playback many times to assert that it works as expected. Sat Apr 8 10:35:30 EEST 2006 George Moschovitis * Updated to prototype 1.5.0_rc0 / Scriptaculous 1.6.1 regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 39901 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060410/da5bdbf5/attachment.zip From bryan.a.soto at gmail.com Mon Apr 10 13:37:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 10:37:21 -0700 Subject: [Nitro] [PATCH] Some new patches/features by me ;-) In-Reply-To: References: Message-ID: I'll try to get these and your previous patchset in today. I've been busy with Postgres/Og and didn't really get to anything else, but On 4/10/06, George Moschovitis wrote: > Mon Apr 10 13:21:55 EEST 2006 George Moschovitis > * Add some simple options to the session vcr: --record session.yaml > and --playback session .yaml, enjoy ;-) > > Sat Apr 8 20:39:04 EEST 2006 George Moschovitis > * Implemented absolutely magical record/playback functionality in > the Webrick adapter to a llow for fully automatic webapp testing. Use > your browser to 'record' your test run of the a pplication and > playback many times to assert that it works as expected. > if you find some time, could you do a screen cast to show this? It sounds like it could be something to advertise. :) Thanks! Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From zimba.tm at gmail.com Mon Apr 10 13:43:20 2006 From: zimba.tm at gmail.com (zimba-tm) Date: Mon, 10 Apr 2006 19:43:20 +0200 Subject: [Nitro] Glue to facets plan In-Reply-To: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> References: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> Message-ID: <3ff63f9b0604101043x16ee28fdme371053789df4a80@mail.gmail.com> Btw. Will you move your repos to devlab finally ? I think it couldmake development easier. We wouldn't need to ask your to submit somefixes to facets. On 10/04/06, TRANS wrote:> Yep. I can do that :-)>> Nice layout for the plan BTW.>> T.>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> --Cheers, zimba http://zimba.oree.ch From george.moschovitis at gmail.com Mon Apr 10 13:43:20 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Apr 2006 20:43:20 +0300 Subject: [Nitro] [PATCH] Some new patches/features by me ;-) In-Reply-To: References: Message-ID: > I'll try to get these and your previous patchset in today. I've been > busy with Postgres/Og and didn't really get to anything else, but please dont integrate your posrgres patch into the repo yet! > if you find some time, could you do a screen cast to show this? It > sounds like it could be something to advertise. :) very easy: ruby run.rb --record mysession.yaml then use your browser to visit your site, hit pages and 'create' a nice test session. on exit a file mysession.yaml is created that contains the request stream and time deltas. then if you type: ruby run.rb --playback mysession.yaml webrick gets the input from this file instead of the socket and replays the session, at the end it emmits errors etc. in the future we can add output compares, or benchmarks and some other ideas. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Mon Apr 10 13:58:41 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 10:58:41 -0700 Subject: [Nitro] [PATCH] Some new patches/features by me ;-) In-Reply-To: References: Message-ID: On 4/10/06, George Moschovitis wrote: > > I'll try to get these and your previous patchset in today. I've been > > busy with Postgres/Og and didn't really get to anything else, but > > please dont integrate your posrgres patch into the repo yet! > > No plans too. I was hoping Rob could give them a thrashing as he's the current Og/Postgres guru. :) > > if you find some time, could you do a screen cast to show this? It > > sounds like it could be something to advertise. :) > > very easy: > That was easy. :) I think I'll try scripting some of the examples. It'd make testing them alot easier. Very nice! -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 10 15:43:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 12:43:36 -0700 Subject: [Nitro] Glue to facets plan In-Reply-To: References: <4b6f054f0604101009j362bcf85g84a91e5a1b1886fa@mail.gmail.com> Message-ID: On 4/10/06, George Moschovitis wrote: > > Nice layout for the plan BTW. > > Yeah I am learning a few organization tricks from Bryan ;-) > /me looks at desk. I assume you're learning what not to do, right? ;) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 10 17:45:31 2006 From: transfire at gmail.com (TRANS) Date: Mon, 10 Apr 2006 17:45:31 -0400 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <3ff63f9b0604100948i479ac6edg97beb8ab24527491@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <3ff63f9b0604100948i479ac6edg97beb8ab24527491@mail.gmail.com> Message-ID: <4b6f054f0604101445s3d69db37i74f710b824f54a25@mail.gmail.com> On 4/10/06, zimba-tm wrote: > oooh nice ! > some name propositions :* class_include* include_all* singleton_include > It should express that you include the class with it's singleton methods. > Now the question arises : how do you note that a module in designed tobe > included with it's singleton-class methods ? Hmm.. good question. Well it just doesn't seem to be the "Ruby Way" to do so. Really I'm not sure why 'interlude' isn't essentially include's behavior already. I've examined the posssible backward compatability issues it could cause and they're extremely remote; only arising if some code is depending on a superclass class method and a module later gets stuck in between with a class method of the same name --not likely. But also that's exactly the behavior we want in other cases, but have to do in special ways. One way it could be done it is to have a psuedo-mixin like: module M is ClassInheritable ... end Then modify #include to see that this is a class inheritable module and use 'interlude' behavior instead. But even though that makes sense conceptually, it is still an obvious hack b/c ClassInheritable isn't actually a real module, it's just a "tag" of sorts. So I think it may just be better just to have the separate method, that way it can be used in general and one can aways back peddle to #include when THAT specific bahavior is needed. So what if we just call this new method #is? T. From bryan.a.soto at gmail.com Mon Apr 10 18:35:13 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 15:35:13 -0700 Subject: [Nitro] [PATCH] Some new patches/features by me ;-) In-Reply-To: References: Message-ID: I've applied these to devlab. On 4/10/06, George Moschovitis wrote: > Dear devs, > > here are some new patches, hopefully Bryan can integrate them. > More to come ;-) > > > Mon Apr 10 13:58:55 EEST 2006 George Moschovitis > * Moved top level repo scripts in script > > Mon Apr 10 13:56:45 EEST 2006 George Moschovitis > * Cleaned up tabs. > > Mon Apr 10 13:26:23 EEST 2006 George Moschovitis > * Updated AUTHORS. > > Mon Apr 10 13:21:55 EEST 2006 George Moschovitis > * Add some simple options to the session vcr: --record session.yaml > and --playback session .yaml, enjoy ;-) > > Mon Apr 10 13:08:42 EEST 2006 George Moschovitis > * Keep the rendering level in the context to allow for conditional > rendering on top_level actions (very useful ;-)). > > Mon Apr 10 12:01:44 EEST 2006 George Moschovitis > * Small updates in docs. > > Sun Apr 9 12:23:08 EEST 2006 George Moschovitis > * Cleaned up router implementation, added more intuitive 'global' > setup (see rdocs). [jame s_b] > > Sun Apr 9 11:27:58 EEST 2006 George Moschovitis > * Better error report when a relation uses a non-existant class as the target. > > Sat Apr 8 20:39:04 EEST 2006 George Moschovitis > * Implemented absolutely magical record/playback functionality in > the Webrick adapter to a llow for fully automatic webapp testing. Use > your browser to 'record' your test run of the a pplication and > playback many times to assert that it works as expected. > > Sat Apr 8 10:35:30 EEST 2006 George Moschovitis > * Updated to prototype 1.5.0_rc0 / Scriptaculous 1.6.1 > > > > regards, > George. > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 10 18:37:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 15:37:00 -0700 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <4b6f054f0604101445s3d69db37i74f710b824f54a25@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <3ff63f9b0604100948i479ac6edg97beb8ab24527491@mail.gmail.com> <4b6f054f0604101445s3d69db37i74f710b824f54a25@mail.gmail.com> Message-ID: On 4/10/06, TRANS wrote: > So what if we just call this new method #is? > Isn't #is already used as an alias to include? Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 10 19:59:30 2006 From: transfire at gmail.com (TRANS) Date: Mon, 10 Apr 2006 19:59:30 -0400 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <3ff63f9b0604100948i479ac6edg97beb8ab24527491@mail.gmail.com> <4b6f054f0604101445s3d69db37i74f710b824f54a25@mail.gmail.com> Message-ID: <4b6f054f0604101659v6a1e7bb3xdaf64761b16d1d04@mail.gmail.com> On 4/10/06, Bryan Soto wrote: > On 4/10/06, TRANS wrote: > > So what if we just call this new method #is? > > > > Isn't #is already used as an alias to include? Exactly. Notice that the heart of 'interlude' is include. It just adds the class-level methods too IF ANY. This makes the inheritance of modules equivalent to that of classes. T. From bryan.a.soto at gmail.com Mon Apr 10 20:34:57 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 17:34:57 -0700 Subject: [Nitro] Web App Testing with Selenium Message-ID: A flash movie link that manveru asked me to post. Enjoy. :) http://wiki.openqa.org/download/attachments/400/Selenium+IDE.swf?version=1 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 10 21:04:54 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 10 Apr 2006 18:04:54 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443A4D8D.4000202@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> Message-ID: On 4/10/06, Andrew Thompson wrote: > Bryan Soto wrote: > > Well, let's open a ticket so I don't forget. I've got to finish up > > with bugs and patches, but this is something I'd like. If nobody else > > joins in, I'd be happy to help try. I'm not a Nitro expert, but > > perhaps between the two of us, we can figure it out. :) > > > > Bryan > > Sounds good, I'm not familiar with trac but I can try to do a ticket if > you'd prefer... > > Andrew > I think there is a setting, Router.strip_path that is supposed to do this. It looks like the code that did the actual strip was removed. I'm assuming that was a mistake since the setting wasn't removed. Let me see if I can figure it out. Are you using 29.0 or the darcs repo? I'm hoping you can test a patch for me. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From itsme213 at hotmail.com Mon Apr 10 22:20:49 2006 From: itsme213 at hotmail.com (itsme213) Date: Mon, 10 Apr 2006 21:20:49 -0500 Subject: [Nitro] Better than classinherit.rb! References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Message-ID: Nice! A couple of questions: - Breaks if mod is enhanced with singleton methods after interlusion? - Do you know any hooks that would enable the inverse operation: R.is_not(M) There are advantages to your older ClassMethods (and less so InstanceMethods) convention, since they require a module holding methods uniformly for either classes or 'other' objects. I have been doing the following. Could probably be simplified further by someone more expert than I ... class Module # TODO: no need for InstanceMethods sub-module # just define module methods directly. def inherit *others others.each do |other| [:ClassMethods, :InstanceMethods].each do |sub_mod| if other.const_defined? sub_mod if self.const_defined? sub_mod self.const_get(sub_mod).send(:include, other.const_get(sub_mod)) else sm = Module.new self.const_set sub_mod, other.const_get(sub_mod) end end end include other end end end class Class def inherit *others others.each do |other| extend other::ClassMethods if defined? other::ClassMethods include other::InstanceMethods if defined? other::InstanceMethods super end end end if __FILE__ == $0 class Object def assert x raise "Failed" unless x end end module A module ClassMethods def cm1 end end module InstanceMethods def im1 end end CONST = 0 def m1 end # def self.m2 # end end assert A::ClassMethods.instance_method(:cm1) assert A.instance_method(:m1) module A1 module ClassMethods def cma1 end end end module B inherit A assert B::ClassMethods assert B::InstanceMethods assert defined? B::CONST assert B::instance_method(:m1) module ClassMethods def cm2 end end assert B::ClassMethods.instance_method(:cm1) assert B::ClassMethods.instance_method(:cm2) module InstanceMethods def im2 end end inherit A1 assert B::ClassMethods.instance_method(:cma1) end assert B::InstanceMethods.instance_method(:im1) assert B::InstanceMethods.instance_method(:im2) class X inherit B assert X.method(:cm1) assert X.instance_method(:im1) assert X.instance_method(:m1) end end From transfire at gmail.com Tue Apr 11 00:25:58 2006 From: transfire at gmail.com (TRANS) Date: Tue, 11 Apr 2006 00:25:58 -0400 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Message-ID: <4b6f054f0604102125w68d02be4jbc47fec9ec8b0358@mail.gmail.com> On 4/10/06, itsme213 wrote: > Nice! > > A couple of questions: > - Breaks if mod is enhanced with singleton methods after interlusion? Yes that's true (seemingly there is always a shortcoming no matter what you do!) So this solution, while robust, suffers from non-dynamics. I tried a fix this shortcoming this evening but the solution opens up an infinite loop --and is getting increasingly more hackish :-(. I'll see if I can't close the loop on Thursday. Beyond that I should point out that I quickly was able to adjust Ruby's source code to this --it's simply a matter of letting Ruby extend using an eigenclass. class X extend (class << FooModule; self ; end) end which actually leads to including classes just like one does modules (although it could be limited to one method like #interlude easily enough) . It works perfectly and all Ruby's test cases pass with the change in place. It's really a shame Matz has some sort of theoretical grudge against this possibility. How many man-hours could have been saved!!!!!!!! > - Do you know any hooks that would enable the inverse operation: R.is_not(M) You mean uninclude? I don't think it's possible. You can always copy and undefine methods but obviously that's not the same thing. The Ruby source code itself has a problem here in the way it works, so I'm not sure it would ever be possible --it is related to the Dynamic Module Problem: Module's themselves are only dynamic upto two layers of inclusion for any including object after it has been instantiated). > There are advantages to your older ClassMethods (and less so > InstanceMethods) convention, since they require a module holding methods > uniformly for either classes or 'other' objects. I have been doing the > following. Could probably be simplified further by someone more expert than > I ... Yes. That has advanages of it's own. Unfortuately it has it's own corner casses too --it won't work with cattr for instance. At this point --and maybe forever, all one can do is pick the hack that works best for the given situation (and pray everyone's choices don't come crashing down on each other ;-) T. From transfire at gmail.com Tue Apr 11 00:29:10 2006 From: transfire at gmail.com (TRANS) Date: Tue, 11 Apr 2006 00:29:10 -0400 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: References: Message-ID: <4b6f054f0604102129o79bd942h981efe7eb48b9820@mail.gmail.com> > http://wiki.openqa.org/download/attachments/400/Selenium+IDE.swf?version=1 V. Cool! T. From aglarond at gmail.com Tue Apr 11 03:02:17 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Tue, 11 Apr 2006 09:02:17 +0200 Subject: [Nitro] replacement transformer Message-ID: <55c107bf0604110002m9f2cfa6xe37f7c7e32bfd98e@mail.gmail.com> Hi All, I was looking through the source code, and oxyliquit, to see if I could find something like this: class MyController < Nitro::Controller def index replace = Nitro::ReplaceTransformer.new( 'default.xhtml' ) replace.div( :content, :mylink ) replace.a( :href => "/mylink", :class => "current" ) replace.transform end end Meaning basically, that you have a map routing from "/mylink" to MyController. The 'index' page is called, and transforms the 'default.xhtml' template in the following way: - the content of the 'div' with 'id'="content" gets replaced with the contents of a file 'mylink' (located in a globally-defined place, like Nitro.transformer_root or something) - the 'a' with 'href'="/mylink" gets the 'class' attribute added to it, with value "current" - important: both the 'div' and the 'a' tags themselves remain in the transformed file, for eventual processing by another compiler in the pipeline or delivery to a cache file/web browser Does anyone know how to do something like this with the current (repo-version) Nitro? I just wanted to check before I go re-inventing the wheel. I know that this type of behavior has been requested by others, I just don't recall if it's been implemented yet. Thanks, - Dimitri From james_b at neurogami.com Tue Apr 11 03:46:12 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 11 Apr 2006 00:46:12 -0700 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: References: Message-ID: <443B5EC4.1060403@neurogami.com> Bryan Soto wrote: > A flash movie link that manveru asked me to post. Enjoy. :) > > http://wiki.openqa.org/download/attachments/400/Selenium+IDE.swf?version=1 > Pretty sweet. I forgot I ad the installed. I poke around with Selenium about a week ago, nothing too involved. I've been using WATIR plus my own custom DSL on top of it to do integration testing, but Selenium looks nicer (plus it can use Firefox). This browser recorder thing kicks ass. But I found this autogenerated code amusing: class NewTest def test_foo open "/" assertTitle "james britt" assertTextPresent "Gee, I Hope They" end end Shame about the lowerCamelCase methodNames But thanks for reminding me to go lookat this more. Saves much time and trouble! -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From vagabond at cataclysm-software.net Tue Apr 11 08:22:16 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 11 Apr 2006 08:22:16 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> Message-ID: <443B9F78.9050405@cataclysm-software.net> Bryan Soto wrote: > I think there is a setting, Router.strip_path that is supposed to do > this. It looks like the code that did the actual strip was removed. > I'm assuming that was a mistake since the setting wasn't removed. Let > me see if I can figure it out. Are you using 29.0 or the darcs repo? > I'm hoping you can test a patch for me. :) I *was* using 0.29, but with all the poking around I did its probably something else by now. I can revert it to the gems or try to figure out darcs if you need me to. Andrew From itsme213 at hotmail.com Tue Apr 11 11:28:52 2006 From: itsme213 at hotmail.com (itsme213) Date: Tue, 11 Apr 2006 10:28:52 -0500 Subject: [Nitro] Better than classinherit.rb! References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <4b6f054f0604102125w68d02be4jbc47fec9ec8b0358@mail.gmail.com> Message-ID: From: "TRANS" > How many man-hours could have been > saved!!!!!!!! Sounds like a great candidate for the 1.9/2.0 stream ... but then what do I know ! >> - Do you know any hooks that would enable the inverse operation: >> R.is_not(M) > source code itself has a problem here in the way it works, so I'm not > sure it would ever be possible --it is related to the Dynamic Module > Problem: Module's themselves are only dynamic upto two layers of > inclusion for any including object after it has been instantiated). Ouch. >> There are advantages to your older ClassMethods (and less so >> InstanceMethods) convention, since they require a module holding methods >> uniformly for either classes or 'other' objects. I have been doing the >> following. Could probably be simplified further by someone more expert >> than >> I ... > > Yes. That has advanages of it's own. Unfortuately it has it's own > corner casses too --it won't work with cattr for instance. I think by having each ClassMethods module know about it's corresponding InstanceMethods module one could make cattr work. But I think class variables should be banned in any scheme that properly does ClassMethods and InstanceMethods. From bryan.a.soto at gmail.com Tue Apr 11 14:17:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 11:17:24 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443B9F78.9050405@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> Message-ID: On 4/11/06, Andrew Thompson wrote: > Bryan Soto wrote: > > I think there is a setting, Router.strip_path that is supposed to do > > this. It looks like the code that did the actual strip was removed. > > I'm assuming that was a mistake since the setting wasn't removed. Let > > me see if I can figure it out. Are you using 29.0 or the darcs repo? > > I'm hoping you can test a patch for me. :) > > I *was* using 0.29, but with all the poking around I did its probably > something else by now. I can revert it to the gems or try to figure out > darcs if you need me to. > Yeah, my 0.29 isn't exactly standard either. :) I think this patch and setting Nitro::Router.strip_path = '/portion_of_path_to_remove_goes_here' in your run.rb file will do it. It routes correctly, so I'm hoping that everything else will work from there. You might need to re-install the gems though, depending on the changes you made. Let me know if it works or if it has any problems. Hopefully I can help. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: router.patch Type: text/x-patch Size: 617 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060411/5979f834/attachment.bin From bryan.a.soto at gmail.com Tue Apr 11 15:00:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 12:00:40 -0700 Subject: [Nitro] replacement transformer In-Reply-To: <55c107bf0604110002m9f2cfa6xe37f7c7e32bfd98e@mail.gmail.com> References: <55c107bf0604110002m9f2cfa6xe37f7c7e32bfd98e@mail.gmail.com> Message-ID: On 4/11/06, Dimitri Aivaliotis wrote: > Does anyone know how to do something like this with the current > (repo-version) Nitro? > About the best I can think of would be to define the fragments you want to render, i.e @content = :mylink, in your controller, then in your view , where :mylink would be stored in a file, mylink.xhtml. The class for the href could be handled similarly, i.e. @a_class = 'current', then in the view, link. Or perhaps as elements? I wonder if <#{@element} /> works? I'm assuming you knew that though and that wasn't what you were looking for. :) > I just wanted to check before I go re-inventing the wheel. I know > that this type of behavior has been requested by others, I just don't > recall if it's been implemented yet. > I guess you're basically looking for a way to pre-process templates with the controller actions before they go through normal processing. I don't think there's anything like that currently. Rather fine grained control too going by your code fragment. *sigh* Now you've got me intrigued and I've got glue files to move. :) I don't know how badly you need this, but perhaps rendering via instance variables would work for now if it's a prototype? I suspect plugging in a template transformer the way you specified would be a bit harder to do... Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Tue Apr 11 15:25:45 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 11 Apr 2006 15:25:45 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> Message-ID: <443C02B9.3020006@cataclysm-software.net> Bryan Soto wrote: > Yeah, my 0.29 isn't exactly standard either. :) > > I think this patch and setting > > Nitro::Router.strip_path = '/portion_of_path_to_remove_goes_here' > > in your run.rb file will do it. It routes correctly, so I'm hoping > that everything else will work from there. You might need to > re-install the gems though, depending on the changes you made. > > Let me know if it works or if it has any problems. Hopefully I can help. :) > > Bryan This *kinda* works (you had a sub instead of a sub! in your patch). I had to hack redirect too because it was redirecting to the document root. It seems to otherwise work except that links are also incorrect. I guess I'd have to dive into the template code to fix that bit... Andrew From bryan.a.soto at gmail.com Tue Apr 11 16:29:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 13:29:26 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443C02B9.3020006@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: On 4/11/06, Andrew Thompson wrote: > This *kinda* works (you had a sub instead of a sub! in your patch). I > had to hack redirect too because it was redirecting to the document > root. It seems to otherwise work except that links are also incorrect. I > guess I'd have to dive into the template code to fix that bit... > Oops, thanks on the sub!. Obviously my unit tests need some work... Good point on the redirects. I've attached a patch for redirect_home. Does redirect_referer work? I can't tell by eyeballing it... With your views, I think if you use encode_url (R is an alias to it), you'll get integration with the doc root stuff. Has the benefit too that you don't have to update all the urls if you ever move to a new directory or change a mount point. :) # Encode controller, action, params into a valid url. # Automatically respects nice urls and routing. # # Handles parameters either as a hash or as an array. # Use the array method to pass parameters to 'nice' actions. # # Pass Controller, action, and (param_name, param_value) # pairs. # # === Examples # # encode_url ForaController, :post, :title, 'Hello', :body, 'World' # encode_url :post, :title, 'Hello', :body, 'World' # => implies controller == self # encode_url :kick, :oid, 4 Hope that helps, Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: render.patch Type: text/x-patch Size: 654 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060411/0046dabf/attachment.bin From bryan.a.soto at gmail.com Tue Apr 11 16:34:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 13:34:36 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: On 4/11/06, Bryan Soto wrote: > Good point on the redirects. I've attached a patch for redirect_home. > Does redirect_referer work? I can't tell by eyeballing it... > Okay, that patch can't even run the unit tests... Don't even waste your time with it. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Tue Apr 11 16:38:16 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 11 Apr 2006 16:38:16 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443C02B9.3020006@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: <443C13B8.5010302@cataclysm-software.net> Hmm, I'm stuck on the link problem, I guess the browser is to blame because nitro just passes along the links as-is and the browser is tasked with resolving em to absolutes... Is it possible the HTTP response contains something that tells the browser how to do this? I simply don't know how how this works... I've tried looking at the HTTP traffic and I don't see anything that looks relevant. Andrew From bryan.a.soto at gmail.com Tue Apr 11 16:40:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 13:40:09 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: Okay, let's try again. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: render.patch Type: text/x-patch Size: 651 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060411/40ed3c34/attachment.bin From vagabond at cataclysm-software.net Tue Apr 11 16:44:59 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 11 Apr 2006 16:44:59 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: <443C154B.5050105@cataclysm-software.net> Bryan Soto wrote: > Okay, that patch can't even run the unit tests... Don't even waste > your time with it. Just a shot in the dark, but maybe a url.squeeze!('/') might fix it? Andrew From aglarond at gmail.com Tue Apr 11 16:48:19 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Tue, 11 Apr 2006 22:48:19 +0200 Subject: [Nitro] replacement transformer In-Reply-To: References: <55c107bf0604110002m9f2cfa6xe37f7c7e32bfd98e@mail.gmail.com> Message-ID: <55c107bf0604111348h530869b1x57d84c4eca9f526e@mail.gmail.com> On 4/11/06, Bryan Soto wrote: > *sigh* Now you've got me intrigued and I've got glue files to move. :) > > I don't know how badly you need this, but perhaps rendering via > instance variables would work for now if it's a prototype? I suspect > plugging in a template transformer the way you specified would be a > bit harder to do... I've actually got an implementation half coded-up. I'll send a bundle when it's finished and tested. I just wanted to make sure that nobody's done this already before I spent the time working on it. - Dimitri From bryan.a.soto at gmail.com Tue Apr 11 17:07:33 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 14:07:33 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443C13B8.5010302@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C13B8.5010302@cataclysm-software.net> Message-ID: On 4/11/06, Andrew Thompson wrote: > Hmm, I'm stuck on the link problem, I guess the browser is to blame > because nitro just passes along the links as-is and the browser is > tasked with resolving em to absolutes... Is it possible the HTTP > response contains something that tells the browser how to do this? > > I simply don't know how how this works... I've tried looking at the HTTP > traffic and I don't see anything that looks relevant. > Could you explain exactly what's happening with the links? Perhaps an example would help me understand what's wrong. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Tue Apr 11 17:12:21 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 11 Apr 2006 17:12:21 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> Message-ID: <443C1BB5.4050302@cataclysm-software.net> Bryan Soto wrote: > With your views, I think if you use encode_url (R is an alias to it), > you'll get integration with the doc root stuff. Has the benefit too > that you don't have to update all the urls if you ever move to a new > directory or change a mount point. :) This ain't working for me, I just get /#/login when I use rewrite_url. It looks like the call of mount_point on the annotation is returning Null. Anyway I'm done for today... Andrew From bryan.a.soto at gmail.com Tue Apr 11 17:20:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 14:20:51 -0700 Subject: [Nitro] Problem with Og enchantments. Message-ID: I started with the Glue removal by moving the validations to Og. Before the move, I had one failure (a test for memcached). After the move, the tests consistently refuse to run with the following error message: /mnt/zip/nitro.glue-move/og/lib/og/entity.rb:514:in `method_missing': undefined method `table' for TC_Join::ArticleToCategory:Class (NoMethodError) from /mnt/zip/nitro.glue-move/og/lib/og/relation/joins_many.rb:40:in `enchant' from /mnt/zip/nitro.glue-move/og/lib/og/relation.rb:246:in `enchant' from /mnt/zip/nitro.glue-move/og/lib/og/relation.rb:244:in `enchant' from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:158:in `manage' from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:233:in `manage_classes' from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:233:in `manage_classes' from ./test/og/tc_join.rb:46 from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5 from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5 If I run that test case by itself, it passes. The test case looks like this (remeber this test passed before): =begin tc_join.rb class Article property :title, String joins_many :first_join, Category, :through => ArticleToCategory joins_many :second_join, Category, :through => ArticleToCategory joins_many :third_join, Category, :table => :ogj_article_category_third joins_many :fourth_join, Category, :table => :ogj_article_category_fourth joins_many Category def initialize(title) @title = title end end class ArticleToCategory property :rate, Float property :hits, Fixnum has_one Article has_one Category end =end If I move the definition of ArticleToCategory to before Article, the tests again pass. Maybe we should hold off on the glue move and concentrate on the enchantments? Perhaps, George, that problem you ran into when trying to optimize Og startup was a real problem? Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 11 17:21:59 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 14:21:59 -0700 Subject: [Nitro] replacement transformer In-Reply-To: <55c107bf0604111348h530869b1x57d84c4eca9f526e@mail.gmail.com> References: <55c107bf0604110002m9f2cfa6xe37f7c7e32bfd98e@mail.gmail.com> <55c107bf0604111348h530869b1x57d84c4eca9f526e@mail.gmail.com> Message-ID: On 4/11/06, Dimitri Aivaliotis wrote: > I've actually got an implementation half coded-up. I'll send a bundle > when it's finished and tested. I just wanted to make sure that > nobody's done this already before I spent the time working on it. > Okay then. I'll look forward to it. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 11 18:42:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 15:42:08 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443C1BB5.4050302@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> Message-ID: On 4/11/06, Andrew Thompson wrote: > Bryan Soto wrote: > > With your views, I think if you use encode_url (R is an alias to it), > > you'll get integration with the doc root stuff. Has the benefit too > > that you don't have to update all the urls if you ever move to a new > > directory or change a mount point. :) > > This ain't working for me, I just get /#/login when > I use rewrite_url. It looks like the call of mount_point on the > annotation is returning Null. > Well, it did say it was experimental. :/ > Anyway I'm done for today... > One last attempt for me. Well two cause there's two patches. One for controller.rb (rather than squeeze, I just took out the leading forward slash) and dispatcher.rb (on controller mount I set that annotation). /me crosses fingers for good news. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: controller.patch Type: text/x-patch Size: 447 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060411/a34978ff/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: dispatcher.patch Type: text/x-patch Size: 356 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060411/a34978ff/attachment-0001.bin From bryan.a.soto at gmail.com Wed Apr 12 01:00:02 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 22:00:02 -0700 Subject: [Nitro] Problem with Og enchantments. In-Reply-To: References: Message-ID: And just for fun, the test suite that failed on Linux ran fine on Windows. No changes. I'll be sending the patch as I'm curious if anyone else has problems with it. On 4/11/06, Bryan Soto wrote: > I started with the Glue removal by moving the validations to Og. > Before the move, I had one failure (a test for memcached). After the > move, the tests consistently refuse to run with the following error > message: > > /mnt/zip/nitro.glue-move/og/lib/og/entity.rb:514:in `method_missing': > undefined method `table' for TC_Join::ArticleToCategory:Class > (NoMethodError) > from /mnt/zip/nitro.glue-move/og/lib/og/relation/joins_many.rb:40:in > `enchant' > from /mnt/zip/nitro.glue-move/og/lib/og/relation.rb:246:in `enchant' > from /mnt/zip/nitro.glue-move/og/lib/og/relation.rb:244:in `enchant' > from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:158:in `manage' > from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:233:in > `manage_classes' > from /mnt/zip/nitro.glue-move/og/lib/og/manager.rb:233:in > `manage_classes' > from ./test/og/tc_join.rb:46 > from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5 > from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5 > > If I run that test case by itself, it passes. The test case looks like > this (remeber this test passed before): > > =begin tc_join.rb > class Article > property :title, String > > joins_many :first_join, Category, :through => ArticleToCategory > joins_many :second_join, Category, :through => ArticleToCategory > joins_many :third_join, Category, :table => :ogj_article_category_third > joins_many :fourth_join, Category, :table => :ogj_article_category_fourth > joins_many Category > > def initialize(title) > @title = title > end > end > > class ArticleToCategory > property :rate, Float > property :hits, Fixnum > has_one Article > has_one Category > end > =end > > If I move the definition of ArticleToCategory to before Article, the > tests again pass. > > Maybe we should hold off on the glue move and concentrate on the > enchantments? Perhaps, George, that problem you ran into when trying > to optimize Og startup was a real problem? > > Bryan > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 12 01:04:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 11 Apr 2006 22:04:24 -0700 Subject: [Nitro] [PATCH] glue-validations-to-og Message-ID: Attached patch moves all code from glue/validation.rb to og/validation.rb. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: glue-validations-to-og.zip Type: application/zip Size: 19921 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060412/efa95ee7/attachment.zip From aglarond at gmail.com Wed Apr 12 03:18:11 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Wed, 12 Apr 2006 09:18:11 +0200 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: Message-ID: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> Hi Bryan, On 4/12/06, Bryan Soto wrote: > Attached patch moves all code from glue/validation.rb to og/validation.rb. Apply the patch didn't cause any further errors for me. Note, though, that I already had to rename a number of files because of various errors: tc_inheritance.rb tc_inheritance2.rb tc_override.rb tc_polymorphic.rb tc_reverse.rb tc_store.rb The problems were either PostgreSQL-STI related, no 'exec' for KirbyBase or because I don't have SQLite installed (the tests really shouldn't assume this). Without renaming the files, the test suite would'nt complete. I'm running on Linux with the latest devlab repo. This is the top of my CONFIG.rb: configA = :psql # FOR MULTI-TESTS configB = :kirby # SET THIS TO true TO ENABLE EXTRA DEBUG CODE debug = true With the file rename, both before and after the patch, I got: 1) Error: test_all(TC_OgAggrCalc): NoMethodError: undefined method `to_f' for ["58"]:Array nitrohq/og/lib/og/store/sql.rb:532:in `calculate' nitrohq/og/lib/og/store/psql.rb:139:in `each_row' nitrohq/og/lib/og/store/psql.rb:138:in `each_row' nitrohq/og/lib/og/store/sql.rb:531:in `calculate' nitrohq/og/lib/og/entity.rb:267:in `calculate' nitrohq/og/lib/og/entity.rb:305:in `sum' ./test/og/tc_aggregations_calculations.rb:39:in `test_all' 2) Failure: test_all(TestMultiple) [./test/og/tc_multiple.rb:37]: is not true. 35 tests, 138 assertions, 1 failures, 1 errors I don't have the time at the moment to follow up and fix the test cases/libraries so that they'll all complete successfully. I just wanted to give some quick feedback on the patch (it works!), and provide this info in case somebody else had time to do the follow-up. - Dimitri From zimba.tm at gmail.com Wed Apr 12 07:34:07 2006 From: zimba.tm at gmail.com (zimba-tm) Date: Wed, 12 Apr 2006 13:34:07 +0200 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> Message-ID: <3ff63f9b0604120434t62517f94x394313481457729f@mail.gmail.com> Method names ideas : * merge* mixin --Cheers, zimba http://zimba.oree.ch From zimba.tm at gmail.com Wed Apr 12 07:57:55 2006 From: zimba.tm at gmail.com (zimba-tm) Date: Wed, 12 Apr 2006 13:57:55 +0200 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <3ff63f9b0604120434t62517f94x394313481457729f@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <3ff63f9b0604120434t62517f94x394313481457729f@mail.gmail.com> Message-ID: <3ff63f9b0604120457gb879147wacd1c8e3c09b6dd5@mail.gmail.com> What would be needed instead of redefining all the methods is toaccess directly to the singleton-class. Something like : class Module def mixin(mod) include mod extend mod.singleton_class end end et voila ! :-p (only the problem is that mod.singleton_class doesn't exist) --Cheers, zimba http://zimba.oree.ch From m.fellinger at gmail.com Wed Apr 12 09:24:49 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Wed, 12 Apr 2006 22:24:49 +0900 Subject: [Nitro] [PATCH] Logger.debug woe Message-ID: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Hey all, I finally sat down, after hearing lots of complains from various sides, and added the 'if $DBG' statement at all the Logger.debug outputs where it was missing, except for the logger-testcase where it might make sense, didn't have a closer look tho.. to trace the missing statements down i used: ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ /_darcs/}' maybe that's something to add to a testcase and trace down missing statements if they occur again... Hope it doesn't break anything, and i'm not sure if all the Logger.debug for the kind-of-session-noticing need that too, but here it is :) ~~~~manveru -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tar.gz Type: application/x-gzip Size: 14643 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060412/10fb0259/attachment.gz From vagabond at cataclysm-software.net Wed Apr 12 09:43:16 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Wed, 12 Apr 2006 09:43:16 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <44366014.4080605@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> Message-ID: <443D03F4.3090905@cataclysm-software.net> I fixed the link issue, a base tag in the html HEAD fixed things. It turns out I don't need the R thing because with the base set correctly things just work(tm). I'm not convinced it'll work with Router.strip_path though, just by looking at it. I also think your patch to redirect_home does more harm than good, I've already hacked redirect() itself so when redirect_home() calls redirect it all goes wrong. I'm satisfied with nitro running in a subdir, though I'd like to be able to run it from /myapp rather than /myapp/public. I think I'll play with that a little next. Let me know if you need anything from me, or if you can generate a patch yourself. Andrew From transfire at gmail.com Wed Apr 12 09:55:44 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 09:55:44 -0400 Subject: [Nitro] Better than classinherit.rb! In-Reply-To: <3ff63f9b0604120457gb879147wacd1c8e3c09b6dd5@mail.gmail.com> References: <4b6f054f0604100905o27d0878cy2f4a5cd82623cdb5@mail.gmail.com> <3ff63f9b0604120434t62517f94x394313481457729f@mail.gmail.com> <3ff63f9b0604120457gb879147wacd1c8e3c09b6dd5@mail.gmail.com> Message-ID: <4b6f054f0604120655l300306e5p808db4749f19f46@mail.gmail.com> On 4/12/06, zimba-tm wrote: > What would be needed instead of redefining all the methods is toaccess directly to the singleton-class. > Something like : > class Module > def mixin(mod) include mod extend mod.singleton_class end > end > et voila ! :-p (only the problem is that mod.singleton_class doesn't exist) Yep. Actually if you think about it, why are "singleton classes" classes at all? You can't instantiate them and you can't subclass them. So they are more like modules in every way... well, except for how they are tied into Ruby's inheritance tree. T. From george.moschovitis at gmail.com Wed Apr 12 10:08:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 17:08:07 +0300 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: <443B5EC4.1060403@neurogami.com> References: <443B5EC4.1060403@neurogami.com> Message-ID: Selenium looks nice, but the new vcr feature of nitro has greater potential... stay tuned for more ;-) -g. On 4/11/06, James Britt wrote: > Bryan Soto wrote: > > A flash movie link that manveru asked me to post. Enjoy. :) > > > > http://wiki.openqa.org/download/attachments/400/Selenium+IDE.swf?version=1 > > > > Pretty sweet. I forgot I ad the installed. I poke around with Selenium > about a week ago, nothing too involved. I've been using WATIR plus my > own custom DSL on top of it to do integration testing, but Selenium > looks nicer (plus it can use Firefox). > > > This browser recorder thing kicks ass. But I found this autogenerated > code amusing: > > > > class NewTest > def test_foo > open "/" > assertTitle "james britt" > assertTextPresent "Gee, I Hope They" > end > end > > > > Shame about the lowerCamelCase methodNames > > But thanks for reminding me to go lookat this more. Saves much time and > trouble! > > > > -- > James Britt > > http://www.ruby-doc.org - Ruby Help & Documentation > http://www.artima.com/rubycs/ - The Journal By & For Rubyists > http://www.rubystuff.com - The Ruby Store for Ruby Stuff > http://www.jamesbritt.com - Playing with Better Toys > http://www.30secondrule.com - Building Better Tools > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 12 10:10:57 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 17:10:57 +0300 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: Message-ID: ehm, better dont apply this patch. Ideally I would propose this: facets/property.rb facets/property/validadion.rb og/validation.rb regards, George. On 4/12/06, Bryan Soto wrote: > Attached patch moves all code from glue/validation.rb to og/validation.rb. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 12 10:14:48 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 17:14:48 +0300 Subject: [Nitro] Problem with Og enchantments. In-Reply-To: References: Message-ID: > Maybe we should hold off on the glue move and concentrate on the yeah, please hold off the glue move. I think it is better to release 0.30.0 before the move, then make a quick (5 days or so) release (0.31.0) only with the glue move and some dir structure cleanup and refactorings. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Wed Apr 12 10:33:14 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 10:33:14 -0400 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: Message-ID: <4b6f054f0604120733p634e5a68y28a68b3fc2a5042@mail.gmail.com> On 4/12/06, George Moschovitis wrote: > ehm, better dont apply this patch. Ideally I would propose this: > > facets/property.rb > facets/property/validadion.rb > og/validation.rb How do you expect that? Right off the bat property.rb has these dependencies: require 'og/entity' require 'og/relation/all' T. From vagabond at cataclysm-software.net Wed Apr 12 10:35:56 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Wed, 12 Apr 2006 10:35:56 -0400 Subject: [Nitro] Problem with Og enchantments. In-Reply-To: References: Message-ID: <443D104C.9070607@cataclysm-software.net> George Moschovitis wrote: > yeah, please hold off the glue move. I think it is better to release > 0.30.0 before the move, then make a quick (5 days or so) release > (0.31.0) only with the glue move and some dir structure cleanup and > refactorings. Or maybe a non-rushed proper cleanup release. I still think this headlong rush for new features isn't letting cleanups/documentation happen as they should. Andrew From transfire at gmail.com Wed Apr 12 10:42:16 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 10:42:16 -0400 Subject: [Nitro] html.rb Message-ID: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> Hey, what's this do exactly? module Glue module Html def self.cleanup(buf) out = buf.dup elements = "input|img|br|hr|link|style|render|include|inject|base|meta" out.gsub! /' out.gsub! /<(#{elements}) ([^>]*)><\/\1>/, '<\1 \2 />' out.gsub! /<(#{elements})><\/\1>/, '<\1 />' out end end end Thanks, T. From aidan at yoyo.org Wed Apr 12 10:52:16 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 13 Apr 2006 00:52:16 +1000 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: References: <443B5EC4.1060403@neurogami.com> Message-ID: <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> The big issue with record/playback testing in a proxy fashion is that you don't test anything client-side. Aidan On 13/04/2006, at 12:08 AM, George Moschovitis wrote: > Selenium looks nice, but the new vcr feature of nitro has greater > potential... > stay tuned for more ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060412/d678cc58/attachment.html From george.moschovitis at gmail.com Wed Apr 12 11:05:52 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 18:05:52 +0300 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: <4b6f054f0604120733p634e5a68y28a68b3fc2a5042@mail.gmail.com> References: <4b6f054f0604120733p634e5a68y28a68b3fc2a5042@mail.gmail.com> Message-ID: hmm.... let me think a bit about this ;-) -g. On 4/12/06, TRANS wrote: > On 4/12/06, George Moschovitis wrote: > > ehm, better dont apply this patch. Ideally I would propose this: > > > > facets/property.rb > > facets/property/validadion.rb > > og/validation.rb > > How do you expect that? Right off the bat property.rb has these dependencies: > > require 'og/entity' > require 'og/relation/all' > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 12 11:07:10 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 18:07:10 +0300 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> References: <443B5EC4.1060403@neurogami.com> <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> Message-ID: > The big issue with record/playback testing in a proxy fashion is that you > don't test anything client-side. what do you mean? For example you can make the same test as demonstrated in the video, ie assert for specific tests, test for exception, assert time to render etc... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Wed Apr 12 11:10:23 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 12 Apr 2006 08:10:23 -0700 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> References: <443B5EC4.1060403@neurogami.com> <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> Message-ID: <443D185F.2070606@neurogami.com> Aidan Rogers wrote: > The big issue with record/playback testing in a proxy fashion is that > you don't test anything client-side. > True. The big appeal of something like Selenium macro recording is that it is snake simple, and easy to demo to clients. I can point the scripts at some application instance and all the stakeholders can verify (hopefully!) correct application behavior. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From itsme213 at hotmail.com Wed Apr 12 11:12:20 2006 From: itsme213 at hotmail.com (itsme213) Date: Wed, 12 Apr 2006 10:12:20 -0500 Subject: [Nitro] Problem with Og enchantments. References: <443D104C.9070607@cataclysm-software.net> Message-ID: "Andrew Thompson" wrote in message > Or maybe a non-rushed proper cleanup release. I still think this > headlong rush for new features isn't letting cleanups/documentation > happen as they should. Amen. One of the most promising CMS systems I used a few years ago eventually died because of this. Nitro and Og are just too valuable to let that happen :-( From vagabond at cataclysm-software.net Wed Apr 12 11:38:58 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Wed, 12 Apr 2006 11:38:58 -0400 Subject: [Nitro] html.rb In-Reply-To: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> References: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> Message-ID: <443D1F12.80900@cataclysm-software.net> TRANS wrote: > Hey, what's this do exactly? > > module Glue > module Html > def self.cleanup(buf) > out = buf.dup > elements = "input|img|br|hr|link|style|render|include|inject|base|meta" > out.gsub! /' > out.gsub! /<(#{elements}) ([^>]*)><\/\1>/, '<\1 \2 />' > out.gsub! /<(#{elements})><\/\1>/, '<\1 />' > out > end > end > end Manveru and I deciphered this for our compiler pipeline dealie. what it does is it converts empty tags like to and to . As far as I recall it does nothing to a textview, but it does nothing in an expensive fashion. Andrew From transfire at gmail.com Wed Apr 12 11:48:29 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 11:48:29 -0400 Subject: [Nitro] properties In-Reply-To: References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> Message-ID: <4b6f054f0604120848y6cb53c3j2c3499970030b6f4@mail.gmail.com> In considering this more, I do think it a good idea to make the ORM as transparent as reasonably possible. in which case, simply annotation is the clearest case. class Foo attr :x ann :x, String, :default => "n/a" end And if we want to take it further we can modify the built in attrbute methods to accept annotations. class Foo attr :x, String, :default => "n/a" end That just seems the Least Path of Resistance. We still need a way to access the list of "properties"; shuoldn't we think in terms of the database? Postgresql used to refer to them as 'attributes', but more commonly I think we refer to them as 'fields' or better 'columns'. T. From transfire at gmail.com Wed Apr 12 11:50:02 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 11:50:02 -0400 Subject: [Nitro] html.rb In-Reply-To: <443D1F12.80900@cataclysm-software.net> References: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> <443D1F12.80900@cataclysm-software.net> Message-ID: <4b6f054f0604120850v49aac9caqfa1af41cbd794a26@mail.gmail.com> On 4/12/06, Andrew Thompson wrote: > TRANS wrote: > > Hey, what's this do exactly? > > > > module Glue > > module Html > > def self.cleanup(buf) > > out = buf.dup > > elements = "input|img|br|hr|link|style|render|include|inject|base|meta" > > out.gsub! /' > > out.gsub! /<(#{elements}) ([^>]*)><\/\1>/, '<\1 \2 />' > > out.gsub! /<(#{elements})><\/\1>/, '<\1 />' > > out > > end > > end > > end > > Manveru and I deciphered this for our compiler pipeline dealie. what it > does is it converts empty tags like to and foo="bar"> to . As far as I recall it does nothing > to a textview, but it does nothing in an expensive fashion. Okay, cool. Thanks. So now I'm wondering where that fits in Facets...... T. From george.moschovitis at gmail.com Wed Apr 12 12:14:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 19:14:23 +0300 Subject: [Nitro] html.rb In-Reply-To: <4b6f054f0604120850v49aac9caqfa1af41cbd794a26@mail.gmail.com> References: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> <443D1F12.80900@cataclysm-software.net> <4b6f054f0604120850v49aac9caqfa1af41cbd794a26@mail.gmail.com> Message-ID: I dont think it fits in facets, I will move it into nitro, ignore this... -g. On 4/12/06, TRANS wrote: > On 4/12/06, Andrew Thompson wrote: > > TRANS wrote: > > > Hey, what's this do exactly? > > > > > > module Glue > > > module Html > > > def self.cleanup(buf) > > > out = buf.dup > > > elements = "input|img|br|hr|link|style|render|include|inject|base|meta" > > > out.gsub! /' > > > out.gsub! /<(#{elements}) ([^>]*)><\/\1>/, '<\1 \2 />' > > > out.gsub! /<(#{elements})><\/\1>/, '<\1 />' > > > out > > > end > > > end > > > end > > > > Manveru and I deciphered this for our compiler pipeline dealie. what it > > does is it converts empty tags like to and > foo="bar"> to . As far as I recall it does nothing > > to a textview, but it does nothing in an expensive fashion. > > Okay, cool. Thanks. > > So now I'm wondering where that fits in Facets...... > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Wed Apr 12 12:19:09 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 12:19:09 -0400 Subject: [Nitro] Glue to facets plan In-Reply-To: References: Message-ID: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> Okay, these have been moved. accumulate.rb aspects.rb on_included.rb These I think are too Nitro/Og oriented (at least for now). property.rb template.rb These I don't understand well enough yet to be sure yet. builder.rb builder/* configuration.rb settings.rb cache.rb cache/* logger.rb These should be ready for use already with their Facets couterparts: paramix.rb (paramix.rb) expirable.rb (expirable.rb) flexob.rb (openobject.rb) These I'm still working-on / considering. html.rb attribute.rb autoreload.rb sanitize.rb And lastly, this one has a comment "gmosx, TODO: deprecate this" > uri.rb Should I bother with it? T. From transfire at gmail.com Wed Apr 12 12:23:49 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 12:23:49 -0400 Subject: [Nitro] html.rb In-Reply-To: References: <4b6f054f0604120742u1174f338n2942847b1e7c567f@mail.gmail.com> <443D1F12.80900@cataclysm-software.net> <4b6f054f0604120850v49aac9caqfa1af41cbd794a26@mail.gmail.com> Message-ID: <4b6f054f0604120923r7a0089e5g3e5ecfd4ee9b4bf@mail.gmail.com> On 4/12/06, George Moschovitis wrote: > I dont think it fits in facets, I will move it into nitro, ignore this... Okay, but I think it might be able to in the future if we add a HtmlUtils module or something like that. T. From george.moschovitis at gmail.com Wed Apr 12 12:34:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 19:34:15 +0300 Subject: [Nitro] Glue to facets plan In-Reply-To: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> Message-ID: > These I think are too Nitro/Og oriented (at least for now). > > property.rb > template.rb ok > These I don't understand well enough yet to be sure yet. > > builder.rb > builder/* > configuration.rb > settings.rb these 3 are general, i think you should include them. > These should be ready for use already with their Facets couterparts: > > paramix.rb (paramix.rb) > expirable.rb (expirable.rb) > flexob.rb (openobject.rb) ok at some point we should update nitro to use these. > And lastly, this one has a comment "gmosx, TODO: deprecate this" > > > uri.rb this should be rewritten with your 'magic' style ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 12 12:42:37 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 19:42:37 +0300 Subject: [Nitro] properties In-Reply-To: <4b6f054f0604120848y6cb53c3j2c3499970030b6f4@mail.gmail.com> References: <4b6f054f0604031247x25d82e54l26fa98cae077d6fa@mail.gmail.com> <4b6f054f0604031411l10d217bfu9e97029f26e5dad7@mail.gmail.com> <4b6f054f0604041011q7078ad4s6f33707fcff2224a@mail.gmail.com> <4b6f054f0604120848y6cb53c3j2c3499970030b6f4@mail.gmail.com> Message-ID: this more or less is what Og does at the moment, the only problem is this list of properties. -g. On 4/12/06, TRANS wrote: > In considering this more, I do think it a good idea to make the ORM as > transparent as reasonably possible. in which case, simply annotation > is the clearest case. > > class Foo > attr :x > ann :x, String, :default => "n/a" > end > > And if we want to take it further we can modify the built in attrbute > methods to accept annotations. > > class Foo > attr :x, String, :default => "n/a" > end > > That just seems the Least Path of Resistance. > > We still need a way to access the list of "properties"; shuoldn't we > think in terms of the database? Postgresql used to refer to them as > 'attributes', but more commonly I think we refer to them as 'fields' > or better 'columns'. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Wed Apr 12 13:32:33 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 10:32:33 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443D03F4.3090905@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> <443D03F4.3090905@cataclysm-software.net> Message-ID: I'm just trying to get a handle on what exactly should be submitted as a patch... I'll leave the R stuff in as it's broken without it and ignore the redirect_home thing like you said. But did the other patches do anything at all? On 4/12/06, Andrew Thompson wrote: > I fixed the link issue, a base tag in the html HEAD fixed things. It > turns out I don't need the R thing because with the base set correctly > things just work(tm). I'm not convinced it'll work with > Router.strip_path though, just by looking at it. > > I also think your patch to redirect_home does more harm than good, I've > already hacked redirect() itself so when redirect_home() calls redirect > it all goes wrong. > > I'm satisfied with nitro running in a subdir, though I'd like to be able > to run it from /myapp rather than /myapp/public. I think I'll play with > that a little next. Let me know if you need anything from me, or if you > can generate a patch yourself. > > Andrew > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Wed Apr 12 14:10:13 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 14:10:13 -0400 Subject: [Nitro] Glue to facets plan In-Reply-To: References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> Message-ID: <4b6f054f0604121110n17b2d2f9mfe021f84919936ab@mail.gmail.com> Could someone give me a nice explination of this, what it does and the how it goes about doing it. Thanks. > > configuration.rb > > settings.rb T. From transfire at gmail.com Wed Apr 12 14:12:24 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 14:12:24 -0400 Subject: [Nitro] Glue to facets plan In-Reply-To: References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> Message-ID: <4b6f054f0604121112i2515eb28u999f9caa050aad@mail.gmail.com> On 4/12/06, George Moschovitis wrote: > > These I don't understand well enough yet to be sure yet. > > > > builder.rb > > builder/* > > configuration.rb > > settings.rb > these 3 are general, i think you should include them. Okay. But I think it's important that I have at least a basic understand everything that's in Facets. > > And lastly, this one has a comment "gmosx, TODO: deprecate this" > > > > > uri.rb > > this should be rewritten with your 'magic' style ;-) I'll have a look. T. From bryan.a.soto at gmail.com Wed Apr 12 14:24:30 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 11:24:30 -0700 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> Message-ID: On 4/12/06, Dimitri Aivaliotis wrote: > Hi Bryan, > > I don't have the time at the moment to follow up and fix the test > cases/libraries so that they'll all complete successfully. I just > wanted to give some quick feedback on the patch (it works!), and > provide this info in case somebody else had time to do the follow-up. > I've actually done quite a bit of work to clean these Postgres errors up, just so you don't waste your time. :) Patch is available here if you're interested. I'd be quite happy with more testers. :) I don't think it will make it in the repo till after 0.30 though if then. http://rubyforge.org/pipermail/nitro-general/2006-April/003853.html Thanks for your feedback on the patch and the test suite. It could definitely use some improvements. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From george.moschovitis at gmail.com Wed Apr 12 14:27:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 21:27:07 +0300 Subject: [Nitro] Glue to facets plan In-Reply-To: <4b6f054f0604121110n17b2d2f9mfe021f84919936ab@mail.gmail.com> References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> <4b6f054f0604121110n17b2d2f9mfe021f84919936ab@mail.gmail.com> Message-ID: It allows you to configure a class. I think the rdoc comments in configuration.rb are self explanatory. here is an example: class MyClass setting :my_setting, :default => 5, :doc => 'this is a simple setting' end you can access the setting like this: MyClass.my_setting MyClass.my_setting = 5 Configuration.MyClass.my_setting # works even before MyClass is defined! Configuration.settings # returns all settings etc, etc... -g. On 4/12/06, TRANS wrote: > Could someone give me a nice explination of this, what it does and the > how it goes about doing it. Thanks. > > > > configuration.rb > > > settings.rb > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 12 14:28:40 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Apr 2006 21:28:40 +0300 Subject: [Nitro] Og thread_safe changes Message-ID: Someone has played a bit with Og's thread safe option and added some code to inti/close stores. These additions create a lot of problems for one of my apps and I was wondering if this person can describe again, what kind of problems his patch solved. thanks, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From bryan.a.soto at gmail.com Wed Apr 12 14:31:28 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 11:31:28 -0700 Subject: [Nitro] Problem with Og enchantments. In-Reply-To: References: Message-ID: On 4/12/06, George Moschovitis wrote: > > Maybe we should hold off on the glue move and concentrate on the > > yeah, please hold off the glue move. I think it is better to release > 0.30.0 before the move, then make a quick (5 days or so) release > (0.31.0) only with the glue move and some dir structure cleanup and > refactorings. > Might I recommend we hold off on any release until nitrohq.com resolves properly? If the wiki displayed edits, that would be a big plus too. :) Just a thought. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Wed Apr 12 14:43:39 2006 From: transfire at gmail.com (TRANS) Date: Wed, 12 Apr 2006 14:43:39 -0400 Subject: [Nitro] Glue to facets plan In-Reply-To: References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> <4b6f054f0604121110n17b2d2f9mfe021f84919936ab@mail.gmail.com> Message-ID: <4b6f054f0604121143x313c6ae6j156bbe845c1d76d3@mail.gmail.com> On 4/12/06, George Moschovitis wrote: > here is an example: > > class MyClass > setting :my_setting, :default => 5, :doc => 'this is a simple setting' > end > > you can access the setting like this: > > MyClass.my_setting > MyClass.my_setting = 5 > Configuration.MyClass.my_setting # works even before MyClass is defined! > Configuration.settings # returns all settings Looks like annotations for classes. T. From vagabond at cataclysm-software.net Wed Apr 12 14:45:47 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Wed, 12 Apr 2006 14:45:47 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <443A4D8D.4000202@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> <443D03F4.3090905@cataclysm-software.net> Message-ID: <443D4ADB.20303@cataclysm-software.net> Bryan Soto wrote: > I'm just trying to get a handle on what exactly should be submitted as > a patch... I'll leave the R stuff in as it's broken without it and > ignore the redirect_home thing like you said. But did the other > patches do anything at all? > I think your fixes to the Router.strip_path you added to decode_route. I think I hacked in some stuff to encode_route and redirect that finished the job. The changes are pretty trivial though, the trick was just finding out where they should go. I can cleanup and diff against 0.29 if you wish... I'm not sure the rest of the patches were any use though ;) Andrew From bryan.a.soto at gmail.com Wed Apr 12 15:15:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 12:15:56 -0700 Subject: [Nitro] Og thread_safe changes In-Reply-To: References: Message-ID: On 4/12/06, George Moschovitis wrote: > Someone has played a bit with Og's thread safe option and added some > code to inti/close stores. These additions create a lot of problems > for one of my apps and I was wondering if this person can describe > again, what kind of problems his patch solved. > I believe that would be Guill and myself that modified it. As I recall, the basic problem was that managers would configure themselves based off that global setting and base their behaviour off of it, but wouldn't account for it being changed in between. As an example, if a manager was created while the setting was true, it would create a pool. If the setting was changed to false, it would return the variable for the single connection. But that variable was never assigned to so it returned nil. Another problem the pool had is there are no calls to put_store anywhere so after 5 method calls, the pool would be empty and it returned nil. I think that was the basic rationale. Hopefully Guill can provide more info if necessary. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 12 15:29:09 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 12:29:09 -0700 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: <443D4ADB.20303@cataclysm-software.net> References: <44351B39.4020904@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> <443D03F4.3090905@cataclysm-software.net> <443D4ADB.20303@cataclysm-software.net> Message-ID: On 4/12/06, Andrew Thompson wrote: > I'm not sure the rest of the patches were any use though ;) > Always the way, isn't it? ;) Okay, the R stuff because it's broken without it. And for running in a subdir of document root: my decode_route/Router.strip_path change your encode_route and redirect changes? Yeah, if you could give those to me as a diff against 0.29, I'll make them a darcs bundle so we can try to get them in to 0.30. That way you can get this stuff "out of the box", so to speak. :) Okay? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 12 16:23:16 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 13:23:16 -0700 Subject: [Nitro] [PATCH][BUGFIX] og-joins_many-relation Message-ID: * og-joins_many-relation When using a through table, joins_many was assuming that the through table class was already enchanted. This modifies it to compute the table name. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-joins_many-relation.zip Type: application/zip Size: 13919 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060412/63e92f0a/attachment.zip From bryan.a.soto at gmail.com Wed Apr 12 16:24:44 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 13:24:44 -0700 Subject: [Nitro] [PATCH] Logger.debug woe In-Reply-To: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> References: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Message-ID: Are there any objections to this? On 4/12/06, Michael Fellinger wrote: > Hey all, > > I finally sat down, after hearing lots of complains from various > sides, and added the 'if $DBG' statement at all the Logger.debug > outputs where it was missing, except for the logger-testcase where it > might make sense, didn't have a closer look tho.. > to trace the missing statements down i used: > ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ /_darcs/}' > > maybe that's something to add to a testcase and trace down missing > statements if they occur again... > > Hope it doesn't break anything, and i'm not sure if all the > Logger.debug for the kind-of-session-noticing need that too, but here > it is :) > > ~~~~manveru > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 12 19:07:37 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 16:07:37 -0700 Subject: [Nitro] Outstanding Patches Message-ID: I think these and what's on devlab are the only outstanding patches out there, right? If you have submitted a patch to the list, it hasn't been applied, doesn't have a ticket and isn't listed here, please let me know. Thanks. [Nitro] [PATCH][BUGFIX] og-joins_many-relation http://rubyforge.org/pipermail/nitro-general/2006-April/003957.html [Nitro] [PATCH] Logger.debug woe http://rubyforge.org/pipermail/nitro-general/2006-April/003924.html [Nitro] [PATCH] glue-validations-to-og http://rubyforge.org/pipermail/nitro-general/2006-April/003920.html [Nitro] [PATCH] og-psql-refactoring http://rubyforge.org/pipermail/nitro-general/2006-April/003853.html [Nitro] [FIX] find_or_create_by with relations http://rubyforge.org/pipermail/nitro-general/2006-April/003730.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 12 19:48:15 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 16:48:15 -0700 Subject: [Nitro] [PATCH][FIX] bugfix-nitro-R-operator Message-ID: * bugfix-nitro-R-operator Fixes the R operator by setting the annotation it requires in the dispatcher when the controller is mounted to the mount point. Adds tests. ~~~~~ George, is this what you had in mind? The R operator doesn't work unless the annotation is set. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: bugfix-nitro-R-operator.zip Type: application/zip Size: 14095 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060412/5b22eefc/attachment.zip From aidan at yoyo.org Wed Apr 12 19:48:40 2006 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 13 Apr 2006 09:48:40 +1000 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: References: <443B5EC4.1060403@neurogami.com> <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> Message-ID: Well, let's say you record a test using the proxy. Then you make some changes to the JavaScript on the client side. All of a sudden, one of your input boxes doesn't display any more, or you've accidentally turned a text field into a hidden field. The proxy recording will still work, because it tests the server's reaction to specific inputs. The client side will be broken. Selenium removes that concern. Of course, it has problems of its own (browser compatibility, poor support for frames, etc.) Proxy browse/record has been around for a long time, and it has it's spot in testing, but generally it's way better for performance testing than for functional tests. Aidan On 13/04/2006, at 1:07 AM, George Moschovitis wrote: >> The big issue with record/playback testing in a proxy fashion is >> that you >> don't test anything client-side. > > what do you mean? For example you can make the same test as > demonstrated in the video, ie assert for specific tests, test for > exception, assert time to render etc... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060412/746398ae/attachment.html From bryan.a.soto at gmail.com Thu Apr 13 02:27:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 12 Apr 2006 23:27:46 -0700 Subject: [Nitro] [PATCH] og-aggregate-type-casting Message-ID: * og-aggregate-type-casting Patch adds a new method, #type_cast, which ensures dates and times are returne d as instances of Date and Time. Adds tests to tc_aggregations_calculations.rb. ~~~~~ Patch adds support and tests for the ticket at http://devlab.oree.ch/trac/nitrohq/ticket/19 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: og-aggregate-type-casting.zip Type: application/zip Size: 14298 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060413/cb60efb3/attachment.zip From zimba.tm at gmail.com Thu Apr 13 02:48:49 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Thu, 13 Apr 2006 08:48:49 +0200 Subject: [Nitro] [PATCH] og-aggregate-type-casting In-Reply-To: References: Message-ID: <38EDE383-3EC8-449E-9AE1-F08834B026A7@gmail.com> Le 13 avr. 06 ? 08:27, Bryan Soto a ?crit : > * og-aggregate-type-casting > Patch adds a new method, #type_cast, which ensures dates and times > are returne > d as instances of Date and Time. Adds tests to > tc_aggregations_calculations.rb. You could use the TypeCast library in facets for such things. From george.moschovitis at gmail.com Thu Apr 13 02:59:36 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Apr 2006 09:59:36 +0300 Subject: [Nitro] [PATCH] Logger.debug woe In-Reply-To: References: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Message-ID: No, add this please! On 4/12/06, Bryan Soto wrote: > Are there any objections to this? > > On 4/12/06, Michael Fellinger wrote: > > Hey all, > > > > I finally sat down, after hearing lots of complains from various > > sides, and added the 'if $DBG' statement at all the Logger.debug > > outputs where it was missing, except for the logger-testcase where it > > might make sense, didn't have a closer look tho.. > > to trace the missing statements down i used: > > ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ /_darcs/}' > > > > maybe that's something to add to a testcase and trace down missing > > statements if they occur again... > > > > Hope it doesn't break anything, and i'm not sure if all the > > Logger.debug for the kind-of-session-noticing need that too, but here > > it is :) > > > > ~~~~manveru > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Apr 13 03:05:20 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Apr 2006 10:05:20 +0300 Subject: [Nitro] Web App Testing with Selenium In-Reply-To: References: <443B5EC4.1060403@neurogami.com> <1B5E0184-2FA1-410D-99A0-3A5B1E9A0E34@yoyo.org> Message-ID: > Proxy browse/record has been around for a long time, and it has it's spot in > testing, but generally it's way better for performance testing than for > functional tests. Well, ok you have a point, but I still find this usefull for me. Perhaps it will be useful for someone else too ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Apr 13 03:07:32 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Apr 2006 10:07:32 +0300 Subject: [Nitro] [PATCH] og-aggregate-type-casting In-Reply-To: References: Message-ID: Nice ;-) havent seen the implementation though... -g. On 4/13/06, Bryan Soto wrote: > * og-aggregate-type-casting > Patch adds a new method, #type_cast, which ensures dates and times are returne > d as instances of Date and Time. Adds tests to tc_aggregations_calculations.rb. > > ~~~~~ > > Patch adds support and tests for the ticket at > http://devlab.oree.ch/trac/nitrohq/ticket/19 > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From aglarond at gmail.com Thu Apr 13 03:56:57 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Thu, 13 Apr 2006 09:56:57 +0200 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> Message-ID: <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> On 4/12/06, Bryan Soto wrote: > On 4/12/06, Dimitri Aivaliotis wrote: > I've actually done quite a bit of work to clean these Postgres errors > up, just so you don't waste your time. :) I really appreciate all the work you've done on Nitro/Og. > Patch is available here if you're interested. I'd be quite happy with > more testers. :) I don't think it will make it in the repo till after > 0.30 though if then. I did see the patch. I was hesitant about applying because of the STI issues. I haven't yet converted my legacy apps over to Og, so I don't know what effects the patches will have on a real application. > Thanks for your feedback on the patch and the test suite. It could > definitely use some improvements. :) Well, here's some more. :) With the patches (glue-validations-to-og and og-psql-refactoring) applied: tc_override doesn't work because it assumes that SQLite3 is installed. tc_reverse doesn't work because the KirbyBase store doesn't support the 'exec' method. tc_inheritance, tc_inheritance2, and store/tc_sti still all give: nitrohq/og/lib/og/store/psql.rb:635:in `exec': ERROR: column "ogtype" duplicated (PGError) 1) Failure: test_all(TC_OgAggrCalc) [./test/og/tc_aggregations_calculations.rb:41]: <28> expected but was <58.0>. 2) Failure: test_all(TestMultiple) [./test/og/tc_multiple.rb:37]: is not true. 36 tests, 188 assertions, 2 failures, 0 errors Am I running something incorrectly here? - Dimitri From george.moschovitis at gmail.com Thu Apr 13 07:41:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Apr 2006 14:41:23 +0300 Subject: [Nitro] [PATCH] Some more nice patches Message-ID: Bryan, when you have time ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 15806 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060413/7ce7d276/attachment.zip From vagabond at cataclysm-software.net Thu Apr 13 09:20:22 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Thu, 13 Apr 2006 09:20:22 -0400 Subject: [Nitro] Nitro::Dispatcher::ROOT and running nitro in a subdirectory... In-Reply-To: References: <44351B39.4020904@cataclysm-software.net> <443B9F78.9050405@cataclysm-software.net> <443C02B9.3020006@cataclysm-software.net> <443C1BB5.4050302@cataclysm-software.net> <443D03F4.3090905@cataclysm-software.net> <443D4ADB.20303@cataclysm-software.net> Message-ID: <443E5016.9020608@cataclysm-software.net> Okay, lets try this patch (pathetically simple now its stripped down to the minimum ;) ) Andrew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: strip_path.diff Url: http://rubyforge.org/pipermail/nitro-general/attachments/20060413/befd41b6/attachment.pl From transfire at gmail.com Thu Apr 13 14:32:43 2006 From: transfire at gmail.com (TRANS) Date: Thu, 13 Apr 2006 14:32:43 -0400 Subject: [Nitro] Nitro and Amrita Message-ID: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> Can Nitro use Amrita? T. From transfire at gmail.com Fri Apr 14 13:29:13 2006 From: transfire at gmail.com (TRANS) Date: Fri, 14 Apr 2006 13:29:13 -0400 Subject: [Nitro] Facets 1.3 Message-ID: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> Put out Facets 1.3 today. This includes all the Glue stuff I mentioned having ported in my last post. This release also adds a couple More libs: xoxo.rb from Christian Neukirchen, json.rb from Florian Frank, and rtals.rb from yours truly. Plus a few bugs have been crushed. Interface Changes: * What was kernel#meta (and then kernel#instance in the last release) is now kernel#__self__. Anyone see anything wrong with that name? * cattr methods have been moved from module/ to class/ --they did not work correctly for modules, only classes. #mattr on the other hand is still in module/ and is not an alias for cattr at the moment -- as I am considering with using class instance vars rather than class vars for it. I'm still working on this. T. From bryan.a.soto at gmail.com Fri Apr 14 18:27:44 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 14 Apr 2006 15:27:44 -0700 Subject: [Nitro] [PATCH] og-aggregate-type-casting In-Reply-To: References: Message-ID: You won't be impressed, I guarantee that. All it does is ensure dates and times are restored properly. I only called it type_cast because it seemed like an appropriate name. But it at least fixes the bug in the ticket. On 4/13/06, George Moschovitis wrote: > Nice ;-) havent seen the implementation though... > > -g. > > On 4/13/06, Bryan Soto wrote: > > * og-aggregate-type-casting > > Patch adds a new method, #type_cast, which ensures dates and times are returne > > d as instances of Date and Time. Adds tests to tc_aggregations_calculations.rb. > > > > ~~~~~ > > > > Patch adds support and tests for the ticket at > > http://devlab.oree.ch/trac/nitrohq/ticket/19 > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 14 19:04:04 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 14 Apr 2006 16:04:04 -0700 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> Message-ID: On 4/13/06, Dimitri Aivaliotis wrote: > > Patch is available here if you're interested. I'd be quite happy with > > more testers. :) I don't think it will make it in the repo till after > > 0.30 though if then. > > I did see the patch. I was hesitant about applying because of the STI > issues. I haven't yet converted my legacy apps over to Og, so I don't > know what effects the patches will have on a real application. > STI issues? Was it you that mentioned Postgres provides table inheritance? Og follows it as quasi-outlined at: http://martinfowler.com/eaaCatalog/singleTableInheritance.html where all the subclasses are stored in a single table. Of course, that is based off of databases not supporting actual table inheritance. :) The only other STI issue is that postgres was determining whether a class is STI differently from the other stores. The patch addresses it by removing the method overrides the postgres adapter does. It actually removes a lot of postgres code and reuses from the superclass. Has the pleasant benefit of making the stores function similarly as well as being the textbook beginnings of refactoring. :) > > Thanks for your feedback on the patch and the test suite. It could > > definitely use some improvements. :) > > Well, here's some more. :) > > With the patches (glue-validations-to-og and og-psql-refactoring) applied: > > tc_override doesn't work because it assumes that SQLite3 is installed. Never noticed now that I have them all installed. :/ > tc_reverse doesn't work because the KirbyBase store doesn't support > the 'exec' method. > Kirby doesn't do alot of things Og needs unfortunately. :( Another thing I need to do is use conditional code depending on which store we are using. I think the sql that is currently exec'd is mysql specific... > tc_inheritance, tc_inheritance2, and store/tc_sti still all give: > > nitrohq/og/lib/og/store/psql.rb:635:in `exec': ERROR: column "ogtype" > duplicated (PGError) > Hmm... I think that has to do with Dylan's Kirby patch where he made ogtype an Og property. I liked the idea and added a ticket to do that for the other stores. Thanks for reminding me on that one... > 1) Failure: > test_all(TC_OgAggrCalc) [./test/og/tc_aggregations_calculations.rb:41]: > <28> expected but was > <58.0>. > This one is the test. The other databases sort the result set. Postgres doesn't. The consensus on the list was to not assume the results were sorted. I need to do that... > 2) Failure: > test_all(TestMultiple) [./test/og/tc_multiple.rb:37]: > is not true. > Bad test as well. Needs to be modified and removed. > > Am I running something incorrectly here? > Not at all. You're just finding things I've missed or forgotten. Forgetfullness is the reason I've opened so many tickets. By the way, have I mentioned how glad I am for people that test patches? (Hint, hint ;) Many thanks to you and Kashia for taking the time to review and comment on them. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From reid.thompson at ateb.com Fri Apr 14 22:58:51 2006 From: reid.thompson at ateb.com (Reid Thompson) Date: Fri, 14 Apr 2006 22:58:51 -0400 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> Message-ID: <4440616B.4020002@ateb.com> Bryan Soto wrote: > On 4/13/06, Dimitri Aivaliotis wrote: > >>> Patch is available here if you're interested. I'd be quite happy with >>> more testers. :) I don't think it will make it in the repo till after >>> 0.30 though if then. >>> >> I did see the patch. I was hesitant about applying because of the STI >> issues. I haven't yet converted my legacy apps over to Og, so I don't >> know what effects the patches will have on a real application. >> >> > > STI issues? Was it you that mentioned Postgres provides table > inheritance? Og follows it as quasi-outlined at: > http://martinfowler.com/eaaCatalog/singleTableInheritance.html where > all the subclasses are stored in a single table. Of course, that is > based off of databases not supporting actual table inheritance. :) > > The only other STI issue is that postgres was determining whether a > class is STI differently from the other stores. The patch addresses it > by removing the method overrides the postgres adapter does. It > actually removes a lot of postgres code and reuses from the > superclass. Has the pleasant benefit of making the stores function > similarly as well as being the textbook beginnings of refactoring. :) > > These links provide information on inheritance in postgresql... http://www.postgresql.org/docs/8.1/static/tutorial-inheritance.html http://www.postgresql.org/docs/8.1/static/ddl-inherit.html http://www.varlena.com/GeneralBits/98.php interesting usage... http://ryandaigle.com/pebble/2005/11/15/1132070306836.html From bryan.a.soto at gmail.com Sat Apr 15 02:30:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 14 Apr 2006 23:30:51 -0700 Subject: [Nitro] [PATCH] test-fix-tc_aggregations_calculations Message-ID: * test-fix-tc_aggregations_calculations Modifies test case for tc_aggregations_calculations.rb. Group by doesn't automatically perform an order by of the grouping field, so the test case was failing due to the assumption that the lowest value was listed first. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: test-fix-tc_aggregations_calculations.zip Type: application/zip Size: 13998 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060415/939b1344/attachment.zip From fabian at oggu.de Sat Apr 15 02:52:27 2006 From: fabian at oggu.de (Fabian Buch) Date: Sat, 15 Apr 2006 08:52:27 +0200 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> Message-ID: Am 15.04.2006 um 01:04 schrieb Bryan Soto: > On 4/13/06, Dimitri Aivaliotis wrote: >> 1) Failure: >> test_all(TC_OgAggrCalc) >> [./test/og/tc_aggregations_calculations.rb:41]: >> <28> expected but was >> <58.0>. > This one is the test. The other databases sort the result set. > Postgres doesn't. The consensus on the list was to not assume the > results were sorted. I need to do that... I doubt that you can rely on other stores sorting it if you don't specify ORDER BY. If ORDER BY is not given and it is sorted, then you had good luck. Some databases sort in the order you entered the data, some other by the position on the harddrive and other things. For Postgres: http://www.postgresql.org/docs/8.1/interactive/queries-order.html "If sorting is not chosen, the rows will be returned in an unspecified order. The actual order in that case will depend on the scan and join plan types and the order on disk, but it must not be relied on. A particular output ordering can only be guaranteed if the sort step is explicitly chosen." How should it know how to sort your data? (not everyone assumes "id" or "oid" is the right field to sort by, only Og always creates an "oid" field) I'm not so familiar with MySQL and not at all with SQLight, but I'm very sure the same I said for PostgreSQL above applies for Oracle (not supported by Og yet, so no issue here). My guess is, that even for MySQL it was luck that it was sorted for the testcase. Fabian From bryan.a.soto at gmail.com Sat Apr 15 03:45:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 15 Apr 2006 00:45:52 -0700 Subject: [Nitro] Outstanding patches. Message-ID: I've got to figure out what to apply to the repo. Can anyone tell me if any of they ran into any problems, whether they think these should be applied, feedback in general, etc. Many thanks. ~~~~~ [Nitro] [PATCH] test-fix-tc_aggregations_calculations http://rubyforge.org/pipermail/nitro-general/2006-April/003975.html [Nitro] [PATCH] Some more nice patches http://rubyforge.org/pipermail/nitro-general/2006-April/003968.html [Nitro] [PATCH] og-aggregate-type-casting http://rubyforge.org/pipermail/nitro-general/2006-April/003962.html [Nitro] [PATCH][FIX] bugfix-nitro-R-operator http://rubyforge.org/pipermail/nitro-general/2006-April/003960.html [Nitro] [PATCH][BUGFIX] og-joins_many-relation http://rubyforge.org/pipermail/nitro-general/2006-April/003957.html [Nitro] [PATCH] Logger.debug woe http://rubyforge.org/pipermail/nitro-general/2006-April/003924.html [Nitro] [PATCH] glue-validations-to-og http://rubyforge.org/pipermail/nitro-general/2006-April/003920.html [Nitro] [PATCH] og-psql-refactoring http://rubyforge.org/pipermail/nitro-general/2006-April/003853.html [Nitro] [PATCH] tags http://rubyforge.org/pipermail/nitro-general/2006-April/003829.html [Nitro] [PATCH]: og-postgres-sti-fix http://rubyforge.org/pipermail/nitro-general/2006-April/003811.html [Nitro] [PATCH] og-postgres-join-tables http://rubyforge.org/pipermail/nitro-general/2006-April/003801.html [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly http://rubyforge.org/pipermail/nitro-general/2006-April/003762.html [Nitro] [FIX] find_or_create_by with relations http://rubyforge.org/pipermail/nitro-general/2006-April/003730.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From george.moschovitis at gmail.com Sat Apr 15 04:57:08 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 15 Apr 2006 11:57:08 +0300 Subject: [Nitro] Facets 1.3 In-Reply-To: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> Message-ID: Super ;-) Just in time for the pending Nitro release ;-) -g. On 4/14/06, TRANS wrote: > Put out Facets 1.3 today. This includes all the Glue stuff I mentioned > having ported in my last post. This release also adds a couple More > libs: xoxo.rb from Christian Neukirchen, json.rb from Florian Frank, > and rtals.rb from yours truly. Plus a few bugs have been crushed. > > Interface Changes: > > * What was kernel#meta (and then kernel#instance in the last release) > is now kernel#__self__. Anyone see anything wrong with that name? > > * cattr methods have been moved from module/ to class/ --they did not > work correctly for modules, only classes. #mattr on the other hand is > still in module/ and is not an alias for cattr at the moment -- as I > am considering with using class instance vars rather than class vars > for it. I'm still working on this. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 15 05:03:58 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 15 Apr 2006 12:03:58 +0300 Subject: [Nitro] Glue to facets plan In-Reply-To: <4b6f054f0604121143x313c6ae6j156bbe845c1d76d3@mail.gmail.com> References: <4b6f054f0604120919s692eb883oa0deba6988f005b7@mail.gmail.com> <4b6f054f0604121110n17b2d2f9mfe021f84919936ab@mail.gmail.com> <4b6f054f0604121143x313c6ae6j156bbe845c1d76d3@mail.gmail.com> Message-ID: yeah, but specialized for configuration ;-) -g. On 4/12/06, TRANS wrote: > On 4/12/06, George Moschovitis wrote: > > here is an example: > > > > class MyClass > > setting :my_setting, :default => 5, :doc => 'this is a simple setting' > > end > > > > you can access the setting like this: > > > > MyClass.my_setting > > MyClass.my_setting = 5 > > Configuration.MyClass.my_setting # works even before MyClass is defined! > > Configuration.settings # returns all settings > > Looks like annotations for classes. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 15 05:25:12 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 15 Apr 2006 12:25:12 +0300 Subject: [Nitro] Nitro and Amrita In-Reply-To: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> Message-ID: Not at the moment, but Nitro's template system beats Amrita anytime... -g. On 4/13/06, TRANS wrote: > Can Nitro use Amrita? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From kashia at vfemail.net Sat Apr 15 06:46:08 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sat, 15 Apr 2006 12:46:08 +0200 Subject: [Nitro] Nitro and Amrita In-Reply-To: References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> Message-ID: Hi, > but Nitro's template system beats Amrita anytime... be careful ;) If you read my "revised" Template testcase a few days ago, you see that the current template compiling in Nitro is quite ... fragile. This is not to bash the template system, just the implementation ;) and even not really that, it works great, if you don't leave the path ^^ Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From aglarond at gmail.com Sat Apr 15 14:36:03 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Sat, 15 Apr 2006 20:36:03 +0200 Subject: [Nitro] [PATCH] glue-validations-to-og In-Reply-To: References: <55c107bf0604120018r1828f790y4b9490d25f5ea000@mail.gmail.com> <55c107bf0604130056u394b7165r9bad7634c94dbfb@mail.gmail.com> Message-ID: <55c107bf0604151136i491d059ex3d2d5f61aa449b09@mail.gmail.com> On 4/15/06, Bryan Soto wrote: > On 4/13/06, Dimitri Aivaliotis wrote: > STI issues? Was it you that mentioned Postgres provides table > inheritance? Yup, that was me. :) Reid gave a couple of good links explaining PostgreSQL's inheritance, and pointing out its limitations. > Kirby doesn't do alot of things Og needs unfortunately. :( Maybe this will be taken care of in abstracting Og even more, as Trans mentioned previously? > > 1) Failure: > > test_all(TC_OgAggrCalc) [./test/og/tc_aggregations_calculations.rb:41]: > > <28> expected but was > > <58.0>. > > > > This one is the test. The other databases sort the result set. > Postgres doesn't. The consensus on the list was to not assume the > results were sorted. I need to do that... Ok, thanks. > > > 2) Failure: > > test_all(TestMultiple) [./test/og/tc_multiple.rb:37]: > > is not true. > > > > Bad test as well. Needs to be modified and removed. Ok. Thanks again. > By the way, have I mentioned how glad I am for people that test > patches? (Hint, hint ;) > > Many thanks to you and Kashia for taking the time to review and > comment on them. :) > It's the least I could do. - Dimitri From transfire at gmail.com Sat Apr 15 15:22:22 2006 From: transfire at gmail.com (TRANS) Date: Sat, 15 Apr 2006 15:22:22 -0400 Subject: [Nitro] Nitro and Amrita In-Reply-To: References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> Message-ID: <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> On 4/15/06, George Moschovitis wrote: > Not at the moment, Well, that would be a nice addition. > but Nitro's template system beats Amrita anytime... I wouldn't neccessarily say that b/c Amrita is different from Nitro's templates. Nitro's templates are more like PHPs, while Amrita completely separates layout from data. So Amrita has it's own benefits, although one of the drawbacks appearentnly is that it is relatively slow. T. From bryan.a.soto at gmail.com Sun Apr 16 02:44:38 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 15 Apr 2006 23:44:38 -0700 Subject: [Nitro] Facets 1.3 In-Reply-To: References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> Message-ID: Hi Trans, I was going through to see if Nitro, etc. required any changes, and ran across this in lib/facets/core/kernel/autoreload.rb:32 args.each { |arg| case arg when Numeric check_interval = arg when String files = Dir.glob( arg ) when Array files = arg when TrueClass, FalseClass include_features = arg end end Syntax error. You open the block with a '{' before arg and close with an end. I assume it should be a do rather than an '{'? To simplify: args.each { |arg| # ... end Other than that, no problems. Thanks :) On 4/15/06, George Moschovitis wrote: > Super ;-) > > Just in time for the pending Nitro release ;-) > > -g. > > On 4/14/06, TRANS wrote: > > Put out Facets 1.3 today. This includes all the Glue stuff I mentioned > > having ported in my last post. This release also adds a couple More > > libs: xoxo.rb from Christian Neukirchen, json.rb from Florian Frank, > > and rtals.rb from yours truly. Plus a few bugs have been crushed. > > > > Interface Changes: > > > > * What was kernel#meta (and then kernel#instance in the last release) > > is now kernel#__self__. Anyone see anything wrong with that name? > > > > * cattr methods have been moved from module/ to class/ --they did not > > work correctly for modules, only classes. #mattr on the other hand is > > still in module/ and is not an alias for cattr at the moment -- as I > > am considering with using class instance vars rather than class vars > > for it. I'm still working on this. > > > > T. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Sun Apr 16 03:03:32 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 16 Apr 2006 00:03:32 -0700 Subject: [Nitro] [PATCH] Some more nice patches In-Reply-To: References: Message-ID: On 4/13/06, George Moschovitis wrote: > Bryan, > > when you have time ;-) > Hey George, a few things: * Moving Tag out of Glue isn't backwards compatible. Current code creates the tag table as ogglue_tag. With this change, it'd be ogtag. If you do want to include this, we should note that in the release docs. * My R patch adds an annotation for mount_point saved in dispatcher.rb. I noticed you had a fixme for that in this bundle. I posted it to the list to make sure that was what you were intending. It's at http://rubyforge.org/pipermail/nitro-general/2006-April/003960.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From kashia at vfemail.net Sun Apr 16 05:43:17 2006 From: kashia at vfemail.net (Kashia Buch) Date: Sun, 16 Apr 2006 11:43:17 +0200 Subject: [Nitro] Outstanding patches. In-Reply-To: References: Message-ID: Hi, I'm using following patches successfully, although I have not fully tested them yet thorougly. > [Nitro] [PATCH][BUGFIX] og-joins_many-relation > [Nitro] [PATCH] og-psql-refactoring George said to leave that patch out for now, I think that's because he is in the process of refactoring whole Og for himself (not sure about that) > [Nitro] [PATCH]: og-postgres-sti-fix > [Nitro] [PATCH] og-postgres-join-tables Haven't run into any problems with those patches. Now, back to lab assignments... Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From lasso at lassoweb.nu Sun Apr 16 07:00:42 2006 From: lasso at lassoweb.nu (Lars Olsson) Date: Sun, 16 Apr 2006 13:00:42 +0200 Subject: [Nitro] [PATCH] og-aggregate-type-casting In-Reply-To: References: Message-ID: <444223DA.10901@lassoweb.nu> Hi, The sqlite-ruby libs already supports automatic type translation by themselves. Just use: dbname.type_translation = true before querying. The sqlite-ruby lib can translate the following column types to ruby classes automatically (by help of it's Translator class, see http://sqlite-ruby.rubyforge.org/classes/SQLite/Translator.html): BOOLEAN INTEGER BIT DEC TIME DATE TIMESTAMP BIGINT INT MEDIUMINT DOUBLE NUMERIC DECIMAL TINYINT SMALLINT REAL FIXED DATETIME BOOL FLOAT Shouldn't Og use the existing functionality instead? Kindly /Lars Olsson ________________________________________ Lars Olsson lasso at lassoweb.nu http://www.lassoweb.nu/ Bryan Soto skrev: > You won't be impressed, I guarantee that. All it does is ensure dates > and times are restored properly. I only called it type_cast because it > seemed like an appropriate name. But it at least fixes the bug in the > ticket. > > On 4/13/06, George Moschovitis wrote: >> Nice ;-) havent seen the implementation though... >> >> -g. >> >> On 4/13/06, Bryan Soto wrote: >>> * og-aggregate-type-casting >>> Patch adds a new method, #type_cast, which ensures dates and times are returne >>> d as instances of Date and Time. Adds tests to tc_aggregations_calculations.rb. >>> >>> ~~~~~ >>> >>> Patch adds support and tests for the ticket at >>> http://devlab.oree.ch/trac/nitrohq/ticket/19 >>> >>> -- >>> "Never tell people how to do things. Tell them what to do and they >>> will surprise you with their ingenuity." ?General George S. Patton >>> >>> >>> _______________________________________________ >>> Nitro-general mailing list >>> Nitro-general at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/nitro-general >>> >>> >>> >> >> -- >> http://www.gmosx.com >> http://www.navel.gr >> http://www.nitrohq.com >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From transfire at gmail.com Sun Apr 16 07:11:01 2006 From: transfire at gmail.com (TRANS) Date: Sun, 16 Apr 2006 07:11:01 -0400 Subject: [Nitro] Facets 1.3 In-Reply-To: References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> Message-ID: <4b6f054f0604160411h6ec20304t2cf0a6b794d48fa4@mail.gmail.com> On 4/16/06, Bryan Soto wrote: > Hi Trans, > > I was going through to see if Nitro, etc. required any changes, and > ran across this in lib/facets/core/kernel/autoreload.rb:32 > > args.each { |arg| > case arg > when Numeric > check_interval = arg > when String > files = Dir.glob( arg ) > when Array > files = arg > when TrueClass, FalseClass > include_features = arg > end > end > > Syntax error. You open the block with a '{' before arg and close with > an end. I assume it should be a do rather than an '{'? To simplify: > > args.each { |arg| > # ... > end Huh, surprised that wasn't caught before. > Other than that, no problems. Thanks :) Thanks, T. From transfire at gmail.com Sun Apr 16 10:04:57 2006 From: transfire at gmail.com (TRANS) Date: Sun, 16 Apr 2006 10:04:57 -0400 Subject: [Nitro] XmlBuilder Message-ID: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> Is anyone using Nitro's XmlBuilder? T. From m.fellinger at gmail.com Sun Apr 16 11:46:21 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Mon, 17 Apr 2006 00:46:21 +0900 Subject: [Nitro] XmlBuilder In-Reply-To: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> Message-ID: <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> used to use it a lot, but not so much these days... it's moreconvinient to make good-looking xhtml in the controller and that iswhere i use it most...why're you asking? On 4/16/06, TRANS wrote:> Is anyone using Nitro's XmlBuilder?>> T.>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From james_b at neurogami.com Sun Apr 16 12:19:25 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 16 Apr 2006 09:19:25 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> Message-ID: <44426E8D.4070002@neurogami.com> Michael Fellinger wrote: > used to use it a lot, but not so much these days... it's moreconvinient to make good-looking xhtml in the controller and that iswhere i use it most...why're you asking? > On 4/16/06, TRANS wrote:> Is anyone using Nitro's XmlBuilder?>> T.>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> I've been using Jim Weirich's Builder library, and (sadly) had to hack around Nitro in order to get to work because of naming conflicts. I use it to generate feeds, and picked it over the Nitro lib because a) there are decent docs and examples for it, and b) I had existing code I wanted to reuse. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.30secondrule.com - Building Better Tools From george.moschovitis at gmail.com Sun Apr 16 13:14:33 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 16 Apr 2006 19:14:33 +0200 Subject: [Nitro] Nitro and Amrita In-Reply-To: <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> Message-ID: > I wouldn't neccessarily say that b/c Amrita is different from Nitro's > templates. Nitro's templates are more like PHPs, while Amrita > completely separates layout from data. NOT really. Nitro Templates can be used in PHP like mode and/or Amrita style mode. Have a look at this. def action @user = User.current_user @name = @user.name @articles = @user.articles @something =... end action.xhtml

    #@name

    • #{a.title}
    This is fully separated layout from data. George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 16 13:15:42 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 16 Apr 2006 19:15:42 +0200 Subject: [Nitro] Facets 1.3 In-Reply-To: <4b6f054f0604160411h6ec20304t2cf0a6b794d48fa4@mail.gmail.com> References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> <4b6f054f0604160411h6ec20304t2cf0a6b794d48fa4@mail.gmail.com> Message-ID: Tom, can you fix it and release a new version? -g. On 4/16/06, TRANS wrote: > On 4/16/06, Bryan Soto wrote: > > Hi Trans, > > > > I was going through to see if Nitro, etc. required any changes, and > > ran across this in lib/facets/core/kernel/autoreload.rb:32 > > > > args.each { |arg| > > case arg > > when Numeric > > check_interval = arg > > when String > > files = Dir.glob( arg ) > > when Array > > files = arg > > when TrueClass, FalseClass > > include_features = arg > > end > > end > > > > Syntax error. You open the block with a '{' before arg and close with > > an end. I assume it should be a do rather than an '{'? To simplify: > > > > args.each { |arg| > > # ... > > end > > Huh, surprised that wasn't caught before. > > > Other than that, no problems. Thanks :) > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 16 13:20:25 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 16 Apr 2006 19:20:25 +0200 Subject: [Nitro] Outstanding patches. In-Reply-To: References: Message-ID: > George said to leave that patch out for now, I think that's because > he is in the process of refactoring whole Og for himself (not sure > about that) I have thouht for a long time about refactoring Og stores and I am pretty confident the community will like my changes. When i have all the details figured out i will post an email to ask for extra input than go on and implement the refactoring. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 16 13:25:29 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 16 Apr 2006 19:25:29 +0200 Subject: [Nitro] [PATCH] Some more nice patches In-Reply-To: References: Message-ID: > * Moving Tag out of Glue isn't backwards compatible. Current code > creates the tag table as ogglue_tag. With this change, it'd be ogtag. > If you do want to include this, we should note that in the release > docs. Since we are phasing out Glue altogether (moveing stuff to Facets) I think we should do that. I would like to hear what more people think about this though... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From fabian at oggu.de Sun Apr 16 14:38:42 2006 From: fabian at oggu.de (Fabian Buch) Date: Sun, 16 Apr 2006 20:38:42 +0200 Subject: [Nitro] [PATCH] Some more nice patches In-Reply-To: References: Message-ID: <7c7da25b364c0ecbabd779be3884a36a@oggu.de> Am 16.04.2006 um 19:25 schrieb George Moschovitis: >> * Moving Tag out of Glue isn't backwards compatible. Current code >> creates the tag table as ogglue_tag. With this change, it'd be ogtag. >> If you do want to include this, we should note that in the release >> docs. > > Since we are phasing out Glue altogether (moveing stuff to Facets) I > think we should do that. I would like to hear what more people think > about this though... Go ahead. Old applications can run on old Og versions and if upgrading is needed there are several ways to do workarounds, if old database tables still have to be used and can't be moved: for example a view (if the store supports it). Fabian From dcorbin at machturtle.com Sun Apr 16 14:42:57 2006 From: dcorbin at machturtle.com (David Corbin) Date: Sun, 16 Apr 2006 14:42:57 -0400 Subject: [Nitro] Nitro and Amrita In-Reply-To: References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> Message-ID: <200604161442.57236.dcorbin@machturtle.com> On Sunday 16 April 2006 01:14 pm, George Moschovitis wrote: > > I wouldn't neccessarily say that b/c Amrita is different from Nitro's > > templates. Nitro's templates are more like PHPs, while Amrita > > completely separates layout from data. > > NOT really. Nitro Templates can be used in PHP like mode and/or Amrita > style mode. Have a look at this. > > > def action > @user = User.current_user > @name = @user.name > @articles = @user.articles > @something =... > end > > action.xhtml > >
    >

    #@name

    >
      >
    • #{a.title}
      • > < >
    > > This is fully separated layout from data. I'm a touch out of date with Amrita, but I think it also has the benfit that the template is valid X?HTML. Your example is not. This can be very handy you have to work with "designers", or some 'tool' that requires X?HTML. From transfire at gmail.com Sun Apr 16 15:16:13 2006 From: transfire at gmail.com (TRANS) Date: Sun, 16 Apr 2006 15:16:13 -0400 Subject: [Nitro] Facets 1.3 In-Reply-To: References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> <4b6f054f0604160411h6ec20304t2cf0a6b794d48fa4@mail.gmail.com> Message-ID: <4b6f054f0604161216p3162fb2dk9cf2765ba6b67e04@mail.gmail.com> On 4/16/06, George Moschovitis wrote: > Tom, > > can you fix it and release a new version? Already fixed. I release 1.3.1 sometime tomorrow then. T. From bryan.a.soto at gmail.com Mon Apr 17 01:14:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 16 Apr 2006 22:14:53 -0700 Subject: [Nitro] Outstanding patches. In-Reply-To: References: Message-ID: On 4/16/06, George Moschovitis wrote: > > George said to leave that patch out for now, I think that's because > > he is in the process of refactoring whole Og for himself (not sure > > about that) > > I have thouht for a long time about refactoring Og stores and I am > pretty confident the community will like my changes. When i have all > the details figured out i will post an email to ask for extra input > than go on and implement the refactoring. > Well, the patch in question might be useful in that regard. All it does is remove alot of method overrides the postgres adapter was doing in favor of the SqlStore superclass. Basically, the postgres adapter was overriding methods the other stores weren't, so Postgres had bugs that the other stores didn't. http://rubyforge.org/pipermail/nitro-general/2006-April/003853.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 17 01:21:33 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 16 Apr 2006 22:21:33 -0700 Subject: [Nitro] [PATCH] Some more nice patches In-Reply-To: <7c7da25b364c0ecbabd779be3884a36a@oggu.de> References: <7c7da25b364c0ecbabd779be3884a36a@oggu.de> Message-ID: On 4/16/06, Fabian Buch wrote: > > Am 16.04.2006 um 19:25 schrieb George Moschovitis: > > >> * Moving Tag out of Glue isn't backwards compatible. Current code > >> creates the tag table as ogglue_tag. With this change, it'd be ogtag. > >> If you do want to include this, we should note that in the release > >> docs. > > > > Since we are phasing out Glue altogether (moveing stuff to Facets) I > > think we should do that. I would like to hear what more people think > > about this though... > > Go ahead. Old applications can run on old Og versions and if upgrading > is needed there are several ways to do workarounds, if old database > tables still have to be used and can't be moved: for example a view (if > the store supports it). > > Fabian > Okay Fabian. Just thought I'd mention it, since oxyliquit was the first thing that came to mind as using tags. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 17 01:23:06 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 16 Apr 2006 22:23:06 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: <44426E8D.4070002@neurogami.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <44426E8D.4070002@neurogami.com> Message-ID: On 4/16/06, James Britt wrote: > Michael Fellinger wrote: > > used to use it a lot, but not so much these days... it's moreconvinient to make good-looking xhtml in the controller and that iswhere i use it most...why're you asking? > > On 4/16/06, TRANS wrote:> Is anyone using Nitro's XmlBuilder?>> T.>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > > > I've been using Jim Weirich's Builder library, and (sadly) had to hack > around Nitro in order to get to work because of naming conflicts. > > I use it to generate feeds, and picked it over the Nitro lib because a) > there are decent docs and examples for it, and b) I had existing code I > wanted to reuse. > I thought that had been fixed. I should probably double check that. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 17 01:34:23 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 16 Apr 2006 22:34:23 -0700 Subject: [Nitro] [PATCH] og-aggregate-type-casting In-Reply-To: <444223DA.10901@lassoweb.nu> References: <444223DA.10901@lassoweb.nu> Message-ID: On 4/16/06, Lars Olsson wrote: > Hi, > > The sqlite-ruby libs already supports automatic type translation by > themselves. Just use: > > > dbname.type_translation = true > > > before querying. > That's actually quite good to know. I'm not very familiar with Sqlite. :) > Shouldn't Og use the existing functionality instead? > After a refactoring, perhaps. This particular bug affected only the aggregating methods and hit all the stores. My "hack" has the benefit of working for all. After a refactoring, hopefully it can be used as a last resort. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From james_b at neurogami.com Mon Apr 17 01:52:25 2006 From: james_b at neurogami.com (James Britt) Date: Sun, 16 Apr 2006 22:52:25 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <44426E8D.4070002@neurogami.com> Message-ID: <44432D19.2050508@neurogami.com> Bryan Soto wrote: > On 4/16/06, James Britt wrote: > >>Michael Fellinger wrote: >> >>>used to use it a lot, but not so much these days... it's moreconvinient to make good-looking xhtml in the controller and that iswhere i use it most...why're you asking? >>>On 4/16/06, TRANS wrote:> Is anyone using Nitro's XmlBuilder?>> T.>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>I've been using Jim Weirich's Builder library, and (sadly) had to hack >>around Nitro in order to get to work because of naming conflicts. >> >>I use it to generate feeds, and picked it over the Nitro lib because a) >>there are decent docs and examples for it, and b) I had existing code I >>wanted to reuse. >> > > > I thought that had been fixed. I should probably double check that. Oh, it may have been. I haven't tried it lately, but I do recall there being something sort of loading issue, and I ended up creating a local copy of the Builder code and renaming or namespacing the classes. -- James Britt "Blanket statements are over-rated" From george.moschovitis at gmail.com Mon Apr 17 02:24:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 17 Apr 2006 09:24:24 +0300 Subject: [Nitro] Facets 1.3 In-Reply-To: <4b6f054f0604161216p3162fb2dk9cf2765ba6b67e04@mail.gmail.com> References: <4b6f054f0604141029k2ee8a54frafc642744adae502@mail.gmail.com> <4b6f054f0604160411h6ec20304t2cf0a6b794d48fa4@mail.gmail.com> <4b6f054f0604161216p3162fb2dk9cf2765ba6b67e04@mail.gmail.com> Message-ID: great... On 4/16/06, TRANS wrote: > On 4/16/06, George Moschovitis wrote: > > Tom, > > > > can you fix it and release a new version? > > Already fixed. I release 1.3.1 sometime tomorrow then. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Apr 17 02:25:51 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 17 Apr 2006 09:25:51 +0300 Subject: [Nitro] Nitro and Amrita In-Reply-To: <200604161442.57236.dcorbin@machturtle.com> References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> <200604161442.57236.dcorbin@machturtle.com> Message-ID: nitro's templates are .xhtml (that is why they use the extension .xhtml) You can use optional xml namespace for if/for to make it xhtml compliant, this was a quick example. -g. On 4/16/06, David Corbin wrote: > On Sunday 16 April 2006 01:14 pm, George Moschovitis wrote: > > > I wouldn't neccessarily say that b/c Amrita is different from Nitro's > > > templates. Nitro's templates are more like PHPs, while Amrita > > > completely separates layout from data. > > > > NOT really. Nitro Templates can be used in PHP like mode and/or Amrita > > style mode. Have a look at this. > > > > > > def action > > @user = User.current_user > > @name = @user.name > > @articles = @user.articles > > @something =... > > end > > > > action.xhtml > > > >
    > >

    #@name

    > >
      > >
    • #{a.title}
      • > > < > >
    > > > > This is fully separated layout from data. > > I'm a touch out of date with Amrita, but I think it also has the benfit that > the template is valid X?HTML. Your example is not. This can be very handy > you have to work with "designers", or some 'tool' that requires X?HTML. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Mon Apr 17 03:11:34 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 17 Apr 2006 10:11:34 +0300 Subject: [Nitro] [PATCH] New patch... Message-ID: here you are... -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 17868 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060417/6fd01a9c/attachment.zip From fabian at oggu.de Mon Apr 17 04:06:55 2006 From: fabian at oggu.de (Fabian Buch) Date: Mon, 17 Apr 2006 10:06:55 +0200 Subject: [Nitro] [PATCH] Some more nice patches In-Reply-To: References: <7c7da25b364c0ecbabd779be3884a36a@oggu.de> Message-ID: <04cb9b2367f74d4da04f2dddaac02ab0@oggu.de> Am 17.04.2006 um 07:21 schrieb Bryan Soto: > On 4/16/06, Fabian Buch wrote: >> Go ahead. Old applications can run on old Og versions and if upgrading >> is needed there are several ways to do workarounds, if old database >> tables still have to be used and can't be moved: for example a view >> (if >> the store supports it). > > Okay Fabian. Just thought I'd mention it, since oxyliquit was the > first thing that came to mind as using tags. :) Hehe.. thanks. Me and Kashia would be the first to think of creating a view for them ;).. Fabian From manveru at weez.co.jp Mon Apr 17 05:26:51 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Mon, 17 Apr 2006 18:26:51 +0900 Subject: [Nitro] [TC] EZ an arrays again... Message-ID: <200604171826.51234.manveru@weez.co.jp> Could somebody please have a look at that one? -------------- next part -------------- A non-text attachment was scrubbed... Name: tc_ez.rb.tar.gz Type: application/x-tgz Size: 495 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060417/7ee9d518/attachment.bin From transfire at gmail.com Mon Apr 17 08:00:14 2006 From: transfire at gmail.com (TRANS) Date: Mon, 17 Apr 2006 08:00:14 -0400 Subject: [Nitro] Nitro and Amrita In-Reply-To: References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> Message-ID: <4b6f054f0604170500n552e9db0o47545aacc25e645b@mail.gmail.com> On 4/16/06, George Moschovitis wrote: > > I wouldn't neccessarily say that b/c Amrita is different from Nitro's > > templates. Nitro's templates are more like PHPs, while Amrita > > completely separates layout from data. > > NOT really. Nitro Templates can be used in PHP like mode and/or Amrita > style mode. Have a look at this. > > > def action > @user = User.current_user > @name = @user.name > @articles = @user.articles > @something =... > end > > action.xhtml > >
    >

    #@name

    >
      >
    • #{a.title}
      • >
    >
    > > This is fully separated layout from data. Not quite. Code elements are still being directly referenced from within the markup, ie. @name and @articles. In Amrita you don't even have that.

    name here

    • title here
    Then in code: if @user.admin data = { :user_admin => { :name => @name :articles => @articles.collect { |a| { :title => a.title } } } } else data = { :user_admin => nil } end Amrita uses the data structure to determine the layout structure. T. From transfire at gmail.com Mon Apr 17 08:24:29 2006 From: transfire at gmail.com (TRANS) Date: Mon, 17 Apr 2006 08:24:29 -0400 Subject: [Nitro] XmlBuilder In-Reply-To: <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> Message-ID: <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> On 4/16/06, Michael Fellinger wrote: > why're you asking? I'm looking at the code to bring over to Facets, but I see some problems with the code --primarily name clash issues, so I was wondering if people were using it or not, to what degree those issues were effecting them and whether a rewritten version would be okay. T. From aglarond at gmail.com Mon Apr 17 12:07:24 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Mon, 17 Apr 2006 18:07:24 +0200 Subject: [Nitro] [PATCH] Nitro Transformer Message-ID: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> Hi All, I've made a new type of in-Controller compiler. It will take an XHTML template, and "transform" any element within it. So, you can take any standard XHTML file (layout), apply the transformation (code), and get a true separation of layout and code within Nitro. An example usage is given in the in-file documentation. I've used it to place content (from a separate text file) into a certain "div", while changing the "class" of an "a"-tag. Some possible improvements: - tie it into the Nitro compiler pipeline - bind it into Nitro's caching mechanism - get the "base" and "action" variables automatically Currently, a just-transformed template will not be displayed to the browser. A walk of all transform-enabled URIs needs to be done first, and then either all templates recompiled, or Nitro restarted in order to serve up the transformed templates. Let me know if you have a solution to this. Hope this helps someone else to solve the same kinds of problems I've tried to solve. Comments welcome! - Dimitri -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro-transformer.zip Type: application/zip Size: 15554 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060417/38bbcc84/attachment.zip From bryan.a.soto at gmail.com Mon Apr 17 15:59:59 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 17 Apr 2006 12:59:59 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> Message-ID: On 4/17/06, TRANS wrote: > On 4/16/06, Michael Fellinger wrote: > > why're you asking? > > I'm looking at the code to bring over to Facets, but I see some > problems with the code --primarily name clash issues, so I was > wondering if people were using it or not, to what degree those issues > were effecting them and whether a rewritten version would be okay. > For a little bit of history, see: http://rubyforge.org/pipermail/nitro-general/2006-January/002540.html George says renaming shouldn't be a problem as he thinks it's only used indirectly within Nitro. Hope that helps, Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 17 16:45:43 2006 From: transfire at gmail.com (TRANS) Date: Mon, 17 Apr 2006 16:45:43 -0400 Subject: [Nitro] XmlBuilder In-Reply-To: References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> Message-ID: <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> On 4/17/06, Bryan Soto wrote: > On 4/17/06, TRANS wrote: > > On 4/16/06, Michael Fellinger wrote: > > > why're you asking? > > > > I'm looking at the code to bring over to Facets, but I see some > > problems with the code --primarily name clash issues, so I was > > wondering if people were using it or not, to what degree those issues > > were effecting them and whether a rewritten version would be okay. > > > > For a little bit of history, see: > > http://rubyforge.org/pipermail/nitro-general/2006-January/002540.html > > George says renaming shouldn't be a problem as he thinks it's only > used indirectly within Nitro. Thanks. Actually what I meant by name clash is with internal method names in the XmlBuilder itself. Certain tags woould not make it the method_missing call and thus not markup correctly. I'm almost done rebuilding a new version that deals with these issues. OTOH I may rename it after all b/c I'm using REXML to generate the XML instead of just building a string. I did this simply to avoid having to worry about proper escaping --REXML handles it automatically. So in the case I may in fact rename it to REXMLBuilder or something like that. If someone would prefer a pure string builder then it would be easy enough to create. It just takes a utility/helper module and a little extra glue to past them together: class MyBuilder < Builder include MyHelper # def method_missing ... # def to_s ... end Which brings me to this last issue --the one I think you were thinking I meant. Jim is using Builder namespace so maybe we need something else. But what? T. From james_b at neurogami.com Mon Apr 17 17:09:33 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 17 Apr 2006 14:09:33 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> Message-ID: <4444040D.2090907@neurogami.com> TRANS wrote: ... > > Which brings me to this last issue --the one I think you were thinking > I meant. Jim is using Builder namespace so maybe we need something > else. But what? > Should we try to stick to Nitro "branding" , images, and metaphors? Such as using the names of chemicals and/or explosives? Something like XmlBlaster? -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Mon Apr 17 17:39:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 17 Apr 2006 14:39:56 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> Message-ID: On 4/17/06, TRANS wrote: > Thanks. Actually what I meant by name clash is with internal method > names in the XmlBuilder itself. Certain tags woould not make it the > method_missing call and thus not markup correctly. I'm almost done > rebuilding a new version that deals with these issues. OTOH I may > rename it after all b/c I'm using REXML to generate the XML instead of > just building a string. I did this simply to avoid having to worry > about proper escaping --REXML handles it automatically. So in the case > I may in fact rename it to REXMLBuilder or something like that. If > someone would prefer a pure string builder then it would be easy > enough to create. It just takes a utility/helper module and a little > extra glue to past them together: > > class MyBuilder < Builder > include MyHelper > # def method_missing ... > # def to_s ... > end > > Which brings me to this last issue --the one I think you were thinking > I meant. Jim is using Builder namespace so maybe we need something > else. But what? > Does it do anything different from builder? If not, perhaps Generator, Fabricator or Maker? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From aglarond at gmail.com Mon Apr 17 18:07:12 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Tue, 18 Apr 2006 00:07:12 +0200 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> Message-ID: <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> Minor fix to generate directories in the output path, if they don't already exist. - Dimitri -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro-transformer.zip Type: application/zip Size: 15554 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060417/6039d52b/attachment.zip From bryan.a.soto at gmail.com Mon Apr 17 20:03:07 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 17 Apr 2006 17:03:07 -0700 Subject: [Nitro] Repo updated and beta gems. Message-ID: darcs pull or gem update -y # update all your installed gems. # Optionally, just update facets, cmdparse, daemons gem update -y --source devlab.oree.ch/~bryan/beta gem cleanup I try to keep the repo stable (just my philosophy), so if you run into a problem, we probably don't know it's there unless it has a ticket on the devlab trac. So feel free to report bugs. :) I've tried cleaning up the dependencies as well. Unfortunately gems doesn't seem to handle circular dependencies very well, so I had to remove them, i.e. Og doesn't depend on Glue anymore. :/ If you want to downgrade: %w[gen nitro og glue].each do |package| `gem uninstall #{package}` end gem install nitro -y The following patches were applied: [Nitro] [PATCH] New patch... http://rubyforge.org/pipermail/nitro-general/2006-April/004006.html [Nitro] [PATCH] test-fix-tc_aggregations_calculations http://rubyforge.org/pipermail/nitro-general/2006-April/003975.html [Nitro] [PATCH] og-aggregate-type-casting http://rubyforge.org/pipermail/nitro-general/2006-April/003962.html [Nitro] [PATCH][FIX] bugfix-nitro-R-operator http://rubyforge.org/pipermail/nitro-general/2006-April/003960.html [Nitro] [PATCH][BUGFIX] og-joins_many-relation http://rubyforge.org/pipermail/nitro-general/2006-April/003957.html [Nitro] [PATCH] tags http://rubyforge.org/pipermail/nitro-general/2006-April/003829.html [Nitro] [PATCH]: og-postgres-sti-fix http://rubyforge.org/pipermail/nitro-general/2006-April/003811.html [Nitro] [PATCH] og-postgres-join-tables http://rubyforge.org/pipermail/nitro-general/2006-April/003801.html [Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly http://rubyforge.org/pipermail/nitro-general/2006-April/003762.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From manveru at weez.co.jp Mon Apr 17 21:15:16 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Tue, 18 Apr 2006 10:15:16 +0900 Subject: [Nitro] XmlBuilder In-Reply-To: <4444040D.2090907@neurogami.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> Message-ID: <200604181015.16952.manveru@weez.co.jp> On Tuesday 18 April 2006 06:09, James Britt wrote: > TRANS wrote: > ... > > > Which brings me to this last issue --the one I think you were thinking > > I meant. Jim is using Builder namespace so maybe we need something > > else. But what? > > Should we try to stick to Nitro "branding" , images, and metaphors? > Such as using the names of chemicals and/or explosives? > > Something like XmlBlaster? Since we're at it: i don't think we should give it a destructive name :) How about something like Catalyst or Reductor? From bryan.a.soto at gmail.com Mon Apr 17 21:27:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 17 Apr 2006 18:27:25 -0700 Subject: [Nitro] [PATCH] Logger.debug woe In-Reply-To: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> References: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Message-ID: Hey manveru, I got a conflict with this. I'll take care of it and will probably apply in a few hours. Just so you know. :) On 4/12/06, Michael Fellinger wrote: > Hey all, > > I finally sat down, after hearing lots of complains from various > sides, and added the 'if $DBG' statement at all the Logger.debug > outputs where it was missing, except for the logger-testcase where it > might make sense, didn't have a closer look tho.. > to trace the missing statements down i used: > ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ /_darcs/}' > > maybe that's something to add to a testcase and trace down missing > statements if they occur again... > > Hope it doesn't break anything, and i'm not sure if all the > Logger.debug for the kind-of-session-noticing need that too, but here > it is :) > > ~~~~manveru > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From george.moschovitis at gmail.com Tue Apr 18 03:09:13 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 10:09:13 +0300 Subject: [Nitro] Nitro and Amrita In-Reply-To: <4b6f054f0604170500n552e9db0o47545aacc25e645b@mail.gmail.com> References: <4b6f054f0604131132j2a4c3288g1b6b4b76e8f3a66a@mail.gmail.com> <4b6f054f0604151222g1daac330va4cc9cf921b35d74@mail.gmail.com> <4b6f054f0604170500n552e9db0o47545aacc25e645b@mail.gmail.com> Message-ID: This is extremely easy to do in Nitro with a compiler. In fact I will implement this kind of compiler one of the following days, just for fun (because personally I think it is useless). Stay tuned ;-) -g. On 4/17/06, TRANS wrote: > On 4/16/06, George Moschovitis wrote: > > > I wouldn't neccessarily say that b/c Amrita is different from Nitro's > > > templates. Nitro's templates are more like PHPs, while Amrita > > > completely separates layout from data. > > > > NOT really. Nitro Templates can be used in PHP like mode and/or Amrita > > style mode. Have a look at this. > > > > > > def action > > @user = User.current_user > > @name = @user.name > > @articles = @user.articles > > @something =... > > end > > > > action.xhtml > > > >
    > >

    #@name

    > >
      > >
    • #{a.title}
      • > >
    > >
    > > > > This is fully separated layout from data. > > Not quite. Code elements are still being directly referenced from > within the markup, ie. @name and @articles. In Amrita you don't even > have that. > >
    >

    name here

    >
      >
    • title here
      • >
    >
    > > Then in code: > > if @user.admin > data = { > :user_admin => { > :name => @name > :articles => @articles.collect { |a| > { :title => a.title } > } > } > } > else > data = { :user_admin => nil } > end > > Amrita uses the data structure to determine the layout structure. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 03:11:18 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 10:11:18 +0300 Subject: [Nitro] XmlBuilder In-Reply-To: <4444040D.2090907@neurogami.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> Message-ID: > Something like XmlBlaster? naah ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 03:18:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 10:18:28 +0300 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> Message-ID: So much to review, so little time ;-) Thanks anyway! -g. On 4/18/06, Dimitri Aivaliotis wrote: > Minor fix to generate directories in the output path, if they don't > already exist. > > - Dimitri > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 04:39:54 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 11:39:54 +0300 Subject: [Nitro] Facets 1.3.1 ?? Message-ID: Tom, will you release this? -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From surrender_it at yahoo.it Tue Apr 18 06:36:40 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Tue, 18 Apr 2006 12:36:40 +0200 Subject: [Nitro] Google Summer of Code? Message-ID: Hi people, have someone thought of making Nitro/Og a mentoring project for google's SOC? I think there would be quite a bit of students that would appreciate some nitro hacking in the summer, and the rule seem to allow it. From transfire at gmail.com Tue Apr 18 07:53:16 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 07:53:16 -0400 Subject: [Nitro] Facets 1.3.1 ?? In-Reply-To: References: Message-ID: <4b6f054f0604180453u64c21d36n805a4fd7b3a9fdac@mail.gmail.com> Done. Please have a look at BuilderObject and REXMLBuilder in the More library. This implimentation differs from Jim's Builder by using a redirection Functor --via the method #out, though I may change that name to #build (?). So you don't need special methods with exlimation marks like 'comment!' You just do 'out.comment' instead. It also allows for implicit receiver (like Markaby) or explict receiver (like Jim's Builder). T. From transfire at gmail.com Tue Apr 18 07:58:08 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 07:58:08 -0400 Subject: [Nitro] Google Summer of Code? In-Reply-To: References: Message-ID: <4b6f054f0604180458u47ab1f6cx344ab24f7533fe7b@mail.gmail.com> On 4/18/06, gabriele renzi wrote: > Hi people, > > have someone thought of making Nitro/Og a mentoring project for > google's SOC? > I think there would be quite a bit of students that would appreciate > some nitro hacking in the summer, and the rule seem to allow it. That sounds like a good idea! George are you looking into this by any chance? T. From george.moschovitis at gmail.com Tue Apr 18 09:11:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 16:11:15 +0300 Subject: [Nitro] Facets 1.3.1 ?? In-Reply-To: <4b6f054f0604180453u64c21d36n805a4fd7b3a9fdac@mail.gmail.com> References: <4b6f054f0604180453u64c21d36n805a4fd7b3a9fdac@mail.gmail.com> Message-ID: Ok, let me have a look at this... thanks, George. On 4/18/06, TRANS wrote: > Done. > > Please have a look at BuilderObject and REXMLBuilder in the More library. > > This implimentation differs from Jim's Builder by using a redirection > Functor --via the method #out, though I may change that name to #build > (?). So you don't need special methods with exlimation marks like > 'comment!' You just do 'out.comment' instead. > > It also allows for implicit receiver (like Markaby) or explict > receiver (like Jim's Builder). > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 09:11:57 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 16:11:57 +0300 Subject: [Nitro] Google Summer of Code? In-Reply-To: <4b6f054f0604180458u47ab1f6cx344ab24f7533fe7b@mail.gmail.com> References: <4b6f054f0604180458u47ab1f6cx344ab24f7533fe7b@mail.gmail.com> Message-ID: Nope, I am not looking into this but it sounds like a nice idea. When is the deadline? -g. On 4/18/06, TRANS wrote: > On 4/18/06, gabriele renzi wrote: > > Hi people, > > > > have someone thought of making Nitro/Og a mentoring project for > > google's SOC? > > I think there would be quite a bit of students that would appreciate > > some nitro hacking in the summer, and the rule seem to allow it. > > That sounds like a good idea! George are you looking into this by any chance? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 09:12:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 16:12:24 +0300 Subject: [Nitro] Google Summer of Code? In-Reply-To: References: <4b6f054f0604180458u47ab1f6cx344ab24f7533fe7b@mail.gmail.com> Message-ID: I want to bring the nitro-site up before submitting a proposal to google. -g. On 4/18/06, George Moschovitis wrote: > Nope, I am not looking into this but it sounds like a nice idea. When > is the deadline? > > -g. > > On 4/18/06, TRANS wrote: > > On 4/18/06, gabriele renzi wrote: > > > Hi people, > > > > > > have someone thought of making Nitro/Og a mentoring project for > > > google's SOC? > > > I think there would be quite a bit of students that would appreciate > > > some nitro hacking in the summer, and the rule seem to allow it. > > > > That sounds like a good idea! George are you looking into this by any chance? > > > > T. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Tue Apr 18 09:26:26 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 09:26:26 -0400 Subject: [Nitro] Facets 1.3.1 ?? In-Reply-To: References: <4b6f054f0604180453u64c21d36n805a4fd7b3a9fdac@mail.gmail.com> Message-ID: <4b6f054f0604180626t49646625m9ca53c3f85b519a6@mail.gmail.com> On 4/18/06, George Moschovitis wrote: > Ok, let me have a look at this... Cool. BTW, I just re-uploaded 1.3.1 b/c I had left my dev exmaple of rexmlbuilder uncommented. Shuold be okay now. T. From james_b at neurogami.com Tue Apr 18 10:18:48 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 18 Apr 2006 07:18:48 -0700 Subject: [Nitro] XmlBuilder In-Reply-To: References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> Message-ID: <4444F548.2000201@neurogami.com> George Moschovitis wrote: >>Something like XmlBlaster? > > > > naah ;-) :) I was being fairly facetious. I'm curious, though, what people think of trying to foster a particular metaphor or imagery for Og/Nitro and its related libraries. On the one hand, it can improve name recognition; the downside is that trying to pick names that fit into some particular theme can lead to some extreme goofiness. -- James Britt "A principle or axiom is of no value without the rules for applying it." - Len Bullard From george.moschovitis at gmail.com Tue Apr 18 10:20:15 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 17:20:15 +0300 Subject: [Nitro] web/html methods in facets. Message-ID: Tom, do you think it could be possible to add some html/web related methods in Facets? In the Rails actionpack/helpers dir there are some very useful methods, perhaps some more useful methods are in ActiveSupport. what do you think? George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Tue Apr 18 10:23:23 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 18 Apr 2006 07:23:23 -0700 Subject: [Nitro] Google Summer of Code? In-Reply-To: References: Message-ID: <4444F65B.5030104@neurogami.com> gabriele renzi wrote: > Hi people, > > have someone thought of making Nitro/Og a mentoring project for > google's SOC? > I think there would be quite a bit of students that would appreciate > some nitro hacking in the summer, and the rule seem to allow it. There's been some discussion on this in ruby-talk, and Ruby Central is signing up to be a sponsor. You may want to contact David Black, who recently posted this message: "I've tracked down the info about applying to be a mentor. There's a URL you have to go to, which Google is keeping off their website to try to avoid spam applications. I'm emailing this URL to the people who have expressed mentoring interest here. If you're interested, please email me and I'll email it to you." http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/189244 -- James Britt "A principle or axiom is of no value without the rules for applying it." - Len Bullard From transfire at gmail.com Tue Apr 18 10:40:51 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 10:40:51 -0400 Subject: [Nitro] XmlBuilder In-Reply-To: <4444F548.2000201@neurogami.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> <4444F548.2000201@neurogami.com> Message-ID: <4b6f054f0604180740i38e16f24refa34e7a7591b164@mail.gmail.com> On 4/18/06, James Britt wrote: > George Moschovitis wrote: > >>Something like XmlBlaster? > > > > > > > > naah ;-) > > :) I was being fairly facetious. > > I'm curious, though, what people think of trying to foster a particular > metaphor or imagery for Og/Nitro and its related libraries. > > On the one hand, it can improve name recognition; the downside is that > trying to pick names that fit into some particular theme can lead to > some extreme goofiness. Well I ended up being fairly conervative and named it BuilderObject, since it is meant to be subclassed and not used directly, it fits the pattern of other classes like BasicObject and MockObject, etc. As for the theme naming, I think that's good at higher levels. Facets is a general purpse library. Nitro uses Facets and since Nitro is the "biggest" user of Facets it gets special consideration, clearly. Yet everything in Facets must be general purpose. Personally, I think that's one of the strengths of this relationship. At times it makes things more difficult, but in the end I think the projects are better for it. Anyway, that also means theme naming doesn't apply to Facets in this way. Nonetheless "Blaster" is kind of cool and I actually seriously consider it at first :-) T. From transfire at gmail.com Tue Apr 18 10:54:20 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 10:54:20 -0400 Subject: [Nitro] web/html methods in facets. In-Reply-To: References: Message-ID: <4b6f054f0604180754k61b7b2b6q31ec27a3d8a1e98c@mail.gmail.com> On 4/18/06, George Moschovitis wrote: > Tom, > > do you think it could be possible to add some html/web related methods > in Facets? > In the Rails actionpack/helpers dir there are some very useful > methods, perhaps some more useful methods are in ActiveSupport. > > what do you think? Yep yep. That's actually one of the next things on the agenda. I was planning to create a HtmlHelper module or something like that and also creating a Builder for it. It will pull together the numerous pieces you have in Nitro for this, some from ActiveSupport and some I have sitting around here. Expect it in about a week. There are still a few other things I need to look at like configuration.rb/settings.rb and also zimba sent me a Reactor lib I've been planning to dig into. And I plan to add lazy.rb as well. And of course a few other minor things. Are there other major libs to address? Once all that's done I imagine things will finally start to settle down and the focus can shift to bug fixes and simple enhancements. After that I need to work on some other things, so I'm going to create the Darcs repository for Facets and I'm hopping to find someone else to be a co-maintatiner. T. From george.moschovitis at gmail.com Tue Apr 18 10:59:17 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 17:59:17 +0300 Subject: [Nitro] XmlBuilder In-Reply-To: <4b6f054f0604180740i38e16f24refa34e7a7591b164@mail.gmail.com> References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> <4444F548.2000201@neurogami.com> <4b6f054f0604180740i38e16f24refa34e7a7591b164@mail.gmail.com> Message-ID: BuilderObject is ok, lets stick on this... -g. On 4/18/06, TRANS wrote: > On 4/18/06, James Britt wrote: > > George Moschovitis wrote: > > >>Something like XmlBlaster? > > > > > > > > > > > > naah ;-) > > > > :) I was being fairly facetious. > > > > I'm curious, though, what people think of trying to foster a particular > > metaphor or imagery for Og/Nitro and its related libraries. > > > > On the one hand, it can improve name recognition; the downside is that > > trying to pick names that fit into some particular theme can lead to > > some extreme goofiness. > > Well I ended up being fairly conervative and named it BuilderObject, > since it is meant to be subclassed and not used directly, it fits the > pattern of other classes like BasicObject and MockObject, etc. > > As for the theme naming, I think that's good at higher levels. Facets > is a general purpse library. Nitro uses Facets and since Nitro is the > "biggest" user of Facets it gets special consideration, clearly. Yet > everything in Facets must be general purpose. Personally, I think > that's one of the strengths of this relationship. At times it makes > things more difficult, but in the end I think the projects are better > for it. Anyway, that also means theme naming doesn't apply to Facets > in this way. > > Nonetheless "Blaster" is kind of cool and I actually seriously > consider it at first :-) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 11:00:42 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 18:00:42 +0300 Subject: [Nitro] [PATCH] Some more stuff. Message-ID: I removed some glue files that were integrated in facets 1.3.1, so after you apply the patch you will need the latest facets version. Will remove some more stuff (flexob, builder) before the release. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Tue Apr 18 11:01:41 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 18:01:41 +0300 Subject: [Nitro] [PATCH] here is the patch Message-ID: I forgot to attach the patch, here you are: Mon Apr 17 11:18:15 EEST 2006 George Moschovitis * Added context.no_sync! option, low level hack needed when modifying the users session in interesting ways ;-) Shall I send this patch? (1/5) [ynWvpxqadjk], or ? for help: y Mon Apr 17 11:37:21 EEST 2006 George Moschovitis * More flexible Script generator, the developer can use most of its features without a Client subclass. Shall I send this patch? (2/5) [ynWvpxqadjk], or ? for help: y Tue Apr 18 17:16:33 EEST 2006 George Moschovitis * Removed from glue files that where added in Facets, adapted Nitro accordingly. Shall I send this patch? (3/5) [ynWvpxqadjk], or ? for help: y -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 18053 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060418/091a80ce/attachment.zip From george.moschovitis at gmail.com Tue Apr 18 11:03:14 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 18 Apr 2006 18:03:14 +0300 Subject: [Nitro] Test cases and submitting patches. Message-ID: Dear devs, I have added a script that runs all nitro tests: script/test.rb you can optionally pass a project name to restrict the test cases to be run: script/test.rb nitro The current repo version passes all tests. Please run this script before submitting your patches and make sure that all tests are passed. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From transfire at gmail.com Tue Apr 18 11:12:23 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 11:12:23 -0400 Subject: [Nitro] XmlBuilder In-Reply-To: References: <4b6f054f0604160704i775dec88t7cbfadf2fc7089fc@mail.gmail.com> <9c00d3e00604160846r24431893ob1a00f5a0c1d75fc@mail.gmail.com> <4b6f054f0604170524n6388d4b1mc4b04b05d04e9312@mail.gmail.com> <4b6f054f0604171345j4927c250o2ff1039d3589478c@mail.gmail.com> <4444040D.2090907@neurogami.com> <4444F548.2000201@neurogami.com> <4b6f054f0604180740i38e16f24refa34e7a7591b164@mail.gmail.com> Message-ID: <4b6f054f0604180812h7a23c5c4g902f225813060db6@mail.gmail.com> On 4/18/06, George Moschovitis wrote: > BuilderObject is ok, lets stick on this... Okay. I was just going throught the code to see about building a string based builder, and realized I have a design flaw. I will have to go back to consider this. T. From transfire at gmail.com Tue Apr 18 11:16:42 2006 From: transfire at gmail.com (TRANS) Date: Tue, 18 Apr 2006 11:16:42 -0400 Subject: [Nitro] Test cases and submitting patches. In-Reply-To: References: Message-ID: <4b6f054f0604180816v3139b2beubf87f10f3b5847c9@mail.gmail.com> On 4/18/06, George Moschovitis wrote: > Dear devs, > > I have added a script that runs all nitro tests: > > script/test.rb > > you can optionally pass a project name to restrict the test cases to be run: > > script/test.rb nitro hmm... guess I'll have to take a look at this. I've been using 'reap test'. T. From surrender_it at yahoo.it Tue Apr 18 11:56:49 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Tue, 18 Apr 2006 17:56:49 +0200 Subject: [Nitro] Google Summer of Code? In-Reply-To: <4444F65B.5030104@neurogami.com> References: <4444F65B.5030104@neurogami.com> Message-ID: James Britt ha scritto: > There's been some discussion on this in ruby-talk, and Ruby Central is > signing up to be a sponsor. yes I know, but since I noticed that there are many specific projects applying by themselves instead of relying on a more general umbrella (i.e. MoinMoin is written in python but there is a specific mentoring entry for it instead that under the PSF one), so I thought my idea could be meaningful. > You may want to contact David Black, who recently posted this message: ah, I blame the broken GW for not seing this message on the nntp side :) So maybe the best thing is for george to contact dblack directly. From zimba.tm at gmail.com Tue Apr 18 12:43:56 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 18 Apr 2006 18:43:56 +0200 Subject: [Nitro] [patch] Small fix for Nitro without Og Message-ID: <4E0A6478-0F00-42B1-9851-BA6AC4C402E6@gmail.com> Tue Apr 18 18:40:37 CEST 2006 Jonas Pfenniger * [small fix] Nitro didn't start properly when Og was not used -------------- next part -------------- A non-text attachment was scrubbed... Name: small_nitro_og_fix Type: application/octet-stream Size: 45932 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060418/31506ab1/attachment.obj From zimba.tm at gmail.com Tue Apr 18 12:57:51 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 18 Apr 2006 18:57:51 +0200 Subject: [Nitro] (no subject) Message-ID: <22CA4A05-0ACC-4EAD-A56A-D3D7B92643DE@gmail.com> Hi list, what happened to the self.setup_template_root method ? Some relics are still in the code but I don't see any use of it at the compiler place. Cheers, zimbatm From james_b at neurogami.com Tue Apr 18 13:54:46 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 18 Apr 2006 10:54:46 -0700 Subject: [Nitro] Google Summer of Code? In-Reply-To: References: <4444F65B.5030104@neurogami.com> Message-ID: <444527E6.7080100@neurogami.com> gabriele renzi wrote: > James Britt ha scritto: > > >>There's been some discussion on this in ruby-talk, and Ruby Central is >>signing up to be a sponsor. > > > yes I know, but since I noticed that there are many specific projects > applying by themselves instead of relying on a more general umbrella > (i.e. MoinMoin is written in python but there is a specific mentoring > entry for it instead that under the PSF one), so I thought my idea could > be meaningful. Oh, that may very well be. I've only glanced at the SoC page, and have been following the thread on r-t. So I'm fuzzy on the details and differences between mentors and sponsors. -- James Britt From bryan.a.soto at gmail.com Tue Apr 18 14:40:15 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 11:40:15 -0700 Subject: [Nitro] (no subject) In-Reply-To: <22CA4A05-0ACC-4EAD-A56A-D3D7B92643DE@gmail.com> References: <22CA4A05-0ACC-4EAD-A56A-D3D7B92643DE@gmail.com> Message-ID: On 4/18/06, Jonas Pfenniger wrote: > Hi list, > > what happened to the self.setup_template_root method ? > Some relics are still in the code but I don't see any use of it at > the compiler place. > George introduced a new template root system for 29.0. The basic idea is that you override that method and set up your template roots by adding them to an array stored in @template_root, I think. Check out nitro/lib/nitro/controller.rb, method named mount_at. Perhaps that will give you better explanation. Bryan PS: I tried to use the source browser on Trac to see the changes and got an error, database table is locked. http://devlab.oree.ch/trac/nitrohq/browser -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From fabian at oggu.de Tue Apr 18 15:01:39 2006 From: fabian at oggu.de (Fabian Buch) Date: Tue, 18 Apr 2006 21:01:39 +0200 Subject: [Nitro] [PATCH] New FeedHelper Message-ID: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> new FeedHelper . reimplementation of RssHelper to support all RSS versions . very few code left of Georges original RssHelper . supports RSS versions 0.91, 1.0 and 2.0 . supports Atom 1.0 . supports rough OPML 1.0 . should be backward compatible to the RssHelper for RSS 0.91 feeds . just change "helper :rss" to "helper :feed" for access to all the new features . not much tested yet, so be careful, but test a lot and report bugs . big RDoc, so everyone knows how to use it . more tests, but it still could use a lot more.. (but tests are no validator, right?) RSS 0.91, 1.0, 2.0 and Atom 1.0 validate against http://feedvalidator.org with a quick testapp I've written. It's not in a real-world app yet (oxyliquit has some issues with current glycerin), so there might still be bugs. OPML ist not tested in any app yet. If someone has time to test it or knows a better usage, please tell me, I might improve it then. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: feedhelper.patch.gz Type: application/x-gzip Size: 18979 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060418/874064b5/attachment.gz From bryan.a.soto at gmail.com Tue Apr 18 15:56:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 12:56:53 -0700 Subject: [Nitro] Test cases and submitting patches. In-Reply-To: References: Message-ID: On 4/18/06, George Moschovitis wrote: > Dear devs, > > I have added a script that runs all nitro tests: > > script/test.rb > > you can optionally pass a project name to restrict the test cases to be run: > > script/test.rb nitro > I've touched it up a wee bit. Adds a require to glycerin.rb for people (like me) that don't have RUBYLIB or whatever the environment variable is set (I have too many copies of the repo for this to be feasible ;). Instead of system, I load the files and pass over files ending in a tilde (~) and made it so you can run multiple dirs, i.e. $ ./script/test.rb nitro glue darcs pull for it. > The current repo version passes all tests. Please run this script > before submitting your patches and make sure that all tests are > passed. > Postgres should still have some failures. That refactoring patch that removed some of it's overrides fixed them. Kirby still fails as well. And I believe you still get some failures if you have anything other than Mysql set to the second store. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 18 16:01:51 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 13:01:51 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> Message-ID: On 4/18/06, Fabian Buch wrote: > > new FeedHelper > I've been waiting for this since you mentioned it on #nitro. :) > RSS 0.91, 1.0, 2.0 and Atom 1.0 validate against > http://feedvalidator.org with a quick testapp I've written. It's not in > a real-world app yet (oxyliquit has some issues with current glycerin), Bug reports just make Nitro and Og all the better, so what are the issues? Please!!! :) > so there might still be bugs. > OPML ist not tested in any app yet. If someone has time to test it or > knows a better usage, please tell me, I might improve it then. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 18 16:09:39 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 13:09:39 -0700 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> Message-ID: Manveru, was this the patch you mentioned on #nitro? On 3/3/06, Michael Fellinger wrote: > Hello List, > > I just made a bundle that makes the template-root for flare more > standard, moving it from /template to /templates and adding a > Template.root = "templates" in the run.rb > I could have left this one out since it's the standard, but i'd rather > go sure... > > ~~~~manveru > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Tue Apr 18 16:17:45 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 18 Apr 2006 16:17:45 -0400 Subject: [Nitro] Bryan & dispatcher/router patch? Message-ID: <44454969.9090605@cataclysm-software.net> Hey Bryan, Did you get my patch for the router/redirect change? I haven't seen anything about it on the ML since I submitted.... Andrew From bryan.a.soto at gmail.com Tue Apr 18 16:57:29 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 13:57:29 -0700 Subject: [Nitro] Retrospective and future direction. Message-ID: Over the past two months, I think we've made good progress in taming glycerin. :) We've fixed lots of bugs, added test cases, were gifted with Oxyliquit and our little community is growing. Good work all! I hope people are finding Nitro and Og more stable than ever before. And if you aren't, please let us know so we can fix it. :) Overall, I'm pleased with our progress. I do have to note that patches aren't being applied very quickly, so that's definitely a sticking point in our process that is solely on me. If anyone has anything else to add, good or bad, please do. Especially suggestions that can improve things for us. Now, for future direction, let's start charting our course for 0.31.0. Community participation is especially encouraged here. :) A few of my ideas are below. Please note, I'm merely making suggestions, not defining a course. I think the community as a whole should decide that. I think we should start easing the learning curve. So I suggest we concentrate on writing docs and asking and answering questions on Oxyliquit. This would benefit everyone obviously. I also think we can do a few things to make writing apps easier. I'd like to suggest my gen scaffold and gen model ideas as enhancements to be worked on. Basically, the scaffolding would write everything out to files for easy editing. The model would write out an Og model for an existing database table. The basic idea is to make it really easy to get an application up and running. Anyway, those are my thoughts. I look forward to hearing from others. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 18 16:58:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 13:58:56 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <44454969.9090605@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> Message-ID: On 4/18/06, Andrew Thompson wrote: > Hey Bryan, > > Did you get my patch for the router/redirect change? I haven't seen > anything about it on the ML since I submitted.... > Yes, I did. I'm sorry. I haven't had a chance to make it into a darcs bundle. I'll try and take care of that today. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 18 17:01:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 14:01:21 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <44454969.9090605@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> Message-ID: On 4/18/06, Andrew Thompson wrote: > Hey Bryan, > > Did you get my patch for the router/redirect change? I haven't seen > anything about it on the ML since I submitted.... > And *thank you* for reminding me. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Tue Apr 18 17:49:11 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Tue, 18 Apr 2006 17:49:11 -0400 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: Message-ID: <44455ED7.5040504@cataclysm-software.net> Bryan Soto wrote: > > I think we should start easing the learning curve. So I suggest we > concentrate on writing docs and asking and answering questions on > Oxyliquit. This would benefit everyone obviously. I *totally* agree that we need to do this, we should also audit the code for those 'wtf' methods that nitro seems to have a few of so we can document only functions that actually do something useful ;) Some detailed docs on deploying nitro in different enviroments on different webservers would also be welcome as well as some kind of overview as to what is preferred for different setups. It'd also be nice to have some tutorials that actually go through simple Og and nitro applications. The ones I've seen on this topic usually end with a 'to be continued..' and miss out a lot of important/useful stuff and/or are horribly outdated. Also, it'd be nice to do a pure cleanup/bugfix/documentation release but, I think george is addicted to feature-creep ;) Vag From m.fellinger at gmail.com Tue Apr 18 19:48:40 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Wed, 19 Apr 2006 08:48:40 +0900 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> Message-ID: <9c00d3e00604181648v150a109eo575c40e4784df940@mail.gmail.com> Yeah, it never got applied afaik... On 4/19/06, Bryan Soto wrote:> Manveru, was this the patch you mentioned on #nitro?>> On 3/3/06, Michael Fellinger wrote:> > Hello List,> >> > I just made a bundle that makes the template-root for flare more> > standard, moving it from /template to /templates and adding a> > Template.root = "templates" in the run.rb> > I could have left this one out since it's the standard, but i'd rather> > go sure...> >> > ~~~~manveru> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From bryan.a.soto at gmail.com Tue Apr 18 20:29:43 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 17:29:43 -0700 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: <9c00d3e00604181648v150a109eo575c40e4784df940@mail.gmail.com> References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <9c00d3e00604181648v150a109eo575c40e4784df940@mail.gmail.com> Message-ID: Just wanted to find out. We'll see if it still applies. Thanks. :) On 4/18/06, Michael Fellinger wrote: > Yeah, it never got applied afaik... > On 4/19/06, Bryan Soto wrote:> Manveru, was this the patch you mentioned on #nitro?>> On 3/3/06, Michael Fellinger wrote:> > Hello List,> >> > I just made a bundle that makes the template-root for flare more> > standard, moving it from /template to /templates and adding a> > Template.root = "templates" in the run.rb> > I could have left this one out since it's the standard, but i'd rather> > go sure...> >> > ~~~~manveru> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 18 21:08:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 18:08:25 -0700 Subject: [Nitro] Test cases and submitting patches. In-Reply-To: References: Message-ID: On 4/18/06, George Moschovitis wrote: > The current repo version passes all tests. Please run this script There's these for glue: Copied from http://rubyforge.org/pipermail/nitro-general/2006-April/003743.html Hey George, I've applied to devlab. I still have that same question on the configuration patch. I copied and pasted from my previous email below. You added that evil clear_all_settings method back to Glue::Configuration again in tc_configuration. Is there a reason for that? It causes the test cases after that to fail when you run rake test for glue. Or perhaps the problem is actually in tc_fixture since it fails after the settings are cleared? 1) Error: test_all(TestFixture): NoMethodError: undefined method `[]' for nil:NilClass (eval):3:in `root_dir' ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' ./test/glue/tc_fixture.rb:20:in `test_all' 2) Error: test_global(TestFixture): NoMethodError: undefined method `[]' for nil:NilClass (eval):3:in `root_dir' ./test/glue/../../lib/glue/fixture.rb:70:in `initialize' ./test/glue/../../lib/glue/fixture.rb:23:in `load' ./test/glue/../../lib/glue/fixture.rb:22:in `load' ./test/glue/tc_fixture.rb:38:in `test_global' 36 tests, 160 assertions, 0 failures, 2 errors There's also this rather interesting one that doesn't show up when running rake test for Og: /mnt/zip/devlab/nitrohq/og/lib/og/relation/has_many.rb:22:in `resolve_polymorphic': undefined method `relations' for Bar:Class (NoMethodError) from /mnt/zip/devlab/nitrohq/og/lib/og/relation.rb:197:in `resolve_polymorphic_relations' from /mnt/zip/devlab/nitrohq/og/lib/og/relation.rb:183:in `resolve_polymorphic_relations' from /mnt/zip/devlab/nitrohq/og/lib/og/manager.rb:222:in `manage_classes' from /mnt/zip/devlab/nitrohq/og/lib/og/manager.rb:222:in `manage_classes' from ./test/og/tc_accumulator.rb:28 from ./script/test.rb:20 from /usr/lib/ruby/gems/1.8/gems/facets-1.3.1/lib/facets/core/dir/self/ls_r.rb:15:in `recurse' from /usr/lib/ruby/gems/1.8/gems/facets-1.3.1/lib/facets/core/dir/self/ls_r.rb:11:in `recurse' from /usr/lib/ruby/gems/1.8/gems/facets-1.3.1/lib/facets/core/dir/self/ls_r.rb:17:in `recurse' from /usr/lib/ruby/gems/1.8/gems/facets-1.3.1/lib/facets/core/dir/self/ls_r.rb:11:in `recurse' from ./script/test.rb:18 from ./script/test.rb:17 from ./script/test.rb:15 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 19 01:04:34 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 22:04:34 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <44454969.9090605@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> Message-ID: Andrew, Could you eyeball this patch to make sure I got the important bits? Funny coincidence, but I was trying to handle your other issue "Controller resolution order" in the same repo. :) http://rubyforge.org/pipermail/nitro-general/2006-March/003203.html On 4/18/06, Andrew Thompson wrote: > Hey Bryan, > > Did you get my patch for the router/redirect change? I haven't seen > anything about it on the ML since I submitted.... > > Andrew > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 19 01:05:23 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 18 Apr 2006 22:05:23 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: References: <44454969.9090605@cataclysm-software.net> Message-ID: Hair trigger with the send button :/ On 4/18/06, Bryan Soto wrote: > Andrew, > > Could you eyeball this patch to make sure I got the important bits? > Funny coincidence, but I was trying to handle your other issue > "Controller resolution order" in the same repo. :) > > http://rubyforge.org/pipermail/nitro-general/2006-March/003203.html > > On 4/18/06, Andrew Thompson wrote: > > Hey Bryan, > > > > Did you get my patch for the router/redirect change? I haven't seen > > anything about it on the ML since I submitted.... > > > > Andrew > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro-strip-path.zip Type: application/zip Size: 14746 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060419/f58976a8/attachment.zip From transfire at gmail.com Wed Apr 19 02:40:44 2006 From: transfire at gmail.com (TRANS) Date: Wed, 19 Apr 2006 02:40:44 -0400 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44455ED7.5040504@cataclysm-software.net> References: <44455ED7.5040504@cataclysm-software.net> Message-ID: <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> I'd like to see the template system become completey pluggable. I think it would be better for Nitro, so it can focus on core functionality. Maybe that's not possible for some reason, but it'sa thought. Nitro's template system could then become an separated project, like Og, if someone wished to maintain it (George or otherwise). On 4/18/06, Andrew Thompson wrote: > Also, it'd be nice to do a pure cleanup/bugfix/documentation release > but, I think george is addicted to feature-creep ;) I think so too. In fact there should be a few of these for every major release, I think. T. From zimba.tm at gmail.com Wed Apr 19 03:56:00 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 19 Apr 2006 09:56:00 +0200 Subject: [Nitro] (no subject) In-Reply-To: References: <22CA4A05-0ACC-4EAD-A56A-D3D7B92643DE@gmail.com> Message-ID: Le 18 avr. 06 ? 20:40, Bryan Soto a ?crit : > George introduced a new template root system for 29.0. The basic idea > is that you override that method and set up your template roots by > adding them to an array stored in @template_root, I think. Check out > nitro/lib/nitro/controller.rb, method named mount_at. Perhaps that > will give you better explanation. Thanks, yes it's better > PS: I tried to use the source browser on Trac to see the changes and > got an error, database table is locked. > > http://devlab.oree.ch/trac/nitrohq/browser > Sometimes Trac gets out of sync with the repo. It is repaired for now. I've also read that unrecording patches could cause such problems. Cheers, zimbatm From zimba.tm at gmail.com Wed Apr 19 04:00:35 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 19 Apr 2006 10:00:35 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> References: <44455ED7.5040504@cataclysm-software.net> <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> Message-ID: Le 19 avr. 06 ? 08:40, TRANS a ?crit : > > Nitro's template system could then become an separated project, like > Og, if someone wished to maintain it (George or otherwise). > It would be the View of MVC :-p From george.moschovitis at gmail.com Wed Apr 19 04:02:01 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 11:02:01 +0300 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: Message-ID: > I think we should start easing the learning curve. So I suggest we > concentrate on writing docs and asking and answering questions on > Oxyliquit. This would benefit everyone obviously. I am preparing for a Nitro presentation. I will present Nitro to postgrad students in the National Technical University of Athens. I will prepare some screencasts and slides. I will also work a lot on the new nitro site. > I also think we can do a few things to make writing apps easier. I'd > like to suggest my gen scaffold and gen model ideas as enhancements to > be worked on. Basically, the scaffolding would write everything out to > files for easy editing. The model would write out an Og model for an > existing database table. The basic idea is to make it really easy to > get an application up and running. I like that ;-) -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 19 04:03:26 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 11:03:26 +0300 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> References: <44455ED7.5040504@cataclysm-software.net> <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> Message-ID: > I'd like to see the template system become completey pluggable. I > think it would be better for Nitro, so it can focus on core > functionality. Maybe that's not possible for some reason, but it'sa > thought. Ok ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 19 04:49:43 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 11:49:43 +0300 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> Message-ID: Sounds great! Can't wait to have a look at this (and use it too ;-)) thanks! -g. On 4/18/06, Fabian Buch wrote: > > new FeedHelper > > . reimplementation of RssHelper to support all RSS versions > . very few code left of Georges original RssHelper > . supports RSS versions 0.91, 1.0 and 2.0 > . supports Atom 1.0 > . supports rough OPML 1.0 > . should be backward compatible to the RssHelper for RSS 0.91 feeds > . just change "helper :rss" to "helper :feed" for access to all the > new features > . not much tested yet, so be careful, but test a lot and report bugs > . big RDoc, so everyone knows how to use it > . more tests, but it still could use a lot more.. (but tests are no > validator, right?) > > RSS 0.91, 1.0, 2.0 and Atom 1.0 validate against > http://feedvalidator.org with a quick testapp I've written. It's not in > a real-world app yet (oxyliquit has some issues with current glycerin), > so there might still be bugs. > OPML ist not tested in any app yet. If someone has time to test it or > knows a better usage, please tell me, I might improve it then. > > Fabian > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From fabian at oggu.de Wed Apr 19 06:54:44 2006 From: fabian at oggu.de (Fabian Buch) Date: Wed, 19 Apr 2006 12:54:44 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> Message-ID: Am 18.04.2006 um 22:01 schrieb Bryan Soto: > I've been waiting for this since you mentioned it on #nitro. :) There it is, finally :). >> a real-world app yet (oxyliquit has some issues with current >> glycerin), > > Bug reports just make Nitro and Og all the better, so what are the > issues? Please!!! :) I don't know. Kashia said something like this and I don't know what it is (maybe it's not even a bug). Kashia is too busy with C++ at the moment. If I find the time between all the database and java stuff of mine I'll try it again and if I find bugs I'll report them of course. Fabian From zimba.tm at gmail.com Wed Apr 19 07:07:32 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 19 Apr 2006 13:07:32 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44455ED7.5040504@cataclysm-software.net> <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> Message-ID: <385AABCC-D37D-41BA-857A-895738CA6A7D@gmail.com> Will you do thing George ? If yes, I don't need to implement the proposed selective compiler per controller or action. Le 19 avr. 06 ? 10:03, George Moschovitis a ?crit : >> I'd like to see the template system become completey pluggable. I >> think it would be better for Nitro, so it can focus on core >> functionality. Maybe that's not possible for some reason, but it'sa >> thought. > > > Ok ;-) > > > -g. > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Wed Apr 19 07:56:54 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 14:56:54 +0300 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> References: <44455ED7.5040504@cataclysm-software.net> <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> Message-ID: > I'd like to see the template system become completey pluggable. I Btw, the template system *is* completely pluggable. The template processor is just another Compile Pipeline Stage (ie a Compiler). The pipeline is fully customizable. -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 19 07:57:55 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 14:57:55 +0300 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <385AABCC-D37D-41BA-857A-895738CA6A7D@gmail.com> References: <44455ED7.5040504@cataclysm-software.net> <4b6f054f0604182340qf26996ajd3434cfef9a19e35@mail.gmail.com> <385AABCC-D37D-41BA-857A-895738CA6A7D@gmail.com> Message-ID: Yeap I will do the fine grained compiler pipeline selection (per action, controller, global) -g. On 4/19/06, Jonas Pfenniger wrote: > Will you do thing George ? If yes, I don't need to implement the > proposed selective compiler per controller or action. > > Le 19 avr. 06 ? 10:03, George Moschovitis a ?crit : > > >> I'd like to see the template system become completey pluggable. I > >> think it would be better for Nitro, so it can focus on core > >> functionality. Maybe that's not possible for some reason, but it'sa > >> thought. > > > > > > Ok ;-) > > > > > > -g. > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 19 08:06:13 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 15:06:13 +0300 Subject: [Nitro] Official Repo Message-ID: Dear devs, you can reach the official nitro repo at: repo.nitroproject.org Please continue sending patches to the list. I would like to ask Bryan + Jonas to integrate this patches to the devlab repo. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From vagabond at cataclysm-software.net Wed Apr 19 08:28:00 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Wed, 19 Apr 2006 08:28:00 -0400 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: References: <44454969.9090605@cataclysm-software.net> Message-ID: <44462CD0.6000503@cataclysm-software.net> Bryan Soto wrote: > Hair trigger with the send button :/ > > On 4/18/06, Bryan Soto wrote: >> Andrew, >> >> Could you eyeball this patch to make sure I got the important bits? Bryan, You've omitted the fixes to redirect in render.rb: def redirect(url, status = 303) url = url.to_s + url = "#{Router.strip_path}/#{url}".squeeze('/') if Router.strip_path I'm also not sure you need to require router.rb in render.rb, but I've only semi-tested that impression. Maybe for some use-cases its not a bad idea, require is smart enough to make it a likely non-issue. >> Funny coincidence, but I was trying to handle your other issue >> "Controller resolution order" in the same repo. :) Oh, cool, I thought that one dropped off into the void. Any progress on it? Andrew From transfire at gmail.com Wed Apr 19 09:05:12 2006 From: transfire at gmail.com (TRANS) Date: Wed, 19 Apr 2006 09:05:12 -0400 Subject: [Nitro] Official Repo In-Reply-To: References: Message-ID: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> On 4/19/06, George Moschovitis wrote: > Dear devs, > > you can reach the official nitro repo at: > > repo.nitroproject.org Does this point to the devlab repo or is it a separate one? T. From george.moschovitis at gmail.com Wed Apr 19 10:11:45 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 19 Apr 2006 17:11:45 +0300 Subject: [Nitro] Official Repo In-Reply-To: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> References: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> Message-ID: It points to a separate one. Let me explain what I mean by official. This is the repo that reflects the actual release. I would like to continue using devlab for glycerin (unstable) development, hopefully Bryan and Jonas can continue their *great* job. I will synchorinize the 'official' repo with the devlab repo once per week. regards, George. > Does this point to the devlab repo or is it a separate one? -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From james_b at neurogami.com Wed Apr 19 10:22:28 2006 From: james_b at neurogami.com (James Britt) Date: Wed, 19 Apr 2006 07:22:28 -0700 Subject: [Nitro] Official Repo In-Reply-To: References: Message-ID: <444647A4.10901@neurogami.com> George Moschovitis wrote: > Dear devs, > > you can reach the official nitro repo at: > > repo.nitroproject.org > When nitrohq.com escaped through the auto-renewal cracks, I went and grabbed nitrohq.org. Right now I've set it up to redirect to http://www.oxyliquit.de/, but it's available for a more specific use if needed. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://web2.0validator.com - We're the Dot in Web 2.0 From dylanb at digitalvalence.com Wed Apr 19 10:48:42 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Wed, 19 Apr 2006 09:48:42 -0500 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: Message-ID: <44464DCA.70405@digitalvalence.com> One of the directions I'd like to see the project go is making it easier for new people to get into the code base and contribute. The success of a project like this depends entirely on its community. There is a great group of people here already, and making the party bigger (along with improved docs to provide direction) can only help accelerate growth and adoption. Although the necessity of 'competing' with a project like rails is dubious since NitrOg seems to follow a different set of principles, the success of that project cannot be ignored as a model. And it is dominant in large part because of its massive contributor community, both in the form of direct committers and plugin developers. Toward this end I have a couple of questions: Why does Nitro use a non-standard source control system ? I was able to get it up and running fine, and it seems very nice, but everyone already has CVS (and many have Subversion). They don't need to download or learn anything new to use it. Using a non-standard system hinders adoption and contribution. As for documention, I've been distracted with other things - is the wiki fixed yet ? Or is Nitro moving to oxyliquit as the primary documentation repository ? With NitroHQ gone and oxyliquit off the beaten path and therefore difficult to find, many people would probably be excused for thinking this project was dead, rather than heating up. Perhaps someone can take charge of the minor administravia in order to take the weight off of George's overburdened shoulders ? Diagrams that cover the overall architecture would be very nice to have. And a good philosophy statement, preferably delineating what the Nitro/Og projects are and are not very clearly. I hear George is going to Athens or something to give a presentation. That kind of profile expanding behaviour would be very helpful once the website details are sorted out. If you get people interested and they come in and have no site to go to, you are going to lose most of those new people. How much native code does Nitro use ? The JRuby geniuses almost have rails running on the VM; it would be nice to have 'something doing' in that regard. Not terribly important, but nice. As to the speed of patch application, is there a way to speed this up ? Is this a time constraint issue; a patch review time issue, or what ? How do other projects handle these details ? Also, is there a policy of having to have a test for new features so that they can be easily demonstrated and verified by the patch 'applicator' ? What with the flurry of submitted patches lately, there has to be some standard way of checking for conflicts and notifying the competing contributors so that a solution can be worked out. Dylan > Over the past two months, I think we've made good progress in taming > glycerin. :) > > We've fixed lots of bugs, added test cases, were gifted with Oxyliquit > and our little community is growing. Good work all! > > I hope people are finding Nitro and Og more stable than ever before. > And if you aren't, please let us know so we can fix it. :) > > Overall, I'm pleased with our progress. I do have to note that patches > aren't being applied very quickly, so that's definitely a sticking > point in our process that is solely on me. If anyone has anything else > to add, good or bad, please do. Especially suggestions that can > improve things for us. > > Now, for future direction, let's start charting our course for 0.31.0. > Community participation is especially encouraged here. :) > > A few of my ideas are below. Please note, I'm merely making > suggestions, not defining a course. I think the community as a whole > should decide that. > > I think we should start easing the learning curve. So I suggest we > concentrate on writing docs and asking and answering questions on > Oxyliquit. This would benefit everyone obviously. > > I also think we can do a few things to make writing apps easier. I'd > like to suggest my gen scaffold and gen model ideas as enhancements to > be worked on. Basically, the scaffolding would write everything out to > files for easy editing. The model would write out an Og model for an > existing database table. The basic idea is to make it really easy to > get an application up and running. > > Anyway, those are my thoughts. I look forward to hearing from others. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From dylanb at digitalvalence.com Wed Apr 19 10:55:13 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Wed, 19 Apr 2006 09:55:13 -0500 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44464DCA.70405@digitalvalence.com> References: <44464DCA.70405@digitalvalence.com> Message-ID: <44464F51.4070601@digitalvalence.com> Ahh, Nitrohq.org. Is the .com site completely lost then ? And who can get into Rubyforge to update the home page link ? That is probably the source of many of the curious after new releases. > One of the directions I'd like to see the project go is making it easier > for new people to get into the code base and contribute. The success of > a project like this depends entirely on its community. There is a great > group of people here already, and making the party bigger (along with > improved docs to provide direction) can only help accelerate growth and > adoption. Although the necessity of 'competing' with a project like > rails is dubious since NitrOg seems to follow a different set of > principles, the success of that project cannot be ignored as a model. > And it is dominant in large part because of its massive contributor > community, both in the form of direct committers and plugin developers. > > Toward this end I have a couple of questions: > > Why does Nitro use a non-standard source control system ? I was able to > get it up and running fine, and it seems very nice, but everyone already > has CVS (and many have Subversion). They don't need to download or > learn anything new to use it. Using a non-standard system hinders > adoption and contribution. > > As for documention, I've been distracted with other things - is the wiki > fixed yet ? Or is Nitro moving to oxyliquit as the primary > documentation repository ? With NitroHQ gone and oxyliquit off the > beaten path and therefore difficult to find, many people would probably > be excused for thinking this project was dead, rather than heating up. > Perhaps someone can take charge of the minor administravia in order to > take the weight off of George's overburdened shoulders ? > > Diagrams that cover the overall architecture would be very nice to > have. And a good philosophy statement, preferably delineating what the > Nitro/Og projects are and are not very clearly. > > I hear George is going to Athens or something to give a presentation. > That kind of profile expanding behaviour would be very helpful once the > website details are sorted out. If you get people interested and they > come in and have no site to go to, you are going to lose most of those > new people. > > How much native code does Nitro use ? The JRuby geniuses almost have > rails running on the VM; it would be nice to have 'something doing' in > that regard. Not terribly important, but nice. > > As to the speed of patch application, is there a way to speed this up ? > Is this a time constraint issue; a patch review time issue, or what ? > How do other projects handle these details ? Also, is there a policy of > having to have a test for new features so that they can be easily > demonstrated and verified by the patch 'applicator' ? What with the > flurry of submitted patches lately, there has to be some standard way of > checking for conflicts and notifying the competing contributors so that > a solution can be worked out. > > Dylan > >> Over the past two months, I think we've made good progress in taming >> glycerin. :) >> >> We've fixed lots of bugs, added test cases, were gifted with Oxyliquit >> and our little community is growing. Good work all! >> >> I hope people are finding Nitro and Og more stable than ever before. >> And if you aren't, please let us know so we can fix it. :) >> >> Overall, I'm pleased with our progress. I do have to note that patches >> aren't being applied very quickly, so that's definitely a sticking >> point in our process that is solely on me. If anyone has anything else >> to add, good or bad, please do. Especially suggestions that can >> improve things for us. >> >> Now, for future direction, let's start charting our course for 0.31.0. >> Community participation is especially encouraged here. :) >> >> A few of my ideas are below. Please note, I'm merely making >> suggestions, not defining a course. I think the community as a whole >> should decide that. >> >> I think we should start easing the learning curve. So I suggest we >> concentrate on writing docs and asking and answering questions on >> Oxyliquit. This would benefit everyone obviously. >> >> I also think we can do a few things to make writing apps easier. I'd >> like to suggest my gen scaffold and gen model ideas as enhancements to >> be worked on. Basically, the scaffolding would write everything out to >> files for easy editing. The model would write out an Og model for an >> existing database table. The basic idea is to make it really easy to >> get an application up and running. >> >> Anyway, those are my thoughts. I look forward to hearing from others. >> >> -- >> "Never tell people how to do things. Tell them what to do and they >> will surprise you with their ingenuity." ?General George S. Patton >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From aglarond at gmail.com Wed Apr 19 10:58:29 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Wed, 19 Apr 2006 16:58:29 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: <43BF2C65.8000900@neurogami.com> References: <43BF2C65.8000900@neurogami.com> Message-ID: <55c107bf0604190758s6e1c261cl9071ac97702a1e30@mail.gmail.com> Hi James, On 1/7/06, James Britt wrote: > I have group of pages with the same header, footer, and so on, but the > main body varies, and I'd like to just have a single "shell" template > and plug in the guts that differ for each page. This was one of my motivations for writing the Nitro Transformer. I've attached the file, for those that don't have 'darcs' or just don't want to apply the patch. Documentation is included. Usage is pretty basic: you define a template file, identify the XHTML elements you would like to replace/expand, identify the source file/text, and do the transformation. All in the controller. My current issues are outlined in the patch submission under "[PATCH] Nitro Transformer". Any feedback would be welcome. - Dimitri -------------- next part -------------- A non-text attachment was scrubbed... Name: transformer.rb Type: application/octet-stream Size: 5116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060419/593bb6e8/attachment.obj From zimba.tm at gmail.com Wed Apr 19 12:17:44 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 19 Apr 2006 18:17:44 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> Message-ID: <6AB9DABA-FE5B-476A-B4DD-9A8C577701B8@gmail.com> George, i would like to see the nitro project page on rubyforge cleaned up a little : * point the homepage to the new url * remove some unused tabs : forums / bugs / tasks / documents / polls * if possible point the scm to your new repo or remove it * if possible point the wiki to your new wiki or remove it LMKWYT Le 19 avr. 06 ? 16:11, George Moschovitis a ?crit : > It points to a separate one. > > Let me explain what I mean by official. This is the repo that reflects > the actual release. I would like to continue using devlab for glycerin > (unstable) development, hopefully Bryan and Jonas can continue their > *great* job. I will synchorinize the 'official' repo with the devlab > repo once per week. > > regards, > George. > >> Does this point to the devlab repo or is it a separate one? > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From kashia at vfemail.net Wed Apr 19 15:36:22 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 19 Apr 2006 21:36:22 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44464DCA.70405@digitalvalence.com> References: <44464DCA.70405@digitalvalence.com> Message-ID: Hi, > Toward this end I have a couple of questions: might as well try to answer, take it with a grain of salt, I'm higly biased ;) > Why does Nitro use a non-standard source control system ? I was able to > get it up and running fine, and it seems very nice, but everyone already > has CVS (and many have Subversion). They don't need to download or > learn anything new to use it. Using a non-standard system hinders > adoption and contribution. =being # half burnt, don't read ;) I see it this way: If there is a tool which fits the project perfectly, why chose a solution which is less suited? There are always discussions about the best VCS, none of them ever lead to anything, I am aware of that. No really, darcs has got quite some followers now, and will eventually attract more users, when people finally realize that CVS is not the only way to go. =end You mentioned that Nitro has a different mindset than Nitro, which I fully agree to. But I also think that this mindset extends to the surroundings of Nitro as well, meaning the development style and the current community in general. > As for documention, I've been distracted with other things - is the wiki > fixed yet ? Or is Nitro moving to oxyliquit as the primary > documentation repository ? With NitroHQ gone and oxyliquit off the > beaten path and therefore difficult to find, many people would probably Hmm... now that nitroproject.org is "almost" up, nitrohq.org catched from James and Oxywtf, things are starting to get real better :) For Oxyliquit being off track, how do you mean that, and do you see a solution to make it more "common"? > be excused for thinking this project was dead, rather than heating up. > Perhaps someone can take charge of the minor administravia in order to > take the weight off of George's overburdened shoulders ? We have Brian, I loooove him ;D Yes yes, I'm sorry ;) No really, people really get more emancipated over time :P > Diagrams that cover the overall architecture would be very nice to I agree to that, wasn't there an attempt earlier... I gotta dig that up and put up to oxy. Thanks! > have. And a good philosophy statement, preferably delineating what the > Nitro/Og projects are and are not very clearly. Hmmm... I'm not really sure what you mean here, could you rephrase for a non native? > I hear George is going to Athens or something to give a presentation. > That kind of profile expanding behaviour would be very helpful once the > website details are sorted out. If you get people interested and they > come in and have no site to go to, you are going to lose most of those > new people. I sure hope he first finishes his own page, until then I hope he will mention nitrohq.org/oxyliquit.de and let them make a note of nitroproject > How much native code does Nitro use ? The JRuby geniuses almost have > rails running on the VM; it would be nice to have 'something doing' in > that regard. Not terribly important, but nice. Native? none :) But afaik it uses Threads 'n stuff, where they supported by Java? I think, now that Yarv is almost finished, maybe I could test running Nitro with that :) > As to the speed of patch application, is there a way to speed this up ? > Is this a time constraint issue; a patch review time issue, or what ? > How do other projects handle these details ? Also, is there a policy of > having to have a test for new features so that they can be easily > demonstrated and verified by the patch 'applicator' ? What with the > flurry of submitted patches lately, there has to be some standard way of > checking for conflicts and notifying the competing contributors so that > a solution can be worked out. As Linus Torvalds said once: "As a project maintainer my job is to reject new funny patches, not to accept every single one" (Not an exact quote) At the moment the standard way to contribute, is the following: * Send to mailing list / trac * Brian will merge it if you ask nicely ;D * Brian posts question, if others have problems with patch * A few people answer * patch gets used by a few people :P * patch ends up in repo Note that this is not meant to be a definite guide, more a joke ;) If you have any ideas on how to unify processes (sounds like UML, yuck) just go ahaid and outline what you think :) And overall, your input is very welcome, keep it coming ;D Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From kashia at vfemail.net Wed Apr 19 16:10:32 2006 From: kashia at vfemail.net (Kashia Buch) Date: Wed, 19 Apr 2006 22:10:32 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: Hi, >> Why does Nitro use a non-standard source control system ? I was able to >> get it up and running fine, and it seems very nice, but everyone already >> has CVS (and many have Subversion). They don't need to download or >> learn anything new to use it. Using a non-standard system hinders >> adoption and contribution. http://www.darcs.net/DarcsWiki/Tailor Maybe that can be used as a bridge, to let people use SVN as well? That would require a person willing to shuffle patches/resolve conflicts from the both versioning systems... Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Wed Apr 19 18:10:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 15:10:58 -0700 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44464DCA.70405@digitalvalence.com> References: <44464DCA.70405@digitalvalence.com> Message-ID: On 4/19/06, Dylan Bruzenak wrote: > One of the directions I'd like to see the project go is making it easier > for new people to get into the code base and contribute. The success of > a project like this depends entirely on its community. There is a great > group of people here already, and making the party bigger (along with > improved docs to provide direction) can only help accelerate growth and > adoption. Although the necessity of 'competing' with a project like > rails is dubious since NitrOg seems to follow a different set of > principles, the success of that project cannot be ignored as a model. > And it is dominant in large part because of its massive contributor > community, both in the form of direct committers and plugin developers. > All of this is very true. An open-source project lives or dies by it's community and anything we can do to help foster it is a good thing. > Toward this end I have a couple of questions: > > Why does Nitro use a non-standard source control system ? I was able to > get it up and running fine, and it seems very nice, but everyone already > has CVS (and many have Subversion). They don't need to download or > learn anything new to use it. Using a non-standard system hinders > adoption and contribution. > Well, the why would be for George since he choose it. All I can say is, as a previous CVS person, I rather like it now. Sure, it seemed like a pain at first, but I didn't really need a major push to download something new... Besides, with Pugs being hosted in it, I think it'll become more popular. > As for documention, I've been distracted with other things - is the wiki > fixed yet ? Or is Nitro moving to oxyliquit as the primary > documentation repository ? With NitroHQ gone and oxyliquit off the > beaten path and therefore difficult to find, many people would probably > be excused for thinking this project was dead, rather than heating up. > Perhaps someone can take charge of the minor administravia in order to > take the weight off of George's overburdened shoulders ? > There will be a new website, nitroproject.org. I don't know what George has planned for it. George also mentioned on #nitro that he would figure something out in regards to admining the server. We can only hope. :) I don't know if George is planning for oxyliquit to be the official source for docs. At the very least, it is a very good unofficial one. :) > Diagrams that cover the overall architecture would be very nice to > have. And a good philosophy statement, preferably delineating what the > Nitro/Og projects are and are not very clearly. > Diagrams would be good. Does anyone have any suggestions for diagramming software? Windows or Linux. Preferably free or open-source. And for philosophy, George do you have one for Nitro/Og? > I hear George is going to Athens or something to give a presentation. > That kind of profile expanding behaviour would be very helpful once the > website details are sorted out. If you get people interested and they > come in and have no site to go to, you are going to lose most of those > new people. > Yes. I'm glad George decided to delay the release until he got a new one set up. > How much native code does Nitro use ? The JRuby geniuses almost have > rails running on the VM; it would be nice to have 'something doing' in > that regard. Not terribly important, but nice. > The only portions that are native code would be extensions like fastcgi, the database driver, etc. > As to the speed of patch application, is there a way to speed this up ? > Is this a time constraint issue; a patch review time issue, or what ? > How do other projects handle these details ? Also, is there a policy of > having to have a test for new features so that they can be easily > demonstrated and verified by the patch 'applicator' ? What with the > flurry of submitted patches lately, there has to be some standard way of > checking for conflicts and notifying the competing contributors so that > a solution can be worked out. > As of yet, we haven't had competing contributors. :) I think the bottleneck is that I'm currently the only one reviewing and applying them. Trying to balance that with fixing bugs when I only get a few hours a day to do anything Nitro related just isn't working. Reviewing patches is actually a pretty good way of becoming familiar with the code base (it's how I started), so if there's anyone interested in helping out, please let me know. :) For submitters, tests are expected, whether bugs or enhancements. For an enhancement, docs are expected as well. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 19 18:23:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 15:23:26 -0700 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: On 4/19/06, Kashia Buch wrote: > Hmm... now that nitroproject.org is "almost" up, nitrohq.org catched from > James and Oxywtf, things are starting to get real better :) > > For Oxyliquit being off track, how do you mean that, and do you see a > solution to make it more "common"? > He probably means that if you were thinking of what website to go for Nitro questions and answers, oxyliquit isn't the first thing to come to mind. :) > > be excused for thinking this project was dead, rather than heating up. > > Perhaps someone can take charge of the minor administravia in order to > > take the weight off of George's overburdened shoulders ? > > We have Brian, I loooove him ;D Group hug everyone. :) > Yes yes, I'm sorry ;) > No really, people really get more emancipated over time :P > > > Diagrams that cover the overall architecture would be very nice to > > I agree to that, wasn't there an attempt earlier... I gotta dig that > up and put up to oxy. Thanks! > > > have. And a good philosophy statement, preferably delineating what the > > Nitro/Og projects are and are not very clearly. > > Hmmm... I'm not really sure what you mean here, could you rephrase for a > non native? > How about one sentence that describes what Nitro/Og are trying to accomplish. Does that make more sense? > > I hear George is going to Athens or something to give a presentation. > > That kind of profile expanding behaviour would be very helpful once the > > website details are sorted out. If you get people interested and they > > come in and have no site to go to, you are going to lose most of those > > new people. > > I sure hope he first finishes his own page, until then I hope he will > mention nitrohq.org/oxyliquit.de and let them make a note of nitroproject > > > How much native code does Nitro use ? The JRuby geniuses almost have > > rails running on the VM; it would be nice to have 'something doing' in > > that regard. Not terribly important, but nice. > > Native? none :) > But afaik it uses Threads 'n stuff, where they supported by Java? > I think, now that Yarv is almost finished, maybe I could test running > Nitro with that :) > I've been meaning to try that as well. I'm fairly certain it would work since they got rails running on yarv. > > As to the speed of patch application, is there a way to speed this up ? > > Is this a time constraint issue; a patch review time issue, or what ? > > How do other projects handle these details ? Also, is there a policy of > > having to have a test for new features so that they can be easily > > demonstrated and verified by the patch 'applicator' ? What with the > > flurry of submitted patches lately, there has to be some standard way of > > checking for conflicts and notifying the competing contributors so that > > a solution can be worked out. > > As Linus Torvalds said once: "As a project maintainer my job is to reject > new funny patches, not to accept every single one" > (Not an exact quote) > I think I got a new sig. :) > At the moment the standard way to contribute, is the following: > > * Send to mailing list / trac > * Brian will merge it if you ask nicely ;D > * Brian posts question, if others have problems with patch > * A few people answer > * patch gets used by a few people :P > * patch ends up in repo > > Note that this is not meant to be a definite guide, more a joke ;) > It's actually a pretty good guide though. Maybe we should just use Trac? Patches sent to the list get missed alot. > If you have any ideas on how to unify processes (sounds like UML, yuck) > just go ahaid and outline what you think :) > Is there anyone out there who'd like to help review patches? My general philosophy is that quote from Linus, but would be happy to go into more detail if requested. > And overall, your input is very welcome, keep it coming ;D > +1 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 19 18:27:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 15:27:47 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <44462CD0.6000503@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> Message-ID: On 4/19/06, Andrew Thompson wrote: > Bryan Soto wrote: > > Hair trigger with the send button :/ > > > > On 4/18/06, Bryan Soto wrote: > >> Andrew, > >> > >> Could you eyeball this patch to make sure I got the important bits? > > Bryan, > > You've omitted the fixes to redirect in render.rb: > > def redirect(url, status = 303) > url = url.to_s > + url = "#{Router.strip_path}/#{url}".squeeze('/') if Router.strip_path > You had mentioned you ran into problems with the redirect which is why I omitted. Did I misunderstand? > I'm also not sure you need to require router.rb in render.rb, but I've > only semi-tested that impression. Maybe for some use-cases its not a bad > idea, require is smart enough to make it a likely non-issue. > I think that was necessary for the redirect patch above. Included by mistake. Thanks for the catch. :) > >> Funny coincidence, but I was trying to handle your other issue > >> "Controller resolution order" in the same repo. :) > > Oh, cool, I thought that one dropped off into the void. Any progress on it? > Yeah, actually. But I hate the implementation. :) If I get something nice, are you willing to help test? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Wed Apr 19 18:33:08 2006 From: transfire at gmail.com (TRANS) Date: Wed, 19 Apr 2006 18:33:08 -0400 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: <4b6f054f0604191533h66ee4ebdw7df25c7ed06d29cc@mail.gmail.com> On 4/19/06, Bryan Soto wrote: > > Native? none :) > > But afaik it uses Threads 'n stuff, where they supported by Java? > > I think, now that Yarv is almost finished, maybe I could test running > > Nitro with that :) > > > > I've been meaning to try that as well. I'm fairly certain it would > work since they got rails running on yarv. Oh boy. I'm curious to see how this flys. Nitro is so much more dynamic codewise than Rails, I suspect it won't go as smoothly. But there no way to know except to try! If you do, let me know how it fairs. Thanks, T. From manveru at weez.co.jp Thu Apr 20 00:40:07 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 13:40:07 +0900 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <4b6f054f0604191533h66ee4ebdw7df25c7ed06d29cc@mail.gmail.com> References: <4b6f054f0604191533h66ee4ebdw7df25c7ed06d29cc@mail.gmail.com> Message-ID: <200604201340.07095.manveru@weez.co.jp> On Thursday 20 April 2006 07:33, TRANS wrote: > On 4/19/06, Bryan Soto wrote: > > > Native? none :) > > > But afaik it uses Threads 'n stuff, where they supported by Java? > > > I think, now that Yarv is almost finished, maybe I could test running > > > Nitro with that :) > > > > I've been meaning to try that as well. I'm fairly certain it would > > work since they got rails running on yarv. > > Oh boy. I'm curious to see how this flys. Nitro is so much more > dynamic codewise than Rails, I suspect it won't go as smoothly. But > there no way to know except to try! > > If you do, let me know how it fairs. Well, i tried... but ran into simultanous problems with rubygems (facets)/stdlib and minor issues with syntax-changes... I think it can be done when we just put a bit more effort into it, but YARV is still not the optimal solution. However, if we really want it to run on YARV it shouldn't be a problem was just not worth the effort for me, i did that only to explore a bit how it compares performance-wise and found out that it's a speedup of about 120% for most programs. > > Thanks, > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Thu Apr 20 01:32:14 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 22:32:14 -0700 Subject: [Nitro] [PATCH] here is the patch In-Reply-To: References: Message-ID: I've applied it. On 4/18/06, George Moschovitis wrote: > I forgot to attach the patch, here you are: > > > Mon Apr 17 11:18:15 EEST 2006 George Moschovitis > * Added context.no_sync! option, low level hack needed when > modifying the users session in interesting ways ;-) > Shall I send this patch? (1/5) [ynWvpxqadjk], or ? for help: y > > Mon Apr 17 11:37:21 EEST 2006 George Moschovitis > * More flexible Script generator, the developer can use most of its > features without a Client subclass. > Shall I send this patch? (2/5) [ynWvpxqadjk], or ? for help: y > > Tue Apr 18 17:16:33 EEST 2006 George Moschovitis > * Removed from glue files that where added in Facets, adapted Nitro > accordingly. > Shall I send this patch? (3/5) [ynWvpxqadjk], or ? for help: y > > > -g. > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 01:38:13 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 22:38:13 -0700 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <9c00d3e00604181648v150a109eo575c40e4784df940@mail.gmail.com> Message-ID: Hey manveru, this seems to delete all the templates when applied. Shouldn't it move them to the new templates directory? On 4/18/06, Bryan Soto wrote: > Just wanted to find out. We'll see if it still applies. Thanks. :) > > On 4/18/06, Michael Fellinger wrote: > > Yeah, it never got applied afaik... > > On 4/19/06, Bryan Soto wrote:> Manveru, was this the patch you mentioned on #nitro?>> On 3/3/06, Michael Fellinger wrote:> > Hello List,> >> > I just made a bundle that makes the template-root for flare more> > standard, moving it from /template to /templates and adding a> > Template.root = "templates" in the run.rb> > I could have left this one out since it's the standard, but i'd rather> > go sure...> >> > ~~~~manveru> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From manveru at weez.co.jp Thu Apr 20 01:51:50 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 14:51:50 +0900 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> Message-ID: <200604201451.50541.manveru@weez.co.jp> That was the plan. Doesn't it do that? On Thursday 20 April 2006 14:38, Bryan Soto wrote: > Hey manveru, this seems to delete all the templates when applied. > Shouldn't it move them to the new templates directory? > > On 4/18/06, Bryan Soto wrote: > > Just wanted to find out. We'll see if it still applies. Thanks. :) > > > > On 4/18/06, Michael Fellinger wrote: > > > Yeah, it never got applied afaik... > > > On 4/19/06, Bryan Soto wrote:> Manveru, was > > > this the patch you mentioned on #nitro?>> On 3/3/06, Michael Fellinger > > > wrote:> > Hello List,> >> > I just made a > > > bundle that makes the template-root for flare more> > standard, moving > > > it from /template to /templates and adding a> > Template.root = > > > "templates" in the run.rb> > I could have left this one out since it's > > > the standard, but i'd rather> > go sure...> >> > ~~~~manveru> >> > > > > _______________________________________________> > Nitro-general > > > mailing list> > Nitro-general at rubyforge.org> > > > > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> > > > "Never tell people how to do things. Tell them what to do and they> > > > will surprise you with their ingenuity." ?General George S. Patton>> > > > _______________________________________________> Nitro-general mailing > > > list> Nitro-general at rubyforge.org> > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Thu Apr 20 02:08:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:08:00 -0700 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: <200604171826.51234.manveru@weez.co.jp> References: <200604171826.51234.manveru@weez.co.jp> Message-ID: On 4/17/06, Michael Fellinger wrote: > Could somebody please have a look at that one? > The tests passed for me with both mysql and postgres. I used the darcs repo though. Perhaps the test missed something? Or maybe the bug was already fixed? Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 02:10:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:10:56 -0700 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: References: <200604171826.51234.manveru@weez.co.jp> Message-ID: I did apply your additions to the repo though. Thanks. :) On 4/19/06, Bryan Soto wrote: > On 4/17/06, Michael Fellinger wrote: > > Could somebody please have a look at that one? > > > > The tests passed for me with both mysql and postgres. I used the darcs > repo though. Perhaps the test missed something? Or maybe the bug was > already fixed? > > Bryan > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 02:16:56 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:16:56 -0700 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> Message-ID: Hey George, any opinions on this one? Does it fit with your current plans for Nitro? On 4/18/06, George Moschovitis wrote: > So much to review, so little time ;-) Thanks anyway! > > -g. > > On 4/18/06, Dimitri Aivaliotis wrote: > > Minor fix to generate directories in the output path, if they don't > > already exist. > > > > - Dimitri > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 02:31:35 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:31:35 -0700 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: <200604201451.50541.manveru@weez.co.jp> References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <200604201451.50541.manveru@weez.co.jp> Message-ID: Nah, templates is empty after the patch is applied. Do you want me to fix that? On 4/19/06, Michael Fellinger wrote: > That was the plan. > Doesn't it do that? > > On Thursday 20 April 2006 14:38, Bryan Soto wrote: > > Hey manveru, this seems to delete all the templates when applied. > > Shouldn't it move them to the new templates directory? > > > > On 4/18/06, Bryan Soto wrote: > > > Just wanted to find out. We'll see if it still applies. Thanks. :) > > > > > > On 4/18/06, Michael Fellinger wrote: > > > > Yeah, it never got applied afaik... > > > > On 4/19/06, Bryan Soto wrote:> Manveru, was > > > > this the patch you mentioned on #nitro?>> On 3/3/06, Michael Fellinger > > > > wrote:> > Hello List,> >> > I just made a > > > > bundle that makes the template-root for flare more> > standard, moving > > > > it from /template to /templates and adding a> > Template.root = > > > > "templates" in the run.rb> > I could have left this one out since it's > > > > the standard, but i'd rather> > go sure...> >> > ~~~~manveru> >> > > > > > _______________________________________________> > Nitro-general > > > > mailing list> > Nitro-general at rubyforge.org> > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> > > > > "Never tell people how to do things. Tell them what to do and they> > > > > will surprise you with their ingenuity." ?General George S. Patton>> > > > > _______________________________________________> Nitro-general mailing > > > > list> Nitro-general at rubyforge.org> > > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > > > "Never tell people how to do things. Tell them what to do and they > > > will surprise you with their ingenuity." ?General George S. Patton > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 02:32:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:32:24 -0700 Subject: [Nitro] [PATCH] Logger.debug woe In-Reply-To: References: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Message-ID: Yeah, just a few hours. :/ I've applied this. Thanks. On 4/17/06, Bryan Soto wrote: > Hey manveru, > > I got a conflict with this. I'll take care of it and will probably > apply in a few hours. Just so you know. :) > > On 4/12/06, Michael Fellinger wrote: > > Hey all, > > > > I finally sat down, after hearing lots of complains from various > > sides, and added the 'if $DBG' statement at all the Logger.debug > > outputs where it was missing, except for the logger-testcase where it > > might make sense, didn't have a closer look tho.. > > to trace the missing statements down i used: > > ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ /_darcs/}' > > > > maybe that's something to add to a testcase and trace down missing > > statements if they occur again... > > > > Hope it doesn't break anything, and i'm not sure if all the > > Logger.debug for the kind-of-session-noticing need that too, but here > > it is :) > > > > ~~~~manveru > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 02:50:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 19 Apr 2006 23:50:48 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> Message-ID: On 4/19/06, Fabian Buch wrote: > > Am 18.04.2006 um 22:01 schrieb Bryan Soto: > > I've been waiting for this since you mentioned it on #nitro. :) > > There it is, finally :). > Worth waiting for. Very nice. :) I'm sure this is a Windows thing: 1) Error: test_atom(TC_FeedHelper): ArgumentError: time must be positive ./lib/nitro/helper/feed.rb:231:in `-' ./lib/nitro/helper/feed.rb:231:in `build_atom' ./test/nitro/helper/tc_feed.rb:84:in `test_atom' Snippet from irb: irb(main):001:0> Time.new-60*60*24*365*104 Time.new-60*60*24*365*104 ArgumentError: time must be positive from (irb):1:in `-' from (irb):1 irb(main):004:0> 60*60*24*365*104 60*60*24*365*104 3279744000 irb(main):005:0> Time.new.to_i Time.new.to_i 1145515169 Was there a reason we need to subtract 104 years? Maybe 5 would be enough? It seems to work on WIndows: irb(main):007:0> Time.new-(60*60*24*365*5) Time.new-(60*60*24*365*5) Fri Apr 20 23:49:53 Pacific Standard Time 2001 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From manveru at weez.co.jp Thu Apr 20 03:19:35 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 16:19:35 +0900 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: References: <200604171826.51234.manveru@weez.co.jp> Message-ID: <200604201619.35203.manveru@weez.co.jp> Sorry, the testcase was not really helping... i wanted to reproduce a bug but that only shows up with schema_inheritance and EZ. so if you have something like: class Person property :name, String property :kids, Integer schema_inheritance end class Musician < Person property :instruments, Array end class Plumber < Person property :tools, Array end Musician.find{|m| m.kids === [3,4,5]} I know, this example is a bit far-fetched, but i have to do stuff like that :) Hope this helps... On Thursday 20 April 2006 15:10, Bryan Soto wrote: > I did apply your additions to the repo though. Thanks. :) > > On 4/19/06, Bryan Soto wrote: > > On 4/17/06, Michael Fellinger wrote: > > > Could somebody please have a look at that one? > > > > The tests passed for me with both mysql and postgres. I used the darcs > > repo though. Perhaps the test missed something? Or maybe the bug was > > already fixed? > > > > Bryan > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From manveru at weez.co.jp Thu Apr 20 03:20:54 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 16:20:54 +0900 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <200604201451.50541.manveru@weez.co.jp> Message-ID: <200604201620.54161.manveru@weez.co.jp> I certainly checked that the files are added... however, since i'm not that familiar with darcs it might have gone wrong despite of my effort :( Could you please fix it for me, just moving the directory from 'template' to 'templates' On Thursday 20 April 2006 15:31, Bryan Soto wrote: > Nah, templates is empty after the patch is applied. Do you want me to fix > that? > > On 4/19/06, Michael Fellinger wrote: > > That was the plan. > > Doesn't it do that? > > > > On Thursday 20 April 2006 14:38, Bryan Soto wrote: > > > Hey manveru, this seems to delete all the templates when applied. > > > Shouldn't it move them to the new templates directory? > > > > > > On 4/18/06, Bryan Soto wrote: > > > > Just wanted to find out. We'll see if it still applies. Thanks. :) > > > > > > > > On 4/18/06, Michael Fellinger wrote: > > > > > Yeah, it never got applied afaik... > > > > > On 4/19/06, Bryan Soto wrote:> Manveru, > > > > > was this the patch you mentioned on #nitro?>> On 3/3/06, Michael > > > > > Fellinger wrote:> > Hello List,> >> > I > > > > > just made a bundle that makes the template-root for flare more> > > > > > > standard, moving it from /template to /templates and adding a> > > > > > > Template.root = "templates" in the run.rb> > I could have left this > > > > > one out since it's the standard, but i'd rather> > go sure...> >> > > > > > > ~~~~manveru> >> > _______________________________________________> > > > > > > Nitro-general mailing list> > Nitro-general at rubyforge.org> > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> > > > > > "Never tell people how to do things. Tell them what to do and they> > > > > > will surprise you with their ingenuity." ?General George S. > > > > > Patton>> _______________________________________________> > > > > > Nitro-general mailing list> Nitro-general at rubyforge.org> > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > > > > _______________________________________________ > > > > > Nitro-general mailing list > > > > > Nitro-general at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > > > > "Never tell people how to do things. Tell them what to do and they > > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > -- > > > "Never tell people how to do things. Tell them what to do and they > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From manveru at weez.co.jp Thu Apr 20 03:22:25 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 16:22:25 +0900 Subject: [Nitro] [PATCH] Logger.debug woe In-Reply-To: References: <9c00d3e00604120624s50a905fw96b55cf2719b52ba@mail.gmail.com> Message-ID: <200604201622.25462.manveru@weez.co.jp> Hehe, thanks a lot :) On Thursday 20 April 2006 15:32, Bryan Soto wrote: > Yeah, just a few hours. :/ > > I've applied this. Thanks. > > On 4/17/06, Bryan Soto wrote: > > Hey manveru, > > > > I got a conflict with this. I'll take care of it and will probably > > apply in a few hours. Just so you know. :) > > > > On 4/12/06, Michael Fellinger wrote: > > > Hey all, > > > > > > I finally sat down, after hearing lots of complains from various > > > sides, and added the 'if $DBG' statement at all the Logger.debug > > > outputs where it was missing, except for the logger-testcase where it > > > might make sense, didn't have a closer look tho.. > > > to trace the missing statements down i used: > > > ruby -e 'puts `egrep -r Logger.debug *`.reject{|x| x =~ /DBG/ || x =~ > > > /_darcs/}' > > > > > > maybe that's something to add to a testcase and trace down missing > > > statements if they occur again... > > > > > > Hope it doesn't break anything, and i'm not sure if all the > > > Logger.debug for the kind-of-session-noticing need that too, but here > > > it is :) > > > > > > ~~~~manveru > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From dylanb at digitalvalence.com Thu Apr 20 03:55:22 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Thu, 20 Apr 2006 02:55:22 -0500 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: <44473E6A.1080100@digitalvalence.com> Too bad I'm all questions and no answers ;) Hopefully as more people join more of this can be decentralized. Maybe there is some way to make it easier to review patches ? Some sort of quick apply and testing or a public forum for reading the code... Awfully late here, so I'm just pinging things off the wall. > As of yet, we haven't had competing contributors. :) > > I think the bottleneck is that I'm currently the only one reviewing > and applying them. Trying to balance that with fixing bugs when I only > get a few hours a day to do anything Nitro related just isn't working. > Reviewing patches is actually a pretty good way of becoming familiar > with the code base (it's how I started), so if there's anyone > interested in helping out, please let me know. :) > > For submitters, tests are expected, whether bugs or enhancements. For > an enhancement, docs are expected as well. > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From dylanb at digitalvalence.com Thu Apr 20 04:01:09 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Thu, 20 Apr 2006 03:01:09 -0500 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: <44473FC5.9030008@digitalvalence.com> As for the off the beaten path comment, what I mean is more literal: it is just hard to find the site. It isn't linked off ruby forge; if I wasn't a member of the mailing list I wouldn't know about it. Even googling nitro doesn't bring up a hit for it early in the list. Once the new site it up I imagine this will be a lot easier. I think the oxyliquit site is great, very much needed. The base concept is much clearer than the usual wiki dialogs that usually appear around OSS projects. From dylanb at digitalvalence.com Thu Apr 20 04:04:34 2006 From: dylanb at digitalvalence.com (Dylan Bruzenak) Date: Thu, 20 Apr 2006 03:04:34 -0500 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <200604201340.07095.manveru@weez.co.jp> References: <4b6f054f0604191533h66ee4ebdw7df25c7ed06d29cc@mail.gmail.com> <200604201340.07095.manveru@weez.co.jp> Message-ID: <44474092.3030403@digitalvalence.com> 120% ? More than twice as fast ? At version .4 ? Even if that is actually 20%, that is still promising. I'll have to keep tabs on that thing. JRuby is currently slow, but they haven't gone through a performance dev cycle yet. > On Thursday 20 April 2006 07:33, TRANS wrote: > >> On 4/19/06, Bryan Soto wrote: >> >>>> Native? none :) >>>> But afaik it uses Threads 'n stuff, where they supported by Java? >>>> I think, now that Yarv is almost finished, maybe I could test running >>>> Nitro with that :) >>>> >>> I've been meaning to try that as well. I'm fairly certain it would >>> work since they got rails running on yarv. >>> >> Oh boy. I'm curious to see how this flys. Nitro is so much more >> dynamic codewise than Rails, I suspect it won't go as smoothly. But >> there no way to know except to try! >> >> If you do, let me know how it fairs. >> > > Well, i tried... but ran into simultanous problems with rubygems > (facets)/stdlib and minor issues with syntax-changes... > I think it can be done when we just put a bit more effort into it, but YARV is > still not the optimal solution. > However, if we really want it to run on YARV it shouldn't be a problem was > just not worth the effort for me, i did that only to explore a bit how it > compares performance-wise and found out that it's a speedup of about 120% for > most programs. > > >> Thanks, >> T. >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > From manveru at weez.co.jp Thu Apr 20 04:58:13 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 17:58:13 +0900 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44474092.3030403@digitalvalence.com> References: <200604201340.07095.manveru@weez.co.jp> <44474092.3030403@digitalvalence.com> Message-ID: <200604201758.13195.manveru@weez.co.jp> In fact it's always around 100-120% given a runtime of usual ruby of 10 seconds it will take 5 seconds in yarv in most cases, and yes, this is ruby 2.0.0 (Base: Ruby 1.9.0 2006-02-14) [i686-linux] YARVCore 0.4.0 Rev: 486 (2006-04-11) [opts: ] http://rafb.net/paste/results/OAhxBH21.html (this might be gone in a few days) On Thursday 20 April 2006 17:04, Dylan Bruzenak wrote: > 120% ? More than twice as fast ? At version .4 ? Even if that is > actually 20%, that is still promising. I'll have to keep tabs on that > thing. JRuby is currently slow, but they haven't gone through a > performance dev cycle yet. > > > On Thursday 20 April 2006 07:33, TRANS wrote: > >> On 4/19/06, Bryan Soto wrote: > >>>> Native? none :) > >>>> But afaik it uses Threads 'n stuff, where they supported by Java? > >>>> I think, now that Yarv is almost finished, maybe I could test running > >>>> Nitro with that :) > >>> > >>> I've been meaning to try that as well. I'm fairly certain it would > >>> work since they got rails running on yarv. > >> > >> Oh boy. I'm curious to see how this flys. Nitro is so much more > >> dynamic codewise than Rails, I suspect it won't go as smoothly. But > >> there no way to know except to try! > >> > >> If you do, let me know how it fairs. > > > > Well, i tried... but ran into simultanous problems with rubygems > > (facets)/stdlib and minor issues with syntax-changes... > > I think it can be done when we just put a bit more effort into it, but > > YARV is still not the optimal solution. > > However, if we really want it to run on YARV it shouldn't be a problem > > was just not worth the effort for me, i did that only to explore a bit > > how it compares performance-wise and found out that it's a speedup of > > about 120% for most programs. > > > >> Thanks, > >> T. > >> > >> _______________________________________________ > >> Nitro-general mailing list > >> Nitro-general at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/nitro-general > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From manveru at weez.co.jp Thu Apr 20 05:25:05 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 18:25:05 +0900 Subject: [Nitro] [PATCH] small fix for EZ (===) Message-ID: <200604201825.06107.manveru@weez.co.jp> this one should fix the problems with schema_inheritance and the use of === in EZ-clauses, it patches sql.rb though, so please be careful, i haven't had a problem so far but i'm not using the full extend of Og so it's hard to tell. -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tar.gz Type: application/x-tgz Size: 15063 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060420/8efa8c90/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle Type: text/x-java Size: 46842 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060420/8efa8c90/attachment-0001.bin From news at stephan.walter.name Thu Apr 20 05:37:01 2006 From: news at stephan.walter.name (Stephan Walter) Date: Thu, 20 Apr 2006 11:37:01 +0200 Subject: [Nitro] strange syntax in og/entity.rb Message-ID: Hi, while digging around in the Og code, I found this in og/entity.rb, line 598, private method "finder": %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{ogmanager.store.quote(value)}| I couldn't find anything in the ruby docs, but I would guess that the %|...| will evaluate the string it contains. Is that correct? If yes, I see a problem that the string itself contains pipes. -Stephan From manveru at weez.co.jp Thu Apr 20 06:00:53 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 19:00:53 +0900 Subject: [Nitro] strange syntax in og/entity.rb In-Reply-To: References: Message-ID: <200604201900.53612.manveru@weez.co.jp> IMHO you are absolutly right, it should better be: %{#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{ogmanager.store.quote(value)}} and %|| is a string, according to irb at least On Thursday 20 April 2006 18:37, Stephan Walter wrote: > Hi, > > while digging around in the Og code, I found this in og/entity.rb, line > 598, private method "finder": > > %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} > #{ogmanager.store.quote(value)}| > > I couldn't find anything in the ruby docs, but I would guess that the > %|...| will evaluate the string it contains. Is that correct? If yes, I > see a problem that the string itself contains pipes. > > -Stephan > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nissl at tiscali.it Thu Apr 20 06:11:47 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Thu, 20 Apr 2006 12:11:47 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: Message-ID: <1145527907.4137.7.camel@nissl.mammuth> hi george, I've dowloaded this repo for testing with our application, but there is some probs, (all is fine with 0.29 and some brian repo, but not last) this is the tracelog: Error Path: /get_content wrong number of arguments (3 for 1) Request Parameters: {"params"=>"menu_item_008", "_"=>nil} Cookies: {"nsid"=>"aea95bed4f3786d3ec06a993659bf11f"} Headers: SERVER_NAME => localhost HTTP_X_PROTOTYPE_VERSION => 1.5.0_rc0 ACCEPT-CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 ACCEPT-LANGUAGE => en-us,en;q=0.5 PATH_INFO => /get_content REMOTE_HOST => 127.0.0.1 HTTP_ACCEPT_ENCODING => gzip,deflate HTTP_USER_AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 ACCEPT => text/javascript, text/html, application/xml, text/xml, */* CONNECTION => keep-alive SCRIPT_NAME => SERVER_PROTOCOL => HTTP/1.1 HTTP_ACCEPT_LANGUAGE => en-us,en;q=0.5 HTTP_HOST => localhost:9999 ACCEPT-ENCODING => gzip,deflate X-PROTOTYPE-VERSION => 1.5.0_rc0 REMOTE_ADDR => 127.0.0.1 SERVER_SOFTWARE => WEBrick/1.3.1 (Ruby/1.8.4/2005-12-24) HTTP_KEEP_ALIVE => 300 USER-AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 X-REQUESTED-WITH => XMLHttpRequest COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f HTTP_COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 REQUEST_URI => /get_content?params=menu_item_008&_= SERVER_PORT => 9999 GATEWAY_INTERFACE => CGI/1.1 QUERY_STRING => params=menu_item_008&_= REMOTE_USER => HOST => localhost:9999 HTTP_ACCEPT => text/javascript, text/html, application/xml, text/xml, */* KEEP-ALIVE => 300 REQUEST_METHOD => GET HTTP_CONNECTION => keep-alive HTTP_X_REQUESTED_WITH => XMLHttpRequest Massimo Maria Ghisalberti From manveru at weez.co.jp Thu Apr 20 06:12:47 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Thu, 20 Apr 2006 19:12:47 +0900 Subject: [Nitro] [PATCH] support for localization in table-helper Message-ID: <200604201912.47981.manveru@weez.co.jp> One thing that bugged me for quite a while is that the table-helper is not included in the pipelines, so i had to make a workaround for localization so that [[something]] will be replaced by the content of @lc[something] it works well so far... please let me know if you have problems using that patch... also there should be some more elegant solution possible, but i just couldn't find a better way :| -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle Type: text/x-java Size: 46940 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060420/1d954792/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.tar.gz Type: application/x-tgz Size: 15029 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060420/1d954792/attachment-0001.bin From george.moschovitis at gmail.com Thu Apr 20 06:23:30 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 20 Apr 2006 13:23:30 +0300 Subject: [Nitro] Official Repo In-Reply-To: <6AB9DABA-FE5B-476A-B4DD-9A8C577701B8@gmail.com> References: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> <6AB9DABA-FE5B-476A-B4DD-9A8C577701B8@gmail.com> Message-ID: Jonas, I am working to resolve the Nitro homepage issue, I hope I will have something ready some day in the next week. Regarding the rubyforge page, I m not sure what you propose is possible. But I will give it a try. regards, George. On 4/19/06, Jonas Pfenniger wrote: > George, > > i would like to see the nitro project page on rubyforge cleaned up a > little : > * point the homepage to the new url > * remove some unused tabs : forums / bugs / tasks / documents / polls > * if possible point the scm to your new repo or remove it > * if possible point the wiki to your new wiki or remove it > > LMKWYT > > Le 19 avr. 06 ? 16:11, George Moschovitis a ?crit : > > > It points to a separate one. > > > > Let me explain what I mean by official. This is the repo that reflects > > the actual release. I would like to continue using devlab for glycerin > > (unstable) development, hopefully Bryan and Jonas can continue their > > *great* job. I will synchorinize the 'official' repo with the devlab > > repo once per week. > > > > regards, > > George. > > > >> Does this point to the devlab repo or is it a separate one? > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From zimba.tm at gmail.com Thu Apr 20 06:30:09 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Thu, 20 Apr 2006 12:30:09 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: <4b6f054f0604190605i1ee1c52fn2a9cb6f4b2715cf9@mail.gmail.com> <6AB9DABA-FE5B-476A-B4DD-9A8C577701B8@gmail.com> Message-ID: <5C61D3B3-97B3-4759-BB3C-AB6EE4F1F0DB@gmail.com> Thanks for your work, I've seen other projects that have less tabs. http://rubyforge.org/ projects/rubystylejs/ For example. Le 20 avr. 06 ? 12:23, George Moschovitis a ?crit : > Jonas, > > I am working to resolve the Nitro homepage issue, I hope I will have > something ready some day in the next week. Regarding the rubyforge > page, I m not sure what you propose is possible. But I will give it a > try. > > regards, > George. > > On 4/19/06, Jonas Pfenniger wrote: >> George, >> >> i would like to see the nitro project page on rubyforge cleaned up a >> little : >> * point the homepage to the new url >> * remove some unused tabs : forums / bugs / tasks / documents / >> polls >> * if possible point the scm to your new repo or remove it >> * if possible point the wiki to your new wiki or remove it >> >> LMKWYT >> >> Le 19 avr. 06 ? 16:11, George Moschovitis a ?crit : >> >>> It points to a separate one. >>> >>> Let me explain what I mean by official. This is the repo that >>> reflects >>> the actual release. I would like to continue using devlab for >>> glycerin >>> (unstable) development, hopefully Bryan and Jonas can continue their >>> *great* job. I will synchorinize the 'official' repo with the devlab >>> repo once per week. >>> >>> regards, >>> George. >>> >>>> Does this point to the devlab repo or is it a separate one? >>> >>> >>> -- >>> http://www.gmosx.com >>> http://www.navel.gr >>> http://www.nitrohq.com >>> >>> _______________________________________________ >>> Nitro-general mailing list >>> Nitro-general at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> > > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From george.moschovitis at gmail.com Thu Apr 20 06:32:32 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 20 Apr 2006 13:32:32 +0300 Subject: [Nitro] Nitro templating question In-Reply-To: <55c107bf0604190758s6e1c261cl9071ac97702a1e30@mail.gmail.com> References: <43BF2C65.8000900@neurogami.com> <55c107bf0604190758s6e1c261cl9071ac97702a1e30@mail.gmail.com> Message-ID: I will have a look at it, please be a bit more patient... thanks, George. On 4/19/06, Dimitri Aivaliotis wrote: > Hi James, > > On 1/7/06, James Britt wrote: > > > I have group of pages with the same header, footer, and so on, but the > > main body varies, and I'd like to just have a single "shell" template > > and plug in the guts that differ for each page. > > This was one of my motivations for writing the Nitro Transformer. > I've attached the file, for those that don't have 'darcs' or just > don't want to apply the patch. Documentation is included. Usage is > pretty basic: you define a template file, identify the XHTML elements > you would like to replace/expand, identify the source file/text, and > do the transformation. All in the controller. My current issues are > outlined in the patch submission under "[PATCH] Nitro Transformer". > > Any feedback would be welcome. > > - Dimitri > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Thu Apr 20 06:33:59 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 20 Apr 2006 13:33:59 +0300 Subject: [Nitro] strange syntax in og/entity.rb In-Reply-To: <200604201900.53612.manveru@weez.co.jp> References: <200604201900.53612.manveru@weez.co.jp> Message-ID: You can use any character for strings... ie %{}, %||, %[], %~~, etc etc... -g. On 4/20/06, Michael Fellinger wrote: > IMHO you are absolutly right, it should better be: > > %{#{field_name} #{options.delete("#{name}_op".to_sym) || '='} > #{ogmanager.store.quote(value)}} > > and %|| is a string, according to irb at least > > On Thursday 20 April 2006 18:37, Stephan Walter wrote: > > Hi, > > > > while digging around in the Og code, I found this in og/entity.rb, line > > 598, private method "finder": > > > > %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} > > #{ogmanager.store.quote(value)}| > > > > I couldn't find anything in the ruby docs, but I would guess that the > > %|...| will evaluate the string it contains. Is that correct? If yes, I > > see a problem that the string itself contains pipes. > > > > -Stephan > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From aglarond at gmail.com Thu Apr 20 06:39:15 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Thu, 20 Apr 2006 12:39:15 +0200 Subject: [Nitro] Nitro templating question In-Reply-To: References: <43BF2C65.8000900@neurogami.com> <55c107bf0604190758s6e1c261cl9071ac97702a1e30@mail.gmail.com> Message-ID: <55c107bf0604200339o5c7673a0u99249f48285e564a@mail.gmail.com> Hi George, On 4/20/06, George Moschovitis wrote: > I will have a look at it, please be a bit more patient... No pressure. I know you have a lot on your plate. ;) I just wanted to open up the possibility for others to use the transformer, and comment on how it fits their needs. - Dimitri From kashia at vfemail.net Thu Apr 20 06:48:45 2006 From: kashia at vfemail.net (Kashia Buch) Date: Thu, 20 Apr 2006 12:48:45 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44473FC5.9030008@digitalvalence.com> References: <44464DCA.70405@digitalvalence.com> <44473FC5.9030008@digitalvalence.com> Message-ID: Hi, > As for the off the beaten path comment, what I mean is more literal: it > is just hard to find the site. It isn't linked off ruby forge; if I > wasn't a member of the mailing list I wouldn't know about it. Even > googling nitro doesn't bring up a hit for it early in the list. Once It does :) It just depends on what you search ;D * Nitro FAQ * Nitro Q&A both first place (kinda) :P For being not searchable by using "Nitro"... even Nitro doesn't get a first place there... which is even less good.. > the new site it up I imagine this will be a lot easier. I think the > oxyliquit site is great, very much needed. The base concept is much > clearer than the usual wiki dialogs that usually appear around OSS projects. Yup, very nice concept, that's why I stole it ;D (not really, I tried to not look at the original page at all, I was hooked at the first glance at it) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From m.fellinger at gmail.com Thu Apr 20 09:38:22 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 20 Apr 2006 22:38:22 +0900 Subject: [Nitro] strange syntax in og/entity.rb In-Reply-To: References: <200604201900.53612.manveru@weez.co.jp> Message-ID: <9c00d3e00604200638h45cb5f68nb2af0479320f6add@mail.gmail.com> yeah, but the problem is non-closurei.e.%{} finds { and } in between and just ignores them until the final }%|| just breaks with | in between...same goes for %~~ when a ~ is in there... so we should better staywith %{} %() or %[] On 4/20/06, George Moschovitis wrote:> You can use any character for strings... ie>> %{}, %||, %[], %~~, etc etc...>> -g.>> On 4/20/06, Michael Fellinger wrote:> > IMHO you are absolutly right, it should better be:> >> > %{#{field_name} #{options.delete("#{name}_op".to_sym) || '='}> > #{ogmanager.store.quote(value)}}> >> > and %|| is a string, according to irb at least> >> > On Thursday 20 April 2006 18:37, Stephan Walter wrote:> > > Hi,> > >> > > while digging around in the Og code, I found this in og/entity.rb, line> > > 598, private method "finder":> > >> > > %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='}> > > #{ogmanager.store.quote(value)}|> > >> > > I couldn't find anything in the ruby docs, but I would guess that the> > > %|...| will evaluate the string it contains. Is that correct? If yes, I> > > see a problem that the string itself contains pipes.> > >> > > -Stephan> > >> > > _______________________________________________> > > Nitro-general mailing list> > > Nitro-general at rubyforge.org> > > http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From aglarond at gmail.com Thu Apr 20 09:52:41 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Thu, 20 Apr 2006 15:52:41 +0200 Subject: [Nitro] strange syntax in og/entity.rb In-Reply-To: References: Message-ID: <55c107bf0604200652p32a9ad1aj8c2a95ef9915663f@mail.gmail.com> On 4/20/06, Stephan Walter wrote: > %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{ogmanager.store.quote(value)}| Isn't this a non-issue? I just tried it out in irb, with some dummy variables: field_name = "test field name" options = [ :test_op, :field_op ] name = "field" %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{name}| => "test field name = field" options => [:test_op] The ruby parser is intelligent enough to recognize a || within a %||, or that's at least what it looks like... - Dimitri From m.fellinger at gmail.com Thu Apr 20 10:17:23 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 20 Apr 2006 23:17:23 +0900 Subject: [Nitro] strange syntax in og/entity.rb In-Reply-To: <55c107bf0604200652p32a9ad1aj8c2a95ef9915663f@mail.gmail.com> References: <55c107bf0604200652p32a9ad1aj8c2a95ef9915663f@mail.gmail.com> Message-ID: <9c00d3e00604200717l6021a5fbn6b496d2956b27e5b@mail.gmail.com> %|this is | a test|:)and yes, with two it works... so we just close that topic... On 4/20/06, Dimitri Aivaliotis wrote:> On 4/20/06, Stephan Walter wrote:>> > %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{ogmanager.store.quote(value)}|>> Isn't this a non-issue? I just tried it out in irb, with some dummy variables:>> field_name = "test field name"> options = [ :test_op, :field_op ]> name = "field">> %|#{field_name} #{options.delete("#{name}_op".to_sym) || '='} #{name}|> => "test field name = field">> options> => [:test_op]>> The ruby parser is intelligent enough to recognize a || within a %||,> or that's at least what it looks like...>> - Dimitri>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From nissl at tiscali.it Thu Apr 20 10:18:15 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Thu, 20 Apr 2006 16:18:15 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: Message-ID: <1145542695.10257.2.camel@nissl.mammuth> hi george, I've dowloaded this repo for testing with our application, but there is some probs, (all is fine with 0.29 and some brian repo, but not last) this is the tracelog: Error Path: /get_content wrong number of arguments (3 for 1) Request Parameters: {"params"=>"menu_item_008", "_"=>nil} Cookies: {"nsid"=>"aea95bed4f3786d3ec06a993659bf11f"} Headers: SERVER_NAME => localhost HTTP_X_PROTOTYPE_VERSION => 1.5.0_rc0 ACCEPT-CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 ACCEPT-LANGUAGE => en-us,en;q=0.5 PATH_INFO => /get_content REMOTE_HOST => 127.0.0.1 HTTP_ACCEPT_ENCODING => gzip,deflate HTTP_USER_AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 ACCEPT => text/javascript, text/html, application/xml, text/xml, */* CONNECTION => keep-alive SCRIPT_NAME => SERVER_PROTOCOL => HTTP/1.1 HTTP_ACCEPT_LANGUAGE => en-us,en;q=0.5 HTTP_HOST => localhost:9999 ACCEPT-ENCODING => gzip,deflate X-PROTOTYPE-VERSION => 1.5.0_rc0 REMOTE_ADDR => 127.0.0.1 SERVER_SOFTWARE => WEBrick/1.3.1 (Ruby/1.8.4/2005-12-24) HTTP_KEEP_ALIVE => 300 USER-AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 X-REQUESTED-WITH => XMLHttpRequest COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f HTTP_COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 REQUEST_URI => /get_content?params=menu_item_008&_= SERVER_PORT => 9999 GATEWAY_INTERFACE => CGI/1.1 QUERY_STRING => params=menu_item_008&_= REMOTE_USER => HOST => localhost:9999 HTTP_ACCEPT => text/javascript, text/html, application/xml, text/xml, */* KEEP-ALIVE => 300 REQUEST_METHOD => GET HTTP_CONNECTION => keep-alive HTTP_X_REQUESTED_WITH => XMLHttpRequest Massimo Maria Ghisalberti From vagabond at cataclysm-software.net Thu Apr 20 10:35:33 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Thu, 20 Apr 2006 10:35:33 -0400 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> Message-ID: <44479C35.4090703@cataclysm-software.net> Bryan Soto wrote: > > You had mentioned you ran into problems with the redirect which is why > I omitted. Did I misunderstand? Well, redirect change is needed for redirects to work at all (AFAIK). I think I included it with the patch I sent to the ML so I was wondering where it vanished to... >> >> Funny coincidence, but I was trying to handle your other issue >> >> "Controller resolution order" in the same repo. :) >> >> Oh, cool, I thought that one dropped off into the void. Any progress on it? >> > > Yeah, actually. But I hate the implementation. :) > If I get something nice, are you willing to help test? Sure, though I don't have the codebase I was running into issues with this on anymore, I'd have to cook up a new test-app to see how things work. Andrew From bryan.a.soto at gmail.com Thu Apr 20 13:33:21 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 10:33:21 -0700 Subject: [Nitro] Official Repo In-Reply-To: <1145527907.4137.7.camel@nissl.mammuth> References: <1145527907.4137.7.camel@nissl.mammuth> Message-ID: Hi, I noticed this is an AJAX request. Are you, by chance, using Nitro's script generator? If so, George made same changes to it in the patch here: http://rubyforge.org/pipermail/nitro-general/2006-April/004038.html If not, could you list the backtrace generated on the console running webrick? I'm happy to help debug this, but need a little more information. :) Bryan On 4/20/06, Massimo Maria Ghisalberti wrote: > hi george, > > I've dowloaded this repo for testing with our application, but there is > some probs, (all is fine with 0.29 and some brian repo, but not last) > > this is the tracelog: > Error > Path: /get_content > wrong number of arguments (3 for 1) > > Request > Parameters: {"params"=>"menu_item_008", "_"=>nil} > > Cookies: {"nsid"=>"aea95bed4f3786d3ec06a993659bf11f"} > > Headers: > SERVER_NAME => localhost > HTTP_X_PROTOTYPE_VERSION => 1.5.0_rc0 > ACCEPT-CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 > ACCEPT-LANGUAGE => en-us,en;q=0.5 > PATH_INFO => /get_content > REMOTE_HOST => 127.0.0.1 > HTTP_ACCEPT_ENCODING => gzip,deflate > HTTP_USER_AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) > Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 > ACCEPT => text/javascript, text/html, application/xml, text/xml, */* > CONNECTION => keep-alive > SCRIPT_NAME => > SERVER_PROTOCOL => HTTP/1.1 > HTTP_ACCEPT_LANGUAGE => en-us,en;q=0.5 > HTTP_HOST => localhost:9999 > ACCEPT-ENCODING => gzip,deflate > X-PROTOTYPE-VERSION => 1.5.0_rc0 > REMOTE_ADDR => 127.0.0.1 > SERVER_SOFTWARE => WEBrick/1.3.1 (Ruby/1.8.4/2005-12-24) > HTTP_KEEP_ALIVE => 300 > USER-AGENT => Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) > Gecko/20060203 Fedora/1.5.0.1-1.1.fc4.nr Firefox/1.5.0.1 > X-REQUESTED-WITH => XMLHttpRequest > COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f > HTTP_COOKIE => nsid=aea95bed4f3786d3ec06a993659bf11f > HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7 > REQUEST_URI => /get_content?params=menu_item_008&_= > SERVER_PORT => 9999 > GATEWAY_INTERFACE => CGI/1.1 > QUERY_STRING => params=menu_item_008&_= > REMOTE_USER => > HOST => localhost:9999 > HTTP_ACCEPT => text/javascript, text/html, application/xml, text/xml, > */* > KEEP-ALIVE => 300 > REQUEST_METHOD => GET > HTTP_CONNECTION => keep-alive > HTTP_X_REQUESTED_WITH => XMLHttpRequest > > > > > > Massimo Maria Ghisalberti > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 13:44:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 10:44:58 -0700 Subject: [Nitro] Retrospective and future direction. In-Reply-To: <44473E6A.1080100@digitalvalence.com> References: <44464DCA.70405@digitalvalence.com> <44473E6A.1080100@digitalvalence.com> Message-ID: On 4/20/06, Dylan Bruzenak wrote: > Too bad I'm all questions and no answers ;) Hopefully as more people > join more of this can be decentralized. Maybe there is some way to make > it easier to review patches ? Some sort of quick apply and testing or a > public forum for reading the code... Awfully late here, so I'm just > pinging things off the wall. If I understand correctly, devlab is now to be the place for quick applying and testing of patches. Periodically, George will select from it those to be included into the official repo. At least that's my impression. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From nissl at tiscali.it Thu Apr 20 15:56:57 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Thu, 20 Apr 2006 21:56:57 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: <1145527907.4137.7.camel@nissl.mammuth> Message-ID: <1145563017.13698.11.camel@nissl.mammuth> ok Bryan, yes is an AJAX request autogenerated from this: #{_t :item_001} the method of Client class: def getSection if Settings[:APPLICATION][:access_log] params = "get_client_info(params, true)" else params = "get_client_info(params, false)" end ajax_update "content_area", { :url => "/get_content", :method => "get", :params => params, :before => proc { show :spinner }, :success => proc { hide :spinner show :content_area js "propagate_content_info()" # tools.js } } end the controller handler method: def get_content(item) .... end this is the console backtrace: D, [2006-04-20T21:35:12.520048 #17075] DEBUG -- : Rendering '/get_content'. D, [2006-04-20T21:35:12.521310 #17075] DEBUG -- : Compiling action 'MainPageController#get_content' E, [2006-04-20T21:35:12.527002 #17075] ERROR -- : Error while handling '/get_content'. E, [2006-04-20T21:35:12.527453 #17075] ERROR -- : wrong number of arguments (3 for 1) (eval):20:in `get_content' (eval):20:in `get_content_action' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/controller.rb:93:in `method_missing' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/render.rb:129:in `render' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/adapter/webrick.rb:223:in `do_GET' /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib/ruby/1.8/webrick/server.rb:82:in `start' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/adapter/webrick.rb:59:in `start' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/server/runner.rb:343:in `invoke_server' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/server/runner.rb:305:in `invoke' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/server.rb:128:in `run' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro.rb:78:in `run' /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/run.rb:138 LOGGED FROM: /home/nissl/develop/eclipse-workspace/projects/www.ilcanticodellanatura.it/application/cantico-0.5.2.0/libs/nitro/nitro/lib/nitro/render.rb:249:in `log_error' D, [2006-04-20T21:35:12.527814 #17075] DEBUG -- : Rendering '/error'. D, [2006-04-20T21:35:12.535228 #17075] DEBUG -- : Rendering '/error'. ciao... Il giorno gio, 20/04/2006 alle 10.33 -0700, Bryan Soto ha scritto: > Hi, > > I noticed this is an AJAX request. Are you, by chance, using Nitro's > script generator? If so, George made same changes to it in the patch > here: > > http://rubyforge.org/pipermail/nitro-general/2006-April/004038.html > > If not, could you list the backtrace generated on the console running > webrick? I'm happy to help debug this, but need a little more > information. :) > > Bryan > -- Massimo Maria Ghisalberti From bryan.a.soto at gmail.com Thu Apr 20 16:33:49 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 13:33:49 -0700 Subject: [Nitro] Official Repo In-Reply-To: <1145563017.13698.11.camel@nissl.mammuth> References: <1145527907.4137.7.camel@nissl.mammuth> <1145563017.13698.11.camel@nissl.mammuth> Message-ID: On 4/20/06, Massimo Maria Ghisalberti wrote: > E, [2006-04-20T21:35:12.527002 #17075] ERROR -- : Error while handling > '/get_content'. > E, [2006-04-20T21:35:12.527453 #17075] ERROR -- : wrong number of > arguments (3 for 1) > (eval):20:in `get_content' > (eval):20:in `get_content_action' Hmm... what's the url that it's generating in the html page? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From fabian at oggu.de Thu Apr 20 17:15:46 2006 From: fabian at oggu.de (Fabian Buch) Date: Thu, 20 Apr 2006 23:15:46 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> Message-ID: <106c3dc1f6043a4c856857e7f58679ea@oggu.de> Am 20.04.2006 um 08:50 schrieb Bryan Soto: > Was there a reason we need to subtract 104 years? Maybe 5 would be > enough? It seems to work on WIndows: Yeah, you're absolutely right. I didn't think enough about this and just substracted the biggest that worked on my system. We shouldn't rely on this and probably noone wants to create feeds with a date older than 5 years ago. On the other hand, there could probably still exist feeds created today in five years (2011). Probably I should set a fixed date in the past for initialization. I hope to create another patch tomorrow. Fabian From bryan.a.soto at gmail.com Thu Apr 20 17:26:27 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 14:26:27 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <106c3dc1f6043a4c856857e7f58679ea@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> Message-ID: On 4/20/06, Fabian Buch wrote: > > Am 20.04.2006 um 08:50 schrieb Bryan Soto: > > Was there a reason we need to subtract 104 years? Maybe 5 would be > > enough? It seems to work on WIndows: > > Yeah, you're absolutely right. I didn't think enough about this and > just substracted the biggest that worked on my system. We shouldn't > rely on this and probably noone wants to create feeds with a date older > than 5 years ago. On the other hand, there could probably still exist > feeds created today in five years (2011). Probably I should set a fixed > date in the past for initialization. > I hope to create another patch tomorrow. > Time.at(0) maybe? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 18:23:20 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 15:23:20 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <44479C35.4090703@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> <44479C35.4090703@cataclysm-software.net> Message-ID: On 4/20/06, Andrew Thompson wrote: > Bryan Soto wrote: > > Yeah, actually. But I hate the implementation. :) > > If I get something nice, are you willing to help test? > > Sure, though I don't have the codebase I was running into issues with > this on anymore, I'd have to cook up a new test-app to see how things work. No worries. I cooked up a test case. Oh, and here's a revise including redirect_home and adds some logic for stripping Router.strip_path to dispatch. Maybe that was the problem you were running into that required base href? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro-router.strip_path-fix.zip Type: application/zip Size: 15161 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060420/daa7eb94/attachment.zip From bryan.a.soto at gmail.com Thu Apr 20 19:56:47 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 16:56:47 -0700 Subject: [Nitro] [patch] Small fix for Nitro without Og In-Reply-To: <4E0A6478-0F00-42B1-9851-BA6AC4C402E6@gmail.com> References: <4E0A6478-0F00-42B1-9851-BA6AC4C402E6@gmail.com> Message-ID: I've applied this, thanks. On 4/18/06, Jonas Pfenniger wrote: > Tue Apr 18 18:40:37 CEST 2006 Jonas Pfenniger > * [small fix] Nitro didn't start properly when Og was not used > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 20:07:24 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 17:07:24 -0700 Subject: [Nitro] [PATCH] small fix for EZ (===) In-Reply-To: <200604201825.06107.manveru@weez.co.jp> References: <200604201825.06107.manveru@weez.co.jp> Message-ID: On 4/20/06, Michael Fellinger wrote: > this one should fix the problems with schema_inheritance and the use of === in > EZ-clauses, it patches sql.rb though, so please be careful, i haven't had a > problem so far but i'm not using the full extend of Og so it's hard to tell. > Thanks for the patch. I'll see if I can create a test case for this based off your other email. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 20 20:10:39 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 20 Apr 2006 17:10:39 -0700 Subject: [Nitro] [PATCH] support for localization in table-helper In-Reply-To: <200604201912.47981.manveru@weez.co.jp> References: <200604201912.47981.manveru@weez.co.jp> Message-ID: On 4/20/06, Michael Fellinger wrote: > One thing that bugged me for quite a while is that the table-helper is not > included in the pipelines, so i had to make a workaround for localization so > that [[something]] will be replaced by the content of @lc[something] > it works well so far... please let me know if you have problems using that > patch... > also there should be some more elegant solution possible, but i just couldn't > find a better way :| > I'll see what I can do with it, though I don't have much experience with localization. By the way, did you see babel? http://rubyforge.org/pipermail/nitro-general/2006-April/003702.html -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From manveru at weez.co.jp Thu Apr 20 22:48:18 2006 From: manveru at weez.co.jp (Michael Fellinger) Date: Fri, 21 Apr 2006 11:48:18 +0900 Subject: [Nitro] [PATCH] support for localization in table-helper In-Reply-To: References: <200604201912.47981.manveru@weez.co.jp> Message-ID: <200604211148.18254.manveru@weez.co.jp> Oh sure i've seen it :) But Bable doesn't help you with localization that doesn't come from Og. This is where Glue::Localization comes in, you give it an hash per language and it uses Glue::Localization::get(session[:LOCALE])[("string"||:symbol)] to fetch the right snippet out of that hash so if you define for example for the localization :en = { :world => "world", :hello => "hello", :Hello => "Hello", :exclamation_mark => "!" } :de = { :world => "Welt", :hello => "hallo", :Hello => "Hallo", :exclamation_mark => "!" } and you put in your template [[Hello]] [[world]][[exclamation_mark]] then you get for session[:LOCALE] = :en "Hello world!" for :de "Hallo Welt!" However, this didn't work with the TableHelper, so i had to create a Patch for that. Hope that explains it. now you can do #{table :values => ["[[hello]]", "[[world]]"]} and it will be translated... On Friday 21 April 2006 09:10, Bryan Soto wrote: > On 4/20/06, Michael Fellinger wrote: > > One thing that bugged me for quite a while is that the table-helper is > > not included in the pipelines, so i had to make a workaround for > > localization so that [[something]] will be replaced by the content of > > @lc[something] it works well so far... please let me know if you have > > problems using that patch... > > also there should be some more elegant solution possible, but i just > > couldn't find a better way :| > > I'll see what I can do with it, though I don't have much experience > with localization. By the way, did you see babel? > http://rubyforge.org/pipermail/nitro-general/2006-April/003702.html > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From nissl at tiscali.it Fri Apr 21 04:46:40 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Fri, 21 Apr 2006 10:46:40 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: <1145527907.4137.7.camel@nissl.mammuth> <1145563017.13698.11.camel@nissl.mammuth> Message-ID: <1145609200.4061.15.camel@nissl.mammuth> the request URi is /get_content?params=menu_item_001&_= the last part of the query string is a prototype.js addendum, &_= the html code generated home __nc_getSection js code: function __nc_getSection(params) { $('spinner').style.display = 'block'; new Ajax.Updater( { success: 'content_area' }, '/get_content', { method: 'get', parameters: get_client_info(params, false), onLoading: function(request) { $('spinner').style.display = 'block'; }, onComplete: function(request) { $('spinner').style.display = 'none';$('content_area').style.display = 'block';propagate_content_info() } } ); } the get_client_info(params, false) return the query string for get method: params=menu_item_001 in this case. a simple workaround for controller method is get_content(location, param2 = nil, param3 = nil) :) but why 3 parameters if only one is send? (or max two with the prototype &_=) ciao Il giorno gio, 20/04/2006 alle 13.33 -0700, Bryan Soto ha scritto: > On 4/20/06, Massimo Maria Ghisalberti wrote: > > E, [2006-04-20T21:35:12.527002 #17075] ERROR -- : Error while handling > > '/get_content'. > > E, [2006-04-20T21:35:12.527453 #17075] ERROR -- : wrong number of > > arguments (3 for 1) > > (eval):20:in `get_content' > > (eval):20:in `get_content_action' > > Hmm... what's the url that it's generating in the html page? > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Massimo Maria Ghisalberti From fabian at oggu.de Fri Apr 21 05:08:45 2006 From: fabian at oggu.de (Fabian Buch) Date: Fri, 21 Apr 2006 11:08:45 +0200 Subject: [Nitro] Retrospective and future direction. In-Reply-To: References: <44464DCA.70405@digitalvalence.com> Message-ID: > It's actually a pretty good guide though. Maybe we should just use > Trac? Patches sent to the list get missed alot. I'm not so familiar with Trac. How would I send in a patch via Trac? Not via a ticket, right? Fabian From fabian at oggu.de Fri Apr 21 08:24:22 2006 From: fabian at oggu.de (Fabian Buch) Date: Fri, 21 Apr 2006 14:24:22 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> Message-ID: <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Am 20.04.2006 um 23:26 schrieb Bryan Soto: > Time.at(0) maybe? Perfect! Changed that and tests work here on my machine (MacOSX), hopefully Windows has something reasonable (maybe 1970 too?) as well. So now it should work on Windows too. I made a new patch bundle (the initial patch, plus the Time.at(0) fix) and submitted it as Trac ticket (http://devlab.oree.ch/trac/nitrohq/ticket/33). Is that better than attaching it to mails to the ML, Brian? Fabian From vagabond at cataclysm-software.net Fri Apr 21 08:26:49 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Fri, 21 Apr 2006 08:26:49 -0400 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> <44479C35.4090703@cataclysm-software.net> Message-ID: <4448CF89.3040406@cataclysm-software.net> Bryan Soto wrote: > No worries. I cooked up a test case. Oh, and here's a revise including > redirect_home and adds some logic for stripping Router.strip_path to > dispatch. Maybe that was the problem you were running into that > required base href? Umm, redirect_home calls redirect, so you'll be prepending strip_path twice there... I actually think we already discussed this. I'll try to test the dispatcher patch later today. Andrew From bryan.a.soto at gmail.com Fri Apr 21 13:19:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 10:19:08 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <4448CF89.3040406@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> <44479C35.4090703@cataclysm-software.net> <4448CF89.3040406@cataclysm-software.net> Message-ID: On 4/21/06, Andrew Thompson wrote: > Umm, redirect_home calls redirect, so you'll be prepending strip_path > twice there... I actually think we already discussed this. > That's just bad... My apologies. > I'll try to test the dispatcher patch later today. > If you like. I think I need to start from scratch with some testcases to catch these stupid mistakes I'm making. :/ -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 13:33:13 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 10:33:13 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Message-ID: On 4/21/06, Fabian Buch wrote: > > Am 20.04.2006 um 23:26 schrieb Bryan Soto: > > Time.at(0) maybe? > > Perfect! Changed that and tests work here on my machine (MacOSX), > hopefully Windows has something reasonable (maybe 1970 too?) as well. > So now it should work on Windows too. > It does. :) I never knew this one. WinXP: ruby -ve 'p Time.at(-1)' ruby 1.8.4 (2005-12-24) [i386-mswin32] -e:1:in 'at': time must be positive (ArgumentError) from -e:1 Linux2.6: ruby -ve 'p Time.at(-1)' ruby 1.8.4 (2005-12-24) [i686-linux] Wed Dec 31 15:59:59 PST 1969 Obviously time on Windows is unsigned. Must be why your first try didn't work. > I made a new patch bundle (the initial patch, plus the Time.at(0) fix) > and submitted it as Trac ticket > (http://devlab.oree.ch/trac/nitrohq/ticket/33). Is that better than > attaching it to mails to the ML, Brian? > Probably not. :/ Anyone have any suggestions on a better way of managing patches? I think we'd like to keep them submitted via the mailing list (it seems to be popular). Maybe I'll just create my own tickets on Trac as reminders of what I need to do. Honestly, I don't know. I just don't want to lose patches like we did manveru's re cently. :( > Fabian > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 13:41:54 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 10:41:54 -0700 Subject: [Nitro] Official Repo In-Reply-To: <1145609200.4061.15.camel@nissl.mammuth> References: <1145527907.4137.7.camel@nissl.mammuth> <1145563017.13698.11.camel@nissl.mammuth> <1145609200.4061.15.camel@nissl.mammuth> Message-ID: On 4/21/06, Massimo Maria Ghisalberti wrote: > a simple workaround for controller method is get_content(location, param2 = nil, param3 = nil) > Well, at least there's a workaround. :) > :) but why 3 parameters if only one is send? (or max two with the prototype &_=) > Very good question. It's either in the dispatcher or the params parsing so we're making progress. Thanks for the info, I'll see what I can figure out. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 13:45:14 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 10:45:14 -0700 Subject: [Nitro] [PATCH] support for localization in table-helper In-Reply-To: <200604211148.18254.manveru@weez.co.jp> References: <200604201912.47981.manveru@weez.co.jp> <200604211148.18254.manveru@weez.co.jp> Message-ID: On 4/20/06, Michael Fellinger wrote: > Hope that explains it. > Very much so, thanks. :) And thanks for the example, I think that can be turned into a test case. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From vagabond at cataclysm-software.net Fri Apr 21 14:41:14 2006 From: vagabond at cataclysm-software.net (Andrew Thompson) Date: Fri, 21 Apr 2006 14:41:14 -0400 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> <44479C35.4090703@cataclysm-software.net> <4448CF89.3040406@cataclysm-software.net> Message-ID: <4449274A.2090806@cataclysm-software.net> Bryan Soto wrote: > If you like. I think I need to start from scratch with some testcases > to catch these stupid mistakes I'm making. :/ Hmm, it works, but it also works without the tag or with any/all of them... I wonder if this is needed (I think I just had an invalid base tag that was breaking things). Andrew From bryan.a.soto at gmail.com Fri Apr 21 14:53:57 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 11:53:57 -0700 Subject: [Nitro] Bryan & dispatcher/router patch? In-Reply-To: <4449274A.2090806@cataclysm-software.net> References: <44454969.9090605@cataclysm-software.net> <44462CD0.6000503@cataclysm-software.net> <44479C35.4090703@cataclysm-software.net> <4448CF89.3040406@cataclysm-software.net> <4449274A.2090806@cataclysm-software.net> Message-ID: On 4/21/06, Andrew Thompson wrote: > Hmm, it works, but it also works without the tag or with any/all > of them... I wonder if this is needed (I think I just had an invalid > base tag that was breaking things). > Oh, yeah. I definitely need tests... :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 15:25:59 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 12:25:59 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Message-ID: On 4/21/06, Fabian Buch wrote: > > Am 20.04.2006 um 23:26 schrieb Bryan Soto: > > Time.at(0) maybe? > > Perfect! Changed that and tests work here on my machine (MacOSX), > hopefully Windows has something reasonable (maybe 1970 too?) as well. > So now it should work on Windows too. > > I made a new patch bundle (the initial patch, plus the Time.at(0) fix) > and submitted it as Trac ticket > (http://devlab.oree.ch/trac/nitrohq/ticket/33). Is that better than > attaching it to mails to the ML, Brian? > Windows is being... difficult. :/ 1) Error: test_atom(TC_FeedHelper): ArgumentError: 3 elements of civil date are necessary c:/ruby/lib/ruby/1.8/date.rb:1214:in 'new_with_hash' c:/ruby/lib/ruby/1.8/date.rb:1258:in 'parse' ./lib/nitro/helper/feed.rb:389:in 'to_rfc3339' ./lib/nitro/helper/feed.rb:241:in 'build_atom' ./test/nitro/helper/tc_feed.rb:84:in 'test_atom' Passes fine on linux, though. I'll see what I can figure out and run it by you. Sound good? -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 16:44:25 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 13:44:25 -0700 Subject: [Nitro] Interesting web app mentioned on the Seaside list. Message-ID: http://www.netvibes.com/ -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From james_b at neurogami.com Fri Apr 21 17:53:55 2006 From: james_b at neurogami.com (James Britt) Date: Fri, 21 Apr 2006 14:53:55 -0700 Subject: [Nitro] Interesting web app mentioned on the Seaside list. In-Reply-To: References: Message-ID: <44495473.7000109@neurogami.com> Bryan Soto wrote: > http://www.netvibes.com/ Loading... I'm hopeful that, some day, it will become common for Web developers to write Web apps that offer useful behavior in the absence of JavaScript. But today is not that day. I'm going to guess that I must now turn on JavaScript to have the page load even a basic "Welcome!" message. But it doesn't make me confident that what I'll see is well thought out. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Fri Apr 21 18:09:53 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 15:09:53 -0700 Subject: [Nitro] Interesting web app mentioned on the Seaside list. In-Reply-To: <44495473.7000109@neurogami.com> References: <44495473.7000109@neurogami.com> Message-ID: I should have given a description. My apologies. >From the about page (still requires javascript though): Netvibes.com is a custom made web 2.0 home page solution This service is free and gives the user the ability : * to create a personalized page with the content they like. * to put together data feeds and services from web 2.0 with a very simple interface * to access your page anytime and from any computer . It is also possible to : * browse, modify, and import your RSS feeds with our integrated RSS/ATOM feedreader. You can easily import an OPML file as well. * to import, download and listen podcasts without any additional software * to check your mail on one or many gmail account, to stick webnotes, weather and many more to come ! -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Fri Apr 21 18:11:59 2006 From: transfire at gmail.com (TRANS) Date: Fri, 21 Apr 2006 18:11:59 -0400 Subject: [Nitro] Interesting web app mentioned on the Seaside list. In-Reply-To: <44495473.7000109@neurogami.com> References: <44495473.7000109@neurogami.com> Message-ID: <4b6f054f0604211511h4557fb85k8f48884be2c2b23@mail.gmail.com> On 4/21/06, James Britt wrote: > I'm hopeful that, some day, it will become common for Web developers to > write Web apps that offer useful behavior in the absence of JavaScript. > > But today is not that day. > > I'm going to guess that I must now turn on JavaScript to have the page > load even a basic "Welcome!" message. > > But it doesn't make me confident that what I'll see is well thought out. It's a nice looking sitr really. But it is extra extra AJAX. But is it a Nitro site? T. From bryan.a.soto at gmail.com Fri Apr 21 18:32:06 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 15:32:06 -0700 Subject: [Nitro] Interesting web app mentioned on the Seaside list. In-Reply-To: <4b6f054f0604211511h4557fb85k8f48884be2c2b23@mail.gmail.com> References: <44495473.7000109@neurogami.com> <4b6f054f0604211511h4557fb85k8f48884be2c2b23@mail.gmail.com> Message-ID: On 4/21/06, TRANS wrote: > It's a nice looking sitr really. But it is extra extra AJAX. But is it > a Nitro site? > I don't think so. Perhaps I shouldn't have even mentioned it as it's off-topic. Sorry for the noise. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Fri Apr 21 19:21:11 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 21 Apr 2006 16:21:11 -0700 Subject: [Nitro] Official Repo In-Reply-To: References: <1145527907.4137.7.camel@nissl.mammuth> <1145563017.13698.11.camel@nissl.mammuth> <1145609200.4061.15.camel@nissl.mammuth> Message-ID: On 4/21/06, Bryan Soto wrote: > Very good question. It's either in the dispatcher or the params > parsing so we're making progress. Thanks for the info, I'll see what I > can figure out. > I know you submitted a patch previously, so on the off chance you can help debug, I believe it has to do with the changes submitted here: http://devlab.oree.ch/trac/nitrohq/changeset/603#file1 in compiler.rb. At the very least, if you find the time to change things back as they were in that file, we can confirm where the problem is. :) I'm going to see if you there's enough info in your emails to create a test case to narrow this one down. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Fri Apr 21 20:34:58 2006 From: transfire at gmail.com (TRANS) Date: Fri, 21 Apr 2006 20:34:58 -0400 Subject: [Nitro] Interesting web app mentioned on the Seaside list. In-Reply-To: References: <44495473.7000109@neurogami.com> <4b6f054f0604211511h4557fb85k8f48884be2c2b23@mail.gmail.com> Message-ID: <4b6f054f0604211734v7d7c057w1be27e86d8111c9c@mail.gmail.com> On 4/21/06, Bryan Soto wrote: > On 4/21/06, TRANS wrote: > > It's a nice looking sitr really. But it is extra extra AJAX. But is it > > a Nitro site? > > > > I don't think so. Perhaps I shouldn't have even mentioned it as it's off-topic. > > Sorry for the noise. Hey, a little noise is what makes life interesting. T. From nissl at tiscali.it Sat Apr 22 06:22:07 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Sat, 22 Apr 2006 12:22:07 +0200 Subject: [Nitro] Official Repo In-Reply-To: References: <1145527907.4137.7.camel@nissl.mammuth> <1145563017.13698.11.camel@nissl.mammuth> <1145609200.4061.15.camel@nissl.mammuth> Message-ID: <1145701327.4201.27.camel@nissl.mammuth> ok, after to have a rapid look to nitro/lib/nitro/compiler.rb i find a problem in compile_action method ################################################################# -- change this line : (288) code << "break unless i < #{param_count};" -- in: (288) code << "break if i < #{param_count};" -- with this change correctly i have two parameters: ["menu_item_001", "pippo"] -- for http://localhost:9999/get_content?params=menu_item_001&_=pippo and not three ################################################################# ################################################################## -- without the previous change params, already is ["menu_item_001"] -- and after the concat call I have 3 params ["menu_item_001", "menu_item_001", "pippo"] # Concatenate some extracted parameters. (217) params.concat(context.params.values) ################################################################## but... the last parameter is _= (&_=) in a prototype.js AJAX request: (670 in prot. 1.5.0_rc0) if (parameters.length > 0) parameters += '&_='; (see http://blog.markjuh.net/markjuh/2005/9/26/unexpected_characters_when_using_prototy for ref direction) removing this line from js make a fine uri request for nitro. ;) modify prototype or modify nitro (for handling bogus parameters)? to be or not to be... that's the question :D ciao Massimo Maria Ghisalberti From george.moschovitis at gmail.com Sat Apr 22 12:31:44 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 22 Apr 2006 18:31:44 +0200 Subject: [Nitro] Nitro Blog Message-ID: Dear devs, I will integrate a simple Blog in the forthcoming Nitro homepage (www.nitroproject.org). I would like to hear suggestions about content categories for this Blog. thanks, George. PS: Is anyone interested in writing articles for this Blog? -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From m.fellinger at gmail.com Sat Apr 22 12:35:45 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Sun, 23 Apr 2006 01:35:45 +0900 Subject: [Nitro] Nitro Blog In-Reply-To: References: Message-ID: <9c00d3e00604220935r2c36d0co60b94fb947664f4e@mail.gmail.com> Uhm, sure - i hardly get to writing lengthy articles tho these daysif you want to have one or two thoughts a day about nitro just tell me :) On 4/23/06, George Moschovitis wrote:> Dear devs,>> I will integrate a simple Blog in the forthcoming Nitro homepage> (www.nitroproject.org). I would like to hear suggestions about content> categories for this Blog.>> thanks,> George.>> PS: Is anyone interested in writing articles for this Blog?>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From transfire at gmail.com Sat Apr 22 12:39:14 2006 From: transfire at gmail.com (TRANS) Date: Sat, 22 Apr 2006 12:39:14 -0400 Subject: [Nitro] nitro-auth Message-ID: <4b6f054f0604220939j5ad1e8bcu270773a9cb877967@mail.gmail.com> What's up with nitro-auth? T. From george.moschovitis at gmail.com Sat Apr 22 12:43:23 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 22 Apr 2006 18:43:23 +0200 Subject: [Nitro] Nitro Blog In-Reply-To: <9c00d3e00604220935r2c36d0co60b94fb947664f4e@mail.gmail.com> References: <9c00d3e00604220935r2c36d0co60b94fb947664f4e@mail.gmail.com> Message-ID: Thanks... -g. On 4/22/06, Michael Fellinger wrote: > Uhm, sure - i hardly get to writing lengthy articles tho these daysif you want to have one or two thoughts a day about nitro just tell me :) > On 4/23/06, George Moschovitis wrote:> Dear devs,>> I will integrate a simple Blog in the forthcoming Nitro homepage> (www.nitroproject.org). I would like to hear suggestions about content> categories for this Blog.>> thanks,> George.>> PS: Is anyone interested in writing articles for this Blog?>>> --> http://www.gmosx.com> http://www.navel.gr> http://www.nitrohq.com>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 22 12:54:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 22 Apr 2006 18:54:28 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Message-ID: > Anyone have any suggestions on a better way of managing patches? I > think we'd like to keep them submitted via the mailing list (it seems > to be popular). Maybe I'll just create my own tickets on Trac as > reminders of what I need to do. > please submit to the mailing list too! -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From fabian at oggu.de Sat Apr 22 18:43:14 2006 From: fabian at oggu.de (Fabian Buch) Date: Sun, 23 Apr 2006 00:43:14 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Message-ID: <60aba4c02cc38e9fad5e23bc76af225c@oggu.de> Am 22.04.2006 um 18:54 schrieb George Moschovitis: > please submit to the mailing list too! here you are (identical to the one attached to trac) Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: feedhelper.patch.gz Type: application/x-gzip Size: 19845 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060422/f9ead0cb/attachment.gz -------------- next part -------------- From fabian at oggu.de Sat Apr 22 18:45:45 2006 From: fabian at oggu.de (Fabian Buch) Date: Sun, 23 Apr 2006 00:45:45 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> Message-ID: <1cbe878b70a212b9fa90359fdff36da4@oggu.de> Am 21.04.2006 um 21:25 schrieb Bryan Soto: > Windows is being... difficult. :/ > > 1) Error: > test_atom(TC_FeedHelper): > ArgumentError: 3 elements of civil date are necessary > c:/ruby/lib/ruby/1.8/date.rb:1214:in 'new_with_hash' > c:/ruby/lib/ruby/1.8/date.rb:1258:in 'parse' > ./lib/nitro/helper/feed.rb:389:in 'to_rfc3339' > ./lib/nitro/helper/feed.rb:241:in 'build_atom' > ./test/nitro/helper/tc_feed.rb:84:in 'test_atom' > > Passes fine on linux, though. > > I'll see what I can figure out and run it by you. Sound good? Thank you. I've no Windows box handy, so it'd be very cool if you could figure out what it is. Fabian From fabian at oggu.de Sat Apr 22 18:53:21 2006 From: fabian at oggu.de (Fabian Buch) Date: Sun, 23 Apr 2006 00:53:21 +0200 Subject: [Nitro] nitro-auth In-Reply-To: <4b6f054f0604220939j5ad1e8bcu270773a9cb877967@mail.gmail.com> References: <4b6f054f0604220939j5ad1e8bcu270773a9cb877967@mail.gmail.com> Message-ID: <5ede263ba0d32a911a989deac7e086dd@oggu.de> Am 22.04.2006 um 18:39 schrieb TRANS: > What's up with nitro-auth? not maintained at the moment, but several ppl are interested in using it (needs to be customized for current Nitro and some improvement) From mischa.kroon at gmail.com Sat Apr 22 22:37:03 2006 From: mischa.kroon at gmail.com (Mischa Kroon) Date: Sun, 23 Apr 2006 04:37:03 +0200 Subject: [Nitro] Interesting web app mentioned on the Seaside list. References: <44495473.7000109@neurogami.com><4b6f054f0604211511h4557fb85k8f48884be2c2b23@mail.gmail.com> <4b6f054f0604211734v7d7c057w1be27e86d8111c9c@mail.gmail.com> Message-ID: <007401c6667e$cede5eb0$0a01a8c0@mischabak> Personally I think this is a very good site to look at in regarding the development of NITRO. Somehting webpart alike ( .Net terminology for personasible dragable parts on the screen ) wouldn't misstand NITRO in any way. However elegance is of the issue :) * shutting up again * From bryan.a.soto at gmail.com Sun Apr 23 03:40:17 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 23 Apr 2006 00:40:17 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <1cbe878b70a212b9fa90359fdff36da4@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> <1cbe878b70a212b9fa90359fdff36da4@oggu.de> Message-ID: On 4/22/06, Fabian Buch wrote: > > Am 21.04.2006 um 21:25 schrieb Bryan Soto: > > Windows is being... difficult. :/ > > > > 1) Error: > > test_atom(TC_FeedHelper): > > ArgumentError: 3 elements of civil date are necessary > > c:/ruby/lib/ruby/1.8/date.rb:1214:in 'new_with_hash' > > c:/ruby/lib/ruby/1.8/date.rb:1258:in 'parse' > > ./lib/nitro/helper/feed.rb:389:in 'to_rfc3339' > > ./lib/nitro/helper/feed.rb:241:in 'build_atom' > > ./test/nitro/helper/tc_feed.rb:84:in 'test_atom' > > > > Passes fine on linux, though. > > > > I'll see what I can figure out and run it by you. Sound good? > > Thank you. I've no Windows box handy, so it'd be very cool if you could > figure out what it is. > Could you try this change and see if it works for you then? It passes the tests on WIndows. # feed.rb:388 def to_rfc3339(datetime) # t = DateTime.parse(datetime.to_s).strftime('%FT%T%z') time = Time.parse(datetime.to_s) t = DateTime.parse(time.strftime('%Y-%m-%d')).strftime('%FT%T%z') return t[0..-3]+":"+t[-2..-1] end Thanks. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From fabian at oggu.de Sun Apr 23 05:22:45 2006 From: fabian at oggu.de (Fabian Buch) Date: Sun, 23 Apr 2006 11:22:45 +0200 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> <1cbe878b70a212b9fa90359fdff36da4@oggu.de> Message-ID: <7b317862dc5fc9ae29bdb7d587dc0b10@oggu.de> Am 23.04.2006 um 09:40 schrieb Bryan Soto: > Could you try this change and see if it works for you then? It passes > the tests on WIndows. > t = DateTime.parse(time.strftime('%Y-%m-%d')).strftime('%FT%T%z') Makes tests pass indeed, but also sets time to 00:00:00 for all your Atom entries. Digged a little further into it and it seems to_rfc3339 is an interpretation of iso8601 and in ruby's stdlib it's called iso8601/xmlschema. Should've noticed this earlier. So finally no bad to_rfc3339 hack anymore, instead using the method iso8601 of Time for Atom. Patch bundle attached. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: feedhelper.patch.gz Type: application/x-gzip Size: 20045 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060423/9beb0667/attachment.gz From transfire at gmail.com Sun Apr 23 08:13:29 2006 From: transfire at gmail.com (TRANS) Date: Sun, 23 Apr 2006 08:13:29 -0400 Subject: [Nitro] Just discovered Laszlo Message-ID: <4b6f054f0604230513m502aac2fq6317b8cd401e6367@mail.gmail.com> I got your VIEW right here. http://www.laszlosystems.com/developers/ T. From george.moschovitis at gmail.com Sun Apr 23 11:45:42 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 23 Apr 2006 18:45:42 +0300 Subject: [Nitro] nitro-auth In-Reply-To: <5ede263ba0d32a911a989deac7e086dd@oggu.de> References: <4b6f054f0604220939j5ad1e8bcu270773a9cb877967@mail.gmail.com> <5ede263ba0d32a911a989deac7e086dd@oggu.de> Message-ID: never actually used it... it is seriously outdated and does not use nitro to its full potential. regards, George. On 4/23/06, Fabian Buch wrote: > Am 22.04.2006 um 18:39 schrieb TRANS: > > What's up with nitro-auth? > > not maintained at the moment, but several ppl are interested in using > it (needs to be customized for current Nitro and some improvement) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sun Apr 23 12:16:56 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 23 Apr 2006 19:16:56 +0300 Subject: [Nitro] [PATCH] Some more changes/fixes from me ;-) Message-ID: Here comes one more patch... -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 25167 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060423/640b00f9/attachment.zip From bryan.a.soto at gmail.com Mon Apr 24 02:03:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 23 Apr 2006 23:03:40 -0700 Subject: [Nitro] [PATCH] New FeedHelper In-Reply-To: <7b317862dc5fc9ae29bdb7d587dc0b10@oggu.de> References: <72b1d7fedda2b8da73e5488a51e00978@oggu.de> <106c3dc1f6043a4c856857e7f58679ea@oggu.de> <1e603594b8a7ddd855eab19c3e6a7a70@oggu.de> <1cbe878b70a212b9fa90359fdff36da4@oggu.de> <7b317862dc5fc9ae29bdb7d587dc0b10@oggu.de> Message-ID: On 4/23/06, Fabian Buch wrote: > > Am 23.04.2006 um 09:40 schrieb Bryan Soto: > > Could you try this change and see if it works for you then? It passes > > the tests on WIndows. > > > t = DateTime.parse(time.strftime('%Y-%m-%d')).strftime('%FT%T%z') > > Makes tests pass indeed, but also sets time to 00:00:00 for all your > Atom entries. Digged a little further into it and it seems to_rfc3339 > is an interpretation of iso8601 and in ruby's stdlib it's called > iso8601/xmlschema. Should've noticed this earlier. So finally no bad > to_rfc3339 hack anymore, instead using the method iso8601 of Time for > Atom. > > Patch bundle attached. > Which works perfectly and has been applied. Many thanks. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 24 02:27:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sun, 23 Apr 2006 23:27:48 -0700 Subject: [Nitro] [PATCH] Some more changes/fixes from me ;-) In-Reply-To: References: Message-ID: These will require a little more work. You had included an older version of Oggu's feed helper, so I had to apply to a temp repo and send from there. You might want to unpull that before pulling from the repo. I don't know if you'll get conflicts... On 4/23/06, George Moschovitis wrote: > Here comes one more patch... > > -g. > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 24 03:03:10 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 24 Apr 2006 00:03:10 -0700 Subject: [Nitro] [PATCH] Some more changes/fixes from me ;-) In-Reply-To: References: Message-ID: I have about six left, which I'll take care of tomorrow. On 4/23/06, Bryan Soto wrote: > These will require a little more work. You had included an older > version of Oggu's feed helper, so I had to apply to a temp repo and > send from there. > > You might want to unpull that before pulling from the repo. I don't > know if you'll get conflicts... > > On 4/23/06, George Moschovitis wrote: > > Here comes one more patch... > > > > -g. > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From epiperak at gmail.com Mon Apr 24 10:39:29 2006 From: epiperak at gmail.com (Emmanouil Piperakis) Date: Mon, 24 Apr 2006 23:39:29 +0900 Subject: [Nitro] Happy Name Day George! Message-ID: For non-Greeks this might be a new thing, but today is the name day (celebration of the name) for George! George, we wish you (I believe the whole list too) happy name day and many many years of happiness, health and fruitful nitro coding! Emmanouil / EerieShadow -- Dr Emmanouil Piperakis Tokyo Institute of Technology Neural Networks & Brain Theory epiperak at gmail.com, epiperak at isl.titech.ac.jp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060424/413124e0/attachment.html From transfire at gmail.com Mon Apr 24 12:01:44 2006 From: transfire at gmail.com (TRANS) Date: Mon, 24 Apr 2006 12:01:44 -0400 Subject: [Nitro] Happy Name Day George! In-Reply-To: References: Message-ID: <4b6f054f0604240901q883bbc6vb60793a7cebec059@mail.gmail.com> You mean there are only 365 Greek names? ;-) Happy name day! T. From billk at cts.com Mon Apr 24 13:01:04 2006 From: billk at cts.com (Bill Kelly) Date: Mon, 24 Apr 2006 10:01:04 -0700 Subject: [Nitro] Happy Name Day George! References: <4b6f054f0604240901q883bbc6vb60793a7cebec059@mail.gmail.com> Message-ID: <0fe501c667c0$aca034c0$6442a8c0@musicbox> > You mean there are only 365 Greek names? ;-) > > Happy name day! And who gets Feb 29th? From bryan.a.soto at gmail.com Mon Apr 24 20:33:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 24 Apr 2006 17:33:26 -0700 Subject: [Nitro] [PATCH] Some more changes/fixes from me ;-) In-Reply-To: References: Message-ID: They've all been applied. On 4/24/06, Bryan Soto wrote: > I have about six left, which I'll take care of tomorrow. > > On 4/23/06, Bryan Soto wrote: > > These will require a little more work. You had included an older > > version of Oggu's feed helper, so I had to apply to a temp repo and > > send from there. > > > > You might want to unpull that before pulling from the repo. I don't > > know if you'll get conflicts... > > > > On 4/23/06, George Moschovitis wrote: > > > Here comes one more patch... > > > > > > -g. > > > > > > -- > > > http://www.gmosx.com > > > http://www.navel.gr > > > http://www.nitrohq.com > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 24 20:42:08 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 24 Apr 2006 17:42:08 -0700 Subject: [Nitro] [FIX] find_or_create_by with relations In-Reply-To: References: Message-ID: I'll be applying this unless there is an objection. On 4/4/06, Bryan Soto wrote: > I'm not sure if this is a bug or an enhancement. I don't think what > Stephan was trying to do was supported by Og. What do you think? Is > this a good enhancement? Any other opinions? See > http://devlab.oree.ch/trac/nitrohq/ticket/29 > > Thanks, > > Bryan > > On 4/2/06, George Moschovitis wrote: > > Thanks, i will review this shortly. > > > > -g. > > > > On 4/2/06, Stephan Walter wrote: > > > Hi, > > > > > > Og currently has a problem with find_or_create_by_* if the object has > > > relations. The find will execute correctly, but when no object is found, > > > the creation of the new object will not include the relations. > > > > > > Made-up example: > > > > > > class A > > > property :name > > > belongs_to :b, B > > > end > > > > > > class B > > > end > > > > > > A.find_or_create_by_name_and_b("foo", @b) > > > > > > This will result in the correct SELECT statement: > > > > > > SELECT * FROM a WHERE name = 'foo' AND b_oid = 1 > > > > > > If no object is found, the following INSERT statement will be wrong, the > > > b_oid should not be NULL: > > > > > > INSERT INTO a (name,b_oid,oid) VALUES ('foo',NULL,NULL) > > > > > > The patch at http://84.16.238.99/files/entity.rb.patch fixes this. However > > > I am not sure if the patch does the right thing, and I have not tested it > > > a lot. It'd be great if someone could look into this. > > > > > > -Stephan > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Mon Apr 24 20:42:29 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 24 Apr 2006 17:42:29 -0700 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> Message-ID: I'll be applying this one unless there is any objection. On 4/19/06, Bryan Soto wrote: > Hey George, any opinions on this one? Does it fit with your current > plans for Nitro? > > On 4/18/06, George Moschovitis wrote: > > So much to review, so little time ;-) Thanks anyway! > > > > -g. > > > > On 4/18/06, Dimitri Aivaliotis wrote: > > > Minor fix to generate directories in the output path, if they don't > > > already exist. > > > > > > - Dimitri > > > > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > -- > > http://www.gmosx.com > > http://www.navel.gr > > http://www.nitrohq.com > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Mon Apr 24 21:36:44 2006 From: transfire at gmail.com (TRANS) Date: Mon, 24 Apr 2006 21:36:44 -0400 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> Message-ID: <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> Hi all, I was reading a little about Capistrano (SwitchTower) this evening after working most of the day on Reap. What struck me was that Capistrano looks just to be an extenion on Rake. Which got me wondering in general. So I'd like to ask: What do you think of Reap and how it works? For those who haven't used it much here's a quick overview... Reap's main intention is as a dedicated packaging assistant, and has a number of tasks built-in for that. It didn't start out as a general task executor at all, but as it evoloved that became more and more doable. Now one can actually create a custom task just by dropping the code into your project's task/ directory and it will show up when you run reap. A Reap task is designed like this: class MyTask < Reap::Task task_desc "This is my task's one-line description." task_help %{ I can do on and on here about this task and how to use it. } def run # do stuff # use task.some_property to get info from ProjectInfo # ... end end Then you can do reap mytask There are a few more details of course, but that's jist of it anyway. Probably those most stark distiction between Rake and Reap, besides the stuctural differences is how you prefore the same type of task more than once. With Rake you'd define two task with slighly differnt names that access common code. Eg. maybe: task :rdoc_core { |r| r.include = "lib/facets/core/" r.dir = "doc/api/core" # ... rdoc(r) } task :rdoc_more { |r| r.include = "lib/facets/more/" r.dir = "doc/api/more" # ... rdoc(r) } In Reap you'd actually just create and array under the rdoc section in the ProjectInfo file. rdoc: - include: lib/facets/core/ dir: doc/api/core # ... - include: lib/facets/more dir: doc/api/more # ... This works well with the exception that you have no handle to which to say I want to run only second or the first --you have to go throught both no matter what. I've though using names and types, ie: rdoc_core: !rdoc include: lib/facets/core/ dir: doc/api/core # ... rdoc_mode: !rdoc include: lib/facets/more dir: doc/api/more # ... My only concer there is that the ProjectInfo file would start to loose it's "objectivity" so to speak --to tell in general terms about the project. Is that irrational? Anyhow those are some of my thoughts. Sorry for going on so long. Was wondering what others think about this and Reap in gerneral. Thanks, T. From james_b at neurogami.com Tue Apr 25 00:01:00 2006 From: james_b at neurogami.com (James Britt) Date: Mon, 24 Apr 2006 21:01:00 -0700 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> Message-ID: <444D9EFC.70004@neurogami.com> TRANS wrote: > Hi all, > > I was reading a little about Capistrano (SwitchTower) this evening > after working most of the day on Reap. What struck me was that > Capistrano looks just to be an extenion on Rake. Which got me > wondering in general. So I'd like to ask: What do you think of Reap > and how it works? For those who haven't used it much here's a quick > overview... I've not yet used Reap. I've grown accustom to Rake. But I'm curious about the social/network effects of tool adoption. Before there was SwitchTower, I has started assembling a set of scripts to package and deploy my code. When I began these scripts they were for me alone, so little quirks and system dependencies were acceptable. They worked for me, so I was happy. Working with a team, though, I decided that explaining or hacking around these things was a Bad Idea. I took a look at SwitchTower (which was then being renamed to Capistrano), but it was quirky, and didn't quite work for me. The best documentation I could find was wiki-grade. Given the choice between dealing with the quirks and bugs of someone else's (largely undocumented) software, or doing the same for my own, I went with the code I knew and knew worked for me. But I liked how Capistrano was defined as a collection of Rake tasks. For better or worse, Rake has the same "market share" as rubygems. There are alternatives, and they have their virtues, but using them entails additional friction. So I recrafted my deployment tools as Rake tasks. And I've done something similar for my database schema tools. As with Capistrano, Rails migrations kinda-sorta-but-not-really worked. And I'd already worked out my own basic tools for avoiding the 'discomfort' of bouncing in and out of SQL tools. Now, given that I'm involving people on a Rails project, it would perhaps be best to just figure out how to use the "standard" Rails tools for utility jobs, but in lieu of that (as it would likely mean spending time sorting out issues that are, ultimately, tangential to the application itself) using Rake nicely wraps the custom code in a familiar UI. Now, I still write code on my own, largely Nitro (if it's a Web app), but given my increasing familiarity with Rake, I have to expect that I would use Rake tasks to automate ancillary jobs as well. Basically, once a tool starts to play a regular role in my projects, the burden of employing alternative tools for the same tasks becomes higher; I need a compelling reason to go with an alternative. It has to at least do something important that the more mainstream option either doesn't do, or doesn't do well. I have that with Og/Nitro (for many tasks, at least; some are better handled by Rails, some by pure hand-rolled code). What's the argument for Reap? Is it a "better Rake"? Is that an over-simplification? Plain wrong? In writing this I'm reminded of when people look for ways to convince their Java-hooked bosses to use Ruby. So: What's the elevator pitch for Reap? > > Reap's main intention is as a dedicated packaging assistant, and has a > number of tasks built-in for that. It didn't start out as a general > task executor at all, but as it evoloved that became more and more > doable. Now one can actually create a custom task just by dropping the > code into your project's task/ directory and it will show up when you > run reap. I believe Rake allows that, or perhaps it's some Rails thing. But in Rails you can drop *.rake files into lib/tasks and file's tasks are available. > ... > There are a few more details of course, but that's jist of it anyway. > Probably those most stark distiction between Rake and Reap, besides > the stuctural differences is how you prefore the same type of task > more than once. With Rake you'd define two task with slighly differnt > names that access common code. Eg. maybe: When find that I want to perform the same task multiple times I move code to plain methods, and call the method from a task. For example, I had a task that would drop and recreate a database, then load in some fixture data. It initially worked against a single database, but later I wanted to be able to sweep all known databases. I found that I could not loop and call a task more than once, so I just moved the task guts to a method. Simpler all around. -- James Britt "Blanket statements are over-rated" From transfire at gmail.com Tue Apr 25 00:34:43 2006 From: transfire at gmail.com (TRANS) Date: Tue, 25 Apr 2006 00:34:43 -0400 Subject: [Nitro] General inquiry about Reap In-Reply-To: <444D9EFC.70004@neurogami.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> Message-ID: <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> On 4/25/06, James Britt wrote: > TRANS wrote: > > Hi all, > > > > I was reading a little about Capistrano (SwitchTower) this evening > > after working most of the day on Reap. What struck me was that > > Capistrano looks just to be an extenion on Rake. Which got me > > wondering in general. So I'd like to ask: What do you think of Reap > > and how it works? For those who haven't used it much here's a quick > > overview... > > I've not yet used Reap. I've grown accustom to Rake. But I'm curious > about the social/network effects of tool adoption. > > Before there was SwitchTower, I has started assembling a set of scripts > to package and deploy my code. When I began these scripts they were for > me alone, so little quirks and system dependencies were acceptable. > They worked for me, so I was happy. > > Working with a team, though, I decided that explaining or hacking around > these things was a Bad Idea. I took a look at SwitchTower (which was > then being renamed to Capistrano), but it was quirky, and didn't quite > work for me. The best documentation I could find was wiki-grade. > > Given the choice between dealing with the quirks and bugs of someone > else's (largely undocumented) software, or doing the same for my own, I > went with the code I knew and knew worked for me. > > But I liked how Capistrano was defined as a collection of Rake tasks. > For better or worse, Rake has the same "market share" as rubygems. > There are alternatives, and they have their virtues, but using them > entails additional friction. > > So I recrafted my deployment tools as Rake tasks. And I've done > something similar for my database schema tools. As with Capistrano, > Rails migrations kinda-sorta-but-not-really worked. And I'd already > worked out my own basic tools for avoiding the 'discomfort' of bouncing > in and out of SQL tools. > > Now, given that I'm involving people on a Rails project, it would > perhaps be best to just figure out how to use the "standard" Rails tools > for utility jobs, but in lieu of that (as it would likely mean spending > time sorting out issues that are, ultimately, tangential to the > application itself) using Rake nicely wraps the custom code in a > familiar UI. > > Now, I still write code on my own, largely Nitro (if it's a Web app), > but given my increasing familiarity with Rake, I have to expect that I > would use Rake tasks to automate ancillary jobs as well. > > Basically, once a tool starts to play a regular role in my projects, the > burden of employing alternative tools for the same tasks becomes higher; > I need a compelling reason to go with an alternative. It has to at > least do something important that the more mainstream option either > doesn't do, or doesn't do well. > > I have that with Og/Nitro (for many tasks, at least; some are better > handled by Rails, some by pure hand-rolled code). > > What's the argument for Reap? Is it a "better Rake"? Is that an > over-simplification? Plain wrong? > > In writing this I'm reminded of when people look for ways to convince > their Java-hooked bosses to use Ruby. Very good points. Thanks James. The transition to yet another tool is understandably steep. And has to be worth the effort. I would like to lower the bar as much as possible while increasing the worth of corssing over at the same time. At one point Reap actually went through a phase of being just a set or Rake tasks. But it lacked a little bit for it, so I decided against that route. Nonethless I'm asking partly b/c I am wondering about making it, at least, more like Rake. Note you can already use Reap via Rake just as if Reap were nothing but a set of tasks --I just created Rake interfaces for each Reap task. It wasn;t hard. But I find it more trouble than it's worth. Why create a Rakefile when you already have the tasks availabe to you just by calling reap? > So: What's the elevator pitch for Reap? Well, first understand Reap's core intent is like that of Meta Project (if you've heard of that project) --a project assitant that makes it easy to do many of the common chores. For instance Reap makes it pretty easy to generate .tar.gz, .gem and .deb packages in one fell swoop. Another intersting task is it's ability to extract unit tests from source comments. It also has a testing task that has very nice output and isolates each test in it's own process. And it will release to Rubyforge right easy too. Plus others. So that's one thing. Like I said the ability to create cusotm tasks simply evolved out the dedicated tasks I was building, and it's still evolving, but wan't the original intent. But the main thing that really sets Reap apart is the ProjectInfo file. It's a YAML file that describes the project and how things need to be handled for it. In this way there's a single resource for all this information that can reused by any task. And becuase it is pure data and not Ruby code, that information is available in a very clear and descernable way to any other tool, or human for that matter. Do check out the webpage (albiet still a bit rough). http://reap.rubyforge.org T. From bryan.a.soto at gmail.com Tue Apr 25 02:26:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Mon, 24 Apr 2006 23:26:40 -0700 Subject: [Nitro] Patch applied. Message-ID: I've updated the repo to facets 1.3.2. Facets currently has a bug in aspects. Attached patch to facets-1.3.2/lib/facets/more/aspects.rb fixes. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: aspects.patch Type: text/x-patch Size: 822 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060425/2f328bd8/attachment.bin From transfire at gmail.com Tue Apr 25 06:20:52 2006 From: transfire at gmail.com (TRANS) Date: Tue, 25 Apr 2006 06:20:52 -0400 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> Message-ID: <4b6f054f0604250320s4c9a135cg9c2d5cd758c720de@mail.gmail.com> A quick follow-up. I could easily make task building something like this: task :name do when { projectfile? } help <<-end Help information. end run do |x| # do the task end end That would probably be the most proper course. But if Rake compatibility (or nearly so at least) is though vitially important than could do something like this: desc "This is a description" task :name do |x| # do the task end cont do help <<-end This is help text. end when do projectfile? end end Not sure what to call "cont". T. From fabian at oggu.de Tue Apr 25 06:26:31 2006 From: fabian at oggu.de (Fabian Buch) Date: Tue, 25 Apr 2006 12:26:31 +0200 Subject: [Nitro] devlab's glycerin RDoc Message-ID: suggestion for http://devlab.oree.ch/rdoc/nitrohq/: I think it'd be nicer and more usable if _darcs would be excluded (-x _darcs) and a main page set (-m) (maybe nitro/README ?) Fabian From surrender_it at yahoo.it Tue Apr 25 07:23:00 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Tue, 25 Apr 2006 13:23:00 +0200 Subject: [Nitro] Better diagnostics for gen Message-ID: Hi people, I noticed working on a friend's box that the current exception handling tends to swallow too much information. The problem is that in gen/bin/gen the block: begin require "gen/#{generator}/gen.rb" rescue LoadError puts 'Cannot load the specified generator!' exit 1 end won't notice the difference between a non existing generator and a LoadError raised in the generator file (friend's problem was related to a corrupted install of facets). Maybe there could be a more explanative message, i.e. begin path="gen/#{generator}/gen.rb" require path rescue LoadError =>e if e.message[/#{path}$/] reason= %{\tno such generator "#{generator}"} else reason= %{\tunmet dependency loading "#{path}":\n\t#{e.message}} end puts "Cannot load the specified generator!" puts reason exit 1 end I think spitting out the available generators is not meaningful as of now, but if Brian's suggestion of model/scaffold generators is going to be applied I think it would be nice to also show the list in the first case. From james_b at neurogami.com Tue Apr 25 09:52:10 2006 From: james_b at neurogami.com (James Britt) Date: Tue, 25 Apr 2006 06:52:10 -0700 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> Message-ID: <444E298A.2080403@neurogami.com> TRANS wrote: > On 4/25/06, James Britt wrote: > >> ... >>In writing this I'm reminded of when people look for ways to convince >>their Java-hooked bosses to use Ruby. > > > Very good points. Thanks James. The transition to yet another tool is > understandably steep. And has to be worth the effort. I would like to > lower the bar as much as possible while increasing the worth of > corssing over at the same time. > Thank you. I have to believe Reap has cool stuff; it's just that time gets tighter and tighter, and I really do have to sort of sell technological variations to co-workers and clients. > At one point Reap actually went through a phase of being just a set or > Rake tasks. But it lacked a little bit for it, so I decided against > that route. Nonethless I'm asking partly b/c I am wondering about > making it, at least, more like Rake. > > Note you can already use Reap via Rake just as if Reap were nothing > but a set of tasks --I just created Rake interfaces for each Reap > task. It wasn;t hard. But I find it more trouble than it's worth. Why > create a Rakefile when you already have the tasks availabe to you just > by calling reap? If all you have.need is Reap, then I agree. But someone already has a Rake investment, then exposing new tools through a familiar interface seems a really good way to get them used. That was one motivation to rewrite my packing code as Rake tasks. I knew that my teammates would have to know about Rake, and learn Rake conventions and such, so might as well build on that. Plus I like Rake; Jim has done a really good job. (BTW, if you ever get a chance to see him give a presentation, I lore you to watch. He's smart, funny, entertaining, and you'll learn stuff. Plus he juggles, which earns Cool Geek points in my book.) > > >>So: What's the elevator pitch for Reap? > > > Well, first understand Reap's core intent is like that of Meta Project > (if you've heard of that project) --a project assitant that makes it > easy to do many of the common chores. For instance Reap makes it > pretty easy to generate .tar.gz, .gem and .deb packages in one fell > swoop. Another intersting task is it's ability to extract unit tests > from source comments. Ah, I've not seen that. Very slick. > It also has a testing task that has very nice > output and isolates each test in it's own process. And it will release > to Rubyforge right easy too. Plus others. So that's one thing. Like I > said the ability to create cusotm tasks simply evolved out the > dedicated tasks I was building, and it's still evolving, but wan't the > original intent. > > But the main thing that really sets Reap apart is the ProjectInfo > file. It's a YAML file that describes the project and how things need > to be handled for it. In this way there's a single resource for all > this information that can reused by any task. And becuase it is pure > data and not Ruby code, that information is available in a very clear > and descernable way to any other tool, or human for that matter. > > Do check out the webpage (albiet still a bit rough). > > http://reap.rubyforge.org > Thanks, will do. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://yourelevatorpitch.com - Finding Business Focus From zimba.tm at gmail.com Tue Apr 25 11:38:08 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 25 Apr 2006 17:38:08 +0200 Subject: [Nitro] General inquiry about Reap In-Reply-To: <444E298A.2080403@neurogami.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> <444E298A.2080403@neurogami.com> Message-ID: IMHO the ProjectInfo dependency is too tight for some problems. Rdoc generation (taking from your example), should also be callable outside of a project with custom attributes. ProjectInfo fits really well for common tasks like tests, doc generation, publishing. But refactoring or others should be callable with simple arguments. I think rake is superior in that because it provides more flexibility. If you can manage to do both then everybody should be happy. Isn't it ? Cheers, zimbatm From zimba.tm at gmail.com Tue Apr 25 11:47:57 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 25 Apr 2006 17:47:57 +0200 Subject: [Nitro] devlab's glycerin RDoc In-Reply-To: References: Message-ID: <8813DE45-1B80-4F70-ACAE-1474FA9CDCBE@gmail.com> Hi Fabian, If somebody wants to help, it would be nice to indicate me how to ignore _darcs in rake. Or i could switch to reap :-p Here is my rake task : require 'rake/rdoctask' require 'rake/testtask' # Default task task :default => :rdoc Rake::RDocTask.new do |rd| rd.main = 'etc/RDOC' rd.rdoc_dir = 'htdocs/rdoc/nitrohq' rd.rdoc_files.include('nitrohq/*/lib/**/*.rb') end # * Jonas Pfenniger Le 25 avr. 06 ? 12:26, Fabian Buch a ?crit : > suggestion for http://devlab.oree.ch/rdoc/nitrohq/: I think it'd be > nicer and more usable if _darcs would be excluded (-x _darcs) and a > main page set (-m) (maybe nitro/README ?) > > Fabian > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From fabian at oggu.de Tue Apr 25 12:34:14 2006 From: fabian at oggu.de (Fabian Buch) Date: Tue, 25 Apr 2006 18:34:14 +0200 Subject: [Nitro] devlab's glycerin RDoc In-Reply-To: <8813DE45-1B80-4F70-ACAE-1474FA9CDCBE@gmail.com> References: <8813DE45-1B80-4F70-ACAE-1474FA9CDCBE@gmail.com> Message-ID: Am 25.04.2006 um 17:47 schrieb Jonas Pfenniger: > Hi Fabian, > > If somebody wants to help, it would be nice to indicate me how to > ignore _darcs in rake. Or i could switch to reap :-p > > Here is my rake task : > > require 'rake/rdoctask' > require 'rake/testtask' > > # Default task > > task :default => :rdoc > > Rake::RDocTask.new do |rd| > rd.main = 'etc/RDOC' > rd.rdoc_dir = 'htdocs/rdoc/nitrohq' > rd.rdoc_files.include('nitrohq/*/lib/**/*.rb') > end > > # * Jonas Pfenniger I know nothing about Rake, but quick googling: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/164567 http://dev.rubyonrails.org/svn/rails/trunk/activerecord/Rakefile So, as expected rdoc_files.exclude: rdoc.rdoc_files.exclude('lib/active_record/vendor/*') or rdoc.rdoc_files.exclude('_darcs/**/*.rb') Fabian From zimba.tm at gmail.com Tue Apr 25 13:20:58 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 25 Apr 2006 19:20:58 +0200 Subject: [Nitro] devlab's glycerin RDoc In-Reply-To: References: <8813DE45-1B80-4F70-ACAE-1474FA9CDCBE@gmail.com> Message-ID: <97C703E5-BDD5-4715-8268-8BF91B171DDD@gmail.com> Thanks, I'm a bit lazy some times :-p It should be better now Le 25 avr. 06 ? 18:34, Fabian Buch a ?crit : > rdoc.rdoc_files.exclude('_darcs/**/*.rb') -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060425/a529406e/attachment.html From transfire at gmail.com Tue Apr 25 14:33:45 2006 From: transfire at gmail.com (TRANS) Date: Tue, 25 Apr 2006 14:33:45 -0400 Subject: [Nitro] General inquiry about Reap In-Reply-To: References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> <444E298A.2080403@neurogami.com> Message-ID: <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> On 4/25/06, Jonas Pfenniger wrote: > IMHO the ProjectInfo dependency is too tight for some problems. Rdoc > generation (taking from your example), should also be callable > outside of a project with custom attributes. > > ProjectInfo fits really well for common tasks like tests, doc > generation, publishing. But refactoring or others should be callable > with simple arguments. I think rake is superior in that because it > provides more flexibility. If you can manage to do both then > everybody should be happy. Isn't it ? I may be able to work something in for that, but I wonder to what extent it is really useful. You can change the rdoc 'options' attribute in the ProjectInfo file to make it work basically any way you could from the command line. So the difference is just being callable from outside the project and with custom attributes passed on the command line. Is that right? The former I don't know how that could work (can you even do that with Rake?) Won't you still have to specify the project directory somehow, so isn't something like the following essentially the same: cd myproject/path; reap rdoc; cd ../.. Even so I could of course add a flag for the project directory --and see no reaosn not to. So I'll do that. Thanks! As for the later parameters, I can see how that might be useful, but only rarely. while there's surely some way to accept command line parameters for it, I tend to think it would be easier just to edit the ProjectInfo file. Am I missing something in this respect? Perhaps just being able to create variant specification in the ProjectInfo and being able to call them by name would help? Your and James' input is helping lots, T. From transfire at gmail.com Tue Apr 25 14:57:08 2006 From: transfire at gmail.com (TRANS) Date: Tue, 25 Apr 2006 14:57:08 -0400 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> <444E298A.2080403@neurogami.com> <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> Message-ID: <4b6f054f0604251157y7cb279e8y5ed6655d26aa27fe@mail.gmail.com> One thing I hate about Rake though, is the default task. I think that's kind of dangerous, and worses I hate having to use -T to look at the tasks. T. From zimba.tm at gmail.com Tue Apr 25 15:07:20 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 25 Apr 2006 21:07:20 +0200 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> <444E298A.2080403@neurogami.com> <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> Message-ID: <26923556-7B66-43BC-B2FB-74A60B2379D9@gmail.com> Le 25 avr. 06 ? 20:33, TRANS a ?crit : > > I may be able to work something in for that, but I wonder to what > extent it is really useful. You can change the rdoc 'options' > attribute in the ProjectInfo file to make it work basically any way > you could from the command line. So the difference is just being > callable from outside the project and with custom attributes passed on > the command line. Is that right? The former I don't know how that > could work (can you even do that with Rake?) Won't you still have to > specify the project directory somehow, so isn't something like the > following essentially the same: > > cd myproject/path; reap rdoc; cd ../.. I don't know how exactly works ProjectInfo but why not use it to set default values to tasks ? Imagine the rdoc task requires a source parameter. If ProjectInfo contains rdoc[:source], it would be used by the reap task. Otherwise, reap would ask for the source option. (cf: Glue's configuration) > Even so I could of course add a flag for the project directory --and > see no reaosn not to. So I'll do that. Thanks! Yes this is a good idea. > > As for the later parameters, I can see how that might be useful, but > only rarely. while there's surely some way to accept command line > parameters for it, I tend to think it would be easier just to edit the > ProjectInfo file. Am I missing something in this respect? Perhaps > just being able to create variant specification in the ProjectInfo and > being able to call them by name would help? Yes as project directory, a reap config parameter can be useful. I just hope it won't add too many lines of code. Concerning Gem autoload. A quick google search showed me that you can tell a gem to autorequire a file. As I understood, you can build gems in a way that they will automatically require a gem when 'rubygem' is required. I don't know how it works with multiple versions of the same gem altrough. This means that Gems could autorequire rake tasks so that they are loaded in the namespace. You then could use the ObjectSpace browsing method to look for available tasks. Concerning standard ruby intalls, the RUBYOPT env variable could be used to attain the same effect. Or is there an autorequire feature also available in standard ruby libs ? Cheers, zimbatm From zimba.tm at gmail.com Tue Apr 25 15:08:09 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Tue, 25 Apr 2006 21:08:09 +0200 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604251157y7cb279e8y5ed6655d26aa27fe@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> <444D9EFC.70004@neurogami.com> <4b6f054f0604242134p39bec911w8725c81fec99ddcb@mail.gmail.com> <444E298A.2080403@neurogami.com> <4b6f054f0604251133k8a77475ub8d8e7de6f691e9f@mail.gmail.com> <4b6f054f0604251157y7cb279e8y5ed6655d26aa27fe@mail.gmail.com> Message-ID: +1 Le 25 avr. 06 ? 20:57, TRANS a ?crit : > One thing I hate about Rake though, is the default task. I think > that's kind of dangerous, and worses I hate having to use -T to look > at the tasks. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From bryan.a.soto at gmail.com Tue Apr 25 15:26:26 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 25 Apr 2006 12:26:26 -0700 Subject: [Nitro] Better diagnostics for gen In-Reply-To: References: Message-ID: Welcome Gabriele, On 4/25/06, gabriele renzi wrote: > Maybe there could be a more explanative message, i.e. > > begin > path="gen/#{generator}/gen.rb" > require path > rescue LoadError =>e > if e.message[/#{path}$/] > reason= %{\tno such generator "#{generator}"} > else > reason= %{\tunmet dependency loading "#{path}":\n\t#{e.message}} > end > puts "Cannot load the specified generator!" > puts reason > exit 1 > end > That does seem nicer. The load error messages from gems can be rather unhelpful. Is this what you used to debug your friends problem? Just want to know how much of a beating to give it for testing purposes. :) > I think spitting out the available generators is not meaningful as of > now, but if Brian's suggestion of model/scaffold generators is going to > be applied I think it would be nice to also show the list in the first > case. > That's a nice idea too. If/when we get any more generators. Thanks, Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Tue Apr 25 15:46:46 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Tue, 25 Apr 2006 12:46:46 -0700 Subject: [Nitro] General inquiry about Reap In-Reply-To: <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> References: <4b6f054f0604241835i533f227x22f69beb3b0797b6@mail.gmail.com> <4b6f054f0604241836jbfd03dfr37e0881846971e4d@mail.gmail.com> Message-ID: On 4/24/06, TRANS wrote: > Anyhow those are some of my thoughts. Sorry for going on so long. Was > wondering what others think about this and Reap in gerneral. > Actually, one of the things that came to mind when George did that test script was can you have ProjectInfo files that reference other ProjectInfo files (Composite of GOF fame). Taking Nitro as an example, nitro, og and glue would have their own ProjectInfo files with a top-level ProjectInfo: /ProjectInfo /glue/ProjectInfo /nitro/ProjectInfo /og/ProjectInfo So within the og subdirectory, reap test would run the og test suite, /og $ reap test # runs og tests while at the top level / $ reap test could execute whatever tasks are defined for test in the top level projectinfo file, or as a default, search for ProjectInfos in subdirectories and see if they have test sections defined. Of course, Reap might do this currently. I've found that the time I used to have to investigate projects that interested me has decreased dramatically since getting involved with Nitro, so my apologies if that's the case. Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From surrender_it at yahoo.it Tue Apr 25 16:12:33 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Tue, 25 Apr 2006 22:12:33 +0200 Subject: [Nitro] Better diagnostics for gen In-Reply-To: References: Message-ID: Bryan Soto ha scritto: > That does seem nicer. The load error messages from gems can be rather > unhelpful. Is this what you used to debug your friends problem? well, no, I just commented out the rescue.. Anyway this was just a suggestion and this is the reason I've not provided it as a patch+tests, but it /seem/ to work with the sources from repo.nitroproject.org: $ ruby gen/bin/gen app foo Cannot load the specified generator! unmet dependency loading gen/app/gen.rb: Could not find RubyGem facets (= 1.0.3) $ gem install facets $ruby gen/bin/gen app NAME gen app - Nitro application generator. $ ruby gen/bin/gen ap Cannot load the specified generator! no such generator "ap" and withouth -rubygems $ ruby gen/bin/gen app Cannot load the specified generator! unmet dependency loading gen/app/gen.rb: no such file to load -- facet/dir/self/recurse > Just > want to know how much of a beating to give it for testing purposes. :) Oh, please be hard with it, I just quickly tested on a win32 box, which is Evil(TM) From aglarond at gmail.com Wed Apr 26 04:49:55 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Wed, 26 Apr 2006 10:49:55 +0200 Subject: [Nitro] [PATCH] xhtml helper Message-ID: <55c107bf0604260149i343a3380q2ea0226a23b6f744@mail.gmail.com> just a small change to the xhtml helper, to make sure that the comparison is done correctly. Note: no actual patch is included because it is a trivial change. http://devlab.oree.ch/trac/nitrohq/ticket/34: line 54 of lib/nitro/helper/xhtml.rb (version 0.29.0) line 78 of lib/nitro/helper/xhtml.rb (current repo) if value == selected should be if value.to_i == selected because 'selected' has .to_i done to it earlier. Let me know if I should make an actual patch for this, and I'll send it later today. - Dimitri From zimba.tm at gmail.com Wed Apr 26 07:21:33 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Wed, 26 Apr 2006 13:21:33 +0200 Subject: [Nitro] Repo splitup ? Message-ID: Hi list, Hmm, what do you think of splitting the repo ? What is the state of Glue -> Facets migration ? I suggest that if the migration is done, we could make a release and the splitup the repo. What do you think ? Cheers, zimbatm From george.moschovitis at gmail.com Wed Apr 26 10:01:00 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 26 Apr 2006 17:01:00 +0300 Subject: [Nitro] Happy Name Day George! In-Reply-To: <0fe501c667c0$aca034c0$6442a8c0@musicbox> References: <4b6f054f0604240901q883bbc6vb60793a7cebec059@mail.gmail.com> <0fe501c667c0$aca034c0$6442a8c0@musicbox> Message-ID: Thanks ;-) > > Happy name day! -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 26 10:17:32 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 26 Apr 2006 17:17:32 +0300 Subject: [Nitro] [PATCH] Some more changes/fixes from me ;-) In-Reply-To: References: Message-ID: Thanks... I will try to sync again and post a new bundle later... -g. On 4/25/06, Bryan Soto wrote: > They've all been applied. > > On 4/24/06, Bryan Soto wrote: > > I have about six left, which I'll take care of tomorrow. > > > > On 4/23/06, Bryan Soto wrote: > > > These will require a little more work. You had included an older > > > version of Oggu's feed helper, so I had to apply to a temp repo and > > > send from there. > > > > > > You might want to unpull that before pulling from the repo. I don't > > > know if you'll get conflicts... > > > > > > On 4/23/06, George Moschovitis wrote: > > > > Here comes one more patch... > > > > > > > > -g. > > > > > > > > -- > > > > http://www.gmosx.com > > > > http://www.navel.gr > > > > http://www.nitrohq.com > > > > > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > > > > > > > > > -- > > > "Never tell people how to do things. Tell them what to do and they > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Wed Apr 26 10:27:51 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 26 Apr 2006 17:27:51 +0300 Subject: [Nitro] Repo splitup ? In-Reply-To: References: Message-ID: Hello, I want to have ready the new code for nitroproject.com before the release of 0.30.0 Hopefully both will be ready in the beginning of next week. Then if more people think we should spilt the repos' we could try it. -g. On 4/26/06, Jonas Pfenniger wrote: > Hi list, > > Hmm, what do you think of splitting the repo ? > > What is the state of Glue -> Facets migration ? > > I suggest that if the migration is done, we could make a release and > the splitup the repo. > > What do you think ? > > Cheers, > zimbatm > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From nissl at tiscali.it Wed Apr 26 13:06:34 2006 From: nissl at tiscali.it (Massimo Maria Ghisalberti) Date: Wed, 26 Apr 2006 19:06:34 +0200 Subject: [Nitro] Compiler::compile_action ... Message-ID: <1146071194.18851.13.camel@nissl.mammuth> in a previous post I've made some investigation on this method for parameters error in Ajax request... sorry, but I don't understend why this line: # Concatenate some extracted parameters. params.concat(context.params.values) in some testing with uri in this form: http://localhost:9999/test3?val1=xxx&val2=yyy and: http://localhost:9999/test3/xxx/yyy this line is problematic. with the first I've this error: wrong number of arguments (4 for 2) because params already is ["xxx", "yyy"] and after the concat ["xxx", "yyy", "xxx", "yyy"], only with the second uri is fine (context.params.values is empty). In which case this line is useful? -- Massimo Maria Ghisalberti From bryan.a.soto at gmail.com Wed Apr 26 13:40:22 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 26 Apr 2006 10:40:22 -0700 Subject: [Nitro] [PATCH] xhtml helper In-Reply-To: <55c107bf0604260149i343a3380q2ea0226a23b6f744@mail.gmail.com> References: <55c107bf0604260149i343a3380q2ea0226a23b6f744@mail.gmail.com> Message-ID: That's all right, I'll take care of it. Thanks. On 4/26/06, Dimitri Aivaliotis wrote: > just a small change to the xhtml helper, to make sure that the > comparison is done correctly. > > Note: no actual patch is included because it is a trivial change. > > http://devlab.oree.ch/trac/nitrohq/ticket/34: > > line 54 of lib/nitro/helper/xhtml.rb (version 0.29.0) > > line 78 of lib/nitro/helper/xhtml.rb (current repo) > > if value == selected > > should be > > if value.to_i == selected > > because 'selected' has .to_i done to it earlier. > > > Let me know if I should make an actual patch for this, and I'll send > it later today. > > - Dimitri > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Wed Apr 26 13:53:58 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 26 Apr 2006 10:53:58 -0700 Subject: [Nitro] Compiler::compile_action ... In-Reply-To: <1146071194.18851.13.camel@nissl.mammuth> References: <1146071194.18851.13.camel@nissl.mammuth> Message-ID: On 4/26/06, Massimo Maria Ghisalberti wrote: > # Concatenate some extracted parameters. > params.concat(context.params.values) > > In which case this line is useful? > I was hoping George would explain why he made that change. Perhaps he missed the earlier thread, so it was a good idea to start a new one. In the mean time, I'm going to consider that a bug, remove that line and see how the tests do without it. If there aren't any additional failures, I'll apply that change to the repo. If there are, maybe I'll be able to figure out why it's there. Thanks. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From surrender_it at yahoo.it Wed Apr 26 15:49:19 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Wed, 26 Apr 2006 21:49:19 +0200 Subject: [Nitro] Question about error handling in *Store Message-ID: Hi people, I notice that all the Og::Store subclasses are defined in files with an header similar to begin require 'sqlite' rescue Object => ex Logger.error 'Ruby-Sqlite bindings are not installed!' Logger.error ex end There are two things I found strange in this, first, it seems excessive to hide all possible exceptions by rescueing Object, I think that LoadError would be a better fit; second, I 'm not sure I undesrtand why the problem is just logged instead of letting the application crash, because in most cases there will be a crash whenever something is done that is store related, by referencing a a nil object. It seem to me that this is a bad thing and that a crash-early approach would be better and allow faster diagnostics, but maybe there is something I have overlooked. Someone who would like to still use the application withouth having a real reference to a Store could just create an empty foo.rb in src/ and go on anyway. From bryan.a.soto at gmail.com Wed Apr 26 16:18:12 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 26 Apr 2006 13:18:12 -0700 Subject: [Nitro] Question about error handling in *Store In-Reply-To: References: Message-ID: On 4/26/06, gabriele renzi wrote: > Hi people, > > I notice that all the Og::Store subclasses are defined in files with an > header similar to > > begin > require 'sqlite' > rescue Object => ex > Logger.error 'Ruby-Sqlite bindings are not installed!' > Logger.error ex > end > $ grep -R 'rescue Object' nitro/* glue/* og/* gen/* nitro/lib/glue/sweeper.rb: rescue Object nitro/lib/nitro/compiler/script.rb: rescue Object nitro/lib/nitro/helper/debug.rb: rescue Object nitro/lib/nitro/adapter/mongrel.rb: rescue Object => ex nitro/lib/nitro/adapter/scgi.rb: rescue Object nitro/lib/nitro/adapter/scgi.rb: rescue Object nitro/lib/nitro/adapter/webrick.rb: rescue Object => ex nitro/lib/nitro/adapter/webrick.rb: rescue Object => ex nitro/lib/nitro/caching/output.rb: rescue Object => ex nitro/lib/nitro/helper.rb: rescue Object nitro/proto/script/scgi_service: rescue Object => nitro_error nitro/proto/script/scgi_ctl: rescue Object nitro/test/nitro/tc_session.rb: rescue Object # Errno::EBADF => e glue/lib/glue/configuration.rb: rescue Object glue/lib/glue/mailer/outgoing.rb: rescue Object => e og/lib/og/store/sqlite2.rb:rescue Object => ex og/lib/og/store/sqlite2.rb: rescue Object og/lib/og/store/sqlite2.rb: rescue Object => ex og/lib/og/store/sqlite2.rb: rescue Object => ex og/lib/og/store/alpha/sqlserver.rb:rescue Object => ex og/lib/og/store/kirby.rb:rescue Object => ex og/lib/og/store/kirby.rb: rescue Object og/lib/og/store/sqlite.rb:rescue Object => ex og/lib/og/store/sqlite.rb: rescue Object og/lib/og/store/sqlite.rb: rescue Object => ex og/lib/og/store/mysql.rb:rescue Object => ex og/lib/og/store/mysql.rb: rescue Object => ex og/lib/og/store/psql.rb:rescue Object => ex og/test/og/tc_cacheable.rb:rescue Object It's a general tendency of George's. I can confirm this as my original capture of Errno::EBADF here was changed. nitro/test/nitro/tc_session.rb: rescue Object # Errno::EBADF => e > There are two things I found strange in this, first, it seems excessive > to hide all possible exceptions by rescueing Object, I think that > LoadError would be a better fit; second, I 'm not sure I undesrtand why > the problem is just logged instead of letting the application crash, > because in most cases there will be a crash whenever something is done > that is store related, by referencing a a nil object. > Personally, I tend to agree that exception handling should be as specific as possible. Differing philosophies, I suppose. But you make a very good point on the stores I think. > It seem to me that this is a bad thing and that a crash-early approach > would be better and allow faster diagnostics, but maybe there is > something I have overlooked. Anyone have any objections to changing this? Seems to be a bug to me. > Someone who would like to still use the application withouth having a > real reference to a Store could just create an empty foo.rb in src/ and > go on anyway. > That is equivalent to what we're currently doing, isn't it. :) Bryan -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From transfire at gmail.com Wed Apr 26 18:24:47 2006 From: transfire at gmail.com (TRANS) Date: Wed, 26 Apr 2006 18:24:47 -0400 Subject: [Nitro] Repo splitup ? In-Reply-To: References: Message-ID: <4b6f054f0604261524mcc4821aubc3ab5213fac352f@mail.gmail.com> On 4/26/06, George Moschovitis wrote: > Hello, > > I want to have ready the new code for nitroproject.com before the > release of 0.30.0 > Hopefully both will be ready in the beginning of next week. > > Then if more people think we should spilt the repos' we could try it. Good SOC of the model, view and controller (done well or course) should prove quite a flexible and powerful platform. T. From m.fellinger at gmail.com Thu Apr 27 00:15:53 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 27 Apr 2006 13:15:53 +0900 Subject: [Nitro] [PATCH] xhtml helper In-Reply-To: References: <55c107bf0604260149i343a3380q2ea0226a23b6f744@mail.gmail.com> Message-ID: <9c00d3e00604262115i2bfed643k42fc2284a755cf50@mail.gmail.com> to be honest, i don't use the select-helper but wrote my own because you can't just have strings as values, or URLs with a javascript that redirects you :) have a look here... On 4/27/06, Bryan Soto wrote: > That's all right, I'll take care of it. > > Thanks. > > On 4/26/06, Dimitri Aivaliotis wrote: > > just a small change to the xhtml helper, to make sure that the > > comparison is done correctly. > > > > Note: no actual patch is included because it is a trivial change. > > > > http://devlab.oree.ch/trac/nitrohq/ticket/34: > > > > line 54 of lib/nitro/helper/xhtml.rb (version 0.29.0) > > > > line 78 of lib/nitro/helper/xhtml.rb (current repo) > > > > if value == selected > > > > should be > > > > if value.to_i == selected > > > > because 'selected' has .to_i done to it earlier. > > > > > > Let me know if I should make an actual patch for this, and I'll send > > it later today. > > > > - Dimitri > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > "Never tell people how to do things. Tell them what to do and they > will surprise you with their ingenuity." ?General George S. Patton > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- A non-text attachment was scrubbed... Name: form_select.rb.tar.gz Type: application/x-gzip Size: 696 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060427/7d4f53b2/attachment.gz From bryan.a.soto at gmail.com Thu Apr 27 01:50:48 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 26 Apr 2006 22:50:48 -0700 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: <200604201619.35203.manveru@weez.co.jp> References: <200604171826.51234.manveru@weez.co.jp> <200604201619.35203.manveru@weez.co.jp> Message-ID: On 4/20/06, Michael Fellinger wrote: > Sorry, the testcase was not really helping... i wanted to reproduce a bug but > that only shows up with schema_inheritance and EZ. > so if you have something like: > > class Person > property :name, String > property :kids, Integer > schema_inheritance > end > > class Musician < Person > property :instruments, Array > end > > class Plumber < Person > property :tools, Array > end > > Musician.find{|m| m.kids === [3,4,5]} > Just to be sure, this is the error your patch is supposed to fix, right? I, [2006-04-26T22:26:02.070000 #4452] INFO -- : Og uses the Sqlite store. I, [2006-04-26T22:26:05.836000 #4452] INFO -- : Created table 'ogperson'. k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `+': can't convert String into Array (TypeError) from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `update_condition' from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1027:in `resolve_options' from k:/devlab/nitrohq/og/lib/og/store/sql.rb:465:in `find' from k:/devlab/nitrohq/og/lib/og/entity.rb:191:in `find' from manveru-ez-test.rb:23 -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From aglarond at gmail.com Thu Apr 27 02:39:21 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Thu, 27 Apr 2006 08:39:21 +0200 Subject: [Nitro] [PATCH] xhtml helper In-Reply-To: <9c00d3e00604262115i2bfed643k42fc2284a755cf50@mail.gmail.com> References: <55c107bf0604260149i343a3380q2ea0226a23b6f744@mail.gmail.com> <9c00d3e00604262115i2bfed643k42fc2284a755cf50@mail.gmail.com> Message-ID: <55c107bf0604262339y605e8e10of46338c6393035b8@mail.gmail.com> On 4/27/06, Michael Fellinger wrote: > to be honest, i don't use the select-helper but wrote my own because > you can't just have strings as values, or URLs with a javascript that > redirects you :) > > have a look here... looks interesting... - Dimitri From bryan.a.soto at gmail.com Thu Apr 27 02:48:40 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Wed, 26 Apr 2006 23:48:40 -0700 Subject: [Nitro] [PATCH] small fix for EZ (===) In-Reply-To: References: <200604201825.06107.manveru@weez.co.jp> Message-ID: Rather than: options[:condition] = options[:condition].shift.gsub('(?*)', "(#{options[:condition].pop.join(',')})") what do you think of: [options[:condition]].flatten[0] << " #{joiner} #{cond}" It seems more straight forward to me... -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 27 03:09:12 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 27 Apr 2006 00:09:12 -0700 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: <200604201620.54161.manveru@weez.co.jp> References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <200604201451.50541.manveru@weez.co.jp> <200604201620.54161.manveru@weez.co.jp> Message-ID: I was going to do this one, but I noticed that your patch doesn't match spark. So which is "the Nitro way" to layout an app? Or is the fact that they don't match the point? :) Any opinions on where the template directory should be? Spark has them under src (spark/src/template) and Flare has them at the root (flare/template). Should we standardize on one way? Bryan On 4/20/06, Michael Fellinger wrote: > I certainly checked that the files are added... however, since i'm not that > familiar with darcs it might have gone wrong despite of my effort :( > Could you please fix it for me, just moving the directory from 'template' > to 'templates' > > On Thursday 20 April 2006 15:31, Bryan Soto wrote: > > Nah, templates is empty after the patch is applied. Do you want me to fix > > that? > > > > On 4/19/06, Michael Fellinger wrote: > > > That was the plan. > > > Doesn't it do that? > > > > > > On Thursday 20 April 2006 14:38, Bryan Soto wrote: > > > > Hey manveru, this seems to delete all the templates when applied. > > > > Shouldn't it move them to the new templates directory? > > > > > > > > On 4/18/06, Bryan Soto wrote: > > > > > Just wanted to find out. We'll see if it still applies. Thanks. :) > > > > > > > > > > On 4/18/06, Michael Fellinger wrote: > > > > > > Yeah, it never got applied afaik... > > > > > > On 4/19/06, Bryan Soto wrote:> Manveru, > > > > > > was this the patch you mentioned on #nitro?>> On 3/3/06, Michael > > > > > > Fellinger wrote:> > Hello List,> >> > I > > > > > > just made a bundle that makes the template-root for flare more> > > > > > > > standard, moving it from /template to /templates and adding a> > > > > > > > Template.root = "templates" in the run.rb> > I could have left this > > > > > > one out since it's the standard, but i'd rather> > go sure...> >> > > > > > > > ~~~~manveru> >> > _______________________________________________> > > > > > > > Nitro-general mailing list> > Nitro-general at rubyforge.org> > > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> --> > > > > > > "Never tell people how to do things. Tell them what to do and they> > > > > > > will surprise you with their ingenuity." ?General George S. > > > > > > Patton>> _______________________________________________> > > > > > > Nitro-general mailing list> Nitro-general at rubyforge.org> > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > > > > > _______________________________________________ > > > > > > Nitro-general mailing list > > > > > > Nitro-general at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > -- > > > > > "Never tell people how to do things. Tell them what to do and they > > > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > > > -- > > > > "Never tell people how to do things. Tell them what to do and they > > > > will surprise you with their ingenuity." ?General George S. Patton > > > > > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > > "Never tell people how to do things. Tell them what to do and they > > will surprise you with their ingenuity." ?General George S. Patton > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From surrender_it at yahoo.it Thu Apr 27 03:18:29 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Thu, 27 Apr 2006 09:18:29 +0200 Subject: [Nitro] Question about error handling in *Store In-Reply-To: References: Message-ID: Bryan Soto ha scritto: >>Someone who would like to still use the application withouth having a >>real reference to a Store could just create an empty foo.rb in src/ and >>go on anyway. >> > > > That is equivalent to what we're currently doing, isn't it. :) well, yes, but it becomes an explicit choice of the developer and not an hidden thing. George could you please comment on this and on the general "large rescue" thing? thanks bryan for the quick answers anyway :) From zimba.tm at gmail.com Thu Apr 27 03:50:33 2006 From: zimba.tm at gmail.com (Jonas Pfenniger) Date: Thu, 27 Apr 2006 09:50:33 +0200 Subject: [Nitro] Repo splitup ? In-Reply-To: References: Message-ID: Ok, I just would like to add that like TRANS said, i think SOC is a general good idea. When the separate templating system will be done, we'll have 3 projects. One for each part of the MVC architecture. Model : Og View : New templating system Controller : Nitro What's nice is to think that the Model and View could be changed to other systems. Cheers, zimbatm From m.fellinger at gmail.com Thu Apr 27 04:49:36 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 27 Apr 2006 17:49:36 +0900 Subject: [Nitro] [PATCH] Fixed the template-root for flare In-Reply-To: References: <9c00d3e00603030910j139e7967td0aa9b8fa8bdee3b@mail.gmail.com> <200604201451.50541.manveru@weez.co.jp> <200604201620.54161.manveru@weez.co.jp> Message-ID: <9c00d3e00604270149i3ad8c2bdw303041bb9d4b66a0@mail.gmail.com> i referenced to 'the nitro way' in terms of template-path-lookup, andthere the /templates directory has a fixed place - please correct meif i'm wrong. in the end it doesn't really matter, as long as the template-root isadded to the correct place On 4/27/06, Bryan Soto wrote:> I was going to do this one, but I noticed that your patch doesn't> match spark. So which is "the Nitro way" to layout an app? Or is the> fact that they don't match the point? :)>> Any opinions on where the template directory should be? Spark has them> under src (spark/src/template) and Flare has them at the root> (flare/template). Should we standardize on one way?>> Bryan>> On 4/20/06, Michael Fellinger wrote:> > I certainly checked that the files are added... however, since i'm not that> > familiar with darcs it might have gone wrong despite of my effort :(> > Could you please fix it for me, just moving the directory from 'template'> > to 'templates'> >> > On Thursday 20 April 2006 15:31, Bryan Soto wrote:> > > Nah, templates is empty after the patch is applied. Do you want me to fix> > > that?> > >> > > On 4/19/06, Michael Fellinger wrote:> > > > That was the plan.> > > > Doesn't it do that?> > > >> > > > On Thursday 20 April 2006 14:38, Bryan Soto wrote:> > > > > Hey manveru, this seems to delete all the templates when applied.> > > > > Shouldn't it move them to the new templates directory?> > > > >> > > > > On 4/18/06, Bryan Soto wrote:> > > > > > Just wanted to find out. We'll see if it still applies. Thanks. :)> > > > > >> > > > > > On 4/18/06, Michael Fellinger wrote:> > > > > > > Yeah, it never got applied afaik...> > > > > > > On 4/19/06, Bryan Soto wrote:> Manveru,> > > > > > > was this the patch you mentioned on #nitro?>> On 3/3/06, Michael> > > > > > > Fellinger wrote:> > Hello List,> >> > I> > > > > > > just made a bundle that makes the template-root for flare more> >> > > > > > > standard, moving it from /template to /templates and adding a> >> > > > > > > Template.root = "templates" in the run.rb> > I could have left this> > > > > > > one out since it's the standard, but i'd rather> > go sure...> >> >> > > > > > > ~~~~manveru> >> > _______________________________________________>> > > > > > > > Nitro-general mailing list> > Nitro-general at rubyforge.org> >> > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> >> >> >>>> -->> > > > > > > "Never tell people how to do things. Tell them what to do and they>> > > > > > > will surprise you with their ingenuity." ?General George S.> > > > > > > Patton>> _______________________________________________>> > > > > > > Nitro-general mailing list> Nitro-general at rubyforge.org>> > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general>> > > > > > > _______________________________________________> > > > > > > Nitro-general mailing list> > > > > > > Nitro-general at rubyforge.org> > > > > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > > > >> > > > > > --> > > > > > "Never tell people how to do things. Tell them what to do and they> > > > > > will surprise you with their ingenuity." ?General George S. Patton> > > > >> > > > > --> > > > > "Never tell people how to do things. Tell them what to do and they> > > > > will surprise you with their ingenuity." ?General George S. Patton> > > > >> > > > > _______________________________________________> > > > > Nitro-general mailing list> > > > > Nitro-general at rubyforge.org> > > > > http://rubyforge.org/mailman/listinfo/nitro-general> > > >> > > > _______________________________________________> > > > Nitro-general mailing list> > > > Nitro-general at rubyforge.org> > > > http://rubyforge.org/mailman/listinfo/nitro-general> > >> > > --> > > "Never tell people how to do things. Tell them what to do and they> > > will surprise you with their ingenuity." ?General George S. Patton> > >> > > _______________________________________________> > > Nitro-general mailing list> > > Nitro-general at rubyforge.org> > > http://rubyforge.org/mailman/listinfo/nitro-general> >> > _______________________________________________> > Nitro-general mailing list> > Nitro-general at rubyforge.org> > http://rubyforge.org/mailman/listinfo/nitro-general> >>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From m.fellinger at gmail.com Thu Apr 27 04:50:40 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 27 Apr 2006 17:50:40 +0900 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: References: <200604171826.51234.manveru@weez.co.jp> <200604201619.35203.manveru@weez.co.jp> Message-ID: <9c00d3e00604270150x75bcb14cr3ae7eabd80a6061d@mail.gmail.com> *nods in a frantical manner* that's it, that's it - KILL IT pleeease :) On 4/27/06, Bryan Soto wrote:> On 4/20/06, Michael Fellinger wrote:> > Sorry, the testcase was not really helping... i wanted to reproduce a bug but> > that only shows up with schema_inheritance and EZ.> > so if you have something like:> >> > class Person> > property :name, String> > property :kids, Integer> > schema_inheritance> > end> >> > class Musician < Person> > property :instruments, Array> > end> >> > class Plumber < Person> > property :tools, Array> > end> >> > Musician.find{|m| m.kids === [3,4,5]}> >>> Just to be sure, this is the error your patch is supposed to fix, right?>> I, [2006-04-26T22:26:02.070000 #4452] INFO -- : Og uses the Sqlite store.> I, [2006-04-26T22:26:05.836000 #4452] INFO -- : Created table 'ogperson'.> k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `+': can't convert String into> Array (TypeError)> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `update_condition'> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1027:in `resolve_options'> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:465:in `find'> from k:/devlab/nitrohq/og/lib/og/entity.rb:191:in `find'> from manveru-ez-test.rb:23>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From m.fellinger at gmail.com Thu Apr 27 04:53:28 2006 From: m.fellinger at gmail.com (Michael Fellinger) Date: Thu, 27 Apr 2006 17:53:28 +0900 Subject: [Nitro] [PATCH] small fix for EZ (===) In-Reply-To: References: <200604201825.06107.manveru@weez.co.jp> Message-ID: <9c00d3e00604270153i591d7993h1d9f02a68fd93a67@mail.gmail.com> whatever you like best, as long as it fixes the problem :) - and yes,my code sometimes look really weird... On 4/27/06, Bryan Soto wrote:> Rather than:>> options[:condition] = options[:condition].shift.gsub('(?*)',> "(#{options[:condition].pop.join(',')})")>> what do you think of:>> [options[:condition]].flatten[0] << " #{joiner} #{cond}">> It seems more straight forward to me...>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> From john at oxyliquit.de Thu Apr 27 04:53:28 2006 From: john at oxyliquit.de (john at oxyliquit.de) Date: Thu, 27 Apr 2006 10:53:28 +0200 Subject: [Nitro] problem with: facets-1.3.2-update and Tags Message-ID: <20060427085328.GA5943@oxyliquit.de> Hi Bryan, This patch: Tue Apr 25 07:46:29 CEST 2006 bryan.a.soto at gmail.com * facets-1.3.2-update Updates to facets 1.3.2 by removing the Glue namespace prefix from Nitro code. This seems to do more stuff than just removing prefixes. I had conflicts in psql.rb and sql.rb after resolving them and starting: E, [2006-04-26T13:55:31.672604 #6653] ERROR -- : Error while handling '/'. E, [2006-04-26T13:55:31.674394 #6653] ERROR -- : undefined method `getvalue' for # (eval):4:in `og_read' /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:1177:in `read_all' /Volumes/Data/build/cvs/nitro/og/lib/og/store/psql.rb:139:in `each_row' /Volumes/Data/build/cvs/nitro/og/lib/og/store/psql.rb:138:in `each_row' /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:1175:in `read_all' /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:470:in `find' /Volumes/Data/build/cvs/nitro/og/lib/og/entity.rb:191:in `find' ./src/controller.rb:21:in `index' (eval):6:in `index_action' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/controller.rb:93:in `method_missing' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/render.rb:129:in `render' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/adapter/webrick.rb:223:in `do_GET' /usr/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' /usr/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/local/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/local/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/local/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/local/lib/ruby/1.8/webrick/server.rb:82:in `start' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/adapter/webrick.rb:59:in `start' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server/runner.rb:344:in `invoke_server' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server/runner.rb:306:in `invoke' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server.rb:128:in `run' /Volumes/Data/build/cvs/nitro/nitro/lib/nitro.rb:78:in `run' ./run.rb:96 LOGGED FROM: /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/render.rb:249:in `log_error' D, [2006-04-26T13:55:31.701004 #6653] DEBUG -- : Rendering '/error'. I either seem to have a non standard patch (maybe psql refactoring from bsoto?), or something else is breaking. Don't know what's causing the issue.. I unpulled it for now. And another thing while I'm ranting: why removing the Tag from Glue again? -_- We agreed at the time, that having "Tag" in the global namespace isn't exactly a good idea. And moving something _temporarily_ is an even worse idea, right now I'm just not pulling that patch from George, I'm just waiting for it to move to Nitro or Og or something. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From bryan.a.soto at gmail.com Thu Apr 27 15:12:36 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 27 Apr 2006 12:12:36 -0700 Subject: [Nitro] problem with: facets-1.3.2-update and Tags In-Reply-To: <20060427085328.GA5943@oxyliquit.de> References: <20060427085328.GA5943@oxyliquit.de> Message-ID: On 4/27/06, john at oxyliquit.de wrote: > Hi Bryan, > > This patch: > > Tue Apr 25 07:46:29 CEST 2006 bryan.a.soto at gmail.com > * facets-1.3.2-update > Updates to facets 1.3.2 by removing the Glue namespace prefix from Nitro code. > > This seems to do more stuff than just removing prefixes. > > I had conflicts in psql.rb and sql.rb > Nope, but it does touch those two files. > after resolving them and starting: > > E, [2006-04-26T13:55:31.672604 #6653] ERROR -- : Error while handling '/'. > E, [2006-04-26T13:55:31.674394 #6653] ERROR -- : undefined method `getvalue' for # > (eval):4:in `og_read' > /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:1177:in `read_all' > /Volumes/Data/build/cvs/nitro/og/lib/og/store/psql.rb:139:in `each_row' > /Volumes/Data/build/cvs/nitro/og/lib/og/store/psql.rb:138:in `each_row' > /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:1175:in `read_all' > /Volumes/Data/build/cvs/nitro/og/lib/og/store/sql.rb:470:in `find' > /Volumes/Data/build/cvs/nitro/og/lib/og/entity.rb:191:in `find' > ./src/controller.rb:21:in `index' > (eval):6:in `index_action' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/controller.rb:93:in `method_missing' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/render.rb:129:in `render' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/adapter/webrick.rb:223:in `do_GET' > /usr/local/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `service' > /usr/local/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' > /usr/local/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' > /usr/local/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' > /usr/local/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' > /usr/local/lib/ruby/1.8/webrick/server.rb:95:in `start' > /usr/local/lib/ruby/1.8/webrick/server.rb:92:in `start' > /usr/local/lib/ruby/1.8/webrick/server.rb:23:in `start' > /usr/local/lib/ruby/1.8/webrick/server.rb:82:in `start' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/adapter/webrick.rb:59:in `start' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server/runner.rb:344:in `invoke_server' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server/runner.rb:306:in `invoke' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/server.rb:128:in `run' > /Volumes/Data/build/cvs/nitro/nitro/lib/nitro.rb:78:in `run' > ./run.rb:96 > LOGGED FROM: /Volumes/Data/build/cvs/nitro/nitro/lib/nitro/render.rb:249:in `log_error' > D, [2006-04-26T13:55:31.701004 #6653] DEBUG -- : Rendering '/error'. > > I either seem to have a non standard patch (maybe psql refactoring from bsoto?), > or something else is breaking. > That would be it. George requested I not apply it to the repo, though I've tried to convince him otherwise. Perhaps it would be best if you remove it since it's not approved. I believe if you run $ darcs unpull --patch=refactor you'd have a fairly easy time of tracking it down. After that, you should be able to sync up to glycerin again. > Don't know what's causing the issue.. I unpulled it for now. > > And another thing while I'm ranting: why removing the Tag from Glue again? -_- > We agreed at the time, that having "Tag" in the global namespace isn't exactly > a good idea. And moving something _temporarily_ is an even worse idea, right > now I'm just not pulling that patch from George, I'm just waiting for it to > move to Nitro or Og or something. > See http://rubyforge.org/pipermail/nitro-general/2006-April/003968.html for the thread. George, Fabian and I had a little discussion about the Tags part. That's a good point about polluting the global namespace. I had forgotten about that. > Kashia > > -- > Feel the love I'm just not feeling it right now. ;) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 27 15:25:00 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 27 Apr 2006 12:25:00 -0700 Subject: [Nitro] Question about error handling in *Store In-Reply-To: References: Message-ID: On 4/27/06, gabriele renzi wrote: > Bryan Soto ha scritto: > > >>Someone who would like to still use the application withouth having a > >>real reference to a Store could just create an empty foo.rb in src/ and > >>go on anyway. > >> > > > > > > That is equivalent to what we're currently doing, isn't it. :) > > well, yes, but it becomes an explicit choice of the developer and not an > hidden thing. > I'm sorry, what I meant was, when you describe it your way (creating an empty file) what we currently do sounds rather silly. :) -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From humberaquino at gmail.com Thu Apr 27 16:07:49 2006 From: humberaquino at gmail.com (Humber Aquino) Date: Thu, 27 Apr 2006 16:07:49 -0400 Subject: [Nitro] [Bug]? Only one test per test case? Message-ID: <37fd0c50604271307w40a5c930s402ffc00e4891ff6@mail.gmail.com> This configuration let me have just one test per test case. The User model model: class User property :name, String end The test case file: require 'test/unit' require 'glue/fixture' require 'og/test' require 'src/model/user' class TestCaseUser < Test::Unit::TestCase def setup @og = Og.setup( :destroy => true, :store => :mysql, :name => 'db_test', :user => 'dbuser', :password => 'dbpass' ) og_fixture User end def test_something assert_kind_of User, @some_user end end When i run this test i get this result: $ ruby test/tc_user.rb Loaded suite test/tc_user Started I, [2006-04-26T13:03:44.421900 #12824] INFO -- : Og uses the Mysql store. Database "db_test" dropped I, [2006-04-26T13:03:44.493233 #12824] INFO -- : Database 'db_test' not found! I, [2006-04-26T13:03:44.617892 #12824] INFO -- : Created table 'oguser'. . Finished in 0.218669 seconds. 1 tests, 1 assertions, 0 failures, 0 errors Thats ok. But when i add other test to this test case, for example: def test_something_else assert_equal @some_user.name, 'John Doe' end Tthe result is this one: $ ruby test/tc_user.rb Loaded suite test/tc_user Started I, [2006-04-26T13:05:48.496080 #12883] INFO -- : Og uses the Mysql store. Database "db_test" dropped I, [2006-04-26T13:05:48.581070 #12883] INFO -- : Database 'db_test' not found! I, [2006-04-26T13:05:48.694901 #12883] INFO -- : Created table 'oguser'. .I, [2006-04-26T13:05:48.711974 #12883] INFO -- : Og uses the Mysql store. Database "db_test" dropped I, [2006-04-26T13:05:48.754274 #12883] INFO -- : Database 'db_test' not found! E, [2006-04-26T13:05:48.838177 #12883] ERROR -- : DB error Table 'db_test.oguser' doesn't exist, [SELECT * FROM oguser WHERE name = 'John Doe'] E, [2006-04-26T13:05:48.838573 #12883] ERROR -- : /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/mysql.rb:166:in `query'/usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/mysql.rb:166:in `query' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:464:in `find_one' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:565:in `finder' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:461:in `method_missing' ./src/model/user.rb:28:in `validate' /usr/lib/ruby/gems/1.8/gems/glue-0.29.0/lib/glue/validation.rb:156:in `valid?' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:99:in `save' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/test/testcase.rb:46:in `og_fixture' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/test/testcase.rb:45:in `og_fixture' /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/test/testcase.rb:42:in `og_fixture' test/tc_user.rb:19:in `setup' /usr/lib/ruby/1.8/test/unit/testcase.rb:69:in `run' /usr/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run' /usr/lib/ruby/1.8/test/unit/testsuite.rb:31:in `run' /usr/lib/ruby/1.8/test/unit/testsuite.rb:32:in `run' /usr/lib/ruby/1.8/test/unit/testsuite.rb:31:in `run' /usr/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:44:in `run_suite' /usr/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:65:in `start_mediator' /usr/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:39:in `start' /usr/lib/ruby/1.8/test/unit/ui/testrunnerutilities.rb:27:in `run' /usr/lib/ruby/1.8/test/unit/autorunner.rb:200:in `run' /usr/lib/ruby/1.8/test/unit/autorunner.rb:13:in `run' /usr/lib/ruby/1.8/test/unit.rb:285 test/tc_user.rb:26 /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:883:in `handle_sql_exception': Og::StoreException (Og::StoreException) from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/mysql.rb:168:in `query' from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store/sql.rb:464:in `find_one' from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:565:in `finder' from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:461:in `method_missing' from ./src/model/user.rb:28:in `validate' from /usr/lib/ruby/gems/1.8/gems/glue-0.29.0/lib/glue/validation.rb:156:in `valid?' from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/store.rb:99:in `save' from /usr/lib/ruby/gems/1.8/gems/og-0.29.0/lib/og/entity.rb:32:in `save' ... 13 levels... from /usr/lib/ruby/1.8/test/unit/autorunner.rb:200:in `run' from /usr/lib/ruby/1.8/test/unit/autorunner.rb:13:in `run' from /usr/lib/ruby/1.8/test/unit.rb:285 from test/tc_user.rb:26 I looks like Og setup runs correctly only once. then it doesn't create the db structure again. How can i fix this? am i missing somethig? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060427/7c07311f/attachment.html From james_b at neurogami.com Thu Apr 27 16:49:15 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 27 Apr 2006 13:49:15 -0700 Subject: [Nitro] Google SoC Projects Message-ID: <44512E4B.4000301@neurogami.com> I don't know who here also follows the ruby-talk list, but David A. Black has put out a "last call" post for Google Summer of Code projects and mentors. If you're got ideas, you'll need to get in touch with him to see about registering. -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys http://www.30secondrule.com - Building Better Tools From bryan.a.soto at gmail.com Thu Apr 27 18:34:01 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 27 Apr 2006 15:34:01 -0700 Subject: [Nitro] [TC] EZ an arrays again... In-Reply-To: <9c00d3e00604270150x75bcb14cr3ae7eabd80a6061d@mail.gmail.com> References: <200604171826.51234.manveru@weez.co.jp> <200604201619.35203.manveru@weez.co.jp> <9c00d3e00604270150x75bcb14cr3ae7eabd80a6061d@mail.gmail.com> Message-ID: Tis dead. Thanks for the report. :) On 4/27/06, Michael Fellinger wrote: > *nods in a frantical manner* that's it, that's it - KILL IT pleeease :) > On 4/27/06, Bryan Soto wrote:> On 4/20/06, Michael Fellinger wrote:> > Sorry, the testcase was not really helping... i wanted to reproduce a bug but> > that only shows up with schema_inheritance and EZ.> > so if you have something like:> >> > class Person> > property :name, String> > property :kids, Integer> > schema_inheritance> > end> >> > class Musician < Person> > property :instruments, Array> > end> >> > class Plumber < Person> > property :tools, Array> > end> >> > Musician.find{|m| m.kids === [3,4,5]}> >>> Just to be sure, this is the error your patch is supposed to fix, right?>> I, [2006-04-26T22:26:02.070000 #4452] INFO -- : Og uses the Sqlite store.> I, [2006-04-26T22:26:05.836000 #4452] INFO -- : Created table 'ogperson'.> k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `+': can't convert String into> Array (TypeError)> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1182:in `update_condition'> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:1027:in `resolve_options'> from k:/devlab/nitrohq/og/lib/og/store/sql.rb:465:in `find'> from k:/devlab/nitrohq/og/lib/og/entity.rb:191:in `find'> from manveru-ez-test.rb:23>>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From bryan.a.soto at gmail.com Thu Apr 27 18:34:52 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Thu, 27 Apr 2006 15:34:52 -0700 Subject: [Nitro] [PATCH] small fix for EZ (===) In-Reply-To: <9c00d3e00604270153i591d7993h1d9f02a68fd93a67@mail.gmail.com> References: <200604201825.06107.manveru@weez.co.jp> <9c00d3e00604270153i591d7993h1d9f02a68fd93a67@mail.gmail.com> Message-ID: Okay, I went with mine till someone comes up with something nicer. :) On 4/27/06, Michael Fellinger wrote: > whatever you like best, as long as it fixes the problem :) - and yes,my code sometimes look really weird... > On 4/27/06, Bryan Soto wrote:> Rather than:>> options[:condition] = options[:condition].shift.gsub('(?*)',> "(#{options[:condition].pop.join(',')})")>> what do you think of:>> [options[:condition]].flatten[0] << " #{joiner} #{cond}">> It seems more straight forward to me...>> --> "Never tell people how to do things. Tell them what to do and they> will surprise you with their ingenuity." ?General George S. Patton>> _______________________________________________> Nitro-general mailing list> Nitro-general at rubyforge.org> http://rubyforge.org/mailman/listinfo/nitro-general> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From surrender_it at yahoo.it Thu Apr 27 19:26:47 2006 From: surrender_it at yahoo.it (gabriele renzi) Date: Fri, 28 Apr 2006 01:26:47 +0200 Subject: [Nitro] Question about error handling in *Store In-Reply-To: References: Message-ID: Bryan Soto ha scritto: > I'm sorry, what I meant was, when you describe it your way (creating > an empty file) what we currently do sounds rather silly. :) ouch, sorry, I guess I had my sense of humor turned off :) From transfire at gmail.com Thu Apr 27 21:56:26 2006 From: transfire at gmail.com (TRANS) Date: Thu, 27 Apr 2006 21:56:26 -0400 Subject: [Nitro] [Bug]? Only one test per test case? In-Reply-To: <37fd0c50604271307w40a5c930s402ffc00e4891ff6@mail.gmail.com> References: <37fd0c50604271307w40a5c930s402ffc00e4891ff6@mail.gmail.com> Message-ID: <4b6f054f0604271856o44ed695fo237aabc18d2fe171@mail.gmail.com> While there may be a more fundamental problem to address, right off the bat I notice that this might help: def setup @og ||= Og.setup( :destroy => true, :store => :mysql, :name => 'db_test', :user => 'dbuser', :password => 'dbpass' ) og_fixture User end Notice the ||=. Don't hold me to it though ;) T. From transfire at gmail.com Thu Apr 27 23:01:39 2006 From: transfire at gmail.com (TRANS) Date: Thu, 27 Apr 2006 23:01:39 -0400 Subject: [Nitro] Reap's future Message-ID: <4b6f054f0604272001x5c039b0epcab42b8ce86ac512@mail.gmail.com> I will certainly be incorprating the suggestions provided in the last thread into Reap, like the project directory flag and the multi-ProjectInfo ability for instance. Thanks for those! Right now I want to cover the potential future of Reap you all have helped me envision. I have been giving it a lot of thought and I've decided Reap proper must stay focues on it's meta-project roots rather than become another custom task system, nonethless, it needs to integrate with such capabilities in some fashion, so I've come to see two potential directions for this. Both essentially end up in similar places, but take vastly different routes for getting there --and both are relative to Rake. First, and certainly the easiest of the two is to integrate Reap as essentially an extension to Rake. Basically one would have the ProjectInfo file with Reap's task meta-data AND a Rakefile. In the Rakefile one would simply do: require 'reap' and all the Reap tasks as specified in the ProjectInfo file would be added to Rake tasks. This works well, EXCEPT for the pre-project tasks: template and scaffold. Since in that case no Rakefile could exist. Those would be a problem (although below I consider a possible solution.) The alternative is to do essentially the same thing, but instead of integrating with Rake, build a independent task system essentially compatible with Rake's, except I would make the task system more fundamental, such that it could actually be used as a general programming component. -- I like this idea, and would like to pursue it, but it is certainly a good bit more work and "catching" up to the capabilites of Rake would take a while. Finally, I was thinking about Gen. Reap has the scaffold task which does a limited version of what Gen is intended to do. Then it occured to me that in a way most everything that Reap does can be thought of as a "Generator" --generate packages, announcement, test, rdoc, etc. Maybe there's room for Reap to merge with Gen? T. From james_b at neurogami.com Fri Apr 28 00:03:18 2006 From: james_b at neurogami.com (James Britt) Date: Thu, 27 Apr 2006 21:03:18 -0700 Subject: [Nitro] Reap's future In-Reply-To: <4b6f054f0604272001x5c039b0epcab42b8ce86ac512@mail.gmail.com> References: <4b6f054f0604272001x5c039b0epcab42b8ce86ac512@mail.gmail.com> Message-ID: <44519406.10405@neurogami.com> TRANS wrote: .. > > First, and certainly the easiest of the two is to integrate Reap as > essentially an extension to Rake. Basically one would have the > ProjectInfo file with Reap's task meta-data AND a Rakefile. In the > Rakefile one would simply do: > > require 'reap' > I like this idea. > ... > Finally, I was thinking about Gen. Reap has the scaffold task which > does a limited version of what Gen is intended to do. Then it occured > to me that in a way most everything that Reap does can be thought of > as a "Generator" --generate packages, announcement, test, rdoc, etc. > Maybe there's room for Reap to merge with Gen? > I good, (more or less) general-purpose generator would be nice. I would like to be able to assemble a collection of files common to my style of development and be able to either drop them in as project-specific tasks (or whatever), or store them in some central location where they would be available to all instances of Reap/Gen. Thanks for the good work! -- James Britt http://www.ruby-doc.org - Ruby Help & Documentation http://www.artima.com/rubycs/ - The Journal By & For Rubyists http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://web2.0validator.com - We're the Dot in Web 2.0 From bryan.a.soto at gmail.com Fri Apr 28 03:30:02 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Fri, 28 Apr 2006 00:30:02 -0700 Subject: [Nitro] Compiler::compile_action ... In-Reply-To: References: <1146071194.18851.13.camel@nissl.mammuth> Message-ID: On 4/26/06, Bryan Soto wrote: > In the mean time, I'm going to consider that a bug, remove that line > and see how the tests do without it. If there aren't any additional > failures, I'll apply that change to the repo. If there are, maybe I'll > be able to figure out why it's there. > I just realized that if the tests covered this better, they'd already be failing. :/ I'm currently trying to duplicate this in a test. I'll let you know what I come up with. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton From humberaquino at gmail.com Fri Apr 28 08:53:01 2006 From: humberaquino at gmail.com (Humber Aquino) Date: Fri, 28 Apr 2006 08:53:01 -0400 Subject: [Nitro] [Bug]? Only one test per test case? In-Reply-To: <4b6f054f0604271856o44ed695fo237aabc18d2fe171@mail.gmail.com> References: <37fd0c50604271307w40a5c930s402ffc00e4891ff6@mail.gmail.com> <4b6f054f0604271856o44ed695fo237aabc18d2fe171@mail.gmail.com> Message-ID: <37fd0c50604280553k3a89c9baw5fcb94dd7b819ea6@mail.gmail.com> Hi T! The result is the same :( I don't know why og knows that the db doesn't exists and did not create the db as in the first time. I will try to look into the og code to look 4 answers. Regards :D On 4/27/06, TRANS wrote: > > While there may be a more fundamental problem to address, right off > the bat I notice that this might help: > > def setup > @og ||= Og.setup( > :destroy => true, > :store => :mysql, > :name => 'db_test', > :user => 'dbuser', > :password => 'dbpass' > ) > og_fixture User > end > > Notice the ||=. Don't hold me to it though ;) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060428/bee86185/attachment.html From aglarond at gmail.com Fri Apr 28 16:28:10 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Fri, 28 Apr 2006 22:28:10 +0200 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> Message-ID: <55c107bf0604281328vc9c9544w27bb32ed5c665465@mail.gmail.com> On 4/25/06, Bryan Soto wrote: > I'll be applying this one unless there is any objection. If you could apply this latest version, that'd be great. I've made it now so that multiple tags with the same name can be changed in the same transform (basically changed the tag storage type from Hash to Array of Hashes). It's also now possible to add text directly to an Element, without having to get it from a file first: To hide the navigation 'div's in the 'index' method of a controller: replace = Nitro::Replacer.new( 'bluerobot.xhtml' ) replace.transform_root = 'txt' # this will take the text from the 'search' file in the 'txt' directory, and add it to the 'div' with 'class="content"' replace.div( {:class => "content"}, :search ) # these two will add the 'class="hide"' attribute to the 'navAlpha' and 'navBeta' 'div's replace.div( :navAlpha, :class => 'hide' ) replace.div( :navBeta, :class => 'hide' ) replace.transform To add the Pager navigation to one navigation div, and a 'return to search' link in the other: replace = Nitro::Replacer.new( 'bluerobot.xhtml', '/', 'find' ) replace.transform_root = 'txt' replace.div( {:class => "content"}, :find ) # note that the text for the body of these Elements comes directly from the methods here replace.div( :navAlpha, 'Page: #{@pager.navigation}' ) replace.div( :navBeta, 'search again' ) replace.transform If you're interested in the 'bluerobot.xhtml' template, I got it from the BlueRobot Layout Reservoir . Enjoy! - Dimitri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060428/b1913943/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nitro-transformer_multi-element.zip Type: application/zip Size: 18162 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060428/b1913943/attachment.zip From bryan.a.soto at gmail.com Sat Apr 29 03:22:20 2006 From: bryan.a.soto at gmail.com (Bryan Soto) Date: Sat, 29 Apr 2006 00:22:20 -0700 Subject: [Nitro] [PATCH][FIX] fix-nitro-compiler-param-processing Message-ID: Attached adds a test case for, and seems to fix the problem of, incorrect number of arguments when calling Nitro actions, reported by Massimo on the mailing list (http://rubyforge.org/pipermail/nitro-general/2006-April/004106.html) and Kashia on irc. I didn't have time to try it in an app (it's after midnight for me here) but I thought I'd throw it out anyway. ~~~~~ * fix-nitro-compiler-param-processing Cleans up compiler param processing to controller actions. Removes code which was incorrectly appending already accounted for parameters to the action method call causing errors. -- "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." ?General George S. Patton -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-nitro-compiler-param-processing.zip Type: application/zip Size: 16458 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060429/ca692929/attachment.zip From john at oxyliquit.de Sat Apr 29 05:18:47 2006 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 29 Apr 2006 11:18:47 +0200 Subject: [Nitro] problem with: facets-1.3.2-update and Tags In-Reply-To: References: <20060427085328.GA5943@oxyliquit.de> Message-ID: Hi, > That would be it. George requested I not apply it to the repo, though > I've tried to convince him otherwise. Perhaps it would be best if you > remove it since it's not approved. I believe if you run Yay, thank you, that did it :) > > See http://rubyforge.org/pipermail/nitro-general/2006-April/003968.html > for the thread. George, Fabian and I had a little discussion about the > Tags part. That's a good point about polluting the global namespace. I > had forgotten about that. Yes, I also read the thread, but forgot too quickly about it. Anyway, I'm hereby voting for revoking that patch and or moving it to Nitro or Og namespace. For more discussion about this topic, please read here: * http://rubyforge.org/pipermail/nitro-general/2006-February/002870.html >> Feel the love > I'm just not feeling it right now. ;) Yeh, sorry, I should look more at that picture before writing ;) Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Apr 29 05:29:22 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 11:29:22 +0200 Subject: [Nitro] Dimitri's Transformer. Message-ID: I had a look at this code, and it seems interesting. However this seems to be a subset of a bigger idea I am trying to formulate in my mind. I will get back to this at a later time. thanks Dimitri ;-) -g. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From john at oxyliquit.de Sat Apr 29 05:59:13 2006 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 29 Apr 2006 11:59:13 +0200 Subject: [Nitro] [PATCH][FIX] fix-nitro-compiler-param-processing In-Reply-To: References: Message-ID: Hi, > Attached adds a test case for, and seems to fix the problem of, > incorrect number of arguments when calling Nitro actions, reported by > Massimo on the mailing list > (http://rubyforge.org/pipermail/nitro-general/2006-April/004106.html) > and Kashia on irc. I didn't have time to try it in an app (it's after > midnight for me here) but I thought I'd throw it out anyway. > > * fix-nitro-compiler-param-processing Yay for Bryan :D Tested it with Oxy: ERROR -- : Error while handling '/add/question'. ERROR -- : wrong number of arguments (0 for 1) It now seems to swallow more arguments than it's supposed to. assert_match(/#{params}/, get(:uri => '/test', :params => { 'params' => '1', 'arg2'=>'2' })) this line fails with <"arg1=&arg2="> expected to be =~ . in the unit tests. Which I find weird. Since it runs the other two asserts just fine. (I just uncommented that line.) My case ('/add/question') should be handled by the other test-cases, but it seems it isn't. I added another test function: def test3(arg); "arg=#{arg}"; end and another assert: assert_match(/arg=1/, post(:uri => '/test3/1')) result: <"arg1=1&arg2=2"> expected to be =~ . I also doubt about the usefulness of this assert: assert_match(/#{params}/, get(:uri => '/test2/1/2')) the test2() function doesn't accept any arguments, so why doesn't the assert fail? I just realized... the "return value" doesn't get reset, even when running the next assert/get(:uri..). Thats why the test2 test doesn't fail like it should. running a single assert gives the real return value, the test2 does indeed fail. Hmm.. too bad I don't get any of this parameter handling stuff.. I hope that my mail helps you a bit, bryan. Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Apr 29 06:07:50 2006 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 29 Apr 2006 12:07:50 +0200 Subject: [Nitro] [PATCH][FIX] fix-nitro-compiler-param-processing In-Reply-To: References: Message-ID: Hi, > assert_match(/#{params}/, get(:uri => '/test', :params => { 'params' => > '1', 'arg2'=>'2' })) > > this line fails with > > <"arg1=&arg2="> expected to be =~ . Now that I think about it, I think it is correct to fail here. Why should this url: /test?params=1&arg2=2 map to the same as: /test/1/2 ? Wouldn't it complicate matters too much, if this is allowed? I'm really not sure about all this... Maybe thats where the error originates from? Kashia -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Apr 29 06:21:28 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 12:21:28 +0200 Subject: [Nitro] [PATCH] Nitro Transformer In-Reply-To: <55c107bf0604281328vc9c9544w27bb32ed5c665465@mail.gmail.com> References: <55c107bf0604170907p34e846b1occ39ea698a745bab@mail.gmail.com> <55c107bf0604171507q3e473f9cpe625c668c22d8ca6@mail.gmail.com> <55c107bf0604281328vc9c9544w27bb32ed5c665465@mail.gmail.com> Message-ID: Hmm.. I would prefer if we could wait a little bit on this. As I said in another email, I think I can generalize this idea and make it more useful and/or better integrated in nitro. please be a bit more patient, George. On 4/28/06, Dimitri Aivaliotis wrote: > On 4/25/06, Bryan Soto wrote: > > I'll be applying this one unless there is any objection. > > If you could apply this latest version, that'd be great. I've made it now > so that multiple tags with the same name can be changed in the same > transform (basically changed the tag storage type from Hash to Array of > Hashes). > > It's also now possible to add text directly to an Element, without having > to get it from a file first: > > To hide the navigation 'div's in the 'index' method of a controller: > > replace = Nitro:: Replacer.new( 'bluerobot.xhtml' ) > replace.transform_root = 'txt' > # this will take the text from the 'search' file in the 'txt' directory, and > add it to the 'div' with 'class="content"' > replace.div ( {:class => "content"}, :search ) > # these two will add the 'class="hide"' attribute to the 'navAlpha' and > 'navBeta' 'div's > replace.div( :navAlpha, :class => 'hide' ) > replace.div ( :navBeta, :class => 'hide' ) > replace.transform > > > To add the Pager navigation to one navigation div, and a 'return to search' > link in the other: > > replace = Nitro::Replacer.new( 'bluerobot.xhtml ', '/', 'find' ) > replace.transform_root = 'txt' > replace.div( {:class => "content"}, :find ) > # note that the text for the body of these Elements comes directly from the > methods here > replace.div ( :navAlpha, 'Page: #{@pager.navigation}' ) > replace.div( :navBeta, 'search again' ) > replace.transform > > > If you're interested in the 'bluerobot.xhtml' template, I got it from the > BlueRobot Layout Reservoir. > > Enjoy! > > - Dimitri > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 29 12:39:24 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 19:39:24 +0300 Subject: [Nitro] [PATCH]: More patches against the devlab repo Message-ID: Hello Bryan, I hope you can add these too ;-) regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From george.moschovitis at gmail.com Sat Apr 29 12:44:01 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 19:44:01 +0300 Subject: [Nitro] [PATCH]: More patches against the devlab repo In-Reply-To: References: Message-ID: and the attachment... -g. On 4/29/06, George Moschovitis wrote: > Hello Bryan, > > I hope you can add these too ;-) > > regards, > George. > > -- > http://www.gmosx.com > http://www.navel.gr > http://www.nitrohq.com > -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.zip Type: application/zip Size: 22335 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20060429/d7637994/attachment.zip From george.moschovitis at gmail.com Sat Apr 29 13:38:05 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 20:38:05 +0300 Subject: [Nitro] Added latest rdocs to nitroproject.org Message-ID: Dear devs, developing the new nitroproject.org homepage will take some extra time. in the meantime I added up-to-date rdocs, the videos and the mailing list links to the placeholder. George. -- http://www.nitroproject.org http://www.gmosx.com From george.moschovitis at gmail.com Sat Apr 29 13:48:07 2006 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 29 Apr 2006 20:48:07 +0300 Subject: [Nitro] Reap's future In-Reply-To: <44519406.10405@neurogami.com> References: <4b6f054f0604272001x5c039b0epcab42b8ce86ac512@mail.gmail.com> <44519406.10405@neurogami.com> Message-ID: A bit OT: the latest version of Reap *needs* facets 1.3.2. It does not work with facets 1.2.1 for example. Tom you should probably update the gem dependencies. regards, George. -- http://www.gmosx.com http://www.navel.gr http://www.nitrohq.com From aglarond at gmail.com Sun Apr 30 14:09:52 2006 From: aglarond at gmail.com (Dimitri Aivaliotis) Date: Sun, 30 Apr 2006 20:09:52 +0200 Subject: [Nitro] Dimitri's Transformer. In-Reply-To: References: Message-ID: <55c107bf0604301109m6a03113fkdef105bec7c53805@mail.gmail.com> On 4/29/06, George Moschovitis wrote: > > I had a look at this code, and it seems interesting. However this > seems to be a subset of a bigger idea I am trying to formulate in my > mind. I will get back to this at a later time. > > > thanks Dimitri ;-) > No problem. Just let me know if I can be of any assistance. And do update me on when this idea is better developed/integrated with Nitro. I've been using it on all of my current projects, and would need to adapt them to whatever the official system becomes. - Dimitri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060430/d3dcdd5a/attachment.html