From william.full.moon at gmail.com Sat Sep 1 02:32:56 2007 From: william.full.moon at gmail.com (* William) Date: Sat, 1 Sep 2007 16:32:56 +1000 Subject: [Nitro] check this [bitrock] out Message-ID: <9e03c3c60708312332p203933c0n2cb8133bee64d4f7@mail.gmail.com> Hey hey! I see the nice bitrock people have a Ruby stack for the web. It includes Rails. I believe it would be really really useful to put an effort into drawing a line under features for Nitro so that it is a viable candidate for a packaged stack. As a first step, what do you reckon by making a "Bitrock Nitro" add-on, that people can fit into a Bitrock stack for themselves? Some thoughts from a Saturday on the web. Aloha, Will. --------------------------------------------------------------------------------------- - http://bitrock.com/products_ruby_overview.html Integrated Open Source Ruby Distribution RubyStack is a freely available, ready to run distribution of Ruby on Rails?. Packaged with a very user-friendly installer, RubyStack makes it easy to have an enterprise-ready Rails environment up and running in just minutes. It allows you to take advantage of the stability, low cost and high performance of Ruby on Rails without the hassle of integrating, configuring, and supporting your own build. RubyStack is currently available for Linux and Mac OS X, with support for Windows and Solaris coming soon. As with all of our Web Stacks, RubyStack is free to downloadand use under the terms of the Apache 2.0 license. As the stack contains several open source tools and libraries, it is important that you read and comply with the licenses for each stack component. RubyStack offers two installation profiles to make it easy to set up Ruby in both development and production environments. Both profiles install the following open source software, along with several other tools and libraries . - Ruby - Subversion - SQLite - MySQL - ImageMagick - Several Ruby Gems, including: Rails, Mongrel, mongrel_cluster and RMagick The Production installation profile also installs Apache 2.2 with rewrite and proxy support, so you have everything you need to deploy your Ruby on Rails applications. You can learn more about the benefitsof using BitRock Web Stacks or go directly to the download page to get a copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/f938bcd4/attachment-0001.html From mvyver at gmail.com Sat Sep 1 02:33:17 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 1 Sep 2007 16:33:17 +1000 Subject: [Nitro] OG and DBI: Oxyliquit draft tip In-Reply-To: <389c43e40708310050o2adfb056s75ab532208934166@mail.gmail.com> References: <389c43e40708310050o2adfb056s75ab532208934166@mail.gmail.com> Message-ID: <389c43e40708312333x2d4a23bdvaf4064bcf2b18d60@mail.gmail.com> Correction: > #-- start-bash ---------------------------- > su > DBNAME=mysql > ODBCVER=0.9995 > DBIVER=0.1.1 > pushd /tmp > wget http://ch-werner.de/rubyodbc/ruby-odbc-${ODBCVER}.tar.gz > tar -xvf ruby-odbc-${ODBCVER}.tar.gz > pushd ruby-odbc-${ODBCVER} > ruby extconf.rb --enable-dlopen > make > make install > #Installation of utf8 version: > ruby -Cutf8 extconf.rb --enable-dlopen > make -C utf8 > make -C utf8 install > popd > - gem install ${DBNAME} sqlite + gem install ${DBDNAME} sqlite-ruby sqlite3-ruby > wget http://rubyforge.org/frs/download.php/12368/dbi-${DBIVER}.tar.gz > tar -xvf dbi-${DBIVER}.tar.gz > pushd ruby-dbi > ruby setup.rb config --with=dbi,dbd_sqlite,dbd_odbc,dbd_${DBNAME} > ruby setup.rb install > popd > popd > #-- end-bash ---------------------------- > From mvyver at gmail.com Sat Sep 1 02:48:16 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 1 Sep 2007 16:48:16 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) Message-ID: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Hi, I think I found some unexpected behaviors from OG - the first can be a show stopper from some. This may be specific to the MySQL and sqlite adapters? The two ruby scripts show the behaviors described below. I use the MySQL and the Sqlite adapters, could any one confirm they see the same behavior described below with another adapter - just in case. **SHOW STOPPER** 1) The Og::SqlStore#exec_statement seems to rearrange the data submitted in an sql string, and example of the original SQL statement data and the SQL statement submitted to the MySQL store follows. insert into ogmember ( address1,city,email,first_name,state,last_name ) values ( '123 High St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' ) DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') **Normal** 2) In script og_create_unexpected2b.rb the DEBUG statements do not print out when running the single method in the 'Benchmark.bmbm do ..end' loop. In script og_create_unexpected2.rb I observe that the addition of another method in the benchmark loop results in the Debug code being printed. The same behavior occurs if 5 or 5000 rows are inserted, so I don't think it is some output buffering issue - or maybe it is? The only difference in these two files is in the benchmark loop where "'create' => :create_fixture," is present or absent. **trivial** 3) Og#connect seems to make two selects from a table that has just been created. I haven't dug in to see why, but thought I give a 'heads-up' in case they shouldn't be there. The queries I refer to are issued from within OG#connect, the attached files should print out: INFO: Og uses the Mysql store. DEBUG: Og manageable classes: [Member] DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, `address1` text, `city` text, `state` text, `email` text, `oid` integer AUTO_INCREMENT PRIMARY KEY) DEBUG: SELECT * FROM `ogmember` LIMIT 1 DEBUG: SELECT * FROM `ogmember` LIMIT 1 Using the Sqlite adapter I see something slightly different, but still the duplicate `'SELECT': INFO: Og uses the Sqlite store. DEBUG: Og manageable classes: [Member] DEBUG: CREATE TABLE ogmember (first_name text, last_name text, address1 text, city text, state text, email text, oid integer PRIMARY KEY) INFO: Created table ogmember. DEBUG: SELECT * FROM ogmember LIMIT 1 DEBUG: SELECT * FROM ogmember LIMIT 1 HTH Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: og_create_unexpected2.rb Type: application/x-ruby Size: 2876 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070901/0673ff4b/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: og_create_unexpected2b.rb Type: application/x-ruby Size: 2839 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070901/0673ff4b/attachment-0001.bin From mvyver at gmail.com Sat Sep 1 04:01:38 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 1 Sep 2007 18:01:38 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> Hmm, I think I've worked out what the problem is and may have a solution that should also improve performance - I hope. Mark On 9/1/07, Mark Van De Vyver wrote: > Hi, > > I think I found some unexpected behaviors from OG - the first can be a > show stopper from some. > This may be specific to the MySQL and sqlite adapters? > The two ruby scripts show the behaviors described below. > I use the MySQL and the Sqlite adapters, could any one confirm they > see the same behavior described below with another adapter - just in > case. > > **SHOW STOPPER** > 1) The Og::SqlStore#exec_statement seems to rearrange the data > submitted in an sql string, and example of the original SQL statement > data and the SQL statement submitted to the MySQL store follows. > > insert into ogmember ( address1,city,email,first_name,state,last_name > ) values ( '123 High > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' > ) > > DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') > > **Normal** > 2) In script og_create_unexpected2b.rb the DEBUG statements do not > print out when running the single method in the 'Benchmark.bmbm do > ..end' loop. > In script og_create_unexpected2.rb I observe that the addition of > another method in the benchmark loop results in the Debug code being > printed. The same behavior occurs if 5 or 5000 rows are inserted, so > I don't think it is some output buffering issue - or maybe it is? > The only difference in these two files is in the benchmark loop > where "'create' => :create_fixture," is present or absent. > > **trivial** > 3) Og#connect seems to make two selects from a table that has just > been created. I haven't dug in to see why, but thought I give a > 'heads-up' in case they shouldn't be there. The queries I refer to > are issued from within OG#connect, the attached files should print > out: > > INFO: Og uses the Mysql store. > DEBUG: Og manageable classes: [Member] > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > `address1` text, `city` text, `state` text, `email` text, `oid` > integer AUTO_INCREMENT PRIMARY KEY) > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > Using the Sqlite adapter I see something slightly different, but still > the duplicate `'SELECT': > > INFO: Og uses the Sqlite store. > DEBUG: Og manageable classes: [Member] > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > address1 text, city text, state text, email text, oid integer PRIMARY > KEY) > INFO: Created table ogmember. > DEBUG: SELECT * FROM ogmember LIMIT 1 > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > HTH > Mark > > From george.moschovitis at gmail.com Sat Sep 1 04:42:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Sep 2007 11:42:09 +0300 Subject: [Nitro] advice.rb In-Reply-To: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> Message-ID: Quick question... does the SVN contain everything contained in the older version of facets ( 1.8.54) ? Would it make sense to start converting Nitro to use the svn version? What is the 'dev' directory? thanks, -g. On 9/1/07, TRANS wrote: > > It's called it advice.rb (though maybe it should be renamed > advisable.rb) and you can find it in the current SVN repo. > > I changed the name from aspects.rb b/c a) the Aspect/Aspects classes > are no longer needed and b) the name clashes with the class now in > aop.rb --which is a full-blown heavy-wieght cuts-based AOP solution > (work in progress). > > For advice.rb to work you also need 1stclassmethod.rb and > unboundmethod/arguments. I've attached them, but it may be easier just > to pull down the SVN repo. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/2a2c82df/attachment.html From george.moschovitis at gmail.com Sat Sep 1 04:51:08 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Sep 2007 11:51:08 +0300 Subject: [Nitro] check this [bitrock] out In-Reply-To: <9e03c3c60708312332p203933c0n2cb8133bee64d4f7@mail.gmail.com> References: <9e03c3c60708312332p203933c0n2cb8133bee64d4f7@mail.gmail.com> Message-ID: I didn't knwo about bitrock. Is this some kind of a vm image? like amazon AMI's ? -g. On 9/1/07, * William wrote: > > Hey hey! > > I see the nice bitrock people have a Ruby stack for the web. It includes Rails. > > I believe it would be really really useful to put an effort into drawing a > line under features for Nitro so that it is a viable candidate for a > packaged stack. > > As a first step, what do you reckon by making a "Bitrock Nitro" add-on, > that people can fit into a Bitrock stack for themselves? > > Some thoughts from a Saturday on the web. > > Aloha, > Will. > > > --------------------------------------------------------------------------------------- > > - http://bitrock.com/products_ruby_overview.html > > Integrated Open Source Ruby Distribution > > RubyStack is a freely available, ready to run distribution of Ruby on > Rails?. Packaged with a very user-friendly installer, RubyStack makes it > easy to have an enterprise-ready Rails environment up and running in just > minutes. It allows you to take advantage of the stability, low cost and high > performance of Ruby on Rails without the hassle of integrating, configuring, > and supporting your own build. > > RubyStack is currently available for Linux and Mac OS X, with support for > Windows and Solaris coming soon. As with all of our Web Stacks, > RubyStack is free to downloadand use under the terms of the Apache > 2.0 license. As the stack contains several open source tools and > libraries, it is important that you read and comply with the licenses for > each stack component. > > RubyStack offers two installation profiles to make it easy to set up Ruby > in both development and production environments. Both profiles install the > following open source software, along with several other tools and > libraries . > > - Ruby > - Subversion > - SQLite > - MySQL > - ImageMagick > - Several Ruby Gems, including: Rails, Mongrel, mongrel_cluster and > RMagick > > The Production installation profile also installs Apache 2.2 with rewrite > and proxy support, so you have everything you need to deploy your Ruby on > Rails applications. You can learn more about the benefitsof using BitRock Web Stacks or go directly to the > download page to get a > copy. > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/5daefea5/attachment-0001.html From mvyver at gmail.com Sat Sep 1 04:57:11 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 1 Sep 2007 18:57:11 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> Message-ID: <389c43e40709010157q3e086a36qa36f76f54f0ff6a1@mail.gmail.com> On 9/1/07, Mark Van De Vyver wrote: > Hmm, > I think I've worked out what the problem is and may have a solution > that should also improve performance - I hope. No joy. I'm stumped..... :( Mark > Mark > > On 9/1/07, Mark Van De Vyver wrote: > > Hi, > > > > I think I found some unexpected behaviors from OG - the first can be a > > show stopper from some. > > This may be specific to the MySQL and sqlite adapters? > > The two ruby scripts show the behaviors described below. > > I use the MySQL and the Sqlite adapters, could any one confirm they > > see the same behavior described below with another adapter - just in > > case. > > > > **SHOW STOPPER** > > 1) The Og::SqlStore#exec_statement seems to rearrange the data > > submitted in an sql string, and example of the original SQL statement > > data and the SQL statement submitted to the MySQL store follows. > > > > insert into ogmember ( address1,city,email,first_name,state,last_name > > ) values ( '123 High > > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' > > ) > > > > DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, > > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', > > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') > > > > **Normal** > > 2) In script og_create_unexpected2b.rb the DEBUG statements do not > > print out when running the single method in the 'Benchmark.bmbm do > > ..end' loop. > > In script og_create_unexpected2.rb I observe that the addition of > > another method in the benchmark loop results in the Debug code being > > printed. The same behavior occurs if 5 or 5000 rows are inserted, so > > I don't think it is some output buffering issue - or maybe it is? > > The only difference in these two files is in the benchmark loop > > where "'create' => :create_fixture," is present or absent. > > > > **trivial** > > 3) Og#connect seems to make two selects from a table that has just > > been created. I haven't dug in to see why, but thought I give a > > 'heads-up' in case they shouldn't be there. The queries I refer to > > are issued from within OG#connect, the attached files should print > > out: > > > > INFO: Og uses the Mysql store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > > `address1` text, `city` text, `state` text, `email` text, `oid` > > integer AUTO_INCREMENT PRIMARY KEY) > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > > Using the Sqlite adapter I see something slightly different, but still > > the duplicate `'SELECT': > > > > INFO: Og uses the Sqlite store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > > address1 text, city text, state text, email text, oid integer PRIMARY > > KEY) > > INFO: Created table ogmember. > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > > > > HTH > > Mark > > > > > From george.moschovitis at gmail.com Sat Sep 1 05:08:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Sep 2007 12:08:55 +0300 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40709010157q3e086a36qa36f76f54f0ff6a1@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> <389c43e40709010157q3e086a36qa36f76f54f0ff6a1@mail.gmail.com> Message-ID: Let me have a look at your scripts. -g. On 9/1/07, Mark Van De Vyver wrote: > > On 9/1/07, Mark Van De Vyver wrote: > > Hmm, > > I think I've worked out what the problem is and may have a solution > > that should also improve performance - I hope. > > No joy. I'm stumped..... :( > > Mark > > > Mark > > > > On 9/1/07, Mark Van De Vyver wrote: > > > Hi, > > > > > > I think I found some unexpected behaviors from OG - the first can be a > > > show stopper from some. > > > This may be specific to the MySQL and sqlite adapters? > > > The two ruby scripts show the behaviors described below. > > > I use the MySQL and the Sqlite adapters, could any one confirm they > > > see the same behavior described below with another adapter - just in > > > case. > > > > > > **SHOW STOPPER** > > > 1) The Og::SqlStore#exec_statement seems to rearrange the data > > > submitted in an sql string, and example of the original SQL statement > > > data and the SQL statement submitted to the MySQL store follows. > > > > > > insert into ogmember ( address1,city,email,first_name,state,last_name > > > ) values ( '123 High > > > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' > > > ) > > > > > > DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, > > > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', > > > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') > > > > > > **Normal** > > > 2) In script og_create_unexpected2b.rb the DEBUG statements do not > > > print out when running the single method in the 'Benchmark.bmbm do > > > ..end' loop. > > > In script og_create_unexpected2.rb I observe that the addition of > > > another method in the benchmark loop results in the Debug code being > > > printed. The same behavior occurs if 5 or 5000 rows are inserted, so > > > I don't think it is some output buffering issue - or maybe it is? > > > The only difference in these two files is in the benchmark loop > > > where "'create' => :create_fixture," is present or absent. > > > > > > **trivial** > > > 3) Og#connect seems to make two selects from a table that has just > > > been created. I haven't dug in to see why, but thought I give a > > > 'heads-up' in case they shouldn't be there. The queries I refer to > > > are issued from within OG#connect, the attached files should print > > > out: > > > > > > INFO: Og uses the Mysql store. > > > DEBUG: Og manageable classes: [Member] > > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > > > `address1` text, `city` text, `state` text, `email` text, `oid` > > > integer AUTO_INCREMENT PRIMARY KEY) > > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > > > > Using the Sqlite adapter I see something slightly different, but still > > > the duplicate `'SELECT': > > > > > > INFO: Og uses the Sqlite store. > > > DEBUG: Og manageable classes: [Member] > > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > > > address1 text, city text, state text, email text, oid integer PRIMARY > > > KEY) > > > INFO: Created table ogmember. > > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > > > > > > > HTH > > > Mark > > > > > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/604c2ce8/attachment.html From george.moschovitis at gmail.com Sat Sep 1 05:18:53 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Sep 2007 12:18:53 +0300 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: > > 3) Og#connect seems to make two selects from a table that has just > been created. I haven't dug in to see why, but thought I give a > 'heads-up' in case they shouldn't be there. The queries I refer to > are issued from within OG#connect, the attached files should print > out: > I have seen this one, can't find where the second select comes from. Will have to investigate further. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/916f5823/attachment.html From george.moschovitis at gmail.com Sat Sep 1 05:22:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 1 Sep 2007 12:22:26 +0300 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> <389c43e40709010101l4f680dacpf69bba9df6ab5085@mail.gmail.com> Message-ID: > > Hmm, > I think I've worked out what the problem is and may have a solution > that should also improve performance - I hope. What do you think is the problem? -g. Mark > > On 9/1/07, Mark Van De Vyver wrote: > > Hi, > > > > I think I found some unexpected behaviors from OG - the first can be a > > show stopper from some. > > This may be specific to the MySQL and sqlite adapters? > > The two ruby scripts show the behaviors described below. > > I use the MySQL and the Sqlite adapters, could any one confirm they > > see the same behavior described below with another adapter - just in > > case. > > > > **SHOW STOPPER** > > 1) The Og::SqlStore#exec_statement seems to rearrange the data > > submitted in an sql string, and example of the original SQL statement > > data and the SQL statement submitted to the MySQL store follows. > > > > insert into ogmember ( address1,city,email,first_name,state,last_name > > ) values ( '123 High > > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' > > ) > > > > DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, > > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', > > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') > > > > **Normal** > > 2) In script og_create_unexpected2b.rb the DEBUG statements do not > > print out when running the single method in the 'Benchmark.bmbm do > > ..end' loop. > > In script og_create_unexpected2.rb I observe that the addition of > > another method in the benchmark loop results in the Debug code being > > printed. The same behavior occurs if 5 or 5000 rows are inserted, so > > I don't think it is some output buffering issue - or maybe it is? > > The only difference in these two files is in the benchmark loop > > where "'create' => :create_fixture," is present or absent. > > > > **trivial** > > 3) Og#connect seems to make two selects from a table that has just > > been created. I haven't dug in to see why, but thought I give a > > 'heads-up' in case they shouldn't be there. The queries I refer to > > are issued from within OG#connect, the attached files should print > > out: > > > > INFO: Og uses the Mysql store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > > `address1` text, `city` text, `state` text, `email` text, `oid` > > integer AUTO_INCREMENT PRIMARY KEY) > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > > Using the Sqlite adapter I see something slightly different, but still > > the duplicate `'SELECT': > > > > INFO: Og uses the Sqlite store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > > address1 text, city text, state text, email text, oid integer PRIMARY > > KEY) > > INFO: Created table ogmember. > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > > > > HTH > > Mark > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/0486ee67/attachment.html From william.full.moon at gmail.com Sat Sep 1 05:30:23 2007 From: william.full.moon at gmail.com (* William) Date: Sat, 1 Sep 2007 19:30:23 +1000 Subject: [Nitro] check this [bitrock] out In-Reply-To: References: <9e03c3c60708312332p203933c0n2cb8133bee64d4f7@mail.gmail.com> Message-ID: <9e03c3c60709010230x12ce9418gcb979226b37418ed@mail.gmail.com> Hi ... It is an installer -- OpneSource configurations like pre-configured LAMP, WAMP, etc. This news story will complete most of the picture... - http://bitrock.com/about_news_rubystack.html w. On 01/09/2007, George Moschovitis wrote: > > I didn't knwo about bitrock. Is this some kind of a vm image? like amazon > AMI's ? > > -g. > > > > On 9/1/07, * William < william.full.moon at gmail.com> wrote: > > > Hey hey! > > > > I see the nice bitrock people have a Ruby stack for the web. It includes Rails. > > > > I believe it would be really really useful to put an effort into drawing > > a line under features for Nitro so that it is a viable candidate for a > > packaged stack. > > > > As a first step, what do you reckon by making a "Bitrock Nitro" add-on, > > that people can fit into a Bitrock stack for themselves? > > > > Some thoughts from a Saturday on the web. > > > > Aloha, > > Will. > > > > > > --------------------------------------------------------------------------------------- > > > > - http://bitrock.com/products_ruby_overview.html > > > > Integrated Open Source Ruby Distribution > > > > RubyStack is a freely available, ready to run distribution of Ruby on > > Rails?. Packaged with a very user-friendly installer, RubyStack makes it > > easy to have an enterprise-ready Rails environment up and running in just > > minutes. It allows you to take advantage of the stability, low cost and high > > performance of Ruby on Rails without the hassle of integrating, configuring, > > and supporting your own build. > > > > RubyStack is currently available for Linux and Mac OS X, with support > > for Windows and Solaris coming soon. As with all of our Web Stacks, > > RubyStack is free to downloadand use under the terms of the Apache > > 2.0 license. As the stack contains several open source tools and > > libraries, it is important that you read and comply with the licenses for > > each stack component. > > > > RubyStack offers two installation profiles to make it easy to set up > > Ruby in both development and production environments. Both profiles install > > the following open source software, along with several other tools and > > libraries . > > > > - Ruby > > - Subversion > > - SQLite > > - MySQL > > - ImageMagick > > - Several Ruby Gems, including: Rails, Mongrel, mongrel_cluster > > and RMagick > > > > The Production installation profile also installs Apache 2.2 with > > rewrite and proxy support, so you have everything you need to deploy your > > Ruby on Rails applications. You can learn more about the benefitsof using BitRock Web Stacks or go directly to the > > download page to get a > > copy. > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/10c87e33/attachment-0001.html From john at oxyliquit.de Sat Sep 1 05:47:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 01 Sep 2007 11:47:28 +0200 Subject: [Nitro] Testing the whole website with GET/POST In-Reply-To: References: <367301c7eacc$df9b18a0$6442a8c0@musicbox> Message-ID: Hi, > Very good idea! I will try this as well. This would be a greate candidate > for an oxyliquid tip. http://www.oxyliquit.de/tip/38 thanks for that, I don't like that it's a little short and not comprehensive, but anyway, more 'data'. :P Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Sep 1 05:47:38 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 01 Sep 2007 11:47:38 +0200 Subject: [Nitro] OG and DBI: Oxyliquit draft tip In-Reply-To: <389c43e40708310050o2adfb056s75ab532208934166@mail.gmail.com> References: <389c43e40708310050o2adfb056s75ab532208934166@mail.gmail.com> Message-ID: Hi, > To use DBI there is some work that needs to be done to install the > drivers. I thought to make a Oxyliquit tip about this - I'd > appreciate feedback on the script below. that sounds nice. ^_^ > The draft below prepares for sqlite, mysql and odbc. > It'd be useful to know if it is possible to change DBNAME (used twice) > to install postgres , Oracle, any other drivers? See at end of script, that would be my idea. > Before placing anything on Oxyliquit it would be useful to confirm > which distributions the following 'script' succeeds on - the location > of the odbc library might be an issue if it is not in /usr/lib.... > other issues? > I've tested the following on openSUSE 10.2 That looks like it'd work everywhere where ruby is installed (and that stuff compiles that is). I'm surprised though that it's so hard to install that stuff... Arent there gems for dbi? > My understanding is that DBI and ruby-ODBC are packaged in windows > one-click installer - can some one confirm that? > #-- start-bash ---------------------------- > su > ODBCVER=0.9995 > DBIVER=0.1.1 > pushd /tmp > wget http://ch-werner.de/rubyodbc/ruby-odbc-${ODBCVER}.tar.gz > tar -xvf ruby-odbc-${ODBCVER}.tar.gz > pushd ruby-odbc-${ODBCVER} > ruby extconf.rb --enable-dlopen > make > make install > #Installation of utf8 version: > ruby -Cutf8 extconf.rb --enable-dlopen > make -C utf8 > make -C utf8 install > popd > gem install "$@" sqlite wget http://rubyforge.org/frs/download.php/12368/dbi-${DBIVER}.tar.gz tar -xvf dbi-${DBIVER}.tar.gz pushd ruby-dbi str='dbi,dbd_sqlite,dbd_odbc' for db in $@; do str="$str,dbd_$db"; done echo $str ruby setup.rb config --with="$str" ruby setup.rb install popd popd > #-- end-bash ---------------------------- ./bash-script psql oracle ------- Just lumped together, but that might just work. :) Where of course the 'gem install' for postgres would be ruby-postgres, and that would not compatible with the "--with="... maybe you have a better idea looking at this. Make people install the gems manually? Or.. make the script ruby which then could be better adapted, my bash scripting foo is like non-existant. ;) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Sat Sep 1 10:54:35 2007 From: transfire at gmail.com (Trans) Date: Sat, 01 Sep 2007 14:54:35 -0000 Subject: [Nitro] advice.rb In-Reply-To: References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> Message-ID: <1188658475.138118.179200@22g2000hsm.googlegroups.com> On Sep 1, 1:42 am, "George Moschovitis" wrote: > Quick question... > > does the SVN contain everything contained in the older version of facets ( > 1.8.54) ? Not under trunk. The old version is currently in branches/series-1.8. Actually I need to tag that. In trunk/, everything should be there except for what was moved to Blow, English and Stick. I still have to create the Nemo project but unfortunately I can't pry the damn Rubyforge project by that name from it's dead beat owner (he's no where to be found). I'll make one last try today, otherwise we need a new name. > Would it make sense to start converting Nitro to use the svn > version? Yes. That would be good. But do it this way: require 'facets' That will load ALL core code. Then you can load "more" libs as needed (just facets/, not facets/more/). This is the preferred usage for any application that uses a significant proportion of Facets' core functionality --such as Nitro/Og. The idea is to have a strong core lib that everyone can depend upon. (The new core, btw, is smaller, more refined and much tighter than before.) Let's keep close communications for the initial change over, it shouldn't be too hard, but it will, no doubt, flush out some things that need to be fixed/improved. I'll get a beta release ready over the next few days, so once the Nitro/Og conversion is complete others can hack on it too. SHould I just go ahead an make the release to Rubyforge? > What is the 'dev' directory? Stands for "development" it's just a play/scrap code area. T. From mvyver at gmail.com Sat Sep 1 20:29:11 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 2 Sep 2007 10:29:11 +1000 Subject: [Nitro] Nitro/OG spec convention/organization questions Message-ID: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> Hi, I've questions about spec best practice and organization of specs in nitro/og. Please don't consider any of this critical - I'm just talking about superficial issues, not the content of the current written spec files. I'd appreciate any thoughts on what is considered best practice in the RSpec/spec world. My understanding is that specs _can_ be a form of documentation and a source of 'howto' hints for users - maybe even point them to convenience/performance ways of doing things (if not best practice) - this is probably more important while these projects are being developed and before all the books are written ;) This makes me think we should maybe consider a directory structure: ./spec ./spec/developer A 'spec' of classes and methods a user is 'expected' to encounter should be in the first level, others should be in the second. In some sense a split that is a hassel, but maybe the user level specs will be quite stable relative to the developer specs, so One would still be spending most time in one folder? Next, should spec files correspond to the file name containing the code they spec, or the class/module name? If you think the file name, then what should be done with directory structures? Or should there be no such ties that bind? The issue here is how do the unitiated/stale work out from the spec just where the code resides (the ideal solution will also permit one to work out from the code where the spec is/should be) Related to the last issue: should file naming be <...>_spec.rb, or without the _spec extension? Finally, if anyone specs an example or a benchmark should these be in separate directories? A directory structure might look like: ./spec ./spec/benchmarks ./spec/developer ./spec/examples ./spec/fixtures ./spec/models The fixtures and models dir's could be sub dir's of ./spec/support/ Or, should we 'just do it' and merge/cull/re-organize later? I think can hear some people groaning :) Cheers Mark From mvyver at gmail.com Sat Sep 1 21:21:47 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 2 Sep 2007 11:21:47 +1000 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <46DA0B28.5040701@arnebrasseur.net> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <46DA0B28.5040701@arnebrasseur.net> Message-ID: <389c43e40709011821u1dabd847ic476d2c61fc95562@mail.gmail.com> Hi Arne, On 9/2/07, Arne Brasseur wrote: > Mark Van De Vyver schreef: > > Hi, > > I've questions about spec best practice and organization of specs in > > nitro/og. Please don't consider any of this critical - I'm just > > talking about superficial issues, not the content of the current > > written spec files. > > > Both structure and content can (IMHO) be improved upon. Before recently > Nitro/Og used Test::Unit. There was decided (before I came here) to > convert everything to RSpec. This conversion had been slacking for a > long time. I implemented the rake tasks to run the specs, with the > actual test runners taken from Ramaze. It was by no means perfect, but > Good Enough to get things going again and put a bit more emphasis on the > tests. > > I did most of the syntax-level conversion from Test::Unit to RSpec, with > Jo making sure the tests pass. The last time I checked there were still > several incomplete or failing tests. Thanks for effort you guys put in and the background is good to know. > > ... > > > > > Next, should spec files correspond to the file name containing the > > code they spec, or the class/module name? If you think the file name, > > then what should be done with directory structures? Or should there be > > no such ties that bind? > > > ... > > A directory structure might look like: > > > > ./spec > > ./spec/benchmarks > > ./spec/developer > > ./spec/examples > > ./spec/fixtures > > ./spec/models > > > > The fixtures and models dir's could be sub dir's of > > ./spec/support/ > > > > Or, should we 'just do it' and merge/cull/re-organize later? I think > > can hear some people groaning :) > > > Actually I'm glad you bring this up. The rule of thumb I applied was to > largely mirror the lib/ dir in spec, so one spec file with the > same name and relative location for every source file. This was not > considered stringent. This leaves the question open where to put support > files. Ok, sound like there is some flux and some things are settled. > My idea was to > - convert everything > - make tests go green > - improve on content and structure > > However George seems to have some great plans with the specs, with the > hidden directories and all of that, so I'm waiting to see what happens. > He told me three weeks ago the tests would be moved back ASAP. I also > moved to the other side of the world this week, so I haven't really > looked at it much lately. > > I hope this answers some of your questions. George, could you please let > us in on what you have in mind regarding the tests/specs? Thanks, you definitely answered some questions. I'll wait to hear from George on hwo to structure things, if they are to be structured now. Cheers Mark > regards > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > From arne at arnebrasseur.net Sat Sep 1 21:00:24 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 02 Sep 2007 09:00:24 +0800 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> Message-ID: <46DA0B28.5040701@arnebrasseur.net> Mark Van De Vyver schreef: > Hi, > I've questions about spec best practice and organization of specs in > nitro/og. Please don't consider any of this critical - I'm just > talking about superficial issues, not the content of the current > written spec files. > Both structure and content can (IMHO) be improved upon. Before recently Nitro/Og used Test::Unit. There was decided (before I came here) to convert everything to RSpec. This conversion had been slacking for a long time. I implemented the rake tasks to run the specs, with the actual test runners taken from Ramaze. It was by no means perfect, but Good Enough to get things going again and put a bit more emphasis on the tests. I did most of the syntax-level conversion from Test::Unit to RSpec, with Jo making sure the tests pass. The last time I checked there were still several incomplete or failing tests. > ... > > Next, should spec files correspond to the file name containing the > code they spec, or the class/module name? If you think the file name, > then what should be done with directory structures? Or should there be > no such ties that bind? > ... > A directory structure might look like: > > ./spec > ./spec/benchmarks > ./spec/developer > ./spec/examples > ./spec/fixtures > ./spec/models > > The fixtures and models dir's could be sub dir's of > ./spec/support/ > > Or, should we 'just do it' and merge/cull/re-organize later? I think > can hear some people groaning :) > Actually I'm glad you bring this up. The rule of thumb I applied was to largely mirror the lib/ dir in spec, so one spec file with the same name and relative location for every source file. This was not considered stringent. This leaves the question open where to put support files. My idea was to - convert everything - make tests go green - improve on content and structure However George seems to have some great plans with the specs, with the hidden directories and all of that, so I'm waiting to see what happens. He told me three weeks ago the tests would be moved back ASAP. I also moved to the other side of the world this week, so I haven't really looked at it much lately. I hope this answers some of your questions. George, could you please let us in on what you have in mind regarding the tests/specs? regards (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From work at ashleymoran.me.uk Sun Sep 2 18:15:37 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Sun, 2 Sep 2007 23:15:37 +0100 Subject: [Nitro] Questions to help me evaluate Nitro Message-ID: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> Hi I have a few n00b questions regarding Nitro that I thought might be answered quicker by people who know the framework than me playing around. Basically my situation is I have been employed for the last 3 years doing sysadmin, DBA and Rails work, but I've recently handed my notice in, and by December I will need some real work. That give me 3 months (clock already ticking!) to create a little side-project, either as a money-spinner or just something for my CV to help me get some contract or permanent work. I was about to dive in with Rails but I thought I'd take another look at Nitro because it's a while since I read anything about it. I'm drawn to it because from what I've seen, it seems to have a sense of beauty that Rails lacks. (Rails is very clever, but it sure can be ugly at times.) However I have a few concerns I was hoping someone could address. (Ok actually quite a lot, now I've written them all out.) - Og - I have a very database-centric view of web apps: I see the data as the core of any project and the application just a means to do something useful with it. This seem at odds with the Og philosophy that the object model is key, and the database is used to support it. With Rails, I am constantly doing database-level changes, like renaming columns, moving columns from one table to another, inserting or deleting static data, setting arbitrary constraints (eg CHECK). The blog example makes it look like everything must be done with Og black magic. Will I need to build my own migration system to get the level of database control I'm used to? (Or I could hijack ActiveRecord Migrations for this, I guess.) - Testing - I see Nitro uses RSpec for it's own unit tests now. This I like :) RSpec is possibly my favourite piece of software ever. The rspec_on_rails plugin is pretty cool too, and by and large, the only problems I run into are due to Rails ugliness. Neither of the example apps have any testing. How easy is it to do unit tests with RSpec for each of the MVC layers? How about integration tests - are there any best practices for integrating, say Watir into a Nitro app's development cycle? - Plugins / Third-party code - One nice thing about Rails due to its popularity relative maturity is that if you've thought about it, at least three other people have too, and one has certainly written a plugin for it. What's the situation in Nitro? Is there a lot of wheel-reinvention needed for things Rails people take for granted? I'm sure this is very much dependent on the exact problem you are trying to solve. - Documentation - Ok, so Rails hardly gets 5* here, seeing as learning Rails involves scouring the web for answers. But it does have an excellent printed book and a pretty helpful wiki. The Nitro site has a lot of dangling links (also true of most of the sub-projects and related projects) and I can't find much in the way of tutorial/how-to stuff. If I start building a Nitro app tomorrow, will I find myself spending the first month just trying to figure out basic things? - JavaScript - I've been a bit spoilt by RJS. Will I be forced to (finally, grudgingly) learn JavaScript? Does Nitro have an equivalent means of sending multiple updates to a page? With RJS, I can pretty much reconfigure a whole page with a few lines of Ruby. It's often not perfect, but it's a real time saver. - Real World Use - Are there any lists of Nitro-powered sites so I can see what people have achieved? I don't doubt you can build large, robust apps with Nitro (I still work with people who question if you can do that with Rails), I'd just like to know what they are. I hope I'm not rehashing any old subjects here, but I can't seem my questions answered in the last few months on this list (admittedly, I've only skimmed the subjects). Also please don't take any of this as criticism, I am just curious about the Nitro world. Finally, is there any really cool stuff about Nitro will make me say "I wish Rails could do that/did it that way"? I'm much more impressed by elegant solutions to problems than I am put off by things not working out of the box. Thanks in advance for any advice Ashley From george.moschovitis at gmail.com Mon Sep 3 00:50:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 07:50:01 +0300 Subject: [Nitro] advice.rb In-Reply-To: <1188658475.138118.179200@22g2000hsm.googlegroups.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1188658475.138118.179200@22g2000hsm.googlegroups.com> Message-ID: > > Blow, English and Stick. I still have to create the Nemo project but hmm, nitro needs stuff from these projects too, can you remind me their svn repositories urls? try today, otherwise we need a new name. how about: memo, mnemo (from mnemonic = memory in greek), nah, memo is better. > require 'facets' Ok. > Let's keep close communications for the initial change over, it > shouldn't be too hard, but it will, no doubt, flush out some things > that need to be fixed/improved. I will attempt the conversion from tomorrow (tuesday). I'll get a beta release ready over the next few days, so once the > Nitro/Og conversion is complete others can hack on it too. SHould I > just go ahead an make the release to Rubyforge? Not before we verify that it works 100% with Nitro. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/a90e213b/attachment-0001.html From george.moschovitis at gmail.com Mon Sep 3 00:58:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 07:58:33 +0300 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> Message-ID: > > My understanding is that specs _can_ be a form of documentation and a > source of 'howto' hints for users - maybe even point them to > convenience/performance ways of doing things (if not best practice) - this is a great goal ;-) > nk we should maybe consider a directory structure: > ./spec > ./spec/developer This is not the directory structure currently used. At the moment the specs are residing in the 'test' direrectory. The test directory closely matches the contents of the lib directory. One example will make things cleae: lib/og.rb lib/og/model.rb lib/og/model/timestamped.rb .. and test/og.rb test/og/model.rb test/og/model/timestamped.rb Next, should spec files correspond to the file name containing the > code they spec, or the class/module name? If you think the file name, > then what should be done with directory structures? Or should there be > no such ties that bind? see the above example. > Related to the last issue: should file naming be <...>_spec.rb, or > without the _spec extension? no _spec extension. Finally, if anyone specs an example or a benchmark should these be in > separate directories? examples/blog/* -> examples/blog/test/* dunno why you would like to test a benchmark. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/2185673c/attachment.html From george.moschovitis at gmail.com Mon Sep 3 01:01:59 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 08:01:59 +0300 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <46DA0B28.5040701@arnebrasseur.net> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <46DA0B28.5040701@arnebrasseur.net> Message-ID: > > I hope this answers some of your questions. George, could you please let > us in on what you have in mind regarding the tests/specs? > I have improved slightly the directory structure of tests. I plan to cleanup up and move tests from the hidden directory to the new test directory on a file-by-file basis. I will also remove some tests for deprecated functionality. I want to first convert nitro with the latest version of facets 2 though. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/cf5c508d/attachment.html From george.moschovitis at gmail.com Mon Sep 3 01:15:00 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 08:15:00 +0300 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> Message-ID: > > Basically my situation is I have been employed for the last 3 years > doing sysadmin, DBA and Rails work, but I've recently handed my > ...since I read anything about it. I'm drawn to it because from what > I've seen, it seems to have a sense of beauty that Rails lacks. > (Rails is very clever, but it sure can be ugly at times.) I am glad you appreciate Nitro's aesthetics ;-) - Og - > > I have a very database-centric view of web apps: I see the data as > the core of any project and the application just a means to do > something useful with it. This seem at odds with the Og philosophy > that the object model is key, and the database is used to support it. > > With Rails, I am constantly doing database-level changes, like > renaming columns, moving columns from one table to another, inserting > or deleting static data, setting arbitrary constraints (eg CHECK). > The blog example makes it look like everything must be done with Og > black magic. > > Will I need to build my own migration system to get the level of > database control I'm used to? (Or I could hijack ActiveRecord > Migrations for this, I guess.) Og works both as an object-to-relational mapper (default mode) and as a relational to object mapper. Ie, you can manually change your schema (as you do in AR) and just add your attributes to your classes. If you follow some simple conventions with your schema changes everything will work. I am doing this all the time. Please note that Og also provides an *automatic* evolution schema. For example if you add or remove or rename attributes in your model classes, Og automatically detects theses changes and automatically changes the relational schema accordingly. > RSpec for each of the MVC layers? How about integration tests - are > there any best practices for integrating, say Watir into a Nitro > app's development cycle? Older versions of Nitro offered support for unit/integration testing. This code is currently out-of-date in the repository version :( I plan to actively work on this, this month though. I *need* testing infrastructure for my current project so you can be sure that testing support will be back sooner rather than later. One nice thing about Rails due to its popularity relative maturity is > that if you've thought about it, at least three other people have > too, and one has certainly written a plugin for it. What's the > situation in Nitro? Is there a lot of wheel-reinvention needed for > things Rails people take for granted? I'm sure this is very much > dependent on the exact problem you are trying to solve. Nitro is quite compatible with Rails. I find it *extremely* easy to 'convert' most Rails plugins for my own usage. > If I > start building a Nitro app tomorrow, will I find myself spending the > first month just trying to figure out basic things? The lack of proper documentation is the biggest problem in Nitro. But the mailing list is pretty helpful. I would say go for it, and we will help you as much as possible. I've been a bit spoilt by RJS. Will I be forced to (finally, > grudgingly) learn JavaScript? Does Nitro have an equivalent means of > sending multiple updates to a page? With RJS, I can pretty much > reconfigure a whole page with a few lines of Ruby. It's often not > perfect, but it's a real time saver. The latest versions of Nitro promote the usage of JQuery. JQuery renders a system like RJS obsolete. You can do everythinthing just as consize and be more flexible with JQuery. Now that you mention it, I will keep in mind to provide some example about how I am using JQuery with nitro for some cool and extremely easy to implement ajax effects. JQuery is so powerfull that I decided to remove all the old javascript helpers. You just don't need helpers with JQuery. - Real World Use - > > Are there any lists of Nitro-powered sites so I can see what people > have achieved? I don't doubt you can build large, robust apps with > Nitro (I still work with people who question if you can do that with > Rails), I'd just like to know what they are. > I am about to use Nitro on a *really big project*. Some earlier public exaples are: - www.cull.gr - www.joyerz.com - www.phidz.com - www.ruby-doc.org I hope this helps, -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/4d8cea2d/attachment.html From arne at arnebrasseur.net Mon Sep 3 02:23:41 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 14:23:41 +0800 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> Message-ID: <46DBA86D.1030509@arnebrasseur.net> George Moschovitis schreef: > dunno why you would like to test a benchmark. > Performance characteristics _can_ be part of a specification. The hard part is choosing good benchmark boundaries, since this greatly depends on the environment the tests run in. It wouldn't really count as a unit test, since it's not always reproducable. I would see it more as a sort of sanity check. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From mvyver at gmail.com Mon Sep 3 02:50:35 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 16:50:35 +1000 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> Message-ID: <389c43e40709022350q40e49d87qa5403a9949253391@mail.gmail.com> ... > > I have a very database-centric view of web apps: I see the data as > > the core of any project and the application just a means to do > > something useful with it. This seem at odds with the Og philosophy > > that the object model is key, and the database is used to support it. I'm new to OG but I had formed the view that OG tries to make the data(base) and the OG model indistiguishable - as much as that can be done. So it seems to me that your db-centric view and OGs' approach match? > > With Rails, I am constantly doing database-level changes, like > > renaming columns, moving columns from one table to another, inserting > > or deleting static data, setting arbitrary constraints (eg CHECK). I'm using OG because my understanding - confirmed in an earlier email was that this duplication of effort is eliminated if you use OG in its default mode (a data mapper). If control of the db/table structure is outside of your control (fortunately not my situation), or you manually want to make some db changes, then it seems you can still use OG as a data wrapper. > > The blog example makes it look like everything must be done with Og > > black magic. Maybe that should be Ruby black magic? OG implements some neat ideas but seems to do it in a very 'Ruby-way'. Lots of Meta programming (all very new to me, but _very_ interesting.) Another reason I chose OG is because it seems to be more ruby like. This impression I formed from some emails - I've not used Rails/AR so I could be off the mark here. My 2c :) Mark > > Will I need to build my own migration system to get the level of > > database control I'm used to? (Or I could hijack ActiveRecord > > Migrations for this, I guess.) > > Og works both as an object-to-relational mapper (default mode) and as a > relational to object mapper. Ie, > you can manually change your schema (as you do in AR) and just add your > attributes to your classes. If you follow > some simple conventions with your schema changes everything will work. I am > doing this all the time. > > Please note that Og also provides an *automatic* evolution schema. For > example if you add or remove or rename attributes > in your model classes, Og automatically detects theses changes and > automatically changes the relational schema > accordingly. > > > RSpec for each of the MVC layers? How about integration tests - are > > there any best practices for integrating, say Watir into a Nitro > > app's development cycle? > > Older versions of Nitro offered support for unit/integration testing. This > code is currently out-of-date in the repository > version :( I plan to actively work on this, this month though. I *need* > testing infrastructure for my current project so you can be sure that > testing support will be back sooner rather than later. > > > One nice thing about Rails due to its popularity relative maturity is > > that if you've thought about it, at least three other people have > > too, and one has certainly written a plugin for it. What's the > > situation in Nitro? Is there a lot of wheel-reinvention needed for > > things Rails people take for granted? I'm sure this is very much > > dependent on the exact problem you are trying to solve. > > Nitro is quite compatible with Rails. I find it *extremely* easy to > 'convert' most Rails plugins for my own usage. > > > If I > > start building a Nitro app tomorrow, will I find myself spending the > > first month just trying to figure out basic things? > > The lack of proper documentation is the biggest problem in Nitro. But the > mailing list is pretty helpful. I would say go for it, and we will help you > as much as possible. > > > I've been a bit spoilt by RJS. Will I be forced to (finally, > > grudgingly) learn JavaScript? Does Nitro have an equivalent means of > > sending multiple updates to a page? With RJS, I can pretty much > > reconfigure a whole page with a few lines of Ruby. It's often not > > perfect, but it's a real time saver. > > The latest versions of Nitro promote the usage of JQuery. JQuery renders a > system like RJS obsolete. You can do everythinthing just as consize and be > more flexible with JQuery. Now that you mention it, I will keep in mind to > provide some example about how I am using JQuery with nitro for some cool > and extremely easy to implement ajax effects. JQuery is so powerfull that I > decided to remove all the old javascript helpers. You just don't need > helpers with JQuery. > > > - Real World Use - > > > > Are there any lists of Nitro-powered sites so I can see what people > > have achieved? I don't doubt you can build large, robust apps with > > Nitro (I still work with people who question if you can do that with > > Rails), I'd just like to know what they are. > > > > I am about to use Nitro on a *really big project*. Some earlier public > exaples are: > > - www.cull.gr > - www.joyerz.com > - www.phidz.com > - www.ruby-doc.org > > > > I hope this helps, > > -g. > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From mvyver at gmail.com Mon Sep 3 02:57:29 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 16:57:29 +1000 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> Message-ID: <389c43e40709022357n4253a75chb6fe38607524deb8@mail.gmail.com> > > > nk we should maybe consider a directory structure: > > ./spec > > ./spec/developer > > This is not the directory structure currently used. At the moment the specs > are residing in the 'test' direrectory. The > test directory closely matches the contents of the lib directory. One > example will make things cleae: > > lib/og.rb > lib/og/model.rb > lib/og/model/timestamped.rb ... > and > > test/og.rb > test/og/model.rb > test/og/model/timestamped.rb ... OK I think this is the layout Arne mentioned. He thought it was out of favor. It seems not? I'll replicate the source tree location for any test/spec I submit - unless I hear other wise. mv > > > Next, should spec files correspond to the file name containing the > > code they spec, or the class/module name? If you think the file name, > > then what should be done with directory structures? Or should there be > > no such ties that bind? > > see the above example. > > > Related to the last issue: should file naming be <...>_spec.rb, or > > without the _spec extension? > > no _spec extension. > > > Finally, if anyone specs an example or a benchmark should these be in > > separate directories? > > > examples/blog/* > -> > examples/blog/test/* > > dunno why you would like to test a benchmark. > > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From mvyver at gmail.com Mon Sep 3 03:05:44 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 17:05:44 +1000 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <46DBA86D.1030509@arnebrasseur.net> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <46DBA86D.1030509@arnebrasseur.net> Message-ID: <389c43e40709030005x44194ceej51732216343d63c6@mail.gmail.com> On 9/3/07, Arne Brasseur wrote: > George Moschovitis schreef: > > dunno why you would like to test a benchmark. > > > Performance characteristics _can_ be part of a specification. The hard > part is choosing good benchmark boundaries, since this greatly depends > on the environment the tests run in. > > It wouldn't really count as a unit test, since it's not always > reproducable. I would see it more as a sort of sanity check. Yep, that's possible. My thought was more for in the development cycle, maybe use fixture(s) to have a quick way of testing if a change improves or harms performance, and to get RSpecs' verification/signal that all is well in that part of the code. Haven't fully worked this out. MV From arne at arnebrasseur.net Mon Sep 3 03:32:32 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 15:32:32 +0800 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <389c43e40709022357n4253a75chb6fe38607524deb8@mail.gmail.com> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <389c43e40709022357n4253a75chb6fe38607524deb8@mail.gmail.com> Message-ID: <46DBB890.5020600@arnebrasseur.net> Mark Van De Vyver schreef: > OK I think this is the layout Arne mentioned. He thought it was out > of favor. It seems not? > What I meant to say was that it is/was possible to deviate from this pattern if it seems/seemed practical, although I can't at the moment recall why it was felt necessary. Sorry if I wasn't being clear. I'm not a native speaker. I still feel there should be a place to put spec "helpers" like special models, controllers, rspec matchers, etc. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From george.moschovitis at gmail.com Mon Sep 3 03:42:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 10:42:41 +0300 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: <46DBB890.5020600@arnebrasseur.net> References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <389c43e40709022357n4253a75chb6fe38607524deb8@mail.gmail.com> <46DBB890.5020600@arnebrasseur.net> Message-ID: > > I still feel there should be a place to put spec "helpers" like special > models, controllers, rspec matchers, etc. > test/raw/... helpers in: test/helper.rb test/helper/... -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/c64ee8f6/attachment.html From arne at arnebrasseur.net Mon Sep 3 03:47:38 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 15:47:38 +0800 Subject: [Nitro] Nitro/OG spec convention/organization questions In-Reply-To: References: <389c43e40709011729u5ada0339m981c97995747f2bb@mail.gmail.com> <389c43e40709022357n4253a75chb6fe38607524deb8@mail.gmail.com> <46DBB890.5020600@arnebrasseur.net> Message-ID: <46DBBC1A.5050107@arnebrasseur.net> George Moschovitis schreef: > helpers in: > > test/helper.rb > test/helper/... > Perfect! Thank you (ab) > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/a79ebc72/attachment.html From mvyver at gmail.com Mon Sep 3 04:24:45 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 18:24:45 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: <389c43e40709030124k3172e2cbtc56deb469212fff8@mail.gmail.com> > **SHOW STOPPER** ... Ignore that - my stale Ruby at fault of this one. .... > **trivial** > 3) Og#connect seems to make two selects from a table that has just > been created. I haven't dug in to see why, but thought I give a > 'heads-up' in case they shouldn't be there. The queries I refer to > are issued from within OG#connect, the attached files should print > out: > > INFO: Og uses the Mysql store. > DEBUG: Og manageable classes: [Member] > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > `address1` text, `city` text, `state` text, `email` text, `oid` > integer AUTO_INCREMENT PRIMARY KEY) > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > DEBUG: SELECT * FROM `ogmember` LIMIT 1 This I've tracked down to: [./og/lib/sql.rb] Line 290 Line 291 In line sql.rb:290 SQLEnchantMixin#og_create_scheme is called, which in turn calls SQLStore#create_field_map. In line sql.rb:290 SQLStore#create_field_map is called again. Hence the duplicated queries to the database whenever a table is created. I'm not sure how to fix this, but hope this helps someone. I'm happy to help test if needed. Mark > Using the Sqlite adapter I see something slightly different, but still > the duplicate `'SELECT': > > INFO: Og uses the Sqlite store. > DEBUG: Og manageable classes: [Member] > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > address1 text, city text, state text, email text, oid integer PRIMARY > KEY) > INFO: Created table ogmember. > DEBUG: SELECT * FROM ogmember LIMIT 1 > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > HTH > Mark > > From george.moschovitis at gmail.com Mon Sep 3 04:39:47 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 11:39:47 +0300 Subject: [Nitro] Og tests helper Message-ID: Dear devs, I have a little problem with the rspec infrastructure 'borrowed' from Ramaze. when I run the (few) og tests with rake test:og I get: (in /home/gmosx/code/public) Running og... [ 1 specs - 0 failed ] Running og/store/sql... [ 1 specs - 0 failed ] Running og/validation... [ 1 specs - all passed ] -------------------------------------[ og ]------------------------------------- ExitStatus: # StdOut: Database "test" dropped . Finished in 0.136994 seconds 1 example, 0 failures The problem seems to be that the system command used to drop the database before each test. It seems to trigger the error code in script/lib/wrap.rb... If you run the tests one by one they work. Michael, Jonathan, Arne, do you have any idea? -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/2def5b21/attachment.html From arne at arnebrasseur.net Mon Sep 3 04:59:00 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 16:59:00 +0800 Subject: [Nitro] Og tests helper In-Reply-To: References: Message-ID: <46DBCCD4.3070901@arnebrasseur.net> I'm trying to reproduce this here so I can better understand the issue. Is there a preferred way to tell the og tests about my MySql configuration? (ab) George Moschovitis schreef: > Dear devs, > > I have a little problem with the rspec infrastructure 'borrowed' from > Ramaze. > > when I run the (few) og tests with > > rake test:og > > I get: > > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the > database before each test. It seems to trigger the error code in > script/lib/wrap.rb... > > If you run the tests one by one they work. > > Michael, Jonathan, Arne, do you have any idea? > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/5ca8bba9/attachment-0001.html From george.moschovitis at gmail.com Mon Sep 3 05:00:54 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 12:00:54 +0300 Subject: [Nitro] Og tests helper In-Reply-To: <46DBCCD4.3070901@arnebrasseur.net> References: <46DBCCD4.3070901@arnebrasseur.net> Message-ID: I use $ export DB_PASSWORD=",sql51e' you can also change the settings in og/test/helper.rb -g. On 9/3/07, Arne Brasseur wrote: > > I'm trying to reproduce this here so I can better understand the issue. > Is there a preferred way to tell the og tests about my MySql configuration? > > (ab) > > George Moschovitis schreef: > > Dear devs, > > I have a little problem with the rspec infrastructure 'borrowed' from > Ramaze. > > when I run the (few) og tests with > > rake test:og > > I get: > > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the database > before each test. It seems to trigger the error code in > script/lib/wrap.rb... > > If you run the tests one by one they work. > > Michael, Jonathan, Arne, do you have any idea? > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.netarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/06f43bad/attachment.html From arne at arnebrasseur.net Mon Sep 3 05:31:34 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 17:31:34 +0800 Subject: [Nitro] Og tests helper In-Reply-To: References: Message-ID: <46DBD476.7060207@arnebrasseur.net> George Moschovitis schreef: > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the > database before each test. It seems to trigger the error code in > script/lib/wrap.rb... Actually the problem seems to be that some ANSI control codes (or something that looks like it) are sent to StdErr. Because the test outputs on StdErr it is shown in red and the details are given. If you change line 159 in script/lib/wrap.rb from puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr to puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr.inspect you will see this: -------------------------------------[ og ]------------------------------------- ExitStatus: # StdOut: . Finished in 0.418628 seconds 1 example, 0 failures StdErr: "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" nil --------------------------------[ og/store/sql ]-------------------------------- ExitStatus: # StdOut: . Finished in 0.359741 seconds 1 example, 0 failures StdErr: "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From work at ashleymoran.me.uk Mon Sep 3 05:43:34 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Mon, 3 Sep 2007 10:43:34 +0100 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> Message-ID: <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> On 3 Sep 2007, at 06:15, George Moschovitis wrote: > Og works both as an object-to-relational mapper (default mode) and > as a relational to object mapper. Ie, > you can manually change your schema (as you do in AR) and just add > your attributes to your classes. If you follow > some simple conventions with your schema changes everything will > work. I am doing this all the time. Ok cool - I could not see any structure to help Og handle manual schema changes. As long as I can > Please note that Og also provides an *automatic* evolution schema. > For example if you add or remove or rename attributes > in your model classes, Og automatically detects theses changes and > automatically changes the relational schema > accordingly. I noticed this. I'll have to take your word for it for now, sounds like black magic to me :) > Older versions of Nitro offered support for unit/integration > testing. This code is currently out-of-date in the repository > version :( I plan to actively work on this, this month though. I > *need* testing infrastructure for my current project so you can be > sure that testing support will be back sooner rather than later. Can I be any help with this? I won't start working on any web apps until I have the tools to work BDD, so I'm happy to help get RSpec working. > Nitro is quite compatible with Rails. I find it *extremely* easy to > 'convert' most Rails plugins for my own usage. I was hoping this might be the case, but without actually trying anything I had no idea. > The lack of proper documentation is the biggest problem in Nitro. > But the mailing list is pretty helpful. I would say go for it, and > we will help you as much as possible. Thanks - I think one of the best thing about programming in Ruby is the helpfulness of other developers. > The latest versions of Nitro promote the usage of JQuery. JQuery > renders a system like RJS obsolete. You can do everythinthing just > as consize and be more flexible with JQuery. Now that you mention > it, I will keep in mind to provide some example about how I am > using JQuery with nitro for some cool and extremely easy to > implement ajax effects. JQuery is so powerfull that I decided to > remove all the old javascript helpers. You just don't need helpers > with JQuery. When you say JQuery, do you mean ? If so, it looks pretty cool. I watched some of the examples here: . Can you sum up in a few words how JQuery replaces RJS? It looks all client-side to me. Is it possible to use JQuery when the exact data and effects are determined by the database? Whatever, it looks like I will have to learn JavaScript. Don't supppose you can recommend a good book? > I am about to use Nitro on a *really big project*. Some earlier > public exaples are: > > - www.cull.gr > - www.joyerz.com > - www.phidz.com > - www.ruby-doc.org I don't speak any greek - could you explain what's going on in this pic? > I hope this helps, Yes it does - I'm sold :) I have a few other things to get out of the way but hopefully I will be able to make a test Nitro app this week. It sounds like the leap from Rails will not be that big, and it looks like I won't lose anything important (apart from testing for the time being). Thanks! Ashley From arne at arnebrasseur.net Mon Sep 3 05:53:54 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 17:53:54 +0800 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> Message-ID: <46DBD9B2.3030407@arnebrasseur.net> Ashley Moran schreef: > Finally, is there any really cool stuff about Nitro will make me say > "I wish Rails could do that/did it that way"? I'm much more > impressed by elegant solutions to problems than I am put off by > things not working out of the box. > One of the things that impressed me was the Nitro 'compiler pipeline'. Basically a page in Nitro is rendered in two steps, in the first 'compilation' step the template is converted into code which is then evaluated every time the template is rendered. This compilation happens through a configurable pipeline of transformation steps. The transformations could be XML based or just working on the plain text. One of the IMHO coolest available out of the box is the 'Morpher', e.g.
...
  • #{item}
    • The nice thing is that everything that can be done at compilation is a one time overhead, so afterwards pages render ultra-fast. You could for instance turn the CSSDryer plugin from Rails into a compiler step, so you can write 'nested' CSS like this: #content { p { a {...} a:hover {} ... } } #sidebar { a {...} } (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From work at ashleymoran.me.uk Mon Sep 3 06:03:05 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Mon, 3 Sep 2007 11:03:05 +0100 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <389c43e40709022350q40e49d87qa5403a9949253391@mail.gmail.com> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <389c43e40709022350q40e49d87qa5403a9949253391@mail.gmail.com> Message-ID: On 3 Sep 2007, at 07:50, Mark Van De Vyver wrote: > I'm new to OG but I had formed the view that OG tries to make the > data(base) and the OG model indistiguishable - as much as that can be > done. So it seems to me that your db-centric view and OGs' approach > match? From George's response it sounds like Og is pretty flexible with regards to migrating the schema. I'll have to play around with it now and see how it works. I don't think *any* ORM layer perfectly maps objects to and from the database, but the code I've seen does look pretty smart. > I'm using OG because my understanding - confirmed in an earlier email > was that this > duplication of effort is eliminated if you use OG in its default mode > (a data mapper). > If control of the db/table structure is outside of your control > (fortunately not my situation), or you manually want to make some db > changes, then it seems you can still use OG as a data wrapper. When you say data mapper, do you mean in the Martin Fowler sense? () At first glance, Og looks like it also follows the Active Record pattern. The automatic schema migrations sound clever, and I don't have any legacy schemas to worry about, but I will certainly need the ability to run custom SQL. For example, to create a partial index on a column, or update static data. > Maybe that should be Ruby black magic? OG implements some neat ideas > but seems to do it in a very 'Ruby-way'. Lots of Meta programming > (all very new to me, but _very_ interesting.) > Another reason I chose OG is because it seems to be more ruby like. > This impression I formed from some emails - I've not used Rails/AR so > I could be off the mark here. When I said Og black magic, I was thinking more of the automatic schema generation. I'm sure there's plenty of cool metaprogramming in there - it wouldn't be Ruby otherwise! In Rails, there's plenty of stuff that looks clever (and IS clever), but makes testing your app a real pain. Anyway George has convinced me that Nitro is worth a look so I will start experimenting very soon. Ashley From mvyver at gmail.com Mon Sep 3 06:03:50 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 20:03:50 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40709030124k3172e2cbtc56deb469212fff8@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> <389c43e40709030124k3172e2cbtc56deb469212fff8@mail.gmail.com> Message-ID: <389c43e40709030303l379e4cf5q6ef8f754905dc096@mail.gmail.com> > > INFO: Og uses the Mysql store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > > `address1` text, `city` text, `state` text, `email` text, `oid` > > integer AUTO_INCREMENT PRIMARY KEY) > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > This I've tracked down to: > [./og/lib/sql.rb] > Line 290 > Line 291 > > In line sql.rb:290 SQLEnchantMixin#og_create_scheme is called, which > in turn calls SQLStore#create_field_map. The full route to the first call of SQLStore#create_field_map is: sql.rb:290 og_create_scheme sql.rb:79 evolve_schema evolution.rb:59 create_field_map The second call of SQLStore#create_field_map is: sql.rb:291 create_field_map > > Hence the duplicated queries to the database whenever a table is created. > > I'm not sure how to fix this, but hope this helps someone. > I'm happy to help test if needed. > > Mark > > > Using the Sqlite adapter I see something slightly different, but still > > the duplicate `'SELECT': > > > > INFO: Og uses the Sqlite store. > > DEBUG: Og manageable classes: [Member] > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > > address1 text, city text, state text, email text, oid integer PRIMARY > > KEY) > > INFO: Created table ogmember. > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > > > > HTH > > Mark > > > > > From arne at arnebrasseur.net Mon Sep 3 06:12:40 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 03 Sep 2007 18:12:40 +0800 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> Message-ID: <46DBDE18.8030708@arnebrasseur.net> Ashley Moran schreef: > I don't speak any greek - could you explain what's going on in this > pic? > Interesting :) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From work at ashleymoran.me.uk Mon Sep 3 06:28:35 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Mon, 3 Sep 2007 11:28:35 +0100 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <46DBD9B2.3030407@arnebrasseur.net> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <46DBD9B2.3030407@arnebrasseur.net> Message-ID: On 3 Sep 2007, at 10:53, Arne Brasseur wrote: > One of the things that impressed me was the Nitro 'compiler pipeline'. > Basically a page in Nitro is rendered in two steps, in the first > 'compilation' step the template is converted into code which is then > evaluated every time the template is rendered. This compilation > happens > through a configurable pipeline of transformation steps. The > transformations could be XML based or just working on the plain text. I noticed something clever was going on in the views :) I have to say, I won't miss ERb. Am I right that Nitro templates are all valid XML? > One of the IMHO coolest available out of the box is the 'Morpher', > e.g. > >
    ...
    > >
  • #{item}
    • Snazzy! This clearly needs more investigation. It reminds me of Yurii Rashkovski's Lilu () which I'm pretty sure he is using for his new issuesdone.com project. Lilu is cool because you can preview the templates in a browser. Looks like the "Morpher" has a similar idea but embeds the code as XML attributes. > The nice thing is that everything that can be done at compilation is a > one time overhead, so afterwards pages render ultra-fast. I saw the example "hello" app has compiled and dynamic includes, but my Webrick started going weird when I was running it last night, and stopped responding to requests, so I gave up. > You could for instance turn the CSSDryer plugin from Rails into a > compiler step, so you can write 'nested' CSS like this: > > #content { > p { > a {...} > a:hover {} > ... > } > } > > #sidebar { > a {...} > } Now I'm getting excited :) For my current Rails project at work I built a dynamic CSS renderer, so can I write things like html, body { font-family: Arial, Helvetica, sans-serif; font-size: 12px; background: <%= @colours[:background] %> url(../images/bg.gif) repeat-y top center; } I'll have to see how I can do this in Nitro, I may well need it for my own work. Ashley From work at ashleymoran.me.uk Mon Sep 3 06:29:47 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Mon, 3 Sep 2007 11:29:47 +0100 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <46DBDE18.8030708@arnebrasseur.net> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> <46DBDE18.8030708@arnebrasseur.net> Message-ID: <35D2AD40-AE00-4A75-95BA-14A758E81203@ashleymoran.me.uk> On 3 Sep 2007, at 11:12, Arne Brasseur wrote: > Ashley Moran schreef: >> I don't speak any greek - could you explain what's going on in this >> pic? >> > Interesting :) I'm not sure it's the strangest thing on cull.gr either! From mvyver at gmail.com Mon Sep 3 07:32:59 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 21:32:59 +1000 Subject: [Nitro] OG draft patch: Eliminate the duplicate query seen in calls to og_create_schema Message-ID: <389c43e40709030432y41371b53l92ad2a0de009de4e@mail.gmail.com> Hi Devs, Attached is a draft patch that should eliminate the duplicate query when og_create_schema is run. I guess this is likely only to have hurt your performace if you have to create lots of tables (my use case), have a very slow connection, or a DB that is under heavy load? Anyway it was an interesting exercise to try and come to grips with some of the OG code - I don't fully understand the different roles of the different SQLEnchant* modules.... This is my first open source patch so don't expect too much :) Seriously, _when_ the guts of this change is OK, then I'll dump all the commented code and submit a cleaner patch. I've tested with the Sqlite and Mysql stores/adapters. Hopefully a more constructive email than some of the noise I've been sending lately - steep learning curve :) Mark From mvyver at gmail.com Mon Sep 3 07:34:15 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 3 Sep 2007 21:34:15 +1000 Subject: [Nitro] OG draft patch: Eliminate the duplicate query seen in calls to og_create_schema In-Reply-To: <389c43e40709030432y41371b53l92ad2a0de009de4e@mail.gmail.com> References: <389c43e40709030432y41371b53l92ad2a0de009de4e@mail.gmail.com> Message-ID: <389c43e40709030434o467f8d9ah4c47df835a27f7d0@mail.gmail.com> This time with the patch... been a long day :) On 9/3/07, Mark Van De Vyver wrote: > Hi Devs, > > Attached is a draft patch that should eliminate the duplicate query > when og_create_schema is run. I guess this is likely only to have > hurt your performace if you have to create lots of tables (my use > case), have a very slow connection, or a DB that is under heavy load? > > Anyway it was an interesting exercise to try and come to grips with > some of the OG code - I don't fully understand the different roles of > the different SQLEnchant* modules.... > > This is my first open source patch so don't expect too much :) > > Seriously, _when_ the guts of this change is OK, then I'll dump all > the commented code and submit a cleaner patch. > I've tested with the Sqlite and Mysql stores/adapters. > > Hopefully a more constructive email than some of the noise I've been > sending lately - steep learning curve :) > > Mark > -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070803-1-1-draft Type: application/octet-stream Size: 61254 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070903/08ca118e/attachment-0001.obj From george.moschovitis at gmail.com Mon Sep 3 09:08:07 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 16:08:07 +0300 Subject: [Nitro] Og tests helper In-Reply-To: <46DBD476.7060207@arnebrasseur.net> References: <46DBD476.7060207@arnebrasseur.net> Message-ID: shouldn't it say: x/all passed instead of 0 failed ? -g. On 9/3/07, Arne Brasseur wrote: > > George Moschovitis schreef: > > (in /home/gmosx/code/public) > > Running og... [ 1 specs - 0 failed ] > > Running og/store/sql... [ 1 specs - 0 failed ] > > Running og/validation... [ 1 specs - all passed ] > > -------------------------------------[ og > > ]------------------------------------- > > ExitStatus: > > # > > StdOut: > > Database "test" dropped > > . > > > > Finished in 0.136994 seconds > > > > 1 example, 0 failures > > > > The problem seems to be that the system command used to drop the > > database before each test. It seems to trigger the error code in > > script/lib/wrap.rb... > Actually the problem seems to be that some ANSI control codes (or > something that looks like it) are sent to StdErr. Because the test > outputs on StdErr it is shown in red and the details are given. If you > change line 159 in script/lib/wrap.rb from > puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr > to > puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr.inspect > > you will see this: > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > . > > Finished in 0.418628 seconds > > 1 example, 0 failures > StdErr: > "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" > nil > --------------------------------[ og/store/sql > ]-------------------------------- > ExitStatus: > # > StdOut: > . > > Finished in 0.359741 seconds > > 1 example, 0 failures > StdErr: > "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" > > > > (ab) > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/d6fd91ee/attachment.html From aurelianocalvo at yahoo.com.ar Mon Sep 3 09:21:11 2007 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Mon, 3 Sep 2007 10:21:11 -0300 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <46DBDE18.8030708@arnebrasseur.net> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> <46DBDE18.8030708@arnebrasseur.net> Message-ID: <1340963a0709030621l100eb600w2fb8ae80d29daa9f@mail.gmail.com> > > I don't speak any greek - could you explain what's going on in this > > pic? > > > Interesting :) I know no greek, but this was in the news here in Argentina. It seems that in some part of Australia (I don't know where) because of the climate change (or something) a river changed its volume and when this water mixed with the salty sea water, generated lots and lots of foam. These pictures show the generated foam. From george.moschovitis at gmail.com Mon Sep 3 09:40:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 16:40:40 +0300 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40709030303l379e4cf5q6ef8f754905dc096@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> <389c43e40709030124k3172e2cbtc56deb469212fff8@mail.gmail.com> <389c43e40709030303l379e4cf5q6ef8f754905dc096@mail.gmail.com> Message-ID: Nice, I guess we can remove line 291 then? -g. On 9/3/07, Mark Van De Vyver wrote: > > > > INFO: Og uses the Mysql store. > > > DEBUG: Og manageable classes: [Member] > > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text, > > > `address1` text, `city` text, `state` text, `email` text, `oid` > > > integer AUTO_INCREMENT PRIMARY KEY) > > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > DEBUG: SELECT * FROM `ogmember` LIMIT 1 > > > > This I've tracked down to: > > [./og/lib/sql.rb] > > Line 290 > > Line 291 > > > > In line sql.rb:290 SQLEnchantMixin#og_create_scheme is called, which > > in turn calls SQLStore#create_field_map. > > The full route to the first call of SQLStore#create_field_map is: > sql.rb:290 og_create_scheme > sql.rb:79 evolve_schema > evolution.rb:59 create_field_map > > The second call of SQLStore#create_field_map is: > sql.rb:291 create_field_map > > > > > > Hence the duplicated queries to the database whenever a table is > created. > > > > I'm not sure how to fix this, but hope this helps someone. > > I'm happy to help test if needed. > > > > Mark > > > > > Using the Sqlite adapter I see something slightly different, but still > > > the duplicate `'SELECT': > > > > > > INFO: Og uses the Sqlite store. > > > DEBUG: Og manageable classes: [Member] > > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text, > > > address1 text, city text, state text, email text, oid integer PRIMARY > > > KEY) > > > INFO: Created table ogmember. > > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > DEBUG: SELECT * FROM ogmember LIMIT 1 > > > > > > > > > HTH > > > Mark > > > > > > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/b389eb61/attachment.html From george.moschovitis at gmail.com Mon Sep 3 09:43:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 16:43:33 +0300 Subject: [Nitro] OG draft patch: Eliminate the duplicate query seen in calls to og_create_schema In-Reply-To: <389c43e40709030434o467f8d9ah4c47df835a27f7d0@mail.gmail.com> References: <389c43e40709030432y41371b53l92ad2a0de009de4e@mail.gmail.com> <389c43e40709030434o467f8d9ah4c47df835a27f7d0@mail.gmail.com> Message-ID: Thanks for the patch, I will see if I can further cleanup the code. -g. On 9/3/07, Mark Van De Vyver wrote: > > This time with the patch... been a long day :) > > On 9/3/07, Mark Van De Vyver wrote: > > Hi Devs, > > > > Attached is a draft patch that should eliminate the duplicate query > > when og_create_schema is run. I guess this is likely only to have > > hurt your performace if you have to create lots of tables (my use > > case), have a very slow connection, or a DB that is under heavy load? > > > > Anyway it was an interesting exercise to try and come to grips with > > some of the OG code - I don't fully understand the different roles of > > the different SQLEnchant* modules.... > > > > This is my first open source patch so don't expect too much :) > > > > Seriously, _when_ the guts of this change is OK, then I'll dump all > > the commented code and submit a cleaner patch. > > I've tested with the Sqlite and Mysql stores/adapters. > > > > Hopefully a more constructive email than some of the noise I've been > > sending lately - steep learning curve :) > > > > Mark > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/420e4923/attachment.html From george.moschovitis at gmail.com Mon Sep 3 11:33:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 3 Sep 2007 18:33:18 +0300 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> Message-ID: > > I noticed this. I'll have to take your word for it for now, sounds > like black magic to me :) it is relatively easy to implement, nothing magic. But it is certainly nice to have in practice. Can I be any help with this? I won't start working on any web apps > until I have the tools to work BDD, so I'm happy to help get RSpec > working. I would suggest that you have a look at the two examples and the tests for the following days. Then as you get more experienced, you can help me with the testing infrastructure. I was hoping this might be the case, but without actually trying > anything I had no idea. trust me, it is quite easy. When you say JQuery, do you mean ? If so, it > looks pretty cool. yeap. I watched some of the examples here: docs.jquery.com/Tutorials:Live_Examples_of_jQuery>. Can you sum up > in a few words how JQuery replaces RJS? It looks all client-side to > me. Is it possible to use JQuery when the exact data and effects are > determined by the database? I will post some examples over the next days. Whatever, it looks like I will have to learn JavaScript. Don't > supppose you can recommend a good book? there is a jquery book, have a look at their site. > > I don't speak any greek - could you explain what's going on in this > pic? it is just a fuuny pic. Yes it does - I'm sold :) I have a few other things to get out of > the way but hopefully I will be able to make a test Nitro app this > week. It sounds like the leap from Rails will not be that big, and > it looks like I won't lose anything important (apart from testing for > the time being). that's great, if you need help just ask! -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070903/717c577c/attachment-0001.html From arne at arnebrasseur.net Mon Sep 3 13:30:59 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 04 Sep 2007 01:30:59 +0800 Subject: [Nitro] Og tests helper In-Reply-To: References: <46DBD476.7060207@arnebrasseur.net> Message-ID: <46DC44D3.1070000@arnebrasseur.net> George Moschovitis schreef: > shouldn't it say: x/all passed instead of 0 failed ? > I suppose it only says that when StdErr is empty, but I'll look in to it and get back to you tomorrow. If I ever want to get accustomed to the Taiwanese time zone I should go to sleep now. (ab) > -g. > > On 9/3/07, *Arne Brasseur* > wrote: > > George Moschovitis schreef: > > (in /home/gmosx/code/public) > > Running og... [ 1 specs - 0 failed ] > > Running og/store/sql... [ 1 specs - 0 failed ] > > Running og/validation... [ 1 specs - all passed ] > > -------------------------------------[ og > > ]------------------------------------- > > ExitStatus: > > # > > StdOut: > > Database "test" dropped > > . > > > > Finished in 0.136994 seconds > > > > 1 example, 0 failures > > > > The problem seems to be that the system command used to drop the > > database before each test. It seems to trigger the error code in > > script/lib/wrap.rb... > Actually the problem seems to be that some ANSI control codes (or > something that looks like it) are sent to StdErr. Because the test > outputs on StdErr it is shown in red and the details are given. If you > change line 159 in script/lib/wrap.rb from > puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr > to > puts "StdOut:".yellow, @stdout, "StdErr:".yellow, @stderr.inspect > > you will see this: > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > . > > Finished in 0.418628 seconds > > 1 example, 0 failures > StdErr: > "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" > nil > --------------------------------[ og/store/sql > ]-------------------------------- > ExitStatus: > # > StdOut: > . > > Finished in 0.359741 seconds > > 1 example, 0 failures > StdErr: > "\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m\e[32m\e[0m" > > > > (ab) > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070904/de5334ae/attachment.html From john at oxyliquit.de Mon Sep 3 19:18:33 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 04 Sep 2007 01:18:33 +0200 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: Hi, > I have seen this one, can't find where the second select comes from. Will > have to investigate further. just as a general debugging Og tip (even if it involves your own app): Put a `pp caller` in exec_statement(), it generates a lot of line-noise but is very helpful if there just doesn't seem to be a reason for an unexpected query. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Mon Sep 3 19:18:35 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 04 Sep 2007 01:18:35 +0200 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: Hi, > **SHOW STOPPER** > 1) The Og::SqlStore#exec_statement seems to rearrange the data > submitted in an sql string, and example of the original SQL statement > data and the SQL statement submitted to the MySQL store follows. >insert into ogmember ( address1,city,email,first_name,state,last_name > ) values ( '123 High > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone' > ) >DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`, > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com', > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik') a few questions: * where does the original come from? * which method are you using to generate that query? (.save?) I haven't had a problem yet where Og would 'rearrange' something, this would be quite a bug to have, as essentially nothing would work. exec_statement itself does nothing to the query (at least last I had a look at it, it'd make no sense anyway, as it would have to parse SQL since it only gets SQL). Where that could only happen (depending on the method you used for inserting): sql.rb: def insert_sql(..) That'd be the first place where I would make a few puts to find out if Og is the culprit or if the original object was populated wrong in the first place. Hope that leads to Og working better for you, Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From work at ashleymoran.me.uk Mon Sep 3 19:23:54 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Tue, 4 Sep 2007 00:23:54 +0100 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> Message-ID: <8F47E8E6-E65D-469E-A9C1-56C266DEB3C9@ashleymoran.me.uk> On Sep 03, 2007, at 4:33 pm, George Moschovitis wrote: > I would suggest that you have a look at the two examples and the > tests for the following days. Then as you get more experienced, you > can help me with the testing infrastructure. I'll do just that. I might try and write tests for the sample apps, and see how far I get. > I will post some examples over the next days. Cool - I think Nitro needs a few more examples. I'm sure you are busy working on Nitro though, and don't get much time to do stuff like that. > there is a jquery book, have a look at their site. I've ordered Learning jQuery and the jQuery Reference Guide - should keep me good for a while! > that's great, if you need help just ask! I'm sure I will be back :) The list has been great so far, thanks for everyone's help Ashley From mvyver at gmail.com Mon Sep 3 19:43:39 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Tue, 4 Sep 2007 09:43:39 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: <389c43e40709031643i765d0117x76b91599f299d73e@mail.gmail.com> Hi Jo > a few questions: You can ignore that report - a bug in my code :( Apologies. Mark > * where does the original come from? > * which method are you using to generate that query? (.save?) > > I haven't had a problem yet where Og would 'rearrange' something, > this would be quite a bug to have, as essentially nothing would work. > > exec_statement itself does nothing to the query (at least last I > had a look at it, it'd make no sense anyway, as it would have to > parse SQL since it only gets SQL). > > Where that could only happen (depending on the method you used for > inserting): sql.rb: def insert_sql(..) > > That'd be the first place where I would make a few puts to find > out if Og is the culprit or if the original object was populated > wrong in the first place. > > Hope that leads to Og working better for you, > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > From mvyver at gmail.com Mon Sep 3 19:46:39 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Tue, 4 Sep 2007 09:46:39 +1000 Subject: [Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial) In-Reply-To: References: <389c43e40708312348g6ccb7ab2k6f930332cd752696@mail.gmail.com> Message-ID: <389c43e40709031646i27f46773tcde5f4ca55105180@mail.gmail.com> Hi Jonathon > > I have seen this one, can't find where the second select comes from. Will > > have to investigate further. > > just as a general debugging Og tip (even if it involves your own app): > > Put a `pp caller` in exec_statement(), it generates a lot of line-noise > but is very helpful if there just doesn't seem to be a reason for an > unexpected query. Thanks for the `pp caller` tip. Re: the double select on `og_create_schema`, I've posted a patch of what works for me - I'm sure it could be improved :) Regards Mark > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Tue Sep 4 01:14:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 4 Sep 2007 08:14:37 +0300 Subject: [Nitro] Questions to help me evaluate Nitro In-Reply-To: <8F47E8E6-E65D-469E-A9C1-56C266DEB3C9@ashleymoran.me.uk> References: <79BF73B4-9FB3-4ABA-B10D-918A1BAD916A@ashleymoran.me.uk> <798AE3CB-5470-4E49-8119-24C3BCBACEBD@ashleymoran.me.uk> <8F47E8E6-E65D-469E-A9C1-56C266DEB3C9@ashleymoran.me.uk> Message-ID: > > Cool - I think Nitro needs a few more examples. I'm sure you are > busy working on Nitro though, and don't get much time to do stuff > like that. > I will probably convert the wiki example from older versions, stay tuned. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070904/53783d5d/attachment.html From arne at arnebrasseur.net Tue Sep 4 07:20:08 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 04 Sep 2007 19:20:08 +0800 Subject: [Nitro] Og tests helper In-Reply-To: References: Message-ID: <46DD3F68.2090001@arnebrasseur.net> I found the problem, although it took some Sherlock Holmes style investigation. Turns out the butler... uh I mean the logger did it. What's wrong with this code? def info(str) @@global_logger << Console::ANSICode.green @@global_logger.info(str) @@global_logger << Console::ANSICode.clear end def error(str) @@global_logger << Console::ANSICode.red @@global_logger.error(str) @@global_logger << Console::ANSICode.clear end The solution can be found in/pulled from my repo : http://darcs.arnebrasseur.net/glycerin (in /home/plexus/work/nitro_repo) Running og... [ 1 specs - all passed ] Running og/store/sql... [ 1 specs - all passed ] Running og/validation... [ 1 specs - all passed ] 3 examples, 0 failures No failing examples, let's add some tests! (ab) George Moschovitis schreef: > Dear devs, > > I have a little problem with the rspec infrastructure 'borrowed' from > Ramaze. > > when I run the (few) og tests with > > rake test:og > > I get: > > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the > database before each test. It seems to trigger the error code in > script/lib/wrap.rb... > > If you run the tests one by one they work. > > Michael, Jonathan, Arne, do you have any idea? > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070904/210c5a07/attachment-0001.html From arne at arnebrasseur.net Tue Sep 4 11:00:20 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 04 Sep 2007 23:00:20 +0800 Subject: [Nitro] [PATCH] proto template path now includes "app" Message-ID: <46DD7304.8010303@arnebrasseur.net> Pushed another one, seems like the proto application template path moved. hunk ./raw/lib/raw/controller/publishable.rb 151 - stack << File.join(Nitro.proto_path, "template", path).gsub(/\/$/, "") + stack << File.join(Nitro.proto_path, "app", "template", path).gsub(/\/$/, "") George, could you remind me : will Nitro 0.50 allow to have controller actions without template files, and if so, should this work by simply returning a string, or by using an explicit output function? (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From george.moschovitis at gmail.com Wed Sep 5 00:34:34 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 07:34:34 +0300 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: <46DD7304.8010303@arnebrasseur.net> References: <46DD7304.8010303@arnebrasseur.net> Message-ID: At the moment you have to call print "my output" -g. On 9/4/07, Arne Brasseur wrote: > > Pushed another one, seems like the proto application template path moved. > > hunk ./raw/lib/raw/controller/publishable.rb 151 > - stack << File.join(Nitro.proto_path, "template", > path).gsub(/\/$/, "") > + stack << File.join(Nitro.proto_path, "app", "template", > path).gsub(/\/$/, "") > > > George, could you remind me : will Nitro 0.50 allow to have controller > actions without template files, and if so, should this work by simply > returning a string, or by using an explicit output function? > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/e13710f2/attachment.html From george.moschovitis at gmail.com Wed Sep 5 04:58:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 11:58:31 +0300 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: <46DD7304.8010303@arnebrasseur.net> References: <46DD7304.8010303@arnebrasseur.net> Message-ID: please send me patch bundles, makes things a lot easier for me. -g. On 9/4/07, Arne Brasseur wrote: > > Pushed another one, seems like the proto application template path moved. > > hunk ./raw/lib/raw/controller/publishable.rb 151 > - stack << File.join(Nitro.proto_path, "template", > path).gsub(/\/$/, "") > + stack << File.join(Nitro.proto_path, "app", "template", > path).gsub(/\/$/, "") > > > George, could you remind me : will Nitro 0.50 allow to have controller > actions without template files, and if so, should this work by simply > returning a string, or by using an explicit output function? > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/c7f65426/attachment.html From arne at arnebrasseur.net Wed Sep 5 05:25:50 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 05 Sep 2007 17:25:50 +0800 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: References: <46DD7304.8010303@arnebrasseur.net> Message-ID: <46DE761E.2050005@arnebrasseur.net> George Moschovitis schreef: > please send me patch bundles, makes things a lot easier for me. No problem, you will find them in attachment. But isn't "darcs pull http://darcs.arnebrasseur.net/glycerin" easier? (ab) Tue Sep 4 19:12:14 CST 2007 Arne Brasseur * Fix colorful logging, don't output ANSI color codes for nothing Tue Sep 4 22:56:11 CST 2007 Arne Brasseur * proto template path now includes "app" > > -g. > > On 9/4/07, *Arne Brasseur* > wrote: > > Pushed another one, seems like the proto application template path > moved. > > hunk ./raw/lib/raw/controller/publishable.rb 151 > - stack << File.join(Nitro.proto_path, "template", > path).gsub(/\/$/, "") > + stack << File.join(Nitro.proto_path, "app", "template", > path).gsub(/\/$/, "") > > > George, could you remind me : will Nitro 0.50 allow to have controller > actions without template files, and if so, should this work by simply > returning a string, or by using an explicit output function? > > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/9339b208/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20070905.patch Type: text/x-patch Size: 60051 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070905/9339b208/attachment-0001.bin From arne at arnebrasseur.net Wed Sep 5 07:48:55 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 05 Sep 2007 19:48:55 +0800 Subject: [Nitro] Mini Nitro example Message-ID: <46DE97A7.4050809@arnebrasseur.net> I just coded up a very small Nitro app to assist me in blogging my Flickr pictures. Since the world seriously lacks Nitro examples, I decided to put it 'out there'. http://www.arnebrasseur.net/2007/09/05/scratching-my-flickr-itch-with-nitro/en/ I sincerely hope someone has a use for this (educational or otherwise). At least I do :-) cheers, (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From george.moschovitis at gmail.com Wed Sep 5 08:24:25 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 15:24:25 +0300 Subject: [Nitro] Mini Nitro example In-Reply-To: <46DE97A7.4050809@arnebrasseur.net> References: <46DE97A7.4050809@arnebrasseur.net> Message-ID: This looks very helpful for new comers, thank you! -g. On 9/5/07, Arne Brasseur wrote: > > I just coded up a very small Nitro app to assist me in blogging my > Flickr pictures. Since the world seriously lacks Nitro examples, I > decided to put it 'out there'. > > > http://www.arnebrasseur.net/2007/09/05/scratching-my-flickr-itch-with-nitro/en/ > > I sincerely hope someone has a use for this (educational or otherwise). > At least I do :-) > > cheers, > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/0616ce64/attachment.html From george.moschovitis at gmail.com Wed Sep 5 08:26:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 15:26:21 +0300 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: <46DE761E.2050005@arnebrasseur.net> References: <46DD7304.8010303@arnebrasseur.net> <46DE761E.2050005@arnebrasseur.net> Message-ID: I keep forgetting these repos ;-) -g. On 9/5/07, Arne Brasseur wrote: > > George Moschovitis schreef: > > please send me patch bundles, makes things a lot easier for me. > > No problem, you will find them in attachment. > > But isn't "darcs pull http://darcs.arnebrasseur.net/glycerin" easier? > > (ab) > > Tue Sep 4 19:12:14 CST 2007 Arne Brasseur > * Fix colorful logging, don't output ANSI color codes for nothing > > Tue Sep 4 22:56:11 CST 2007 Arne Brasseur > * proto template path now includes "app" > > > -g. > > On 9/4/07, Arne Brasseur wrote: > > > > Pushed another one, seems like the proto application template path > > moved. > > > > hunk ./raw/lib/raw/controller/publishable.rb 151 > > - stack << File.join(Nitro.proto_path, "template", > > path).gsub(/\/$/, "") > > + stack << File.join(Nitro.proto_path, "app", "template", > > path).gsub(/\/$/, "") > > > > > > George, could you remind me : will Nitro 0.50 allow to have controller > > actions without template files, and if so, should this work by simply > > returning a string, or by using an explicit output function? > > > > (ab) > > > > -- > > Arne Brasseur > > http://www.arnebrasseur.net > > arne at arnebrasseur.net > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.netarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/c11179bd/attachment.html From arne at arnebrasseur.net Wed Sep 5 10:05:46 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Wed, 05 Sep 2007 22:05:46 +0800 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: References: <46DD7304.8010303@arnebrasseur.net> <46DE761E.2050005@arnebrasseur.net> Message-ID: <46DEB7BA.9000806@arnebrasseur.net> If you're using bash you can just enter "darcs pull " to get a list of the repos you've interacted with. The darcs autocompletion is really excellent. Nitro developers tip of the day :) (ab) George Moschovitis schreef: > I keep forgetting these repos ;-) > > -g. > > On 9/5/07, *Arne Brasseur* > wrote: > > George Moschovitis schreef: >> please send me patch bundles, makes things a lot easier for me. > No problem, you will find them in attachment. > > But isn't "darcs pull http://darcs.arnebrasseur.net/glycerin" easier? > > (ab) > > Tue Sep 4 19:12:14 CST 2007 Arne Brasseur > > * Fix colorful logging, don't output ANSI color codes for nothing > > Tue Sep 4 22:56:11 CST 2007 Arne Brasseur > > * proto template path now includes "app" > >> >> -g. >> >> On 9/4/07, *Arne Brasseur* > > wrote: >> >> Pushed another one, seems like the proto application template >> path moved. >> >> hunk ./raw/lib/raw/controller/publishable.rb 151 >> - stack << File.join(Nitro.proto_path, "template", >> path).gsub(/\/$/, "") >> + stack << File.join(Nitro.proto_path, "app", "template", >> path).gsub(/\/$/, "") >> >> >> George, could you remind me : will Nitro 0.50 allow to have >> controller >> actions without template files, and if so, should this work >> by simply >> returning a string, or by using an explicit output function? >> >> (ab) >> >> -- >> Arne Brasseur >> http://www.arnebrasseur.net >> arne at arnebrasseur.net >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> >> >> >> -- >> http://www.me.gr >> http://phidz.com >> http://blog.gmosx.com >> http://cull.gr >> http://www.joy.gr >> http://nitroproject.org >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/4003ef73/attachment.html From george.moschovitis at gmail.com Wed Sep 5 10:39:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 17:39:26 +0300 Subject: [Nitro] [PATCH] proto template path now includes "app" In-Reply-To: <46DEB7BA.9000806@arnebrasseur.net> References: <46DD7304.8010303@arnebrasseur.net> <46DE761E.2050005@arnebrasseur.net> <46DEB7BA.9000806@arnebrasseur.net> Message-ID: nice one ;-) On 9/5/07, Arne Brasseur wrote: > > If you're using bash you can just enter "darcs pull " to get a > list of the repos you've interacted with. The darcs autocompletion is really > excellent. > > Nitro developers tip of the day :) > > (ab) > > > George Moschovitis schreef: > > I keep forgetting these repos ;-) > > -g. > > On 9/5/07, Arne Brasseur wrote: > > > > George Moschovitis schreef: > > > > please send me patch bundles, makes things a lot easier for me. > > > > No problem, you will find them in attachment. > > > > But isn't "darcs pull http://darcs.arnebrasseur.net/glycerin" easier? > > > > (ab) > > > > Tue Sep 4 19:12:14 CST 2007 Arne Brasseur > > * Fix colorful logging, don't output ANSI color codes for nothing > > > > Tue Sep 4 22:56:11 CST 2007 Arne Brasseur > > * proto template path now includes "app" > > > > > > -g. > > > > On 9/4/07, Arne Brasseur wrote: > > > > > > Pushed another one, seems like the proto application template path > > > moved. > > > > > > hunk ./raw/lib/raw/controller/publishable.rb 151 > > > - stack << File.join(Nitro.proto_path, "template", > > > path).gsub(/\/$/, "") > > > + stack << File.join(Nitro.proto_path, "app", "template", > > > path).gsub(/\/$/, "") > > > > > > > > > George, could you remind me : will Nitro 0.50 allow to have controller > > > actions without template files, and if so, should this work by simply > > > returning a string, or by using an explicit output function? > > > > > > (ab) > > > > > > -- > > > Arne Brasseur > > > http://www.arnebrasseur.net > > > arne at arnebrasseur.net > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > -- > > http://www.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > > ------------------------------ > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > > Arne Brasseur > > http://www.arnebrasseur.netarne at arnebrasseur.net > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > > ------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general > > > > -- > Arne Brasseur > http://www.arnebrasseur.netarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/9ecddc69/attachment-0001.html From rff_rff at yahoo.it Wed Sep 5 14:00:15 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Wed, 5 Sep 2007 18:00:15 +0000 (UTC) Subject: [Nitro] Timestamped not working Message-ID: Hi list, while trying the darcs version of Og, I noticed that the test suite is almost completely empty, is it normal or am I nmissing something? Anyway, since there is nothing to test it, it seems that the timestamped mixin doesn't work anymore, I believe that the before methods are not called at all. Or maybe something is changed since I last used Og, and now this is not working anymore: require 'og' class Post is Timestamped end Og.setup() describe 'Timestamped' do it 'should update create_time on save' do p=Post.new p.save p.oid.should be_an_instance_of(Fixnum) p.create_time.should be_an_instance_of(Time) p.update_time.should be_an_instance_of(Time) p.access_time.should be_an_instance_of(Time) p.delete end end Any hint will be appreciated :) -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From transfire at gmail.com Wed Sep 5 14:20:24 2007 From: transfire at gmail.com (Trans) Date: Wed, 05 Sep 2007 18:20:24 -0000 Subject: [Nitro] advice.rb In-Reply-To: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> Message-ID: <1189016424.594578.72540@k79g2000hse.googlegroups.com> Ran into one snag with advice.rb. The advice blocks are not evaluated in the instance binding of their object, so instance methods (eg. @x) are not accessible. Unfortunately, the easy fix for this requires #instance_exec, which (very annoyingly) isn't slated for inclusion until Ruby 1.9. Considering the alternatives (Proc.bind or myriads of method definitions), it may be best to accept this limitation for the time being. If one has to access an instance var in an advice block then one can always make an accessor to it, which, of course, works fine. I think, the only other thing left to do is support other methods as advice, rather than just blocks. T. From transfire at gmail.com Wed Sep 5 14:28:45 2007 From: transfire at gmail.com (Trans) Date: Wed, 05 Sep 2007 18:28:45 -0000 Subject: [Nitro] advice.rb In-Reply-To: <1189016424.594578.72540@k79g2000hse.googlegroups.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1189016424.594578.72540@k79g2000hse.googlegroups.com> Message-ID: <1189016925.135158.171190@50g2000hsm.googlegroups.com> On Sep 5, 11:20 am, Trans wrote: > Considering the alternatives (Proc.bind or myriads of method > definitions), it may be best to accept this limitation for the time > being. If one has to access an instance var in an advice block then > one can always make an accessor to it, which, of course, works fine. No... I'm actually wrong about that. This has to be fixed b/c not even instance methods are accessible. Damn it. Alright, well, I'll just have to define methods. T. From transfire at gmail.com Wed Sep 5 15:00:05 2007 From: transfire at gmail.com (Trans) Date: Wed, 05 Sep 2007 19:00:05 -0000 Subject: [Nitro] advice.rb In-Reply-To: <1189016925.135158.171190@50g2000hsm.googlegroups.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1189016424.594578.72540@k79g2000hse.googlegroups.com> <1189016925.135158.171190@50g2000hsm.googlegroups.com> Message-ID: <1189018805.102898.258400@d55g2000hsg.googlegroups.com> On Sep 5, 11:28 am, Trans wrote: > On Sep 5, 11:20 am, Trans wrote: > > > Considering the alternatives (Proc.bind or myriads of method > > definitions), it may be best to accept this limitation for the time > > being. If one has to access an instance var in an advice block then > > one can always make an accessor to it, which, of course, works fine. > > No... I'm actually wrong about that. This has to be fixed b/c not even > instance methods are accessible. Damn it. Alright, well, I'll just > have to define methods. See the crazy methods ;) ["inspect", "out", "clone", "x:before-605787008", "method", "public_methods", "instance_variable_defined?", "equal?", "freeze", "methods", "respond_to?", "method!", "x:after-605787178", "dup", "instance_variables", "x", "__id__", "eql?", "object_id", "to_yaml_style", "x:before-605774938", "id", "singleton_methods", "send", "taint", "x:around-605787338", "frozen?", "instance_variable_get", "__send__", "instance_of?", "to_a", "to_yaml_properties", "type", "x:after-605783528", "to_yaml", "protected_methods", "instance_eval", "==", "display", "x_origin", "===", "instance_variable_set", "kind_of?", "extend", "to_s", "taguri", "out_origin", "hash", "class", "tainted?", "=~", "private_methods", "taguri=", "nil?", "untaint", "is_a?"] Okay, well it works good. A little faster too, despite the crufty methods. Only one question, is this the right execution order? ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER Y#x", "AFTER X#x"] or should it be: ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] T. From george.moschovitis at gmail.com Wed Sep 5 15:18:30 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 22:18:30 +0300 Subject: [Nitro] Timestamped not working In-Reply-To: References: Message-ID: Let me have a look at this and I will get back to you. The tests reside in a hidden directory at the moment, I will convert them shortly. welcome back to the list btw, -g. On 9/5/07, gabriele renzi wrote: > > Hi list, > > > while trying the darcs version of Og, I noticed that the test suite is > almost completely empty, is it normal or am I nmissing something? > > Anyway, since there is nothing to test it, it seems that the timestamped > mixin doesn't work anymore, I believe that the before methods are not > called at all. > > Or maybe something is changed since I last used Og, and now this is not > working anymore: > > require 'og' > class Post > is Timestamped > end > Og.setup() > describe 'Timestamped' do > it 'should update create_time on save' do > p=Post.new > p.save > p.oid.should be_an_instance_of(Fixnum) > p.create_time.should be_an_instance_of(Time) > p.update_time.should be_an_instance_of(Time) > p.access_time.should be_an_instance_of(Time) > p.delete > end > end > > Any hint will be appreciated :) > > > > -- > goto 10: http://www.goto10.it > blog it: http://riffraff.blogsome.com > blog en: http://www.riffraff.info > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/0c99ffd0/attachment.html From george.moschovitis at gmail.com Wed Sep 5 15:30:42 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 5 Sep 2007 22:30:42 +0300 Subject: [Nitro] advice.rb In-Reply-To: <1189018805.102898.258400@d55g2000hsg.googlegroups.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1189016424.594578.72540@k79g2000hse.googlegroups.com> <1189016925.135158.171190@50g2000hsm.googlegroups.com> <1189018805.102898.258400@d55g2000hsg.googlegroups.com> Message-ID: I would say this one: > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] what do others think? -g. On 9/5/07, Trans wrote: > > > > On Sep 5, 11:28 am, Trans wrote: > > On Sep 5, 11:20 am, Trans wrote: > > > > > Considering the alternatives (Proc.bind or myriads of method > > > definitions), it may be best to accept this limitation for the time > > > being. If one has to access an instance var in an advice block then > > > one can always make an accessor to it, which, of course, works fine. > > > > No... I'm actually wrong about that. This has to be fixed b/c not even > > instance methods are accessible. Damn it. Alright, well, I'll just > > have to define methods. > > See the crazy methods ;) > > ["inspect", "out", "clone", "x:before-605787008", "method", > "public_methods", "instance_variable_defined?", "equal?", "freeze", > "methods", "respond_to?", "method!", "x:after-605787178", "dup", > "instance_variables", "x", "__id__", "eql?", "object_id", > "to_yaml_style", "x:before-605774938", "id", "singleton_methods", > "send", "taint", "x:around-605787338", "frozen?", > "instance_variable_get", "__send__", "instance_of?", "to_a", > "to_yaml_properties", "type", "x:after-605783528", "to_yaml", > "protected_methods", "instance_eval", "==", "display", "x_origin", > "===", "instance_variable_set", "kind_of?", "extend", "to_s", > "taguri", "out_origin", "hash", "class", "tainted?", "=~", > "private_methods", "taguri=", "nil?", "untaint", "is_a?"] > > Okay, well it works good. A little faster too, despite the crufty > methods. Only one question, is this the right execution order? > > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER Y#x", "AFTER X#x"] > > or should it be: > > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] > > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070905/59df72e0/attachment.html From work at ashleymoran.me.uk Wed Sep 5 17:11:50 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Wed, 5 Sep 2007 22:11:50 +0100 Subject: [Nitro] Mini Nitro example In-Reply-To: <46DE97A7.4050809@arnebrasseur.net> References: <46DE97A7.4050809@arnebrasseur.net> Message-ID: <17F7C291-F5DE-40E0-A8C5-F3DA4CB451EB@ashleymoran.me.uk> On Sep 05, 2007, at 12:48 pm, Arne Brasseur wrote: > I sincerely hope someone has a use for this (educational or > otherwise). > At least I do :-) Thanks for putting this up. I haven't had much luck so far though. First Flickr has a major network outage ("one of our main switches went on holiday without telling anyone", or something like that). Now Flickr is back online, I get an exception when running the app: iMac-G5-AM:~/Documents/Development/nitro/flikker ashleymoran$ ./launch INFO: Starting Mongrel server in debug mode, listening at 0.0.0.0:9000 INFO: Press Ctrl-C to shutdown; Run with --help for options. DEBUG: Compiling 'Base#index' super-method DEBUG: Compiling 'index' view sub-method [format: html] ERROR: Error while handling '/favicon.ico' ERROR: Cannot respond to '/favicon.ico' using the 'ico' format representation. /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/dispatcher.rb: 160:in `dispatch' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/dispatcher.rb: 116:in `dispatch_context' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:62:in `handle_context' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/mongrel.rb: 124:in `process' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 618:in `process_client' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 617:in `each' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 617:in `process_client' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 736:in `run' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 736:in `initialize' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 736:in `new' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 736:in `run' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 720:in `initialize' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 720:in `new' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel.rb: 720:in `run' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:271:in `run' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:270:in `each' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:270:in `run' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/mongrel.rb: 48:in `cloaker_' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:138:in `call' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:138:in `listener' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/mongrel.rb: 45:in `cloaker_' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:51:in `call' /opt/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/ configurator.rb:51:in `initialize' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/mongrel.rb: 44:in `new' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter/mongrel.rb: 44:in `start' /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb: 135:in `start' app.rb:12 LOGGED FROM: /Users/ashleymoran/Documents/Development/nitro/ repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:72:in `handle_context' This is using nitro I pulled from the repository a few days ago, and facets I pulled from RubyForge SVN a few minutes ago. Looks like something REALLY simple, so I thought I'd just ask here. Can anyone help? Thanks Ashley From work at ashleymoran.me.uk Wed Sep 5 17:19:36 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Wed, 5 Sep 2007 22:19:36 +0100 Subject: [Nitro] Mini Nitro example In-Reply-To: <17F7C291-F5DE-40E0-A8C5-F3DA4CB451EB@ashleymoran.me.uk> References: <46DE97A7.4050809@arnebrasseur.net> <17F7C291-F5DE-40E0-A8C5-F3DA4CB451EB@ashleymoran.me.uk> Message-ID: Sorry I forgot the actual error that caused the exception... On Sep 05, 2007, at 10:11 pm, Ashley Moran wrote: > LOGGED FROM: /Users/ashleymoran/Documents/Development/nitro/ > repo.nitroproject.org/script/lib/../../raw/lib/raw/adapter.rb:72:in > `handle_context' Wed Sep 05 22:04:48 +0100 2007: ERROR: undefined method `out' for nil:NilClass From work at ashleymoran.me.uk Wed Sep 5 18:13:36 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Wed, 5 Sep 2007 23:13:36 +0100 Subject: [Nitro] Mini Nitro example In-Reply-To: References: <46DE97A7.4050809@arnebrasseur.net> <17F7C291-F5DE-40E0-A8C5-F3DA4CB451EB@ashleymoran.me.uk> Message-ID: <17C46073-F1B0-4A01-91B3-3F3918258F52@ashleymoran.me.uk> On Sep 05, 2007, at 10:19 pm, Ashley Moran wrote: > Wed Sep 05 22:04:48 +0100 2007: ERROR: undefined method `out' for > nil:NilClass Ignore me - looks like the issue has already been fixed. Sorry for the noise. Finally figured out how darcs works (so much to learn at once...) and updated my Nitro repository with the latest 12 patches. Nice little demo app! Will start trying some of my own stuff out soon. Ashley From mvyver at gmail.com Wed Sep 5 19:01:39 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 6 Sep 2007 09:01:39 +1000 Subject: [Nitro] advice.rb In-Reply-To: References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1189016424.594578.72540@k79g2000hse.googlegroups.com> <1189016925.135158.171190@50g2000hsm.googlegroups.com> <1189018805.102898.258400@d55g2000hsg.googlegroups.com> Message-ID: <389c43e40709051601y50bcfbaam27834afcb817498d@mail.gmail.com> > I would say this one: > > > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] > > what do others think? seems more natural to me. > -g. > > > > > > > On 9/5/07, Trans wrote: > > > > > > On Sep 5, 11:28 am, Trans wrote: > > > On Sep 5, 11:20 am, Trans wrote: > > > > > > > Considering the alternatives (Proc.bind or myriads of method > > > > definitions), it may be best to accept this limitation for the time > > > > being. If one has to access an instance var in an advice block then > > > > one can always make an accessor to it, which, of course, works fine. > > > > > > No... I'm actually wrong about that. This has to be fixed b/c not even > > > instance methods are accessible. Damn it. Alright, well, I'll just > > > have to define methods. > > > > See the crazy methods ;) > > > > ["inspect", "out", "clone", "x:before-605787008", "method", > > "public_methods", "instance_variable_defined?", "equal?", "freeze", > > "methods", "respond_to?", "method!", "x:after-605787178", "dup", > > "instance_variables", "x", "__id__", "eql?", "object_id", > > "to_yaml_style", "x:before-605774938", "id", "singleton_methods", > > "send", "taint", "x:around-605787338", "frozen?", > > "instance_variable_get", "__send__", "instance_of?", "to_a", > > "to_yaml_properties", "type", "x:after-605783528", "to_yaml", > > "protected_methods", "instance_eval", "==", "display", "x_origin", > > "===", "instance_variable_set", "kind_of?", "extend", "to_s", > > "taguri", "out_origin", "hash", "class", "tainted?", "=~", > > "private_methods", "taguri=", "nil?", "untaint", "is_a?"] > > > > Okay, well it works good. A little faster too, despite the crufty > > methods. Only one question, is this the right execution order? > > > > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER Y#x", "AFTER X#x"] > > > > or should it be: > > > > ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] > > > > > > T. > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From arne at arnebrasseur.net Wed Sep 5 19:35:25 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Thu, 06 Sep 2007 07:35:25 +0800 Subject: [Nitro] advice.rb In-Reply-To: <389c43e40709051601y50bcfbaam27834afcb817498d@mail.gmail.com> References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1189016424.594578.72540@k79g2000hse.googlegroups.com> <1189016925.135158.171190@50g2000hsm.googlegroups.com> <1189018805.102898.258400@d55g2000hsg.googlegroups.com> <389c43e40709051601y50bcfbaam27834afcb817498d@mail.gmail.com> Message-ID: <46DF3D3D.7060104@arnebrasseur.net> Mark Van De Vyver schreef: >> I would say this one: >> >> >>> ["BEFORE Y#x", "BEFORE X#x", "Y#x", "X#x", "AFTER X#x", "AFTER Y#x"] >>> >> what do others think? >> > > seems more natural to me. > > +1 -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/3c029fcb/attachment.html From transfire at gmail.com Wed Sep 5 20:00:24 2007 From: transfire at gmail.com (Trans) Date: Thu, 06 Sep 2007 00:00:24 -0000 Subject: [Nitro] advice.rb In-Reply-To: References: <4b6f054f0708311724n35b8ba91r42323cc630d86aa7@mail.gmail.com> <1188658475.138118.179200@22g2000hsm.googlegroups.com> Message-ID: <1189036824.580808.46250@k79g2000hse.googlegroups.com> On Sep 2, 9:50 pm, "George Moschovitis" wrote: > > Blow, English and Stick. I still have to create the Nemo project but > > hmm, nitro needs stuff from these projects too, can you remind me their svn > repositories urls? Oops. Sorry mis read that the first time. Here you are. For English just sub 'english' for 'blow'. Anonymous Subversion Access This project's SVN repository can be checked out through anonymous access with the following command(s). svn checkout svn://rubyforge.org/var/svn/blow svn checkout http://blow.rubyforge.org/svn/trunk/ Developer Subversion Access via SSH Only project developers can access the SVN tree via this method. SSH must be installed on your client machine. Substitute developername with the proper values. Enter your site password when prompted. svn checkout svn+ssh://developername at rubyforge.org/var/svn/blow T. From transfire at gmail.com Wed Sep 5 21:07:56 2007 From: transfire at gmail.com (Trans) Date: Thu, 06 Sep 2007 01:07:56 -0000 Subject: [Nitro] Facets 2.w00t!!! Message-ID: <1189040876.325856.178130@w3g2000hsg.googlegroups.com> Check it out: http://groups.google.com/group/facets-universal/browse_thread/thread/e25982e9f60a4ae0?hl=en T. From reid.thompson at ateb.com Wed Sep 5 23:18:19 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Wed, 05 Sep 2007 23:18:19 -0400 Subject: [Nitro] Facets 2.w00t!!! In-Reply-To: <1189040876.325856.178130@w3g2000hsg.googlegroups.com> References: <1189040876.325856.178130@w3g2000hsg.googlegroups.com> Message-ID: <46DF717B.2020208@ateb.com> Trans wrote: > Check it out: > > http://groups.google.com/group/facets-universal/browse_thread/thread/e25982e9f60a4ae0?hl=en > nice From george.moschovitis at gmail.com Thu Sep 6 01:49:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 08:49:27 +0300 Subject: [Nitro] Facets 2.w00t!!! In-Reply-To: <1189040876.325856.178130@w3g2000hsg.googlegroups.com> References: <1189040876.325856.178130@w3g2000hsg.googlegroups.com> Message-ID: impressive, great work! -g. On 9/6/07, Trans wrote: > > Check it out: > > > http://groups.google.com/group/facets-universal/browse_thread/thread/e25982e9f60a4ae0?hl=en > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/5df946d8/attachment.html From mvyver at gmail.com Thu Sep 6 02:19:22 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 6 Sep 2007 16:19:22 +1000 Subject: [Nitro] OG [PATCH 1/4]: Default Og manager options - resolve inconsistent setup of defaults. Message-ID: <389c43e40709052319l127cd1c6qc9352e44f1d9785d@mail.gmail.com> Hi Devs, While trying to work out where and how OG sets options for an adapter I discovered that you got inconsistent default options with the following cases: OG.start Og.start( {} ) Part of the reason was that defaults for sqlite were being set in different places. I've tested this patch with the dbi adapter specs that will follow. I've not changed the default manager_options to use the dbi/sqlite adapter/driver but I am testing with both, so have the dbi/sqlite settings present but commented out in ./lib/og.rb mvdv-20070906-1-of-x.patch Changes to the Og manager default options: - default sqlite database name is memory (was data). - default manager options are set in Module Og. - default options used if none (including {}) given. -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-1-of-x.patch.tar.gz Type: application/x-gzip Size: 16970 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/a6ccc1c9/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-1-of-x.patch Type: text/x-patch Size: 61813 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/a6ccc1c9/attachment-0001.bin From mvyver at gmail.com Thu Sep 6 02:20:38 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 6 Sep 2007 16:20:38 +1000 Subject: [Nitro] OG [PATCH 2/4]: DBI adapter - initialize, disconnect and dbi-tracing activated Message-ID: <389c43e40709052320x3c591c2dma1042196c8033056@mail.gmail.com> mvdv-20070906-2-of-x.patch Changes to the DBI adapter: - added initialize (spec'd) - added disconnect (not spec'd) - Activate DBI tracing if $DBG is true - Some RDoc format changes (./og/lib/og/adapter/dbi.rb) -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-2-of-x.patch Type: text/x-patch Size: 67861 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/5087ec39/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-2-of-x.patch.tar.gz Type: application/x-gzip Size: 18873 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/5087ec39/attachment-0001.gz From mvyver at gmail.com Thu Sep 6 02:21:41 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 6 Sep 2007 16:21:41 +1000 Subject: [Nitro] OG [PATCH 3/4]: test helper - split setup, added dbi_sqlite and dbi_mysql support Message-ID: <389c43e40709052321j595652edoac8167f198a26ae@mail.gmail.com> mvdv-20070906-3-of-x.patch Changes to test helper: - added :dbi_sqlite options to OG_CONFIG - separated OgSpecHelper#setup into OgSpecHelper#setup and OgSpecHelper#start (required to spec store connection behavior) - removed setup as a synonym/alias for start (these are quite different actions?) -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-3-of-x.patch Type: text/x-patch Size: 61093 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/3cdab0f1/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-3-of-x.patch.tar.gz Type: application/x-gzip Size: 16807 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/3cdab0f1/attachment-0001.gz From mvyver at gmail.com Thu Sep 6 02:22:54 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 6 Sep 2007 16:22:54 +1000 Subject: [Nitro] OG [PATCH 4/4]: dbi adapter spec - default connect options Message-ID: <389c43e40709052322k42a782ffyd7d9a0105fc6a859@mail.gmail.com> mvdv-20070906-4-of-x.patch Changes to DBI adapter spec: - Added 2 tests/specs for connecting with the default options. a) Og.start b) Og.start({}) -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-4-of-x.patch.tar.gz Type: application/x-gzip Size: 17262 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/01897650/attachment-0001.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070906-4-of-x.patch Type: text/x-patch Size: 63077 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070906/01897650/attachment-0001.bin From george.moschovitis at gmail.com Thu Sep 6 03:19:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 10:19:44 +0300 Subject: [Nitro] OG [PATCH 4/4]: dbi adapter spec - default connect options In-Reply-To: <389c43e40709052322k42a782ffyd7d9a0105fc6a859@mail.gmail.com> References: <389c43e40709052322k42a782ffyd7d9a0105fc6a859@mail.gmail.com> Message-ID: Mark, thanks for the patches. Some initial remarks though: please follow the coding conventions. For example use def initialize(options) not def initialize( options ) use double quotes for escaping Strings, ie "this is a string", not 'this is a string' etc... read more here: http://www.nitroproject.org/repo thank you, George. On 9/6/07, Mark Van De Vyver wrote: > > mvdv-20070906-4-of-x.patch > > Changes to DBI adapter spec: > - Added 2 tests/specs for connecting with the default options. > a) Og.start > b) Og.start({}) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/132f2346/attachment.html From george.moschovitis at gmail.com Thu Sep 6 03:43:56 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 10:43:56 +0300 Subject: [Nitro] Mini Nitro example In-Reply-To: <17C46073-F1B0-4A01-91B3-3F3918258F52@ashleymoran.me.uk> References: <46DE97A7.4050809@arnebrasseur.net> <17F7C291-F5DE-40E0-A8C5-F3DA4CB451EB@ashleymoran.me.uk> <17C46073-F1B0-4A01-91B3-3F3918258F52@ashleymoran.me.uk> Message-ID: Great ;-) On 9/6/07, Ashley Moran wrote: > > > On Sep 05, 2007, at 10:19 pm, Ashley Moran wrote: > > Wed Sep 05 22:04:48 +0100 2007: ERROR: undefined method `out' for > > nil:NilClass > > > Ignore me - looks like the issue has already been fixed. Sorry for > the noise. Finally figured out how darcs works (so much to learn at > once...) and updated my Nitro repository with the latest 12 patches. > > Nice little demo app! Will start trying some of my own stuff out soon. > > Ashley > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/a1373c86/attachment.html From billk at cts.com Thu Sep 6 03:47:49 2007 From: billk at cts.com (Bill Kelly) Date: Thu, 6 Sep 2007 00:47:49 -0700 Subject: [Nitro] Sporadic 'Found altered cookie' errors Message-ID: <006301c7f05a$3901f160$6442a8c0@musicbox> Hi, Is anyone else getting sporadic 'Found altered cookie' errors in their logs? At first I thought it was just related to the haphazard way I was refreshing my pages during development. But now that I'm using WWW::Mechanize to test my site, it's also randomly seeing these cookie errors. I somehow doubt FireFox and WWW::Mechanize have the same bug in their cookie handling, so ... it seems something on the server-side is having issues. I'll continue debugging, but I just wondered if anyone else has been seeing this? (Note: I never noticed this problem on Nitro 0.31 ... it only started after I ported my code to the repo version...) Thanks, Bill From george.moschovitis at gmail.com Thu Sep 6 04:03:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 11:03:58 +0300 Subject: [Nitro] Sporadic 'Found altered cookie' errors In-Reply-To: <006301c7f05a$3901f160$6442a8c0@musicbox> References: <006301c7f05a$3901f160$6442a8c0@musicbox> Message-ID: I have noticed this. This has to do with the new cookie based session system that is used by default. This looks like a serious bug, will have to look at this more closely. I would really appreciate it if someone could have a look at lib/raw/context/session/cookie.rb and perhaps offer some ideas. In the meantime, how about using the memory session store for your tests? -g. On 9/6/07, Bill Kelly wrote: > > Hi, > > Is anyone else getting sporadic 'Found altered cookie' > errors in their logs? > > At first I thought it was just related to the haphazard > way I was refreshing my pages during development. But now > that I'm using WWW::Mechanize to test my site, it's also > randomly seeing these cookie errors. > > I somehow doubt FireFox and WWW::Mechanize have the same > bug in their cookie handling, so ... it seems something on > the server-side is having issues. > > I'll continue debugging, but I just wondered if anyone else > has been seeing this? > > (Note: I never noticed this problem on Nitro 0.31 ... it > only started after I ported my code to the repo version...) > > > Thanks, > > Bill > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/70e2d7ef/attachment.html From billk at cts.com Thu Sep 6 04:49:18 2007 From: billk at cts.com (Bill Kelly) Date: Thu, 6 Sep 2007 01:49:18 -0700 Subject: [Nitro] Sporadic 'Found altered cookie' errors References: <006301c7f05a$3901f160$6442a8c0@musicbox> Message-ID: <009d01c7f062$cfe808a0$6442a8c0@musicbox> From: George Moschovitis > > I have noticed this. This has to do with the new cookie > based session system that is used by default. > This looks like a serious bug, will have to look at this > more closely. I would really appreciate it if someone could > have a look at > > lib/raw/context/session/cookie.rb > > and perhaps offer some ideas. > > In the meantime, how about using the memory session store for your tests? Thanks. What is the recommended way to enable the memory session store? It seems that Application#start of nitro/lib/nitro/application.rb sets: @session_store = Raw::CookieSessionStore.new So that when I do app.start, @session_store will be set to CookieSessionStore. I can modify nitro/lib/nitro/application.rb for now, but I was wondering if there's a better way that I'm missing? Thanks, Bill From george.moschovitis at gmail.com Thu Sep 6 06:09:51 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 13:09:51 +0300 Subject: [Nitro] OG [PATCH 3/4]: test helper - split setup, added dbi_sqlite and dbi_mysql support In-Reply-To: <389c43e40709052321j595652edoac8167f198a26ae@mail.gmail.com> References: <389c43e40709052321j595652edoac8167f198a26ae@mail.gmail.com> Message-ID: I changed the OgSpecHelper#setup method back as it was... It is very inconvienient having to call 2 methods. -g. On 9/6/07, Mark Van De Vyver wrote: > > mvdv-20070906-3-of-x.patch > > Changes to test helper: > - added :dbi_sqlite options to OG_CONFIG > - separated OgSpecHelper#setup into OgSpecHelper#setup and > OgSpecHelper#start > (required to spec store connection behavior) > - removed setup as a synonym/alias for start (these are quite > different actions?) > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/c0eb03d7/attachment.html From george.moschovitis at gmail.com Thu Sep 6 06:17:11 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 13:17:11 +0300 Subject: [Nitro] Timestamped not working In-Reply-To: References: Message-ID: You are probably using Og without Nitro. In the repo version of Nitro you have to call Aspects.setup for this to work. Have a look at the timestamped spec I just added. Tom is working on a new aspects implementation. Hopefully the call to #setup want be necessary any more. If you have more problems let me know, -g. On 9/5/07, George Moschovitis wrote: > > Let me have a look at this and I will get back to you. The tests reside in > a hidden directory at the moment, I will convert them shortly. > > welcome back to the list btw, > -g. > > On 9/5/07, gabriele renzi wrote: > > > > Hi list, > > > > > > while trying the darcs version of Og, I noticed that the test suite is > > almost completely empty, is it normal or am I nmissing something? > > > > Anyway, since there is nothing to test it, it seems that the timestamped > > > > mixin doesn't work anymore, I believe that the before methods are not > > called at all. > > > > Or maybe something is changed since I last used Og, and now this is not > > working anymore: > > > > require 'og' > > class Post > > is Timestamped > > end > > Og.setup() > > describe 'Timestamped' do > > it 'should update create_time on save' do > > p=Post.new > > p.save > > p.oid.should be_an_instance_of(Fixnum) > > p.create_time.should be_an_instance_of(Time) > > p.update_time.should be_an_instance_of(Time) > > p.access_time.should be_an_instance_of(Time) > > p.delete > > end > > end > > > > Any hint will be appreciated :) > > > > > > > > -- > > goto 10: http://www.goto10.it > > blog it: http://riffraff.blogsome.com > > blog en: http://www.riffraff.info > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/20275529/attachment-0001.html From rff_rff at yahoo.it Thu Sep 6 08:23:23 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Thu, 6 Sep 2007 12:23:23 +0000 (UTC) Subject: [Nitro] Timestamped not working References: Message-ID: On Thu, 06 Sep 2007 13:17:11 +0300, George Moschovitis wrote: > You are probably using Og without Nitro. In the repo version of Nitro you > have to call > > Aspects.setup > > > for this to work. Have a look at the timestamped spec I just added. well, I was just using iog standalon because I was writing the model tests :) > Tom is working on a new aspects implementation. Hopefully the call to > #setup want be necessary any more. nice, thanks you. -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From george.moschovitis at gmail.com Thu Sep 6 08:29:04 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 15:29:04 +0300 Subject: [Nitro] Select default value. Message-ID: Dear devs, I would like your opinion on this problem, lets say I have this select field:
    I would like to allocate a 'special' value to the default options, that Nitro will 'ignore'. Ie if the user does not select any gender, request["gender"] == nil and not request["gender"] == "??" # <-- the special value any ideas, suggestions? -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/12030266/attachment.html From rff_rff at yahoo.it Thu Sep 6 08:34:15 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Thu, 6 Sep 2007 12:34:15 +0000 (UTC) Subject: [Nitro] Timestamped not working References: Message-ID: On Thu, 06 Sep 2007 13:17:11 +0300, George Moschovitis wrote: > You are probably using Og without Nitro. In the repo version of Nitro you > have to call > > Aspects.setup > > > for this to work. Have a look at the timestamped spec I just added. ok, the spec does not run correctly for me: rff at ut:~/nitro$ ruby og/test/og/model/timestamped.rb F 1) 'the timestamped mixin automatically fills timestamp attributes when inserting models' FAILED expected: Time, got: NilClass (using ==) og/test/og/model/timestamped.rb:27: og/test/og/model/timestamped.rb:16: As far as I understand Aspects.setup is called by SpecHelper.setup so it should work, but it seems it doesn't. Maybe there is some change you have not pushed yet ? -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From george.moschovitis at gmail.com Thu Sep 6 10:02:41 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 17:02:41 +0300 Subject: [Nitro] Timestamped not working In-Reply-To: References: Message-ID: Pull again, it is fixed now. thanks, -g. On 9/6/07, gabriele renzi wrote: > > On Thu, 06 Sep 2007 13:17:11 +0300, George Moschovitis wrote: > > > You are probably using Og without Nitro. In the repo version of Nitro > you > > have to call > > > > Aspects.setup > > > > > > for this to work. Have a look at the timestamped spec I just added. > > > ok, the spec does not run correctly for me: > > rff at ut:~/nitro$ ruby og/test/og/model/timestamped.rb > F > > 1) > 'the timestamped mixin automatically fills timestamp attributes when > inserting models' FAILED > expected: Time, > got: NilClass (using ==) > og/test/og/model/timestamped.rb:27: > og/test/og/model/timestamped.rb:16: > > > As far as I understand Aspects.setup is called by SpecHelper.setup so it > should work, but it seems it doesn't. > Maybe there is some change you have not pushed yet ? > > > > -- > goto 10: http://www.goto10.it > blog it: http://riffraff.blogsome.com > blog en: http://www.riffraff.info > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/30360fcd/attachment.html From billk at cts.com Thu Sep 6 13:09:43 2007 From: billk at cts.com (Bill Kelly) Date: Thu, 6 Sep 2007 10:09:43 -0700 Subject: [Nitro] Sporadic 'Found altered cookie' errors References: <006301c7f05a$3901f160$6442a8c0@musicbox> <009d01c7f062$cfe808a0$6442a8c0@musicbox> Message-ID: <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> From: "Bill Kelly" > > It seems that Application#start of nitro/lib/nitro/application.rb > sets: @session_store = Raw::CookieSessionStore.new > > So that when I do app.start, @session_store will be set to > CookieSessionStore. > > I can modify nitro/lib/nitro/application.rb for now, but I was > wondering if there's a better way that I'm missing? N.B. I have modified Application#start in nitro/lib/nitro/application.rb from: @session_store = Raw::CookieSessionStore.new to: @session_store ||= Raw::CookieSessionStore.new Now I'm able to do: app.session_store = Raw::MemorySessionStore.new app.start Regards, Bill From george.moschovitis at gmail.com Thu Sep 6 16:43:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 6 Sep 2007 23:43:21 +0300 Subject: [Nitro] Sporadic 'Found altered cookie' errors In-Reply-To: <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> References: <006301c7f05a$3901f160$6442a8c0@musicbox> <009d01c7f062$cfe808a0$6442a8c0@musicbox> <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> Message-ID: How about sending a nice Darcs patch. You will help the project and get your name in the CONTRIBUTORS list ;-) thank you, -g. On 9/6/07, Bill Kelly wrote: > > > From: "Bill Kelly" > > > > It seems that Application#start of nitro/lib/nitro/application.rb > > sets: @session_store = Raw::CookieSessionStore.new > > > > So that when I do app.start, @session_store will be set to > > CookieSessionStore. > > > > I can modify nitro/lib/nitro/application.rb for now, but I was > > wondering if there's a better way that I'm missing? > > N.B. I have modified Application#start in nitro/lib/nitro/application.rb > from: > > @session_store = Raw::CookieSessionStore.new > > to: > > @session_store ||= Raw::CookieSessionStore.new > > Now I'm able to do: > > app.session_store = Raw::MemorySessionStore.new > app.start > > > Regards, > > Bill > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070906/686aa94f/attachment.html From rff_rff at yahoo.it Thu Sep 6 18:13:47 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Thu, 6 Sep 2007 22:13:47 +0000 (UTC) Subject: [Nitro] Timestamped not working References: Message-ID: On Thu, 06 Sep 2007 17:02:41 +0300, George Moschovitis wrote: > Pull again, it is fixed now. yes, works as a charm > thanks, thanks to you :) -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From mvyver at gmail.com Thu Sep 6 22:08:22 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 7 Sep 2007 12:08:22 +1000 Subject: [Nitro] OG [PATCH RFC]: Og test helper - Cleaner setup of defaults and more flexible Message-ID: <389c43e40709061908w4c23d9ddhbcbd6190c1aa80d9@mail.gmail.com> Hi Devs, A RFC on some changes to the Og test helper that shouldn't break anyones' existing tests - famous last words :) Current syntax should leave you with the current behavior. Changes: - Og setup default options are separated out and accessible. - config or config and start supported. Default is the current config and start. RFC: 1) In the config only case: should `Aspects.setup` be called before config hash is returned? Currently it is called after, so is only activated when OG has been started..... At this point I have no idea what Aspects does. 2) For clarity maybe the `default_options` accessor should just be `options` since we don't actualy chage OGs default options - those are hardcocded in og.rb? Usage: a) OgSpecHelper.setup b) OgSpecHelper.setup(:config_only=>true) c) OgSpecHelper.default_options = {.....} OgSpecHelper.setup d) OgSpecHelper.default_options = {.....} OgSpecHelper.setup(:config_only=>true) -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070907-1-rfc.patch Type: text/x-patch Size: 62970 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070907/d996bcf8/attachment-0001.bin From aurelianocalvo at yahoo.com.ar Thu Sep 6 22:08:59 2007 From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo) Date: Thu, 6 Sep 2007 23:08:59 -0300 Subject: [Nitro] Select default value. In-Reply-To: References: Message-ID: <1340963a0709061908l44508878pdd1f6b601a00f73f@mail.gmail.com> > Dear devs, > > I would like your opinion on this problem, lets say I have this select > field: > > > > > I would like to allocate a 'special' value to the default options, that > Nitro will 'ignore'. Ie if the user does not select > any gender, > > request["gender"] == nil > > and not > > request["gender"] == "??" # <-- the special value > > any ideas, suggestions? > How about? and request["gender"] == "" From arne at arnebrasseur.net Thu Sep 6 23:57:37 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 07 Sep 2007 11:57:37 +0800 Subject: [Nitro] Darcs patch mini Howto [was: Sporadic 'Found altered cookie' errors] In-Reply-To: References: <006301c7f05a$3901f160$6442a8c0@musicbox> <009d01c7f062$cfe808a0$6442a8c0@musicbox> <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> Message-ID: <46E0CC31.3000302@arnebrasseur.net> George Moschovitis schreef: > How about sending a nice Darcs patch. You will help the project and > get your name in the CONTRIBUTORS list ;-) > And just in case you (or someone else) needs to know: darcs record nitro/lib/nitro/application.rb This will record your changes as a new patch. If it's the first time you do this, darcs will ask your name and email. Press 'y' for the hunks that need to be in, 'n' for those that shouldn't. Give it a comprehensive short description and your patch gets recorded. Now you have a patch in your local repository that can be propagated to other darcs repositories, so on your local machine you can do darcs push user at host:/path/to/repo or from the remote machine darcs pull url://to_your_repo Darcs will look for patches that are in the source repo but not in the destination, and ask if you want to propagate them. Alternatively (and perhaps recommended here) is to create a patch file and send it in via email darcs send -o patch_yourname_date.patch http://repo.nitroproject.org As with push or pull you get asked which patches to send. Afterwards you just stick the patch file to an email and send it here. (ab) > thank you, > -g. > > On 9/6/07, *Bill Kelly * > wrote: > > > From: "Bill Kelly" < billk at cts.com > > > > > It seems that Application#start of nitro/lib/nitro/application.rb > > sets: @session_store = Raw::CookieSessionStore.new > > > > So that when I do app.start, @session_store will be set to > > CookieSessionStore. > > > > I can modify nitro/lib/nitro/application.rb for now, but I was > > wondering if there's a better way that I'm missing? > > N.B. I have modified Application#start in > nitro/lib/nitro/application.rb > from: > > @session_store = Raw::CookieSessionStore.new > > to: > > @session_store ||= Raw::CookieSessionStore.new > > Now I'm able to do: > > app.session_store = Raw::MemorySessionStore.new > app.start > > > Regards, > > Bill > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070907/ed8cc668/attachment.html From arne at arnebrasseur.net Fri Sep 7 00:00:55 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Fri, 07 Sep 2007 12:00:55 +0800 Subject: [Nitro] Select default value. In-Reply-To: <1340963a0709061908l44508878pdd1f6b601a00f73f@mail.gmail.com> References: <1340963a0709061908l44508878pdd1f6b601a00f73f@mail.gmail.com> Message-ID: <46E0CCF7.7020007@arnebrasseur.net> Aureliano Calvo schreef: >> request["gender"] == nil >> >> and not >> >> request["gender"] == "??" # <-- the special value >> > > How about? > > > > > I find this quite natural. > and request["gender"] == "" > Georges suggestion was that Nitro would treat this case special : request["gender"] == nil I like this, any objections? (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070907/2fb07e3d/attachment.html From george.moschovitis at gmail.com Fri Sep 7 01:37:13 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 7 Sep 2007 08:37:13 +0300 Subject: [Nitro] Select default value. In-Reply-To: <1340963a0709061908l44508878pdd1f6b601a00f73f@mail.gmail.com> References: <1340963a0709061908l44508878pdd1f6b601a00f73f@mail.gmail.com> Message-ID: > > > aah, I tried ---nosel-- and it returned "--nosel--". however, "" may be a valid value, but let me think a bit about this, I think we can make this work. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070907/3d67b75e/attachment.html From rff_rff at yahoo.it Fri Sep 7 03:30:51 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Fri, 7 Sep 2007 07:30:51 +0000 (UTC) Subject: [Nitro] Darcs patch mini Howto [was: Sporadic 'Found altered cookie' errors] References: <006301c7f05a$3901f160$6442a8c0@musicbox> <009d01c7f062$cfe808a0$6442a8c0@musicbox> <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> <46E0CC31.3000302@arnebrasseur.net> Message-ID: On Fri, 07 Sep 2007 11:57:37 +0800, Arne Brasseur wrote: > Alternatively (and perhaps recommended here) is to create a patch file > and send it in via email > > darcs send -o patch_yourname_date.patch http://repo.nitroproject.org > > As with push or pull you get asked which patches to send. Afterwards you > just stick the patch file to an email and send it here. if you did not setup your own repository, then nitro's repo will be the default, so you can omit the argumene. And if you want to send patches via mail you can simply do darcs send --to=email or darcs send and the recipient will be asked interactively. No need to create a bundle and then write the meial by yourself ;) -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From mvyver at gmail.com Fri Sep 7 04:35:14 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 7 Sep 2007 18:35:14 +1000 Subject: [Nitro] Nitro/OG spec questions Message-ID: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> Hi, As you might have seen from the previous email, I've been wrestling with specs for the DBI Adapter - I am restricting my self to adapter behavior, but still run into problems that whoever has or will spec the Manager, etc classes, is likely to encounter. Specifically, ensuring that you 'start' each spec in exactly the same state, i.e. the spec should be atomic/uncontaminated by pervious results. This seems to be the 'spec-best-practice' - correct? I can believe that because I can imagine a debug head ache if you start getting false negatives or the worst - false positives. Initially I thought to use `describe do ... end` for every spec where the options passed in are different. Even this does not help since the changed attributes (class variables) persist between 'describe' specs. I'm not familiar with the spec infrastructure - I assume starting a spec in a new file ensure your starting 'from-scratch'? Have I missed something obvious? Choices: stick with single spec file per source, and just wrestle (and cross fingers). split the sources and maintain on spec file per source file (may/ may not fully solve the issue?). adopt some convention for multiple spec files per source (pointless if this doesn't over come the above problem). Comments/thoughts/tips? Mark From rff_rff at yahoo.it Fri Sep 7 06:03:16 2007 From: rff_rff at yahoo.it (gabriele renzi) Date: Fri, 7 Sep 2007 10:03:16 +0000 (UTC) Subject: [Nitro] Nitro/OG spec questions References: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> Message-ID: On Fri, 07 Sep 2007 18:35:14 +1000, Mark Van De Vyver wrote: > I'm not familiar with the spec infrastructure - I assume starting a > spec in a new file ensure your starting 'from-scratch'? Have I missed > something obvious? AFAIK all specs are loaded together, so even sticking to single spec per source is not useful but see later. > Choices: > stick with single spec file per source, and just wrestle (and cross > fingers). split the sources and maintain on spec file per source file > (may/ may not fully solve the issue?). > adopt some convention for multiple spec files per source (pointless if > this doesn't over come the above problem). > > Comments/thoughts/tips? use before {block} after {block} for setup something between every "it" and before :all {} after :all {} for whole-spec setup/teardown i.e. I have tests like describe "foo" do before :all { Og.setup(:dbfile=>'test.db' } #run at the start of spec after { Foo.delete_all } #run between every spec it 'should create XYZ" {Foo.create("arg"); Foo.count.should == 1} after :all {File.delete('test.db') } #run at end for cleanup end This is general good practice for tests. -- goto 10: http://www.goto10.it blog it: http://riffraff.blogsome.com blog en: http://www.riffraff.info From mvyver at gmail.com Fri Sep 7 07:22:32 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 7 Sep 2007 21:22:32 +1000 Subject: [Nitro] Nitro/OG spec questions In-Reply-To: References: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> Message-ID: <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> Hi Gabrielle, On 9/7/07, gabriele renzi wrote: > On Fri, 07 Sep 2007 18:35:14 +1000, Mark Van De Vyver wrote: > > > I'm not familiar with the spec infrastructure - I assume starting a > > spec in a new file ensure your starting 'from-scratch'? Have I missed > > something obvious? > > AFAIK all specs are loaded together, so even sticking to single spec per > source is not useful but see later. Thanks. Good to know. > > Choices: > > stick with single spec file per source, and just wrestle (and cross > > fingers). split the sources and maintain on spec file per source file > > (may/ may not fully solve the issue?). > > adopt some convention for multiple spec files per source (pointless if > > this doesn't over come the above problem). > > > > Comments/thoughts/tips? > > use > before {block} > after {block} > for setup something between every "it" and > before :all {} > after :all {} > for whole-spec setup/teardown > > i.e. I have tests like > > describe "foo" do > before :all { Og.setup(:dbfile=>'test.db' } #run at the start of spec > > after { Foo.delete_all } #run between every spec > > it 'should create XYZ" {Foo.create("arg"); Foo.count.should == 1} > > after :all {File.delete('test.db') } #run at end for cleanup > end > > This is general good practice for tests. Thanks much appreciated. Regards Mark > > > -- > goto 10: http://www.goto10.it > blog it: http://riffraff.blogsome.com > blog en: http://www.riffraff.info > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From mvyver at gmail.com Fri Sep 7 09:09:42 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 7 Sep 2007 23:09:42 +1000 Subject: [Nitro] Nitro/OG spec questions In-Reply-To: <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> References: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> Message-ID: <389c43e40709070609n416cccf7pa31a6351dade77b@mail.gmail.com> Hi Devs, In case any one is interested, it seems what I really wanted to do isn't so straight forward... Essentially, that is something like: delete a class. The following is an old thread, 2002, but I've not yet seen anything setting out how this can be done in a straight forward manner: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/58851 For what it is worth If I use : it do @manager=Og.start @manager.should be_an_instance_of(Og::Manager) end Several such specs pass, so then I add: after(:each) do @manager.store.disconnect Object.module_eval { remove_const '@manager' } end and the spec fails. I get same result (failing spec) using the approach set out in ./og/.old_test/spec, i.e. after(:each) do @manager.store.disconnect #Object.module_eval { remove_const '@manager' } OgSpecHelper.stop(@manager) end where: module OgSpecHelper class << self def stop(manager) manager.close_store manager.unmanage_classes end end end I think I'm going to have to work a different way... unless there is something obvious I'm missing or doing wrong? Mark On 9/7/07, Mark Van De Vyver wrote: > Hi Gabrielle, > > On 9/7/07, gabriele renzi wrote: > > On Fri, 07 Sep 2007 18:35:14 +1000, Mark Van De Vyver wrote: > > > > > I'm not familiar with the spec infrastructure - I assume starting a > > > spec in a new file ensure your starting 'from-scratch'? Have I missed > > > something obvious? > > > > AFAIK all specs are loaded together, so even sticking to single spec per > > source is not useful but see later. > > Thanks. Good to know. > > > > Choices: > > > stick with single spec file per source, and just wrestle (and cross > > > fingers). split the sources and maintain on spec file per source file > > > (may/ may not fully solve the issue?). > > > adopt some convention for multiple spec files per source (pointless if > > > this doesn't over come the above problem). > > > > > > Comments/thoughts/tips? > > > > use > > before {block} > > after {block} > > for setup something between every "it" and > > before :all {} > > after :all {} > > for whole-spec setup/teardown > > > > i.e. I have tests like > > > > describe "foo" do > > before :all { Og.setup(:dbfile=>'test.db' } #run at the start of spec > > > > after { Foo.delete_all } #run between every spec > > > > it 'should create XYZ" {Foo.create("arg"); Foo.count.should == 1} > > > > after :all {File.delete('test.db') } #run at end for cleanup > > end > > > > This is general good practice for tests. > > Thanks much appreciated. > Regards > Mark > > > > > > > -- > > goto 10: http://www.goto10.it > > blog it: http://riffraff.blogsome.com > > blog en: http://www.riffraff.info > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > From mvyver at gmail.com Fri Sep 7 10:50:39 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 8 Sep 2007 00:50:39 +1000 Subject: [Nitro] Nitro/OG spec questions In-Reply-To: <389c43e40709070609n416cccf7pa31a6351dade77b@mail.gmail.com> References: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> <389c43e40709070609n416cccf7pa31a6351dade77b@mail.gmail.com> Message-ID: <389c43e40709070750j58d2abc1yd813ad95af169684@mail.gmail.com> I'm making some progress, see below.... On 9/7/07, Mark Van De Vyver wrote: > Hi Devs, > In case any one is interested, it seems what I really wanted to do > isn't so straight forward... > Essentially, that is something like: delete a class. > The following is an old thread, 2002, but I've not yet seen anything > setting out how this can be done in a straight forward manner: > > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/58851 > > For what it is worth If I use : > it do > @manager=Og.start > @manager.should be_an_instance_of(Og::Manager) > end > > Several such specs pass, so then I add: > > after(:each) do > @manager.store.disconnect > Object.module_eval { remove_const '@manager' } > end > > and the spec fails. > > I get same result (failing spec) using the approach set out in > ./og/.old_test/spec, i.e. > > after(:each) do > @manager.store.disconnect > #Object.module_eval { remove_const '@manager' } > OgSpecHelper.stop(@manager) > end If I use after :all {....} instead of after :each{....}: after(:all) do @manager.store.disconnect OgSpecHelper.stop(@manager) end > where: > > module OgSpecHelper > class << self > def stop(manager) > manager.close_store > manager.unmanage_classes > end > end > end Then I get the mentioned specs to pass, now I'm running into some other issues, and I'm beginning to think the after :each {...} failure was because I effectively had: manager.store.disconnect manager.close_store manager.unmanage_classes I think the duplicate close/disconnect was causing the earlier failure.... we'll see. This has raised (excuse the pun) some questions in my mind about exceptions. I'll raise, :-) this in another thread. Cheer Mark > I think I'm going to have to work a different way... unless there is > something obvious I'm missing or doing wrong? > > Mark > > > On 9/7/07, Mark Van De Vyver wrote: > > Hi Gabrielle, > > > > On 9/7/07, gabriele renzi wrote: > > > On Fri, 07 Sep 2007 18:35:14 +1000, Mark Van De Vyver wrote: > > > > > > > I'm not familiar with the spec infrastructure - I assume starting a > > > > spec in a new file ensure your starting 'from-scratch'? Have I missed > > > > something obvious? > > > > > > AFAIK all specs are loaded together, so even sticking to single spec per > > > source is not useful but see later. > > > > Thanks. Good to know. > > > > > > Choices: > > > > stick with single spec file per source, and just wrestle (and cross > > > > fingers). split the sources and maintain on spec file per source file > > > > (may/ may not fully solve the issue?). > > > > adopt some convention for multiple spec files per source (pointless if > > > > this doesn't over come the above problem). > > > > > > > > Comments/thoughts/tips? > > > > > > use > > > before {block} > > > after {block} > > > for setup something between every "it" and > > > before :all {} > > > after :all {} > > > for whole-spec setup/teardown > > > > > > i.e. I have tests like > > > > > > describe "foo" do > > > before :all { Og.setup(:dbfile=>'test.db' } #run at the start of spec > > > > > > after { Foo.delete_all } #run between every spec > > > > > > it 'should create XYZ" {Foo.create("arg"); Foo.count.should == 1} > > > > > > after :all {File.delete('test.db') } #run at end for cleanup > > > end > > > > > > This is general good practice for tests. > > > > Thanks much appreciated. > > Regards > > Mark > > > > > > > > > > > -- > > > goto 10: http://www.goto10.it > > > blog it: http://riffraff.blogsome.com > > > blog en: http://www.riffraff.info > > > > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > From mvyver at gmail.com Fri Sep 7 10:54:45 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 8 Sep 2007 00:54:45 +1000 Subject: [Nitro] Nitro/Og exceptions: To raise or not to raise? Message-ID: <389c43e40709070754s5dc40073rbb37fba0fc9e5cc9@mail.gmail.com> Hi Devs, Following up on some 'issues I ran into with trying to spec an adapter..... I noticed that exceptions are _almost_ never raised in OG. Is there a policy? Is there a style/structure that should be following? Is there a significant performance cost? Mark From billk at cts.com Fri Sep 7 12:53:07 2007 From: billk at cts.com (Bill Kelly) Date: Fri, 7 Sep 2007 09:53:07 -0700 Subject: [Nitro] Darcs patch mini Howto [was: Sporadic 'Found altered cookie' errors] References: <006301c7f05a$3901f160$6442a8c0@musicbox> <009d01c7f062$cfe808a0$6442a8c0@musicbox> <00fc01c7f0a8$b85998c0$6442a8c0@musicbox> <46E0CC31.3000302@arnebrasseur.net> Message-ID: <00b401c7f16f$91367e80$6442a8c0@musicbox> From: Arne Brasseur > > And just in case you (or someone else) needs to know: > > darcs record nitro/lib/nitro/application.rb > > [...] Thank you! Much appreciated. Regards, Bill From arne at arnebrasseur.net Fri Sep 7 15:55:17 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 08 Sep 2007 03:55:17 +0800 Subject: [Nitro] Nitro/Og exceptions: To raise or not to raise? In-Reply-To: <389c43e40709070754s5dc40073rbb37fba0fc9e5cc9@mail.gmail.com> References: <389c43e40709070754s5dc40073rbb37fba0fc9e5cc9@mail.gmail.com> Message-ID: <46E1ACA5.9060107@arnebrasseur.net> Mark Van De Vyver schreef: > Hi Devs, > Following up on some 'issues I ran into with trying to spec an adapter..... > I noticed that exceptions are _almost_ never raised in OG. > Is there a policy? > Is there a style/structure that should be following? > Is there a significant performance cost? > This is not an easy subject, it has lots to do with development culture and philosophy. Books have been written on this. Also I'm not closely familiar with the Og code. My most humble personal opinion is that if you start raising exceptions you need clear conventions about it. Exceptions are part of the interface, it should be clear to the programmer which methods can raise which exceptions. C-style programming has always done without exceptions, just wrapping every non-trivial method in an if to see if it failed. Essentially it's the same thing, but the programming interface differs. The down and upside about exceptions is that they propagate up the stack. This is good because it follows the 'fail early' rule. The application will immediately fail if nothing is done about the error, instead of carrying on with possibly corrupt data. The developer gets early feedback, close to the source of the error. This can also be bad in production because when the error is non-critical it causes the whole application to fail, instead of carrying on. Unless you're doing banking or rocket launching it can be OK to have an application do a 'best effort'. As I said I'm not closely familiar with the Og code, I'm just spitting some random thoughts. Sorry for any conceived noise. Personally I think exceptions make the most sense if you properly layer your library/application. For every layer make an exception superclass for that layer. In the layer(s) above, always catch exceptions from below, possibly wrapping them in an exception for the current layer and raising them again. This way your interfaces stay cleanly separated... But then again imposing too many rules might seriously hamper developer creativity. I usually take the view that too much up front thought about error handling just makes the code more complex. Let the code prove itself, add error handling for areas where it shows (or it's really obvious) that things can go wrong. After all you could check for insufficient memory after every call, but it wouldn't be very useful. I think virtually every programmer has their own thought about this, I'd love to hear what others on this list think. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From mvyver at gmail.com Fri Sep 7 19:58:18 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 8 Sep 2007 09:58:18 +1000 Subject: [Nitro] Nitro/Og exceptions: To raise or not to raise? In-Reply-To: <46E1ACA5.9060107@arnebrasseur.net> References: <389c43e40709070754s5dc40073rbb37fba0fc9e5cc9@mail.gmail.com> <46E1ACA5.9060107@arnebrasseur.net> Message-ID: <389c43e40709071658l566da739raa83c40b6b81415b@mail.gmail.com> Hi Arne, On 9/8/07, Arne Brasseur wrote: > Mark Van De Vyver schreef: > > Hi Devs, > > Following up on some 'issues I ran into with trying to spec an adapter..... > > I noticed that exceptions are _almost_ never raised in OG. > > Is there a policy? > > Is there a style/structure that should be following? > > Is there a significant performance cost? > > > This is not an easy subject, it has lots to do with development culture > and philosophy. Books have been written on this. Also I'm not closely > familiar with the Og code. > > My most humble personal opinion is that if you start raising exceptions > you need clear conventions about it. Exceptions are part of the > interface, it should be clear to the programmer which methods can raise > which exceptions. > I'd tend to agree. > C-style programming has always done without exceptions, just wrapping > every non-trivial method in an if to see if it failed. Essentially it's > the same thing, but the programming interface differs. > > The down and upside about exceptions is that they propagate up the > stack. This is good because it follows the 'fail early' rule. The > application will immediately fail if nothing is done about the error, > instead of carrying on with possibly corrupt data. The developer gets > early feedback, close to the source of the error. > Yes, this would have helped in my case, but.... > This can also be bad in production because when the error is > non-critical it causes the whole application to fail, instead of > carrying on. Unless you're doing banking or rocket launching it can be > OK to have an application do a 'best effort'. > you're right. It'd be brave to predict how Nitro/OG will be used or (in my case) abused. Most people would be building on top of OG, so I imagine they would rather not have to catch umpteen different exceptions. With one possible exception ;-).... > > As I said I'm not closely familiar with the Og code, I'm just spitting > some random thoughts. Sorry for any conceived noise. > No, keep them coming. > Personally I think exceptions make the most sense if you properly layer > your library/application. Would it be stretching things too far to say that _fully_ and _properly_ (don't ask me to define those) spec'd code is in much lesser need of exception handling? ()I'm not claiming there is no need for it, just a lesser need to have it through out the code, it may still be important at the last layer?) >From my impression of what spec's tend to do... the result is that for someone writing code and 'dealing with' a low level/internal OG method or object, the approach/advice might be: Rather than relying on handling exceptions in their code, they would be best advised to check their code can handle all the behavior that is spec'd for that OG method or object. So the exception handling is done at write time rather than run time - am I way off the mark? Spec guru's? (maybe this now off-topic?) > For every layer make an exception superclass > for that layer. In the layer(s) above, always catch exceptions from > below, possibly wrapping them in an exception for the current layer and > raising them again. This way your interfaces stay cleanly separated... Sounds nice :) > But then again imposing too many rules might seriously hamper developer > creativity. I usually take the view that too much up front thought about > error handling just makes the code more complex. Let the code prove > itself, add error handling for areas where it shows (or it's really > obvious) that things can go wrong. After all you could check for > insufficient memory after every call, but it wouldn't be very useful. > I'd agree with that. I think people would be more comfortable with this knowing that the code was 'fully' spec'd - what this is, is probably a moving target. The possible exception I mentioned earlier.... where you use a package that throws exceptions you should rescue those? Let anything else go through? I'm not familiar with Facets and what it does - I suppose a good time to look into that is soon. Another possibility is to only place exceptions in a particular layer of code, say the last layer(s). This too you'd probably only be able to do with some confidence once and the behavior was set out. In the case of OG this would mean og.rb and/or the vendor adapter ruby files. Any strong opinions? > I think virtually every programmer has their own thought about this, I'd > love to hear what others on this list think. > Unless I'm way off the mark with my previous comments.... I'd be inclined/happy to keep exceptions out of it as much as possible (nice vague statements), relying on the specs to guide people on how to use the objects and methods, and what to except from them. This would probably mean asking the current (low level) users and spec writers to tough it out in the mean time. Also, let's face it, I don't see this list full of people emailing with tails of woe about unexpected/unfathomable failures/behavior, so it seems the code is pretty well proved. Leave aside some instances of me mis-using some OG objects out of ignorance :) Cheers Mark > (ab) > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > From george.moschovitis at gmail.com Sat Sep 8 03:17:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 8 Sep 2007 10:17:18 +0300 Subject: [Nitro] Nitro/Og exceptions: To raise or not to raise? In-Reply-To: <389c43e40709071658l566da739raa83c40b6b81415b@mail.gmail.com> References: <389c43e40709070754s5dc40073rbb37fba0fc9e5cc9@mail.gmail.com> <46E1ACA5.9060107@arnebrasseur.net> <389c43e40709071658l566da739raa83c40b6b81415b@mail.gmail.com> Message-ID: You are right, Og does not use Exceptions as much as it should. This is starting to change, for example the new version raises a ValidationError exception when trying to save an invalid object. I think, more changes along this line are needed. We will have to discuss this in future posts. However, if you have identified a particular spot where an exception should be raised, please let us know. thanks, George. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070908/e427b061/attachment-0001.html From mvyver at gmail.com Sat Sep 8 07:27:40 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 8 Sep 2007 21:27:40 +1000 Subject: [Nitro] Nitro/OG spec questions In-Reply-To: <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> References: <389c43e40709070135l6def0539l1b00ac0c0a9dd455@mail.gmail.com> <389c43e40709070422k3d2ee896m78393293a3d0aebe@mail.gmail.com> Message-ID: <389c43e40709080427g2007ed36md754e31e3e3429c4@mail.gmail.com> Hi Gabrielle On 9/7/07, Mark Van De Vyver wrote: > Hi Gabrielle, > > On 9/7/07, gabriele renzi wrote: > > On Fri, 07 Sep 2007 18:35:14 +1000, Mark Van De Vyver wrote: > > > > > I'm not familiar with the spec infrastructure - I assume starting a > > > spec in a new file ensure your starting 'from-scratch'? Have I missed > > > something obvious? > > > > AFAIK all specs are loaded together, so even sticking to single spec per > > source is not useful but see later. > > Thanks. Good to know. > > > > Choices: > > > stick with single spec file per source, and just wrestle (and cross > > > fingers). split the sources and maintain on spec file per source file > > > (may/ may not fully solve the issue?). > > > adopt some convention for multiple spec files per source (pointless if > > > this doesn't over come the above problem). > > > > > > Comments/thoughts/tips? > > > > use > > before {block} > > after {block} > > for setup something between every "it" and > > before :all {} > > after :all {} > > for whole-spec setup/teardown > > > > i.e. I have tests like > > > > describe "foo" do > > before :all { Og.setup(:dbfile=>'test.db' } #run at the start of spec > > > > after { Foo.delete_all } #run between every spec Sorry for being a bit slow on the up-take, I was not clear that wanted to delete the manger between specs :-) I now see that store and model have this `delete_all` method. I didn't fully appreciate your tip at the time. Thanks for the insight. Cheers Mark > > it 'should create XYZ" {Foo.create("arg"); Foo.count.should == 1} > > > > after :all {File.delete('test.db') } #run at end for cleanup > > end > > > > This is general good practice for tests. > > Thanks much appreciated. > Regards > Mark > > > > > > > -- > > goto 10: http://www.goto10.it > > blog it: http://riffraff.blogsome.com > > blog en: http://www.riffraff.info > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > From mvyver at gmail.com Sat Sep 8 07:43:54 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sat, 8 Sep 2007 21:43:54 +1000 Subject: [Nitro] OG accessing manager attributes 'beneath' manager.store.ogmanager Message-ID: <389c43e40709080443l6d3d209do48b47cb3b6e9f04c@mail.gmail.com> Hi, In the context of writing a spec, I'm having trouble accessing any attribute "below" the @manager.store.ogmanager attribute. By below I mean in reference to the print out below. Hopefully I'm doing something really dumb, I can print everything from `@manager.models` down to `@manager.store.ogmanager`, but nothing beneath that. Specifically, for example, `pp @manager.store.options` gives an error, see the end of the the following output (Questions follow below): > @config = OgSpecHelper.setup({:config_only=>true}) > @manager = Og.start > Aspects.setup > pp @manager >. pp @manager.store.options #:memory, :user=>"", :dbi_driver=>:sqlite, :evolve_schema=>:warn, :password=>"", :called_by_og_setup=>true, :adapter=>:dbi}, @store= #, @trace_mode=2, @trace_output=#>, @ogmanager=#, @options= {:name=>:memory, :user=>"", :dbi_driver=>:sqlite, :evolve_schema=>:warn, :password=>"", :called_by_og_setup=>true, :adapter=>:dbi}, @transaction_nesting=0, @typemap= {Fixnum=>"integer", Time=>"timestamp", Float=>"float", Integer=>"integer", Date=>"date", TrueClass=>"boolean", Hash=>"text", Og::Blob=>"bytea", Object=>"text", String=>"text", Array=>"text"}>, @store_class=Og::DbiAdapter> NoMethodError in 'A default connection to a new Og store manager before(:all)' undefined method `options' for # Is this expected behavior? If not, any suggestions about what might be causing this? Mark From mvyver at gmail.com Sat Sep 8 17:50:47 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 9 Sep 2007 07:50:47 +1000 Subject: [Nitro] OG [PATCH RFC]: Hash.dup -> deep copy function intended? Message-ID: <389c43e40709081450p4f32c61dj5fae847cd6fb36af@mail.gmail.com> Hi Devs, Looking over some of the OG code I see a fair amount of `Hash#dup`, where typically the Hash is some options hash passed in to the method. Some times options are updated/deleted/altered. I'm assuming the intent of the Hash#dup is to isolate any changes to these options (if not, I'd be interested to know what value .dup adds), but my understanding is that this (use of .dup) won't be the case with Hash.dup, and a deep copy is required. My Q is: Is this right or is there some other reason for using Hash#dup? Is Marshal.load(Marshal.dump(hash)) the preferred (for performance) deep copy method? OG examples: ./og/lib/og/store/model.rb 328, 348, 780 ./og/lib/og/store/sql.rb 421 example patch attached. Cheers Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070908-3.patch Type: text/x-patch Size: 63496 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/87d388e3/attachment-0001.bin From mvyver at gmail.com Sat Sep 8 19:56:18 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 9 Sep 2007 09:56:18 +1000 Subject: [Nitro] OG accessing manager attributes 'beneath' manager.store.ogmanager In-Reply-To: <389c43e40709080443l6d3d209do48b47cb3b6e9f04c@mail.gmail.com> References: <389c43e40709080443l6d3d209do48b47cb3b6e9f04c@mail.gmail.com> Message-ID: <389c43e40709081656h7dab24a4m4056d9ed228349e9@mail.gmail.com> Hi, To make it clearer, the following script should help.... Can anyone confirm that: a) whether any of the three commented out lines fail/succeed? b) Is this expected? c) If yes, can that data be accessed any other way? Thanks Mark ************ start script ************ #!/usr/bin/ruby require "spec" require "yaml" require "pp" begin require "rubygems" rescue LoadError => ex # drink it! end require "og" @manager = Og.start Aspects.setup pp @manager pp @manager.store.class.name pp @manager.store.conn pp @manager.store.ogmanager #pp @manager.store.options #undefined method `options' ... #pp @manager.store.transaction_nesting #undefined method `transaction_nesting'... pp @manager.store.typemap #pp @manager.store.store_class # undefined method `store_class' ************ End script ************ On 9/8/07, Mark Van De Vyver wrote: > Hi, > In the context of writing a spec, I'm having trouble accessing any > attribute "below" the @manager.store.ogmanager attribute. > > By below I mean in reference to the print out below. > > Hopefully I'm doing something really dumb, I can print everything from > `@manager.models` down to `@manager.store.ogmanager`, but nothing > beneath that. > > Specifically, for example, `pp @manager.store.options` gives an error, > see the end of the the following output (Questions follow below): > > > @config = OgSpecHelper.setup({:config_only=>true}) > > @manager = Og.start > > Aspects.setup > > pp @manager > >. pp @manager.store.options > > # @models=[], > @name=:memory, > @options= > {:name=>:memory, > :user=>"", > :dbi_driver=>:sqlite, > :evolve_schema=>:warn, > :password=>"", > :called_by_og_setup=>true, > :adapter=>:dbi}, > @store= > # @conn= > # @handle=#, > @trace_mode=2, > @trace_output=#>, > @ogmanager=#, > @options= > {:name=>:memory, > :user=>"", > :dbi_driver=>:sqlite, > :evolve_schema=>:warn, > :password=>"", > :called_by_og_setup=>true, > :adapter=>:dbi}, > @transaction_nesting=0, > @typemap= > {Fixnum=>"integer", > Time=>"timestamp", > Float=>"float", > Integer=>"integer", > Date=>"date", > TrueClass=>"boolean", > Hash=>"text", > Og::Blob=>"bytea", > Object=>"text", > String=>"text", > Array=>"text"}>, > @store_class=Og::DbiAdapter> > NoMethodError in 'A default connection to a new Og store manager before(:all)' > undefined method `options' for # > > Is this expected behavior? > If not, any suggestions about what might be causing this? > > Mark > From rob at robmela.com Sat Sep 8 20:46:10 2007 From: rob at robmela.com (Robert Mela) Date: Sat, 08 Sep 2007 20:46:10 -0400 Subject: [Nitro] ModelUI? Message-ID: <46E34252.6010909@robmela.com> Noticed this during a darcs pull today -- autogenerate a UI from a model? Something along the lines of the Og admin part, only more flexible? Thu Sep 6 06:56:31 EDT 2007 George Moschovitis * Introduced experimental concept of ModelUI. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070908/faba46a9/attachment.vcf From rob at robmela.com Sun Sep 9 00:34:47 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 00:34:47 -0400 Subject: [Nitro] Nitrous blog category and categories Message-ID: <46E377E7.4010801@robmela.com> I think the Rails convention of tablename := pluralized modelname is like so totally Yuck-O-la. So I'm bummed to see it in the Nitro blog example. The rationale, I suppose, is that by changing, e.g., "bicycle" to "bicycles" we indicate that the table is a set of bicycles: "bicycle" + "s" = table or set of bicycles But the saying "table of" or "set of" already means there may be more than one. Changing the morphology is redundant. The plural is also flakier. Consider a "category" table with one row. So we refer to one category as categories? It gets a little confusing. In app.rb for the blog example there's: app.dispatcher.root.comments = Comment app.dispatcher.root.categories = Category I had to add a "to_link" method to the models to get the demo to run. In category.rb I added class Category def to_link "#{title}" end ... but the dispatcher path is /categories/! D'oh! And in Rails we type "Category.find" to get many categories from a table full of categories.... The morphology of pluralization is an artifact of the European grammars burned into our brains. Think of Japanese. Would a Japanese programmer be at any disadvantage for the lack of pluralization in her table names? Heck, case and gnarly verb conjugations are part of how we think. We don't add those to our programming conventions ( except in variable names ). So why bother with plurals, when 1) the information it's intended to convey is already clear from context 2) It's excess code 3) It's complicated -- elk -> elk -- does it do latin? -- Is it available in Finnish -- what about the languages where it's a no-op? 4) It introduces inconsistencies in usage ( Category.find -- looks in a group of many categories, may return many categories... etc.) I bet the reason plurals are part of the convention is because...uh, because we can. A few simple rules, and a dictionary for the exceptions.... -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/29ea8760/attachment.vcf From mvyver at gmail.com Sun Sep 9 00:35:41 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Sun, 9 Sep 2007 14:35:41 +1000 Subject: [Nitro] OG accessing manager attributes 'beneath' manager.store.ogmanager In-Reply-To: <389c43e40709081656h7dab24a4m4056d9ed228349e9@mail.gmail.com> References: <389c43e40709080443l6d3d209do48b47cb3b6e9f04c@mail.gmail.com> <389c43e40709081656h7dab24a4m4056d9ed228349e9@mail.gmail.com> Message-ID: <389c43e40709082135w28a3e08ap589ee866e10bcfb8@mail.gmail.com> On 9/9/07, Mark Van De Vyver wrote: > Hi, > To make it clearer, the following script should help.... > Can anyone confirm that: > a) whether any of the three commented out lines fail/succeed? The three fail as expected. > b) Is this expected? Yes, ./og/lib/og/store.rb: attr_accessor :ogmanager ./og/lib/og/store/sql.rb attr_accessor :conn attr_accessor :typemap The other instance variables are encapsulated and aren't 'exposed', via attr_reader or attr_accessor. There is an issue here about the scope of the `options` variable. If I understand correctly: A manager looks after one-and-only-one store. - The manager and store options should never be out of sync - correct? (This wasn't necessarily the case). Can anyone confirm this should be the behavior? Mark > c) If yes, can that data be accessed any other way? > > Thanks > Mark > > ************ start script ************ > > #!/usr/bin/ruby > require "spec" > require "yaml" > require "pp" > > begin > require "rubygems" > rescue LoadError => ex > # drink it! > end > > require "og" > > @manager = Og.start > > Aspects.setup > > pp @manager > pp @manager.store.class.name > pp @manager.store.conn > pp @manager.store.ogmanager > #pp @manager.store.options #undefined method `options' ... > #pp @manager.store.transaction_nesting #undefined method > `transaction_nesting'... > pp @manager.store.typemap > #pp @manager.store.store_class # undefined method `store_class' > > ************ End script ************ > > On 9/8/07, Mark Van De Vyver wrote: > > Hi, > > In the context of writing a spec, I'm having trouble accessing any > > attribute "below" the @manager.store.ogmanager attribute. > > > > By below I mean in reference to the print out below. > > > > Hopefully I'm doing something really dumb, I can print everything from > > `@manager.models` down to `@manager.store.ogmanager`, but nothing > > beneath that. > > > > Specifically, for example, `pp @manager.store.options` gives an error, > > see the end of the the following output (Questions follow below): > > > > > @config = OgSpecHelper.setup({:config_only=>true}) > > > @manager = Og.start > > > Aspects.setup > > > pp @manager > > >. pp @manager.store.options > > > > # > @models=[], > > @name=:memory, > > @options= > > {:name=>:memory, > > :user=>"", > > :dbi_driver=>:sqlite, > > :evolve_schema=>:warn, > > :password=>"", > > :called_by_og_setup=>true, > > :adapter=>:dbi}, > > @store= > > # > @conn= > > # > @handle=#, > > @trace_mode=2, > > @trace_output=#>, > > @ogmanager=#, > > @options= > > {:name=>:memory, > > :user=>"", > > :dbi_driver=>:sqlite, > > :evolve_schema=>:warn, > > :password=>"", > > :called_by_og_setup=>true, > > :adapter=>:dbi}, > > @transaction_nesting=0, > > @typemap= > > {Fixnum=>"integer", > > Time=>"timestamp", > > Float=>"float", > > Integer=>"integer", > > Date=>"date", > > TrueClass=>"boolean", > > Hash=>"text", > > Og::Blob=>"bytea", > > Object=>"text", > > String=>"text", > > Array=>"text"}>, > > @store_class=Og::DbiAdapter> > > NoMethodError in 'A default connection to a new Og store manager before(:all)' > > undefined method `options' for # > > > > Is this expected behavior? > > If not, any suggestions about what might be causing this? > > > > Mark > > > From george.moschovitis at gmail.com Sun Sep 9 03:24:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 9 Sep 2007 10:24:27 +0300 Subject: [Nitro] ModelUI? In-Reply-To: <46E34252.6010909@robmela.com> References: <46E34252.6010909@robmela.com> Message-ID: > > autogenerate a UI from a model? Something along the lines of the Og > admin part, only more flexible? I am working on a new improved administration system (called System part). It will be an alternative to the Admin part. It gives you much more functionality, but it needs more complicated initialization. ModelUI (temp title) allows you to customize the way the scaffolding code renders lists, forms etc. The initial code I have is very promising ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070909/5cc3e270/attachment.html From george.moschovitis at gmail.com Sun Sep 9 03:33:20 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 9 Sep 2007 10:33:20 +0300 Subject: [Nitro] Nitrous blog category and categories In-Reply-To: <46E377E7.4010801@robmela.com> References: <46E377E7.4010801@robmela.com> Message-ID: > > I think the Rails convention of tablename := pluralized modelname is > like so totally Yuck-O-la. Hello Robert, Og uses singular for table names. And we use singular for all directories. app.dispatcher.root.comments = Comment > app.dispatcher.root.categories = Category this has nothing to do with the database or the tables. A plural is used here to provide standard REST urls: /comments -> lists the comments /comments/view/1 -> view comment 1 it makes not much sense to use /comment to list all comments. However, since we use singular in all other places in Nitro/Og, for some time now I am thinking to use singular even on controller mount points. This is a personal decision though. The important thing is that Nitro/Og uses singular throughout, but allows the developer to override this (as is the case in the Blog example: the developer (me) decided to use plural names as mount points) regards, George. I had to add a "to_link" method to the models to get the demo to run. > In category.rb I added > > class Category > def to_link > "#{title}" > end > > ... but the dispatcher path is /categories/! D'oh! > > And in Rails we type "Category.find" to get many categories from a table > full of categories.... > > The morphology of pluralization is an artifact of the European grammars > burned into our brains. Think of Japanese. Would a Japanese > programmer be at any disadvantage for the lack of pluralization in her > table names? > > Heck, case and gnarly verb conjugations are part of how we think. We > don't add those to our programming conventions ( except in variable > names ). So why bother with plurals, when > > 1) the information it's intended to convey is already clear from context > 2) It's excess code > 3) It's complicated > -- elk -> elk > -- does it do latin? > -- Is it available in Finnish > -- what about the languages where it's a no-op? > 4) It introduces inconsistencies in usage ( Category.find -- looks in a > group of many categories, may return many categories... etc.) > > I bet the reason plurals are part of the convention is because...uh, > because we can. A few simple rules, and a dictionary for the > exceptions.... > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070909/4beac6f8/attachment.html From arne at arnebrasseur.net Sun Sep 9 05:54:13 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 09 Sep 2007 17:54:13 +0800 Subject: [Nitro] ModelUI? In-Reply-To: References: <46E34252.6010909@robmela.com> Message-ID: <46E3C2C5.9010507@arnebrasseur.net> George Moschovitis schreef: > ModelUI (temp title) allows you to customize the way the scaffolding > code renders lists, forms etc. I think ModelUI isn't such a bad name, for certain better than ModelView, the other name you propose in the code's comments. (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From rob at robmela.com Sun Sep 9 06:45:16 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 06:45:16 -0400 Subject: [Nitro] Nitrous blog category and categories In-Reply-To: References: <46E377E7.4010801@robmela.com> Message-ID: <1189334716.3406.47.camel@rmela-desktop> Is there a REST spec? "Plural" does not appear in Fielding's dissertation. The Wikipedia article on Restful_State_Transfer lists these as REST URLS: http://example.com/users/ http://example.com/users/{user} (one for each user) http://example.com/findUserForm http://example.com/locations/ http://example.com/locations/{location} (one for each location) http://example.com/findLocationForm I suspect, but do not know, that a NOUN is a controller noun as defined by REST, and it's accidental that we use natural language nouns. And when we do use natural language nouns, the plural/singular is a stylistic, arbitrary matter. Maybe I'm just Googling in all the wrong places :( On Sun, 2007-09-09 at 10:33 +0300, George Moschovitis wrote: > I think the Rails convention of tablename := pluralized > modelname is > like so totally Yuck-O-la. > > Hello Robert, > > Og uses singular for table names. And we use singular for all > directories. > > > app.dispatcher.root.comments = Comment > app.dispatcher.root.categories = Category > > this has nothing to do with the database or the tables. A plural is > used here to provide standard REST urls: > > /comments -> lists the comments > /comments/view/1 -> view comment 1 > > it makes not much sense to use /comment to list all comments. However, > since we use singular in all other places in Nitro/Og, for some time > now I am thinking to use singular even on controller mount points. > This is a personal decision though. > > The important thing is that Nitro/Og uses singular throughout, but > allows the developer to override this (as is the case in the Blog > example: the developer (me) decided to use plural names as mount > points) > > > regards, > George. > > > > > I had to add a "to_link" method to the models to get the demo > to run. > In category.rb I added > > class Category > def to_link > "#{title}" > end > > ... but the dispatcher path is /categories/! D'oh! > > And in Rails we type "Category.find" to get many categories > from a table > full of categories.... > > The morphology of pluralization is an artifact of the European > grammars > burned into our brains. Think of Japanese. Would a > Japanese > programmer be at any disadvantage for the lack of > pluralization in her > table names? > > Heck, case and gnarly verb conjugations are part of how we > think. We > don't add those to our programming conventions ( except in > variable > names ). So why bother with plurals, when > > 1) the information it's intended to convey is already clear > from context > 2) It's excess code > 3) It's complicated > -- elk -> elk > -- does it do latin? > -- Is it available in Finnish > -- what about the languages where it's a no-op? > 4) It introduces inconsistencies in usage ( Category.find -- > looks in a > group of many categories, may return many categories... etc.) > > I bet the reason plurals are part of the convention is > because...uh, > because we can. A few simple rules, and a dictionary for the > exceptions.... > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From wyhaines at gmail.com Sun Sep 9 10:26:01 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Sun, 9 Sep 2007 15:26:01 +0100 (BST) Subject: [Nitro] Invitation from Kirk Haines (wyhaines@gmail.com) Message-ID: <20070909142604.6BB542B08BD@mail2.quechup.com> KirkHaines (wyhaines at gmail.com) has invited you as a friend on Quechup... ...the social networking platform sweeping the globe Go to: http://quechup.com/join.php/aT0wMDAwMDAwMDEwMDM5MTg5JmM9MTAyNTU2 to accept Kirk's invite You can use Quechup to meet new people, catch up with old friends, maintain a blog, share videos & photos, chat with other members, play games, and more. It's no wonder Quechup is fast becoming 'The Social Networking site to be on' Join Kirk and his friends today: http://quechup.com/join.php/aT0wMDAwMDAwMDEwMDM5MTg5JmM9MTAyNTU2 ------------------------------------------------------------------ You received this because Kirk Haines (wyhaines at gmail.com) knows and agreed to invite you. You will only receive one invitation from wyhaines at gmail.com. Quechup will not spam or sell your email address, see our privacy policy - http://quechup.com/privacy.php Go to http://quechup.com/emailunsubscribe.php/ZW09bml0cm8tZ2VuZXJhbEBydWJ5Zm9yZ2Uub3Jn if you do not wish to receive any more emails from Quechup. ------------------------------------------------------------------ Copyright Quechup.com 2007. ------------------------------------ Go to http://quechup.com/emailunsubscribe.php/ZW09bml0cm8tZ2VuZXJhbEBydWJ5Zm9yZ2Uub3Jn if you do not wish to receive any more emails from Quechup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070909/2c506a67/attachment.html From transfire at gmail.com Sun Sep 9 14:33:37 2007 From: transfire at gmail.com (TRANS) Date: Sun, 9 Sep 2007 11:33:37 -0700 Subject: [Nitro] Fwd: [Facets] Lay me out 2.0 In-Reply-To: <1189346241.282037.147980@y42g2000hsy.googlegroups.com> References: <1189346241.282037.147980@y42g2000hsy.googlegroups.com> Message-ID: <4b6f054f0709091133m2aa71fb9k2e4b6a8badb0254b@mail.gmail.com> ---------- Forwarded message ---------- From: Trans Date: Sep 9, 2007 6:57 AM Subject: [Facets] Lay me out 2.0 To: facets-universal at rubyforge.org I'm just about ready to release version 2.0. I have only one last major decision to make, and it is an important one. So I thought it a good idea to put it out to the community. As you know, Facets 1.8+ is laid out between facets/core/ and facets/ more/ subdirectories. There is also a facet/ shortcut directory that simply contains files that redirect back to the first two. The idea being that the extension method libs were in core/, the other libs in more/, and facet/ was for convenience. With Facets 2.0 there are two points that make things different: 1) A goal of 2.0 was to make all the libs directly available via facets/, without the need for core/ or more/ or redirection. 2) The extensions are no longer stored one-file-per-method, but are instead bundled with other closely related methods. However, Facets will still provide per-method requires via redirection files. So those two points change things a bit. To take them into account, the current 2.0 layout looks like this: lib/facets/ <-- all libs lib/facet/ <-- method redirects Unfortunately this layout almost completely breaks backward- compatibility with 1.8. Is there a remedy? I could offer backward compatibility if I did this instead: lib/facets/core/ <-- method redirects lib/facets/more/ <-- additional libs lib/facets/xore/ <-- extension libs Yes, the xore/ is a bit weird (do you have a better name?), but it keeps with the flow. With this layout I can use RubyGems' libpath specification parameter to add more/ and xore/ to the load path and achieve my first goal while remaining backward compatible with 1.8. The problem though, is that _manual_ installs have no means of automatically adding to the load path. So those will need a special file that would either have to be loaded at the start of ones app or added to the RUBYOPT environment variable. Is that extra hassle worth it? And, with regard to require statements, how important is backward compatibility to you? Thanks, T. _______________________________________________ facets-universal mailing list facets-universal at rubyforge.org http://rubyforge.org/mailman/listinfo/facets-universal -- O trans ^^ transfire at gmail.com If there's one thing I learned from watching sitcoms it's this: whenever someone abruptly says "don't be silly", by all means be silly! From rob at robmela.com Sun Sep 9 15:13:21 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 15:13:21 -0400 Subject: [Nitro] Nitrous blog category and categories In-Reply-To: References: <46E377E7.4010801@robmela.com> Message-ID: <46E445D1.6020603@robmela.com> I read and understand what you've written. Nitro is really good at working like I expect, and it's great that - Og uses singular for table names and directories - Router mount points are left to developer discretion in Nitro - Router mount point names are independent of table names Nitro in fact makes the consistency I'm suggesting possible. What I'm saying is that - I don't think that REST specifies use of plurals as REST controller nouns - Using plurals introduces inconsistencies all its own, and is more trouble than its worth It makes sense, if we think of a REST controller noun as opposed to an English noun, to use "comment" to list all comments. It only looks funny at first due to our inability to think outside our European grammars. Even if one decides that morphology matters here, then the flip side is that "/comments/11" is a silly way to retrieve a single comment! So do we have /comment/11 and /comments? It's rife with inconsistencies! And it gets confusing when half the English speaking population doesn't know criteria / criterium, hypothesis / hypotheses, and our zoo database needs elk/elk and deer/deer, and our sidewalk has passerby / passersby... It's weird, it's ugly, it doesn't match the table and class names... and I can't even see any official standards that say the controller noun needs to be plural. If REST-mania had started in Japan there would be no such issue, as there's no morphological change to indicate plural! Nitro does a great job of breaking away from Rails on this -- it'd be wonderful to maintain that simplicity and consistency in REST on Nitro. George Moschovitis wrote: > > I think the Rails convention of tablename := pluralized modelname is > like so totally Yuck-O-la. > > > Hello Robert, > > Og uses singular for table names. And we use singular for all > directories. > > app.dispatcher.root.comments = Comment > app.dispatcher.root.categories = Category > > > this has nothing to do with the database or the tables. A plural is > used here to provide standard REST urls: > > /comments -> lists the comments > /comments/view/1 -> view comment 1 > > it makes not much sense to use /comment to list all comments. However, > since we use singular in all other places in Nitro/Og, for some time > now I am thinking to use singular even on controller mount points. > This is a personal decision though. > > The important thing is that Nitro/Og uses singular throughout, but > allows the developer to override this (as is the case in the Blog > example: the developer (me) decided to use plural names as mount points) > > > regards, > George. > > > > > I had to add a "to_link" method to the models to get the demo to run. > In category.rb I added > > class Category > def to_link > "#{title}" > end > > ... but the dispatcher path is /categories/! D'oh! > > And in Rails we type "Category.find" to get many categories from a > table > full of categories.... > > The morphology of pluralization is an artifact of the European > grammars > burned into our brains. Think of Japanese. Would a Japanese > programmer be at any disadvantage for the lack of pluralization in her > table names? > > Heck, case and gnarly verb conjugations are part of how we think. We > don't add those to our programming conventions ( except in variable > names ). So why bother with plurals, when > > 1) the information it's intended to convey is already clear from > context > 2) It's excess code > 3) It's complicated > -- elk -> elk > -- does it do latin? > -- Is it available in Finnish > -- what about the languages where it's a no-op? > 4) It introduces inconsistencies in usage ( Category.find -- looks > in a > group of many categories, may return many categories... etc.) > > I bet the reason plurals are part of the convention is because...uh, > because we can. A few simple rules, and a dictionary for the > exceptions.... > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/99c926f2/attachment.vcf From rob at robmela.com Sun Sep 9 15:44:06 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 15:44:06 -0400 Subject: [Nitro] Poor Kirk In-Reply-To: <20070909142604.6BB542B08BD@mail2.quechup.com> References: <20070909142604.6BB542B08BD@mail2.quechup.com> Message-ID: <46E44D06.9000308@robmela.com> http://webworkerdaily.com/2007/09/05/quechup-with-a-side-of-spam/ Also, someone I know was bitten by this, and sent this in his apology: Yesterday, I signed up for a social networking group called Quechup. Somehow it got access to my Google Address book and sent out invitations from me to all 2000 entries. My apologies. To be explicit, please do not join this *&^*&^% website. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/2177d6b3/attachment.vcf From rob at robmela.com Sun Sep 9 17:21:41 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 17:21:41 -0400 Subject: [Nitro] silent failures... Message-ID: <46E463E5.1060105@robmela.com> The typo in my conf/debug.rb is not a problem. What's a problem is that: -- Nitro catches an exception while executing conf/debug.rb -- There is no printout of the exception to screen -- Nitro continues to execute AFTER failing in initialization! In my case the exception is thrown before Og initialization occurs. It's pointless and confusing to allow a program to continue running after that... it should exit ( and print an error ) at that point. The error occurs in my code, which is executed in read_configuration_file() in application.rb line 200. Whatever calls my bad code should exit after catching the exception. rdb:1) bt --> #0 /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:167 in 'read_configuration_file' #1 /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:200 in 'configure' #2 /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:105 in 'start' #3 app.rb:26 -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/047a76e8/attachment-0001.vcf From rob at robmela.com Sun Sep 9 22:08:20 2007 From: rob at robmela.com (Robert Mela) Date: Sun, 09 Sep 2007 22:08:20 -0400 Subject: [Nitro] OgAdminController fixes, SessionData size Message-ID: <46E4A714.9060300@robmela.com> 1) OgAdminController#save was throwing an exception that nil.NilClass has no [] method... I fixed it by changing all instance of this request['object_class_name'] to this request.post_params['object_class_name'] Is this worth a patch, or is the og admin part no longer used? 2) I'm getting a webrick internal server error with the message " Session data size exceeds the cookie size limit" How do I use a database for session store? I s'pose I could dig for it in the code... thx. -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070909/434c26c8/attachment.vcf From mvyver at gmail.com Mon Sep 10 00:55:47 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 10 Sep 2007 14:55:47 +1000 Subject: [Nitro] OG RFC: Manager-Store-Adapter options and new store_details attr Message-ID: <389c43e40709092155t4d066abbx2c881a8e0a8ea023@mail.gmail.com> Hi, As you'd have seen from some earlier emails, I've been getting up to speed on the OG Manager-Store-Adapter relation. Currently, start-up options are passed from manger to adapter and immediately are out of sync: manage.options indicates nothing about the options that store has used. Store @options isn't readable or settable. To sync and provide some flexibility I'll need later I thought to make the following changes - these shouldn't break existing behavior, and are the smallest I could come up with that give the flexibility I think I'll need. Maybe use details instead of store_details? Comments welcome. Mark # start ruby script require "pp" module Og class Manager attr_accessor :options attr_accessor :store def initialize(options) @store = Adapter.new(options) # new sync manager and store options data @options = @store.store_details[:options] end end class Store attr_accessor :ogmanager attr_accessor :store_details # new def initialize(options) @store_details={} # new @store_details[:options] ||= options # new @options = @store_details[:options] # same content & behavior end end class SQLstore < Store # no changes here def initialize(options) super end end class Adapter < SQLstore # no changes here def initialize(options) super end end end @manager = Og::Manager.new({:adapter => :dbi}) pp @manager.options pp @manager.store.store_details[:options] @manager.store.store_details[:dbi_driver]=:mysql pp @manager.store.store_details @manager.store.store_details[:options][:dbi_driver]=:mysql pp @manager.options pp @manager.store.store_details[:options] pp @manager.store.store_details pp @manager.options @manager.options[:new]="option" pp @manager.store.store_details[:options] pp @manager.options # end ruby script From arne at arnebrasseur.net Mon Sep 10 03:49:19 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 10 Sep 2007 15:49:19 +0800 Subject: [Nitro] [PATCH] Proto app polish Message-ID: <46E4F6FF.8090709@arnebrasseur.net> For new users doing a nitro --create test && cd test && nitro The first makes the app run, the second brings the welcome page up to date. To be found in attachment or directly from http://darcs.arnebrasseur.net/glycerin cheers, (ab) Mon Sep 10 15:34:31 CST 2007 Arne Brasseur * include Nitro in the proto app.rb Mon Sep 10 15:40:37 CST 2007 Arne Brasseur * Bring the proto-app welcome page up to date. - Remove references to examples that are no longer included - Change 'xhtml' to 'htmlx' -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20070910.patch Type: text/x-patch Size: 63698 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070910/651a3a22/attachment-0001.bin From george.moschovitis at gmail.com Mon Sep 10 03:56:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 10:56:40 +0300 Subject: [Nitro] silent failures... In-Reply-To: <46E463E5.1060105@robmela.com> References: <46E463E5.1060105@robmela.com> Message-ID: Fixed, thanks for reporting. -g. On 9/10/07, Robert Mela wrote: > > The typo in my conf/debug.rb is not a problem. > > What's a problem is that: > > -- Nitro catches an exception while executing conf/debug.rb > -- There is no printout of the exception to screen > -- Nitro continues to execute AFTER failing in initialization! > > In my case the exception is thrown before Og initialization occurs. > It's pointless and confusing to allow a program to continue running > after that... it should exit ( and print an error ) at that point. > > The error occurs in my code, which is executed in > read_configuration_file() in application.rb line 200. Whatever calls my > bad code should exit after catching the exception. > > > > rdb:1) bt > --> #0 > > /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:167 > in 'read_configuration_file' > #1 > > /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:200 > in 'configure' > #2 > > /Users/robertmela/nitro/repo.nitroproject.org/script/lib/../../nitro/lib/nitro/application.rb:105 > in 'start' > #3 app.rb:26 > > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/dd1dc779/attachment.html From george.moschovitis at gmail.com Mon Sep 10 03:59:40 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 10:59:40 +0300 Subject: [Nitro] OgAdminController fixes, SessionData size In-Reply-To: <46E4A714.9060300@robmela.com> References: <46E4A714.9060300@robmela.com> Message-ID: > > 1) OgAdminController#save was throwing an exception that nil.NilClass > has no [] method... > > I fixed it by changing all instance of this > > request['object_class_name'] > > to this > > request.post_params['object_class_name'] > > Is this worth a patch, or is the og admin part no longer used? Please send a patch. The Admin part will not go away. 2) I'm getting a webrick internal server error with the message " > Session data size exceeds the cookie size limit" How do I use a > database for session store? I s'pose I could dig for it in the code... > try this to use the MemorySessionStore app.session_store = Raw::MemorySessionStore.new app.start Jonathan, this one is a nice candidate for an oxywtf tip. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/f4abd8d2/attachment.html From george.moschovitis at gmail.com Mon Sep 10 04:01:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 11:01:09 +0300 Subject: [Nitro] [PATCH] Proto app polish In-Reply-To: <46E4F6FF.8090709@arnebrasseur.net> References: <46E4F6FF.8090709@arnebrasseur.net> Message-ID: thank you. -g. On 9/10/07, Arne Brasseur wrote: > > For new users doing a nitro --create test && cd test && nitro > > The first makes the app run, the second brings the welcome page up to > date. > > To be found in attachment or directly from > http://darcs.arnebrasseur.net/glycerin > > cheers, > (ab) > > Mon Sep 10 15:34:31 CST 2007 Arne Brasseur > * include Nitro in the proto app.rb > > Mon Sep 10 15:40:37 CST 2007 Arne Brasseur > * Bring the proto-app welcome page up to date. > - Remove references to examples that are no longer included > - Change 'xhtml' to 'htmlx' > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/b4ca0bce/attachment.html From george.moschovitis at gmail.com Mon Sep 10 04:04:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 11:04:09 +0300 Subject: [Nitro] Fwd: [Facets] Lay me out 2.0 In-Reply-To: <4b6f054f0709091133m2aa71fb9k2e4b6a8badb0254b@mail.gmail.com> References: <1189346241.282037.147980@y42g2000hsy.googlegroups.com> <4b6f054f0709091133m2aa71fb9k2e4b6a8badb0254b@mail.gmail.com> Message-ID: Personaly I am not that interested in backwards compatibility. But I do expect that the 2.0 API will stay frozen for a long time. The constant changes are not good for this project. Moreover, I do not think that there is an easy way to offer backwards compatibility. I would suggest that you do not 'pollute' the facets 2.0directory with backwards compatibility code. Whoever wants to use the old API should use the older gem. thank you, George. On 9/9/07, TRANS wrote: > > ---------- Forwarded message ---------- > From: Trans > Date: Sep 9, 2007 6:57 AM > Subject: [Facets] Lay me out 2.0 > To: facets-universal at rubyforge.org > > > I'm just about ready to release version 2.0. I have only one last > major decision to make, and it is an important one. So I thought it a > good idea to put it out to the community. > > As you know, Facets 1.8+ is laid out between facets/core/ and facets/ > more/ subdirectories. There is also a facet/ shortcut directory that > simply contains files that redirect back to the first two. The idea > being that the extension method libs were in core/, the other libs in > more/, and facet/ was for convenience. > > With Facets 2.0 there are two points that make things different: > > 1) A goal of 2.0 was to make all the libs directly available via > facets/, without the need for core/ or more/ or redirection. > > 2) The extensions are no longer stored one-file-per-method, but are > instead bundled with other closely related methods. However, Facets > will still provide per-method requires via redirection files. > > So those two points change things a bit. To take them into account, > the current 2.0 layout looks like this: > > lib/facets/ <-- all libs > lib/facet/ <-- method redirects > > Unfortunately this layout almost completely breaks backward- > compatibility with 1.8. > > Is there a remedy? I could offer backward compatibility if I did this > instead: > > lib/facets/core/ <-- method redirects > lib/facets/more/ <-- additional libs > lib/facets/xore/ <-- extension libs > > Yes, the xore/ is a bit weird (do you have a better name?), but it > keeps with the flow. With this layout I can use RubyGems' libpath > specification parameter to add more/ and xore/ to the load path and > achieve my first goal while remaining backward compatible with 1.8. > > The problem though, is that _manual_ installs have no means of > automatically adding to the load path. So those will need a special > file that would either have to be loaded at the start of ones app or > added to the RUBYOPT environment variable. > > Is that extra hassle worth it? > > And, with regard to require statements, how important is backward > compatibility to you? > > Thanks, > T. > > _______________________________________________ > facets-universal mailing list > facets-universal at rubyforge.org > http://rubyforge.org/mailman/listinfo/facets-universal > > > -- > O trans > ^^ transfire at gmail.com > > If there's one thing I learned from watching sitcoms it's this: > whenever someone abruptly says "don't be silly", by all means be > silly! > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/96d567a0/attachment.html From george.moschovitis at gmail.com Mon Sep 10 04:05:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 11:05:52 +0300 Subject: [Nitro] OG RFC: Manager-Store-Adapter options and new store_details attr In-Reply-To: <389c43e40709092155t4d066abbx2c881a8e0a8ea023@mail.gmail.com> References: <389c43e40709092155t4d066abbx2c881a8e0a8ea023@mail.gmail.com> Message-ID: Let me think a bit about this and i will get back to you. Things are kinf of hectic here. Thanks for your work and useful posts to this list. regards, George. On 9/10/07, Mark Van De Vyver wrote: > > Hi, > As you'd have seen from some earlier emails, I've been getting up to > speed on the OG Manager-Store-Adapter relation. > > Currently, start-up options are passed from manger to adapter and > immediately are out of sync: manage.options indicates nothing about > the options that store has used. Store @options isn't readable or > settable. To sync and provide some flexibility I'll need later I > thought to make the following changes - these shouldn't break existing > behavior, and are the smallest I could come up with that give the > flexibility I think I'll need. > > Maybe use details instead of store_details? > > Comments welcome. > > Mark > > # start ruby script > > require "pp" > > module Og > > class Manager > attr_accessor :options > attr_accessor :store > def initialize(options) > > @store = Adapter.new(options) > # new sync manager and store options data > @options = @store.store_details[:options] > end > end > > class Store > > attr_accessor :ogmanager > attr_accessor :store_details # new > > def initialize(options) > @store_details={} # new > @store_details[:options] ||= options # new > @options = @store_details[:options] # same content & behavior > end > > end > > class SQLstore < Store # no changes here > def initialize(options) > super > end > end > > class Adapter < SQLstore # no changes here > > def initialize(options) > super > end > > end > > end > > @manager = Og::Manager.new({:adapter => :dbi}) > > pp @manager.options > pp @manager.store.store_details[:options] > @manager.store.store_details[:dbi_driver]=:mysql > pp @manager.store.store_details > @manager.store.store_details[:options][:dbi_driver]=:mysql > pp @manager.options > pp @manager.store.store_details[:options] > pp @manager.store.store_details > pp @manager.options > @manager.options[:new]="option" > pp @manager.store.store_details[:options] > pp @manager.options > > # end ruby script > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/b822d276/attachment-0001.html From george.moschovitis at gmail.com Mon Sep 10 04:10:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 11:10:33 +0300 Subject: [Nitro] Nitrous blog category and categories In-Reply-To: <46E445D1.6020603@robmela.com> References: <46E377E7.4010801@robmela.com> <46E445D1.6020603@robmela.com> Message-ID: I more or less agree. I will use singular for controller mount points in my projects, and (if there are no objections) I will change the default Nitro examples as well. thanks, -g. On 9/9/07, Robert Mela wrote: > > I read and understand what you've written. Nitro is really good at > working like I expect, and it's great that > > - Og uses singular for table names and directories > - Router mount points are left to developer discretion in Nitro > - Router mount point names are independent of table names > > Nitro in fact makes the consistency I'm suggesting possible. > > What I'm saying is that > > - I don't think that REST specifies use of plurals as REST controller > nouns > - Using plurals introduces inconsistencies all its own, and is more > trouble than its worth > > It makes sense, if we think of a REST controller noun as opposed to an > English noun, to use "comment" to list all comments. It only looks > funny at first due to our inability to think outside our European > grammars. > > Even if one decides that morphology matters here, then the flip side is > that "/comments/11" is a silly way to retrieve a single comment! So do > we have /comment/11 and /comments? > > It's rife with inconsistencies! And it gets confusing when half the > English speaking population doesn't know criteria / criterium, > hypothesis / hypotheses, and our zoo database needs elk/elk and > deer/deer, and our sidewalk has passerby / passersby... > > It's weird, it's ugly, it doesn't match the table and class names... and > I can't even see any official standards that say the controller noun > needs to be plural. If REST-mania had started in Japan there would be > no such issue, as there's no morphological change to indicate plural! > > Nitro does a great job of breaking away from Rails on this -- it'd be > wonderful to maintain that simplicity and consistency in REST on Nitro. > > > > George Moschovitis wrote: > > > > I think the Rails convention of tablename := pluralized modelname is > > like so totally Yuck-O-la. > > > > > > Hello Robert, > > > > Og uses singular for table names. And we use singular for all > > directories. > > > > app.dispatcher.root.comments = Comment > > app.dispatcher.root.categories = Category > > > > > > this has nothing to do with the database or the tables. A plural is > > used here to provide standard REST urls: > > > > /comments -> lists the comments > > /comments/view/1 -> view comment 1 > > > > it makes not much sense to use /comment to list all comments. However, > > since we use singular in all other places in Nitro/Og, for some time > > now I am thinking to use singular even on controller mount points. > > This is a personal decision though. > > > > The important thing is that Nitro/Og uses singular throughout, but > > allows the developer to override this (as is the case in the Blog > > example: the developer (me) decided to use plural names as mount points) > > > > > > regards, > > George. > > > > > > > > > > I had to add a "to_link" method to the models to get the demo to > run. > > In category.rb I added > > > > class Category > > def to_link > > "#{title}" > > end > > > > ... but the dispatcher path is /categories/! D'oh! > > > > And in Rails we type "Category.find" to get many categories from a > > table > > full of categories.... > > > > The morphology of pluralization is an artifact of the European > > grammars > > burned into our brains. Think of Japanese. Would a Japanese > > programmer be at any disadvantage for the lack of pluralization in > her > > table names? > > > > Heck, case and gnarly verb conjugations are part of how we think. > We > > don't add those to our programming conventions ( except in variable > > names ). So why bother with plurals, when > > > > 1) the information it's intended to convey is already clear from > > context > > 2) It's excess code > > 3) It's complicated > > -- elk -> elk > > -- does it do latin? > > -- Is it available in Finnish > > -- what about the languages where it's a no-op? > > 4) It introduces inconsistencies in usage ( Category.find -- looks > > in a > > group of many categories, may return many categories... etc.) > > > > I bet the reason plurals are part of the convention is because...uh, > > because we can. A few simple rules, and a dictionary for the > > exceptions.... > > > > > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > -- > > http://www.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/16ea5c36/attachment.html From arne at arnebrasseur.net Mon Sep 10 04:24:03 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 10 Sep 2007 16:24:03 +0800 Subject: [Nitro] Fwd: [Facets] Lay me out 2.0 In-Reply-To: References: <1189346241.282037.147980@y42g2000hsy.googlegroups.com> <4b6f054f0709091133m2aa71fb9k2e4b6a8badb0254b@mail.gmail.com> Message-ID: <46E4FF23.8050000@arnebrasseur.net> Since it's a 'major point' release I see no big problem in breaking backwards compatibility. Especially since it's not trivial in this case. It would be better if the 1.8 branch could have bugfix support for a bounded period of time, so people have time to migrate. As George said, focus on a clean and stable API that can be used for a long time, instead of focusing on backwards compatibility. Alternatively there could be a separate 'adapter' gem with all the redirects to make migrating easier. (ab) George Moschovitis schreef: > Personaly I am not that interested in backwards compatibility. But I > do expect that the 2.0 API will stay frozen for a long time. The > constant changes are not good for this project. > > Moreover, I do not think that there is an easy way to offer backwards > compatibility. I would suggest that you do not 'pollute' the facets > 2.0 directory with backwards compatibility code. Whoever wants to use > the old API should use the older gem. > > thank you, > George. > > On 9/9/07, *TRANS* > > wrote: > > ---------- Forwarded message ---------- > From: Trans > > Date: Sep 9, 2007 6:57 AM > Subject: [Facets] Lay me out 2.0 > To: facets-universal at rubyforge.org > > > > I'm just about ready to release version 2.0. I have only one last > major decision to make, and it is an important one. So I thought it a > good idea to put it out to the community. > > As you know, Facets 1.8+ is laid out between facets/core/ and facets/ > more/ subdirectories. There is also a facet/ shortcut directory that > simply contains files that redirect back to the first two. The idea > being that the extension method libs were in core/, the other libs in > more/, and facet/ was for convenience. > > With Facets 2.0 there are two points that make things different: > > 1) A goal of 2.0 was to make all the libs directly available via > facets/, without the need for core/ or more/ or redirection. > > 2) The extensions are no longer stored one-file-per-method, but are > instead bundled with other closely related methods. However, Facets > will still provide per-method requires via redirection files. > > So those two points change things a bit. To take them into account, > the current 2.0 layout looks like this: > > lib/facets/ <-- all libs > lib/facet/ <-- method redirects > > Unfortunately this layout almost completely breaks backward- > compatibility with 1.8. > > Is there a remedy? I could offer backward compatibility if I did this > instead: > > lib/facets/core/ <-- method redirects > lib/facets/more/ <-- additional libs > lib/facets/xore/ <-- extension libs > > Yes, the xore/ is a bit weird (do you have a better name?), but it > keeps with the flow. With this layout I can use RubyGems' libpath > specification parameter to add more/ and xore/ to the load path and > achieve my first goal while remaining backward compatible with 1.8. > > The problem though, is that _manual_ installs have no means of > automatically adding to the load path. So those will need a special > file that would either have to be loaded at the start of ones app or > added to the RUBYOPT environment variable. > > Is that extra hassle worth it? > > And, with regard to require statements, how important is backward > compatibility to you? > > Thanks, > T. > > _______________________________________________ > facets-universal mailing list > facets-universal at rubyforge.org > http://rubyforge.org/mailman/listinfo/facets-universal > > > > -- > O trans > ^^ transfire at gmail.com > > If there's one thing I learned from watching sitcoms it's this: > whenever someone abruptly says "don't be silly", by all means be > silly! > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/c65a61db/attachment.html From arne at arnebrasseur.net Mon Sep 10 04:28:41 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 10 Sep 2007 16:28:41 +0800 Subject: [Nitro] render :index broken Message-ID: <46E50039.3000005@arnebrasseur.net> When doing "render :index " in a controller action, the following gives me an error: #dispatcher.rb line 142 def dispatch(uri, method = :get) # Extract the query string. path, query = uri.split("?", 2) # <------- uri == "" then path == query == nil path ||= "" # <------ This solves the problem # Try to route the path. path = @router.route(path) if @router # The characters after the last '.' in the path form the # extension that itself represents the expected response # content type. ext = File.extname(path)[1..-1] || "html" # <------------ extname don't like no nil .... So if uri.length == 0, then uri.split('?') returns [], so path and query are both nil. The call to File.extname fails because of this. I solved this by adding the path ||= "", does this look like a good solution? Should I make a patch? thx, (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net From mvyver at gmail.com Mon Sep 10 04:59:08 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 10 Sep 2007 18:59:08 +1000 Subject: [Nitro] OG RFC: Manager-Store-Adapter options and new store_details attr In-Reply-To: References: <389c43e40709092155t4d066abbx2c881a8e0a8ea023@mail.gmail.com> Message-ID: <389c43e40709100159g159c2167q7d4e81befca9950b@mail.gmail.com> Hi George, On 9/10/07, George Moschovitis wrote: > Let me think a bit about this and i will get back to you. Things are kinf of > hectic here. Thanks for your work and useful posts to this list. Hmm, don't speak too soon I could turn into more hindrance than help :) There are two issues really: 1) Syncing the manager and store/adapter options listing (this I'm really not sure about). I just do this using the store_details hash because its within my skill set ;) (but I am worried about two objects sharing a hash - it doesn't feel right - probably just fear out of ignorance) 2) Providing a method that allows someone using an instance of an adapter to get information about what that adapter has setup(for this I do like the store_details hash idea, but I now wonder if that should be 'adapter_details', in case later on some 'elaborate' store needs 'store_details'). I the case of DBI this '*_details' hash will (I think) be very useful, and keep the DbiAdapter flexibile (certain dbi drivers allow you to configure/set/activate particular 'things' and we should let people do just this if they want? and if it is done it would be easy to find out about what has been done) Also it is only once a store is fully set up by the Adapter that we'll know for sure what 'state' it is in. Dynamically creating methods that return the values that would otherwise be in the store_details hash might work best? But, is more complicated(?) we'll just be replacing: special_method if store_details[:special_option] with special_method if responds_to?(...) # or method_missing? OK, of the synching issue: If Og::Manager was a module and included/extended into Store, then it might be possible to use the (Facets) Kernel.as(..).method I've seen described here: http://rubyurl.com/Oai But the Store would get 'cluttered' and one comment suggests there may to be some memory leak issue? I prefer the idea of not including or extending Manager into Store - they seem very different objects to me. I also wasn't sure how, or whether, the Advice 'before' and 'after' discussed in the list would help with the synchronization issue - I'd be interested in knowing if it's possible. Cheers Mark > regards, > George. > > > On 9/10/07, Mark Van De Vyver wrote: > > > > Hi, > > As you'd have seen from some earlier emails, I've been getting up to > > speed on the OG Manager-Store-Adapter relation. > > > > Currently, start-up options are passed from manger to adapter and > > immediately are out of sync: manage.options indicates nothing about > > the options that store has used. Store @options isn't readable or > > settable. To sync and provide some flexibility I'll need later I > > thought to make the following changes - these shouldn't break existing > > behavior, and are the smallest I could come up with that give the > > flexibility I think I'll need. > > > > Maybe use details instead of store_details? > > > > Comments welcome. > > > > Mark > > > > # start ruby script > > > > require "pp" > > > > module Og > > > > class Manager > > attr_accessor :options > > attr_accessor :store > > def initialize(options) > > > > @store = Adapter.new(options) > > # new sync manager and store options data > > @options = @store.store_details[:options] > > end > > end > > > > class Store > > > > attr_accessor :ogmanager > > attr_accessor :store_details # new > > > > def initialize(options) > > @store_details={} # new > > @store_details[:options] ||= options # new > > @options = @store_details[:options] # same content & behavior > > end > > > > end > > > > class SQLstore < Store # no changes here > > def initialize(options) > > super > > end > > end > > > > class Adapter < SQLstore # no changes here > > > > def initialize(options) > > super > > end > > > > end > > > > end > > > > @manager = Og::Manager.new({:adapter => :dbi}) > > > > pp @manager.options > > pp @manager.store.store_details[:options] > > @manager.store.store_details[:dbi_driver]=:mysql > > pp @manager.store.store_details > > @manager.store.store_details[:options][:dbi_driver]=:mysql > > pp @manager.options > > pp @manager.store.store_details[:options] > > pp @manager.store.store_details > > pp @manager.options > > @manager.options[:new]="option" > > pp @manager.store.store_details[:options] > > pp @ manager.options > > > > # end ruby script > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From mvyver at gmail.com Mon Sep 10 05:04:06 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Mon, 10 Sep 2007 19:04:06 +1000 Subject: [Nitro] Fwd: [Facets] Lay me out 2.0 In-Reply-To: <46E4FF23.8050000@arnebrasseur.net> References: <1189346241.282037.147980@y42g2000hsy.googlegroups.com> <4b6f054f0709091133m2aa71fb9k2e4b6a8badb0254b@mail.gmail.com> <46E4FF23.8050000@arnebrasseur.net> Message-ID: <389c43e40709100204o527708cem34d18b2bdde17ec7@mail.gmail.com> I've not used Factes in my own projects yet, but.... On 9/10/07, Arne Brasseur wrote: > > Since it's a 'major point' release I see no big problem in breaking > backwards compatibility. Especially since it's not trivial in this case. > > It would be better if the 1.8 branch could have bugfix support for a > bounded period of time, so people have time to migrate. > > As George said, focus on a clean and stable API that can be used for a long > time, instead of focusing on backwards compatibility. I agree with George and Arne - this would give me the warmest-fuzziest feeling of the choices available :) Mark > Alternatively there could be a separate 'adapter' gem with all the > redirects to make migrating easier. > > (ab) > > George Moschovitis schreef: > Personaly I am not that interested in backwards compatibility. But I do > expect that the 2.0 API will stay frozen for a long time. The constant > changes are not good for this project. > > Moreover, I do not think that there is an easy way to offer backwards > compatibility. I would suggest that you do not 'pollute' the facets 2.0 > directory with backwards compatibility code. Whoever wants to use the old > API should use the older gem. > > thank you, > George. > > > On 9/9/07, TRANS wrote: > > ---------- Forwarded message ---------- > > From: Trans > > Date: Sep 9, 2007 6:57 AM > > Subject: [Facets] Lay me out 2.0 > > To: facets-universal at rubyforge.org > > > > > > I'm just about ready to release version 2.0. I have only one last > > major decision to make, and it is an important one. So I thought it a > > good idea to put it out to the community. > > > > As you know, Facets 1.8+ is laid out between facets/core/ and facets/ > > more/ subdirectories. There is also a facet/ shortcut directory that > > simply contains files that redirect back to the first two. The idea > > being that the extension method libs were in core/, the other libs in > > more/, and facet/ was for convenience. > > > > With Facets 2.0 there are two points that make things different: > > > > 1) A goal of 2.0 was to make all the libs directly available via > > facets/, without the need for core/ or more/ or redirection. > > > > 2) The extensions are no longer stored one-file-per-method, but are > > instead bundled with other closely related methods. However, Facets > > will still provide per-method requires via redirection files. > > > > So those two points change things a bit. To take them into account, > > the current 2.0 layout looks like this: > > > > lib/facets/ <-- all libs > > lib/facet/ <-- method redirects > > > > Unfortunately this layout almost completely breaks backward- > > compatibility with 1.8. > > > > Is there a remedy? I could offer backward compatibility if I did this > > instead: > > > > lib/facets/core/ <-- method redirects > > lib/facets/more/ <-- additional libs > > lib/facets/xore/ <-- extension libs > > > > Yes, the xore/ is a bit weird (do you have a better name?), but it > > keeps with the flow. With this layout I can use RubyGems' libpath > > specification parameter to add more/ and xore/ to the load path and > > achieve my first goal while remaining backward compatible with 1.8. > > > > The problem though, is that _manual_ installs have no means of > > automatically adding to the load path. So those will need a special > > file that would either have to be loaded at the start of ones app or > > added to the RUBYOPT environment variable. > > > > Is that extra hassle worth it? > > > > And, with regard to require statements, how important is backward > > compatibility to you? > > > > Thanks, > > T. > > > > _______________________________________________ > > facets-universal mailing list > > facets-universal at rubyforge.org > > http://rubyforge.org/mailman/listinfo/facets-universal > > > > > > -- > > O trans > > ^^ transfire at gmail.com > > > > If there's one thing I learned from watching sitcoms it's this: > > whenever someone abruptly says "don't be silly", by all means be > > silly! > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org ________________________________ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From arne at arnebrasseur.net Mon Sep 10 07:32:23 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 10 Sep 2007 19:32:23 +0800 Subject: [Nitro] [PATCH] Bugfix in __force_#{attr} Message-ID: <46E52B47.2050405@arnebrasseur.net> Another small patch, for Og model attributes a method __force_#{attr} is dynamically added. This method is used by assign_attributes. e.g. model_instance.assign_attributes('title' => 'Programming Nitro', 'expensive' => true) For boolean attributes (with TrueClass or FalseClass as the attribute type) this method always gave 'false' for anything but the string 'on'. The new version correctly handles %w(on off true false), true, false and converts anything else to boolean according to Ruby's rules (everything is true except false and nil). I also noticed that the keys in the call to assign_attributes must be strings, this right here surprisingly doesn't work: model_instance.assign_attributes(:title => 'Programming Nitro', :expensive => true) Any thoughts? Should I change this so it can use both? thank you all, (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20070910_2.patch Type: text/x-patch Size: 63019 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070910/aa5c4c3c/attachment-0001.bin From george.moschovitis at gmail.com Mon Sep 10 07:50:14 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 14:50:14 +0300 Subject: [Nitro] [PATCH] Bugfix in __force_#{attr} In-Reply-To: <46E52B47.2050405@arnebrasseur.net> References: <46E52B47.2050405@arnebrasseur.net> Message-ID: > > > The new version correctly handles %w(on off true false), true, false and > converts anything else to boolean according to Ruby's rules (everything > is true except false and nil). thanks. I also noticed that the keys in the call to assign_attributes must be > strings, this right here surprisingly doesn't work: > > model_instance.assign_attributes(:title => 'Programming Nitro', > :expensive => true) > > Any thoughts? Should I change this so it can use both? sounds reasonable. Remember, assign_attributes uses a lower level facets method (assign_with) so you may have to cooperate with Tom (trans) on this. -g. thank you all, > (ab) > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/e1caf294/attachment.html From v.konrad at lse.ac.uk Mon Sep 10 10:08:23 2007 From: v.konrad at lse.ac.uk (vladimir konrad) Date: Mon, 10 Sep 2007 15:08:23 +0100 Subject: [Nitro] porting from 0.41 to 0.5 Message-ID: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Hello! I have a controller method which takes one parameter (hostname). The following URL worked in 0.41 but does not in 0.5 (latest nitro trunk): http://localhost:9000/afs/server/norte.lse.ac.uk The norte.lse.ac.uk is the parameter. The erros is ERROR: Cannot respond to '/afs/server/norte.lse.ac.uk' using the 'uk' format representation. Any ideas? Vlad Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm From george.moschovitis at gmail.com Mon Sep 10 10:12:24 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 17:12:24 +0300 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Message-ID: Hmm, there is a problem with the '.' in the uri parameter... I cant see an easy way to fix this. anyone has any idea? -g. On 9/10/07, vladimir konrad wrote: > > > Hello! > > I have a controller method which takes one parameter (hostname). The > following URL worked in 0.41 but does not in 0.5 (latest nitro trunk): > > http://localhost:9000/afs/server/norte.lse.ac.uk > > The norte.lse.ac.uk is the parameter. The erros is > > ERROR: Cannot respond to '/afs/server/norte.lse.ac.uk' using the 'uk' > format representation. > > Any ideas? > > Vlad > > > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/1021b146/attachment.html From arne at arnebrasseur.net Mon Sep 10 10:48:14 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Mon, 10 Sep 2007 22:48:14 +0800 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Message-ID: <46E5592E.30600@arnebrasseur.net> George Moschovitis schreef: > Hmm, there is a problem with the '.' in the uri parameter... > I cant see an easy way to fix this. > > anyone has any idea? The easy way would be to just use GET parameters: http://localhost:9000/afs/server?host=norte.lse.ac.uk Maybe not the nicest solution but shouldn't be too hard to implement. Also, can't the 'router' be used to do special URI to controller mapping more flexibly then the 'dispatcher' can? If not could you maybe give an example of what the router is useful for? It's not used with normal controller/action/param URI's, right? (ab) > > -g. > > On 9/10/07, * vladimir konrad* > wrote: > > > Hello! > > I have a controller method which takes one parameter (hostname). The > following URL worked in 0.41 but does not in 0.5 (latest nitro trunk): > > http://localhost:9000/afs/server/norte.lse.ac.uk > > The norte.lse.ac.uk is the parameter. The > erros is > > ERROR: Cannot respond to '/afs/server/norte.lse.ac.uk' using the 'uk' > format representation. > > Any ideas? > > Vlad > > > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/e1427dba/attachment.html From v.konrad at lse.ac.uk Mon Sep 10 11:06:28 2007 From: v.konrad at lse.ac.uk (Vladimir Konrad) Date: Mon, 10 Sep 2007 16:06:28 +0100 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: <46E5592E.30600@arnebrasseur.net> References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> <46E5592E.30600@arnebrasseur.net> Message-ID: <20070910160628.18596784@19.201.dyn.lse.ac.uk> > The easy way would be to just use GET parameters: > > http://localhost:9000/afs/server?host=norte.lse.ac.uk no worries, i will recode it using number -> server mapping (it is not much work). Vlad Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm From rob at robmela.com Mon Sep 10 11:21:12 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 10 Sep 2007 11:21:12 -0400 Subject: [Nitro] [PATCH] Proto app polish In-Reply-To: <46E4F6FF.8090709@arnebrasseur.net> References: <46E4F6FF.8090709@arnebrasseur.net> Message-ID: <46E560E8.900@robmela.com> I think the template nitro app should include some comments & such. Was playing with this yesterday, and sample app.rb with comments in: http://robmela.com/nitrostart Arne Brasseur wrote: > For new users doing a nitro --create test && cd test && nitro > > The first makes the app run, the second brings the welcome page up to > date. > > To be found in attachment or directly from > http://darcs.arnebrasseur.net/glycerin > > cheers, > (ab) > > Mon Sep 10 15:34:31 CST 2007 Arne Brasseur > * include Nitro in the proto app.rb > > Mon Sep 10 15:40:37 CST 2007 Arne Brasseur > * Bring the proto-app welcome page up to date. > - Remove references to examples that are no longer included > - Change 'xhtml' to 'htmlx' > > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 123 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070910/5154f9a9/attachment.vcf From george.moschovitis at gmail.com Mon Sep 10 14:23:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 10 Sep 2007 21:23:28 +0300 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: <46E5592E.30600@arnebrasseur.net> References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> <46E5592E.30600@arnebrasseur.net> Message-ID: > > Also, can't the 'router' be used to do special URI to controller mapping > more flexibly then the 'dispatcher' can? > If not could you maybe give an example of what the router is useful for? > It's not used with normal controller/action/param URI's, right? > This is an excellent idea. You can use router to rewrite the URI! -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070910/b7525818/attachment-0001.html From mvyver at gmail.com Mon Sep 10 21:12:53 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Tue, 11 Sep 2007 11:12:53 +1000 Subject: [Nitro] Og tests helper In-Reply-To: <46DD3F68.2090001@arnebrasseur.net> References: <46DD3F68.2090001@arnebrasseur.net> Message-ID: <389c43e40709101812v15897677y4166005a633a958c@mail.gmail.com> I'm not sure if it's the same cause but I see the red '0 failed' results if I use the following in the test helper: OG_ADAPTER = :dbi_sqlite OG_ADAPTER = :sqlite In case I use: # OG_ADAPTER = :dbi_sqlite OG_ADAPTER = :sqlite I see the green all passed. HTH? Mark On 9/4/07, Arne Brasseur wrote: > > I found the problem, although it took some Sherlock Holmes style > investigation. Turns out the butler... uh I mean the logger did it. > > What's wrong with this code? > > def info(str) > @@global_logger << Console::ANSICode.green > @@global_logger.info(str) > @@global_logger << Console::ANSICode.clear > end > > def error(str) > @@global_logger << Console::ANSICode.red > @@global_logger.error(str) > @@global_logger << Console::ANSICode.clear > end > > The solution can be found in/pulled from my repo : > http://darcs.arnebrasseur.net/glycerin > > (in /home/plexus/work/nitro_repo) > Running og... [ 1 specs - all passed ] > Running og/store/sql... [ 1 specs - all passed ] > Running og/validation... [ 1 specs - all passed ] > 3 examples, 0 failures > > No failing examples, let's add some tests! > > (ab) > > George Moschovitis schreef: > Dear devs, > > I have a little problem with the rspec infrastructure 'borrowed' from > Ramaze. > > when I run the (few) og tests with > > rake test:og > > I get: > > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the database > before each test. It seems to trigger the error code in > script/lib/wrap.rb... > > If you run the tests one by one they work. > > Michael, Jonathan, Arne, do you have any idea? > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org ________________________________ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From arne at arnebrasseur.net Tue Sep 11 04:07:27 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 11 Sep 2007 16:07:27 +0800 Subject: [Nitro] Og tests helper In-Reply-To: <389c43e40709101812v15897677y4166005a633a958c@mail.gmail.com> References: <46DD3F68.2090001@arnebrasseur.net> <389c43e40709101812v15897677y4166005a633a958c@mail.gmail.com> Message-ID: <46E64CBF.4060905@arnebrasseur.net> Mark Van De Vyver schreef: > I'm not sure if it's the same cause but I see the red '0 failed' > results if I use the following in the test helper: > > OG_ADAPTER = :dbi_sqlite > OG_ADAPTER = :sqlite > You're reassigning a constant, ruby outputs a warning, probably on stderr. (ab) > In case I use: > > # OG_ADAPTER = :dbi_sqlite > OG_ADAPTER = :sqlite > > I see the green all passed. > > HTH? > > Mark > > > On 9/4/07, Arne Brasseur wrote: > >> I found the problem, although it took some Sherlock Holmes style >> investigation. Turns out the butler... uh I mean the logger did it. >> >> What's wrong with this code? >> >> def info(str) >> @@global_logger << Console::ANSICode.green >> @@global_logger.info(str) >> @@global_logger << Console::ANSICode.clear >> end >> >> def error(str) >> @@global_logger << Console::ANSICode.red >> @@global_logger.error(str) >> @@global_logger << Console::ANSICode.clear >> end >> >> The solution can be found in/pulled from my repo : >> http://darcs.arnebrasseur.net/glycerin >> >> (in /home/plexus/work/nitro_repo) >> Running og... [ 1 specs - all passed ] >> Running og/store/sql... [ 1 specs - all passed ] >> Running og/validation... [ 1 specs - all passed ] >> 3 examples, 0 failures >> >> No failing examples, let's add some tests! >> >> (ab) >> >> George Moschovitis schreef: >> Dear devs, >> >> I have a little problem with the rspec infrastructure 'borrowed' from >> Ramaze. >> >> when I run the (few) og tests with >> >> rake test:og >> >> I get: >> >> (in /home/gmosx/code/public) >> Running og... [ 1 specs - 0 failed ] >> Running og/store/sql... [ 1 specs - 0 failed ] >> Running og/validation... [ 1 specs - all passed ] >> -------------------------------------[ og >> ]------------------------------------- >> ExitStatus: >> # >> StdOut: >> Database "test" dropped >> . >> >> Finished in 0.136994 seconds >> >> 1 example, 0 failures >> >> The problem seems to be that the system command used to drop the database >> before each test. It seems to trigger the error code in >> script/lib/wrap.rb... >> >> If you run the tests one by one they work. >> >> Michael, Jonathan, Arne, do you have any idea? >> >> -g. >> >> >> -- >> http://www.me.gr >> http://phidz.com >> http://blog.gmosx.com >> http://cull.gr >> http://www.joy.gr >> http://nitroproject.org ________________________________ >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> -- >> Arne Brasseur >> http://www.arnebrasseur.net >> arne at arnebrasseur.net >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070911/d1c64061/attachment.html From mvyver at gmail.com Tue Sep 11 05:15:18 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Tue, 11 Sep 2007 19:15:18 +1000 Subject: [Nitro] Og tests helper In-Reply-To: <46E64CBF.4060905@arnebrasseur.net> References: <46DD3F68.2090001@arnebrasseur.net> <389c43e40709101812v15897677y4166005a633a958c@mail.gmail.com> <46E64CBF.4060905@arnebrasseur.net> Message-ID: <389c43e40709110215l1ad11bb8k756a0f0ae57c36ab@mail.gmail.com> On 9/11/07, Arne Brasseur wrote: > > Mark Van De Vyver schreef: > I'm not sure if it's the same cause but I see the red '0 failed' > results if I use the following in the test helper: > > OG_ADAPTER = :dbi_sqlite > OG_ADAPTER = :sqlite > > You're reassigning a constant, ruby outputs a warning, probably on stderr. Apologies. I'd guessed/thought rspec might distinguish between errors inside 'describe' and outside mv > (ab) > > > In case I use: > > # OG_ADAPTER = :dbi_sqlite > OG_ADAPTER = :sqlite > > I see the green all passed. > > HTH? > > Mark > > > On 9/4/07, Arne Brasseur wrote: > > > I found the problem, although it took some Sherlock Holmes style > investigation. Turns out the butler... uh I mean the logger did it. > > What's wrong with this code? > > def info(str) > @@global_logger << Console::ANSICode.green > @@global_logger.info(str) > @@global_logger << Console::ANSICode.clear > end > > def error(str) > @@global_logger << Console::ANSICode.red > @@global_logger.error(str) > @@global_logger << Console::ANSICode.clear > end > > The solution can be found in/pulled from my repo : > http://darcs.arnebrasseur.net/glycerin > > (in /home/plexus/work/nitro_repo) > Running og... [ 1 specs - all passed ] > Running og/store/sql... [ 1 specs - all passed ] > Running og/validation... [ 1 specs - all passed ] > 3 examples, 0 failures > > No failing examples, let's add some tests! > > (ab) > > George Moschovitis schreef: > Dear devs, > > I have a little problem with the rspec infrastructure 'borrowed' from > Ramaze. > > when I run the (few) og tests with > > rake test:og > > I get: > > (in /home/gmosx/code/public) > Running og... [ 1 specs - 0 failed ] > Running og/store/sql... [ 1 specs - 0 failed ] > Running og/validation... [ 1 specs - all passed ] > -------------------------------------[ og > ]------------------------------------- > ExitStatus: > # > StdOut: > Database "test" dropped > . > > Finished in 0.136994 seconds > > 1 example, 0 failures > > The problem seems to be that the system command used to drop the database > before each test. It seems to trigger the error code in > script/lib/wrap.rb... > > If you run the tests one by one they work. > > Michael, Jonathan, Arne, do you have any idea? > > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org ________________________________ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > From arne at arnebrasseur.net Tue Sep 11 06:36:04 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 11 Sep 2007 18:36:04 +0800 Subject: [Nitro] Og tests helper In-Reply-To: <389c43e40709110215l1ad11bb8k756a0f0ae57c36ab@mail.gmail.com> References: <46DD3F68.2090001@arnebrasseur.net> <389c43e40709101812v15897677y4166005a633a958c@mail.gmail.com> <46E64CBF.4060905@arnebrasseur.net> <389c43e40709110215l1ad11bb8k756a0f0ae57c36ab@mail.gmail.com> Message-ID: <46E66F94.6020502@arnebrasseur.net> Mark Van De Vyver schreef: > On 9/11/07, Arne Brasseur wrote: > >> Mark Van De Vyver schreef: >> I'm not sure if it's the same cause but I see the red '0 failed' >> results if I use the following in the test helper: >> >> OG_ADAPTER = :dbi_sqlite >> OG_ADAPTER = :sqlite >> >> You're reassigning a constant, ruby outputs a warning, probably on stderr. >> > > > Apologies. I'd guessed/thought rspec might distinguish between errors > inside 'describe' and outside > > The thing is that our test runner launches a new ruby interpreter for every test. It just scrapes stdout, stderr and the process' return code. It then parses stdout to see how many tests succeeded or failed, and checks that stderr id empty and the return code is zero. This is why sometimes it still shows the output in red, even though it reports that all tests succeeded. It sort of wraps around rspec's test runner, so it can't distinguish between inside and outside 'describe' blocks. (ab) > mv > -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070911/7cca7620/attachment.html From arne at arnebrasseur.net Tue Sep 11 06:41:07 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 11 Sep 2007 18:41:07 +0800 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> <46E5592E.30600@arnebrasseur.net> Message-ID: <46E670C3.4000709@arnebrasseur.net> George Moschovitis schreef: > > Also, can't the 'router' be used to do special URI to controller > mapping more flexibly then the 'dispatcher' can? > If not could you maybe give an example of what the router is > useful for? It's not used with normal controller/action/param > URI's, right? > > > This is an excellent idea. You can use router to rewrite the URI! Could you please give a short example of how this works? Thank you very much! (ab) -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070911/3faae254/attachment.html From george.moschovitis at gmail.com Tue Sep 11 06:51:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 11 Sep 2007 13:51:31 +0300 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: <46E670C3.4000709@arnebrasseur.net> References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> <46E5592E.30600@arnebrasseur.net> <46E670C3.4000709@arnebrasseur.net> Message-ID: Try this: def view site = request[:site] ... end ann :view, :match => %r{/view/(.*)$}, :params => [:site] -g. On 9/11/07, Arne Brasseur wrote: > > George Moschovitis schreef: > > Also, can't the 'router' be used to do special URI to controller mapping > > more flexibly then the 'dispatcher' can? > > If not could you maybe give an example of what the router is useful for? > > It's not used with normal controller/action/param URI's, right? > > > > This is an excellent idea. You can use router to rewrite the URI! > > Could you please give a short example of how this works? > > Thank you very much! > (ab) > > -- > Arne Brasseur > http://www.arnebrasseur.netarne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070911/3e252b4d/attachment-0001.html From rob at robmela.com Tue Sep 11 14:12:31 2007 From: rob at robmela.com (Robert Mela) Date: Tue, 11 Sep 2007 14:12:31 -0400 Subject: [Nitro] singleton can't be dumped In-Reply-To: <46E4A714.9060300@robmela.com> References: <46E4A714.9060300@robmela.com> Message-ID: <46E6DA8F.6010809@robmela.com> "singleton can't be dumped" is an odd way to tell me that my htmlx template is missing an HTML tag. Fortunately I'm married, and so am used to triangulating back from statements like this to locate the real meaning. yadda yadda Yields this: Internal Server Error singleton can't be dumped ------------------------------------------------------------------------ WEBrick/1.3.1 (Ruby/1.8.5/2006-12-25) at robmela.com:80 -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070911/71805049/attachment.vcf From mvyver at gmail.com Tue Sep 11 18:18:22 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 12 Sep 2007 08:18:22 +1000 Subject: [Nitro] OG with Postgresql or Oracle: vanilla methods list Message-ID: <389c43e40709111518j43a5b7av3e0038dfea035eaf@mail.gmail.com> Hi, I'd appreciate anyone with access to Postgresql, or Oracle, posting the results of the following: class PlainPostgresql < Og::PostgresqlAdapter; end; plain_postgresql = PlainPostgresql.new({}).methods.sort Or something like it. Regards Mark From mvyver at gmail.com Tue Sep 11 20:06:02 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 12 Sep 2007 10:06:02 +1000 Subject: [Nitro] Og store vs sql over-ride methods Message-ID: <389c43e40709111706w2b35f4fawe2417d855c9b0d9e@mail.gmail.com> Hi, Is my understanding correct?: Methods def'd but 'Not implemented' in 'store.rb', should or must (?) be implemented by one of its subclasses. There can be many stores, and SQL is one (popular) type. Methods def'd 'Not implemented' in 'sql.rb', should or must (?) be implemented by one of its subclasses. If this is right shouldn't the transaction related methods in 'store.rb' rather be in 'sql.rb'? Pedantic, and not fatal, I know but I'm trying to get a handle on what Og considers an SQL adapter should or must(?) implement - to my mind sql.rb should contain that info... Comments? Mark From mvyver at gmail.com Tue Sep 11 22:42:00 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 12 Sep 2007 12:42:00 +1000 Subject: [Nitro] Nitro/Og specs: Mock framework Message-ID: <389c43e40709111942h4aa44aek1454ad29aed15763@mail.gmail.com> Hi, I've seen some discussion on the rspec list that the rspec mock facility may/will be deprecated. indication is that it should support flexmock or mocha. 2 Q's: a) Anyone know if this has been decided? b) Which Nitro/Og will choose? mv From mvyver at gmail.com Wed Sep 12 03:05:28 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 12 Sep 2007 17:05:28 +1000 Subject: [Nitro] OG clarification: Adapter method source locations Message-ID: <389c43e40709120005m6bc6603fv270018e09ed0da5e@mail.gmail.com> Hi Devs, Can anyone elaborate on the following (pedantic/trivial?): Adpater methods that override methods in [./og/lib/og/store.rb] or [./og/lib/og/store/sql.rb] or [./og/lib/og/store/sql/*.rb] should be placed in: [./og/lib/og/adapter//override.rb] Adpater methods that provide adapter specific utility methods (i.e. do not appear in any of the above) should go in: [./og/lib/og/adapter//utils.rb] Consequently the bulk of the implementation will appear in the override.rb file? The file [./og/lib/og/adapter/.rb] will in-fact contain very little, possibly as little as some requires and initialize.... mv From george.moschovitis at gmail.com Wed Sep 12 03:06:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 10:06:52 +0300 Subject: [Nitro] singleton can't be dumped In-Reply-To: <46E6DA8F.6010809@robmela.com> References: <46E4A714.9060300@robmela.com> <46E6DA8F.6010809@robmela.com> Message-ID: You are right, I got to fix this... -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/16937be6/attachment.html From mvyver at gmail.com Wed Sep 12 03:19:51 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Wed, 12 Sep 2007 17:19:51 +1000 Subject: [Nitro] OG clarification: Adapter method source locations In-Reply-To: <389c43e40709120005m6bc6603fv270018e09ed0da5e@mail.gmail.com> References: <389c43e40709120005m6bc6603fv270018e09ed0da5e@mail.gmail.com> Message-ID: <389c43e40709120019tca9a734k8102a509cb2e1ee8@mail.gmail.com> Hmm, I think I've now got the hang of this: [./og/lib/og/adapter]: ---------------------------------------------- Adpater methods that override methods in [./og/lib/og/store.rb] or [./og/lib/og/store/sql.rb] or [./og/lib/og/store/sql/*.rb] should be placed here. [./og/lib/og/adapter//override.rb]: ----------------------------------------------------------- Adpater methods that override the driver methods (e.g. those in ruby-mysql, or postgr, or ruby-odbc, etc.) go here. [./og/lib/og/adapter//utils.rb]: ----------------------------------------------------- Everything else. Better? mv On 9/12/07, Mark Van De Vyver wrote: > Hi Devs, > > Can anyone elaborate on the following (pedantic/trivial?): > > Adpater methods that override methods in > [./og/lib/og/store.rb] or [./og/lib/og/store/sql.rb] or > [./og/lib/og/store/sql/*.rb] should be placed in: > [./og/lib/og/adapter//override.rb] > > Adpater methods that provide adapter specific utility methods > (i.e. do not appear in any of the above) should go in: > [./og/lib/og/adapter//utils.rb] > > Consequently the bulk of the implementation will appear in the override.rb file? > > The file [./og/lib/og/adapter/.rb] will in-fact contain very > little, possibly as little as some requires and initialize.... > > mv > From george.moschovitis at gmail.com Wed Sep 12 03:36:30 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 10:36:30 +0300 Subject: [Nitro] Og store vs sql over-ride methods In-Reply-To: <389c43e40709111706w2b35f4fawe2417d855c9b0d9e@mail.gmail.com> References: <389c43e40709111706w2b35f4fawe2417d855c9b0d9e@mail.gmail.com> Message-ID: I think transaction support is not SQL exclusive. It is a n ACID requirement for every kind of store. -g. On 9/12/07, Mark Van De Vyver wrote: > > Hi, > Is my understanding correct?: > > Methods def'd but 'Not implemented' in 'store.rb', should or must (?) > be implemented by one of its subclasses. There can be many stores, > and SQL is one (popular) type. > > Methods def'd 'Not implemented' in 'sql.rb', should or must (?) be > implemented by one of its subclasses. > > If this is right shouldn't the transaction related methods in > 'store.rb' rather be in 'sql.rb'? > > Pedantic, and not fatal, I know but I'm trying to get a handle on what > Og considers an SQL adapter should or must(?) implement - to my mind > sql.rb should contain that info... > Comments? > > Mark > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/e50ba126/attachment.html From george.moschovitis at gmail.com Wed Sep 12 03:37:16 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 10:37:16 +0300 Subject: [Nitro] Nitro/Og specs: Mock framework In-Reply-To: <389c43e40709111942h4aa44aek1454ad29aed15763@mail.gmail.com> References: <389c43e40709111942h4aa44aek1454ad29aed15763@mail.gmail.com> Message-ID: no idea. I understand there is a member of the rspec dev team on this list, maybe he can help. -g. On 9/12/07, Mark Van De Vyver wrote: > > Hi, > I've seen some discussion on the rspec list that the rspec mock > facility may/will be deprecated. > indication is that it should support flexmock or mocha. > > 2 Q's: > a) Anyone know if this has been decided? > b) Which Nitro/Og will choose? > > mv > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/08b3a91d/attachment.html From george.moschovitis at gmail.com Wed Sep 12 06:29:25 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 13:29:25 +0300 Subject: [Nitro] TMail in Nitro Message-ID: Dear devs, I planning on including the TMail source files in the Nitro distribution. I need some advanced email handling features that I don't feel like implementing from scratch. From what I see there is no gem. any objections and/or other ideas? -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/6977a427/attachment.html From john at oxyliquit.de Wed Sep 12 09:26:49 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 12 Sep 2007 15:26:49 +0200 Subject: [Nitro] OgAdminController fixes, SessionData size In-Reply-To: References: <46E4A714.9060300@robmela.com> Message-ID: Hi, > try this to use the MemorySessionStore > > app.session_store = Raw::MemorySessionStore.new > app.start see here: http://oxywtf.de/question/96 No, not only see, answer, as I cannot. :P > Jonathan, this one is a nice candidate for an oxywtf tip. Indeed, and that is where you come in. :P That is why I made Oxywtf a public web 2.0 kinda website where the community is providing the content and not necessarily the original creator. ;) So, I'd love if you'd also use it and not tell me to make Tips of things other people know way more about than me. :) Oxyliquit doesn't bite, if you lost your login I'd be more than happy to provide you with a new one. :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Sep 12 09:26:48 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 12 Sep 2007 15:26:48 +0200 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Message-ID: Hi, > Hmm, there is a problem with the '.' in the uri parameter... > I cant see an easy way to fix this. > > anyone has any idea? can I say that I find this to be an extremely bad idea? I think we had this discussion before, when Nitro regarded all URLs with a dot in it as Files (instead of normal Nitro actions). As I said before, this is an extremely bad idea. The way I discovered this before is with Oxywtf and Tags. /tag/Nitro/0.49 Which clearly should be allowed, no? But this is quite contrary to your current 'scheme'. What about configuration? "Use auto-file-type discovering" That or a definitive list of used file types. But, I always fear that this would lead to inconsistencies, depending on user input (which a URL is) is quite an icky topic to handle. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Sep 12 09:26:50 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 12 Sep 2007 15:26:50 +0200 Subject: [Nitro] OG [PATCH RFC]: Hash.dup -> deep copy function intended? In-Reply-To: <389c43e40709081450p4f32c61dj5fae847cd6fb36af@mail.gmail.com> References: <389c43e40709081450p4f32c61dj5fae847cd6fb36af@mail.gmail.com> Message-ID: Hi, > Looking over some of the OG code I see a fair amount of `Hash#dup`, where > typically the Hash is some options hash passed in to the method. > Some times options are updated/deleted/altered. > I'm assuming the intent of the Hash#dup is to isolate any changes to > these options (if not, I'd be interested to know what value .dup > adds), but my understanding is that this (use of .dup) won't be the > case with Hash.dup, and a deep copy is required. 'isolate changes to the options' is the right sentence. The Hashes are the options, and thus the Hash must be protected. The contents of the Hashes are (as far as I can remember, been a while since I last looked at it) never changed. There might be .update/.merge!/.deletes on the Hash, but since that doesn't affect the contents, the options are 'isolated'. So, while a deep copy might be the _really_ correct way, it is more expensive than simply duplicating the Hash. > My Q is: > Is this right or is there some other reason for using Hash#dup? > Is Marshal.load(Marshal.dump(hash)) the preferred (for performance) > deep copy method? I couldn't look at your patch yet, but I'm not sure if it's worth doing a deep copy. The .dups right now (I added some as well) are kind of "carefully crafted" to not lead to weird side effects. Of course, if you can find the case of some string or something else modified, just do tell. Then we might think again about using either a deep copy or just recoding the modifying code. I'm kinda late, but hope that helps, Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Sep 12 09:26:50 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 12 Sep 2007 15:26:50 +0200 Subject: [Nitro] Thank you Mark! Message-ID: Hi, (on a little break again, but still) thank you for your recent impact on Nitro/Og! Your help is really appriciated. /me also pokes Arne, specs specs specs? ;) Other than that, I'm really really happy for Nitro, the volume of the posts (I have 150 unread here, I'm really behind) is just lovely. Also thanks to all the new people here besides Mark! *bow* Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Wed Sep 12 10:03:16 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 17:03:16 +0300 Subject: [Nitro] Thank you Mark! In-Reply-To: References: Message-ID: Hopefully you will join the party as well ;-) -g. On 9/12/07, Jonathan Buch wrote: > > Hi, > > (on a little break again, but still) thank you for your recent > impact on Nitro/Og! Your help is really appriciated. > > /me also pokes Arne, specs specs specs? ;) > > Other than that, I'm really really happy for Nitro, the volume > of the posts (I have 150 unread here, I'm really behind) is > just lovely. > > Also thanks to all the new people here besides Mark! *bow* > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/55190d0e/attachment.html From george.moschovitis at gmail.com Wed Sep 12 10:05:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 17:05:57 +0300 Subject: [Nitro] OgAdminController fixes, SessionData size In-Reply-To: References: <46E4A714.9060300@robmela.com> Message-ID: ok, ok, please email me my login/password ;-) -g. On 9/12/07, Jonathan Buch wrote: > > Hi, > > > try this to use the MemorySessionStore > > > > app.session_store = Raw::MemorySessionStore.new > > app.start > > see here: > > http://oxywtf.de/question/96 > > No, not only see, answer, as I cannot. :P > > > Jonathan, this one is a nice candidate for an oxywtf tip. > > Indeed, and that is where you come in. :P > That is why I made Oxywtf a public web 2.0 kinda website where > the community is providing the content and not necessarily the > original creator. ;) > > So, I'd love if you'd also use it and not tell me to make Tips > of things other people know way more about than me. :) > > Oxyliquit doesn't bite, if you lost your login I'd be more than > happy to provide you with a new one. :) > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/b7e9a12b/attachment.html From george.moschovitis at gmail.com Wed Sep 12 10:10:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 17:10:09 +0300 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Message-ID: Ok, I will fix this like this: nitro will try to extract a filename, if is is not 'registered' it will just use the string as a param. everyone finds this logical? -g. On 9/12/07, Jonathan Buch wrote: > > Hi, > > > Hmm, there is a problem with the '.' in the uri parameter... > > I cant see an easy way to fix this. > > > > anyone has any idea? > > can I say that I find this to be an extremely bad idea? > I think we had this discussion before, when Nitro regarded > all URLs with a dot in it as Files (instead of normal Nitro > actions). As I said before, this is an extremely bad idea. > > The way I discovered this before is with Oxywtf and Tags. > > /tag/Nitro/0.49 > > Which clearly should be allowed, no? But this is quite > contrary to your current 'scheme'. > > What about configuration? "Use auto-file-type discovering" > > That or a definitive list of used file types. But, I always > fear that this would lead to inconsistencies, depending on > user input (which a URL is) is quite an icky topic to handle. > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070912/c68e4a7c/attachment.html From george.moschovitis at gmail.com Wed Sep 12 10:57:25 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 12 Sep 2007 17:57:25 +0300 Subject: [Nitro] porting from 0.41 to 0.5 In-Reply-To: References: <20070910150823.05913fd6@19.201.dyn.lse.ac.uk> Message-ID: check out the repo. if the extension is not recognized, the text after the dot is not stripped, and Nitro uses the "html" format. -g. On 9/12/07, George Moschovitis wrote: > Ok, I will fix this like this: > > nitro will try to extract a filename, if is is not 'registered' it will just > use the string as a param. > > everyone finds this logical? > > -g. > > > On 9/12/07, Jonathan Buch wrote: > > Hi, > > > > > Hmm, there is a problem with the '.' in the uri parameter... > > > I cant see an easy way to fix this. > > > > > > anyone has any idea? > > > > can I say that I find this to be an extremely bad idea? > > I think we had this discussion before, when Nitro regarded > > all URLs with a dot in it as Files (instead of normal Nitro > > actions). As I said before, this is an extremely bad idea. > > > > The way I discovered this before is with Oxywtf and Tags. > > > > /tag/Nitro/0.49 > > > > Which clearly should be allowed, no? But this is quite > > contrary to your current 'scheme'. > > > > What about configuration? "Use auto-file-type discovering" > > > > That or a definitive list of used file types. But, I always > > fear that this would lead to inconsistencies, depending on > > user input (which a URL is) is quite an icky topic to handle. > > > > Jo > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From rob at robmela.com Wed Sep 12 14:37:12 2007 From: rob at robmela.com (Robert Mela) Date: Wed, 12 Sep 2007 14:37:12 -0400 Subject: [Nitro] OgAdminController fixes, SessionData size In-Reply-To: References: <46E4A714.9060300@robmela.com> Message-ID: <46E831D8.7070802@robmela.com> And while you're at it pls provide an example of using the file session store... thx George Moschovitis wrote: > ok, ok, please email me my login/password ;-) > > -g. > > On 9/12/07, *Jonathan Buch* > wrote: > > Hi, > > > try this to use the MemorySessionStore > > > > app.session_store = Raw::MemorySessionStore.new > > app.start > > see here: > > http://oxywtf.de/question/96 > > No, not only see, answer, as I cannot. :P > > > Jonathan, this one is a nice candidate for an oxywtf tip. > > Indeed, and that is where you come in. :P > That is why I made Oxywtf a public web 2.0 kinda website where > the community is providing the content and not necessarily the > original creator. ;) > > So, I'd love if you'd also use it and not tell me to make Tips > of things other people know way more about than me. :) > > Oxyliquit doesn't bite, if you lost your login I'd be more than > happy to provide you with a new one. :) > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070912/9c2fd3a7/attachment-0001.vcf From mvyver at gmail.com Wed Sep 12 16:40:45 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 06:40:45 +1000 Subject: [Nitro] OG [PATCH RFC]: Hash.dup -> deep copy function intended? In-Reply-To: References: <389c43e40709081450p4f32c61dj5fae847cd6fb36af@mail.gmail.com> Message-ID: <389c43e40709121340vcf9dbdcuac96f43a607b05f9@mail.gmail.com> Hi, On 9/12/07, Jonathan Buch wrote: > Hi, > > > Looking over some of the OG code I see a fair amount of `Hash#dup`, where > > typically the Hash is some options hash passed in to the method. > > Some times options are updated/deleted/altered. > > I'm assuming the intent of the Hash#dup is to isolate any changes to > > these options (if not, I'd be interested to know what value .dup > > adds), but my understanding is that this (use of .dup) won't be the > > case with Hash.dup, and a deep copy is required. > > 'isolate changes to the options' is the right sentence. > > The Hashes are the options, and thus the Hash must be protected. > The contents of the Hashes are (as far as I can remember, been a > while since I last looked at it) never changed. > There might be .update/.merge!/.deletes on the Hash, but since > that doesn't affect the contents, the options are 'isolated'. > > So, while a deep copy might be the _really_ correct way, it is > more expensive than simply duplicating the Hash. > > > My Q is: > > Is this right or is there some other reason for using Hash#dup? > > Is Marshal.load(Marshal.dump(hash)) the preferred (for performance) > > deep copy method? > > I couldn't look at your patch yet, but I'm not sure if it's worth > doing a deep copy. The .dups right now (I added some as well) are > kind of "carefully crafted" to not lead to weird side effects. > > Of course, if you can find the case of some string or something > else modified, just do tell. Then we might think again about > using either a deep copy or just recoding the modifying code. I've not seen anything yet - just paranoid - but prefer performance,,,, so 'if it ain't broke.....' There is a related issue you might want to opine on. Should manager.options always be in sync with manager.store.options? This relates to, what you think is the best way to 'expose' to external users/code the state (including options) that an adapter is in.... see my later email. George is still considering this - unless something has been decided. Thanks Mark > I'm kinda late, but hope that helps, > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > From mvyver at gmail.com Wed Sep 12 16:50:44 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 06:50:44 +1000 Subject: [Nitro] Nitro/Og spec jump-start Message-ID: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> Hi Devs, Steve Ross has kindly updated his spec_todo script to rspec_todo.rb - see below. He asks to be informed of any Nitro/Og special cases..... Not pure BDDD, but saves a few keys strokes and gives a target to shoot at (and the only prepare script I'm aware of) FYI, 'not yet implemented' specs aren't parsed in the current test-helper scripts so you'll see red '0 failed' summary. Cheers Mark ---------- Forwarded message ---------- From: s.ross Date: Sep 13, 2007 4:03 AM Subject: rspec_todo To: mvyver at gmail.com I made an svn project (haven't changed my blog post yet), but you can check this out at: http://svn.calicowebdev.com/rspec_todo/trunk Note that the name has changed from spec_todo.rb to rspec_todo.rb. I also incorporated your suggestion to omit the block for the "it". I will be changing "describe" to recognize controllers, but this won't help Nitro/Og. If there are any special cases for those, I'd love to hear about them. The code still has the old do/end for the "it" block, but commented out (I know, sloppy, sloppy). If you have other suggestions that might make this tool more useful, please let me know. Thanks for your interest. --s On Sep 11, 2007, at 11:31 PM, Mark Van De Vyver wrote: > Hi Steve, > On 9/12/07, s.ross wrote: > >> The script was created a while ago and rspec has changed a bit. If >> you find any problem, let me know. > > Seems to run 90% OK. > I pointed at the Postgresql adapter file in the Nitro/Og project: > - seems to only parse one parameter. > > If you do revise, I think for the 'it' to be recognized as - Not Yet > Implemented - the do/end block is omitted. There is a new pending() > method that is recognized. > > Anyway, looks great and is a fantastic jump start/target to shoot at. > > thanks > Mark > > >> --s >> >> On Sep 11, 2007, at 8:58 PM, mvyver at gmail.com wrote: >> >>> The following person signed the Calico Web Development contact form: >>> >>> Mark Van De Vyver >>> >>> The submitted information is: >>> >>> name: Mark Van De Vyver >>> phone: >>> email: mvyver at gmail.com >>> site_type: other >>> timeframe: just kicking tires >>> >>> comments: >>> >>> Hi, >>> Thnaks for the interesting blog pages! >>> I'm writing to request a copy of the spec_todo ruby helper script - >>> the file link on Steve's "Bootstrapping RSpec Generation" blog page >>> pointed to a page pointing here... >>> >>> Thanks in advance >>> Regards >>> Mark >> >> From work at ashleymoran.me.uk Wed Sep 12 16:52:51 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Wed, 12 Sep 2007 21:52:51 +0100 Subject: [Nitro] RailsConf Berlin Message-ID: Anyone going? Bit of a long shot I guess! But would be good to meet up with Nitro users if any are around (I'm only there for the tutorial day on Monday). Actually, I've spent so much time arranging flights, accommodation etc, I've hardly had any time to actually USE Nitro this last week or two... Ashley From mvyver at gmail.com Wed Sep 12 18:39:54 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 08:39:54 +1000 Subject: [Nitro] TMail in Nitro Message-ID: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> Hi, > I planning on including the TMail source files in the Nitro distribution. I > need some advanced email handling features that I don't feel like > implementing from scratch. From what I see there is no gem. > > any objections and/or other ideas? Not an objection, just an idea..... Event Machine? http://rubyforge.org/projects/eventmachine Email is not my use-case but it seems it may have what you need? Perhaps more importantly, and if my understanding is correct, it also offers valuable 'head-room' (I've some ideas but these are half-baked at the moment)! It would be great if EM was 'accommodated' in Nitro/Og. There is also an aim to be Jruby compatible.... For those not aware of EM, from a recent post of Francis Cianfrocca : At bottom, EM is a high-performance I/O engine, very very stable and based on years on insights from high-performance network programming. It also (I will admit) enables programmers to avoid threads, which is a personal bias of mine. (In my defense, I'll say that this bias is not a prejudice. I've been writing threaded programs on Windows since the earliest Win32 betas, 15 years ago, and on Unix since before Posix threads were a standard.) Above the base level, however, the goal is to provide as complete a set of tools for network programming and distributed computing as possible, congruent with the "Ruby way." I'll be happy when Ruby programmers needing to write network-aware software can reach into the EM toolkit and just pull out what they need. A perfect example is the subject of this thread: a complete and correct implementation of SMTP (both server and client side) that any Ruby programmer can simply drop in. The SMTP implementation (like the already-existing HTTP and other implementations) throws off "events" that your programs can respond to. > -g. > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From wyhaines at gmail.com Wed Sep 12 18:53:21 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 12 Sep 2007 15:53:21 -0700 Subject: [Nitro] TMail in Nitro In-Reply-To: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> References: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> Message-ID: On 9/12/07, Mark Van De Vyver wrote: > Hi, > > > I planning on including the TMail source files in the Nitro distribution. I > > need some advanced email handling features that I don't feel like > > implementing from scratch. From what I see there is no gem. > > > > any objections and/or other ideas? > > Not an objection, just an idea..... Event Machine? > http://rubyforge.org/projects/eventmachine > > Email is not my use-case but it seems it may have what you need? TMail and the SMTP server for email are for different things. TMail is primarily used to make it easy to build email. The SMTP protocol for EM is used to create SMTP servers. As far as EM within Nitro/Og.... If one uses evented_mongrel or swiftiplied_mongrel with Nitro, then Nitro is running inside an EventMachine event loop, and an other EM stuff can then be used, as well. Kirk Haines From mvyver at gmail.com Wed Sep 12 20:09:11 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 10:09:11 +1000 Subject: [Nitro] TMail in Nitro In-Reply-To: References: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> Message-ID: <389c43e40709121709m3355ee7eo6b31e4af63f67c46@mail.gmail.com> Hi Kirk, You've more skill & experience (period) than me... do you immediately see/know of any way EM could benefit Og? yes /no response would be fine - save me wasting time pursuing this ;) My experience - in a different with Ruby threads was they hurt my performance - I see threads quite a bit in Og but don't fully understand this yet. Cheers Mark On 9/13/07, Kirk Haines wrote: > On 9/12/07, Mark Van De Vyver wrote: > > Hi, > > > > > I planning on including the TMail source files in the Nitro distribution. I > > > need some advanced email handling features that I don't feel like > > > implementing from scratch. From what I see there is no gem. > > > > > > any objections and/or other ideas? > > > > Not an objection, just an idea..... Event Machine? > > http://rubyforge.org/projects/eventmachine > > > > Email is not my use-case but it seems it may have what you need? > > TMail and the SMTP server for email are for different things. > > TMail is primarily used to make it easy to build email. > > The SMTP protocol for EM is used to create SMTP servers. > > As far as EM within Nitro/Og.... > > If one uses evented_mongrel or swiftiplied_mongrel with Nitro, then > Nitro is running inside an EventMachine event loop, and an other EM > stuff can then be used, as well. > > > Kirk Haines > From transfire at gmail.com Wed Sep 12 21:25:41 2007 From: transfire at gmail.com (Trans) Date: Thu, 13 Sep 2007 01:25:41 -0000 Subject: [Nitro] TMail in Nitro In-Reply-To: References: Message-ID: <1189646741.008780.39930@22g2000hsm.googlegroups.com> On Sep 12, 3:29 am, "George Moschovitis" wrote: > Dear devs, > > I planning on including the TMail source files in the Nitro distribution. I > need some advanced email handling features that I don't feel like > implementing from scratch. From what I see there is no gem. > > any objections and/or other ideas? I would contact Minero Aoki and ask him what the status of that project is. It looks like it hasn't been updated since 2004. You never know, Minero might suggest an alternative (have you looked for any, btw?). Or he might be willing to turn it over to you if you want to revive it. I'd be happy to set it up as a new project in that case. T. From wyhaines at gmail.com Wed Sep 12 21:31:17 2007 From: wyhaines at gmail.com (Kirk Haines) Date: Wed, 12 Sep 2007 18:31:17 -0700 Subject: [Nitro] TMail in Nitro In-Reply-To: <1189646741.008780.39930@22g2000hsm.googlegroups.com> References: <1189646741.008780.39930@22g2000hsm.googlegroups.com> Message-ID: On 9/12/07, Trans wrote: > > I planning on including the TMail source files in the Nitro distribution. I > > need some advanced email handling features that I don't feel like > > implementing from scratch. From what I see there is no gem. > > > > any objections and/or other ideas? > > I would contact Minero Aoki and ask him what the status of that > project is. It looks like it hasn't been updated since 2004. You never > know, Minero might suggest an alternative (have you looked for any, > btw?). Or he might be willing to turn it over to you if you want to > revive it. I'd be happy to set it up as a new project in that case. AFAIK, it's no longer maintained, but is widely used. There was one other project, rubymail, but it's no longer worked on, either, and tmail was better. I personally have bundled tmail, with a pure ruby version, in IOWA for quite a while now. It isn't installed if tmail is already on the system, though. Kirk Haines From ezmobius at gmail.com Wed Sep 12 21:46:11 2007 From: ezmobius at gmail.com (Ezra Zygmuntowicz) Date: Wed, 12 Sep 2007 18:46:11 -0700 Subject: [Nitro] TMail in Nitro In-Reply-To: References: <1189646741.008780.39930@22g2000hsm.googlegroups.com> Message-ID: <5633336F-B851-4C41-BD12-8930C8326B7A@gmail.com> On Sep 12, 2007, at 6:31 PM, Kirk Haines wrote: > On 9/12/07, Trans wrote: > >>> I planning on including the TMail source files in the Nitro >>> distribution. I >>> need some advanced email handling features that I don't feel like >>> implementing from scratch. From what I see there is no gem. >>> >>> any objections and/or other ideas? >> >> I would contact Minero Aoki and ask him what the status of that >> project is. It looks like it hasn't been updated since 2004. You >> never >> know, Minero might suggest an alternative (have you looked for any, >> btw?). Or he might be willing to turn it over to you if you want to >> revive it. I'd be happy to set it up as a new project in that case. > > AFAIK, it's no longer maintained, but is widely used. There was one > other project, rubymail, but it's no longer worked on, either, and > tmail was better. > > I personally have bundled tmail, with a pure ruby version, in IOWA for > quite a while now. It isn't installed if tmail is already on the > system, though. > > > Kirk Haines There is a gem called mailfactory that is maintained and works well. It;s what I'm using in merb without issues. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) From arne at arnebrasseur.net Wed Sep 12 22:16:26 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Wed, 12 Sep 2007 19:16:26 -0700 (PDT) Subject: [Nitro] Thank you Mark! In-Reply-To: References: Message-ID: <1255.140.134.80.68.1189649786.squirrel@webmail.arnebrasseur.net> > /me also pokes Arne, specs specs specs? ;) Specs are out of my hands at the moment, but I'm doing other useful stuff... to be revealed soon :) (ab) From mvyver at gmail.com Thu Sep 13 01:43:39 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 15:43:39 +1000 Subject: [Nitro] OG [PATCH RFC]: Separate Og.start options hash from Og.manager_options Message-ID: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> Hi Devs, Spec's helped indicate something was wrong but it still took much time to work out what - esp given I was working on an adapter spec and this is in the og.rb file.... :) Separate Og start options hash from Og.manager_options - consecutive starts no longer pollute Og.manager_options The attached patch attempts to isolate the options hash that og receives on start, and any changes made to it, from the defaults stored in Og.manager_options. Reason, consider the following sequence (pre-patch): Og.start # Starts with Og default options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes Og.start({}) # Starts with custom options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes Og.start # Starts with custom options - UNEXPECTED Og.manager.close_store Og.manager.unmanage_classes Instead I believe the startup behavior should be (post-patch): Og.start # Starts with Og default options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes Og.start({}) # Starts with custom options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes Og.start # Starts with Og default options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes The way to change default startup behavior would be (post-patch): Og.manger_options={}.update({}) Og.start #starts with custom options - EXPECTED Og.manager.close_store Og.manager.unmanage_classes -------------- next part -------------- A non-text attachment was scrubbed... Name: mvdv-20070913-1.patch Type: text/x-patch Size: 64546 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/3ddd0972/attachment-0001.bin From george.moschovitis at gmail.com Thu Sep 13 03:08:45 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:08:45 +0300 Subject: [Nitro] Thank you Mark! In-Reply-To: <1255.140.134.80.68.1189649786.squirrel@webmail.arnebrasseur.net> References: <1255.140.134.80.68.1189649786.squirrel@webmail.arnebrasseur.net> Message-ID: > > Specs are out of my hands at the moment, but I'm doing other useful > stuff... to be revealed soon :) sounds interesting ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/3d9f9f7e/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:13:53 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:13:53 +0300 Subject: [Nitro] RailsConf Berlin In-Reply-To: References: Message-ID: It would be nice to attend, maybe next time :( -g. On 9/12/07, Ashley Moran wrote: > > Anyone going? Bit of a long shot I guess! But would be good to meet > up with Nitro users if any are around (I'm only there for the > tutorial day on Monday). Actually, I've spent so much time arranging > flights, accommodation etc, I've hardly had any time to actually USE > Nitro this last week or two... > > Ashley > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/051774ab/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:37:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:37:23 +0300 Subject: [Nitro] OG [PATCH RFC]: Separate Og.start options hash from Og.manager_options In-Reply-To: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> References: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> Message-ID: Seems logical. I am applying the patch. However a better solution is needed (that will properly handle multiple Og stores at the same time, for db partitioning/sharding, etc) We will get back to this at a later time. thank you, George. On 9/13/07, Mark Van De Vyver wrote: > > Hi Devs, > > Spec's helped indicate something was wrong but it still took much time > to work out what - esp given I was working on an adapter spec and this > is in the og.rb file.... :) > > Separate Og start options hash from Og.manager_options - consecutive > starts no longer pollute Og.manager_options > > The attached patch attempts to isolate the options hash that og > receives on start, and any changes made to it, from the defaults > stored in Og.manager_options. > > Reason, consider the following sequence (pre-patch): > > Og.start # Starts with Og default options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > Og.start({}) # Starts with custom options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > Og.start # Starts with custom options - UNEXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > Instead I believe the startup behavior should be (post-patch): > > Og.start # Starts with Og default options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > Og.start({}) # Starts with custom options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > Og.start # Starts with Og default options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > The way to change default startup behavior would be (post-patch): > > Og.manger_options={}.update({}) > Og.start #starts with custom options - EXPECTED > Og.manager.close_store > Og.manager.unmanage_classes > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/00c10a61/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:42:44 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:42:44 +0300 Subject: [Nitro] TMail in Nitro In-Reply-To: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> References: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> Message-ID: Thanks for this link. I need TMail for correct multipart email parsing. Not to implement some kind of SMTP protocol. net/pop3 (especially with some backported code from 1.9) is sufficient for this. So EM does not really solve our problem in this context. thanks, George. On 9/13/07, Mark Van De Vyver wrote: > > Hi, > > > I planning on including the TMail source files in the Nitro > distribution. I > > need some advanced email handling features that I don't feel like > > implementing from scratch. From what I see there is no gem. > > > > any objections and/or other ideas? > > Not an objection, just an idea..... Event Machine? > http://rubyforge.org/projects/eventmachine > > Email is not my use-case but it seems it may have what you need? > Perhaps more importantly, and if my understanding is correct, it also > offers valuable 'head-room' (I've some ideas but these are half-baked > at the moment)! > It would be great if EM was 'accommodated' in Nitro/Og. There is also > an aim to be Jruby compatible.... > > For those not aware of EM, from a recent post of Francis Cianfrocca : > > At bottom, EM is a high-performance I/O engine, very very stable and > based on years on insights from high-performance network programming. > It also (I will admit) enables programmers to avoid threads, which is > a personal bias of mine. (In my defense, I'll say that this bias is > not a prejudice. I've been writing threaded programs on Windows since > the earliest Win32 betas, 15 years ago, and on Unix since before Posix > threads were a standard.) > > Above the base level, however, the goal is to provide as complete a > set of tools for network programming and distributed computing as > possible, congruent with the "Ruby way." I'll be happy when Ruby > programmers needing to write network-aware software can reach into the > EM toolkit and just pull out what they need. > > A perfect example is the subject of this thread: a complete and > correct implementation of SMTP (both server and client side) that any > Ruby programmer can simply drop in. The SMTP implementation (like the > already-existing HTTP and other implementations) throws off "events" > that your programs can respond to. > > > > -g. > > > > > > -- > > http://www.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/015d608f/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:43:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:43:31 +0300 Subject: [Nitro] TMail in Nitro In-Reply-To: References: <389c43e40709121539v4ffe8d9eu5b6c3b567ae76237@mail.gmail.com> Message-ID: > > If one uses evented_mongrel or swiftiplied_mongrel with Nitro, then > Nitro is running inside an EventMachine event loop, and an other EM > stuff can then be used, as well. > This is one for my todo list! ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/93b98630/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:44:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:44:58 +0300 Subject: [Nitro] TMail in Nitro In-Reply-To: <1189646741.008780.39930@22g2000hsm.googlegroups.com> References: <1189646741.008780.39930@22g2000hsm.googlegroups.com> Message-ID: > > I would contact Minero Aoki and ask him what the status of that > project is. It looks like it hasn't been updated since 2004. You never > know, Minero might suggest an alternative (have you looked for any, > btw?). Or he might be willing to turn it over to you if you want to > revive it. I'd be happy to set it up as a new project in that case. > I think it makes more sense that you setup this as a facets sub-project. This is of more general usability than web applications (== Nitro) Remember, we are trying to get rid of Glue ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/3aedacd9/attachment-0001.html From george.moschovitis at gmail.com Thu Sep 13 03:45:23 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:45:23 +0300 Subject: [Nitro] TMail in Nitro In-Reply-To: <5633336F-B851-4C41-BD12-8930C8326B7A@gmail.com> References: <1189646741.008780.39930@22g2000hsm.googlegroups.com> <5633336F-B851-4C41-BD12-8930C8326B7A@gmail.com> Message-ID: > > There is a gem called mailfactory that is maintained and works > well. > It;s what I'm using in merb without issues. > Thank you, I will check this out! -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/266dee67/attachment.html From george.moschovitis at gmail.com Thu Sep 13 03:48:02 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 10:48:02 +0300 Subject: [Nitro] TMail in Nitro In-Reply-To: References: <1189646741.008780.39930@22g2000hsm.googlegroups.com> <5633336F-B851-4C41-BD12-8930C8326B7A@gmail.com> Message-ID: hmm I mostly need mail parsing. From what I see mailfactory does not support this. -g. On 9/13/07, George Moschovitis wrote: > > There is a gem called mailfactory that is maintained and works > > well. > > It;s what I'm using in merb without issues. > > > > > Thank you, I will check this out! > > -g. > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/a5d5d7f7/attachment.html From mvyver at gmail.com Thu Sep 13 03:56:29 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Thu, 13 Sep 2007 17:56:29 +1000 Subject: [Nitro] OG [PATCH RFC]: Separate Og.start options hash from Og.manager_options In-Reply-To: References: <389c43e40709122243n72b866f7u61ec05551c0f5ab@mail.gmail.com> Message-ID: <389c43e40709130056p21ef5f8etad1215edc3aaa125@mail.gmail.com> Hi On 9/13/07, George Moschovitis wrote: > Seems logical. I am applying the patch. However a better solution is needed > (that will properly handle multiple Og stores at the same time, for db > partitioning/sharding, etc) I agree. My understanding is that each manger looks after only one store, but there are multiple managers that are tracked. I have a solution in mind - that should be backwards compatible, and handle multiple stores, of different types, and possibly stores of one type with multiple adapters. I'm beginning to form the view that the manager's options should be separated from (i.e. not sync'd with) the store's options, and both should at least be attr_readable. Anyone have a case for making them, that is `manger.options` and `store.options`, attr_accessor? > We will get back to this at a later time. OK. But I'm working on an adapter's spec's now, so I'll post anything I come up with while it is fresh in my mind. Cheers Mark > > thank you, > George. > > > On 9/13/07, Mark Van De Vyver wrote: > > > > Hi Devs, > > > > Spec's helped indicate something was wrong but it still took much time > > to work out what - esp given I was working on an adapter spec and this > > is in the og.rb file.... :) > > > > Separate Og start options hash from Og.manager_options - consecutive > > starts no longer pollute Og.manager_options > > > > The attached patch attempts to isolate the options hash that og > > receives on start, and any changes made to it, from the defaults > > stored in Og.manager_options. > > > > Reason, consider the following sequence (pre-patch): > > > > Og.start # Starts with Og default options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > Og.start ({}) # Starts with custom options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > Og.start # Starts with custom options - UNEXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > Instead I believe the startup behavior should be (post-patch): > > > > Og.start # Starts with Og default options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > Og.start({}) # Starts with custom options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > Og.start # Starts with Og default options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > The way to change default startup behavior would be (post-patch): > > > > Og.manger_options={}.update({}) > > Og.start #starts with custom options - EXPECTED > > Og.manager.close_store > > Og.manager.unmanage_classes > > > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org From george.moschovitis at gmail.com Thu Sep 13 04:07:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 11:07:01 +0300 Subject: [Nitro] Two-way cryptographic method Message-ID: Dear devs, a slightly off topic question: can anyone suggest a two-way cryptographics function with a robust ruby implementation? I to do something like this: e = XXX.encrypt("original string", "thekey") b = XXX.decrypt(e, "thekey") # b == "original string" the function may be asymmetric, ie use different encryption/decryption keys. thanks in advance for any suggestions. -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/a08d1afe/attachment.html From transfire at gmail.com Thu Sep 13 07:21:52 2007 From: transfire at gmail.com (Trans) Date: Thu, 13 Sep 2007 11:21:52 -0000 Subject: [Nitro] 0.50 release Message-ID: <1189682512.524954.156010@50g2000hsm.googlegroups.com> George, Where are we at for a 0.50 release? I'm a little worried b/c I suddenly see this flurry of new feature development (a new admin part, tmail, cryptology, etc.), but I thought you were waiting on me for Facets 2.0 to release. I'm just about ready to release, but I fear Nitro is going to get held up by these new features. T. From Reid.Thompson at ateb.com Thu Sep 13 07:26:14 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Thu, 13 Sep 2007 07:26:14 -0400 Subject: [Nitro] Two-way cryptographic method In-Reply-To: References: Message-ID: <1189682774.21800.13.camel@jhereg> On Thu, 2007-09-13 at 11:07 +0300, George Moschovitis wrote: > Dear devs, > > a slightly off topic question: > > can anyone suggest a two-way cryptographics function with a robust > ruby implementation? I to do something like this: > > e = XXX.encrypt("original string", "thekey") > b = XXX.decrypt(e, "thekey") # b == "original string" > you may have already found these... http://crypt.rubyforge.org/index.html http://ezcrypto.rubyforge.org/ Simple examples To encrypt: Generate a key using a password and a salt. Use the keys encrypt method to encrypt a strings worth of data: @key=EzCrypto::Key.with_password "password", "system salt" @encrypted=@key.encrypt "Top secret should not be revealed" To decrypt: Same procedure as encrypt. Generate a key using a password and a salt. Use the keys decrypt method to decrypt a strings worth of data: @key=EzCrypto::Key.with_password "password", "system salt" @key.decrypt @encrypted One liners: These simple examples use one line each: @encrypted=EzCrypto::Key.encrypt_with_password "password", @salt,"Top secret should not be revealed" EzCrypto::Key.decrypt_with_password "password", @salt, at encrypted From george.moschovitis at gmail.com Thu Sep 13 07:27:15 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 14:27:15 +0300 Subject: [Nitro] 0.50 release In-Reply-To: <1189682512.524954.156010@50g2000hsm.googlegroups.com> References: <1189682512.524954.156010@50g2000hsm.googlegroups.com> Message-ID: No, these features are not planned for Nitro 0.50.0, they are form my personal projects. I just have to find some time to: - finish the new form helper that doesn't use the glue builder - get rid of the glue builder - integrate with facets 2.0 beta - test that the nemo/memo code works, if so, the remove glue/cache... - try to remove glue altogehter... - improve the release docs and thats it ;-) -g. On 9/13/07, Trans wrote: > George, > > Where are we at for a 0.50 release? I'm a little worried b/c I > suddenly see this flurry of new feature development (a new admin part, > tmail, cryptology, etc.), but I thought you were waiting on me for > Facets 2.0 to release. I'm just about ready to release, but I fear > Nitro is going to get held up by these new features. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From transfire at gmail.com Thu Sep 13 08:13:53 2007 From: transfire at gmail.com (Trans) Date: Thu, 13 Sep 2007 12:13:53 -0000 Subject: [Nitro] Two-way cryptographic method In-Reply-To: References: Message-ID: <1189685633.012073.61340@g4g2000hsf.googlegroups.com> Maybe we can add two-way features to Facets crypt.rb lib? T. From rmela at rcn.com Thu Sep 13 09:06:20 2007 From: rmela at rcn.com (Robert Mela) Date: Thu, 13 Sep 2007 09:06:20 -0400 Subject: [Nitro] [Fwd: app/elements, app/bin] Message-ID: <46E935CC.8060304@rcn.com> -------------- next part -------------- An embedded message was scrubbed... From: Robert Mela Subject: app/elements, app/bin Date: Thu, 13 Sep 2007 08:55:42 -0400 Size: 1862 Url: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/a1c8b2c4/attachment-0001.eml -------------- next part -------------- A non-text attachment was scrubbed... Name: rmela.vcf Type: text/x-vcard Size: 160 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/a1c8b2c4/attachment-0001.vcf From rmela at rcn.com Thu Sep 13 09:06:51 2007 From: rmela at rcn.com (Robert Mela) Date: Thu, 13 Sep 2007 09:06:51 -0400 Subject: [Nitro] [Fwd: Accessing Element attributes] Message-ID: <46E935EB.2070501@rcn.com> -------------- next part -------------- An embedded message was scrubbed... From: Robert Mela Subject: Accessing Element attributes Date: Thu, 13 Sep 2007 09:04:19 -0400 Size: 1421 Url: http://rubyforge.org/pipermail/nitro-general/attachments/20070913/3ee970f4/attachment.eml -------------- next part -------------- A non-text attachment was scrubbed... Name: rmela.vcf Type: text/x-vcard Size: 160 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/3ee970f4/attachment.vcf From george.moschovitis at gmail.com Thu Sep 13 09:09:03 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 16:09:03 +0300 Subject: [Nitro] Two-way cryptographic method In-Reply-To: <1189685633.012073.61340@g4g2000hsf.googlegroups.com> References: <1189685633.012073.61340@g4g2000hsf.googlegroups.com> Message-ID: that would be a great idea... this is a very useful feature. -g. On 9/13/07, Trans wrote: > Maybe we can add two-way features to Facets crypt.rb lib? > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From rob at robmela.com Thu Sep 13 09:10:05 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 13 Sep 2007 09:10:05 -0400 Subject: [Nitro] Skeleton app/elements dir? Message-ID: <46E936AD.50208@robmela.com> I was impressed by the reusable controls in ASP.Net and I see Nitro Elements as more powerful yet cleaner. I think a real site will have far more elements than app/skin.rb, and the nitro skeleton generator should create an app/elements directory. I'd also like a way to require them at the template level, rather than in app.rb. I suppose I could do it at the controller level, but somehow template seems a more natural place e.g. app/templates/blog/index.htmlx #{require 'app/elements/skin'} or app/templates/blog/photos.htmlx #{require 'app/elements/skin'} #{require 'app/elements/blogelements'} app/templates/wiki/index.htmlx #{require 'app/element/wikicontrols'} -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/aae633f9/attachment.vcf From rob at robmela.com Thu Sep 13 09:11:08 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 13 Sep 2007 09:11:08 -0400 Subject: [Nitro] Raw::Element attribute accessors? Message-ID: <46E936EC.9060707@robmela.com> Saw this in raw/lib/raw/compiler/filter/elements/element.rb # class Box < Raw::Element # def render # %{ #
    # #{content} #
    # } # end Wouldn't it be neater to include an attributes accessor on Element, so that def render %{ *
    *
    } end or better yet...
    -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/cf63e16e/attachment.vcf From george.moschovitis at gmail.com Thu Sep 13 09:26:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 16:26:21 +0300 Subject: [Nitro] [Fwd: Accessing Element attributes] In-Reply-To: <46E935EB.2070501@rcn.com> References: <46E935EB.2070501@rcn.com> Message-ID: Ok, I added the requested helper. It works like this: # # To make the Element render method more elegant, you can use # the attr (or attribute helper). You can replace: # #
    # # with #
    # # or #
    what do you think? regards, George. On 9/13/07, Robert Mela wrote: > > > Saw this in raw/lib/raw/compiler/filter/elements/element.rb > > # class Box < Raw::Element > # def render > # %{ > #
    > # #{content} > #
    > # } > # end > > Wouldn't it be neater to include an attributes accessor on Element, so that > > def render > > %{ > *
    > *
    > } > end > > or better yet... > >
    > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Thu Sep 13 09:36:16 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 16:36:16 +0300 Subject: [Nitro] Nitro/Og spec jump-start In-Reply-To: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> References: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> Message-ID: excuse my ignorance, but.. what is spec_todo.rb ? -g. On 9/12/07, Mark Van De Vyver wrote: > Hi Devs, > Steve Ross has kindly updated his spec_todo script to rspec_todo.rb - > see below. He asks to be informed of any Nitro/Og special cases..... > > Not pure BDDD, but saves a few keys strokes and gives a target to > shoot at (and the only prepare script I'm aware of) > > FYI, 'not yet implemented' specs aren't parsed in the current > test-helper scripts so you'll see red '0 failed' summary. > > Cheers > Mark > > ---------- Forwarded message ---------- > From: s.ross > Date: Sep 13, 2007 4:03 AM > Subject: rspec_todo > To: mvyver at gmail.com > > > I made an svn project (haven't changed my blog post yet), but you can > check this out at: > > http://svn.calicowebdev.com/rspec_todo/trunk > > Note that the name has changed from spec_todo.rb to rspec_todo.rb. I > also incorporated your suggestion to omit the block for the "it". I > will be changing "describe" to recognize controllers, but this won't > help Nitro/Og. If there are any special cases for those, I'd love to > hear about them. > > The code still has the old do/end for the "it" block, but commented > out (I know, sloppy, sloppy). > > If you have other suggestions that might make this tool more useful, > please let me know. > > Thanks for your interest. > > --s > > On Sep 11, 2007, at 11:31 PM, Mark Van De Vyver wrote: > > > Hi Steve, > > On 9/12/07, s.ross wrote: > > > >> The script was created a while ago and rspec has changed a bit. If > >> you find any problem, let me know. > > > > Seems to run 90% OK. > > I pointed at the Postgresql adapter file in the Nitro/Og project: > > - seems to only parse one parameter. > > > > If you do revise, I think for the 'it' to be recognized as - Not Yet > > Implemented - the do/end block is omitted. There is a new pending() > > method that is recognized. > > > > Anyway, looks great and is a fantastic jump start/target to shoot at. > > > > thanks > > Mark > > > > > >> --s > >> > >> On Sep 11, 2007, at 8:58 PM, mvyver at gmail.com wrote: > >> > >>> The following person signed the Calico Web Development contact form: > >>> > >>> Mark Van De Vyver > >>> > >>> The submitted information is: > >>> > >>> name: Mark Van De Vyver > >>> phone: > >>> email: mvyver at gmail.com > >>> site_type: other > >>> timeframe: just kicking tires > >>> > >>> comments: > >>> > >>> Hi, > >>> Thnaks for the interesting blog pages! > >>> I'm writing to request a copy of the spec_todo ruby helper script - > >>> the file link on Steve's "Bootstrapping RSpec Generation" blog page > >>> pointed to a page pointing here... > >>> > >>> Thanks in advance > >>> Regards > >>> Mark > >> > >> > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From transfire at gmail.com Thu Sep 13 12:01:36 2007 From: transfire at gmail.com (Trans) Date: Thu, 13 Sep 2007 16:01:36 -0000 Subject: [Nitro] 0.50 release In-Reply-To: References: <1189682512.524954.156010@50g2000hsm.googlegroups.com> Message-ID: <1189699296.645223.306480@57g2000hsv.googlegroups.com> On Sep 13, 4:27 am, "George Moschovitis" wrote: > No, these features are not planned for Nitro 0.50.0, they are form my > personal projects. I just have to find some time to: > > - finish the new form helper that doesn't use the glue builder > - get rid of the glue builder > - integrate with facets 2.0 beta > - test that the nemo/memo code works, if so, the remove glue/cache... > - try to remove glue altogehter... > - improve the release docs > > and thats it ;-) Hmm... That seems like a lot to me. The builder stuff alone could take a little while. I tried to do it a while back, if you recall, but there were conflicts that I couldn't easily resolve, you were busy with other things, so I had to give up the attempt. The Blow html markup code also needs a little polishing. I still think it would just be better to move whatever is left in Glue to Nitro, Raw or Og, and we can tackle each piece bit by bit over the next couple of releases. The Nemo code is basically identical to what's in Glue now, so there shouldn't be any problems there. I would have had it out by now --it looked like Tom Copeland was just about to grant me access to the nemo rubyforge project, but all of sudden-like, he up and vanished. I haven't heard from him in days. Anyhow, I really need to get Facets 2 out and about, most of my other projects depend on it. So everything is waiting on that. I'm already months behind my original schedule --which was already months behind the original schedule before that ;) T. From george.moschovitis at gmail.com Thu Sep 13 12:51:27 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 19:51:27 +0300 Subject: [Nitro] 0.50 release In-Reply-To: <1189699296.645223.306480@57g2000hsv.googlegroups.com> References: <1189682512.524954.156010@50g2000hsm.googlegroups.com> <1189699296.645223.306480@57g2000hsv.googlegroups.com> Message-ID: > Anyhow, I really need to get Facets 2 out and about, most of my other > projects depend on it. So everything is waiting on that. I'm already > months behind my original schedule --which was already months behind > the original schedule before that ;) Ok, I will try to speed things up! -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From work at ashleymoran.me.uk Thu Sep 13 13:54:17 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Thu, 13 Sep 2007 18:54:17 +0100 Subject: [Nitro] RailsConf Berlin In-Reply-To: References: Message-ID: <1201E23A-7838-4690-AF75-670768DE42C7@ashleymoran.me.uk> On Sep 13, 2007, at 8:13 am, George Moschovitis wrote: > It would be nice to attend, maybe next time :( Maybe you can arrange a NitroConf in Greece for next year :) From rob at robmela.com Thu Sep 13 14:02:35 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 13 Sep 2007 14:02:35 -0400 Subject: [Nitro] [Fwd: Accessing Element attributes] In-Reply-To: References: <46E935EB.2070501@rcn.com> Message-ID: <46E97B3B.506@robmela.com> I like it. This feels like Perl4: #
    This feels like Nitro: #
    George Moschovitis wrote: > Ok, > > I added the requested helper. It works like this: > > # > # To make the Element render method more elegant, you can use > # the attr (or attribute helper). You can replace: > # > #
    > # > # with > #
    > # > # or > > > what do you think? > > regards, > George. > > > On 9/13/07, Robert Mela wrote: > >> Saw this in raw/lib/raw/compiler/filter/elements/element.rb >> >> # class Box < Raw::Element >> # def render >> # %{ >> #
    >> # #{content} >> #
    >> # } >> # end >> >> Wouldn't it be neater to include an attributes accessor on Element, so that >> >> def render >> >> %{ >> *
    >> *
    >> } >> end >> >> or better yet... >> >>
    >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/9bdd3fd3/attachment-0001.vcf From george.moschovitis at gmail.com Thu Sep 13 14:06:39 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 21:06:39 +0300 Subject: [Nitro] [Fwd: Accessing Element attributes] In-Reply-To: <46E97B3B.506@robmela.com> References: <46E935EB.2070501@rcn.com> <46E97B3B.506@robmela.com> Message-ID: > This feels like Nitro: > > #
    thanks :) -g. > > > George Moschovitis wrote: > > Ok, > > > > I added the requested helper. It works like this: > > > > # > > # To make the Element render method more elegant, you can use > > # the attr (or attribute helper). You can replace: > > # > > #
    > > # > > # with > > #
    > > # > > # or > > > > > > what do you think? > > > > regards, > > George. > > > > > > On 9/13/07, Robert Mela wrote: > > > >> Saw this in raw/lib/raw/compiler/filter/elements/element.rb > >> > >> # class Box < Raw::Element > >> # def render > >> # %{ > >> #
    > >> # #{content} > >> #
    > >> # } > >> # end > >> > >> Wouldn't it be neater to include an attributes accessor on Element, so that > >> > >> def render > >> > >> %{ > >> *
    > >> *
    > >> } > >> end > >> > >> or better yet... > >> > >>
    > >> > >> _______________________________________________ > >> 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.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Thu Sep 13 14:07:35 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 13 Sep 2007 21:07:35 +0300 Subject: [Nitro] RailsConf Berlin In-Reply-To: <1201E23A-7838-4690-AF75-670768DE42C7@ashleymoran.me.uk> References: <1201E23A-7838-4690-AF75-670768DE42C7@ashleymoran.me.uk> Message-ID: > Maybe you can arrange a NitroConf in Greece for next year :) This is a nice idea ;-) If we have many interested people we can do it. First, we have a lot of work to bring this project back on track. I am optimistic though ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From aidan at yoyo.org Thu Sep 13 15:20:41 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Thu, 13 Sep 2007 20:20:41 +0100 Subject: [Nitro] The basics Message-ID: Hi all, long time no speak. I'm writing another web app, and given that it's been a while since I last used Nitro I thought I'd take a look and see what was new. There seems to be a lot changed, but unfortunately I can't find any documentation :-) Oxyliquit doesn't have anything in the way of tutorials that is less than a year old. So: is there a tutorial, and if so can someone point me to it? Thanks, Aidan From rob at robmela.com Thu Sep 13 15:41:38 2007 From: rob at robmela.com (Robert Mela) Date: Thu, 13 Sep 2007 15:41:38 -0400 Subject: [Nitro] The basics In-Reply-To: References: Message-ID: <46E99272.3010202@robmela.com> Same situation for me. This time around I made some notes, which I'll be fleshing out further this weekend. http://robmela.com/cheatsheets Aidan Rogers wrote: > Hi all, long time no speak. > > I'm writing another web app, and given that it's been a while since I > last used Nitro I thought I'd take a look and see what was new. > There seems to be a lot changed, but unfortunately I can't find any > documentation :-) > > Oxyliquit doesn't have anything in the way of tutorials that is less > than a year old. So: is there a tutorial, and if so can someone > point me to it? > > Thanks, > > Aidan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070913/f9e71f28/attachment.vcf From mvyver at gmail.com Thu Sep 13 20:03:15 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 10:03:15 +1000 Subject: [Nitro] Nitro/Og spec jump-start In-Reply-To: References: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> Message-ID: <389c43e40709131703u7ac9ac48vbb337ee937dc21b0@mail.gmail.com> It's trivial, saves some keys strokes - I've used it more to give me a target to shoot at (it probably does not provide 100% coverage): /tmp/rspec_todo.rb ./og/lib/og/adapter/oracle/override.rb #------------------------------------------------------------ # File: /og/lib/og/adapter/oracle/override_spec.rb #------------------------------------------------------------ require File.dirname(__FILE__) + '/../spec_helper' describe OCI8::Cursor, "as currently implemented" do it "should do something sensible with blank?." it "should do something sensible with fields." it "should do something sensible with each_row." it "should do something sensible with first_value." end I've exchanged some emails with Steve he may(?) alter the format a little - RSpec now support pending(....) HTH? Mark On 9/13/07, George Moschovitis wrote: > excuse my ignorance, but.. what is spec_todo.rb ? > > -g. > > On 9/12/07, Mark Van De Vyver wrote: > > Hi Devs, > > Steve Ross has kindly updated his spec_todo script to rspec_todo.rb - > > see below. He asks to be informed of any Nitro/Og special cases..... > > > > Not pure BDDD, but saves a few keys strokes and gives a target to > > shoot at (and the only prepare script I'm aware of) > > > > FYI, 'not yet implemented' specs aren't parsed in the current > > test-helper scripts so you'll see red '0 failed' summary. > > > > Cheers > > Mark > > > > ---------- Forwarded message ---------- > > From: s.ross > > Date: Sep 13, 2007 4:03 AM > > Subject: rspec_todo > > To: mvyver at gmail.com > > > > > > I made an svn project (haven't changed my blog post yet), but you can > > check this out at: > > > > http://svn.calicowebdev.com/rspec_todo/trunk > > > > Note that the name has changed from spec_todo.rb to rspec_todo.rb. I > > also incorporated your suggestion to omit the block for the "it". I > > will be changing "describe" to recognize controllers, but this won't > > help Nitro/Og. If there are any special cases for those, I'd love to > > hear about them. > > > > The code still has the old do/end for the "it" block, but commented > > out (I know, sloppy, sloppy). > > > > If you have other suggestions that might make this tool more useful, > > please let me know. > > > > Thanks for your interest. > > > > --s > > > > On Sep 11, 2007, at 11:31 PM, Mark Van De Vyver wrote: > > > > > Hi Steve, > > > On 9/12/07, s.ross wrote: > > > > > >> The script was created a while ago and rspec has changed a bit. If > > >> you find any problem, let me know. > > > > > > Seems to run 90% OK. > > > I pointed at the Postgresql adapter file in the Nitro/Og project: > > > - seems to only parse one parameter. > > > > > > If you do revise, I think for the 'it' to be recognized as - Not Yet > > > Implemented - the do/end block is omitted. There is a new pending() > > > method that is recognized. > > > > > > Anyway, looks great and is a fantastic jump start/target to shoot at. > > > > > > thanks > > > Mark > > > > > > > > >> --s > > >> > > >> On Sep 11, 2007, at 8:58 PM, mvyver at gmail.com wrote: > > >> > > >>> The following person signed the Calico Web Development contact form: > > >>> > > >>> Mark Van De Vyver > > >>> > > >>> The submitted information is: > > >>> > > >>> name: Mark Van De Vyver > > >>> phone: > > >>> email: mvyver at gmail.com > > >>> site_type: other > > >>> timeframe: just kicking tires > > >>> > > >>> comments: > > >>> > > >>> Hi, > > >>> Thnaks for the interesting blog pages! > > >>> I'm writing to request a copy of the spec_todo ruby helper script - > > >>> the file link on Steve's "Bootstrapping RSpec Generation" blog page > > >>> pointed to a page pointing here... > > >>> > > >>> Thanks in advance > > >>> Regards > > >>> Mark > > >> > > >> > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > From mvyver at gmail.com Thu Sep 13 20:16:43 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 10:16:43 +1000 Subject: [Nitro] Nitro/Og spec jump-start In-Reply-To: <389c43e40709131703u7ac9ac48vbb337ee937dc21b0@mail.gmail.com> References: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> <389c43e40709131703u7ac9ac48vbb337ee937dc21b0@mail.gmail.com> Message-ID: <389c43e40709131716ubb97a84v89bc975a8aeaa841@mail.gmail.com> In case anyone is interested..... update from Steve Ross (examples below): Added two mutually exclusive parameters: -m - wrap each spec in a module -u - use block form of "it" Note that if you use either argument alone the spec works fine. If you use them together, it errs out claiming there is no method 'new' in module FileName. Let me know what you think of the tool as is, and if you can shed any light on the problem with using -m and -u together. $ /tmp/rspec_todo.rb -m ./og/lib/og/adapter/oracle/override.rb #------------------------------------------------------------ # File: /og/lib/og/adapter/oracle/override_spec.rb #------------------------------------------------------------ require File.dirname(__FILE__) + '/../spec_helper' module Override describe OCI8::Cursor, "as currently implemented" do it "should do something sensible with blank?." it "should do something sensible with fields." it "should do something sensible with each_row." it "should do something sensible with first_value." end end $ /tmp/rspec_todo.rb -u ./og/lib/og/adapter/oracle/override.rb #------------------------------------------------------------ # File: /og/lib/og/adapter/oracle/override_spec.rb #------------------------------------------------------------ require File.dirname(__FILE__) + '/../spec_helper' describe OCI8::Cursor, "as currently implemented" do it "should do something sensible with blank?." do pending("for some reason") true.should eql(true) end it "should do something sensible with fields." do pending("for some reason") true.should eql(true) end it "should do something sensible with each_row." do pending("for some reason") true.should eql(true) end it "should do something sensible with first_value." do pending("for some reason") true.should eql(true) end end On 9/14/07, Mark Van De Vyver wrote: > It's trivial, saves some keys strokes - I've used it more to give me a > target to shoot at (it probably does not provide 100% coverage): > > /tmp/rspec_todo.rb ./og/lib/og/adapter/oracle/override.rb > #------------------------------------------------------------ > # File: /og/lib/og/adapter/oracle/override_spec.rb > #------------------------------------------------------------ > > require File.dirname(__FILE__) + '/../spec_helper' > > describe OCI8::Cursor, "as currently implemented" do > it "should do something sensible with blank?." > it "should do something sensible with fields." > it "should do something sensible with each_row." > it "should do something sensible with first_value." > end > > I've exchanged some emails with Steve he may(?) alter the format a > little - RSpec now support pending(....) > > HTH? > > Mark > > > On 9/13/07, George Moschovitis wrote: > > excuse my ignorance, but.. what is spec_todo.rb ? > > > > -g. > > > > On 9/12/07, Mark Van De Vyver wrote: > > > Hi Devs, > > > Steve Ross has kindly updated his spec_todo script to rspec_todo.rb - > > > see below. He asks to be informed of any Nitro/Og special cases..... > > > > > > Not pure BDDD, but saves a few keys strokes and gives a target to > > > shoot at (and the only prepare script I'm aware of) > > > > > > FYI, 'not yet implemented' specs aren't parsed in the current > > > test-helper scripts so you'll see red '0 failed' summary. > > > > > > Cheers > > > Mark > > > > > > ---------- Forwarded message ---------- > > > From: s.ross > > > Date: Sep 13, 2007 4:03 AM > > > Subject: rspec_todo > > > To: mvyver at gmail.com > > > > > > > > > I made an svn project (haven't changed my blog post yet), but you can > > > check this out at: > > > > > > http://svn.calicowebdev.com/rspec_todo/trunk > > > > > > Note that the name has changed from spec_todo.rb to rspec_todo.rb. I > > > also incorporated your suggestion to omit the block for the "it". I > > > will be changing "describe" to recognize controllers, but this won't > > > help Nitro/Og. If there are any special cases for those, I'd love to > > > hear about them. > > > > > > The code still has the old do/end for the "it" block, but commented > > > out (I know, sloppy, sloppy). > > > > > > If you have other suggestions that might make this tool more useful, > > > please let me know. > > > > > > Thanks for your interest. > > > > > > --s > > > > > > On Sep 11, 2007, at 11:31 PM, Mark Van De Vyver wrote: > > > > > > > Hi Steve, > > > > On 9/12/07, s.ross wrote: > > > > > > > >> The script was created a while ago and rspec has changed a bit. If > > > >> you find any problem, let me know. > > > > > > > > Seems to run 90% OK. > > > > I pointed at the Postgresql adapter file in the Nitro/Og project: > > > > - seems to only parse one parameter. > > > > > > > > If you do revise, I think for the 'it' to be recognized as - Not Yet > > > > Implemented - the do/end block is omitted. There is a new pending() > > > > method that is recognized. > > > > > > > > Anyway, looks great and is a fantastic jump start/target to shoot at. > > > > > > > > thanks > > > > Mark > > > > > > > > > > > >> --s > > > >> > > > >> On Sep 11, 2007, at 8:58 PM, mvyver at gmail.com wrote: > > > >> > > > >>> The following person signed the Calico Web Development contact form: > > > >>> > > > >>> Mark Van De Vyver > > > >>> > > > >>> The submitted information is: > > > >>> > > > >>> name: Mark Van De Vyver > > > >>> phone: > > > >>> email: mvyver at gmail.com > > > >>> site_type: other > > > >>> timeframe: just kicking tires > > > >>> > > > >>> comments: > > > >>> > > > >>> Hi, > > > >>> Thnaks for the interesting blog pages! > > > >>> I'm writing to request a copy of the spec_todo ruby helper script - > > > >>> the file link on Steve's "Bootstrapping RSpec Generation" blog page > > > >>> pointed to a page pointing here... > > > >>> > > > >>> Thanks in advance > > > >>> Regards > > > >>> Mark > > > >> > > > >> > > > _______________________________________________ > > > Nitro-general mailing list > > > Nitro-general at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > -- > > http://www.me.gr > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > > From work at ashleymoran.me.uk Thu Sep 13 21:58:47 2007 From: work at ashleymoran.me.uk (Ashley Moran) Date: Fri, 14 Sep 2007 02:58:47 +0100 Subject: [Nitro] RailsConf Berlin In-Reply-To: References: <1201E23A-7838-4690-AF75-670768DE42C7@ashleymoran.me.uk> Message-ID: <9FFD58B9-2F7A-4484-9BA9-2201CBFBAA5D@ashleymoran.me.uk> On Sep 13, 2007, at 7:07 pm, George Moschovitis wrote: > This is a nice idea ;-) If we have many interested people we can do > it. First, we have a lot of work to bring this project back on track. > I am optimistic though ;-) What do you mean by back on track? What sort of stuff has gone off the rails (sorry! lol)? I'm really excited about using Nitro. I'm hoping it can be Rails without all the ugly bits. My two jQuery books are here, so when I get back from RailsConf I will start learning that (looks easy, though). And then I MUST learn how Og database changes work. But hopefully next month I will get to building something serious. Ashley From transfire at gmail.com Thu Sep 13 23:07:09 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 03:07:09 -0000 Subject: [Nitro] Rubyscript2exe Message-ID: <1189739229.405901.117220@o80g2000hse.googlegroups.com> Has anyone used Rubyscript2exe on a Nitro app? Thanks, T. From mvyver at gmail.com Fri Sep 14 00:08:41 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 14:08:41 +1000 Subject: [Nitro] Nitro/Og headsup: RSpec's Story Runner Message-ID: <389c43e40709132108t79e3f115rbc0d3896d8a9fcba@mail.gmail.com> Hi Devs, This probably is old news to some/most/all(?), but thought I'd post anyway. If you're delving into RSpec, you might be interested in looking into RSpec's Story Runner. Some info: - recent posts on mail list - http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner - http://dannorth.net/whats-in-a-story HTH mv From mvyver at gmail.com Fri Sep 14 01:20:13 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 15:20:13 +1000 Subject: [Nitro] Nitro/Og default option handling behavior Message-ID: <389c43e40709132220p6358d802i133c51a70f41abe0@mail.gmail.com> Hi devs, Sorry to post yet another options related question, again this relates to specifying Og behavior.... If there is one, what is the standard Nitro/Og default behavior where a option hash is passed to a method that has defaults specified? a) any custom option negates all the defaults b) custom options update/extend the defaults c) both a) and b) Pseudo example illustrating the different effects: I'd expect this would fail under a) but pass under b) Og.manger_options = {} man=[] ['bd1'..'dbN'].each do |dbname| man< dbname}) end For what it is worth I'd be in favor of b) mv From george.moschovitis at gmail.com Fri Sep 14 02:00:31 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 09:00:31 +0300 Subject: [Nitro] RailsConf Berlin In-Reply-To: <9FFD58B9-2F7A-4484-9BA9-2201CBFBAA5D@ashleymoran.me.uk> References: <1201E23A-7838-4690-AF75-670768DE42C7@ashleymoran.me.uk> <9FFD58B9-2F7A-4484-9BA9-2201CBFBAA5D@ashleymoran.me.uk> Message-ID: > What do you mean by back on track? What sort of stuff has gone off > the rails (sorry! lol)? After I went off for the Army, and then while I was preparing to get married, things slowed down a bit... But after the 0.50 is out of the door, things will speed up again. -g. > > I'm really excited about using Nitro. I'm hoping it can be Rails > without all the ugly bits. My two jQuery books are here, so when I > get back from RailsConf I will start learning that (looks easy, > though). And then I MUST learn how Og database changes work. But > hopefully next month I will get to building something serious. > > Ashley > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From mvyver at gmail.com Fri Sep 14 02:37:49 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 16:37:49 +1000 Subject: [Nitro] Nitro/Og spec jump-start In-Reply-To: <389c43e40709131716ubb97a84v89bc975a8aeaa841@mail.gmail.com> References: <389c43e40709121350y66ffa31dt76a90ffcd1f76f1d@mail.gmail.com> <389c43e40709131703u7ac9ac48vbb337ee937dc21b0@mail.gmail.com> <389c43e40709131716ubb97a84v89bc975a8aeaa841@mail.gmail.com> Message-ID: <389c43e40709132337w66664430o194b7c1294192f00@mail.gmail.com> On 9/14/07, Mark Van De Vyver wrote: > In case anyone is interested..... update from Steve Ross (examples below): > > Added two mutually exclusive parameters: > > -m - wrap each spec in a module > -u - use block form of "it" This has just been fixed... these options can be used together: rspec_todo.rb -u -m your_source_file.rb >>spec_target.rb HTH Mark > Note that if you use either argument alone the spec works fine. If > you use them together, it errs out claiming there is no method 'new' > in module FileName. Let me know what you think of the tool as is, and > if you can shed any light on the problem with using -m and -u together. > > > $ /tmp/rspec_todo.rb -m ./og/lib/og/adapter/oracle/override.rb > #------------------------------------------------------------ > # File: /og/lib/og/adapter/oracle/override_spec.rb > #------------------------------------------------------------ > > require File.dirname(__FILE__) + '/../spec_helper' > > module Override > describe OCI8::Cursor, "as currently implemented" do > it "should do something sensible with blank?." > it "should do something sensible with fields." > it "should do something sensible with each_row." > it "should do something sensible with first_value." > end > > end > > > $ /tmp/rspec_todo.rb -u ./og/lib/og/adapter/oracle/override.rb > #------------------------------------------------------------ > # File: /og/lib/og/adapter/oracle/override_spec.rb > #------------------------------------------------------------ > > require File.dirname(__FILE__) + '/../spec_helper' > > describe OCI8::Cursor, "as currently implemented" do > it "should do something sensible with blank?." do > pending("for some reason") > true.should eql(true) > end > it "should do something sensible with fields." do > pending("for some reason") > true.should eql(true) > end > it "should do something sensible with each_row." do > pending("for some reason") > true.should eql(true) > end > it "should do something sensible with first_value." do > pending("for some reason") > true.should eql(true) > end > end > > > On 9/14/07, Mark Van De Vyver wrote: > > It's trivial, saves some keys strokes - I've used it more to give me a > > target to shoot at (it probably does not provide 100% coverage): > > > > /tmp/rspec_todo.rb ./og/lib/og/adapter/oracle/override.rb > > #------------------------------------------------------------ > > # File: /og/lib/og/adapter/oracle/override_spec.rb > > #------------------------------------------------------------ > > > > require File.dirname(__FILE__) + '/../spec_helper' > > > > describe OCI8::Cursor, "as currently implemented" do > > it "should do something sensible with blank?." > > it "should do something sensible with fields." > > it "should do something sensible with each_row." > > it "should do something sensible with first_value." > > end > > > > I've exchanged some emails with Steve he may(?) alter the format a > > little - RSpec now support pending(....) > > > > HTH? > > > > Mark > > > > > > On 9/13/07, George Moschovitis wrote: > > > excuse my ignorance, but.. what is spec_todo.rb ? > > > > > > -g. > > > > > > On 9/12/07, Mark Van De Vyver wrote: > > > > Hi Devs, > > > > Steve Ross has kindly updated his spec_todo script to rspec_todo.rb - > > > > see below. He asks to be informed of any Nitro/Og special cases..... > > > > > > > > Not pure BDDD, but saves a few keys strokes and gives a target to > > > > shoot at (and the only prepare script I'm aware of) > > > > > > > > FYI, 'not yet implemented' specs aren't parsed in the current > > > > test-helper scripts so you'll see red '0 failed' summary. > > > > > > > > Cheers > > > > Mark > > > > > > > > ---------- Forwarded message ---------- > > > > From: s.ross > > > > Date: Sep 13, 2007 4:03 AM > > > > Subject: rspec_todo > > > > To: mvyver at gmail.com > > > > > > > > > > > > I made an svn project (haven't changed my blog post yet), but you can > > > > check this out at: > > > > > > > > http://svn.calicowebdev.com/rspec_todo/trunk > > > > > > > > Note that the name has changed from spec_todo.rb to rspec_todo.rb. I > > > > also incorporated your suggestion to omit the block for the "it". I > > > > will be changing "describe" to recognize controllers, but this won't > > > > help Nitro/Og. If there are any special cases for those, I'd love to > > > > hear about them. > > > > > > > > The code still has the old do/end for the "it" block, but commented > > > > out (I know, sloppy, sloppy). > > > > > > > > If you have other suggestions that might make this tool more useful, > > > > please let me know. > > > > > > > > Thanks for your interest. > > > > > > > > --s > > > > > > > > On Sep 11, 2007, at 11:31 PM, Mark Van De Vyver wrote: > > > > > > > > > Hi Steve, > > > > > On 9/12/07, s.ross wrote: > > > > > > > > > >> The script was created a while ago and rspec has changed a bit. If > > > > >> you find any problem, let me know. > > > > > > > > > > Seems to run 90% OK. > > > > > I pointed at the Postgresql adapter file in the Nitro/Og project: > > > > > - seems to only parse one parameter. > > > > > > > > > > If you do revise, I think for the 'it' to be recognized as - Not Yet > > > > > Implemented - the do/end block is omitted. There is a new pending() > > > > > method that is recognized. > > > > > > > > > > Anyway, looks great and is a fantastic jump start/target to shoot at. > > > > > > > > > > thanks > > > > > Mark > > > > > > > > > > > > > > >> --s > > > > >> > > > > >> On Sep 11, 2007, at 8:58 PM, mvyver at gmail.com wrote: > > > > >> > > > > >>> The following person signed the Calico Web Development contact form: > > > > >>> > > > > >>> Mark Van De Vyver > > > > >>> > > > > >>> The submitted information is: > > > > >>> > > > > >>> name: Mark Van De Vyver > > > > >>> phone: > > > > >>> email: mvyver at gmail.com > > > > >>> site_type: other > > > > >>> timeframe: just kicking tires > > > > >>> > > > > >>> comments: > > > > >>> > > > > >>> Hi, > > > > >>> Thnaks for the interesting blog pages! > > > > >>> I'm writing to request a copy of the spec_todo ruby helper script - > > > > >>> the file link on Steve's "Bootstrapping RSpec Generation" blog page > > > > >>> pointed to a page pointing here... > > > > >>> > > > > >>> Thanks in advance > > > > >>> Regards > > > > >>> Mark > > > > >> > > > > >> > > > > _______________________________________________ > > > > Nitro-general mailing list > > > > Nitro-general at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > > > > > > -- > > > http://www.me.gr > > > http://phidz.com > > > http://blog.gmosx.com > > > http://cull.gr > > > http://www.joy.gr > > > http://nitroproject.org > > > > > > From george.moschovitis at gmail.com Fri Sep 14 03:14:24 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 10:14:24 +0300 Subject: [Nitro] Nitro/Og headsup: RSpec's Story Runner In-Reply-To: <389c43e40709132108t79e3f115rbc0d3896d8a9fcba@mail.gmail.com> References: <389c43e40709132108t79e3f115rbc0d3896d8a9fcba@mail.gmail.com> Message-ID: looks very interesting, something to read over the w/e. -g. On 9/14/07, Mark Van De Vyver wrote: > Hi Devs, > This probably is old news to some/most/all(?), but thought I'd post anyway. > > If you're delving into RSpec, you might be interested in looking into > RSpec's Story Runner. > > Some info: > - recent posts on mail list > - http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner > - http://dannorth.net/whats-in-a-story > > HTH > mv > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Fri Sep 14 03:18:15 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 10:18:15 +0300 Subject: [Nitro] The basics In-Reply-To: References: Message-ID: Arne, is working on a tutorial, be patient... -g. On 9/13/07, Aidan Rogers wrote: > Hi all, long time no speak. > > I'm writing another web app, and given that it's been a while since I > last used Nitro I thought I'd take a look and see what was new. > There seems to be a lot changed, but unfortunately I can't find any > documentation :-) > > Oxyliquit doesn't have anything in the way of tutorials that is less > than a year old. So: is there a tutorial, and if so can someone > point me to it? > > Thanks, > > Aidan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Fri Sep 14 03:18:57 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 10:18:57 +0300 Subject: [Nitro] Nemo svn repo Message-ID: Tom, where can I find the current nemo source code? thanks, -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Fri Sep 14 03:25:03 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 10:25:03 +0300 Subject: [Nitro] Facets 2.0 Message-ID: Tom, I cannot understand the directory structure in the repo version of facets... I would expect something like: lib/facets/... instead I see: lib/fore/facets/... (!!!!) lib/more/facets/... Am I missing something? -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From transfire at gmail.com Fri Sep 14 06:07:31 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 10:07:31 -0000 Subject: [Nitro] Nemo svn repo In-Reply-To: References: Message-ID: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> On Sep 14, 12:18 am, "George Moschovitis" wrote: > Tom, > > where can I find the current nemo source code? Well, I just got word from Tom Copeland last night. He's not going to let me take over the Nemo rubyforge project after all. Kind of irks me, and really gets me thinking about how Ruby is painting itself into a sort of corner. Think about this. RubyGems is now Ruby's official package system. Rubyforge is the official gem repository b/c RubyGems defaults to it as it's remote location. So unless one has a Rubyforge project, and more precisely, gem packages for download in that Rubyforge project, one's project might as well not even exist. So Rubyforge alone is responsible for what is and is not extant in the Ruby world. And yet they take no responsibility for keeping the repository clean and up to date; and they have no policy for dead projects. Case in point: nemo. If you go to the site: http://rubyforge.org/projects/nemo/, one can see clearly the project is dead. Kevin Howe put a big fat ***DEFUNCT*** in the project description. And Kevin Howe himself is no longer anywhere to be found --his email address is defunct; and I even put an APB out for him on ruby-talk, twice, to no avail. The project itself is a plugin for Wee, so I even made arrangements with Michael Neumann of Wee to host the old nemo.gem as wee-nemo.gem, so it wouldn't be totally lost. Hek, I figured, it might even revitalize the project. But apparently even that wasn't good enough. A case of sour grapes? Sure, a little. But it would be different if Kevin's nemo was a current and active project. It clearly is not, and so it just doesn't seem right that I can't name this project nemo b/c of it. T. From transfire at gmail.com Fri Sep 14 06:15:58 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 10:15:58 -0000 Subject: [Nitro] Facets 2.0 In-Reply-To: References: Message-ID: <1189764958.117077.325800@d55g2000hsg.googlegroups.com> On Sep 14, 12:25 am, "George Moschovitis" wrote: > Tom, > > I cannot understand the directory structure in the repo version of facets... > > I would expect something like: > > lib/facets/... > > instead I see: > > lib/fore/facets/... (!!!!) > lib/more/facets/... > > Am I missing something? Tricky is the ruby master ;) I will likely rename these dirs to be more descriptive, but it doesn't matter what they are called b/c to use them, they need to be added to the $LOAD_PATH. So add lib/fore, lib/core and lib/more (in that order) to $: and then _everything_ becomes available via: require 'facets/...' The RubyGems install does that automatically. Ah, I was going to say you can do manual site_ruby install via task/ install (a special installer just for Facets) but now that I think about it, that depends on Ratch which depends on Facets 2 --that's a problem I'll need to fix. Hold on, I'll post a beta gem to the website, and you can use that. T. From transfire at gmail.com Fri Sep 14 06:22:42 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 10:22:42 -0000 Subject: [Nitro] Nemo svn repo In-Reply-To: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> Message-ID: <1189765362.456373.282500@g4g2000hsf.googlegroups.com> On Sep 14, 3:07 am, Trans wrote: > > A case of sour grapes? Sure, a little. But it would be different if > Kevin's nemo was a current and active project. It clearly is not, and > so it just doesn't seem right that I can't name this project nemo b/c > of it. And I had an octopus for a mascot and everything :( T. From aidan at yoyo.org Fri Sep 14 06:28:14 2007 From: aidan at yoyo.org (Aidan Rogers) Date: Fri, 14 Sep 2007 11:28:14 +0100 Subject: [Nitro] Nemo svn repo In-Reply-To: <1189765362.456373.282500@g4g2000hsf.googlegroups.com> References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> <1189765362.456373.282500@g4g2000hsf.googlegroups.com> Message-ID: The octopus character from Finding Nemo was called 'Pearl' - somewhat ironic name for a Ruby project :-) Aidan On Sep 14, 2007, at 11:22 AM, Trans wrote: > > > On Sep 14, 3:07 am, Trans wrote: >> >> A case of sour grapes? Sure, a little. But it would be different if >> Kevin's nemo was a current and active project. It clearly is not, and >> so it just doesn't seem right that I can't name this project nemo b/c >> of it. > > And I had an octopus for a mascot and everything :( > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Fri Sep 14 07:05:07 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 14:05:07 +0300 Subject: [Nitro] Facets 2.0 In-Reply-To: <1189764958.117077.325800@d55g2000hsg.googlegroups.com> References: <1189764958.117077.325800@d55g2000hsg.googlegroups.com> Message-ID: Ok thanks for the info! -g. On 9/14/07, Trans wrote: > > > On Sep 14, 12:25 am, "George Moschovitis" > wrote: > > Tom, > > > > I cannot understand the directory structure in the repo version of facets... > > > > I would expect something like: > > > > lib/facets/... > > > > instead I see: > > > > lib/fore/facets/... (!!!!) > > lib/more/facets/... > > > > Am I missing something? > > Tricky is the ruby master ;) > > I will likely rename these dirs to be more descriptive, but it doesn't > matter what they are called b/c to use them, they need to be added to > the $LOAD_PATH. So add lib/fore, lib/core and lib/more (in that order) > to $: and then _everything_ becomes available via: > > require 'facets/...' > > The RubyGems install does that automatically. > > Ah, I was going to say you can do manual site_ruby install via task/ > install (a special installer just for Facets) but now that I think > about it, that depends on Ratch which depends on Facets 2 --that's a > problem I'll need to fix. > > Hold on, I'll post a beta gem to the website, and you can use that. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From george.moschovitis at gmail.com Fri Sep 14 07:07:20 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 14:07:20 +0300 Subject: [Nitro] Nemo svn repo In-Reply-To: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> Message-ID: Perhaps, more people from the nitro and facets mailing lists should email Tom. What is the email? -g. On 9/14/07, Trans wrote: > > > On Sep 14, 12:18 am, "George Moschovitis" > wrote: > > Tom, > > > > where can I find the current nemo source code? > > Well, I just got word from Tom Copeland last night. He's not going to > let me take over the Nemo rubyforge project after all. Kind of irks > me, and really gets me thinking about how Ruby is painting itself into > a sort of corner. Think about this. RubyGems is now Ruby's official > package system. Rubyforge is the official gem repository b/c RubyGems > defaults to it as it's remote location. So unless one has a Rubyforge > project, and more precisely, gem packages for download in that > Rubyforge project, one's project might as well not even exist. So > Rubyforge alone is responsible for what is and is not extant in the > Ruby world. > > And yet they take no responsibility for keeping the repository clean > and up to date; and they have no policy for dead projects. Case in > point: nemo. If you go to the site: http://rubyforge.org/projects/nemo/, > one can see clearly the project is dead. Kevin Howe put a big fat > ***DEFUNCT*** in the project description. And Kevin Howe himself is no > longer anywhere to be found --his email address is defunct; and I even > put an APB out for him on ruby-talk, twice, to no avail. The project > itself is a plugin for Wee, so I even made arrangements with Michael > Neumann of Wee to host the old nemo.gem as wee-nemo.gem, so it > wouldn't be totally lost. Hek, I figured, it might even revitalize the > project. But apparently even that wasn't good enough. > > A case of sour grapes? Sure, a little. But it would be different if > Kevin's nemo was a current and active project. It clearly is not, and > so it just doesn't seem right that I can't name this project nemo b/c > of it. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From transfire at gmail.com Fri Sep 14 07:24:39 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 11:24:39 -0000 Subject: [Nitro] Facets 2.0 In-Reply-To: References: <1189764958.117077.325800@d55g2000hsg.googlegroups.com> Message-ID: <1189769079.385570.107390@k79g2000hse.googlegroups.com> On Sep 14, 4:05 am, "George Moschovitis" wrote: > Ok thanks for the info! No problem. Here you go: $ wget http://facets.rubyforge.org/pkg/facets-2.0.0.gem $ gem install facets-2.0.0.gem Let me know how that works for you. T. From transfire at gmail.com Fri Sep 14 07:49:21 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 11:49:21 -0000 Subject: [Nitro] Nemo svn repo In-Reply-To: References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> Message-ID: <1189770561.356157.125280@w3g2000hsg.googlegroups.com> On Sep 14, 4:07 am, "George Moschovitis" wrote: > Perhaps, more people from the nitro and facets mailing lists should > email Tom. What is the email? See: http://rubyforge.org/users/tom/ But under the other circumstance I think it's probably time just to let it go and pick a different name, so we can get on with it. There's no guarantee that Tom will change his mind. And the release of this project has already been delayed too long as it is. So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a bit generic). Any other ideas for short, concise name for a persistent memory system? Preferably one that goes along with an octopus ;) T. From transfire at gmail.com Fri Sep 14 08:04:30 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 12:04:30 -0000 Subject: [Nitro] Nemo svn repo In-Reply-To: References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> <1189765362.456373.282500@g4g2000hsf.googlegroups.com> Message-ID: <1189771470.892268.279320@k79g2000hse.googlegroups.com> On Sep 14, 3:28 am, Aidan Rogers wrote: > The octopus character from Finding Nemo was called 'Pearl' - somewhat > ironic name for a Ruby project :-) LOL :) T. From mvyver at gmail.com Fri Sep 14 08:16:48 2007 From: mvyver at gmail.com (Mark Van De Vyver) Date: Fri, 14 Sep 2007 22:16:48 +1000 Subject: [Nitro] Nemo svn repo In-Reply-To: <1189770561.356157.125280@w3g2000hsg.googlegroups.com> References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> <1189770561.356157.125280@w3g2000hsg.googlegroups.com> Message-ID: <389c43e40709140516s4c96ef3bx1518c9ef7b55a1f6@mail.gmail.com> Maybe too close to nemo... and then there is the octopus to take care of ;-) mneme (or the phonetic nee-mee) >From Dictionary.com: noun 1. Psychology. the retentive basis or basic principle in a mind or organism accounting for memory. 2. (initial capital letter) Classical Mythology. the Muse of memory, one of the original three Muses. On 9/14/07, Trans wrote: > > > On Sep 14, 4:07 am, "George Moschovitis" > wrote: > > Perhaps, more people from the nitro and facets mailing lists should > > email Tom. What is the email? > > See: http://rubyforge.org/users/tom/ > > But under the other circumstance I think it's probably time just to > let it go and pick a different name, so we can get on with it. There's > no guarantee that Tom will change his mind. And the release of this > project has already been delayed too long as it is. > > So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a > bit generic). Any other ideas for short, concise name for a persistent > memory system? Preferably one that goes along with an octopus ;) > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > From george.moschovitis at gmail.com Fri Sep 14 08:28:25 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 15:28:25 +0300 Subject: [Nitro] Nemo svn repo In-Reply-To: <1189770561.356157.125280@w3g2000hsg.googlegroups.com> References: <1189764451.176938.245490@r29g2000hsg.googlegroups.com> <1189770561.356157.125280@w3g2000hsg.googlegroups.com> Message-ID: > So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a memo is fine with me! go grab it ;-) -g. -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From prpht9 at gmail.com Fri Sep 14 11:01:25 2007 From: prpht9 at gmail.com (chris) Date: Fri, 14 Sep 2007 11:01:25 -0400 Subject: [Nitro] Keeping Documentation and Tutorials up-to-date Message-ID: Hi all, A methodology recommendation has been rolling around in my head for a few days now and I'd like to bring it up here on the mailing list. So, I'll get started with a little background and a question. I was reading a post earlier today called "The basics" and want to ask the question "Where are the new tutorials going to be published?". This seemed like an innocent enough question until i realized, your probably going to put it on OxyLiquit . I'm not going to knock putting them there, it's actually one of the top locations new users are going to look for that information. The problem I see is the same thing that happened to the other 4 tutorials. They went out of date almost as quickly as they were posted. I would like to make a recommendation to the Nitro/Og (raw, etc, etc.) team. How about rolling a basic tutorial into the RDocs. IMHO the situation your team is running into is a knowledge transfer gap between the creators and the intermediate to expert users of Nitro, not the newbies who barely know where to start. Rake's RDoc index pageis a good example of what I think Nitro's should look like. It gives all the information a newbie needs to get their feet wet and attempt to get to an intermediate level of understanding. What the expert users needs is good reference material that explains the inner workings of how the components work with each other and small examples of how someone can utilize them. eg: Rake::RDocTaskand Rake::GemPackageTask These examples do not need to be easily understood by a novice. However, they do need to effectively communicate a technical concept to a competent ruby developer without having to delve too deeply into the code to accomplish something. I'm not saying they won't run into exceptions trying to get it working, but they should know what is possible with the class or module. note: I used rake just because it's something I picked up fairly quickly due to the rdocs. The advantage of taking this approach to documenting your projects is you create a basis for the expert users to write the tutorials. They could write them on their blogs, (good for your google ranking), on Fora or on OxyLiquit. I'm basically saying, you should not be writing full blown tutorials, but moving smaller examples of how to perform actions into your RDocs. This has key advantages... 1 - When a developer makes a change to the code they can make the example adjustments without having to open another editor. eg: Or even better, without having to open a web browser, login to a wiki ( whatever ) and then make changes. Way too many steps. Developers are lazy, I mean efficient. (tongue in cheek) 2 - The examples for a particular version of each project are in revision control with the code they reference. eg: someone can download x.x lower version of the project and have the correct examples for that version 3 - The published RDocs can be available through your website and through ri without you having to publish yet another piece of documentation. eg: rake deploy is all it takes (if you use newgem, not sure if you do) 4 - Patches from your userbase don't have to be just code, they can be updates to your tutorials as well. eg: In fact if I were in your shoes, the first page of the RDocs would reference a page on how to submit updates to the examples as a patch. As a final note, I would like to say the HelloWorld example from the repository for nitro-0.50 is a perfect starting point to put in the RDocs. Then you could work the Blog example in for each of the components you want to communicate howto ___. I'm all done ranting. Criticism always welcome, Chris Scheper ---------------------------------------------------------------------------- "If you project isn't using rspec and rbehave. it should ..." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070914/c93bf5df/attachment-0001.html From prpht9 at gmail.com Fri Sep 14 11:04:02 2007 From: prpht9 at gmail.com (chris) Date: Fri, 14 Sep 2007 11:04:02 -0400 Subject: [Nitro] Keeping Documentation and Tutorials up-to-date In-Reply-To: References: Message-ID: Ok, I just looked at Robert Mela's cheatsheets. Those are perfect for going into the RDocs. Chris On 9/14/07, chris wrote: > > Hi all, > > A methodology recommendation has been rolling around in my head for a > few days now and I'd like to bring it up here on the mailing list. So, I'll > get started with a little background and a question. > > I was reading a post earlier today called "The basics" and want to ask > the question "Where are the new tutorials going to be published?". > > This seemed like an innocent enough question until i realized, your > probably going to put it on OxyLiquit . I'm not going > to knock putting them there, it's actually one of the top locations new > users are going to look for that information. The problem I see is the same > thing that happened to the other 4 tutorials. > > They went out of date almost as quickly as they were posted. > > I would like to make a recommendation to the Nitro/Og (raw, etc, etc.) > team. How about rolling a basic tutorial into the RDocs. IMHO the > situation your team is running into is a knowledge transfer gap between the > creators and the intermediate to expert users of Nitro, not the newbies who > barely know where to start. Rake's RDoc index pageis a good example of what I think Nitro's should look like. It gives all > the information a newbie needs to get their feet wet and attempt to get to > an intermediate level of understanding. > > What the expert users needs is good reference material that explains the > inner workings of how the components work with each other and small examples > of how someone can utilize them. eg: Rake::RDocTaskand > Rake::GemPackageTask > These examples do not need to be easily understood by a novice. However, > they do need to effectively communicate a technical concept to a competent > ruby developer without having to delve too deeply into the code to > accomplish something. I'm not saying they won't run into exceptions trying > to get it working, but they should know what is possible with the class or > module. > > note: I used rake just because it's something I picked up fairly quickly > due to the rdocs. > > The advantage of taking this approach to documenting your projects is > you create a basis for the expert users to write the tutorials. They could > write them on their blogs, (good for your google ranking), on Fora or on > OxyLiquit. I'm basically saying, you should not be writing full blown > tutorials, but moving smaller examples of how to perform actions into your > RDocs. This has key advantages... > > 1 - When a developer makes a change to the code they can make the example > adjustments without having to open another editor. > eg: Or even better, without having to open a web browser, login to a > wiki ( whatever ) and then make changes. Way too many steps. Developers > are lazy, I mean efficient. (tongue in cheek) > 2 - The examples for a particular version of each project are in revision > control with the code they reference. > eg: someone can download x.x lower version of the project and have the > correct examples for that version > 3 - The published RDocs can be available through your website and through > ri without you having to publish yet another piece of documentation. > eg: rake deploy is all it takes (if you use newgem, not sure if you do) > 4 - Patches from your userbase don't have to be just code, they can be > updates to your tutorials as well. > eg: In fact if I were in your shoes, the first page of the RDocs would > reference a page on how to submit updates to the examples as a patch. > > As a final note, I would like to say the HelloWorld example from the > repository for nitro-0.50 is a perfect starting point to put in the > RDocs. Then you could work the Blog example in for each of the components > you want to communicate howto ___. I'm all done ranting. > > Criticism always welcome, > > Chris Scheper > > > ---------------------------------------------------------------------------- > "If you project isn't using rspec and > rbehave . it should > ..." > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070914/ea301c7e/attachment.html From george.moschovitis at gmail.com Fri Sep 14 11:14:22 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 14 Sep 2007 18:14:22 +0300 Subject: [Nitro] Facets 2.0 In-Reply-To: <1189769079.385570.107390@k79g2000hse.googlegroups.com> References: <1189764958.117077.325800@d55g2000hsg.googlegroups.com> <1189769079.385570.107390@k79g2000hse.googlegroups.com> Message-ID: Ok, will test them and get back to you! thanks, -g. On 9/14/07, Trans wrote: > > > On Sep 14, 4:05 am, "George Moschovitis" > wrote: > > Ok thanks for the info! > > No problem. Here you go: > > $ wget http://facets.rubyforge.org/pkg/facets-2.0.0.gem > $ gem install facets-2.0.0.gem > > Let me know how that works for you. > > T. > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From rob at robmela.com Fri Sep 14 12:10:14 2007 From: rob at robmela.com (Robert Mela) Date: Fri, 14 Sep 2007 12:10:14 -0400 Subject: [Nitro] Nitro Presentation? In-Reply-To: References: Message-ID: <46EAB266.4010006@robmela.com> Thanks. These are my notes to me, formatted for other "mes". I'll be adding Og examples this weekend. That may be as far as I get before life takes me away from Nitro again :( Lift and copy at will... thanks for the thanks. Hopefully Arne will have a book together soon :) chris wrote: > Ok, > > I just looked at Robert Mela's cheatsheets > . Those are perfect for going into > the RDocs. > > Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070914/3b793a64/attachment.vcf From transfire at gmail.com Fri Sep 14 16:26:34 2007 From: transfire at gmail.com (Trans) Date: Fri, 14 Sep 2007 20:26:34 -0000 Subject: [Nitro] Keeping Documentation and Tutorials up-to-date In-Reply-To: References: Message-ID: <1189801594.894732.275060@57g2000hsv.googlegroups.com> Speaking of RDocs. I find the current set (for 0.42) a bit overwhelming. It would be nice if the 0.50 rdocs were broken out into parts, one each for Og, Raw and Nitro. T. From arne at arnebrasseur.net Sat Sep 15 10:06:48 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 15 Sep 2007 22:06:48 +0800 Subject: [Nitro] render :index broken In-Reply-To: <46E50039.3000005@arnebrasseur.net> References: <46E50039.3000005@arnebrasseur.net> Message-ID: <46EBE6F8.6000206@arnebrasseur.net> Patch included. This solves redirecting to the index method of the root controller. (ab) Arne Brasseur schreef: > When doing "render :index " in a controller action, the following gives > me an error: > > #dispatcher.rb line 142 > > def dispatch(uri, method = :get) > # Extract the query string. > > path, query = uri.split("?", 2) # <------- uri == "" then > path == query == nil > > path ||= "" # <------ This solves the problem > > # Try to route the path. > > path = @router.route(path) if @router > > # The characters after the last '.' in the path form the > # extension that itself represents the expected response > # content type. > > ext = File.extname(path)[1..-1] || "html" # <------------ extname > don't like no nil > .... > > So if uri.length == 0, then uri.split('?') returns [], so path and query > are both nil. The call to File.extname fails because of this. > > I solved this by adding the path ||= "", does this look like a good > solution? Should I make a patch? > > thx, > (ab) > > -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20070915.patch Type: text/x-patch Size: 63987 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070915/ce68c0e5/attachment-0001.bin From george.moschovitis at gmail.com Sat Sep 15 13:42:37 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 15 Sep 2007 20:42:37 +0300 Subject: [Nitro] render :index broken In-Reply-To: <46EBE6F8.6000206@arnebrasseur.net> References: <46E50039.3000005@arnebrasseur.net> <46EBE6F8.6000206@arnebrasseur.net> Message-ID: thanks, for this patch. Is it possible that you add to the spec file: test/raw/dispatcher.rb a test for this? thank you. -g. On 9/15/07, Arne Brasseur wrote: > Patch included. This solves redirecting to the index method of the root > controller. > > (ab) > > Arne Brasseur schreef: > > When doing "render :index " in a controller action, the following gives > > me an error: > > > > #dispatcher.rb line 142 > > > > def dispatch(uri, method = :get) > > # Extract the query string. > > > > path, query = uri.split("?", 2) # <------- uri == "" then > > path == query == nil > > > > path ||= "" # <------ This solves the problem > > > > # Try to route the path. > > > > path = @router.route(path) if @router > > > > # The characters after the last '.' in the path form the > > # extension that itself represents the expected response > > # content type. > > > > ext = File.extname(path)[1..-1] || "html" # <------------ extname > > don't like no nil > > .... > > > > So if uri.length == 0, then uri.split('?') returns [], so path and query > > are both nil. The call to File.extname fails because of this. > > > > I solved this by adding the path ||= "", does this look like a good > > solution? Should I make a patch? > > > > thx, > > (ab) > > > > > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From arne at arnebrasseur.net Sun Sep 16 00:15:27 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 16 Sep 2007 12:15:27 +0800 Subject: [Nitro] render :index broken In-Reply-To: References: <46E50039.3000005@arnebrasseur.net> <46EBE6F8.6000206@arnebrasseur.net> Message-ID: <46ECADDF.1040101@arnebrasseur.net> There you go. Both patches are included. (ab) George Moschovitis schreef: > thanks, for this patch. Is it possible that you add to the spec file: > > test/raw/dispatcher.rb > > a test for this? > > thank you. > > -g. > > On 9/15/07, Arne Brasseur wrote: > >> Patch included. This solves redirecting to the index method of the root >> controller. >> >> (ab) >> >> Arne Brasseur schreef: >> >>> When doing "render :index " in a controller action, the following gives >>> me an error: >>> >>> #dispatcher.rb line 142 >>> >>> def dispatch(uri, method = :get) >>> # Extract the query string. >>> >>> path, query = uri.split("?", 2) # <------- uri == "" then >>> path == query == nil >>> >>> path ||= "" # <------ This solves the problem >>> >>> # Try to route the path. >>> >>> path = @router.route(path) if @router >>> >>> # The characters after the last '.' in the path form the >>> # extension that itself represents the expected response >>> # content type. >>> >>> ext = File.extname(path)[1..-1] || "html" # <------------ extname >>> don't like no nil >>> .... >>> >>> So if uri.length == 0, then uri.split('?') returns [], so path and query >>> are both nil. The call to File.extname fails because of this. >>> >>> I solved this by adding the path ||= "", does this look like a good >>> solution? Should I make a patch? >>> >>> thx, >>> (ab) >>> >>> >>> >> -- >> Arne Brasseur >> http://www.arnebrasseur.net >> arne at arnebrasseur.net >> >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> >> >> > > > -- Arne Brasseur http://www.arnebrasseur.net arne at arnebrasseur.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070916/3b356b37/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle_ab_20070916.patch Type: text/x-patch Size: 64441 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070916/3b356b37/attachment-0001.bin From george.moschovitis at gmail.com Sun Sep 16 02:18:19 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 16 Sep 2007 09:18:19 +0300 Subject: [Nitro] render :index broken In-Reply-To: <46ECADDF.1040101@arnebrasseur.net> References: <46E50039.3000005@arnebrasseur.net> <46EBE6F8.6000206@arnebrasseur.net> <46ECADDF.1040101@arnebrasseur.net> Message-ID: thanks! -g. On 9/16/07, Arne Brasseur wrote: > > There you go. Both patches are included. > > (ab) > > George Moschovitis schreef: > thanks, for this patch. Is it possible that you add to the spec file: > > test/raw/dispatcher.rb > > a test for this? > > thank you. > > -g. > > On 9/15/07, Arne Brasseur wrote: > > > Patch included. This solves redirecting to the index method of the root > controller. > > (ab) > > Arne Brasseur schreef: > > > When doing "render :index " in a controller action, the following gives > me an error: > > #dispatcher.rb line 142 > > def dispatch(uri, method = :get) > # Extract the query string. > > path, query = uri.split("?", 2) # <------- uri == "" then > path == query == nil > > path ||= "" # <------ This solves the problem > > # Try to route the path. > > path = @router.route(path) if @router > > # The characters after the last '.' in the path form the > # extension that itself represents the expected response > # content type. > > ext = File.extname(path)[1..-1] || "html" # <------------ extname > don't like no nil > .... > > So if uri.length == 0, then uri.split('?') returns [], so path and query > are both nil. The call to File.extname fails because of this. > > I solved this by adding the path ||= "", does this look like a good > solution? Should I make a patch? > > thx, > (ab) > > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > > > -- > Arne Brasseur > http://www.arnebrasseur.net > arne at arnebrasseur.net > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From prpht9 at gmail.com Sun Sep 16 18:59:56 2007 From: prpht9 at gmail.com (chris) Date: Sun, 16 Sep 2007 18:59:56 -0400 Subject: [Nitro] Keeping Documentation and Tutorials up-to-date In-Reply-To: <1189801594.894732.275060@57g2000hsv.googlegroups.com> References: <1189801594.894732.275060@57g2000hsv.googlegroups.com> Message-ID: An excellent idea. On 9/14/07, Trans wrote: > > Speaking of RDocs. I find the current set (for 0.42) a bit > overwhelming. It would be nice if the 0.50 rdocs were broken out into > parts, one each for Og, Raw and Nitro. > > 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/20070916/9cff6344/attachment.html From dan at tastapod.com Sun Sep 16 18:49:32 2007 From: dan at tastapod.com (Dan North) Date: Mon, 17 Sep 2007 00:49:32 +0200 Subject: [Nitro] Nitro/Og specs: Mock framework In-Reply-To: References: <389c43e40709111942h4aa44aek1454ad29aed15763@mail.gmail.com> Message-ID: <46EDB2FC.7050000@tastapod.com> Don't worry. The rspec mocking framework won't be going away any time soon. The conversation was about where to focus our energies as rspec developers. Given that ruby has two very good mocking frameworks in mocha and flexmock, we decided to devote less energy to rspec's built-in mocking framework and focus on the story runner and decent Test::Unit integration. rspec's mocks will be supported, and rspec will continue to use rspec mocks internally to describe its own behaviour. David Chelimsky (one of the rspec project leads) added support a while ago for alternative mocking frameworks, which means you can use whichever you prefer and rspec will play nicely with it. You can of course still choose to use the internal one. On a purely personal level, I prefer mocha - mostly because I come from a Java and JMock world and mocha is a very natural progression of that into ruby. However I've heard good things about flexmock so I wouldn't want to tell you to use one over the other (or over rspec's own mocks). So to answer your questions: a) it has been decided that we will continue to support rspec's mock framework, and to encourage and accept improvements to it, and b) nitro is welcome to choose whichever mocking framework it prefers, safe in the knowledge that rspec will work with it. Cheers, Dan George Moschovitis wrote: > no idea. I understand there is a member of the rspec dev team on this > list, maybe he can help. > > -g. > > > > On 9/12/07, *Mark Van De Vyver* < mvyver at gmail.com > > wrote: > > Hi, > I've seen some discussion on the rspec list that the rspec mock > facility may/will be deprecated. > indication is that it should support flexmock or mocha. > > 2 Q's: > a) Anyone know if this has been decided? > b) Which Nitro/Og will choose? > > mv > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > > -- > http://www.me.gr > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070917/5e9fcfd1/attachment.html From arne at arnebrasseur.net Mon Sep 17 01:22:49 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Sun, 16 Sep 2007 22:22:49 -0700 (PDT) Subject: [Nitro] Keeping Documentation and Tutorials up-to-date In-Reply-To: References: <1189801594.894732.275060@57g2000hsv.googlegroups.com> Message-ID: <3250.140.134.35.42.1190006569.squirrel@webmail.arnebrasseur.net> Actually if you do 'rake rdoc' it generates 4 different directories of docs. I'm toying with the rake task a bit. It shells out to rdoc ATM instead of using the rake RDoc task. Also I would like to add the 'inline source' option so you can view the source of methods. However this gives problems with the README files included in the docs. Every time there's a html comment in the README it raises an exception saying "Unhandled special". I'm looking into it, we might have to remove all html-style comments ()from the README files to be able to inline the sources. To be continued... (ab) > An excellent idea. > > > On 9/14/07, Trans wrote: >> >> Speaking of RDocs. I find the current set (for 0.42) a bit >> overwhelming. It would be nice if the 0.50 rdocs were broken out into >> parts, one each for Og, Raw and Nitro. >> >> 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 dan at tastapod.com Mon Sep 17 06:56:15 2007 From: dan at tastapod.com (Dan North) Date: Mon, 17 Sep 2007 12:56:15 +0200 Subject: [Nitro] help! need a nitro demo for railsconf!! Message-ID: <46EE5D4F.6020507@tastapod.com> Hi folks. I'm at RailsConf Europe - I've just presented a workshop about behaviour-driven development on Rails. I've been making some noise about nitro and now people are asking me to show it to them. The movies have disappeared - I assume because they are now out of date wrt the current codebase. So here's my question: What can I show/demonstrate in terms of showing how amazing nitro is? Obviously there's a time-critical element to this :) Thanks, Dan From george.moschovitis at gmail.com Mon Sep 17 08:34:55 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 17 Sep 2007 15:34:55 +0300 Subject: [Nitro] help! need a nitro demo for railsconf!! In-Reply-To: <46EE5D4F.6020507@tastapod.com> References: <46EE5D4F.6020507@tastapod.com> Message-ID: the old screencasts are here: http://oxywtf.de/tip/35 i am a bit busy at the moment, I cannot help you further at this time. -g. On 9/17/07, Dan North wrote: > Hi folks. > > I'm at RailsConf Europe - I've just presented a workshop about > behaviour-driven development on Rails. I've been making some noise about > nitro and now people are asking me to show it to them. > > The movies have disappeared - I assume because they are now out of date > wrt the current codebase. So here's my question: > > What can I show/demonstrate in terms of showing how amazing nitro is? > > Obviously there's a time-critical element to this :) > > Thanks, > Dan > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://www.me.gr http://phidz.com http://blog.gmosx.com http://cull.gr http://www.joy.gr http://nitroproject.org From dan at tastapod.com Mon Sep 17 09:44:55 2007 From: dan at tastapod.com (Dan North) Date: Mon, 17 Sep 2007 15:44:55 +0200 Subject: [Nitro] help! need a nitro demo for railsconf!! In-Reply-To: References: <46EE5D4F.6020507@tastapod.com> Message-ID: <46EE84D7.6020600@tastapod.com> Brilliant, thanks George. Exactly what I was looking for - typos and everything ;) George Moschovitis wrote: > the old screencasts are here: > > http://oxywtf.de/tip/35 > > i am a bit busy at the moment, I cannot help you further at this time. > -g. > > > > On 9/17/07, Dan North wrote: > >> Hi folks. >> >> I'm at RailsConf Europe - I've just presented a workshop about >> behaviour-driven development on Rails. I've been making some noise about >> nitro and now people are asking me to show it to them. >> >> The movies have disappeared - I assume because they are now out of date >> wrt the current codebase. So here's my question: >> >> What can I show/demonstrate in terms of showing how amazing nitro is? >> >> Obviously there's a time-critical element to this :) >> >> Thanks, >> Dan >> _______________________________________________ >> 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/20070917/1c33ddb0/attachment.html From rob at robmela.com Mon Sep 17 10:00:16 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 17 Sep 2007 10:00:16 -0400 Subject: [Nitro] Elements and Partials Message-ID: <46EE8870.9080603@robmela.com> What do people think about the comparison of Nitro elements to Rails partials? It occurs to me that Elements are at once both more flexible and simpler. 1) For starters, a partial has only one point of inclusion in a template. You can pass parameters to it, which is clumsy for some areas. So "render _footer" is the same across all pages -- there's not much flexibility in wrapping custom footer content in it. With Elements, there are two points of inclusion -- a begin and an end, and all the stuff in between is passed to the Element as "content". 2) It also occurs to me that Elements allow stripping the HTML mess out of templates -- making for cleaner, more maintainable templates. while at the same time keeping relevent content in the same template. For some reason I don't quite see this with Rails partials. One of the things I hate most is having to match endless nested divs and pre's. Templates allow putting divs into elements. The elements can be named according to their semantic usage, the resulting template is MUCH easier to read and work with. Matching the opening and closing tags is already handled within the Element -- that alone is worth a lot to me. For example, this element: class CodeSnippet def render %~ 
                #{content}
    ~ end end ... included in the template is... def say_hello(msg) puts msg end ... which, in a template full of content is MUCH MUCH easier to identify than 
    >> behaviour-driven development on Rails. I've been making some noise about
>>> nitro and now people are asking me to show it to them.
>>>
>>> The movies have disappeared - I assume because they are now out of date
>>> wrt the current codebase. So here's my question:
>>>
>>> What can I show/demonstrate in terms of showing how amazing nitro is?
>>>
>>> Obviously there's a time-critical element to this :)
>>>
>>> Thanks,
>>> Dan
>>> _______________________________________________
>>> Nitro-general mailing list
>>> Nitro-general at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/nitro-general
>>>
>>>     
>>
>>
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070917/6841d85c/attachment.html 

From dan at tastapod.com  Mon Sep 17 10:20:47 2007
From: dan at tastapod.com (Dan North)
Date: Mon, 17 Sep 2007 16:20:47 +0200
Subject: [Nitro] help! need a nitro demo for railsconf!!
In-Reply-To: <46EE904A.6030401@arnebrasseur.net>
References: <46EE5D4F.6020507@tastapod.com>		<46EE84D7.6020600@tastapod.com>
	<46EE904A.6030401@arnebrasseur.net>
Message-ID: <46EE8D3F.3070001@tastapod.com>

Nice one Arne. I'll keep a look out for that.


Arne Brasseur wrote:
> Some things that have changed since then, off the top of my head:
>
> - to output from a controller method use print, returning a string no 
> longer works
> - default template dir is app/template
> - default public dir is public/
> - og uses attr_accessor, not property
>
> Good luck, make sure to tell us how it went!
>
> (ab)
>
>
> Dan North schreef:
>> Brilliant, thanks George. Exactly what I was looking for - typos and 
>> everything ;)
>>
>>
>> George Moschovitis wrote:
>>> the old screencasts are here:
>>>
>>> http://oxywtf.de/tip/35
>>>
>>> i am a bit busy at the moment, I cannot help you further at this time.
>>> -g.
>>>
>>>
>>>
>>> On 9/17/07, Dan North  wrote:
>>>   
>>>> Hi folks.
>>>>
>>>> I'm at RailsConf Europe - I've just presented a workshop about
>>>> behaviour-driven development on Rails. I've been making some noise about
>>>> nitro and now people are asking me to show it to them.
>>>>
>>>> The movies have disappeared - I assume because they are now out of date
>>>> wrt the current codebase. So here's my question:
>>>>
>>>> What can I show/demonstrate in terms of showing how amazing nitro is?
>>>>
>>>> Obviously there's a time-critical element to this :)
>>>>
>>>> Thanks,
>>>> Dan
>>>> _______________________________________________
>>>> Nitro-general mailing list
>>>> Nitro-general at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/nitro-general
>>>>
>>>>     
>>>
>>>
>>>   
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
> -- 
> Arne Brasseur
> http://www.arnebrasseur.net
> arne at arnebrasseur.net
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20070917/91dc7447/attachment.html 

From james.britt at gmail.com  Mon Sep 17 11:25:41 2007
From: james.britt at gmail.com (James Britt)
Date: Mon, 17 Sep 2007 08:25:41 -0700
Subject: [Nitro] help! need a nitro demo for railsconf!!
In-Reply-To: <46EE904A.6030401@arnebrasseur.net>
References: <46EE5D4F.6020507@tastapod.com>		<46EE84D7.6020600@tastapod.com>
	<46EE904A.6030401@arnebrasseur.net>
Message-ID: <46EE9C75.6090600@gmail.com>

Arne Brasseur wrote:
> Some things that have changed since then, off the top of my head:
> 
> - to output from a controller method use print, returning a string no 
> longer works

Too bad;  I gave an overview of Nitro at Desert Code Camp here in 
Phoenix the other day, and was explaining how nice it was that the 
return value of controller methods can be the actual page output. 
Methods are just methods, as in a non-Web app.  I really like the "just 
return a string" behavior.


> - default template dir is app/template
> - default public dir is public/
> - og uses attr_accessor, not property

That's a very cool feature, and I like to demonstrate how one can start 
with a  basic Ruby app and evolve it into A Web app with various 
behavior.  And if and when I decide a model class needs persistence, it 
can be arranged with a few simple additions to the attribute defs.

To me, this is the big win for Nitro.    It's very easy to start with a 
static HTML version  of a site, and gradually add in dynamic behavior as 
needed, without the up-front decision on code and feature that you may 
need actually need.  And the code looks like the Ruby code of any 
non-Web app (well, up to a point).


I suspect that people accustomed to Rails would want to know about 
unit/functional/integration testing in Nitro (as would I :)) and how Og 
handles database migrations.



-- 
James Britt

"Inside every large system there's a small system trying to get out".
    - Chet Hendrickson

From mvyver at gmail.com  Tue Sep 18 03:04:02 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Tue, 18 Sep 2007 17:04:02 +1000
Subject: [Nitro] OG [PATCH]: Add quote_column/table required method to
	sql/utils
Message-ID: <389c43e40709180004y4babb3atc65caa580a40eb63@mail.gmail.com>

Hi,
There doesn't seem to be any indication that these methods are
required to be implemented by an SQL store adapter.
This patch brings this requirement to the surface.

mv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvdv-20070918-1
Type: application/octet-stream
Size: 64569 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/5d8dafec/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvdv-20070918-1.tar.gz
Type: application/x-gzip
Size: 17771 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/5d8dafec/attachment-0001.gz 

From george.moschovitis at gmail.com  Tue Sep 18 03:13:14 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 10:13:14 +0300
Subject: [Nitro] help! need a nitro demo for railsconf!!
In-Reply-To: <46EE9C75.6090600@gmail.com>
References: <46EE5D4F.6020507@tastapod.com>
	
	<46EE84D7.6020600@tastapod.com> <46EE904A.6030401@arnebrasseur.net>
	<46EE9C75.6090600@gmail.com>
Message-ID: 

> Too bad;  I gave an overview of Nitro at Desert Code Camp here in
> Phoenix the other day, and was explaining how nice it was that the
> return value of controller methods can be the actual page output.
> Methods are just methods, as in a non-Web app.  I really like the "just
> return a string" behavior.

The old behaviour may return... It is a bit tricky and has edge cases,
but I plan to revisit this issue.

-g.



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From dan at tastapod.com  Tue Sep 18 03:21:36 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 09:21:36 +0200
Subject: [Nitro] install failure for nitro 0.50.0
Message-ID: <46EF7C80.9090502@tastapod.com>

Hi folks.

I'm trying to install 0.50.0 from the darcs source. I ran rake dist:all 
and installed each of the gems. I'm getting this when I try to install 
nitro:

dan at kyle:~/projects/nitro/repo.nitroproject.org$ sudo gem install -y -w 
dist/nitro-0.50.0.gem
Successfully installed nitro, version 0.50.0
Installing ri documentation for nitro-0.50.0...
File not found: vendor


What am I doing wrong?

Thanks,
Dan

From george.moschovitis at gmail.com  Tue Sep 18 03:28:09 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 10:28:09 +0300
Subject: [Nitro] install failure for nitro 0.50.0
In-Reply-To: <46EF7C80.9090502@tastapod.com>
References: <46EF7C80.9090502@tastapod.com>
Message-ID: 

hmm... I added a vendor directory in nitro (it contains the tmail
source code at the moment)
how  did you create the gem? it seems the gem cannot find this dir. I
'll try to fix this today.

-g.



On 9/18/07, Dan North  wrote:
> Hi folks.
>
> I'm trying to install 0.50.0 from the darcs source. I ran rake dist:all
> and installed each of the gems. I'm getting this when I try to install
> nitro:
>
> dan at kyle:~/projects/nitro/repo.nitroproject.org$ sudo gem install -y -w
> dist/nitro-0.50.0.gem
> Successfully installed nitro, version 0.50.0
> Installing ri documentation for nitro-0.50.0...
> File not found: vendor
>
>
> What am I doing wrong?
>
> Thanks,
> Dan
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From t_leitner at gmx.at  Tue Sep 18 05:44:38 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Tue, 18 Sep 2007 11:44:38 +0200
Subject: [Nitro] Difference between /account and /account/ ???
Message-ID: 

Hi everybody,

I have a problem with the repo version of nitro. I have the following  
controller in app/controller/account.rb:

class Account::Controller

   include FormHelper

   def index(*args)
     p 'in index'
     @accounts = Account.all
   end

end

where Account is a model object and the following app/template/ 
account/index.htmlx file:



   
   
   



and app.rb as follows:

#!/usr/bin/env ruby

$DBG = true

require 'nitro_and_og';
include Nitro
require 'nitro/part/admin'

require 'app/setup' # includes all controllers and models
require 'app/skin' # defines the Page element

app = Application.new
app.dispatcher.root = Manager
app.dispatcher.root.account = Account
app.start

The problem is that when navigating to /account everything works just  
fine and I get a list of my accounts. However, when using /account/  
the Account::Controller#index method does not seem to be called which  
results in the @accounts variable not being correctly initialized and  
an error afterwards.

Any ideas why this is so? Kashia suggested on #nitro that this may be  
a bug?!

Thanks for the help,
   Thomas

From john at oxyliquit.de  Tue Sep 18 06:04:07 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Tue, 18 Sep 2007 12:04:07 +0200
Subject: [Nitro] Nitro/Og specs: Mock framework
In-Reply-To: <46EDB2FC.7050000@tastapod.com>
References: <389c43e40709111942h4aa44aek1454ad29aed15763@mail.gmail.com>
	
	<46EDB2FC.7050000@tastapod.com>
Message-ID: 

Hi,

> So to answer your questions: a) it has been decided that we will
> continue to support rspec's mock framework, and to encourage and accept
> improvements to it, and b) nitro is welcome to choose whichever mocking
> framework it prefers, safe in the knowledge that rspec will work with it.

that is very nice.  I used the rspec mocking in a few specs (very few) so
it wouldn't really be a problem to move.
But, I'm happy it's going to stay, as I found it to feel quite nice.

Jo



From rff_rff at yahoo.it  Tue Sep 18 06:10:48 2007
From: rff_rff at yahoo.it (gabriele renzi)
Date: Tue, 18 Sep 2007 10:10:48 +0000 (UTC)
Subject: [Nitro] Elements and Partials
References: <46EE8870.9080603@robmela.com>
Message-ID: 

On Mon, 17 Sep 2007 10:00:16 -0400, Robert Mela wrote:

> What do people think about the comparison of Nitro elements to Rails 
> partials?

I've been away for a while so I don't know if this is changed, but
something that I had issues with elements is that they could not be used
dynamically. 

What I mean:
  #{el} 
 
was impossible, whereas it is possible to pass variables to rails'
partials.

But again, I don't know if this behaviour changed.



-- 
goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info


From george.moschovitis at gmail.com  Tue Sep 18 06:22:10 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 13:22:10 +0300
Subject: [Nitro] Elements and Partials
In-Reply-To: 
References: <46EE8870.9080603@robmela.com> 
Message-ID: 

> was impossible, whereas it is possible to pass variables to rails'
> partials.
>

This is certainly possible:


class Element
  def render
     %{
     
    index: #{attr :idx}
    
     }
  end
end


-g.


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Tue Sep 18 06:22:55 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 13:22:55 +0300
Subject: [Nitro] Elements and Partials
In-Reply-To: <46EE8870.9080603@robmela.com>
References: <46EE8870.9080603@robmela.com>
Message-ID: 

> What do people think about the comparison of Nitro elements to Rails
> partials?


Obviously I like them a lot ;-)

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From dan at tastapod.com  Tue Sep 18 06:22:59 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 12:22:59 +0200
Subject: [Nitro] test failures in og/dbi
Message-ID: <46EFA703.9040005@tastapod.com>

Hi there.

I'm getting some errors in the og specs. Can anyone help?

Thanks,
Dan

    dan at kyle:~/projects/nitro/repo.nitroproject.org$ rake test:og
    /var/lib/gems/1.8/bin/rake:17:Warning: require_gem is obsolete.  Use
    gem instead.
    (in /home/dan/projects/nitro/repo.nitroproject.org)
    Running og...                           [   1 specs - all passed ]
    Running og/adapter/dbi...               [   8 specs -   4 failed ]
    Running og/model/timestamped...         [   1 specs - all passed ]
    Running og/store/sql...                 [   1 specs - all passed ]
    Running og/util/ann_attr...             [   1 specs - all passed ]
    Running og/validation...                [   2 specs - all passed ]
    -------------------------------[ og/adapter/dbi
    ]-------------------------------
    ExitStatus:
    #
    StdOut:
    Database "test" dropped
    FFDatabase "test" dropped
    FF

    1)
    NameError in 'The connection to a new Og store manager should use
    sqlite memory as the default, when given no option.'
    undefined method `eof?' for class `SQLite3::ResultSet'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
    `alias_method'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:16:
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:

    2)
    NameError in 'The connection to a new Og store manager should use
    sqlite memory as the default, when given an empty option hash.'
    undefined method `eof?' for class `SQLite3::ResultSet'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
    `alias_method'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
    /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:25:
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:

    3)
    NoMethodError in 'The DBI adapter structure before(:all)'
    undefined method `merge' for nil:NilClass
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/../../helper.rb:69:in
    `start'
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:43:
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:

    4)
    NoMethodError in 'The DBI adapter structure after(:all)'
    undefined method `store' for nil:NilClass
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:65:
    /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:

    Finished in 0.343557 seconds

    4 examples, 4 failures
    StdErr:

    nil
    14 examples, 4 failures

    These failed: og/adapter/dbi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070918/bfe2e9b7/attachment.html 

From mvyver at gmail.com  Tue Sep 18 07:23:22 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Tue, 18 Sep 2007 21:23:22 +1000
Subject: [Nitro] test failures in og/dbi
In-Reply-To: <46EFA703.9040005@tastapod.com>
References: <46EFA703.9040005@tastapod.com>
Message-ID: <389c43e40709180423xb80e743j13e47b5124f61eff@mail.gmail.com>

Hi Dan,
Yes the DBI adapter is a work in progress.  I it's currently not useful.
I'm a bit confused.... I contributed that code by building on the 0.50
gem, anyway it seems you have it, best advice for the moment is to
ignore it/ easiest might be to remove/empty the DBI/test files?

There are some issues that mean I've altered how I'll proceed with
this adapter, I'd like to get things implemented then, once complete,
contribute 'snippets' and their passing specs to george.  At the
moment things are very much 2-steps forward 1 step back.

Anyway, the adapter is progressing:
103 examples, 15 failures, 19 pending

Of the current 15 failures 14 are 'pending' changes I've implemented -
I've yet to work out how best to get this to George....

Cheers
Mark

On 9/18/07, Dan North  wrote:
>
>  Hi there.
>
>  I'm getting some errors in the og specs. Can anyone help?
>
>  Thanks,
>  Dan
>
>
> dan at kyle:~/projects/nitro/repo.nitroproject.org$ rake
> test:og
>  /var/lib/gems/1.8/bin/rake:17:Warning: require_gem is
> obsolete.  Use gem instead.
>  (in /home/dan/projects/nitro/repo.nitroproject.org)
>  Running og...                           [   1 specs - all passed ]
>  Running og/adapter/dbi...               [   8 specs -   4 failed ]
>  Running og/model/timestamped...         [   1 specs - all passed ]
>  Running og/store/sql...                 [   1 specs - all passed ]
>  Running og/util/ann_attr...             [   1 specs - all passed ]
>  Running og/validation...                [   2 specs - all passed ]
>  -------------------------------[ og/adapter/dbi
> ]-------------------------------
>  ExitStatus:
>  #
>  StdOut:
>  Database "test" dropped
>  FFDatabase "test" dropped
>  FF
>
>  1)
>  NameError in 'The connection to a new Og store manager should use sqlite
> memory as the default, when given no option.'
>  undefined method `eof?' for class `SQLite3::ResultSet'
> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
> `alias_method'
> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:16:
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>
>  2)
>  NameError in 'The connection to a new Og store manager should use sqlite
> memory as the default, when given an empty option hash.'
>  undefined method `eof?' for class `SQLite3::ResultSet'
> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
> `alias_method'
> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:25:
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>
>  3)
>  NoMethodError in 'The DBI adapter structure before(:all)'
>  undefined method `merge' for nil:NilClass
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/../../helper.rb:69:in
> `start'
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:43:
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>
>  4)
>  NoMethodError in 'The DBI adapter structure after(:all)'
>  undefined method `store' for nil:NilClass
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:65:
> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>
>  Finished in 0.343557 seconds
>
>  4 examples, 4 failures
>  StdErr:
>
>  nil
>  14 examples, 4 failures
>
>  These failed: og/adapter/dbi
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From dan at tastapod.com  Tue Sep 18 07:51:18 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 13:51:18 +0200
Subject: [Nitro] test failures in og/dbi
In-Reply-To: <389c43e40709180423xb80e743j13e47b5124f61eff@mail.gmail.com>
References: <46EFA703.9040005@tastapod.com>
	<389c43e40709180423xb80e743j13e47b5124f61eff@mail.gmail.com>
Message-ID: <46EFBBB6.5000201@tastapod.com>

Hi Mark

Thanks for letting me know, and good luck!

Cheers,
Dan


Mark Van De Vyver wrote:
> Hi Dan,
> Yes the DBI adapter is a work in progress.  I it's currently not useful.
> I'm a bit confused.... I contributed that code by building on the 0.50
> gem, anyway it seems you have it, best advice for the moment is to
> ignore it/ easiest might be to remove/empty the DBI/test files?
>
> There are some issues that mean I've altered how I'll proceed with
> this adapter, I'd like to get things implemented then, once complete,
> contribute 'snippets' and their passing specs to george.  At the
> moment things are very much 2-steps forward 1 step back.
>
> Anyway, the adapter is progressing:
> 103 examples, 15 failures, 19 pending
>
> Of the current 15 failures 14 are 'pending' changes I've implemented -
> I've yet to work out how best to get this to George....
>
> Cheers
> Mark
>
> On 9/18/07, Dan North  wrote:
>   
>>  Hi there.
>>
>>  I'm getting some errors in the og specs. Can anyone help?
>>
>>  Thanks,
>>  Dan
>>
>>
>> dan at kyle:~/projects/nitro/repo.nitroproject.org$ rake
>> test:og
>>  /var/lib/gems/1.8/bin/rake:17:Warning: require_gem is
>> obsolete.  Use gem instead.
>>  (in /home/dan/projects/nitro/repo.nitroproject.org)
>>  Running og...                           [   1 specs - all passed ]
>>  Running og/adapter/dbi...               [   8 specs -   4 failed ]
>>  Running og/model/timestamped...         [   1 specs - all passed ]
>>  Running og/store/sql...                 [   1 specs - all passed ]
>>  Running og/util/ann_attr...             [   1 specs - all passed ]
>>  Running og/validation...                [   2 specs - all passed ]
>>  -------------------------------[ og/adapter/dbi
>> ]-------------------------------
>>  ExitStatus:
>>  #
>>  StdOut:
>>  Database "test" dropped
>>  FFDatabase "test" dropped
>>  FF
>>
>>  1)
>>  NameError in 'The connection to a new Og store manager should use sqlite
>> memory as the default, when given no option.'
>>  undefined method `eof?' for class `SQLite3::ResultSet'
>> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
>> `alias_method'
>> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:16:
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>>
>>  2)
>>  NameError in 'The connection to a new Og store manager should use sqlite
>> memory as the default, when given an empty option hash.'
>>  undefined method `eof?' for class `SQLite3::ResultSet'
>> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:in
>> `alias_method'
>> /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite/override.rb:9:
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter/sqlite.rb:12:
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/adapter.rb:30:in `for_name'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og/manager.rb:51:in `initialize'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `new'
>>  /var/lib/gems/1.8/gems/og-0.50.0/lib/og.rb:176:in `start'
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:25:
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>>
>>  3)
>>  NoMethodError in 'The DBI adapter structure before(:all)'
>>  undefined method `merge' for nil:NilClass
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/../../helper.rb:69:in
>> `start'
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:43:
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>>
>>  4)
>>  NoMethodError in 'The DBI adapter structure after(:all)'
>>  undefined method `store' for nil:NilClass
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:65:
>> /home/dan/projects/nitro/repo.nitroproject.org/og/test/og/adapter/dbi.rb:39:
>>
>>  Finished in 0.343557 seconds
>>
>>  4 examples, 4 failures
>>  StdErr:
>>
>>  nil
>>  14 examples, 4 failures
>>
>>  These failed: og/adapter/dbi
>>
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>>
>>     
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070918/93848a0b/attachment.html 

From dan at tastapod.com  Tue Sep 18 08:05:21 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 14:05:21 +0200
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
Message-ID: <46EFBF01.3080807@tastapod.com>

Hi folks.

So I'm telling people at RailsConf about nitro (they're making a funny 
looping knot in a long piece of rope - I wonder what that's for..?), and 
in particular trying to show it to one of the jruby guys.

He pulled down the latest darcs head (having built darcs on his macbook 
which took about 6 hours  - maybe we should consider mercurial?) and 
tried to rake test:all - it breaks all over the place. Not a good first 
impression!

I tried the same on ubuntu and it breaks in the same way.

I managed to get it working on my machine by setting GEM_HOME (which 
incidentally fixed a bunch of other stuff for me too). On his machine it 
still doesn't run through properly. Also, if the gems are installed in 
the correct place relative to your ruby installation, you shouldn't even 
need GEM_HOME, so the nitro build is definitely borked.

Can someone who knows how the build works take a look please? Also, if 
we're using rspec now, we can switch to the standard spec task which 
should fix a lot of this.

Cheers,
Dan

From george.moschovitis at gmail.com  Tue Sep 18 08:17:45 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 15:17:45 +0300
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFBF01.3080807@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
Message-ID: 

Let me try to give you some quick help. I will try to provide a better
solution later today.

Get the latest version from the repository.

make sure you have the following gems installed:

facets-1.8.54             <---------- Notice the version!!
RedCloth-3.0.4
hpricot-0.6
mysql-2.7
xml-simple-1.0.11

add something like this to your .bashrc file

export RUBYOPT="-rubygems -I/home/gmosx/code/public/nitro/lib
-I/home/gmosx/code/public/nitro/vendor
-I/home/gmosx/code/public/og/lib -I/home/gmosx/code/public/glue/lib
-I/home/gmosx/code/public/raw/lib

then run the blog example

$ cd examples/blog
$ vi conf/debug.rb     <---- customize
$ nitro



hope this will work for you.


-g.


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Tue Sep 18 08:27:54 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 15:27:54 +0300
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFBF01.3080807@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
Message-ID: 

try these gems and let me know if they work

install in this order: gem, og, raw, nitro

try the blog example.

-g.


PS: this will be a two part mail...

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: examples-0.50.0.tgz
Type: application/x-gzip
Size: 20996 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/20c1ca66/attachment-0001.tgz 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glue-0.50.0.gem
Type: application/octet-stream
Size: 22528 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/20c1ca66/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: og-0.50.0.gem
Type: application/octet-stream
Size: 103936 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/20c1ca66/attachment-0003.obj 

From george.moschovitis at gmail.com  Tue Sep 18 08:28:40 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 15:28:40 +0300
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: 
References: <46EFBF01.3080807@tastapod.com>
	
Message-ID: 

two more gems...

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: raw-0.50.0.gem
Type: application/octet-stream
Size: 87552 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/49524914/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nitro-0.50.0.gem
Type: application/octet-stream
Size: 139264 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/49524914/attachment-0003.obj 

From aidan at yoyo.org  Tue Sep 18 08:44:44 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Tue, 18 Sep 2007 13:44:44 +0100 (BST)
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFBF01.3080807@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
Message-ID: <12584.199.67.138.84.1190119484.squirrel@yoyo.org>


> He pulled down the latest darcs head (having built darcs on his macbook
> which took about 6 hours  - maybe we should consider mercurial?) and
> tried to rake test:all - it breaks all over the place. Not a good first
> impression!

Hey Dan,

If you're getting Mac users to use this, they shouldn't try to build darcs
or Haskell - just get them to grab the binaries.

Haskell (GHC): http://www.haskell.org/ghc/download_ghc_641.html
Darcs: http://cbis.anu.edu.au/misc/darcs/

I've noticed no difference in having binary versus built-from-source in
terms of performance.

Aidan

From dan at tastapod.com  Tue Sep 18 09:17:08 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 15:17:08 +0200
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <12584.199.67.138.84.1190119484.squirrel@yoyo.org>
References: <46EFBF01.3080807@tastapod.com>
	<12584.199.67.138.84.1190119484.squirrel@yoyo.org>
Message-ID: <46EFCFD4.7030403@tastapod.com>

Yeah, it seemed odd to me too. He said he looked round for darcs 
binaries but couldn't find them.

Having used both darcs and mercurial for a while now, I would still 
recommend mercurial. But if you have to choose between darcs and 
mercurial, you're already in a very happy place :)

Cheers,
Dan


Aidan Rogers wrote:
>> He pulled down the latest darcs head (having built darcs on his macbook
>> which took about 6 hours  - maybe we should consider mercurial?) and
>> tried to rake test:all - it breaks all over the place. Not a good first
>> impression!
>>     
>
> Hey Dan,
>
> If you're getting Mac users to use this, they shouldn't try to build darcs
> or Haskell - just get them to grab the binaries.
>
> Haskell (GHC): http://www.haskell.org/ghc/download_ghc_641.html
> Darcs: http://cbis.anu.edu.au/misc/darcs/
>
> I've noticed no difference in having binary versus built-from-source in
> terms of performance.
>
> Aidan
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070918/4db383c4/attachment.html 

From rob at robmela.com  Tue Sep 18 09:26:53 2007
From: rob at robmela.com (Robert Mela)
Date: Tue, 18 Sep 2007 09:26:53 -0400
Subject: [Nitro] install failure for nitro 0.50.0
In-Reply-To: 
References: <46EF7C80.9090502@tastapod.com>
	
Message-ID: <46EFD21D.5010904@robmela.com>

I was going to create a cheatsheet on creating and installing the gems.  
Maybe we can make that unnecessary -- or make it more brief...

Last time I generated gems it required hand-editing the gemspecs to get 
the version numbers up-to-date ( as an aside: would it make sense have 
the version numbers be 0.49 until 0.50 goes gold? )

It'd be nice to have a utility script that creates the gems and puts 
then in a gem dir. 


George Moschovitis wrote:
> hmm... I added a vendor directory in nitro (it contains the tmail
> source code at the moment)
> how  did you create the gem? it seems the gem cannot find this dir. I
> 'll try to fix this today.
>
> -g.
>
>
>  
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/fa08d6c9/attachment.vcf 

From george.moschovitis at gmail.com  Tue Sep 18 09:28:45 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 16:28:45 +0300
Subject: [Nitro] Difference between /account and /account/ ???
In-Reply-To: 
References: 
Message-ID: 

Thanks for reporting, I will have a look at it.

-g.

On 9/18/07, Thomas Leitner  wrote:
> Hi everybody,
>
> I have a problem with the repo version of nitro. I have the following
> controller in app/controller/account.rb:
>
> class Account::Controller
>
>    include FormHelper
>
>    def index(*args)
>      p 'in index'
>      @accounts = Account.all
>    end
>
> end
>
> where Account is a model object and the following app/template/
> account/index.htmlx file:
>
> 
>
>    
>    
>    
>
> 
>
> and app.rb as follows:
>
> #!/usr/bin/env ruby
>
> $DBG = true
>
> require 'nitro_and_og';
> include Nitro
> require 'nitro/part/admin'
>
> require 'app/setup' # includes all controllers and models
> require 'app/skin' # defines the Page element
>
> app = Application.new
> app.dispatcher.root = Manager
> app.dispatcher.root.account = Account
> app.start
>
> The problem is that when navigating to /account everything works just
> fine and I get a list of my accounts. However, when using /account/
> the Account::Controller#index method does not seem to be called which
> results in the @accounts variable not being correctly initialized and
> an error afterwards.
>
> Any ideas why this is so? Kashia suggested on #nitro that this may be
> a bug?!
>
> Thanks for the help,
>    Thomas
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Tue Sep 18 09:47:19 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 16:47:19 +0300
Subject: [Nitro] Difference between /account and /account/ ???
In-Reply-To: 
References: 
Message-ID: 

Ok, I think  I fixed that, check out the repo version.

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Tue Sep 18 09:49:42 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 16:49:42 +0300
Subject: [Nitro] install failure for nitro 0.50.0
In-Reply-To: <46EFD21D.5010904@robmela.com>
References: <46EF7C80.9090502@tastapod.com>
	
	<46EFD21D.5010904@robmela.com>
Message-ID: 

how about

rake dist:all

-g.

On 9/18/07, Robert Mela  wrote:
> I was going to create a cheatsheet on creating and installing the gems.
> Maybe we can make that unnecessary -- or make it more brief...
>
> Last time I generated gems it required hand-editing the gemspecs to get
> the version numbers up-to-date ( as an aside: would it make sense have
> the version numbers be 0.49 until 0.50 goes gold? )
>
> It'd be nice to have a utility script that creates the gems and puts
> then in a gem dir.
>
>
> George Moschovitis wrote:
> > hmm... I added a vendor directory in nitro (it contains the tmail
> > source code at the moment)
> > how  did you create the gem? it seems the gem cannot find this dir. I
> > 'll try to fix this today.
> >
> > -g.
> >
> >
> >
> >
> >
> >
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From arne at arnebrasseur.net  Tue Sep 18 09:53:14 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Tue, 18 Sep 2007 21:53:14 +0800
Subject: [Nitro] [PATCH] RDoc task / dispatcher bugfix / tutorial start
Message-ID: <46EFD84A.20208@arnebrasseur.net>

As promised I updated the rake task to generate the rdocs with. It no
longer shells out but properly uses the RDoc task. Sources from methods
are included in the HTML, and seperate docs are generated for the
different subprojects.

There's a bit of a hack in there to handle the 'Unhandled special'
problem I mentioned earlier. IMHO RDoc is simply flawed, but better
solutions are welcome.

do a 'rake rdoc:all' and do tell us what you think.


Second patch is a bugfix. We switched from "/" to "" as the mount path
for the root controller. The Raw::Dispatcher constructor still used the
old location. This was only exposed when using the form

Nitro.start(RootController)

instead of

app=Application.new
app.dispatcher.root=RootController
app.start

A testcase is included.

I also finally started working on the tutorial, preview included. I'm
planning to set up a repository contain the text as well as the example
applications. It might take a while (days, maybe over a week) before I
have time to work on this again. That's why I'm already showing what I have.

Cheers!
(ab)

-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bundle_ab_20070918.patch
Type: text/x-patch
Size: 66584 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070918/4f72b6ba/attachment-0001.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tutorial.txt
Url: http://rubyforge.org/pipermail/nitro-general/attachments/20070918/4f72b6ba/attachment-0001.txt 

From dan at tastapod.com  Tue Sep 18 10:39:52 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 16:39:52 +0200
Subject: [Nitro] testable controllers
Message-ID: <46EFE338.3030207@tastapod.com>

Hi George.

This is a plea from the heart to revert the controller (dispatcher 
method) behaviour to returning a string rather than using multiple print 
statements.

I can test the former simply just by constructing a controller class and 
looking at the result of a method call. The latter requires me to 
subvert the global $stdout, which is just evil in a testing context.

As a developer, if I want to assemble the string in chunks I can do that 
during the method and then return the result at the end, which provides 
the same facility as multiple prints would.

Thanks,
Dan

From george.moschovitis at gmail.com  Tue Sep 18 10:43:37 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 17:43:37 +0300
Subject: [Nitro] OG draft patch: Eliminate the duplicate query seen in
	calls to og_create_schema
In-Reply-To: 
References: <389c43e40709030432y41371b53l92ad2a0de009de4e@mail.gmail.com>
	<389c43e40709030434o467f8d9ah4c47df835a27f7d0@mail.gmail.com>
	
Message-ID: 

I cleaned up the code, and I think the original problem is fixed,

thanks,
-g.

On 9/3/07, George Moschovitis  wrote:
> Thanks for the patch, I will see if I can further cleanup the code.
>
> -g.
>
>
>
> On 9/3/07, Mark Van De Vyver  wrote:
> >
> > This time with the patch... been a long day :)
> >
> > On 9/3/07, Mark Van De Vyver < mvyver at gmail.com> wrote:
> > > Hi Devs,
> > >
> > > Attached is a draft patch that should eliminate the duplicate query
> > > when og_create_schema is run.  I guess this is likely only to have
> > > hurt your performace if you have to create lots of tables (my use
> > > case), have a very slow connection, or a DB that is under heavy load?
> > >
> > > Anyway it was an interesting exercise to try and come to grips with
> > > some of the OG code - I don't fully understand the different roles of
> > > the different SQLEnchant* modules....
> > >
> > > This is my first open source patch so don't expect too much :)
> > >
> > > Seriously, _when_ the guts of this change is OK, then I'll dump all
> > > the commented code and submit a cleaner patch.
> > > I've tested with the Sqlite and Mysql stores/adapters.
> > >
> > > Hopefully a more constructive email than some of the noise I've been
> > > sending lately - steep learning curve :)
> > >
> > > Mark
> > >
> >
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> >
> >
>
>
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
>  http://nitroproject.org


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From dan at tastapod.com  Tue Sep 18 10:15:57 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 16:15:57 +0200
Subject: [Nitro] testing views
Message-ID: <46EFDD9D.5080106@tastapod.com>

Hi there.

I ran a BDD tutorial at RailsConf on a rails app, and I'm trying to redo 
it in nitro to present a side-by-side example.

I'm using 0.41.0 and I don't know how to test the output of a view in 
isolation.

What I want to do is something like:

- set up some @properties
- invoke rendering on a .xhtml view (ideally by just passing the view 
name to something)
- get the xhtml result as a string (or DOM) that I can verify using xpath

Any ideas?

Thanks,
Dan

ps. I found the TestCase mixin. Any reason why you're hacking 
Test::Unit::TestCase rather than defining a NitroTestCase subclass?

From dan at tastapod.com  Tue Sep 18 10:54:50 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 16:54:50 +0200
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: 
References: <46EFBF01.3080807@tastapod.com>	
	
Message-ID: <46EFE6BA.5010104@tastapod.com>

Hi George. Thanks for the quick turnaround.

Results so far:

    Successfully installed glue, version 0.50.0
    Installing ri documentation for glue-0.50.0...
    Installing RDoc documentation for glue-0.50.0...
    Successfully installed og, version 0.50.0
    Installing ri documentation for og-0.50.0...
    *While generating documentation for og-0.50.0
    ... MESSAGE:   Unhandled special: Special: type=33, text="The"
    ... RDOC args: --ri --op /home/dan/misc/gems/1.8/doc/og-0.50.0/ri
    --quiet lib
    (continuing with the rest of the installation)
    *Installing RDoc documentation for og-0.50.0...
    Successfully installed raw, version 0.50.0
    Installing ri documentation for raw-0.50.0...
    *While generating documentation for raw-0.50.0
    ... MESSAGE:   Unhandled special: Special: type=33, text="Encapsulates"
    ... RDOC args: --ri --op /home/dan/misc/gems/1.8/doc/raw-0.50.0/ri
    --quiet lib
    (continuing with the rest of the installation)
    *Installing RDoc documentation for raw-0.50.0...
    Successfully installed nitro, version 0.50.0
    Installing ri documentation for nitro-0.50.0...
    *File not found: vendor
    *


So I don't have ri or rdoc for raw, nitro or og.

I ran the blog app and got the following error (error html page attached) :

    Install XMLSimple for XML input.
    ERROR: Cannot find configuration file 'conf/debug'
     INFO: Starting Webrick server in debug mode, listening at 0.0.0.0:9000
     INFO: Press Ctrl-C to shutdown; Run with --help for options.
    DEBUG: Compiling 'Post::Controller#index' super-method
    DEBUG: Rendering '/status_500'
    DEBUG: Compiling 'Post::Controller#status_500' super-method
    DEBUG: Compiling 'status_500' view sub-method [format: html]
    ERROR: Error while handling Post::Controller#index()
    ERROR: undefined local variable or method `ogmanager' for Post:Class
      /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:693:in
    `method_missing'
      /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:334:in `all'
      ./app/controller/post.rb:7:in `index'
      /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
    `send'
      /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
    `index___super'
     
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
    `send'
     
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
    `method_missing'
     
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
    `send'
     
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
    `render_action'
      /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
    `send'
      /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
    `handle_context'
     
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:134:in
    `do_GET'
      /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__'
      /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'
      /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 `each'
      /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/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:57:in
    `start'
     
    /home/dan/misc/gems/1.8/gems/nitro-0.50.0/lib/nitro/application.rb:135:in
    `start'
      app.rb:22
      LOGGED FROM:
    /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:108:in
    `render_action'

Thanks,
Dan


George Moschovitis wrote:
> two more gems...
>
> -g.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20070918/92c8b855/attachment.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070918/92c8b855/attachment-0001.html 

From george.moschovitis at gmail.com  Tue Sep 18 11:03:11 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 18:03:11 +0300
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFE6BA.5010104@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
	
	
	<46EFE6BA.5010104@tastapod.com>
Message-ID: 

What is this?

Cannot find configuration file 'conf/debug'

is this file missing? have you customized it?

-g.





On 9/18/07, Dan North  wrote:
>
>  Hi George. Thanks for the quick turnaround.
>
>  Results so far:
>
>
> Successfully installed glue, version 0.50.0
>  Installing ri documentation for glue-0.50.0...
>  Installing RDoc documentation for glue-0.50.0...
>  Successfully installed og, version 0.50.0
>  Installing ri documentation for og-0.50.0...
>  While generating documentation for og-0.50.0
>  ... MESSAGE:   Unhandled special: Special: type=33, text="The"
>  ... RDOC args: --ri --op /home/dan/misc/gems/1.8/doc/og-0.50.0/ri --quiet
> lib
>  (continuing with the rest of the installation)
>  Installing RDoc documentation for og-0.50.0...
>  Successfully installed raw, version 0.50.0
>  Installing ri documentation for raw-0.50.0...
>  While generating documentation for raw-0.50.0
>  ... MESSAGE:   Unhandled special: Special: type=33, text="Encapsulates"
>  ... RDOC args: --ri --op
> /home/dan/misc/gems/1.8/doc/raw-0.50.0/ri --quiet lib
>  (continuing with the rest of the installation)
>  Installing RDoc documentation for raw-0.50.0...
>  Successfully installed nitro, version 0.50.0
>  Installing ri documentation for nitro-0.50.0...
>  File not found: vendor
>
>  So I don't have ri or rdoc for raw, nitro or og.
>
>  I ran the blog app and got the following error (error html page attached) :
>
>
> Install XMLSimple for XML input.
>  ERROR: Cannot find configuration file 'conf/debug'
>   INFO: Starting Webrick server in debug mode, listening at 0.0.0.0:9000
>   INFO: Press Ctrl-C to shutdown; Run with --help for options.
>  DEBUG: Compiling 'Post::Controller#index' super-method
>  DEBUG: Rendering '/status_500'
>  DEBUG: Compiling 'Post::Controller#status_500' super-method
>  DEBUG: Compiling 'status_500' view sub-method [format: html]
>  ERROR: Error while handling Post::Controller#index()
>  ERROR: undefined local variable or method `ogmanager' for Post:Class
>
> /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:693:in
> `method_missing'
>
> /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:334:in
> `all'
>    ./app/controller/post.rb:7:in `index'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
> `send'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
> `index___super'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
> `send'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
> `method_missing'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
> `send'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
> `render_action'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
> `send'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
> `handle_context'
>
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:134:in
> `do_GET'
>    /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in
> `__send__'
>    /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'
>    /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 `each'
>    /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/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:57:in
> `start'
>
> /home/dan/misc/gems/1.8/gems/nitro-0.50.0/lib/nitro/application.rb:135:in
> `start'
>    app.rb:22
>    LOGGED FROM:
> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:108:in
> `render_action'
>  Thanks,
>  Dan
>
>
>  George Moschovitis wrote:
>  two more gems...
>
> -g.
>
>
>  ________________________________
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>
>
> Internal Server Error
>  Path: /
>  Reload this page. Go to the referer or the home page.
> undefined local variable or method `ogmanager' for Post:Class
>
>
>
> Request
>
>
> Parameters: {}
>
> Cookies: {}
>
> Headers:
> SERVER_NAME => localhost
> ACCEPT-CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7
> ACCEPT-LANGUAGE => en-gb,en;q=0.5
> PATH_INFO => /index.html
> REMOTE_HOST => 127.0.0.1
> HTTP_ACCEPT_ENCODING => gzip,deflate
> HTTP_USER_AGENT => Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6)
> Gecko/20070827 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
> ACCEPT =>
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> CONNECTION => keep-alive
> SCRIPT_NAME =>
> SERVER_PROTOCOL => HTTP/1.1
> HTTP_ACCEPT_LANGUAGE => en-gb,en;q=0.5
> HTTP_HOST => localhost:9000
> ACCEPT-ENCODING => gzip,deflate
> REMOTE_ADDR => 127.0.0.1
> SERVER_SOFTWARE => WEBrick/1.3.1 (Ruby/1.8.6/2007-06-07)
> HTTP_KEEP_ALIVE => 300
> USER-AGENT => Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6)
> Gecko/20070827 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
> HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7
> REQUEST_URI => /
> SERVER_PORT => 9000
> GATEWAY_INTERFACE => CGI/1.1
> QUERY_STRING =>
> REMOTE_USER =>
> HOST => localhost:9000
> HTTP_ACCEPT =>
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> KEEP-ALIVE => 300
> REQUEST_METHOD => GET
> HTTP_CONNECTION => keep-alive
> Response
>
>
> Headers: {"Content-Type"=>"text/html"}
>
> Cookies: nil
> Session
>
>
> Values: {"RENDERING_ERROR"=>#, "FLASH"=>{}}
>
>  Powered by Nitro version 0.50.0
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From dan at tastapod.com  Tue Sep 18 11:09:51 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 18 Sep 2007 17:09:51 +0200
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: 
References: <46EFBF01.3080807@tastapod.com>			<46EFE6BA.5010104@tastapod.com>
	
Message-ID: <46EFEA3F.4060503@tastapod.com>

All I did was:

    $ tar xzf examples-0.50.0.tgz
    $ cd examples/blog
    $ ruby app.rb

It looks like it created conf/debug.rb and conf/live.rb itself during 
the first run.


George Moschovitis wrote:
> What is this?
>
> Cannot find configuration file 'conf/debug'
>
> is this file missing? have you customized it?
>
> -g.
>
>
>
>
>
> On 9/18/07, Dan North  wrote:
>   
>>  Hi George. Thanks for the quick turnaround.
>>
>>  Results so far:
>>
>>
>> Successfully installed glue, version 0.50.0
>>  Installing ri documentation for glue-0.50.0...
>>  Installing RDoc documentation for glue-0.50.0...
>>  Successfully installed og, version 0.50.0
>>  Installing ri documentation for og-0.50.0...
>>  While generating documentation for og-0.50.0
>>  ... MESSAGE:   Unhandled special: Special: type=33, text="The"
>>  ... RDOC args: --ri --op /home/dan/misc/gems/1.8/doc/og-0.50.0/ri --quiet
>> lib
>>  (continuing with the rest of the installation)
>>  Installing RDoc documentation for og-0.50.0...
>>  Successfully installed raw, version 0.50.0
>>  Installing ri documentation for raw-0.50.0...
>>  While generating documentation for raw-0.50.0
>>  ... MESSAGE:   Unhandled special: Special: type=33, text="Encapsulates"
>>  ... RDOC args: --ri --op
>> /home/dan/misc/gems/1.8/doc/raw-0.50.0/ri --quiet lib
>>  (continuing with the rest of the installation)
>>  Installing RDoc documentation for raw-0.50.0...
>>  Successfully installed nitro, version 0.50.0
>>  Installing ri documentation for nitro-0.50.0...
>>  File not found: vendor
>>
>>  So I don't have ri or rdoc for raw, nitro or og.
>>
>>  I ran the blog app and got the following error (error html page attached) :
>>
>>
>> Install XMLSimple for XML input.
>>  ERROR: Cannot find configuration file 'conf/debug'
>>   INFO: Starting Webrick server in debug mode, listening at 0.0.0.0:9000
>>   INFO: Press Ctrl-C to shutdown; Run with --help for options.
>>  DEBUG: Compiling 'Post::Controller#index' super-method
>>  DEBUG: Rendering '/status_500'
>>  DEBUG: Compiling 'Post::Controller#status_500' super-method
>>  DEBUG: Compiling 'status_500' view sub-method [format: html]
>>  ERROR: Error while handling Post::Controller#index()
>>  ERROR: undefined local variable or method `ogmanager' for Post:Class
>>
>> /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:693:in
>> `method_missing'
>>
>> /home/dan/misc/gems/1.8/gems/og-0.50.0/lib/og/model.rb:334:in
>> `all'
>>    ./app/controller/post.rb:7:in `index'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
>> `send'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/compiler.rb:65:in
>> `index___super'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
>> `send'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/publishable.rb:36:in
>> `method_missing'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
>> `send'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:92:in
>> `render_action'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
>> `send'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter.rb:68:in
>> `handle_context'
>>
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:134:in
>> `do_GET'
>>    /usr/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in
>> `__send__'
>>    /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'
>>    /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 `each'
>>    /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/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/adapter/webrick.rb:57:in
>> `start'
>>
>> /home/dan/misc/gems/1.8/gems/nitro-0.50.0/lib/nitro/application.rb:135:in
>> `start'
>>    app.rb:22
>>    LOGGED FROM:
>> /home/dan/misc/gems/1.8/gems/raw-0.50.0/lib/raw/controller/render.rb:108:in
>> `render_action'
>>  Thanks,
>>  Dan
>>
>>
>>  George Moschovitis wrote:
>>  two more gems...
>>
>> -g.
>>
>>
>>  ________________________________
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>>
>>
>>
>>
>> Internal Server Error
>>  Path: /
>>  Reload this page. Go to the referer or the home page.
>> undefined local variable or method `ogmanager' for Post:Class
>>
>>
>>
>> Request
>>
>>
>> Parameters: {}
>>
>> Cookies: {}
>>
>> Headers:
>> SERVER_NAME => localhost
>> ACCEPT-CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> ACCEPT-LANGUAGE => en-gb,en;q=0.5
>> PATH_INFO => /index.html
>> REMOTE_HOST => 127.0.0.1
>> HTTP_ACCEPT_ENCODING => gzip,deflate
>> HTTP_USER_AGENT => Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6)
>> Gecko/20070827 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
>> ACCEPT =>
>> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>> CONNECTION => keep-alive
>> SCRIPT_NAME =>
>> SERVER_PROTOCOL => HTTP/1.1
>> HTTP_ACCEPT_LANGUAGE => en-gb,en;q=0.5
>> HTTP_HOST => localhost:9000
>> ACCEPT-ENCODING => gzip,deflate
>> REMOTE_ADDR => 127.0.0.1
>> SERVER_SOFTWARE => WEBrick/1.3.1 (Ruby/1.8.6/2007-06-07)
>> HTTP_KEEP_ALIVE => 300
>> USER-AGENT => Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6)
>> Gecko/20070827 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
>> HTTP_ACCEPT_CHARSET => ISO-8859-1,utf-8;q=0.7,*;q=0.7
>> REQUEST_URI => /
>> SERVER_PORT => 9000
>> GATEWAY_INTERFACE => CGI/1.1
>> QUERY_STRING =>
>> REMOTE_USER =>
>> HOST => localhost:9000
>> HTTP_ACCEPT =>
>> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>> KEEP-ALIVE => 300
>> REQUEST_METHOD => GET
>> HTTP_CONNECTION => keep-alive
>> Response
>>
>>
>> Headers: {"Content-Type"=>"text/html"}
>>
>> Cookies: nil
>> Session
>>
>>
>> Values: {"RENDERING_ERROR"=>#, "FLASH"=>{}}
>>
>>  Powered by Nitro version 0.50.0
>> _______________________________________________
>> 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/20070918/9bfc42b4/attachment.html 

From rff_rff at yahoo.it  Tue Sep 18 12:34:29 2007
From: rff_rff at yahoo.it (gabriele renzi)
Date: Tue, 18 Sep 2007 16:34:29 +0000 (UTC)
Subject: [Nitro] Elements and Partials
References: <46EE8870.9080603@robmela.com> 
	
Message-ID: 

On Tue, 18 Sep 2007 13:22:10 +0300, George Moschovitis wrote:

>> was impossible, whereas it is possible to pass variables to rails'
>> partials.
>>
> 
> This is certainly possible:
> 
> 
> class Element
>   def render
>      %{
>      
    index: #{attr :idx}
    
>      }
>   end
> end

well, but I was talking in the context of variables that are not available
until the template is executed. 
I didn't know this was possible now, I'm happy it is so :)



-- 
goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info


From aidan at yoyo.org  Tue Sep 18 14:11:19 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Tue, 18 Sep 2007 19:11:19 +0100
Subject: [Nitro] testable controllers
In-Reply-To: <46EFE338.3030207@tastapod.com>
References: <46EFE338.3030207@tastapod.com>
Message-ID: 

+1 from me.

Aidan

On Sep 18, 2007, at 3:39 PM, Dan North wrote:

> Hi George.
>
> This is a plea from the heart to revert the controller (dispatcher
> method) behaviour to returning a string rather than using multiple  
> print
> statements.
>
> I can test the former simply just by constructing a controller  
> class and
> looking at the result of a method call. The latter requires me to
> subvert the global $stdout, which is just evil in a testing context.
>
> As a developer, if I want to assemble the string in chunks I can do  
> that
> during the method and then return the result at the end, which  
> provides
> the same facility as multiple prints would.
>
> Thanks,
> Dan
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


From george.moschovitis at gmail.com  Tue Sep 18 15:10:42 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Tue, 18 Sep 2007 22:10:42 +0300
Subject: [Nitro] Elements and Partials
In-Reply-To: 
References: <46EE8870.9080603@robmela.com> 
	
	
Message-ID: 

> I didn't know this was possible now, I'm happy it is so :)

it was always possible, now it is more elegant ;-)

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From cwdinfo at gmail.com  Tue Sep 18 19:03:13 2007
From: cwdinfo at gmail.com (s.ross)
Date: Tue, 18 Sep 2007 16:03:13 -0700
Subject: [Nitro] Noob Installation Q
Message-ID: 

Hi--

I have been trying to install Nitro and Og, but have run into all  
sorts of gem conflicts. Most recently, I installed from the 0.50 gems  
sent on this list, and everything goes swimmingly until I do:

gen app foo

which gives me the error:

/opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:304:in  
`report_activate_error': RubyGem version error: glue(0.50.0 not =  
0.41.0) (Gem::LoadError)

This is on OSX 10.4.10 with Ruby 1.8.6 and rubygems 0.9.4.

Is there a way to run these from a local tree (sort of like Edge Rails)?

Thx,

--s

From mvyver at gmail.com  Tue Sep 18 21:39:39 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 11:39:39 +1000
Subject: [Nitro] OG: Howto start debugging from within a spec using
	netbeans....?
Message-ID: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>

Hi,
I'm having trouble getting the debug facility of netbeans to 'work' if
I fire it up while in a spec file....
Specifically when the spec helper does: require 'og', etc, it loads
the test file if that is present....

I can't be alone in wanting to do this... so I'm probably doing
something dumb, or have set up something incorrectly.  Is renaming the
test files that get in the way the only solution?

It's taking me days/hours to find/discover things that I could find
quite quickly if I could step through the code.... _please_ any tips?

Cheers
Mark

From mvyver at gmail.com  Tue Sep 18 22:55:19 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 12:55:19 +1000
Subject: [Nitro] OG: Howto start debugging from within a spec using
	netbeans....?
In-Reply-To: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>
References: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>
Message-ID: <389c43e40709181955r188761d6j12c0e7200f8c4b10@mail.gmail.com>

>
> It's taking me days/hours to find/discover things that I could find
> quite quickly if I could step through the code.... _please_ any tips?

I'm not ruling out the dumb/ignorant explanation :)
But, I've found that renaming the spec files to *_spec.rb solves all
my problems.

In the absense of another solution... can the decision not to use this
extension please be reconsidered - I know it'll probably make
something in the setup/install scripts a real pain

Given spec's are witten in reverse you might like to follow Jim Weirich's post:
http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red

Anyway, it is now nice to be writing a spec, set a break points in the
code, ctl+shift+f6 and proceed to exactly which line of code caused a
problem.

Mark


> Cheers
> Mark
>

From arne at arnebrasseur.net  Wed Sep 19 00:23:33 2007
From: arne at arnebrasseur.net (arne at arnebrasseur.net)
Date: Tue, 18 Sep 2007 21:23:33 -0700 (PDT)
Subject: [Nitro] Noob Installation Q
In-Reply-To: 
References: 
Message-ID: <2725.140.134.35.54.1190175813.squirrel@webmail.arnebrasseur.net>

> Hi--
>
> I have been trying to install Nitro and Og, but have run into all
> sorts of gem conflicts. Most recently, I installed from the 0.50 gems
> sent on this list, and everything goes swimmingly until I do:
>
> gen app foo

Use this:

nitro --create foo

gen is no longer available for 0.50.

(ab)

>
> which gives me the error:
>
> /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:304:in
> `report_activate_error': RubyGem version error: glue(0.50.0 not =
> 0.41.0) (Gem::LoadError)
>
> This is on OSX 10.4.10 with Ruby 1.8.6 and rubygems 0.9.4.
>
> Is there a way to run these from a local tree (sort of like Edge Rails)?
>
> Thx,
>
> --s
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



From rob at robmela.com  Wed Sep 19 00:33:04 2007
From: rob at robmela.com (Robert Mela)
Date: Wed, 19 Sep 2007 00:33:04 -0400
Subject: [Nitro] Submitting HTML formatting through Og Admin
Message-ID: <46F0A680.6070708@robmela.com>

Is there a simple way to get the Og admin part to stop stripping HTML 
from submitted text ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/1d305633/attachment.vcf 

From rmela at rcn.com  Wed Sep 19 01:08:57 2007
From: rmela at rcn.com (Robert Mela)
Date: Wed, 19 Sep 2007 01:08:57 -0400
Subject: [Nitro] Never mind: ( was Re: Submitting HTML formatting through Og
 Admin )
In-Reply-To: <46F0A680.6070708@robmela.com>
References: <46F0A680.6070708@robmela.com>
Message-ID: <46F0AEE9.7010606@rcn.com>

Ah, I see...

raw/lib/raw/util/attr.rb:


        if anno[:class] == String and anno[:unfiltered] != true
          # html filter all strings by default.
          prop_value = prop_value.html_filter
        end

So in my model...

 attr_accessor :body, String, :control => :textarea, :unfiltered => true

Robert Mela wrote:
> Is there a simple way to get the Og admin part to stop stripping HTML 
> from submitted text ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rmela.vcf
Type: text/x-vcard
Size: 160 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/cb461593/attachment.vcf 

From rob at robmela.com  Wed Sep 19 01:42:56 2007
From: rob at robmela.com (Robert Mela)
Date: Wed, 19 Sep 2007 01:42:56 -0400
Subject: [Nitro] Problem getting '<' and '>' into output
In-Reply-To: <46F0AEE9.7010606@rcn.com>
References: <46F0A680.6070708@robmela.com> <46F0AEE9.7010606@rcn.com>
Message-ID: <46F0B6E0.1000709@robmela.com>

I want this text to display in a blog post:

   #include 

I'm saving  this text to the Og model, and it gets to the database with 
the entities intact.

  #include <pthread.h>

However, the entities get translated into '<', '>' when the data is 
rendered in a template.  My workaround is two helper methods -- lt and 
gt that I include in templates as #{lt} and #{gt}. 

Suggestions?

Thanks,

    - Rob

PS:

Why the double CGI.unescape in attr.rb?


        prop_value = *CGI.unescape(prop_value)*

        if anno[:class] == String and anno[:unfiltered] != true
          # html filter all strings by default.
          prop_value = prop_value.html_filter
        end

        set_attr(obj, prop_name, *CGI.unescape(prop_value)*)


However, I want

I've set :unfilterd
Robert Mela wrote:
> Ah, I see...
>
> raw/lib/raw/util/attr.rb:
>
>
>        if anno[:class] == String and anno[:unfiltered] != true
>          # html filter all strings by default.
>          prop_value = prop_value.html_filter
>        end
>
> So in my model...
>
> attr_accessor :body, String, :control => :textarea, :unfiltered => true
>
> Robert Mela wrote:
>> Is there a simple way to get the Og admin part to stop stripping HTML 
>> from submitted text ?
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/7ffd394a/attachment.vcf 

From mvyver at gmail.com  Wed Sep 19 03:10:21 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 17:10:21 +1000
Subject: [Nitro] OG [PATCH]: Avoid setting OGTABLE if already initialized
Message-ID: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>

Scenario: In a spec file, an 'OG class' is present outside of a
describe statement.
Effect: Patch eliminates the following warnings from spec's:
.../usr/src/nitro-repo/script/lib/../../og/lib/og/store/sql.rb:268:
warning: already initialized constant OGTABLE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvdv-20070919-1
Type: application/octet-stream
Size: 65199 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/1e0ed33c/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvdv-20070919-1.tar.gz
Type: application/x-gzip
Size: 17866 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/1e0ed33c/attachment-0001.gz 

From george.moschovitis at gmail.com  Wed Sep 19 03:12:44 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:12:44 +0300
Subject: [Nitro] testable controllers
In-Reply-To: 
References: <46EFE338.3030207@tastapod.com>
	
Message-ID: 

Let me try to explain the reasoning behind the deprecation of this feature:

1. actions are not supposed to generate actual output. Typically you
use templates for this stuff.  This means that there are not many
prints around. This is only useful for simple Nitro examples.

2. consider this example:

def my_action
    ...
    evaluate_a_function_that_accidentally_returns_a_string()
end

some times, you may get a string returned by accident.

3. I wanted to promote the auto-redirect_to_referrer feature (ie, if
there is no output, automatically redirect_to_referrer)

In retrospect, 3. is not that safe, and 1-2 are not serious flaws. So
if more people want the return string feature back, I will bring it
back...


regards,
George.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Wed Sep 19 03:15:01 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:15:01 +0300
Subject: [Nitro] Noob Installation Q
In-Reply-To: 
References: 
Message-ID: 

Please use the gems I posted to this list yesterday, and use

nitro --create foo

-g.

PS: welcome to this list.

On 9/19/07, s.ross  wrote:
> Hi--
>
> I have been trying to install Nitro and Og, but have run into all
> sorts of gem conflicts. Most recently, I installed from the 0.50 gems
> sent on this list, and everything goes swimmingly until I do:
>
> gen app foo
>
> which gives me the error:
>
> /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:304:in
> `report_activate_error': RubyGem version error: glue(0.50.0 not =
> 0.41.0) (Gem::LoadError)
>
> This is on OSX 10.4.10 with Ruby 1.8.6 and rubygems 0.9.4.
>
> Is there a way to run these from a local tree (sort of like Edge Rails)?
>
> Thx,
>
> --s
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Wed Sep 19 03:15:43 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:15:43 +0300
Subject: [Nitro] Never mind: ( was Re: Submitting HTML formatting
	through Og Admin )
In-Reply-To: <46F0AEE9.7010606@rcn.com>
References: <46F0A680.6070708@robmela.com> <46F0AEE9.7010606@rcn.com>
Message-ID: 

please, can you add this to  oxywtf?

-g.

On 9/19/07, Robert Mela  wrote:
> Ah, I see...
>
> raw/lib/raw/util/attr.rb:
>
>
>         if anno[:class] == String and anno[:unfiltered] != true
>           # html filter all strings by default.
>           prop_value = prop_value.html_filter
>         end
>
> So in my model...
>
>  attr_accessor :body, String, :control => :textarea, :unfiltered => true
>
> Robert Mela wrote:
> > Is there a simple way to get the Og admin part to stop stripping HTML
> > from submitted text ?
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Wed Sep 19 03:19:54 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:19:54 +0300
Subject: [Nitro] testing views
In-Reply-To: <46EFDD9D.5080106@tastapod.com>
References: <46EFDD9D.5080106@tastapod.com>
Message-ID: 

I am sorry, the testing infrastructure in 0.50.0 is not updated to be
compatible with the latest changes. This is in my todo list, but it
will take a bit more time.

The sad truth is that at the moment there are only two really active
developers on this project (me and Tom Sawyer of facets fame) and our
time is limited. I am working full time on Nitro these days so things
are slowly improving. I am sure you can witness this in the increaded
volume of this mailing list.

be patient,
George.




On 9/18/07, Dan North  wrote:
> Hi there.
>
> I ran a BDD tutorial at RailsConf on a rails app, and I'm trying to redo
> it in nitro to present a side-by-side example.
>
> I'm using 0.41.0 and I don't know how to test the output of a view in
> isolation.
>
> What I want to do is something like:
>
> - set up some @properties
> - invoke rendering on a .xhtml view (ideally by just passing the view
> name to something)
> - get the xhtml result as a string (or DOM) that I can verify using xpath
>
> Any ideas?
>
> Thanks,
> Dan
>
> ps. I found the TestCase mixin. Any reason why you're hacking
> Test::Unit::TestCase rather than defining a NitroTestCase subclass?
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Wed Sep 19 03:27:36 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:27:36 +0300
Subject: [Nitro] OG [PATCH]: Avoid setting OGTABLE if already initialized
In-Reply-To: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>
References: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>
Message-ID: 

please be more careful with patches... after I applied this, things
stopped working.

-g.

On 9/19/07, Mark Van De Vyver  wrote:
> Scenario: In a spec file, an 'OG class' is present outside of a
> describe statement.
> Effect: Patch eliminates the following warnings from spec's:
> .../usr/src/nitro-repo/script/lib/../../og/lib/og/store/sql.rb:268:
> warning: already initialized constant OGTABLE
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From aidan at yoyo.org  Wed Sep 19 03:29:44 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Wed, 19 Sep 2007 08:29:44 +0100 (BST)
Subject: [Nitro] testing views
In-Reply-To: 
References: <46EFDD9D.5080106@tastapod.com>
	
Message-ID: <15771.192.193.221.142.1190186984.squirrel@yoyo.org>

> I am sorry, the testing infrastructure in 0.50.0 is not updated to be
> compatible with the latest changes. This is in my todo list, but it
> will take a bit more time.
>
> The sad truth is that at the moment there are only two really active
> developers on this project (me and Tom Sawyer of facets fame) and our
> time is limited. I am working full time on Nitro these days so things
> are slowly improving. I am sure you can witness this in the increaded
> volume of this mailing list.

George,

Is the number of developers through choice or circumstance?  If the
latter, is there anything we can do to encourage more people to help out? 
For example, you mention you have a TODO list - is it on the web?  Can
some of us pick up any of it and do it?

Aidan

From george.moschovitis at gmail.com  Wed Sep 19 03:30:54 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:30:54 +0300
Subject: [Nitro] OG [PATCH]: Avoid setting OGTABLE if already initialized
In-Reply-To: 
References: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>
	
Message-ID: 

I changed the code to use defined? like this:

      klass.const_set "OGTABLE", table(klass) unless defined? klass::OGTABLE

now everything is ok.

thanks for spotting this (and your attention to detail)

regards,
George.


On 9/19/07, George Moschovitis  wrote:
> please be more careful with patches... after I applied this, things
> stopped working.
>
> -g.
>
> On 9/19/07, Mark Van De Vyver  wrote:
> > Scenario: In a spec file, an 'OG class' is present outside of a
> > describe statement.
> > Effect: Patch eliminates the following warnings from spec's:
> > .../usr/src/nitro-repo/script/lib/../../og/lib/og/store/sql.rb:268:
> > warning: already initialized constant OGTABLE
> >
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> >
> >
>
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Wed Sep 19 03:34:45 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 10:34:45 +0300
Subject: [Nitro] testing views
In-Reply-To: <15771.192.193.221.142.1190186984.squirrel@yoyo.org>
References: <46EFDD9D.5080106@tastapod.com>
	
	<15771.192.193.221.142.1190186984.squirrel@yoyo.org>
Message-ID: 

> Is the number of developers through choice or circumstance?  If the
> latter, is there anything we can do to encourage more people to help out?
> For example, you mention you have a TODO list - is it on the web?  Can
> some of us pick up any of it and do it?

Both,

we don't need 1000  developers like Rails (the snr will reach zero)
but obviously we need 2-3 more active developers.

You can find the TODO list here:

nitro/doc/TODO.

If you have some time to work on Nitro/Og, I can post some important
things to do on this list tomorrow.

-g.



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From mvyver at gmail.com  Wed Sep 19 03:41:36 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 17:41:36 +1000
Subject: [Nitro] OG [PATCH]: Avoid setting OGTABLE if already initialized
In-Reply-To: 
References: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>
	
Message-ID: <389c43e40709190041n7b78479frc14f8a308f424a40@mail.gmail.com>

> please be more careful with patches... after I applied this, things
> stopped working.

Apologies, I'm in the middle of trying to iron out several things...
I think I should hold off on non-critical patches until this adapter
is working - it looks like it'll require several changes and what
shape they take will probably only be clear once it is fully
implemented, then I can poat a patch and a test.

MV

> -g.
>
> On 9/19/07, Mark Van De Vyver  wrote:
> > Scenario: In a spec file, an 'OG class' is present outside of a
> > describe statement.
> > Effect: Patch eliminates the following warnings from spec's:
> > .../usr/src/nitro-repo/script/lib/../../og/lib/og/store/sql.rb:268:
> > warning: already initialized constant OGTABLE
> >
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> >
> >
>
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
>

From mvyver at gmail.com  Wed Sep 19 03:47:18 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 17:47:18 +1000
Subject: [Nitro] testing views
In-Reply-To: 
References: <46EFDD9D.5080106@tastapod.com>
	
	<15771.192.193.221.142.1190186984.squirrel@yoyo.org>
	
Message-ID: <389c43e40709190047h70ffe4c6nb726185cce660bd0@mail.gmail.com>

On 9/19/07, George Moschovitis  wrote:
> > Is the number of developers through choice or circumstance?  If the
> > latter, is there anything we can do to encourage more people to help out?
> > For example, you mention you have a TODO list - is it on the web?  Can
> > some of us pick up any of it and do it?
>
> Both,
>
> we don't need 1000  developers like Rails (the snr will reach zero)
> but obviously we need 2-3 more active developers.
>
> You can find the TODO list here:
>
> nitro/doc/TODO.

Activiating the tracker may help too, people can post issues, others
can grab issues and post patches.
Also I imagine that once the spec's are more comprehensive/complete
it'll be easier to check a patch doesn't 'blow-things-up', like my
last patch ;)

Cheers
Mark


> If you have some time to work on Nitro/Og, I can post some important
> things to do on this list tomorrow.
>
> -g.
>
>
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From mvyver at gmail.com  Wed Sep 19 03:55:13 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 17:55:13 +1000
Subject: [Nitro] OG [PATCH]: Avoid setting OGTABLE if already initialized
In-Reply-To: 
References: <389c43e40709190010i42c16700he8ee82b0f5848699@mail.gmail.com>
	
	
Message-ID: <389c43e40709190055q4520dba6q41c9fff6b5c359d6@mail.gmail.com>

On 9/19/07, George Moschovitis  wrote:
> I changed the code to use defined? like this:
>
>       klass.const_set "OGTABLE", table(klass) unless defined? klass::OGTABLE
>
> now everything is ok.

Thanks that also removes the error message - still leaves me with a
locked db. Now, where is that happening.... ;)

fingers crossed.
Mark

> thanks for spotting this (and your attention to detail)
>
> regards,
> George.
>
>
> On 9/19/07, George Moschovitis  wrote:
> > please be more careful with patches... after I applied this, things
> > stopped working.
> >
> > -g.
> >
> > On 9/19/07, Mark Van De Vyver  wrote:
> > > Scenario: In a spec file, an 'OG class' is present outside of a
> > > describe statement.
> > > Effect: Patch eliminates the following warnings from spec's:
> > > .../usr/src/nitro-repo/script/lib/../../og/lib/og/store/sql.rb:268:
> > > warning: already initialized constant OGTABLE
> > >
> > > _______________________________________________
> > > Nitro-general mailing list
> > > Nitro-general at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/nitro-general
> > >
> > >
> >
> >
> > --
> > http://www.me.gr
> > http://phidz.com
> > http://blog.gmosx.com
> > http://cull.gr
> > http://www.joy.gr
> > http://nitroproject.org
> >
>
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
>

From aidan at yoyo.org  Wed Sep 19 03:57:25 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Wed, 19 Sep 2007 08:57:25 +0100 (BST)
Subject: [Nitro] testing views
In-Reply-To: <389c43e40709190047h70ffe4c6nb726185cce660bd0@mail.gmail.com>
References: <46EFDD9D.5080106@tastapod.com>
	
	<15771.192.193.221.142.1190186984.squirrel@yoyo.org>
	
	<389c43e40709190047h70ffe4c6nb726185cce660bd0@mail.gmail.com>
Message-ID: <29825.199.67.138.153.1190188645.squirrel@yoyo.org>

> On 9/19/07, George Moschovitis  wrote:
>> > Is the number of developers through choice or circumstance?  If the
>> > latter, is there anything we can do to encourage more people to help
>> out?
>> > For example, you mention you have a TODO list - is it on the web?  Can
>> > some of us pick up any of it and do it?
>>
>> Both,
>>
>> we don't need 1000  developers like Rails (the snr will reach zero)
>> but obviously we need 2-3 more active developers.
>>
>> You can find the TODO list here:
>>
>> nitro/doc/TODO.
>
> Activiating the tracker may help too, people can post issues, others
> can grab issues and post patches.
> Also I imagine that once the spec's are more comprehensive/complete
> it'll be easier to check a patch doesn't 'blow-things-up', like my
> last patch ;)

I definitely agree with this one.  I might be able to convince Dan North
to meet up with me one evening and the two of us pair up to significantly
bolster the specs.  However, I know Dan's free-time is almost unicorn-like
in its availability :-)

Dan?  Go on, you know you want to ...

Aidan

From dan at tastapod.com  Wed Sep 19 04:10:12 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 19 Sep 2007 10:10:12 +0200
Subject: [Nitro] testing views
In-Reply-To: 
References: <46EFDD9D.5080106@tastapod.com>
	
Message-ID: <46F0D964.8010909@tastapod.com>

No need to apologise! I appreciate all your hard work George, and I'm 
very glad to hear you're able to work full time on nitro.


George Moschovitis wrote:
> I am sorry, the testing infrastructure in 0.50.0 is not updated to be
> compatible with the latest changes. This is in my todo list, but it
> will take a bit more time.
>
> The sad truth is that at the moment there are only two really active
> developers on this project (me and Tom Sawyer of facets fame) and our
> time is limited. I am working full time on Nitro these days so things
> are slowly improving. I am sure you can witness this in the increaded
> volume of this mailing list.
>
> be patient,
> George.
>
>
>
>
> On 9/18/07, Dan North  wrote:
>   
>> Hi there.
>>
>> I ran a BDD tutorial at RailsConf on a rails app, and I'm trying to redo
>> it in nitro to present a side-by-side example.
>>
>> I'm using 0.41.0 and I don't know how to test the output of a view in
>> isolation.
>>
>> What I want to do is something like:
>>
>> - set up some @properties
>> - invoke rendering on a .xhtml view (ideally by just passing the view
>> name to something)
>> - get the xhtml result as a string (or DOM) that I can verify using xpath
>>
>> Any ideas?
>>
>> Thanks,
>> Dan
>>
>> ps. I found the TestCase mixin. Any reason why you're hacking
>> Test::Unit::TestCase rather than defining a NitroTestCase subclass?
>> _______________________________________________
>> 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/20070919/d27386b4/attachment.html 

From george.moschovitis at gmail.com  Wed Sep 19 04:17:09 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 11:17:09 +0300
Subject: [Nitro] testing views
In-Reply-To: <46F0D964.8010909@tastapod.com>
References: <46EFDD9D.5080106@tastapod.com>
	
	<46F0D964.8010909@tastapod.com>
Message-ID: 

>  No need to apologise! I appreciate all your hard work George, and I'm
very
> glad to hear you're able to work full time on nitro.

Thanks, I just wanted to say publicly that Tom (Trans) is also responsible
for huge parts of the Nitro framework. Facets is really the corner-stone of
Nitro.

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/edb83186/attachment.html 

From t_leitner at gmx.at  Wed Sep 19 04:19:07 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Wed, 19 Sep 2007 10:19:07 +0200
Subject: [Nitro] Difference between /account and /account/ ???
In-Reply-To: 
References: 
	
Message-ID: <8EEF23BD-1BF7-4977-90E3-01BFF7889229@gmx.at>

On 18.09.2007, at 15:47, George Moschovitis wrote:
> Ok, I think  I fixed that, check out the repo version.

Yep, it works now. Thanks!

Bye,
   Thomas

From john at oxyliquit.de  Wed Sep 19 04:26:16 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 10:26:16 +0200
Subject: [Nitro] Noob Installation Q
In-Reply-To: 
References: 
Message-ID: 

Hi,

welcome to the list.

> Is there a way to run these from a local tree (sort of like Edge Rails)?

As this wasn't answered by my predecessors:

A 'local' installation can be done by just using the development version
of Nitro.  This is done by getting the Darcs repository or the snapshot
provided by Arne.

http://www.arnebrasseur.net/2007/07/01/the-daily-nitro/en/

It comes with an 'how to use' as well.

I hope that helps,

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Wed Sep 19 04:34:30 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 10:34:30 +0200
Subject: [Nitro] OG: Howto start debugging from within a spec using
	netbeans....?
In-Reply-To: <389c43e40709181955r188761d6j12c0e7200f8c4b10@mail.gmail.com>
References: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>
	<389c43e40709181955r188761d6j12c0e7200f8c4b10@mail.gmail.com>
Message-ID: 

Hi,

>> It's taking me days/hours to find/discover things that I could find
>> quite quickly if I could step through the code.... _please_ any tips?
>
> I'm not ruling out the dumb/ignorant explanation :)
> But, I've found that renaming the spec files to *_spec.rb solves all
> my problems.
>
> In the absense of another solution... can the decision not to use this
> extension please be reconsidered - I know it'll probably make
> something in the setup/install scripts a real pain

I don't think so, I even was for staying with tc_* for the specs, but
*_spec.rb is good too, makes imo a good distinction between helpers and
real specs.  It probably also makes the rakefile easier as it just has
to react on those with a glob Dir['test/**/*_spec.rb'].

> Given spec's are witten in reverse you might like to follow Jim Weirich's post:
> http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red

I already used the RSpec mocks, I think it'd be good also not to depend
on too many libraries just for testing, but that's just me again.

> Anyway, it is now nice to be writing a spec, set a break points in the
> code, ctl+shift+f6 and proceed to exactly which line of code caused a
> problem.

NetBeans seems to be getting quite nice... I might consider this once in
a while.  That I need a real breakpoint is however _very_ seldom, due to
whatever reason.  I use 'real' debuggers on a daily basis when I'm coding C...

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Wed Sep 19 04:41:21 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 10:41:21 +0200
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFEA3F.4060503@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
	
	
	<46EFE6BA.5010104@tastapod.com>
	
	<46EFEA3F.4060503@tastapod.com>
Message-ID: 

Hi,

> All I did was:
>   $ tar xzf examples-0.50.0.tgz
>    $ cd examples/blog
>    $ ruby app.rb
>It looks like it created conf/debug.rb and conf/live.rb itself during the first run.

I don't know about that, but that error message:

>  ERROR: undefined local variable or method `ogmanager' for Post:Class

says the following:

`Og.start` did not get called or got interrupted and thus the Post class
did not get 'enchanted'.

The database configuration might be wrong or non-existant, `Og.start` call
might be non-existant.

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Wed Sep 19 04:48:20 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 10:48:20 +0200
Subject: [Nitro] testable controllers
In-Reply-To: 
References: <46EFE338.3030207@tastapod.com>
	
	
Message-ID: 

Hi,

> In retrospect, 3. is not that safe, and 1-2 are not serious flaws. So
> if more people want the return string feature back, I will bring it
> back...

I liked the return string method because:

ruby -rubygems -rnitro -e 'class C; def index; "Hello World!"; end; end; Nitro.start(C)'

I know it's not that useful when you write bigger actions, but I
still use it for small 'communication', where I return JSON from
an action or simply return 'error', 'success' as API.
For those just using the 'return string' is the most easy and
most elegant looking method.

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From george.moschovitis at gmail.com  Wed Sep 19 05:00:36 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 12:00:36 +0300
Subject: [Nitro] testable controllers
In-Reply-To: 
References: <46EFE338.3030207@tastapod.com>
	
	
	
Message-ID: 

Ok,

I re-enabled the old behaviour. Please pull the latest repo code, and let me
know if everything works as expected.

thanks,
-g.

On 9/19/07, Jonathan Buch  wrote:
>
> Hi,
>
> > In retrospect, 3. is not that safe, and 1-2 are not serious flaws. So
> > if more people want the return string feature back, I will bring it
> > back...
>
> I liked the return string method because:
>
> ruby -rubygems -rnitro -e 'class C; def index; "Hello World!"; end; end;
> Nitro.start(C)'
>
> I know it's not that useful when you write bigger actions, but I
> still use it for small 'communication', where I return JSON from
> an action or simply return 'error', 'success' as API.
> For those just using the 'return string' is the most easy and
> most elegant looking method.
>
> Jo
>
> --
> Feel the love
> http://pinkjuice.com/pics/ruby.png
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/5ea2c149/attachment.html 

From john at oxyliquit.de  Wed Sep 19 05:04:21 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 11:04:21 +0200
Subject: [Nitro] OG vs Active Record
In-Reply-To: <389c43e40708231642n162cbfc9k114630093b0ea81c@mail.gmail.com>
References: <389c43e40708161949u2781f25x11d916169056f82f@mail.gmail.com>
	 <46C9CC4C.6070702@robmela.com>
	<023001c7e356$3293d430$6442a8c0@musicbox>
	
	<389c43e40708221842h3ba11f04yd2249d12e6e8563a@mail.gmail.com>
	
	<389c43e40708231642n162cbfc9k114630093b0ea81c@mail.gmail.com>
Message-ID: 

Hi,

>> Well, the ORM can't go around 'guessing' your intentions.  There must
>> be a clever way to tell the ORM what exactly you need.  Best is, for
>> one purpose only 1 query, not 250.
>
> Sure, by adopting some conventions the chances that OG 'gets it right'
> are better.  Correct? - I'm assuming Nitro/OG adopt the preference for
> convention over configuration?

I would have to think about that.

ActiveRecord is said to be all about 'convention over configuration'.
AR uses conventions to look up 'stuff' in the database.  Og uses
a kind of 'configuration' to create that database to begin with.

That said, I'm not sure at all if Og schema creation is 'configuration'.

>> For more sophisticated SQL there is just more information needed, and
>> where does that information come from if not from the programmer.
>
> I may be wrong but my current understanding is that OG could
> eventually 'acquire' some of that information from the database/or OGs
> managed objects and their inter-relations.  It wouldn't always be
> optimal, but it could get quite sophisticated - right?

Og has all information the database has.  It knows the DB, its managed
objects and their relations.  It doesn't need to ask the DB for that
kind of information.  In fact, Og created the DB with that knowledge.  :P

If you come up with information which helps to create more performant
queries automatically, shoot.  The guys from `sequel` have a few very
nice sql-creation routines.  (A few of us[1] even had the idea of using
sequel to write an even better Og...)  But I'm off the track.

What I mean is:

How can we aggregate Og-Models in a way that is non-obstrusive, elegant
and performant with the information we have?

Jo

[1] #nitro at irc.freenode.net
-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Wed Sep 19 05:13:45 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 11:13:45 +0200
Subject: [Nitro] testing views
In-Reply-To: 
References: <46EFDD9D.5080106@tastapod.com>
	
	<15771.192.193.221.142.1190186984.squirrel@yoyo.org>
	
Message-ID: 

Hi,

>> Is the number of developers through choice or circumstance?  If the
>> latter, is there anything we can do to encourage more people to help out?
>> For example, you mention you have a TODO list - is it on the web?  Can
>> some of us pick up any of it and do it?

> we don't need 1000  developers like Rails (the snr will reach zero)
> but obviously we need 2-3 more active developers.

LOL, indeed.

> If you have some time to work on Nitro/Og, I can post some important
> things to do on this list tomorrow.

IMO not _some_, I would say exactly 1 thing:

* Specs

We had agreed months ago that the best course of action would be to place
Nitro on stable 'feet' again and only then proceed to add new features.
Now it's kind of 'history repeating itself'.

Yes yes I'm not doing much myself right now, but I make up for it by being
the most persistent guy ever.  ;)

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From george.moschovitis at gmail.com  Wed Sep 19 05:19:33 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 12:19:33 +0300
Subject: [Nitro] testing views
In-Reply-To: 
References: <46EFDD9D.5080106@tastapod.com>
	
	<15771.192.193.221.142.1190186984.squirrel@yoyo.org>
	
	
Message-ID: 

>
> * Specs
>

You got it ;-)

-g.


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/a6604e37/attachment.html 

From john at oxyliquit.de  Wed Sep 19 05:22:54 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 19 Sep 2007 11:22:54 +0200
Subject: [Nitro] [PATCH] RDoc task / dispatcher bugfix / tutorial start
In-Reply-To: <46EFD84A.20208@arnebrasseur.net>
References: <46EFD84A.20208@arnebrasseur.net>
Message-ID: 

Hi,

I think your post here got slightly ignored.  ;)

* Make less topics per post :P


Anyway, as I told you on irc[1], I like the tutorial, it looks like
it's going to be useful.  I especially like the usage of irb, one
can't promote irb enough.  :P

Jo
[1] #nitro at irc.freenode.net

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From george.moschovitis at gmail.com  Wed Sep 19 05:26:09 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 12:26:09 +0300
Subject: [Nitro] [PATCH] RDoc task / dispatcher bugfix / tutorial start
In-Reply-To: 
References: <46EFD84A.20208@arnebrasseur.net> 
Message-ID: 

Not ignored, it is *greatly appreciated*! I just need to find some time to
look over it.

Many many thanks Arne!!

-g.

On 9/19/07, Jonathan Buch  wrote:
>
> Hi,
>
> I think your post here got slightly ignored.  ;)
>
> * Make less topics per post :P
>
>
> Anyway, as I told you on irc[1], I like the tutorial, it looks like
> it's going to be useful.  I especially like the usage of irb, one
> can't promote irb enough.  :P
>
> Jo
> [1] #nitro at irc.freenode.net
>
> --
> Feel the love
> http://pinkjuice.com/pics/ruby.png
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/f38b72f0/attachment.html 

From mvyver at gmail.com  Wed Sep 19 05:42:37 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 19:42:37 +1000
Subject: [Nitro] OG: Howto start debugging from within a spec using
	netbeans....?
In-Reply-To: 
References: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>
	<389c43e40709181955r188761d6j12c0e7200f8c4b10@mail.gmail.com>
	
Message-ID: <389c43e40709190242l42b06803xcbff717435d23deb@mail.gmail.com>

> >
> > In the absense of another solution... can the decision not to use this
> > extension please be reconsidered - I know it'll probably make
> > something in the setup/install scripts a real pain
>
> I don't think so, I even was for staying with tc_* for the specs, but
> *_spec.rb is good too, makes imo a good distinction between helpers and
> real specs.  It probably also makes the rakefile easier as it just has
> to react on those with a glob Dir['test/**/*_spec.rb'].

At this point I don't mind what they are called.
Really, it sounds like this is a netbeans only behavior?
Never mind debugging it's very useful to 'walk the code path' to learn
where, how (and maybe) why things are done.
Given all the enchanting overloading and calls to super that go on it
isn't a trivial exercise to work all this out :)

> > Given spec's are witten in reverse you might like to follow Jim Weirich's post:
> > http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red
>
> I already used the RSpec mocks, I think it'd be good also not to depend
> on too many libraries just for testing, but that's just me again.

Point taken.

> > Anyway, it is now nice to be writing a spec, set a break points in the
> > code, ctl+shift+f6 and proceed to exactly which line of code caused a
> > problem.
>
> NetBeans seems to be getting quite nice... I might consider this once in
> a while.  That I need a real breakpoint is however _very_ seldom, due to
> whatever reason.  I use 'real' debuggers on a daily basis when I'm coding C...

I depend on the debugger, to learn if not to debug :)

Mark

> --
> Feel the love
> http://pinkjuice.com/pics/ruby.png
>

From mvyver at gmail.com  Wed Sep 19 05:48:02 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 19:48:02 +1000
Subject: [Nitro] [PATCH] RDoc task / dispatcher bugfix / tutorial start
In-Reply-To: 
References: <46EFD84A.20208@arnebrasseur.net> 
	
Message-ID: <389c43e40709190248s57eb1c1w31c61ac89e928001@mail.gmail.com>

Yep, nice work :)


On 9/19/07, George Moschovitis  wrote:
> Not ignored, it is *greatly appreciated*! I just need to find some time to
> look over it.
>
> Many many thanks Arne!!
>
> -g.
>
>
> On 9/19/07, Jonathan Buch  wrote:
> > Hi,
> >
> > I think your post here got slightly ignored.  ;)
> >
> > * Make less topics per post :P
> >
> >
> > Anyway, as I told you on irc[1], I like the tutorial, it looks like
> > it's going to be useful.  I especially like the usage of irb, one
> > can't promote irb enough.  :P
> >
> > Jo
> > [1] #nitro at irc.freenode.net
> >
> > --
> > Feel the love
> > http://pinkjuice.com/pics/ruby.png
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> >
>
>
>
> --
> http://www.me.gr
> http://phidz.com
>  http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From aidan at yoyo.org  Wed Sep 19 07:55:10 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Wed, 19 Sep 2007 12:55:10 +0100 (BST)
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <46EFEA3F.4060503@tastapod.com>
References: <46EFBF01.3080807@tastapod.com>
	
	
	<46EFE6BA.5010104@tastapod.com>
	
	<46EFEA3F.4060503@tastapod.com>
Message-ID: <30182.192.193.221.204.1190202910.squirrel@yoyo.org>

> All I did was:
>
>     $ tar xzf examples-0.50.0.tgz
>     $ cd examples/blog
>     $ ruby app.rb
>
> It looks like it created conf/debug.rb and conf/live.rb itself during
> the first run.

Having experienced the exact same problem, here's the solution.

1) install tmail (http://i.loveruby.net/en/projects/tmail/)
2) install uuidtools gem (a dependency in all likelihood)
2) edit your conf/debug.rb so that it has the correct parameters for your
database

That should do it.

I don't have darcs on this computer, but I've created a "fix" which just
reports the correct error message.

Change line 168 of nitro/application.rb to read:
     error "Unable to load config file '#{conf_file}' - #{ex}"

It was reporting that it couldn't find it, when in actuality it could but
it couldn't *load* it because of an unmet dependency on tmail.

Some further issues I ran into:
  * Line 31 of og/adapter/postgresql.rb - got a FATAL when trying to set
the "--min_client_messages=WARNING" parameter.  This is on cygwin, so it
may be a platform specific problem.  Changing that parameter to nil
stopped the crash.
  * another cygwin issue - uuidtools craps out trying to get the MAC
address - creating a symlink like this fixes it:
    $ ln -s "/c/WINNT/system32/ipconfig.exe" /usr/sbin/ipconfig

Hope this is all of some use to someone :-)

Aidan

From mvyver at gmail.com  Wed Sep 19 09:19:53 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 23:19:53 +1000
Subject: [Nitro] OG RFC: Catching an early/fatal exception.
Message-ID: <389c43e40709190619h319932b4s20ced491bf899178@mail.gmail.com>

Hi Devs,

George, now you'll understand why I had no idea about what the effect
of that last patch was :)
Also, try and uncover this without a reasonable debugger :)

Scenario:
You're writing a spec, an Og object is defined at the same 'level' as
the describe's.  'Og.start' is run.
The 'query' call in the first call to sql.rb:create_field_map,
generates an exception.
NOTE: We are within the 'unless map =
klass.instance_variable_get("@field_map")' branch
sql.rb:handle_sql_exception() is called and a new StoreException is raised.

Problem:
That StoreException is never caught.
The Og.start returns silently.
There is still a connection open to the DB backend, the DB backend is untouched.
manager.rb:put_store is entered, @pool is undefined, and it is from
_here_ that we return to og.rb:start where the exception is _logged_,
but not raised.

So we've seen a fatal error, the spec never receives an exception -
just the Og.start returning 'nil', with a DB connection open and
classes still 'managed'.

Your hint that something is not right might be a later exception:
Error code:
Error message: database is locked(database is locked)

And off you go on that tangent :)
Anyway, I digress.....

Questions:
1) Where should these exceptions be handled?
There are three places this exception could be handled:
 a) sql.rb:handle_sql_exception
 b) sql.rb:create_field_map
 c) manager.rb:put_store
 d) both a) and b)

Votes? Instructions?

2) What should be done with the DB connection and the manged classes?
>From my understanding, because
'klass.instance_variable_get("@field_map")' returned nil/false in
sql.rb:create_field_map we should really shutdown the DB connection,
unmanage the classes, and scream blue-murder.  The unmanage classes
step is because I think Og's manger doesn't like being given the same
class twice - but this might be an impression left from the OGTABLE
warning just patched?  Anyway, safety first, and I'd vote for
something like the following somewhere (where?) in 1 d):
        if manager.close_store == nil && manager.unmanage_classes == []
          true
        else
          raise 
        end

Comments _please_

Mark

From mvyver at gmail.com  Wed Sep 19 09:25:03 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Wed, 19 Sep 2007 23:25:03 +1000
Subject: [Nitro] OG: Howto start debugging from within a spec using
	netbeans....?
In-Reply-To: <389c43e40709190242l42b06803xcbff717435d23deb@mail.gmail.com>
References: <389c43e40709181839y86910abqe3dd0902ee54a7de@mail.gmail.com>
	<389c43e40709181955r188761d6j12c0e7200f8c4b10@mail.gmail.com>
	
	<389c43e40709190242l42b06803xcbff717435d23deb@mail.gmail.com>
Message-ID: <389c43e40709190625l67fe925ft2a5204e79b647254@mail.gmail.com>

> > I don't think so, I even was for staying with tc_* for the specs, but
> > *_spec.rb is good too, makes imo a good distinction between helpers and
> > real specs.  It probably also makes the rakefile easier as it just has
> > to react on those with a glob Dir['test/**/*_spec.rb'].
>
> At this point I don't mind what they are called.
> Really, it sounds like this is a netbeans only behavior?

Yep, I've confirmed this is a netbeans bug, and it has been logged (in
case you want to follow):

http://www.netbeans.org/nonav/issues/show_bug.cgi?id=115992

They have nightlies available, so I hope for a quick fix :)

Mark


> Never mind debugging it's very useful to 'walk the code path' to learn
> where, how (and maybe) why things are done.
> Given all the enchanting overloading and calls to super that go on it
> isn't a trivial exercise to work all this out :)
>
> > > Given spec's are witten in reverse you might like to follow Jim Weirich's post:
> > > http://onestepback.org/index.cgi/Tech/Ruby/FlexMockAndFluidDynamics.red
> >
> > I already used the RSpec mocks, I think it'd be good also not to depend
> > on too many libraries just for testing, but that's just me again.
>
> Point taken.
>
> > > Anyway, it is now nice to be writing a spec, set a break points in the
> > > code, ctl+shift+f6 and proceed to exactly which line of code caused a
> > > problem.
> >
> > NetBeans seems to be getting quite nice... I might consider this once in
> > a while.  That I need a real breakpoint is however _very_ seldom, due to
> > whatever reason.  I use 'real' debuggers on a daily basis when I'm coding C...
>
> I depend on the debugger, to learn if not to debug :)
>
> Mark
>
> > --
> > Feel the love
> > http://pinkjuice.com/pics/ruby.png
> >
>

From george.moschovitis at gmail.com  Wed Sep 19 09:52:52 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 16:52:52 +0300
Subject: [Nitro] [Facets]
Message-ID: 

Tom,

I changed facets/core/string/brief.rb a little bit...

-g.



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/41462cde/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brief.rb
Type: application/x-ruby
Size: 873 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070919/41462cde/attachment.bin 

From transfire at gmail.com  Wed Sep 19 10:42:37 2007
From: transfire at gmail.com (Trans)
Date: Wed, 19 Sep 2007 14:42:37 -0000
Subject: [Nitro] [Facets]
In-Reply-To: 
References: 
Message-ID: <1190212957.844715.103880@o80g2000hse.googlegroups.com>



On Sep 19, 6:52 am, "George Moschovitis"
 wrote:
> Tom,
>
> I changed facets/core/string/brief.rb a little bit...

How so?

T.


From cwdinfo at gmail.com  Wed Sep 19 12:17:38 2007
From: cwdinfo at gmail.com (s.ross)
Date: Wed, 19 Sep 2007 09:17:38 -0700
Subject: [Nitro] Noob Installation Q
In-Reply-To: 
References: 
	
Message-ID: <950931A3-F1BD-4EEB-B97F-F0DCE9CECE85@gmail.com>

Ahhhhhhh... Good! Thank you very much, indeed. Is there a recent Web  
page or something where I can find this stuff? I'm (again) stuck  
because when I create a simple model and then browse to:

http://localhost:9000

I get the nitro welcome screen.

http://localhost:9000/admin and it hangs.

Was this feature removed?

I'd be happy to record the experience for posterity (or other new  
adopters :)

Thanks,

--steve


On Sep 19, 2007, at 12:15 AM, George Moschovitis wrote:

> Please use the gems I posted to this list yesterday, and use
>
> nitro --create foo
>
> -g.
>
> PS: welcome to this list.
>
> On 9/19/07, s.ross  wrote:
>> Hi--
>>
>> I have been trying to install Nitro and Og, but have run into all
>> sorts of gem conflicts. Most recently, I installed from the 0.50 gems
>> sent on this list, and everything goes swimmingly until I do:
>>
>> gen app foo
>>
>> which gives me the error:
>>
>> /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:304:in
>> `report_activate_error': RubyGem version error: glue(0.50.0 not =
>> 0.41.0) (Gem::LoadError)
>>
>> This is on OSX 10.4.10 with Ruby 1.8.6 and rubygems 0.9.4.
>>
>> Is there a way to run these from a local tree (sort of like Edge  
>> Rails)?
>>
>> Thx,
>>
>> --s
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>>
>
>
> -- 
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


From transfire at gmail.com  Wed Sep 19 16:26:11 2007
From: transfire at gmail.com (Trans)
Date: Wed, 19 Sep 2007 20:26:11 -0000
Subject: [Nitro] TMail in Nitro
In-Reply-To: 
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
Message-ID: <1190233571.297474.181280@o80g2000hse.googlegroups.com>



On Sep 13, 12:44 am, "George Moschovitis"
 wrote:
> > I would contact Minero Aoki and ask him what the status of that
> > project is. It looks like it hasn't been updated since 2004. You never
> > know, Minero might suggest an alternative (have you looked for any,
> > btw?). Or he might be willing to turn it over to you if you want to
> > revive it. I'd be happy to set it up as a new project in that case.
>
> I think it makes more sense that you setup this as a facets sub-project.
> This is of more general usability than web applications (== Nitro)
> Remember, we are trying to get rid of Glue ;-)

TMail still in? If so have you emailed Minero about us setting up a
Rubyforge project for it? Do you want me too?

T.


From george.moschovitis at gmail.com  Wed Sep 19 16:40:42 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 19 Sep 2007 23:40:42 +0300
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1190233571.297474.181280@o80g2000hse.googlegroups.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
Message-ID: 

>
> TMail still in? If so have you emailed Minero about us setting up a
> Rubyforge project for it? Do you want me too?


It is still in, please contact minero!

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070919/a313c6c6/attachment.html 

From transfire at gmail.com  Wed Sep 19 16:59:57 2007
From: transfire at gmail.com (Trans)
Date: Wed, 19 Sep 2007 20:59:57 -0000
Subject: [Nitro] Nemo svn repo
In-Reply-To: 
References: 
	<1189764451.176938.245490@r29g2000hsg.googlegroups.com>
	
	<1189770561.356157.125280@w3g2000hsg.googlegroups.com>
	
Message-ID: <1190235597.687840.75140@50g2000hsm.googlegroups.com>



On Sep 14, 5:28 am, "George Moschovitis"
 wrote:
> > So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a
>
> memo is fine with me! go grab it ;-)

I know. I know. I'm way too persnickety. But 'memo' just seems to
generic too me. A google search for instance would never find our
project. Am I being too picky, or is that a reasonable concern?

OTOH, I still am not sure of another name. There is the option of the
plural 'nemos'. But perhaps Mark's suggestion 'mneme' is best? Or
slightly shorter 'neme'? Another thought was 'opod', as in a pod being
a place that stores things and cephalopod (my octopus ;) -- 'pod'
itself is already taken by yet another dead project though :(. Another
thought 'rem'.

Wish one name would just jump out at me. At this point, I guess I'm
leaning toward 'opod'.

T.


From weather at speakeasy.net  Wed Sep 19 18:35:52 2007
From: weather at speakeasy.net (Matthew B Gardner)
Date: Wed, 19 Sep 2007 18:35:52 -0400
Subject: [Nitro] Transactions
Message-ID: <200709191835.52723.weather@speakeasy.net>

I've looked around and can't find information regarding how to perform 
transactions in Og -- I did find some mention of Og having support for it, 
but the trail died there. All I'm looking to do at the moment is this...

start transaction
save obj1
save obj2
rollback if errors

Does Og already have something elegant for this?

Thanks for any help,
Matt

From mvyver at gmail.com  Wed Sep 19 20:19:50 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Thu, 20 Sep 2007 10:19:50 +1000
Subject: [Nitro] Nemo svn repo
In-Reply-To: <1190235597.687840.75140@50g2000hsm.googlegroups.com>
References: 
	<1189764451.176938.245490@r29g2000hsg.googlegroups.com>
	
	<1189770561.356157.125280@w3g2000hsg.googlegroups.com>
	
	<1190235597.687840.75140@50g2000hsm.googlegroups.com>
Message-ID: <389c43e40709191719g5db6ea5s5928c52df6d28f84@mail.gmail.com>

On 9/20/07, Trans  wrote:
>
>
> On Sep 14, 5:28 am, "George Moschovitis"
>  wrote:
> > > So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a
> >
> > memo is fine with me! go grab it ;-)
>
> I know. I know. I'm way too persnickety. But 'memo' just seems to
> generic too me. A google search for instance would never find our
> project. Am I being too picky, or is that a reasonable concern?
>
> OTOH, I still am not sure of another name. There is the option of the
> plural 'nemos'. But perhaps Mark's suggestion 'mneme' is best? Or
> slightly shorter 'neme'? Another thought was 'opod', as in a pod being
> a place that stores things and cephalopod (my octopus ;) -- 'pod'
> itself is already taken by yet another dead project though :(. Another
> thought 'rem'.
>
> Wish one name would just jump out at me. At this point, I guess I'm
> leaning toward 'opod'.

>From the whimsical bit in me, since it's unlikely my Gran will be
looking for this package - cephalopod?
meme
metoo
 all unhelpfully obtuse
;)

> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From arne at arnebrasseur.net  Thu Sep 20 00:00:48 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Thu, 20 Sep 2007 12:00:48 +0800
Subject: [Nitro] [PATCH] RDoc task / dispatcher bugfix / tutorial start
In-Reply-To: 
References: <46EFD84A.20208@arnebrasseur.net> 
Message-ID: <46F1F070.3030303@arnebrasseur.net>

Jonathan Buch schreef:
> * Make less topics per post :P
>   
Thank you Jo, I realize I should practice what I preach :)

(ab)

-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net


From arne at arnebrasseur.net  Thu Sep 20 00:04:52 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Thu, 20 Sep 2007 12:04:52 +0800
Subject: [Nitro] nitro build fails on OSX and Ubuntu with gem errors
In-Reply-To: <30182.192.193.221.204.1190202910.squirrel@yoyo.org>
References: <46EFBF01.3080807@tastapod.com>			<46EFE6BA.5010104@tastapod.com>		<46EFEA3F.4060503@tastapod.com>
	<30182.192.193.221.204.1190202910.squirrel@yoyo.org>
Message-ID: <46F1F164.90102@arnebrasseur.net>

Aidan Rogers schreef:
> ...  This is on cygwin, ...
>   
I tried, failed and gave up running Nitro on Cygwin, luckily I no longer 
have to use OS's that aren't POSIX compliant.

Thanks for the tips, I'm sure they'll be of use to someone.

(ab)

-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net


From arne at arnebrasseur.net  Thu Sep 20 00:08:11 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Thu, 20 Sep 2007 12:08:11 +0800
Subject: [Nitro] testable controllers
In-Reply-To: 
References: <46EFE338.3030207@tastapod.com>			
	
Message-ID: <46F1F22B.1070404@arnebrasseur.net>

George Moschovitis schreef:
> Ok,
>
> I re-enabled the old behaviour. Please pull the latest repo code, and 
> let me know if everything works as expected.
Thank you G, I'm sure many will appreciate it, and I can remove the 
VERSION_NOTE from my tutorial ;)

This nicely illustrate that while adding a feature is easy, removing one 
will always cause complaints. Caveat programmer!

(ab)


-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net


From rob at robmela.com  Thu Sep 20 00:47:09 2007
From: rob at robmela.com (Robert Mela)
Date: Thu, 20 Sep 2007 00:47:09 -0400
Subject: [Nitro] Nemo svn repo
In-Reply-To: <1189770561.356157.125280@w3g2000hsg.googlegroups.com>
References: 	<1189764451.176938.245490@r29g2000hsg.googlegroups.com>	
	<1189770561.356157.125280@w3g2000hsg.googlegroups.com>
Message-ID: <46F1FB4D.6030703@robmela.com>

Persistence?

Icelandic "minni" is the same word it was 1,000+ years ago.

If it's a *little* library, well, minni can also mean l?till 
 
:)

Old Icelandic:

http://www.northvegr.org/zoega/h297.php

*minni*, n. (1) /memory /(hann missti minnis ok ??tti n?r sem 
vitstolinn) leggja e-t ? m., /to lay up in the mind/; reka m. til e-s, 
/to call to mind/; (2) esp. in pl. /memorials /(sl?k m. hafa ?slendingar 
Haralds konungs ok m?rg ?nnur); settir eptir (/viz./ dau?a)* *bauta-

Modern Icelandic:

^1 minni n ( -s)

1. memory, recall
hann hefur gott ~
he has a good memory
til ~s um e-?
in memory of sth
skrifa e-? til ~s
make a note of sth
l??a e-? ?r ~
forget sth


Trans wrote:
> On Sep 14, 4:07 am, "George Moschovitis"
>  wrote:
>   
>> Perhaps, more people from the nitro and facets mailing lists should
>> email Tom. What is the email?
>>     
>
>   See: http://rubyforge.org/users/tom/
>
> But under the other circumstance I think it's probably time just to
> let it go and pick a different name, so we can get on with it. There's
> no guarantee that Tom will change his mind. And the release of this
> project has already been delayed too long as it is.
>
> So the original Greek 'mnemo'? Or English 'memo'? (Though they seem a
> bit generic). Any other ideas for short, concise name for a persistent
> memory system? Preferably one that goes along with an octopus ;)
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070920/e1aaf8be/attachment.vcf 

From george.moschovitis at gmail.com  Thu Sep 20 03:33:24 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 10:33:24 +0300
Subject: [Nitro] Transactions
In-Reply-To: <200709191835.52723.weather@speakeasy.net>
References: <200709191835.52723.weather@speakeasy.net>
Message-ID: 

A quick example:

Article.transaction do
  article1.save
  article2.save
end

or

Og.manager.with_store do |s|
  s.transaction do
    article.save
    user.save
  end
end


-g.




On 9/20/07, Matthew B Gardner  wrote:
>
> I've looked around and can't find information regarding how to perform
> transactions in Og -- I did find some mention of Og having support for it,
> but the trail died there. All I'm looking to do at the moment is this...
>
> start transaction
> save obj1
> save obj2
> rollback if errors
>
> Does Og already have something elegant for this?
>
> Thanks for any help,
> Matt
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/e3fa8691/attachment.html 

From george.moschovitis at gmail.com  Thu Sep 20 03:34:21 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 10:34:21 +0300
Subject: [Nitro] testable controllers
In-Reply-To: <46F1F22B.1070404@arnebrasseur.net>
References: <46EFE338.3030207@tastapod.com>
	
	
	
	
	<46F1F22B.1070404@arnebrasseur.net>
Message-ID: 

>
> This nicely illustrate that while adding a feature is easy, removing one
> will always cause complaints. Caveat programmer!
>

;-)



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/22da9837/attachment.html 

From george.moschovitis at gmail.com  Thu Sep 20 06:18:41 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 13:18:41 +0300
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
Message-ID: 

Dear devs,

I would like to find one volunteer to investigate the issue of
Nitro/Og/Facets compatibility with the
upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?

regards,
George.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/d3af15bd/attachment.html 

From mvyver at gmail.com  Thu Sep 20 07:56:34 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Thu, 20 Sep 2007 21:56:34 +1000
Subject: [Nitro] OG RFC: Catching an early/fatal exception.
In-Reply-To: <389c43e40709190619h319932b4s20ced491bf899178@mail.gmail.com>
References: <389c43e40709190619h319932b4s20ced491bf899178@mail.gmail.com>
Message-ID: <389c43e40709200456m1ae5ae33oda6cd25ce0f9e022@mail.gmail.com>

> Scenario:
> You're writing a spec, an Og object is defined at the same 'level' as
> the describe's.  'Og.start' is run.
> The 'query' call in the first call to sql.rb:create_field_map,
> generates an exception.
> NOTE: We are within the 'unless map =
> klass.instance_variable_get("@field_map")' branch
> sql.rb:handle_sql_exception() is called and a new StoreException is raised.

This issue wasn't entirely new:
http://rubyforge.org/pipermail/nitro-general/2006-May/thread.html#4274

The difference in what I've done is to handle the StoreException along
the way and so I throw an exception at the end of Og.start - currently
things are just logged.  This may be a point of contention?
I'll get the patch together tomorrow and post to the list.

I've worked on the assumption that StoreException is the lowest level
OG store related exception we'll see, and if you do see it then not
much has worked - so Og will shut down as described in the first post
(disconnect and unmanage any classes).
Adpater, and driver code _should_ override the functions that generate
StoreException - if they don't there is some informative feedback.

I intend the DBI adapter to raise some dbi annotated exceptions - the
DBI gem does this already so will distinguish mine from those -
anyway, getting ahead of my self.

Due to the netbeans bug I posted about my specs are hosed from rake's
point of view. So I'd appreciate someone applying the patch and seeing
what it does to current specs and their current code.

I've got things to the point that when you run the following (with a
broken adapter):

## Start
begin
  require "rubygems"
rescue LoadError => ex
  # drink it!
end

require "og"

$DBG = true

     class Person
        attr_accessor :name, String
        attr_accessor :age, Integer
        attr_accessor :occupation, String
        attr_accessor :type, Integer
        attr_accessor :notes, String
      end

Og.start

Og.start

## End

You see (note the consecutive Og.start):

 INFO: Og uses the Dbi store.
DEBUG: Og manageable classes: [Person]
DEBUG: SELECT * FROM `ogperson` LIMIT 1
ERROR: DB error undefined method `query' for
#, [SELECT * FROM `ogperson` LIMIT 1]
ERROR: /usr/src/nitro-repo/og/lib/og/store/sql.rb:642:in `query_statement'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:627:in `query'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:1126:in `create_field_map'
/usr/src/nitro-repo/og/lib/og/store/sql/evolution.rb:74:in `evolve_schema'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:90:in `og_create_schema'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:323:in `enchant'
/usr/src/nitro-repo/og/lib/og/manager.rb:228:in `manage'
/usr/src/nitro-repo/og/lib/og/manager.rb:154:in `with_store'
/usr/src/nitro-repo/og/lib/og/manager.rb:227:in `manage'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `manage_classes'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `each'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `manage_classes'
/usr/src/nitro-repo/og/lib/og.rb:209:in `start'
/usr/src/nitro-repo/og/lib/exception_example_1.rb:19
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/lib/ruby-debug.rb:79:in
`debug_load'
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/lib/ruby-debug.rb:79:in `main'
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/bin/rdebug-ide:74
/usr/bin/rdebug-ide:16:in `load'
/usr/bin/rdebug-ide:16
 INFO: Og has encountered a low level SQL related exception - inspect
the info log for additionaldetails.
 INFO: To obtain additional details consider the following:
  - set Og.raise_store_exceptions = true.
  - activate existing logging ($DBG=true).
  - increase the log intensity: Logger.get.level = Logger::DEBUG.
  - inspect the error log.
ERROR: Og failed to query the SQL store.  A schema field map has not
been created for Person, rebuild = true.
ERROR: Og failed to complete a schema evolution.  Table fields have
not been added or removed for Person.
ERROR: Og failed to create the schema.  The table, indices and joins
have not been created or evolved for Person, using Og::DbiAdapter.
ERROR: Og failed to complete enchanting the class Person, managed by memory.
ERROR: Og failed to return a store to the thread pool for Og::DbiAdapter.
ERROR: Og failed to manage this class.  Og related funtionality has
not been injected into the class Person.
ERROR: Og failed to manage at least one of a collection of classes.
ERROR: Og failed to start cleanly. Classes will now be unmanaged and
the store closed.
ERROR: Og::StoreException in Og.setup:
ERROR: Og::StoreException
ERROR: /usr/src/nitro-repo/og/lib/og/store/sql.rb:685:in `handle_sql_exception'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:630:in `query'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:1126:in `create_field_map'
/usr/src/nitro-repo/og/lib/og/store/sql/evolution.rb:74:in `evolve_schema'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:90:in `og_create_schema'
/usr/src/nitro-repo/og/lib/og/store/sql.rb:323:in `enchant'
/usr/src/nitro-repo/og/lib/og/manager.rb:228:in `manage'
/usr/src/nitro-repo/og/lib/og/manager.rb:154:in `with_store'
/usr/src/nitro-repo/og/lib/og/manager.rb:227:in `manage'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `manage_classes'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `each'
/usr/src/nitro-repo/og/lib/og/manager.rb:343:in `manage_classes'
/usr/src/nitro-repo/og/lib/og.rb:209:in `start'
/usr/src/nitro-repo/og/lib/exception_example_1.rb:19
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/lib/ruby-debug.rb:79:in
`debug_load'
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/lib/ruby-debug.rb:79:in `main'
/usr/lib/ruby/gems/1.8/gems/ruby-debug-ide-0.1.8/bin/rdebug-ide:74
/usr/bin/rdebug-ide:16:in `load'
/usr/bin/rdebug-ide:16
[0



and just to check that all is still OK, using:

Og.start({:adapter => :mysql, :user => "root", :password => "", :name
=> "test"})

 INFO: Og uses the Mysql store.
DEBUG: Og manageable classes: [Person]
DEBUG: CREATE TABLE `ogperson` (`name` text, `age` integer,
`occupation` text, `type` integer, `notes` text, `oid` integer
AUTO_INCREMENT PRIMARY KEY)
DEBUG: SELECT * FROM `ogperson` LIMIT 1


Cheers
Mark


> Problem:
> That StoreException is never caught.
> The Og.start returns silently.
> There is still a connection open to the DB backend, the DB backend is untouched.
> manager.rb:put_store is entered, @pool is undefined, and it is from
> _here_ that we return to og.rb:start where the exception is _logged_,
> but not raised.
>
> So we've seen a fatal error, the spec never receives an exception -
> just the Og.start returning 'nil', with a DB connection open and
> classes still 'managed'.
>
> Your hint that something is not right might be a later exception:
> Error code:
> Error message: database is locked(database is locked)
>
> And off you go on that tangent :)
> Anyway, I digress.....
>
> Questions:
> 1) Where should these exceptions be handled?
> There are three places this exception could be handled:
>  a) sql.rb:handle_sql_exception
>  b) sql.rb:create_field_map
>  c) manager.rb:put_store
>  d) both a) and b)
>
> Votes? Instructions?
>
> 2) What should be done with the DB connection and the manged classes?
> From my understanding, because
> 'klass.instance_variable_get("@field_map")' returned nil/false in
> sql.rb:create_field_map we should really shutdown the DB connection,
> unmanage the classes, and scream blue-murder.  The unmanage classes
> step is because I think Og's manger doesn't like being given the same
> class twice - but this might be an impression left from the OGTABLE
> warning just patched?  Anyway, safety first, and I'd vote for
> something like the following somewhere (where?) in 1 d):
>         if manager.close_store == nil && manager.unmanage_classes == []
>           true
>         else
>           raise 
>         end
>
> Comments _please_
>
> Mark
>

From transfire at gmail.com  Thu Sep 20 09:28:49 2007
From: transfire at gmail.com (Trans)
Date: Thu, 20 Sep 2007 13:28:49 -0000
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: 
References: 
Message-ID: <1190294929.746466.167190@r29g2000hsg.googlegroups.com>



On Sep 20, 3:18 am, "George Moschovitis"
 wrote:
> Dear devs,
>
> I would like to find one volunteer to investigate the issue of
> Nitro/Og/Facets compatibility with the
> upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?

Good idea. But can we save it for December/January? I know of a couple
pending changes for Facets, when 1.9 is released, for instance,
Integer#even? and Integer#odd? can be removed. I'm sure there will be
a number of other things too, but I don't feel it anything to worry
about until then.

Let stay focused on the current release. How far are we from a release
of Nitro 0.50?

T.


From dan at tastapod.com  Thu Sep 20 11:01:09 2007
From: dan at tastapod.com (Dan North)
Date: Thu, 20 Sep 2007 17:01:09 +0200
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: 
References: 
Message-ID: <46F28B35.5040506@tastapod.com>

I've been talking to Ola Bini - one of the core developers of JRuby - 
about officially supporting nitro. His position is that he doesn't 
consider it stable enough yet, but he's keeping an open mind if it 
stabilises again quickly.

This was because he was unable to find any up-to-date documentation and 
the build fell apart all over the place due to bogus usage of gems (i.e. 
it mostly worked once we had GEM_HOME set up, but rails and other apps 
don't need this if the gems are in the default location). Not big things 
to fix but absolutely critical for a successful first impression. This 
time I wasn't lucky.

Can I +1 the idea to hold back on new features for a bit and just 
stabilise what's there and document / increase test coverage?

Once we get back to a suitable level, I'll be happy to put it in front 
of him again and try to get official support on JRuby. I think an 
announcement like that would do a lot to raise the profile of nitro and og.

It would be great to see you guys at NitroConf Europe next year :)

Cheers,
Dan


George Moschovitis wrote:
> Dear devs,
>
> I would like to find one volunteer to investigate the issue of 
> Nitro/Og/Facets compatibility with the
> upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?
>
> regards,
> George.
>
> -- 
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/e6e03c72/attachment-0001.html 

From george.moschovitis at gmail.com  Thu Sep 20 11:06:08 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 18:06:08 +0300
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: <46F28B35.5040506@tastapod.com>
References: 
	<46F28B35.5040506@tastapod.com>
Message-ID: 

Ok, thanks for the feedback, I guess we have to try harder to make Nitro
easier for newcomers.

-g.

On 9/20/07, Dan North  wrote:
>
>  I've been talking to Ola Bini - one of the core developers of JRuby -
> about officially supporting nitro. His position is that he doesn't consider
> it stable enough yet, but he's keeping an open mind if it stabilises again
> quickly.
>
> This was because he was unable to find any up-to-date documentation and
> the build fell apart all over the place due to bogus usage of gems (i.e.
> it mostly worked once we had GEM_HOME set up, but rails and other apps don't
> need this if the gems are in the default location). Not big things to fix
> but absolutely critical for a successful first impression. This time I
> wasn't lucky.
>
> Can I +1 the idea to hold back on new features for a bit and just
> stabilise what's there and document / increase test coverage?
>
> Once we get back to a suitable level, I'll be happy to put it in front of
> him again and try to get official support on JRuby. I think an announcement
> like that would do a lot to raise the profile of nitro and og.
>
> It would be great to see you guys at NitroConf Europe next year :)
>
> Cheers,
> Dan
>
>
> George Moschovitis wrote:
>
> Dear devs,
>
> I would like to find one volunteer to investigate the issue of
> Nitro/Og/Facets compatibility with the
> upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?
>
> regards,
> George.
>
> --
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
>
> ------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.orghttp://rubyforge.org/mailman/listinfo/nitro-general
>
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/490f312a/attachment.html 

From dan at tastapod.com  Thu Sep 20 12:01:05 2007
From: dan at tastapod.com (Dan North)
Date: Thu, 20 Sep 2007 18:01:05 +0200
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: 
References: 	<46F28B35.5040506@tastapod.com>
	
Message-ID: <46F29941.1080304@tastapod.com>

Of course this is with the usual disclaimer that I think nitro is 
brilliant and I really want to see/help it succeed :)

George Moschovitis wrote:
> Ok, thanks for the feedback, I guess we have to try harder to make 
> Nitro easier for newcomers.
>
> -g.
>
> On 9/20/07, *Dan North* < dan at tastapod.com > 
> wrote:
>
>     I've been talking to Ola Bini - one of the core developers of
>     JRuby - about officially supporting nitro. His position is that he
>     doesn't consider it stable enough yet, but he's keeping an open
>     mind if it stabilises again quickly.
>
>     This was because he was unable to find any up-to-date
>     documentation and the build fell apart all over the place due to
>     bogus usage of gems (i.e. it mostly worked once we had GEM_HOME
>     set up, but rails and other apps don't need this if the gems are
>     in the default location). Not big things to fix but absolutely
>     critical for a successful first impression. This time I wasn't lucky.
>
>     Can I +1 the idea to hold back on new features for a bit and just
>     stabilise what's there and document / increase test coverage?
>
>     Once we get back to a suitable level, I'll be happy to put it in
>     front of him again and try to get official support on JRuby. I
>     think an announcement like that would do a lot to raise the
>     profile of nitro and og.
>
>     It would be great to see you guys at NitroConf Europe next year :)
>
>     Cheers,
>     Dan
>
>
>     George Moschovitis wrote:
>>     Dear devs,
>>
>>     I would like to find one volunteer to investigate the issue of
>>     Nitro/Og/Facets compatibility with the
>>     upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?
>>
>>     regards,
>>     George.
>>
>>     -- 
>>     http://www.me.gr
>>     http://phidz.com
>>     http://blog.gmosx.com
>>     http://cull.gr
>>     http://www.joy.gr
>>     http://nitroproject.org
>>     ------------------------------------------------------------------------
>>
>>     _______________________________________________
>>     Nitro-general mailing list
>>     Nitro-general at rubyforge.org
>>      
>>     http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>     _______________________________________________
>     Nitro-general mailing list
>     Nitro-general at rubyforge.org 
>     http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>
>
> -- 
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/027b5ad6/attachment.html 

From george.moschovitis at gmail.com  Thu Sep 20 12:23:01 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 19:23:01 +0300
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: <46F29941.1080304@tastapod.com>
References: 
	<46F28B35.5040506@tastapod.com>
	
	<46F29941.1080304@tastapod.com>
Message-ID: 

>
> Of course this is with the usual disclaimer that I think nitro is
> brilliant and I really want to see/help it succeed :)
>

thanks,

it is always nice to hear that ;-)

-g.


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/f8d4fd4d/attachment.html 

From george.moschovitis at gmail.com  Thu Sep 20 12:25:17 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 20 Sep 2007 19:25:17 +0300
Subject: [Nitro] [Facets]
In-Reply-To: <1190212957.844715.103880@o80g2000hse.googlegroups.com>
References: 
	<1190212957.844715.103880@o80g2000hse.googlegroups.com>
Message-ID: 

the old version didn't work ;-)

-g.

On 9/19/07, Trans  wrote:
>
>
>
> On Sep 19, 6:52 am, "George Moschovitis"
>  wrote:
> > Tom,
> >
> > I changed facets/core/string/brief.rb a little bit...
>
> How so?
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070920/e3170c45/attachment.html 

From transfire at gmail.com  Thu Sep 20 12:56:42 2007
From: transfire at gmail.com (Trans)
Date: Thu, 20 Sep 2007 16:56:42 -0000
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
Message-ID: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>

Just wanted to make a few suggestions that I think... no... that I
really know would go along way to improve Nitro/Og development, and in
turn improve stability, availability and adoption.

The main thing is that Og needs to have it's own repository. By
separating Og out from the Nitro framework, it can grow on it's own
merits. This in turn will come back to benefit Nitro, as a matter of
an independent development track, and as people adopt Og as their ORM
of choice, they will also in turn be attracted to Nitro later for
their website needs.

Another thing to consider is using Subversion rather than Darcs. I
know Darcs is great. I miss it too in some respects. But it may be
easier to share in development if there were in fact a central
Rubyforge-hosted repository. This isn't as big a deal as the first
point, but it's worth some serious consideration.

Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!! I
can't stress that enough. An unfinished website is a big turn-off. It
immediately reflects on the quality of the software itself. It's
better to have a small but finished site, than a large unfinished one.
And there simply isn't any reason to ever have broken links --just
don't have the links. If it's something for the future, but not yet
ready, then use  remarks to hide it until it is ready. I also
note that an image link to OxyWTF was never added. I realize it may
not be an "official" Nitro site, but inclusiveness of community
efforts is far more important than minor personal preferences or
gains. Thats how you build a community, and how it grows, and how in
the end it benefits us all more than if each of us acts alone.

Finally, let me say that I do have plans for creating some dynamic
websites down the road, and I want to use Nitro, of course, but I've
really been waiting for the framework to mature. I wish I could help
more in that regard, but working on Facets is about all the time I
have to contribute these days. Yet Nitro needs to mature. In fact, it
has to mature if intends to be a truly viable option.

T.


From transfire at gmail.com  Thu Sep 20 12:59:35 2007
From: transfire at gmail.com (Trans)
Date: Thu, 20 Sep 2007 16:59:35 -0000
Subject: [Nitro] [Facets]
In-Reply-To: 
References: 
	<1190212957.844715.103880@o80g2000hse.googlegroups.com>
	
Message-ID: <1190307575.183796.274400@k79g2000hse.googlegroups.com>



On Sep 20, 9:25 am, "George Moschovitis"
 wrote:
> the old version didn't work ;-)

Okay. Did you change in 2.0 or 1.8? Have you updated the SVN repo or
shall I (if you send me a copy of the change)?

Thanks,
T.


From james.britt at gmail.com  Thu Sep 20 13:19:26 2007
From: james.britt at gmail.com (James Britt)
Date: Thu, 20 Sep 2007 10:19:26 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
Message-ID: <46F2AB9E.40602@gmail.com>

Trans wrote:
> Just wanted to make a few suggestions that I think... no... that I
> really know would go along way to improve Nitro/Og development, and in
> turn improve stability, availability and adoption.
> 
> The main thing is that Og needs to have it's own repository. By
> separating Og out from the Nitro framework, it can grow on it's own
> merits. This in turn will come back to benefit Nitro, as a matter of
> an independent development track, and as people adopt Og as their ORM
> of choice, they will also in turn be attracted to Nitro later for
> their website needs.

Good suggestion.  It would also make it easier for people using Merb, 
Camping, IOWA, etc. to give Og a whirl, or to use Og in standalone 
console apps.

> 
> Another thing to consider is using Subversion rather than Darcs. I
> know Darcs is great. I miss it too in some respects. But it may be
> easier to share in development if there were in fact a central
> Rubyforge-hosted repository. This isn't as big a deal as the first
> point, but it's worth some serious consideration.


Tough call.  I've been moving to Mercurial and away from svn.  I'm fine 
with darcs or svn.

There are tools to link svn with other repos, though they can become yet 
another task to  look after.

Practically speaking, most people will want to pull the lasted code than 
submit patches, so having perhaps a pull-only svn source might work, fed 
by the master darcs repo.


> 
> Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!! 

A good, professional-looking site can go a long way in establishing user 
confidence in a project and encourage people to try it out or get 
involved.    Perhaps some people could be given "Web Master" 
permissions, and fix up the annoying things?

-- 
James Britt

"Discover the recipes you are using and abandon them."
  - Brian Eno and Peter Schmidt, Oblique Strategies

From james.britt at gmail.com  Thu Sep 20 13:23:24 2007
From: james.britt at gmail.com (James Britt)
Date: Thu, 20 Sep 2007 10:23:24 -0700
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: <46F28B35.5040506@tastapod.com>
References: 
	<46F28B35.5040506@tastapod.com>
Message-ID: <46F2AC8C.4030106@gmail.com>

Dan North wrote:
> I've been talking to Ola Bini - one of the core developers of JRuby - 
> about officially supporting nitro. His position is that he doesn't 
> consider it stable enough yet, but he's keeping an open mind if it 
> stabilises again quickly.

I had a short exchange with Charlie Nutter some months back on JRuby + 
Nitro as well.  Basically, we need to run the test suites under JRuby 
and report what breaks and what the errors are.  (The JRuby team are 
keen and having as many tests and use cases as possible.)

I then got stumped trying to figure out how to run the 
Nitro/Og/Raw/Facets test suites. :(


> 
> ... 
> Can I +1 the idea to hold back on new features for a bit and just 
> stabilise what's there and document / increase test coverage?
> 

Yes, please.


> Once we get back to a suitable level, I'll be happy to put it in front 
> of him again and try to get official support on JRuby. I think an 
> announcement like that would do a lot to raise the profile of nitro and og.


Very much so.

> 
> It would be great to see you guys at NitroConf Europe next year :)

:)  Indeed.

James Britt
----
"In physics the truth is rarely perfectly clear, and that is certainly
  universally the case in human affairs. Hence, what is not surrounded by
  uncertainty cannot be the truth."
  - R. Feynman

From transfire at gmail.com  Thu Sep 20 19:49:09 2007
From: transfire at gmail.com (Trans)
Date: Thu, 20 Sep 2007 23:49:09 -0000
Subject: [Nitro] [Facets]
In-Reply-To: 
References: 
	<1190212957.844715.103880@o80g2000hse.googlegroups.com>
	
Message-ID: <1190332149.411934.164300@57g2000hsv.googlegroups.com>



On Sep 20, 9:25 am, "George Moschovitis"
 wrote:
> the old version didn't work ;-)

Okay, I took a look at it and fixed.

T.


From rob at robmela.com  Fri Sep 21 00:16:39 2007
From: rob at robmela.com (Robert Mela)
Date: Fri, 21 Sep 2007 00:16:39 -0400
Subject: [Nitro] Nitro/Og Coupling?
Message-ID: <46F345A7.4010206@robmela.com>

It looks like Form.attributes autogenerates a form from an incoming object.

I tried it with a non-Og object:

#{form :object => @myobj, yadda yadda yadda
     f.attributes
     f.submit 'Submit'
 }

and it reported "undefined method 'validation_errors'".  I threw in a 
no-op validation_errors method, and it threw an exception saying that 
'saved?' was undefined.

Is there a way to pass a non-Og object to a form?  If not, is there a 
way to have an Og object independent of a database?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070921/4b5a6f1e/attachment.vcf 

From george.moschovitis at gmail.com  Fri Sep 21 03:12:25 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 21 Sep 2007 10:12:25 +0300
Subject: [Nitro] Nitro/Og Coupling?
In-Reply-To: <46F345A7.4010206@robmela.com>
References: <46F345A7.4010206@robmela.com>
Message-ID: 

Hmm, interesting, I haven't thought of that.
As you may be aware I am currently redesigning the form helper (have a look
at nform.rb)
I will  take this requirement into account.

thanks,
-g.

On 9/21/07, Robert Mela  wrote:
>
> It looks like Form.attributes autogenerates a form from an incoming
> object.
>
> I tried it with a non-Og object:
>
> #{form :object => @myobj, yadda yadda yadda
>      f.attributes
>      f.submit 'Submit'
> }
>
> and it reported "undefined method 'validation_errors'".  I threw in a
> no-op validation_errors method, and it threw an exception saying that
> 'saved?' was undefined.
>
> Is there a way to pass a non-Og object to a form?  If not, is there a
> way to have an Og object independent of a database?
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/387c75cc/attachment.html 

From george.moschovitis at gmail.com  Fri Sep 21 04:15:00 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 21 Sep 2007 11:15:00 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
Message-ID: 

>
> The main thing is that Og needs to have it's own repository. By
> separating Og out from the Nitro framework, it can grow on it's own
> merits. This in turn will come back to benefit Nitro, as a matter of
> an independent development track, and as people adopt Og as their ORM
> of choice, they will also in turn be attracted to Nitro later for
> their website needs.


Ok, I will do this.


> Another thing to consider is using Subversion rather than Darcs. I
> know Darcs is great. I miss it too in some respects. But it may be
> easier to share in development if there were in fact a central
> Rubyforge-hosted repository. This isn't as big a deal as the first
> point, but it's worth some serious consideration.


Perhaps a readonly SVN repo  like James suggested is a better idea.


> Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!! I
> can't stress that enough. An unfinished website is a big turn-off. It
> immediately reflects on the quality of the software itself. It's


I don't have much time to work on the site.  Does anyone have any time to
work on this?

Finally, let me say that I do have plans for creating some dynamic
> websites down the road, and I want to use Nitro, of course, but I've
> really been waiting for the framework to mature. I wish I could help
> more in that regard, but working on Facets is about all the time I
> have to contribute these days. Yet Nitro needs to mature. In fact, it
> has to mature if intends to be a truly viable option.
>

I would think that Nitro is an ideal solution for you. It is the most
integrated framework with facets. And it is relatively mature. Moreover, I
will have one more developer working on-top of Nitro full time from October
1st, so expect more progress. Hopefully, I will have small amounts of money
to sponsor some nitro/og bounties, or we could even build a small Nitro fund
for stuff like the site or documentation (like the Rails guys did when they
where starting).

food for thought,
-g.


-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/cd90e613/attachment.html 

From mvyver at gmail.com  Fri Sep 21 04:17:07 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 21 Sep 2007 18:17:07 +1000
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <46F2AB9E.40602@gmail.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F2AB9E.40602@gmail.com>
Message-ID: <389c43e40709210117g1a8dca2lbfd2d592296bab5c@mail.gmail.com>

On 9/21/07, James Britt  wrote:
> Trans wrote:
> > Just wanted to make a few suggestions that I think... no... that I
> > really know would go along way to improve Nitro/Og development, and in
> > turn improve stability, availability and adoption.
> >
> > The main thing is that Og needs to have it's own repository. By
> > separating Og out from the Nitro framework, it can grow on it's own
> > merits. This in turn will come back to benefit Nitro, as a matter of
> > an independent development track, and as people adopt Og as their ORM
> > of choice, they will also in turn be attracted to Nitro later for
> > their website needs.
>
> Good suggestion.  It would also make it easier for people using Merb,
> Camping, IOWA, etc. to give Og a whirl, or to use Og in standalone
> console apps.

All good points.  By having a separate repo isn't the admin increased?
If so, there will be a need for extra hands to help George?
I'm only interested in Og, so haven't looked at anything to do with
Nitro.  However, if OG is separated, wouldn't there need to be some
way to ensure changes don't break Nitro?  I imagine this might be the
main concern?

>From my own experience: Some time ago I'd come across the Nitro page
but not being interested in a web framework I moved on :)
Much later, in the course of a general ORM search I hunted Og down
based on Kirk Haines having mentioned it in a discussion about Rails
on the eventmachine list!
So, I'm not certain if it needs a separate repo or not but a more
prominent web presence would, I think, be more significant.  This
however involves a lot of extra work....

> > Another thing to consider is using Subversion rather than Darcs. I
> > know Darcs is great. I miss it too in some respects. But it may be
> > easier to share in development if there were in fact a central
> > Rubyforge-hosted repository. This isn't as big a deal as the first
> > point, but it's worth some serious consideration.
>
>
> Tough call.  I've been moving to Mercurial and away from svn.  I'm fine
> with darcs or svn.
>
> There are tools to link svn with other repos, though they can become yet
> another task to  look after.

Yep.

> Practically speaking, most people will want to pull the lasted code than
> submit patches, so having perhaps a pull-only svn source might work, fed
> by the master darcs repo.
>
>
> >
> > Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!!
>
> A good, professional-looking site can go a long way in establishing user
> confidence in a project and encourage people to try it out or get
> involved.    Perhaps some people could be given "Web Master"
> permissions, and fix up the annoying things?

Again, all good points, which require extra work - I'm not aware of
volunteers being refused to be allowed to help - so far I've fond
George responsive to my code posts.

My 2c
Mark

> --
> James Britt
>
> "Discover the recipes you are using and abandon them."
>   - Brian Eno and Peter Schmidt, Oblique Strategies
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From john at oxyliquit.de  Fri Sep 21 04:58:55 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Fri, 21 Sep 2007 10:58:55 +0200
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: <1190294929.746466.167190@r29g2000hsg.googlegroups.com>
References: 
	<1190294929.746466.167190@r29g2000hsg.googlegroups.com>
Message-ID: 

Hi,

>> I would like to find one volunteer to investigate the issue of
>> Nitro/Og/Facets compatibility with the
>> upcoming Ruby 1.9 and/or JRuby. Anyone up to the task?
>
> Good idea. But can we save it for December/January? I know of a couple
> pending changes for Facets, when 1.9 is released, for instance,
> Integer#even? and Integer#odd? can be removed. I'm sure there will be
> a number of other things too, but I don't feel it anything to worry
> about until then.
>
> Let stay focused on the current release. How far are we from a release
> of Nitro 0.50?

+1

 From a recent discussion on #nitro:

[09:38]   Kashia, i was going to post to the mailing list, but i'm too excited
[09:38]   lol, shoot :)
[09:38]   really wondering what the time-table is looking like for the next release of Og
[09:39]   there's more bug-fixes, design improvements that i'm needing in the current Og darcs repo
[09:39]   so i'm wondering what the general state of Og is at
[09:39]   I'm waiting for George to finish doing whatever he does to the RSpec files atm
[09:39]   excellent
[09:39]   Og needs a good stable testsuite
[09:40]   testsuites do usually help :)
[09:40]   George doesn't have much on his plan for Og otherwise
[09:40]   sweet!
[09:40]   but then, there needs to be some bugfixing (when G installs the specs again)
[09:41]   so there's probably show-stopper bugs in there?
[09:41]   my feeling:  nothing which would stop me from doing apps on it
[09:41]   i was thinking about rushing ahead, and directly including Og into my project, instead of waiting for a stable release
[09:41]   but not sure how much chaos that'd cause me
[09:42]   well, choose a version, stick with it, backport bugfixes, make bugfixes yourself
[09:42]   that's what I do
[09:42]   aye

As I said a few month back, I'd love Nitro/Og just getting the tests
running, and right after that a release (0.49).  George did agree to
that, but alas, there gotta be new features.  :P

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Fri Sep 21 05:10:51 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Fri, 21 Sep 2007 11:10:51 +0200
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
Message-ID: 

Hi,

> I also
> note that an image link to OxyWTF was never added. I realize it may
> not be an "official" Nitro site,

to be fair, the most visitors I get are from np.org

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From george.moschovitis at gmail.com  Fri Sep 21 05:17:44 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 21 Sep 2007 12:17:44 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
Message-ID: 

there is a stupid reason about this. I requested the oxy logo in some vector
format so I can create a banner, but for some reason I never got it.
jonathan can you send me the logo?

-g.



On 9/21/07, Jonathan Buch  wrote:
>
> Hi,
>
> > I also
> > note that an image link to OxyWTF was never added. I realize it may
> > not be an "official" Nitro site,
>
> to be fair, the most visitors I get are from np.org
>
> Jo
>
> --
> Feel the love
> http://pinkjuice.com/pics/ruby.png
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/4029ec69/attachment.html 

From dan at tastapod.com  Fri Sep 21 05:29:59 2007
From: dan at tastapod.com (Dan North)
Date: Fri, 21 Sep 2007 11:29:59 +0200
Subject: [Nitro] Nitro Ruby1.9/JRuby compatibility
In-Reply-To: <46F2AC8C.4030106@gmail.com>
References: 	<46F28B35.5040506@tastapod.com>
	<46F2AC8C.4030106@gmail.com>
Message-ID: <46F38F17.5060208@tastapod.com>

It's more than that. Ola's opinion was that the test coverage on nitro 
is very light compared to rails, and he doesn't want to officially 
endorse something which might break in weird jruby-related ways, which 
would risk jruby's reputation when it comes to endorsing existing ruby 
libraries or frameworks.

We need a much more robust test suite that properly describes the 
behaviour of the various components of nitro. Which would be no bad 
thing in itself anyway.

James Britt wrote:
> Dan North wrote:
>   
>> I've been talking to Ola Bini - one of the core developers of JRuby - 
>> about officially supporting nitro. His position is that he doesn't 
>> consider it stable enough yet, but he's keeping an open mind if it 
>> stabilises again quickly.
>>     
>
> I had a short exchange with Charlie Nutter some months back on JRuby + 
> Nitro as well.  Basically, we need to run the test suites under JRuby 
> and report what breaks and what the errors are.  (The JRuby team are 
> keen and having as many tests and use cases as possible.)
>
> I then got stumped trying to figure out how to run the 
> Nitro/Og/Raw/Facets test suites. :(
>
>
>   
>> ... 
>> Can I +1 the idea to hold back on new features for a bit and just 
>> stabilise what's there and document / increase test coverage?
>>
>>     
>
> Yes, please.
>
>
>   
>> Once we get back to a suitable level, I'll be happy to put it in front 
>> of him again and try to get official support on JRuby. I think an 
>> announcement like that would do a lot to raise the profile of nitro and og.
>>     
>
>
> Very much so.
>
>   
>> It would be great to see you guys at NitroConf Europe next year :)
>>     
>
> :)  Indeed.
>
> James Britt
> ----
> "In physics the truth is rarely perfectly clear, and that is certainly
>   universally the case in human affairs. Hence, what is not surrounded by
>   uncertainty cannot be the truth."
>   - R. Feynman
> _______________________________________________
> 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/20070921/e7e15f79/attachment.html 

From dan at tastapod.com  Fri Sep 21 05:33:25 2007
From: dan at tastapod.com (Dan North)
Date: Fri, 21 Sep 2007 11:33:25 +0200
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
Message-ID: <46F38FE5.7040303@tastapod.com>

If you are thinking about moving away from darcs, can I re-raise my 
suggestion of moving to mercurial? It's written in python so it's 
available on pretty much any platform, and it allows the kind of 
distributed, patch-based development model we're used to with darcs.

A number of projects are moving that way, notably opensolaris and 
hamcrest (the matchers component of jmock and junit). It also comes with 
a very lightweight cgi script that allows you to browse, view 
history/diffs and sync from an online repository over http.

Just my $0.02.

Trans wrote:
> Just wanted to make a few suggestions that I think... no... that I
> really know would go along way to improve Nitro/Og development, and in
> turn improve stability, availability and adoption.
>
> The main thing is that Og needs to have it's own repository. By
> separating Og out from the Nitro framework, it can grow on it's own
> merits. This in turn will come back to benefit Nitro, as a matter of
> an independent development track, and as people adopt Og as their ORM
> of choice, they will also in turn be attracted to Nitro later for
> their website needs.
>
> Another thing to consider is using Subversion rather than Darcs. I
> know Darcs is great. I miss it too in some respects. But it may be
> easier to share in development if there were in fact a central
> Rubyforge-hosted repository. This isn't as big a deal as the first
> point, but it's worth some serious consideration.
>
> Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!! I
> can't stress that enough. An unfinished website is a big turn-off. It
> immediately reflects on the quality of the software itself. It's
> better to have a small but finished site, than a large unfinished one.
> And there simply isn't any reason to ever have broken links --just
> don't have the links. If it's something for the future, but not yet
> ready, then use  remarks to hide it until it is ready. I also
> note that an image link to OxyWTF was never added. I realize it may
> not be an "official" Nitro site, but inclusiveness of community
> efforts is far more important than minor personal preferences or
> gains. Thats how you build a community, and how it grows, and how in
> the end it benefits us all more than if each of us acts alone.
>
> Finally, let me say that I do have plans for creating some dynamic
> websites down the road, and I want to use Nitro, of course, but I've
> really been waiting for the framework to mature. I wish I could help
> more in that regard, but working on Facets is about all the time I
> have to contribute these days. Yet Nitro needs to mature. In fact, it
> has to mature if intends to be a truly viable option.
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>   


From rff_rff at yahoo.it  Fri Sep 21 05:56:48 2007
From: rff_rff at yahoo.it (gabriele renzi)
Date: Fri, 21 Sep 2007 09:56:48 +0000 (UTC)
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com>
Message-ID: 

On Fri, 21 Sep 2007 11:33:25 +0200, Dan North wrote:

> If you are thinking about moving away from darcs, can I re-raise my 
> suggestion of moving to mercurial? It's written in python so it's 
> available on pretty much any platform, and it allows the kind of 
> distributed, patch-based development model we're used to with darcs.

ot, but, since I never quite understood this: does mercurial do dependency
tracking & cherry picking like darcs, or differently, or it does'nt even
try?



-- 
goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info


From dan at tastapod.com  Fri Sep 21 06:49:42 2007
From: dan at tastapod.com (Dan North)
Date: Fri, 21 Sep 2007 12:49:42 +0200
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>	<46F38FE5.7040303@tastapod.com>
	
Message-ID: <46F3A1C6.5070701@tastapod.com>

Mercurial is very "hackable", partly because it's written in python (is 
that heresy on the nitro list?) and partly because the developers have 
designed in some very useful extension points.

There's an extension called record 
 that 
supports darcs-style cherry picking at commit time. Another called 
transplant does the same between repositories. So it's not baked in but 
it's not difficult.

I'm only advocating it as a happy user - I have no other association 
with mercurial, and I was using darcs for a while myself. I just find I 
prefer mercurial for a bunch of weird intangible reasons.

Cheers,
Dan

gabriele renzi wrote:
> On Fri, 21 Sep 2007 11:33:25 +0200, Dan North wrote:
>
>   
>> If you are thinking about moving away from darcs, can I re-raise my 
>> suggestion of moving to mercurial? It's written in python so it's 
>> available on pretty much any platform, and it allows the kind of 
>> distributed, patch-based development model we're used to with darcs.
>>     
>
> ot, but, since I never quite understood this: does mercurial do dependency
> tracking & cherry picking like darcs, or differently, or it does'nt even
> try?
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/6aeba309/attachment.html 

From george.moschovitis at gmail.com  Fri Sep 21 08:54:46 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 21 Sep 2007 15:54:46 +0300
Subject: [Nitro] Og specs
Message-ID: 

I converted some Og specs from the .old_test directory to the new test
directory. I think these conversions demonstrate what needs to be done.
I am wondering if Jonathan and/or Arne (or someone else) can convert some
more of the specs?

-g.

-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/84f1b596/attachment.html 

From wyhaines at gmail.com  Fri Sep 21 10:33:52 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 21 Sep 2007 07:33:52 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <46F3A1C6.5070701@tastapod.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
Message-ID: 

On 9/21/07, Dan North  wrote:

> I'm only advocating it as a happy user - I have no other association with
> mercurial, and I was using darcs for a while myself. I just find I prefer
> mercurial for a bunch of weird intangible reasons.

(*nod*)  I've been using mercurial on my projects for quite a long
time now, and as I mentioned when the revision control thing was last
discussed early in the year, I am quite happy with it.


Kirk Haines

From transfire at gmail.com  Fri Sep 21 12:47:38 2007
From: transfire at gmail.com (Trans)
Date: Fri, 21 Sep 2007 16:47:38 -0000
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <46F3A1C6.5070701@tastapod.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
Message-ID: <1190393258.355583.174860@k79g2000hse.googlegroups.com>



On Sep 21, 3:49 am, Dan North  wrote:
> Mercurial is very "hackable", partly because it's written in python (is
> that heresy on the nitro list?) and partly because the developers have
> designed in some very useful extension points.
>
> There's an extension called record
>  that
> supports darcs-style cherry picking at commit time. Another called
> transplant does the same between repositories. So it's not baked in but
> it's not difficult.
>
> I'm only advocating it as a happy user - I have no other association
> with mercurial, and I was using darcs for a while myself. I just find I
> prefer mercurial for a bunch of weird intangible reasons.

However, that's beyond the scope of this consideration. There's
nothing wrong with Darcs. The question is whether Subversion would
better serve Nitro b/c the Ruby community in general has adopted it.
Ruby itself uses it, Rails uses it, Facets now uses it, etc.

T.


From transfire at gmail.com  Fri Sep 21 13:05:17 2007
From: transfire at gmail.com (Trans)
Date: Fri, 21 Sep 2007 17:05:17 -0000
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
Message-ID: <1190394317.352479.14980@o80g2000hse.googlegroups.com>


On Sep 21, 1:15 am, "George Moschovitis"
 wrote:
> > The main thing is that Og needs to have it's own repository. By
> > separating Og out from the Nitro framework, it can grow on it's own
> > merits. This in turn will come back to benefit Nitro, as a matter of
> > an independent development track, and as people adopt Og as their ORM
> > of choice, they will also in turn be attracted to Nitro later for
> > their website needs.
>
> Ok, I will do this.

That's fantastic!

> Perhaps a readonly SVN repo  like James suggested is a better idea.

I don't think that's necessary. It's not just having a subversion
repo, but a place where shared development occurs. A read-only repo
wouldn't offer that. If you want to stick with Darcs then I think it's
best to do so whole heartedly. I only suggested SVN for consideration
b/c most of the Ruby community is using it, so it might encourage more
Nitro involvement.

Actually there was a good discussion about this:

  http://groups.google.com/group/ruby-talk-google/browse_thread/thread/6b846ca638f44351/8aad5a2a85faaa57?hl=en&q=subversion+trans&lnk=ol&

> I don't have much time to work on the site.  Does anyone have any time to
> work on this?

Hmmm... well, it should only take a few minutes to comment out the
dead links. That in itself is a good start. Then if you just fill in
the image link "holes", the site would look 100% better just from
that. Put an image link for Oxy and one for Facets too if you want.
Almost anything is better than blank space.

> I would think that Nitro is an ideal solution for you. It is the most
> integrated framework with facets. And it is relatively mature. Moreover, I
> will have one more developer working on-top of Nitro full time from October
> 1st, so expect more progress. Hopefully, I will have small amounts of money
> to sponsor some nitro/og bounties, or we could even build a small Nitro fund
> for stuff like the site or documentation (like the Rails guys did when they
> where starting).

That's good to hear!

I want to create a documentation wiki for Facets. And I do think Nitro
is the best solution for this. But I want to see 0.50 get out the door
and stablize a bit first --including having the examples run without
any fuss. I learn primarily by emulating examples, so it's important
to me to see those working top notch so I have something to work off
of.

Thanks for heearing out my hopes and concerns!
T.


From wyhaines at gmail.com  Fri Sep 21 13:13:33 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 21 Sep 2007 10:13:33 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190393258.355583.174860@k79g2000hse.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
Message-ID: 

> However, that's beyond the scope of this consideration. There's
> nothing wrong with Darcs. The question is whether Subversion would
> better serve Nitro b/c the Ruby community in general has adopted it.
> Ruby itself uses it, Rails uses it, Facets now uses it, etc.

Does that matter?  People aren't going to choose what framework to
use, or what ORM, or what library of utilities, based on the revision
control system.  The consideration should be A) Does the revision
control system meet the needs of the projects, and B) Is there an
_easily_ available, usable client for the RCS system so that people
who want to participate in the project don't have a barrier there.  I
think this is where darcs falls short.  I originally started using
Mercurial because, at the time, getting darcs to work on an older
linux system was a ridiculous task.

SVN is kind of the Microsoft Windows of revision control systems right
now.  Lots of people use it because access to it is very easy.
Everyone has it.  If development sticks with darcs, then somewhere in
the documentation about the project, I suggest providing links to
where one can find darcs clients, because "darcs client" in Google is
less that useful, and I do imagine that having to jump through a lot
of hoops to access the repository does put people off.


Kirk Haines

From cwdinfo at gmail.com  Fri Sep 21 13:58:46 2007
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 21 Sep 2007 10:58:46 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
	
Message-ID: 

Are you sure? I think each barrier to entry stops some possible  
adopters. At a certain point, you have narrowed your pool of  
potential adopters to "bleeding-edge" people who try anything once.  
How many people on (ackkk!) Windows do you think want to get working  
installations of SVN, DARCS, Mercurial, git, CVS, or whatever else  
and then remember the different commands for each? That's one barrier.

Barrier two: No updated soup-to-nuts tutorial on installation through  
working app. The sands shift quickly, things are deprecated and  
replaced, and the Google is little or no help. Here's an exercise:  
Find "rails install on mac osx" in Google. Then find "nitro install  
on mac osx" in Google. I accept that the results will be more sparse,  
but one thing that jump started Rails was the Rails wiki. The info  
was, at first, sketchy, but there was a place to go for info about  
info. Nuff said.

Barrier three: Version conflicts. Right now, a gem install simply  
doesn't work. Try gem install rails and everything works as  
advertised. Try gem install nitro and virtually nothing works as  
advertised. Again, accepted that this will take a while. Still, ease  
of entry makes it a softer sell.

I'm trying really hard to love Nitro and Og, but it's tough to know  
what's there. My expectations are clearly different from what's  
there. E.g., what's the right directory structure. Not documented.  
Examples have templates in a flat directory called templates. Is this  
mandatory or optional. Can they go in subdirectories. Do I need to  
experiment? E.g., how do I create a link to an action like 'new'? I  
know how to do it in Rails. Is it really a  tag in Nitro?

I believe 37s had a working app built on Rails before DHH open  
sourced it. While not completely stable, there was a lot of goodness  
baked in and people jumped on board. Generators were tres cool,  
because they encouraged good behavior like test-driven development.  
Directory structure was laid out in the initial application  
generation and generators kept people on the straight and narrow.  
These all tore down barriers to entry.

Lots to like about Nitro/Og. I just can't wrap my head around the  
lack of documentation right now.

Anyhow, that's my $.02 for the day.

--s

On Sep 21, 2007, at 10:13 AM, Kirk Haines wrote:

> People aren't going to choose what framework to
> use, or what ORM, or what library of utilities, based on the revision
> control system.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/065205e0/attachment.html 

From aidan at yoyo.org  Fri Sep 21 14:59:30 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Fri, 21 Sep 2007 19:59:30 +0100
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
Message-ID: 

I think there are three things that stop Nitro/Og from greatness:

1) Getting started is hard
2) Features are more highly valued than stability
3) Rails

Arguably, we're all here because we found things we didn't like with  
#3.  At the same time, I doubt there's anyone on this list who has  
not written at least one Rails app because it's easy to do.

#2 - George loves new features, and we have to be grateful for that -  
otherwise there'd be no Nitro!  Many of us just want it to work  
reliably and testably.

But #1 is what kills Nitro.  Last year I spent six months during  
which I was writing an app using Og and little bits of Nitro.  I  
contributed a few patches to the Og repo and I got to know the  
codebase intimately.  Now I come back and find that I have to learn  
everything again because so many things have changed: how to start an  
app, how to configure Og, how to build classes so that they are Og  
friendly (luckily that wasn't too different), etc.

Right now, Nitro has only one developer and that's George.  There are  
a few others out there whose contributions are patchy (pun  
intended).  We cannot expect George to do everything: maintain a  
website, mailing list, gems, repository AND write new features for 4  
codebases AND make sure it's all well tested AND write documentation.

Personally, I feel that a feature freeze is necessary - George, I  
think you are your own worst enemy in that regard :-)  However, given  
that none of us can prevent you from doing this and that it's  
probably what you enjoy doing most, perhaps we should branch the  
Nitro repository?

If we create a "stable" branch and a "development" branch and get  
stable to 1.0 as quickly as possible  - a full suite of specs,  
documentation, website etc.  Meanwhile, George and whoever else can  
continue to develop the bleeding edge but nothing gets checked into  
"stable" until it has specs, docs and good examples.

Thoughts?  Volunteers?

Whether you split Og off or not, I think the same applies for Og.   
I'd be happy to volunteer to get Og ready for prime-time (I know very  
little about Nitro).

Aidan

On Sep 21, 2007, at 9:15 AM, George Moschovitis wrote:

> The main thing is that Og needs to have it's own repository. By
> separating Og out from the Nitro framework, it can grow on it's own
> merits. This in turn will come back to benefit Nitro, as a matter of
> an independent development track, and as people adopt Og as their ORM
> of choice, they will also in turn be attracted to Nitro later for
> their website needs.
>
> Ok, I will do this.
>
> Another thing to consider is using Subversion rather than Darcs. I
> know Darcs is great. I miss it too in some respects. But it may be
> easier to share in development if there were in fact a central
> Rubyforge-hosted repository. This isn't as big a deal as the first
> point, but it's worth some serious consideration.
>
> Perhaps a readonly SVN repo  like James suggested is a better idea.
>
> Lastly, the website, http://nitroproject.org, HAS TO BE FINISHED!!! I
> can't stress that enough. An unfinished website is a big turn-off. It
> immediately reflects on the quality of the software itself. It's
>
> I don't have much time to work on the site.  Does anyone have any  
> time to work on this?
>
> Finally, let me say that I do have plans for creating some dynamic
> websites down the road, and I want to use Nitro, of course, but I've
> really been waiting for the framework to mature. I wish I could help
> more in that regard, but working on Facets is about all the time I
> have to contribute these days. Yet Nitro needs to mature. In fact, it
> has to mature if intends to be a truly viable option.
>
> I would think that Nitro is an ideal solution for you. It is the  
> most integrated framework with facets. And it is relatively mature.  
> Moreover, I will have one more developer working on-top of Nitro  
> full time from October 1st, so expect more progress. Hopefully, I  
> will have small amounts of money to sponsor some nitro/og bounties,  
> or we could even build a small Nitro fund for stuff like the site  
> or documentation (like the Rails guys did when they where starting).
>
> food for thought,
> -g.
>
>
> -- 
> http://www.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070921/6541894f/attachment-0001.html 

From transfire at gmail.com  Fri Sep 21 17:13:44 2007
From: transfire at gmail.com (Trans)
Date: Fri, 21 Sep 2007 21:13:44 -0000
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
	
Message-ID: <1190409224.278529.313590@50g2000hsm.googlegroups.com>



On Sep 21, 11:59 am, Aidan Rogers  wrote:
> I think there are three things that stop Nitro/Og from greatness:
>
> 1) Getting started is hard
> 2) Features are more highly valued than stability
> 3) Rails
>
> Arguably, we're all here because we found things we didn't like with
> #3.  At the same time, I doubt there's anyone on this list who has
> not written at least one Rails app because it's easy to do.
>
> #2 - George loves new features, and we have to be grateful for that -
> otherwise there'd be no Nitro!  Many of us just want it to work
> reliably and testably.
>
> But #1 is what kills Nitro.  Last year I spent six months during
> which I was writing an app using Og and little bits of Nitro.  I
> contributed a few patches to the Og repo and I got to know the
> codebase intimately.  Now I come back and find that I have to learn
> everything again because so many things have changed: how to start an
> app, how to configure Og, how to build classes so that they are Og
> friendly (luckily that wasn't too different), etc.
>
> Right now, Nitro has only one developer and that's George.  There are
> a few others out there whose contributions are patchy (pun
> intended).  We cannot expect George to do everything: maintain a
> website, mailing list, gems, repository AND write new features for 4
> codebases AND make sure it's all well tested AND write documentation.
>
> Personally, I feel that a feature freeze is necessary - George, I
> think you are your own worst enemy in that regard :-)  However, given
> that none of us can prevent you from doing this and that it's
> probably what you enjoy doing most, perhaps we should branch the
> Nitro repository?
>
> If we create a "stable" branch and a "development" branch and get
> stable to 1.0 as quickly as possible  - a full suite of specs,
> documentation, website etc.  Meanwhile, George and whoever else can
> continue to develop the bleeding edge but nothing gets checked into
> "stable" until it has specs, docs and good examples.
>
> Thoughts?  Volunteers?

Good assessment. A stable and development branch sound like a
reasonable idea. Even so, I think API stability from here out is going
to make or break us, so it might not matter as much as it would have.
Still, couldn't hurt and I could be wrong --George might be planning
to rewrite the whole system again ;)

> Whether you split Og off or not, I think the same applies for Og.
> I'd be happy to volunteer to get Og ready for prime-time (I know very
> little about Nitro).

Wow. Now there's a great offer. George?

T.


From james.britt at gmail.com  Fri Sep 21 23:38:50 2007
From: james.britt at gmail.com (James Britt)
Date: Fri, 21 Sep 2007 20:38:50 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>	<46F38FE5.7040303@tastapod.com>
		<46F3A1C6.5070701@tastapod.com>
	
Message-ID: <46F48E4A.1040501@gmail.com>

Kirk Haines wrote:
> On 9/21/07, Dan North  wrote:
> 
>> I'm only advocating it as a happy user - I have no other association with
>> mercurial, and I was using darcs for a while myself. I just find I prefer
>> mercurial for a bunch of weird intangible reasons.
> 
> (*nod*)  I've been using mercurial on my projects for quite a long
> time now, and as I mentioned when the revision control thing was last
> discussed early in the year, I am quite happy with it.

I, too, have been using Mercurial, but only recently. I'm happy, but 
have not yet done anything terribly complicated.


-- 
James Britt

"I often work by avoidance."
- Brian Eno

From rff_rff at yahoo.it  Sat Sep 22 04:11:12 2007
From: rff_rff at yahoo.it (gabriele renzi)
Date: Sat, 22 Sep 2007 08:11:12 +0000 (UTC)
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
Message-ID: 

On Fri, 21 Sep 2007 12:49:42 +0200, Dan North wrote:

> Mercurial is very "hackable", partly because it's written in python (is 
> that heresy on the nitro list?) and partly because the developers have 
> designed in some very useful extension points.

 I'm working on a project in django so not for me, I like python :) 
 
> There's an extension called record 
>  that 
> supports darcs-style cherry picking at commit time. Another called 
> transplant does the same between repositories. So it's not baked in but 
> it's not difficult.
> 
> I'm only advocating it as a happy user - I have no other association 
> with mercurial, and I was using darcs for a while myself. I just find I 
> prefer mercurial for a bunch of weird intangible reasons.

thanks Dan (and Kirk and James). 
I did use mercurial for like one month more than one year ago, 
but from that experience I only remember that it was fast yet had
something I didn't like. I'll have to give another try sooner or later :)



-- 
goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info


From george.moschovitis at gmail.com  Sat Sep 22 05:00:05 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 22 Sep 2007 12:00:05 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <1190394317.352479.14980@o80g2000hse.googlegroups.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
	<1190394317.352479.14980@o80g2000hse.googlegroups.com>
Message-ID: 

>
>
> Hmmm... well, it should only take a few minutes to comment out the
> dead links. That in itself is a good start. Then if you just fill in
> the image link "holes", the site would look 100% better just from
> that. Put an image link for Oxy and one for Facets too if you want.
> Almost anything is better than blank space.


I can do that in a reasonable time frame (ie the next 10 days).

including having the examples run without
> any fuss. I learn primarily by emulating examples, so it's important
> to me to see those working top notch so I have something to work off
> of.


I can't understand your problems with examples. The are extremely easy to
run...


-g.


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/c813209d/attachment.html 

From george.moschovitis at gmail.com  Sat Sep 22 05:08:08 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 22 Sep 2007 12:08:08 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
	
	
Message-ID: 

>
> Barrier three: Version conflicts. Right now, a gem install simply doesn't
> work. Try gem install rails and everything works as advertised. Try gem
> install nitro and virtually nothing works as advertised. Again, accepted
> that this will take a while. Still, ease of entry makes it a softer sell.
>

!!! I had the idea that gem install DOES work as advertized. You are trying
to install the 0.41.0 gems?


> I'm trying really hard to love Nitro and Og, but it's tough to know what's
> there. My expectations are clearly different from what's there. E.g.,
> what's the right directory structure. Not documented. Examples have
> templates in a flat directory called templates. Is this mandatory or
> optional.
>

you can put them in whichever directory you like, just setup

Template.root_dir = "my/dir"

Can they go in subdirectories. Do I need to experiment? E.g., how do I
> create a link to an action like 'new'? I know how to do it in Rails. Is it
> really a  tag in Nitro?
>

They can go in subdirectories... You can either map the controller on a
subdirectory:

app.dispatcher.root.my.subdir = MySubDirController

or use the following convention in your action name:

def my__sub__dir__action
end

maps to => my/sub/dir/action

you can use simple hrefs or some helpers:




or from a template in the controllers dir


please notice that the helper versions are aware of the routing systmem and
the mount point of your controllers.

-g.

-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/67289707/attachment.html 

From george.moschovitis at gmail.com  Sat Sep 22 05:10:35 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 22 Sep 2007 12:10:35 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
	
Message-ID: 

>
> If we create a "stable" branch and a "development" branch and get stable
> to 1.0 as quickly as possible  - a full suite of specs, documentation,
> website etc.  Meanwhile, George and whoever else can continue to develop the
> bleeding edge but nothing gets checked into "stable" until it has specs,
> docs and good examples.
>

Give me a day or two to think about that. And thank you for your volunteer
offer ;-)

-g.


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/bdc050a5/attachment.html 

From john at oxyliquit.de  Sat Sep 22 09:44:44 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Sat, 22 Sep 2007 15:44:44 +0200
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	
	
Message-ID: 

Hi,

> there is a stupid reason about this. I requested the oxy logo in some vector
> format so I can create a banner, but for some reason I never got it.
> jonathan can you send me the logo?

I know you requested the _font_ for the oxyliquit, which I forwarded to you from
my brother if I remember correctly.  Oh yeah, right, there was a font problem,
where the font was Mac only.

But, anything wrong with just using a png?

* http://www.oxyliquit.de/images/oxy2.png

You could just resize it.  If that isn't sufficient, I'm asking my bro for
the source (where you'd have the font missing, bad).

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From cwdinfo at gmail.com  Sat Sep 22 10:43:53 2007
From: cwdinfo at gmail.com (s.ross)
Date: Sat, 22 Sep 2007 07:43:53 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
	
	
	
Message-ID: <506BB1EE-8877-495F-8738-3009A8251642@gmail.com>

0.41 has all kinds of issues installing on OSX because it requires a  
particular version of facets. Even when installed, it has problems  
with managed classes and the default title rendering of title  
(sitetitle, if I remember correctly). I switched to the gems you  
emailed on the list and got further, but still not to a place where I  
could get the part/admin stuff working without the managed classes  
problem.

Thanks for the info. I will try to be more diligent about reporting  
complete errors, but was under the impression I would have been  
reporting against an out-of-date version.

--s

On Sep 22, 2007, at 2:08 AM, George Moschovitis wrote:

> Barrier three: Version conflicts. Right now, a gem install simply  
> doesn't work. Try gem install rails and everything works as  
> advertised. Try gem install nitro and virtually nothing works as  
> advertised. Again, accepted that this will take a while. Still,  
> ease of entry makes it a softer sell.
>
> !!! I had the idea that gem install DOES work as advertized. You  
> are trying to install the 0.41.0 gems?
>
> I'm trying really hard to love Nitro and Og, but it's tough to know  
> what's there. My expectations are clearly different from what's  
> there. E.g., what's the right directory structure. Not documented.  
> Examples have templates in a flat directory called templates. Is  
> this mandatory or optional.
>
> you can put them in whichever directory you like, just setup
>
> Template.root_dir = "my/dir"
>
> Can they go in subdirectories. Do I need to experiment? E.g., how  
> do I create a link to an action like 'new'? I know how to do it in  
> Rails. Is it really a  tag in Nitro?
>
> They can go in subdirectories... You can either map the controller  
> on a subdirectory:
>
> app.dispatcher.root.my.subdir = MySubDirController
>
> or use the following convention in your action name:
>
> def my__sub__dir__action
> end
>
> maps to => my/sub/dir/action
>
> you can use simple hrefs or some helpers:
>
> 
> 
> 
> or from a template in the controllers dir
> 
>
> please notice that the helper versions are aware of the routing  
> systmem and the mount point of your controllers.
>
> -g.
>
> -- 
> http://gmosx.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/47335b1f/attachment-0001.html 

From george.moschovitis at gmail.com  Sat Sep 22 14:15:19 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 22 Sep 2007 21:15:19 +0300
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: <506BB1EE-8877-495F-8738-3009A8251642@gmail.com>
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
	
	
	
	<506BB1EE-8877-495F-8738-3009A8251642@gmail.com>
Message-ID: 

>
> 0.41 has all kinds of issues installing on OSX because it requires a
> particular version of facets. Even when installed, it has problems with
> managed classes and the default title rendering of title (sitetitle, if I
> remember correctly). I switched to the gems you emailed on the list and got
> further, but still not to a place where I could get the part/admin stuff
> working without the managed classes problem.
>

Well I don't have OSX so I cannot test it. And this is the first time I
heard of problems on OSX. Maybe you can be more specific on the problems you
are facing with the repo version so I can fix them?

thanks,
-g.


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/8560073e/attachment.html 

From cwdinfo at gmail.com  Sat Sep 22 23:22:50 2007
From: cwdinfo at gmail.com (s.ross)
Date: Sat, 22 Sep 2007 20:22:50 -0700
Subject: [Nitro] RFC: Basic Points for a Better Nitro/Og
In-Reply-To: 
References: <1190307402.594187.188270@w3g2000hsg.googlegroups.com>
	<46F38FE5.7040303@tastapod.com> 
	<46F3A1C6.5070701@tastapod.com>
	<1190393258.355583.174860@k79g2000hse.googlegroups.com>
	
	
	
	<506BB1EE-8877-495F-8738-3009A8251642@gmail.com>
	
Message-ID: 

Here's an example:

/opt/local/lib/ruby/gems/1.8/gems/nitro-0.50.0/lib/nitro/part/admin/ 
og/controller.rb:33: uninitialized constant  
OgAdminController::FormHelper (NameError)
         from /opt/local/lib/ruby/site_ruby/1.8/rubygems/ 
custom_require.rb:27:in `gem_original_require'
         from /opt/local/lib/ruby/site_ruby/1.8/rubygems/ 
custom_require.rb:27:in `require'
         from /opt/local/lib/ruby/gems/1.8/gems/nitro-0.50.0/lib/ 
nitro/part/admin.rb:4
         from /opt/local/lib/ruby/site_ruby/1.8/rubygems/ 
custom_require.rb:27:in `gem_original_require'
         from /opt/local/lib/ruby/site_ruby/1.8/rubygems/ 
custom_require.rb:27:in `require'
         from run.rb:6

This was from the todo list tutorial on OxyWTF.



On Sep 22, 2007, at 11:15 AM, George Moschovitis wrote:

> 0.41 has all kinds of issues installing on OSX because it requires  
> a particular version of facets. Even when installed, it has  
> problems with managed classes and the default title rendering of  
> title (sitetitle, if I remember correctly). I switched to the gems  
> you emailed on the list and got further, but still not to a place  
> where I could get the part/admin stuff working without the managed  
> classes problem.
>
> Well I don't have OSX so I cannot test it. And this is the first  
> time I heard of problems on OSX. Maybe you can be more specific on  
> the problems you are facing with the repo version so I can fix them?
>
> thanks,
> -g.
>
>
> -- 
> http://gmosx.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070922/81cd77b1/attachment.html 

From transfire at gmail.com  Mon Sep 24 09:51:16 2007
From: transfire at gmail.com (Trans)
Date: Mon, 24 Sep 2007 13:51:16 -0000
Subject: [Nitro] TMail in Nitro
In-Reply-To: 
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
Message-ID: <1190641876.702548.272050@g4g2000hsf.googlegroups.com>



On Sep 19, 1:40 pm, "George Moschovitis"
 wrote:
> > TMail still in? If so have you emailed Minero about us setting up a
> > Rubyforge project for it? Do you want me too?
>
> It is still in, please contact minero!

Done. It's a go. I'll apply for the project today.

T.


From prpht9 at gmail.com  Tue Sep 25 15:53:39 2007
From: prpht9 at gmail.com (chris)
Date: Tue, 25 Sep 2007 15:53:39 -0400
Subject: [Nitro] Tor is not an HTTP Proxy
Message-ID: 

Is anyone else getting "Tor is not an HTTP Proxy" this when they access
oxywtf.de

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070925/a2bf0ca3/attachment.html 

From aurelianocalvo at yahoo.com.ar  Tue Sep 25 17:53:30 2007
From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo)
Date: Tue, 25 Sep 2007 18:53:30 -0300
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: 
References: 
Message-ID: <1340963a0709251453i472af0fbydc8ed08adc37231a@mail.gmail.com>

I am.

On 9/25/07, chris  wrote:
> Is anyone else getting "Tor is not an HTTP Proxy" this when they access
> oxywtf.de
>
> Chris
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From rob at robmela.com  Tue Sep 25 23:04:27 2007
From: rob at robmela.com (Robert Mela)
Date: Tue, 25 Sep 2007 23:04:27 -0400
Subject: [Nitro] context.post_params and very large files
Message-ID: <46F9CC3B.1050101@robmela.com>

It appears that post form data is read completely and stored in 
@context.post_params.   @context.raw_body also reads input completely.

For uploads of very large files would it a good idea to disable the full 
read and allow the programmer to read directly from from @context.in?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070925/597de9be/attachment.vcf 

From rob at robmela.com  Tue Sep 25 23:13:52 2007
From: rob at robmela.com (Robert Mela)
Date: Tue, 25 Sep 2007 23:13:52 -0400
Subject: [Nitro] Stupid file upload question
Message-ID: <46F9CE70.60805@robmela.com>

I've created a form ( using nforms.rb ) for doing a file upload.   I 
would like the saved file name on the server to have the same basename 
as the user's original file.  However, all I see in the uploaded data is 
the file contents.

Is there a way, w/o JavaScript, to capture the user's original file name 
in the post params?

Thanks in advance.

 #{form :action => "#{R :save}", :method => :post, 
:enctype=>'multipart/form-data' do |f|
    f.select_file :name => 'input_file' # file data accessed server-side as
                                        # @context.post_params['input_file']
    f.submit 'Save'
  end}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070925/116aad20/attachment.vcf 

From g.h.p.ebberink at nclr.nl  Wed Sep 26 02:18:07 2007
From: g.h.p.ebberink at nclr.nl (Gerald Ebberink)
Date: Wed, 26 Sep 2007 08:18:07 +0200
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: 
References: 
Message-ID: <46F9F99F.8080005@nclr.nl>

Yes.

chris wrote:
> Is anyone else getting "Tor is not an HTTP Proxy" this when they
> access oxywtf.de 
>
> Chris
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

From john at oxyliquit.de  Wed Sep 26 02:27:18 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 26 Sep 2007 08:27:18 +0200
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: 
References: 
Message-ID: 

Hi,

> Is anyone else getting "Tor is not an HTTP Proxy" this when they access
> oxywtf.de

thank you for reporting!

As to what happened:  I installed Tor to test it, I did nothing with it
and have no idea why it can hack up one domain and not both.  ^^;
Meaning, I better not test it right now until I find the reason.

Anyway, thank you very much,

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From george.moschovitis at gmail.com  Wed Sep 26 03:07:06 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 26 Sep 2007 10:07:06 +0300
Subject: [Nitro] context.post_params and very large files
In-Reply-To: <46F9CC3B.1050101@robmela.com>
References: <46F9CC3B.1050101@robmela.com>
Message-ID: 

This sounds reasonable. Is ti possible that you provide a patch for this? Or
at least, some more details about how this should be implemented.

thanks,
George.

On 9/26/07, Robert Mela  wrote:
>
> It appears that post form data is read completely and stored in
> @context.post_params.   @context.raw_body also reads input completely.
>
> For uploads of very large files would it a good idea to disable the full
> read and allow the programmer to read directly from from @context.in?
>
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070926/d3dd4654/attachment-0001.html 

From george.moschovitis at gmail.com  Wed Sep 26 03:11:27 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Wed, 26 Sep 2007 10:11:27 +0300
Subject: [Nitro] Stupid file upload question
In-Reply-To: <46F9CE70.60805@robmela.com>
References: <46F9CE70.60805@robmela.com>
Message-ID: 

>
> I've created a form ( using nforms.rb ) for doing a file upload.   I


First of all, nforms.rb is experimental. It will not be part of 0.50.0.

But I like that you are trying to use it, so I can get some constructive
remarks/suggestions about it ;-)

Is there a way, w/o JavaScript, to capture the user's original file name
> in the post params?
>
> Thanks in advance.
>
> #{form :action => "#{R :save}", :method => :post,
> :enctype=>'multipart/form-data' do |f|
>     f.select_file :name => 'input_file' # file data accessed server-side
> as
>                                         # @context.post_params
> ['input_file']
>     f.submit 'Save'
>   end}


Have you tried:

request[:my_file].original_filename
request[:my_file].content_type
r..].path
r..].local_path

etc?

-g.





-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070926/97ae5375/attachment.html 

From transfire at gmail.com  Wed Sep 26 09:17:06 2007
From: transfire at gmail.com (Trans)
Date: Wed, 26 Sep 2007 13:17:06 -0000
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1190641876.702548.272050@g4g2000hsf.googlegroups.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
Message-ID: <1190812626.642255.71790@50g2000hsm.googlegroups.com>



On Sep 24, 6:51 am, Trans  wrote:
> On Sep 19, 1:40 pm, "George Moschovitis"
>
>  wrote:
> > > TMail still in? If so have you emailed Minero about us setting up a
> > > Rubyforge project for it? Do you want me too?
>
> > It is still in, please contact minero!
>
> Done. It's a go. I'll apply for the project today.

I have some bad news about TMail. Turns out part of it is written in
C. I'm not a C programmer and don't feel like becoming one. So I don't
think I can maintain this project. Perhaps if we could convert the C
parts to Ruby, but I don't really have the time for that. Would anyone
else like to pursue it?

T.


From aurelianocalvo at yahoo.com.ar  Wed Sep 26 09:49:32 2007
From: aurelianocalvo at yahoo.com.ar (Aureliano Calvo)
Date: Wed, 26 Sep 2007 10:49:32 -0300
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1190812626.642255.71790@50g2000hsm.googlegroups.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
Message-ID: <1340963a0709260649j5d12b82fvd57df5e572e2e930@mail.gmail.com>

> > > > TMail still in? If so have you emailed Minero about us setting up a
> > > > Rubyforge project for it? Do you want me too?
> >
> > > It is still in, please contact minero!
> >
> > Done. It's a go. I'll apply for the project today.
>
> I have some bad news about TMail. Turns out part of it is written in
> C. I'm not a C programmer and don't feel like becoming one. So I don't
> think I can maintain this project. Perhaps if we could convert the C
> parts to Ruby, but I don't really have the time for that. Would anyone
> else like to pursue it?

Why don't you start with the TMail library inside Rail's Active
Support. AFAIK, it is "pure ruby".

From rob at robmela.com  Wed Sep 26 09:58:10 2007
From: rob at robmela.com (Robert Mela)
Date: Wed, 26 Sep 2007 09:58:10 -0400
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: 
References: 
Message-ID: <46FA6572.2060205@robmela.com>

I am, and using oxyliquit.de still produces the error if I click on 
screencasts or do a  search.

chris wrote:
> Is anyone else getting "Tor is not an HTTP Proxy" this when they 
> access oxywtf.de 
>
> Chris
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070926/f0ace158/attachment.vcf 

From wyhaines at gmail.com  Wed Sep 26 09:54:03 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 26 Sep 2007 06:54:03 -0700
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1190812626.642255.71790@50g2000hsm.googlegroups.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
Message-ID: 

On 9/26/07, Trans  wrote:
> I have some bad news about TMail. Turns out part of it is written in
> C. I'm not a C programmer and don't feel like becoming one. So I don't
> think I can maintain this project. Perhaps if we could convert the C
> parts to Ruby, but I don't really have the time for that. Would anyone
> else like to pursue it?

It's not that big of a deal.  The C portion isn't unwieldly, and there
is a pure ruby equivalent.  I have the pure ruby variant bundled with
IOWA, in fact, to be installed if one doesn't already have TMail on
the system.  The advantage of the C extension based one, obviously, is
that it is faster, but the pure ruby works, too.


Kirk Haines

From transfire at gmail.com  Wed Sep 26 10:19:06 2007
From: transfire at gmail.com (Trans)
Date: Wed, 26 Sep 2007 14:19:06 -0000
Subject: [Nitro] TMail in Nitro
In-Reply-To: 
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
	
Message-ID: <1190816346.396272.127180@d55g2000hsg.googlegroups.com>



On Sep 26, 6:54 am, "Kirk Haines"  wrote:
> On 9/26/07, Trans  wrote:
> It's not that big of a deal.  The C portion isn't unwieldly, and there
> is a pure ruby equivalent.  I have the pure ruby variant bundled with
> IOWA, in fact, to be installed if one doesn't already have TMail on
> the system.  The advantage of the C extension based one, obviously, is
> that it is faster, but the pure ruby works, too.

Hmmm... with the coming of YARV, is the speed boost all that
important? I've set up the Rubyforge site and svn repo:

  http://rubyforge.org/projects/tmail/
  http://rubyforge.org/scm/?group_id=4512

But as I said, just can't do the C thing. If it were just the bit of
code, it be one thing. But their's also build maintenance, and I just
don't know enough to be a good custodian to the project. Would you be
interested Kirk, since IOWA also uses it?

Is the IOWA TMail basically the one from Rails that Aureliano
mentions? I did not know Rails even had that.

T.


From wyhaines at gmail.com  Wed Sep 26 10:35:38 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 26 Sep 2007 07:35:38 -0700
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1340963a0709260649j5d12b82fvd57df5e572e2e930@mail.gmail.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
	<1340963a0709260649j5d12b82fvd57df5e572e2e930@mail.gmail.com>
Message-ID: 

On 9/26/07, Aureliano Calvo  wrote:

> Why don't you start with the TMail library inside Rail's Active
> Support. AFAIK, it is "pure ruby".

It is.  It's pulled from the same code as the one that I have in IOWA.


Kirk

From james.britt at gmail.com  Wed Sep 26 11:33:42 2007
From: james.britt at gmail.com (James Britt)
Date: Wed, 26 Sep 2007 08:33:42 -0700
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: 
References: 
	
Message-ID: <46FA7BD6.5020509@gmail.com>

Jonathan Buch wrote:
> Hi,
> 
>> Is anyone else getting "Tor is not an HTTP Proxy" this when they access
>> oxywtf.de
> 
> thank you for reporting!
> 
> As to what happened:  I installed Tor to test it, I did nothing with it
> and have no idea why it can hack up one domain and not both.  ^^;

Is proxy port used by oxywtf.de?  8118?


-- 
James Britt

"I can see them saying something like 'OMG Three Wizards Awesome'"
   - billinboston, on reddit.com

From transfire at gmail.com  Wed Sep 26 13:01:59 2007
From: transfire at gmail.com (Trans)
Date: Wed, 26 Sep 2007 17:01:59 -0000
Subject: [Nitro] TMail in Nitro
In-Reply-To: 
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
	
Message-ID: <1190826119.189355.15630@o80g2000hse.googlegroups.com>



On Sep 26, 6:54 am, "Kirk Haines"  wrote:
> On 9/26/07, Trans  wrote:
>
> > I have some bad news about TMail. Turns out part of it is written in
> > C. I'm not a C programmer and don't feel like becoming one. So I don't
> > think I can maintain this project. Perhaps if we could convert the C
> > parts to Ruby, but I don't really have the time for that. Would anyone
> > else like to pursue it?
>
> It's not that big of a deal.  The C portion isn't unwieldly, and there
> is a pure ruby equivalent.  I have the pure ruby variant bundled with
> IOWA, in fact, to be installed if one doesn't already have TMail on
> the system.  The advantage of the C extension based one, obviously, is
> that it is faster, but the pure ruby works, too.

Sigh, my original response to this got lost in the ether it seems.

I was just wondering if the C part is all that important given that
YARV is approaching. If it's not then I'll just do the Pure Ruby
version. Opinions?

OTOH, if the general opinion is that the C portion is worth
maintaining, then that's okay too, but we'll need someone else to help
with the project that has C experience. It's not so much the code the
keeps me from it, but the build process. I really have so little
experience in this area that I'd be all but helpless even to put out a
new release.

T.


From wyhaines at gmail.com  Wed Sep 26 14:38:46 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Wed, 26 Sep 2007 11:38:46 -0700
Subject: [Nitro] TMail in Nitro
In-Reply-To: <1190826119.189355.15630@o80g2000hse.googlegroups.com>
References: 
	<1189646741.008780.39930@22g2000hsm.googlegroups.com>
	
	<1190233571.297474.181280@o80g2000hse.googlegroups.com>
	
	<1190641876.702548.272050@g4g2000hsf.googlegroups.com>
	<1190812626.642255.71790@50g2000hsm.googlegroups.com>
	
	<1190826119.189355.15630@o80g2000hse.googlegroups.com>
Message-ID: 

On 9/26/07, Trans  wrote:

> I was just wondering if the C part is all that important given that
> YARV is approaching. If it's not then I'll just do the Pure Ruby
> version. Opinions?

YARV isn't going to change anything.  Stuff that is slow will still be
slow.  Stuff that needs a C extension to not be slow will still need
it.

> OTOH, if the general opinion is that the C portion is worth
> maintaining, then that's okay too, but we'll need someone else to help
> with the project that has C experience. It's not so much the code the
> keeps me from it, but the build process. I really have so little
> experience in this area that I'd be all but helpless even to put out a
> new release.

The problem with C extensions isn't the build process in general.  It's trivial.

It's the build process when dealing with Windows platforms that is
ugly.  This is because the compiler that one needs to use isn't
commercialy available (VC6).

That's where the pain lies.


Kirk

From john at oxyliquit.de  Thu Sep 27 02:27:10 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Thu, 27 Sep 2007 08:27:10 +0200
Subject: [Nitro] Session-store configuration
Message-ID: 

Hi,

Rob, George:

http://www.oxyliquit.de/question/96

Actually only George would have the authority to answer that question,
but that's my take on it.  :P

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From john at oxyliquit.de  Fri Sep 28 04:13:03 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Fri, 28 Sep 2007 10:13:03 +0200
Subject: [Nitro] Tor is not an HTTP Proxy
In-Reply-To: <46FA7BD6.5020509@gmail.com>
References: 
	 <46FA7BD6.5020509@gmail.com>
Message-ID: 

Hi,

>> As to what happened:  I installed Tor to test it, I did nothing with it
>> and have no idea why it can hack up one domain and not both.  ^^;
>
> Is proxy port used by oxywtf.de?  8118?

I found out what happened, before I ran oxy on Apache I used to run a
mongrel on port 9050 as backend which my nginx config still pointed to.
And that is the port for the socks proxy of Tor, which of course doesn't
make much sense.  :P

Problem solved.  :D

Jo

-- 
Feel the love
http://pinkjuice.com/pics/ruby.png

From mvyver at gmail.com  Fri Sep 28 05:25:02 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 28 Sep 2007 19:25:02 +1000
Subject: [Nitro] Og [patch]: Fix pre/post parsing in create_table_indices
	and two minor changes
Message-ID: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>

Fix pre/post parsing in create_table_indices and two minor changes

If accepted - kudos to Jonatjon for pointing out how to use ann(...)

:)

mark

From mvyver at gmail.com  Fri Sep 28 05:25:56 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 28 Sep 2007 19:25:56 +1000
Subject: [Nitro] Og [patch]: Fix pre/post parsing in
	create_table_indices and two minor changes
In-Reply-To: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
References: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
Message-ID: <389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>

this time with the patch...

On 9/28/07, Mark Van De Vyver  wrote:
> Fix pre/post parsing in create_table_indices and two minor changes
>
> If accepted - kudos to Jonatjon for pointing out how to use ann(...)
>
> :)
>
> mark
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mvdv-20070928-1.tar.gz
Type: application/x-gzip
Size: 18135 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070928/38593618/attachment-0001.gz 

From george.moschovitis at gmail.com  Fri Sep 28 08:41:18 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 28 Sep 2007 15:41:18 +0300
Subject: [Nitro] Og [patch]: Fix pre/post parsing in
	create_table_indices and two minor changes
In-Reply-To: <389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>
References: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
	<389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>
Message-ID: 

thanks,
-g.

On 9/28/07, Mark Van De Vyver  wrote:
> this time with the patch...
>
> On 9/28/07, Mark Van De Vyver  wrote:
> > Fix pre/post parsing in create_table_indices and two minor changes
> >
> > If accepted - kudos to Jonatjon for pointing out how to use ann(...)
> >
> > :)
> >
> > mark
> >
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From aidan at yoyo.org  Fri Sep 28 08:44:16 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Fri, 28 Sep 2007 13:44:16 +0100 (BST)
Subject: [Nitro] Og spinout / branching?
In-Reply-To: 
References: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
	<389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>
	
Message-ID: <43125.192.193.220.201.1190983456.squirrel@yoyo.org>

George,

Any decision on whether to make Og it's own project?  And/or to create a
"stable" and "development" branch?

Cheers,

Aidan

From george.moschovitis at gmail.com  Fri Sep 28 09:08:13 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 28 Sep 2007 16:08:13 +0300
Subject: [Nitro] Og spinout / branching?
In-Reply-To: <43125.192.193.220.201.1190983456.squirrel@yoyo.org>
References: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
	<389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>
	
	<43125.192.193.220.201.1190983456.squirrel@yoyo.org>
Message-ID: 

> Any decision on whether to make Og it's own project?  And/or to create a

I will create a separate repo for Og.

> "stable" and "development" branch?

I don't think this is really needed. Contrary to what many believe
there are not many changes in the repo, mostly bug fixes. I do my R&D
stuff in a private repo already.

I have 'allocated' this weekend for some long coding sessions,
hopefully this will include Nitro and Og ;-)

regards,
George.




-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From transfire at gmail.com  Fri Sep 28 11:20:29 2007
From: transfire at gmail.com (Trans)
Date: Fri, 28 Sep 2007 15:20:29 -0000
Subject: [Nitro] Og spinout / branching?
In-Reply-To: 
References: <389c43e40709280225xbee1755n35525962b4ae4b91@mail.gmail.com>
	<389c43e40709280225s7d12fa51i4038fda825d21c8a@mail.gmail.com>
	
	<43125.192.193.220.201.1190983456.squirrel@yoyo.org>
	
Message-ID: <1190992829.504286.291910@g4g2000hsf.googlegroups.com>



On Sep 28, 6:08 am, "George Moschovitis"
 wrote:
> > "stable" and "development" branch?
>
> I don't think this is really needed. Contrary to what many believe
> there are not many changes in the repo, mostly bug fixes. I do my R&D
> stuff in a private repo already.

Oh! Good to know.

T.


From mvyver at gmail.com  Fri Sep 28 21:11:22 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 29 Sep 2007 11:11:22 +1000
Subject: [Nitro] Og CRUD naming of methods
Message-ID: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>

Hi Devs

In [./manager.rb:initialize]
@store_class.allocate.destroy_db(@options) if
Og.destroy_schema||@options[:destroy]

and elsewhere there is this:

  alias_method :destroy, :drop_table
  alias_method :drop_schema, :drop_schema

Despite the typo (in the last alias) it seems there is confusion in
the code about whether a schema is a db or table...

Is it worth articulating following goal for Og to progress to?

To use C.R.U.D stubs to method names. so prepend:
create, read update, delete
to the following
*_db
*_table
*_row
*_field

I also think the abundance of aliases might hurt in the longer term -
it's driving me nuts.  Accepting there may be some pain to adopt these
conventions, but won't it help to have a consistent naming convention
that you don't have to scramble to the docs to check: 'Is it destroy,
drop, delete, table, tbl, schema, etc?"

my 2c after a frustrating few days :)

From t_leitner at gmx.at  Sat Sep 29 08:49:29 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Sat, 29 Sep 2007 14:49:29 +0200
Subject: [Nitro] [PATCH] Some small patches
Message-ID: <146AA715-9FE3-4BDF-A8DA-A0CBC1B5C9EE@gmx.at>

Hi,

I already tried to use 'darcs send' to send the patches to the  
repository, but this didn't work. So attached are some small patches  
for various parts of nitro/og.

Bye,
   Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: some_patches.gz
Type: application/x-gzip
Size: 18599 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070929/ca9eac76/attachment-0001.gz 

From george.moschovitis at gmail.com  Sat Sep 29 08:54:10 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 29 Sep 2007 15:54:10 +0300
Subject: [Nitro] [PATCH] Some small patches
In-Reply-To: <146AA715-9FE3-4BDF-A8DA-A0CBC1B5C9EE@gmx.at>
References: <146AA715-9FE3-4BDF-A8DA-A0CBC1B5C9EE@gmx.at>
Message-ID: 

use:

$darcs send -o bundle

this generates a file called bundle.

tar this file and mail it to the list.

thanks,
-g.

On 9/29/07, Thomas Leitner  wrote:
> Hi,
>
> I already tried to use 'darcs send' to send the patches to the
> repository, but this didn't work. So attached are some small patches
> for various parts of nitro/og.
>
> Bye,
>    Thomas
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From t_leitner at gmx.at  Sat Sep 29 08:56:37 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Sat, 29 Sep 2007 14:56:37 +0200
Subject: [Nitro] [PATCH] Some small patches
In-Reply-To: 
References: <146AA715-9FE3-4BDF-A8DA-A0CBC1B5C9EE@gmx.at>
	
Message-ID: <012276A6-DEDE-4716-8782-2FBDA4F09BFB@gmx.at>

I have used that command, but didn't tar the bundle, but gzipped it  
and attached it to my last email. If you need it as tar.gz I can  
resend it.

Bye,
   Thomas

On 29.09.2007, at 14:54, George Moschovitis wrote:

> use:
>
> $darcs send -o bundle
>
> this generates a file called bundle.
>
> tar this file and mail it to the list.
>
> thanks,
> -g.
>
> On 9/29/07, Thomas Leitner  wrote:
>> Hi,
>>
>> I already tried to use 'darcs send' to send the patches to the
>> repository, but this didn't work. So attached are some small patches
>> for various parts of nitro/og.
>>
>> Bye,
>>    Thomas
>>
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>>
>>
>
>
> -- 
> http://gmosx.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


From george.moschovitis at gmail.com  Sat Sep 29 08:59:22 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 29 Sep 2007 15:59:22 +0300
Subject: [Nitro] [PATCH] Some small patches
In-Reply-To: <012276A6-DEDE-4716-8782-2FBDA4F09BFB@gmx.at>
References: <146AA715-9FE3-4BDF-A8DA-A0CBC1B5C9EE@gmx.at>
	
	<012276A6-DEDE-4716-8782-2FBDA4F09BFB@gmx.at>
Message-ID: 

no it seems ok, will apply it later.

many thanks,
-g.

On 9/29/07, Thomas Leitner  wrote:
> I have used that command, but didn't tar the bundle, but gzipped it
> and attached it to my last email. If you need it as tar.gz I can
> resend it.
>
> Bye,
>    Thomas
>
> On 29.09.2007, at 14:54, George Moschovitis wrote:
>
> > use:
> >
> > $darcs send -o bundle
> >
> > this generates a file called bundle.
> >
> > tar this file and mail it to the list.
> >
> > thanks,
> > -g.
> >
> > On 9/29/07, Thomas Leitner  wrote:
> >> Hi,
> >>
> >> I already tried to use 'darcs send' to send the patches to the
> >> repository, but this didn't work. So attached are some small patches
> >> for various parts of nitro/og.
> >>
> >> Bye,
> >>    Thomas
> >>
> >>
> >> _______________________________________________
> >> Nitro-general mailing list
> >> Nitro-general at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/nitro-general
> >>
> >>
> >
> >
> > --
> > http://gmosx.me.gr
> > http://phidz.com
> > http://blog.gmosx.com
> > http://cull.gr
> > http://www.joy.gr
> > http://nitroproject.org
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Sat Sep 29 09:19:20 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 29 Sep 2007 16:19:20 +0300
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
Message-ID: 

I more or less agree with consistent naming. But, I am afraid this
will have to wait for a later version.

thanks for this *useful* post,
-g.

On 9/29/07, Mark Van De Vyver  wrote:
> Hi Devs
>
> In [./manager.rb:initialize]
> @store_class.allocate.destroy_db(@options) if
> Og.destroy_schema||@options[:destroy]
>
> and elsewhere there is this:
>
>   alias_method :destroy, :drop_table
>   alias_method :drop_schema, :drop_schema
>
> Despite the typo (in the last alias) it seems there is confusion in
> the code about whether a schema is a db or table...
>
> Is it worth articulating following goal for Og to progress to?
>
> To use C.R.U.D stubs to method names. so prepend:
> create, read update, delete
> to the following
> *_db
> *_table
> *_row
> *_field
>
> I also think the abundance of aliases might hurt in the longer term -
> it's driving me nuts.  Accepting there may be some pain to adopt these
> conventions, but won't it help to have a consistent naming convention
> that you don't have to scramble to the docs to check: 'Is it destroy,
> drop, delete, table, tbl, schema, etc?"
>
> my 2c after a frustrating few days :)
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From george.moschovitis at gmail.com  Sat Sep 29 09:20:59 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 29 Sep 2007 16:20:59 +0300
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: 
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
	
Message-ID: 

On second thoughts, If you have the time to go over the source code
and apply the naming conventions (while making sure that it doesnt
break everything) I could apply the patch in the current version.

-g.



On 9/29/07, George Moschovitis  wrote:
> I more or less agree with consistent naming. But, I am afraid this
> will have to wait for a later version.
>
> thanks for this *useful* post,
> -g.
>
> On 9/29/07, Mark Van De Vyver  wrote:
> > Hi Devs
> >
> > In [./manager.rb:initialize]
> > @store_class.allocate.destroy_db(@options) if
> > Og.destroy_schema||@options[:destroy]
> >
> > and elsewhere there is this:
> >
> >   alias_method :destroy, :drop_table
> >   alias_method :drop_schema, :drop_schema
> >
> > Despite the typo (in the last alias) it seems there is confusion in
> > the code about whether a schema is a db or table...
> >
> > Is it worth articulating following goal for Og to progress to?
> >
> > To use C.R.U.D stubs to method names. so prepend:
> > create, read update, delete
> > to the following
> > *_db
> > *_table
> > *_row
> > *_field
> >
> > I also think the abundance of aliases might hurt in the longer term -
> > it's driving me nuts.  Accepting there may be some pain to adopt these
> > conventions, but won't it help to have a consistent naming convention
> > that you don't have to scramble to the docs to check: 'Is it destroy,
> > drop, delete, table, tbl, schema, etc?"
> >
> > my 2c after a frustrating few days :)
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> >
>
>
> --
> http://gmosx.me.gr
> http://phidz.com
> http://blog.gmosx.com
> http://cull.gr
> http://www.joy.gr
> http://nitroproject.org
>


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From arne at arnebrasseur.net  Sat Sep 29 09:43:43 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Sat, 29 Sep 2007 21:43:43 +0800
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: 
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>	
	
Message-ID: <46FE568F.5000003@arnebrasseur.net>

Being all in favor of consistent naming could I still say : be careful 
with this? This is no breaking news but it's surprising how easy one 
overlooks something when renaming a method. And since the test suite is 
all but complete...

Ok, please carry on.

(ab)

George Moschovitis schreef:
> On second thoughts, If you have the time to go over the source code
> and apply the naming conventions (while making sure that it doesnt
> break everything) I could apply the patch in the current version.
>
> -g.
>
>
>
> On 9/29/07, George Moschovitis  wrote:
>   
>> I more or less agree with consistent naming. But, I am afraid this
>> will have to wait for a later version.
>>
>> thanks for this *useful* post,
>> -g.
>>
>> On 9/29/07, Mark Van De Vyver  wrote:
>>     
>>> Hi Devs
>>>
>>> In [./manager.rb:initialize]
>>> @store_class.allocate.destroy_db(@options) if
>>> Og.destroy_schema||@options[:destroy]
>>>
>>> and elsewhere there is this:
>>>
>>>   alias_method :destroy, :drop_table
>>>   alias_method :drop_schema, :drop_schema
>>>
>>> Despite the typo (in the last alias) it seems there is confusion in
>>> the code about whether a schema is a db or table...
>>>
>>> Is it worth articulating following goal for Og to progress to?
>>>
>>> To use C.R.U.D stubs to method names. so prepend:
>>> create, read update, delete
>>> to the following
>>> *_db
>>> *_table
>>> *_row
>>> *_field
>>>
>>> I also think the abundance of aliases might hurt in the longer term -
>>> it's driving me nuts.  Accepting there may be some pain to adopt these
>>> conventions, but won't it help to have a consistent naming convention
>>> that you don't have to scramble to the docs to check: 'Is it destroy,
>>> drop, delete, table, tbl, schema, etc?"
>>>
>>> my 2c after a frustrating few days :)
>>> _______________________________________________
>>> Nitro-general mailing list
>>> Nitro-general at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/nitro-general
>>>
>>>       
>> --
>> http://gmosx.me.gr
>> http://phidz.com
>> http://blog.gmosx.com
>> http://cull.gr
>> http://www.joy.gr
>> http://nitroproject.org
>>
>>     
>
>
>   


-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070929/4b9cf811/attachment.html 

From arne at arnebrasseur.net  Sat Sep 29 09:44:49 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Sat, 29 Sep 2007 21:44:49 +0800
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: <46FE568F.5000003@arnebrasseur.net>
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>		
	<46FE568F.5000003@arnebrasseur.net>
Message-ID: <46FE56D1.9040000@arnebrasseur.net>

Arne Brasseur schreef:
> Being all in favor of consistent naming could I still say : be careful 
> with this? This is no breaking news but it's surprising how easy one 
> overlooks something when renaming a method. And since the test suite 
> is all but complete...
I mean : far from complete...
>
> Ok, please carry on.
>
> (ab)
>
> George Moschovitis schreef:
>> On second thoughts, If you have the time to go over the source code
>> and apply the naming conventions (while making sure that it doesnt
>> break everything) I could apply the patch in the current version.
>>
>> -g.
>>
>>
>>
>> On 9/29/07, George Moschovitis  wrote:
>>   
>>> I more or less agree with consistent naming. But, I am afraid this
>>> will have to wait for a later version.
>>>
>>> thanks for this *useful* post,
>>> -g.
>>>
>>> On 9/29/07, Mark Van De Vyver  wrote:
>>>     
>>>> Hi Devs
>>>>
>>>> In [./manager.rb:initialize]
>>>> @store_class.allocate.destroy_db(@options) if
>>>> Og.destroy_schema||@options[:destroy]
>>>>
>>>> and elsewhere there is this:
>>>>
>>>>   alias_method :destroy, :drop_table
>>>>   alias_method :drop_schema, :drop_schema
>>>>
>>>> Despite the typo (in the last alias) it seems there is confusion in
>>>> the code about whether a schema is a db or table...
>>>>
>>>> Is it worth articulating following goal for Og to progress to?
>>>>
>>>> To use C.R.U.D stubs to method names. so prepend:
>>>> create, read update, delete
>>>> to the following
>>>> *_db
>>>> *_table
>>>> *_row
>>>> *_field
>>>>
>>>> I also think the abundance of aliases might hurt in the longer term -
>>>> it's driving me nuts.  Accepting there may be some pain to adopt these
>>>> conventions, but won't it help to have a consistent naming convention
>>>> that you don't have to scramble to the docs to check: 'Is it destroy,
>>>> drop, delete, table, tbl, schema, etc?"
>>>>
>>>> my 2c after a frustrating few days :)
>>>> _______________________________________________
>>>> Nitro-general mailing list
>>>> Nitro-general at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/nitro-general
>>>>
>>>>       
>>> --
>>> http://gmosx.me.gr
>>> http://phidz.com
>>> http://blog.gmosx.com
>>> http://cull.gr
>>> http://www.joy.gr
>>> http://nitroproject.org
>>>
>>>     
>>
>>
>>   
>
>
> -- 
> Arne Brasseur
> http://www.arnebrasseur.net
> arne at arnebrasseur.net
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070929/1d08d192/attachment-0001.html 

From lists at ruby-forum.com  Sat Sep 29 15:15:12 2007
From: lists at ruby-forum.com (Afa Reg)
Date: Sat, 29 Sep 2007 21:15:12 +0200
Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?=
Message-ID: 

??????
-- 
Posted via http://www.ruby-forum.com/.

From john at oxyliquit.de  Sat Sep 29 17:22:18 2007
From: john at oxyliquit.de (Jonathan Buch)
Date: Sat, 29 Sep 2007 23:22:18 +0200
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
Message-ID: 

Hi,

good points on making a single naming schema for whole Og.

While I do think that is generally a good idea, I propose on doing
what was originally the plan for the next release:

* Get test suite running

I'm starting to sound like a broken recording, sorry.  :/

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From aidan at yoyo.org  Sat Sep 29 17:32:24 2007
From: aidan at yoyo.org (Aidan Rogers)
Date: Sat, 29 Sep 2007 22:32:24 +0100
Subject: [Nitro] =?utf-8?b?5pSv5oyB5aSa55So5oi35LmI?=
In-Reply-To: 
References: 
Message-ID: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org>

???

On Sep 29, 2007, at 8:15 PM, Afa Reg wrote:

> ??????
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


From mvyver at gmail.com  Sat Sep 29 20:46:33 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sun, 30 Sep 2007 10:46:33 +1000
Subject: [Nitro] Og CRUD naming of methods
In-Reply-To: 
References: <389c43e40709281811o8331df4gca60b558e99ba02c@mail.gmail.com>
	
Message-ID: <389c43e40709291746w1bcd6b10r605e36c0916f9661@mail.gmail.com>

Hi,
On 9/30/07, Jonathan Buch  wrote:
> Hi,
>
> good points on making a single naming schema for whole Og.
>
> While I do think that is generally a good idea, I propose on doing
> what was originally the plan for the next release:
>
> * Get test suite running

I had in mind more of an ongoing goal.
And yes, this is easier done with confidence once the specs are complete.
At the moment I'm holding back DBI adapter commits until a large chunk
of functionality is done/settled will then send patches.

Do we invoke a rule at some point that patches only accepted with an
accompanying doc and some spec/test?  If we do this then there should
be more detail on the dev. page about any style choices.

Mark

>
> I'm starting to sound like a broken recording, sorry.  :/
>
> Jo
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

From george.moschovitis at gmail.com  Sun Sep 30 03:52:42 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sun, 30 Sep 2007 10:52:42 +0300
Subject: [Nitro] =?gb2312?b?1qez1rbg08O7p8O0?=
In-Reply-To: <36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org>
References: 
	<36944AFF-D373-41B6-B6B6-285392DD4F37@yoyo.org>
Message-ID: 

huh? ;-)

-g.

On 9/30/07, Aidan Rogers  wrote:
> ???
>
> On Sep 29, 2007, at 8:15 PM, Afa Reg wrote:
>
> > ??????
> > --
> > Posted via http://www.ruby-forum.com/.
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


-- 
http://gmosx.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org

From rob at robmela.com  Sun Sep 30 22:06:33 2007
From: rob at robmela.com (Robert Mela)
Date: Sun, 30 Sep 2007 22:06:33 -0400
Subject: [Nitro] Request#params
Message-ID: <47005629.60208@robmela.com>

Not sure what the intent is here in request.rb, module Raw, included in 
class Context

   31    def params
   32     if method == :post
   33             @post_params.instance_variable_get("@hash")
   34     else
   35             @get_params.instance_variable_get("@hash")
   36     end
   37    end


@post_params is itself a hash and an instance variable on Context,  and 
@post_params.instance_variable_get( "@hash" ) returns nil.

Anything wrong with doing this instead?

   31    def params
   32        return method == :post ? @post_params : @get_params
   33    end

If that's acceptable I'll add it to the patches I'm preparing.

thx.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070930/e386b3ff/attachment.vcf 

From rob at robmela.com  Sun Sep 30 22:29:42 2007
From: rob at robmela.com (Robert Mela)
Date: Sun, 30 Sep 2007 22:29:42 -0400
Subject: [Nitro] Request#params
In-Reply-To: <47005629.60208@robmela.com>
References: <47005629.60208@robmela.com>
Message-ID: <47005B96.9090401@robmela.com>

A second, related question --

OgAdminController#save attempts to access request data via the 'request' 
method call:

klass = name_to_class(*request*['object_class_name'].to_s)
obj.assign(*request*, :assign_relations => true, :force_boolean => true)

A couple problems

  - Major misnomer: request returns a @context object
  - @request does not have a [] method for accessing incoming request 
variables ( nor should it...)

I've worked around it for now by calling 
@context.post_params['object_class_name'] .... which led up to the 
question in my prev. email, since @context.params would be nicer...





Robert Mela wrote:
> Not sure what the intent is here in request.rb, module Raw, included 
> in class Context
>
>   31    def params
>   32     if method == :post
>   33             @post_params.instance_variable_get("@hash")
>   34     else
>   35             @get_params.instance_variable_get("@hash")
>   36     end
>   37    end
>
>
> @post_params is itself a hash and an instance variable on Context,  
> and @post_params.instance_variable_get( "@hash" ) returns nil.
>
> Anything wrong with doing this instead?
>
>   31    def params
>   32        return method == :post ? @post_params : @get_params
>   33    end
>
> If that's acceptable I'll add it to the patches I'm preparing.
>
> thx.
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070930/b3ca10ec/attachment.vcf