From mikisvaz at yahoo.com  Wed Aug  6 08:43:43 2008
From: mikisvaz at yahoo.com (miki)
Date: Wed, 6 Aug 2008 05:43:43 -0700 (PDT)
Subject: [Rake-devel] Lambda for multiple prerequisite rules
Message-ID: <340528.97779.qm@web51602.mail.re2.yahoo.com>

Hi all, I just came across what I think is a bug.

The following Rakefile

-----
rule (/a-b-c/) => lambda{|t| [[t.split('-')]]} do |t|
end

rule (/^[^-]*$/) do |t|
  puts t.name
end
-----

When invoked should render:

$ rake a-b-c-d-e
a
b
c
d
e

but instead renders:

$ rake a-b-c-d-e
a
a
a
a
a


Apparently  the rake.rb file reads:   

def attempt_rule(task_name, extensions, block, level)
      sources = make_sources(task_name, extensions)
      prereqs = sources.collect { |source|
        if File.exist?(source) || Rake::Task.task_defined?(source)
          source
        elsif parent = enhance_with_matching_rule(sources.first, level+1)
          parent.name
        else
          return nil
        end
      }
      task = FileTask.define_task({task_name => prereqs}, &block)
      task.sources = prereqs
      task
 end

I belive line:

        elsif parent = enhance_with_matching_rule(sources.first, level+1)

should be:

        elsif parent = enhance_with_matching_rule(source, level+1)

As this fixes the problem.


Kind regards

Miguel


      

From mikisvaz at yahoo.com  Wed Aug  6 14:55:24 2008
From: mikisvaz at yahoo.com (miki)
Date: Wed, 6 Aug 2008 11:55:24 -0700 (PDT)
Subject: [Rake-devel] Lambda for multiple prerequisite rules
Message-ID: <366080.59485.qm@web51609.mail.re2.yahoo.com>

I'm sorry, the example Rakefile was a little convoluted from playing around with it, It should be:

--------
rule (/-/) => lambda{|t| t.split('-')} do |t|
end

rule (/^[^-]*$/) do |t|
  puts t.name
end
---------

Cheers




----- Original Message ----
From: miki <mikisvaz at yahoo.com>
To: rake-devel at rubyforge.org
Sent: Wednesday, August 6, 2008 2:43:43 PM
Subject: [Rake-devel] Lambda for multiple prerequisite rules

Hi all, I just came across what I think is a bug.

The following Rakefile

-----
rule (/a-b-c/) => lambda{|t| [[t.split('-')]]} do |t|
end

rule (/^[^-]*$/) do |t|
  puts t.name
end
-----

When invoked should render:

$ rake a-b-c-d-e
a
b
c
d
e

but instead renders:

$ rake a-b-c-d-e
a
a
a
a
a


Apparently  the rake.rb file reads:  

def attempt_rule(task_name, extensions, block, level)
      sources = make_sources(task_name, extensions)
      prereqs = sources.collect { |source|
        if File.exist?(source) || Rake::Task.task_defined?(source)
          source
        elsif parent = enhance_with_matching_rule(sources.first, level+1)
          parent.name
        else
          return nil
        end
      }
      task = FileTask.define_task({task_name => prereqs}, &block)
      task.sources = prereqs
      task
end

I belive line:

        elsif parent = enhance_with_matching_rule(sources.first, level+1)

should be:

        elsif parent = enhance_with_matching_rule(source, level+1)

As this fixes the problem.


Kind regards

Miguel


      
_______________________________________________
Rake-devel mailing list
Rake-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/rake-devel



      

From dave at pragprog.com  Wed Aug  6 17:12:53 2008
From: dave at pragprog.com (Dave Thomas)
Date: Wed, 6 Aug 2008 16:12:53 -0500
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
Message-ID: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>

I'm converting our book production scripts from make to Rake, and seem  
to have bumped into an issue.

Say I want to convert XML to HTML via a couple of xslt scripts. I want  
to make the conversion trigger when the .html file is missing, or when  
it is out-of-date compared to the .xml file or either of the .xslt  
files. So, I have:

rule ".html" => [ ".cited-xml", HTML_XSL, LOCAL_HTML_XSL] do |t|
   xslt("ppb2html.xsl", t.source, t.name)
end

This rebuilds if the .html is out of date wrt the xml file, but  
ignores the timestamps on the two XSL files.

I guess my option is to synthesize file tasks for each of my possible  
targets, but this is one of many rules, and I have many HTML files-- 
I'd end up with hundreds if not thousands of tasks doing this.

Am I missing something obvious?


Dave

From jim.weirich at gmail.com  Thu Aug  7 00:57:54 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 7 Aug 2008 00:57:54 -0400
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
In-Reply-To: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
References: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
Message-ID: <0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>


On Aug 6, 2008, at 5:12 PM, Dave Thomas wrote:

> This rebuilds if the .html is out of date wrt the xml file, but  
> ignores the timestamps on the two XSL files.
>
> Am I missing something obvious?

You stumbled upon a bug that has been fixed in source control, but not  
yet released.  I tagged a version rake-0.8.1.5 on github with the  
fix.  This is the same version I've been using locally, so it is  
stable.  You can pull it down from github (http://github.com/jimweirich/rake 
), or I can send you a gem file if you don't want to mess with that.   
I'll be releasing version 0.8.2 with the fix (hopefully) soon.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From assaf at labnotes.org  Thu Aug  7 01:43:49 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Wed, 6 Aug 2008 22:43:49 -0700
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
In-Reply-To: <0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>
References: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
	<0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>
Message-ID: <64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>

On Aug 6, 2008, at 9:57 PM, Jim Weirich wrote:

>
> On Aug 6, 2008, at 5:12 PM, Dave Thomas wrote:
>
>> This rebuilds if the .html is out of date wrt the xml file, but  
>> ignores the timestamps on the two XSL files.
>>
>> Am I missing something obvious?
>
> You stumbled upon a bug that has been fixed in source control, but  
> not yet released.  I tagged a version rake-0.8.1.5 on github with  
> the fix.  This is the same version I've been using locally, so it is  
> stable.  You can pull it down from github (http://github.com/jimweirich/rake 
> ), or I can send you a gem file if you don't want to mess with  
> that.  I'll be releasing version 0.8.2 with the fix (hopefully) soon.

Github runs a gem server, you can make development gems available  
directly from there:

http://gems.github.com/

Assaf

>
>
> -- 
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel


From adam.q.salter at gmail.com  Thu Aug  7 02:11:46 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Thu, 7 Aug 2008 16:11:46 +1000
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
In-Reply-To: <64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>
References: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
	<0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>
	<64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>
Message-ID: <5D555426-8CCC-482A-810E-86A1281F65D4@gmail.com>

+1

Was just about to send Jim a message to say the same thing.

-Adam

On 07/08/2008, at 3:43 PM, Assaf Arkin wrote:

> On Aug 6, 2008, at 9:57 PM, Jim Weirich wrote:
>
>>
>> On Aug 6, 2008, at 5:12 PM, Dave Thomas wrote:
>>
>>> This rebuilds if the .html is out of date wrt the xml file, but  
>>> ignores the timestamps on the two XSL files.
>>>
>>> Am I missing something obvious?
>>
>> You stumbled upon a bug that has been fixed in source control, but  
>> not yet released.  I tagged a version rake-0.8.1.5 on github with  
>> the fix.  This is the same version I've been using locally, so it  
>> is stable.  You can pull it down from github (http://github.com/jimweirich/rake 
>> ), or I can send you a gem file if you don't want to mess with  
>> that.  I'll be releasing version 0.8.2 with the fix (hopefully) soon.
>
> Github runs a gem server, you can make development gems available  
> directly from there:
>
> http://gems.github.com/
>
> Assaf
>
>>
>>
>> -- 
>> -- Jim Weirich
>> -- jim.weirich at gmail.com
>>
>> _______________________________________________
>> Rake-devel mailing list
>> Rake-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rake-devel
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel

From jim.weirich at gmail.com  Thu Aug  7 03:55:09 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 7 Aug 2008 03:55:09 -0400
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
In-Reply-To: <64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>
References: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
	<0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>
	<64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>
Message-ID: <2CE42D31-8F3D-4623-BA19-9195AB819AF2@gmail.com>


On Aug 7, 2008, at 1:43 AM, Assaf Arkin wrote:

> Github runs a gem server, you can make development gems available  
> directly from there:
>
> http://gems.github.com/


Thanks for reminding me of that.  I've updated the rake repo to  
generate an 0.8.1.5 rake.  You will have to do the following to get it:

   $ gem sources -a http://gems.github.com (you only have to do this  
once)
   $ sudo gem install jimweirich-rake

[regarding github gems]

Hmmm... I'm not sure I like the gem package renaming.  That is bound  
to cause confusion.

And will it generate a new package with version 0.8.1.5 on every push  
to the remote repo?  If so, then that would mean that version 0.8.1.5  
means different things at different times.  I *really* don't like that.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From jim.weirich at gmail.com  Thu Aug  7 03:58:43 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 7 Aug 2008 03:58:43 -0400
Subject: [Rake-devel] Using rules (as opposed to tasks) with multiple
	dependencies
In-Reply-To: <2CE42D31-8F3D-4623-BA19-9195AB819AF2@gmail.com>
References: <81CA22D8-63C7-4D29-BE75-25FF5EC14520@pragprog.com>
	<0CA9B3DF-04D7-4E52-BEA8-BB24E11613D9@gmail.com>
	<64913746-CF80-44DC-9C40-1E0BCB00E417@labnotes.org>
	<2CE42D31-8F3D-4623-BA19-9195AB819AF2@gmail.com>
Message-ID: <F3040850-16B8-4C32-B57A-47D84D2C16B0@gmail.com>


On Aug 7, 2008, at 3:55 AM, Jim Weirich wrote:

> And will it generate a new package with version 0.8.1.5 on every  
> push to the remote repo? If so, then that would mean that version  
> 0.8.1.5 means different things at different times. I *really* don't  
> like that.

Nevermind.  I just answered my own question by reading the docs. :)   
Here's the scoop:

# Gems will only be built when the gemspec is modified on the master  
branch.

This is mostly reasonable.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From ittay.dror at gmail.com  Sun Aug 10 01:31:29 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Sun, 10 Aug 2008 08:31:29 +0300
Subject: [Rake-devel] 'thread tried to join itself'
Message-ID: <489E7D31.2000405@gmail.com>

Hi,

After building ruby with --disable-pthreads (which still leaves it 
linked to libpthread)  I started getting a 'thread tried to join itself' 
errors on the line '@lock.synchronize' in invoke_with_call_chain. After 
switching from Mutex to Monitor, the errors disappeared. Can you please 
commit the same change (apart from fixing my issue, I can't see any harm)

Thank you,
Ittay

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From jim.weirich at gmail.com  Sun Aug 10 01:46:34 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 10 Aug 2008 01:46:34 -0400
Subject: [Rake-devel] 'thread tried to join itself'
In-Reply-To: <489E7D31.2000405@gmail.com>
References: <489E7D31.2000405@gmail.com>
Message-ID: <6694AC1F-C0E7-46B5-A878-025FE22FC892@gmail.com>

On Aug 10, 2008, at 1:31 AM, Ittay Dror wrote:

> After building ruby with --disable-pthreads (which still leaves it  
> linked to libpthread)  I started getting a 'thread tried to join  
> itself' errors on the line '@lock.synchronize' in  
> invoke_with_call_chain. After switching from Mutex to Monitor, the  
> errors disappeared. Can you please commit the same change (apart  
> from fixing my issue, I can't see any harm)

Can you send a patch, or better yet, a github pull request?

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From ittay.dror at gmail.com  Sun Aug 10 02:26:12 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Sun, 10 Aug 2008 09:26:12 +0300
Subject: [Rake-devel] 'thread tried to join itself'
In-Reply-To: <6694AC1F-C0E7-46B5-A878-025FE22FC892@gmail.com>
References: <489E7D31.2000405@gmail.com>
	<6694AC1F-C0E7-46B5-A878-025FE22FC892@gmail.com>
Message-ID: <489E8A04.8040105@gmail.com>

this is the change vs. the latest from trunk:
Index: lib/rake.rb
===================================================================
--- lib/rake.rb    (revision 649)
+++ lib/rake.rb    (working copy)
@@ -37,6 +37,7 @@
 require 'singleton'
 require 'thread'
 require 'ostruct'
+require 'monitor'
 
 ######################################################################
 # Rake extensions to Module.
@@ -451,7 +452,7 @@
       @already_invoked = false
       @full_comment = nil
       @comment = nil
-      @lock = Mutex.new
+      @lock = Monitor.new
       @application = app
       @scope = app.current_scope
       @arg_names = nil


Jim Weirich wrote:
> On Aug 10, 2008, at 1:31 AM, Ittay Dror wrote:
>
>> After building ruby with --disable-pthreads (which still leaves it 
>> linked to libpthread)  I started getting a 'thread tried to join 
>> itself' errors on the line '@lock.synchronize' in 
>> invoke_with_call_chain. After switching from Mutex to Monitor, the 
>> errors disappeared. Can you please commit the same change (apart from 
>> fixing my issue, I can't see any harm)
>
> Can you send a patch, or better yet, a github pull request?
>

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From jim.weirich at gmail.com  Sun Aug 10 18:56:59 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 10 Aug 2008 18:56:59 -0400
Subject: [Rake-devel] 'thread tried to join itself'
In-Reply-To: <489E8A04.8040105@gmail.com>
References: <489E7D31.2000405@gmail.com>
	<6694AC1F-C0E7-46B5-A878-025FE22FC892@gmail.com>
	<489E8A04.8040105@gmail.com>
Message-ID: <D9AEA098-3568-4C2C-86DB-9A2A84DFC2CB@gmail.com>

On Aug 10, 2008, at 2:26 AM, Ittay Dror wrote:

> this is the change vs. the latest from trunk:

Thanks.  Your ticket has been entered: http://onestepback.org/redmine/issues/show/11

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From jim.weirich at gmail.com  Sun Aug 10 20:04:33 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 10 Aug 2008 20:04:33 -0400
Subject: [Rake-devel] patch: fail stack
In-Reply-To: <94d1df920804230601v296fee17xe1544b730c31f31b@mail.gmail.com>
References: <94d1df920804230540p33d95765k2ac6e9fb99185ede@mail.gmail.com>
	<94d1df920804230601v296fee17xe1544b730c31f31b@mail.gmail.com>
Message-ID: <1865886A-2CD8-4AF0-8B76-ECD2F5895484@gmail.com>


On Apr 23, 2008, at 9:01 AM, Frank van Viegen wrote:

> Small patch that extends the 'fail' method to show the task stack at
> the moment of the error. It has helped me a lot when debugging
> complicated rakefiles.

Hi Frank.  I'm trying to clear out some outstanding rake feedback and  
took a look at your task stack dump at failure (sorry it took so long  
to get to it).

I've provided some feedback at: http://onestepback.org/redmine/issues/show/3 
.  You can either resubmit you patch with the requested changes, or  
just wait because I might just do it myself if I find the time.

Thanks for your feedback.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From jim.weirich at gmail.com  Sun Aug 10 22:37:35 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 10 Aug 2008 22:37:35 -0400
Subject: [Rake-devel] Redmine site setup for Rake
Message-ID: <CFDFDC24-4EB8-4696-A727-4980953CABBF@gmail.com>

I've been using a private account on LightHouse to track requests and  
bugs on Rake (and other software).  That worked great for me, but  
didn't give anyone else any visibility on the process.

So I've installed a copy of RedMine on my server and have migrated  
over all the open tickets from LightHouse.  You can see it here: http://onestepback.org/redmine/projects/show/rake

I'm trying to get better at dealing with things in a timely manner, so  
feel free to ping me if something lays idle too long.

Thanks to everyone for their patches, bug reports and feedback in the  
building of rake.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From ittay.dror at gmail.com  Mon Aug 11 03:14:41 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Mon, 11 Aug 2008 10:14:41 +0300
Subject: [Rake-devel] recursive task invocation
Message-ID: <489FE6E1.1070102@gmail.com>

Hi,

I'm running a Buildr build and after 20 recursive prerequisites Ruby's 
call stack is exhausted and I get a segmentation fault. The number of 
modules and dependencies is large, so I can't decrease the prerequisites.

How about doing an iterative DFS search on the prerequisites to order 
them and then invoke them according to order?

There are  a few other benefits, besides not needing recursion:
1. it allows to find circular dependencies before starting the invocation
2. it allows for rake to utilize threads to invoke the list of tasks 
(assuming actions don't conflict)

Note that currently tasks can "cheat" and add prerequisites lazily when 
invoked by overriding invoke_prerequisites. This can be achieved with 
the above suggestion by letting them override the prerequisites accessor.

Drawbacks:
This doesn't allow for a task's action to add prerequisites to sibling 
tasks during the invocation chain (unless an API is provided to allow 
changing the invocation list during invocation)

What do you think? I don't mind implementing this, but obviously it is a 
big change.
Ittay

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From ittay.dror at gmail.com  Mon Aug 11 03:48:08 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Mon, 11 Aug 2008 10:48:08 +0300
Subject: [Rake-devel] JobTask
Message-ID: <489FEEB8.1070707@gmail.com>

Hi,

I want to post a mixin that can be used to turn any task into one that 
runs its prerequisites in threads. The difference with MultiTask is that 
MultiTask creates a separate thread per prerequisites which causes 
thrashing if there are many (esp. for tasks that do IO, like compile tasks).

There are two files. The first is thread_pool.rb which provides a 
general thread pool implementation. I've tried several implementations 
and this is the only one that worked reliably for me. The second is the 
mixin. (actually, in the patch the order is reversed)

The patch is attached.

HTH,
Ittay


-- 
--
Ittay Dror <ittay.dror at gmail.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jobtask.patch
Type: text/x-diff
Size: 3389 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/rake-devel/attachments/20080811/6e3f06f3/attachment.bin>

From ittay.dror at gmail.com  Mon Aug 11 09:35:34 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Mon, 11 Aug 2008 16:35:34 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <489FE6E1.1070102@gmail.com>
References: <489FE6E1.1070102@gmail.com>
Message-ID: <48A04026.7080701@gmail.com>



Ittay Dror wrote:
> Hi,
>
> I'm running a Buildr build and after 20 recursive prerequisites Ruby's 
> call stack is exhausted and I get a segmentation fault. The number of 
> modules and dependencies is large, so I can't decrease the prerequisites.
>
> How about doing an iterative DFS search on the prerequisites to order 
> them and then invoke them according to order?
>
> There are  a few other benefits, besides not needing recursion:
> 1. it allows to find circular dependencies before starting the invocation
> 2. it allows for rake to utilize threads to invoke the list of tasks 
> (assuming actions don't conflict)
Note that the current use of threads, in either MultiTask, or the 
JobTask I sent earlier is faulty. Imagine tasks A, B, C, D where  A => 
[B, C], B=>[D], C=>[D]. Now if B and C are invoked in parallel, C 
invokes D which fails. C promptly fails. B continues to run and to it D 
seems to have been already invoked, so it does its actions assuming D's 
actions were executed which isn't true. Now even if the 
MultiTask/JobTask were to cause all other threads to fail, there can be 
nested MultiTask/JobTask already running and the whole issue becomes messy.
>
> Note that currently tasks can "cheat" and add prerequisites lazily 
> when invoked by overriding invoke_prerequisites. This can be achieved 
> with the above suggestion by letting them override the prerequisites 
> accessor.
>
> Drawbacks:
> This doesn't allow for a task's action to add prerequisites to sibling 
> tasks during the invocation chain (unless an API is provided to allow 
> changing the invocation list during invocation)
>
> What do you think? I don't mind implementing this, but obviously it is 
> a big change.
> Ittay
>

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From jim.weirich at gmail.com  Mon Aug 11 11:24:06 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 11 Aug 2008 11:24:06 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <48A04026.7080701@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A04026.7080701@gmail.com>
Message-ID: <8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>


On Aug 11, 2008, at 9:35 AM, Ittay Dror wrote:

> Note that the current use of threads, in either MultiTask, or the  
> JobTask I sent earlier is faulty. Imagine tasks A, B, C, D where  A  
> => [B, C], B=>[D], C=>[D]. Now if B and C are invoked in parallel, C  
> invokes D which fails. C promptly fails. B continues to run and to  
> it D seems to have been already invoked, so it does its actions  
> assuming D's actions were executed which isn't true.


Do we need some kind of error state, eg. invoked, but failed?

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From hgs at dmu.ac.uk  Mon Aug 11 11:47:13 2008
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Mon, 11 Aug 2008 16:47:13 +0100 (BST)
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A04026.7080701@gmail.com>
	<8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
Message-ID: <alpine.LFD.1.10.0808111639410.31586@trueman.cs.cse.dmu.ac.uk>



On Mon, 11 Aug 2008, Jim Weirich wrote:

>
> On Aug 11, 2008, at 9:35 AM, Ittay Dror wrote:
>
>> Note that the current use of threads, in either MultiTask, or the JobTask I 
>> sent earlier is faulty. Imagine tasks A, B, C, D where  A => [B, C], 
>> B=>[D], C=>[D]. Now if B and C are invoked in parallel, C invokes D which 
>> fails. C promptly fails. B continues to run and to it D seems to have been 
>> already invoked, so it does its actions assuming D's actions were executed 
>> which isn't true.
>
>
> Do we need some kind of error state, eg. invoked, but failed?

I've wished for a means of saying task w depends on any of [t,u,v]
succeeding, but I don't care which, but if one works, don't do the
others.  I can't remember the application now.

Also, it might be interesting to poke about in the fault tolerant
shell for inspiration.

http://www.cse.nd.edu/~ccl/software/ftsh/

         Hugh

From ittay.dror at gmail.com  Mon Aug 11 13:37:40 2008
From: ittay.dror at gmail.com (Ittay Dror (Freiman))
Date: Mon, 11 Aug 2008 20:37:40 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A04026.7080701@gmail.com>
	<8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
Message-ID: <667c668f0808111037g601dc91fv134c64f177aae96@mail.gmail.com>

On Mon, Aug 11, 2008 at 6:24 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 11, 2008, at 9:35 AM, Ittay Dror wrote:
>
>> Note that the current use of threads, in either MultiTask, or the JobTask
>> I sent earlier is faulty. Imagine tasks A, B, C, D where  A => [B, C],
>> B=>[D], C=>[D]. Now if B and C are invoked in parallel, C invokes D which
>> fails. C promptly fails. B continues to run and to it D seems to have been
>> already invoked, so it does its actions assuming D's actions were executed
>> which isn't true.
>
>
> Do we need some kind of error state, eg. invoked, but failed?

My initial suggestion is to linearize the invocation process. Then, if
a task fails, Rake stops the execution. If a developer wants the
execution to continue even if some actions fail, he writes those
actions such that they return normally (begin...rescue).
>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From jim.weirich at gmail.com  Mon Aug 11 17:50:25 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 11 Aug 2008 17:50:25 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <667c668f0808111037g601dc91fv134c64f177aae96@mail.gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A04026.7080701@gmail.com>
	<8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
	<667c668f0808111037g601dc91fv134c64f177aae96@mail.gmail.com>
Message-ID: <11F23D3B-228F-44A8-82D8-3EC915512199@gmail.com>


On Aug 11, 2008, at 1:37 PM, Ittay Dror (Freiman) wrote:

> My initial suggestion is to linearize the invocation process. Then, if
> a task fails, Rake stops the execution. If a developer wants the
> execution to continue even if some actions fail, he writes those
> actions such that they return normally (begin...rescue).

Isn't this what happens now?  The problem only occurs if using the  
multitalk options, right?

Or am I misunderstanding?

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From assaf at labnotes.org  Mon Aug 11 18:37:48 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Mon, 11 Aug 2008 15:37:48 -0700
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A04026.7080701@gmail.com>
	<8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>
Message-ID: <5037b6e40808111537i54c84930q3f9bfc214705e24a@mail.gmail.com>

On Mon, Aug 11, 2008 at 8:24 AM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 11, 2008, at 9:35 AM, Ittay Dror wrote:
>
>> Note that the current use of threads, in either MultiTask, or the JobTask
>> I sent earlier is faulty. Imagine tasks A, B, C, D where  A => [B, C],
>> B=>[D], C=>[D]. Now if B and C are invoked in parallel, C invokes D which
>> fails. C promptly fails. B continues to run and to it D seems to have been
>> already invoked, so it does its actions assuming D's actions were executed
>> which isn't true.
>
>
> Do we need some kind of error state, eg. invoked, but failed?

Possibly.  If you invoke the same task twice and the invocation fails,
you only get an exception on the first invocation, the second one will
succeed since the task is marked as invoked, which could lead to the
wrong outcome.

Assaf

>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From ittay.dror at gmail.com  Mon Aug 11 23:21:07 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Tue, 12 Aug 2008 06:21:07 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <11F23D3B-228F-44A8-82D8-3EC915512199@gmail.com>
References: <489FE6E1.1070102@gmail.com>
	<48A04026.7080701@gmail.com>	<8A04F3D1-57BB-498B-A321-B52BAD4A857A@gmail.com>	<667c668f0808111037g601dc91fv134c64f177aae96@mail.gmail.com>
	<11F23D3B-228F-44A8-82D8-3EC915512199@gmail.com>
Message-ID: <48A101A3.7040309@gmail.com>



Jim Weirich wrote:
>
> On Aug 11, 2008, at 1:37 PM, Ittay Dror (Freiman) wrote:
>
>> My initial suggestion is to linearize the invocation process. Then, if
>> a task fails, Rake stops the execution. If a developer wants the
>> execution to continue even if some actions fail, he writes those
>> actions such that they return normally (begin...rescue).
>
> Isn't this what happens now?  The problem only occurs if using the 
> multitalk options, right?
>
> Or am I misunderstanding?
i meant to suggest making the invocation of tasks and iterative process 
rather than recursive.

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From adamm at zombino.com  Tue Aug 12 15:32:29 2008
From: adamm at zombino.com (Adam Majer)
Date: Tue, 12 Aug 2008 14:32:29 -0500
Subject: [Rake-devel] Current rake version number?
In-Reply-To: <4C0671AE-452A-4F82-89DE-15A30F62031D@gmail.com>
References: <488CE094.9070904@zombino.com>
	<4C0671AE-452A-4F82-89DE-15A30F62031D@gmail.com>
Message-ID: <48A1E54D.6040405@zombino.com>

Jim Weirich wrote:
> 
> On Jul 27, 2008, at 4:54 PM, Adam Majer wrote:
>> Currently github is listed as the development place for rake, but the
>> README still talks about rubyforge and there is no mention of the
>> current revision control used except in the mailing lists. Someone not
> 
> Hmmm, you're right.  There is no non-mailing notice that Rake SCM has
> moved to GitHub.  I'll add something to the README file.  Is there
> somewhere else where it would be good to place this notice.
> 
> I plan to keep the subversion repo in place for the moment and push
> major releases out to it.  But the github repo will be the one with the
> latest stuff on it.  Do you see a problem with this?

Yes, README is a good place. Make sure that the project's mainpage is
also updated at rake.rubyforge.org

>> Secondly, if you are tagging versions, could you please tag the versions
>> with a signed tag? Currently there are no tags which makes GIT less
>> reliable.
> 
> I've not made any official releases off the git repository yet, but when
> I do I will tag it.  I generally don't tag intermediate releases (didn't
> in the subversion repo either).  Is this something to reconsider?
> 
> Re: signed tags ... never done one, let me look into it.

In my opinion, singed tags are very important. All you do is,

  git tag -s <tag_name>

instead of,

  git tag <tag_name>

And it will sign it with your GPG key. Then place the key id in the
README as well. If your key is already signed by other people (web of
trust), that helps, but even newly generated GPG key is better than nothing.

The idea is if you crypto signed something, it becomes very difficult,
if not impossible, for someone to change the source code to that
revision (or previous revisions). It also prevents them from removing
the tag and put their own as people would expect a signed tag by you.

- Adam

From adam.q.salter at gmail.com  Tue Aug 12 21:18:24 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Wed, 13 Aug 2008 11:18:24 +1000
Subject: [Rake-devel] Redmine site setup for Rake
In-Reply-To: <CFDFDC24-4EB8-4696-A727-4980953CABBF@gmail.com>
References: <CFDFDC24-4EB8-4696-A727-4980953CABBF@gmail.com>
Message-ID: <BB4304CB-11D6-4FDD-878B-F4ADD14DB61D@gmail.com>

Jim,
Do you want us to just raise bugs in Redmine for stuff that hasn't  
been implemented yet?

E.g. I put in a request for ~/.rake, and submitted a patch.

Obviously it would still be up to you to choose the version to  
implement in (e.g. 0.8.2 or later), but at least bugs could be easily  
tracked.

-Adam


On 11/08/2008, at 12:37 PM, Jim Weirich wrote:

> I've been using a private account on LightHouse to track requests  
> and bugs on Rake (and other software).  That worked great for me,  
> but didn't give anyone else any visibility on the process.
>
> So I've installed a copy of RedMine on my server and have migrated  
> over all the open tickets from LightHouse.  You can see it here: http://onestepback.org/redmine/projects/show/rake
>
> I'm trying to get better at dealing with things in a timely manner,  
> so feel free to ping me if something lays idle too long.
>
> Thanks to everyone for their patches, bug reports and feedback in  
> the building of rake.
>
> -- 
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel

From jim.weirich at gmail.com  Tue Aug 12 21:30:04 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Tue, 12 Aug 2008 21:30:04 -0400
Subject: [Rake-devel] Redmine site setup for Rake
In-Reply-To: <BB4304CB-11D6-4FDD-878B-F4ADD14DB61D@gmail.com>
References: <CFDFDC24-4EB8-4696-A727-4980953CABBF@gmail.com>
	<BB4304CB-11D6-4FDD-878B-F4ADD14DB61D@gmail.com>
Message-ID: <604DE49B-A2CD-4AD2-9085-7D558D1AF559@gmail.com>


On Aug 12, 2008, at 9:18 PM, Adam Salter wrote:

> Jim,
> Do you want us to just raise bugs in Redmine for stuff that hasn't  
> been implemented yet?
>
> E.g. I put in a request for ~/.rake, and submitted a patch.
>
> Obviously it would still be up to you to choose the version to  
> implement in (e.g. 0.8.2 or later), but at least bugs could be  
> easily tracked.

Yes.  Go ahead and post any bugs/feature requests to the redmine  
sight.  Drop me a note when you register (I don't have outgoing mail  
setup on that host yet), and I will enable you as a reporter.

And yes, please add you .rake patch to the tracker (or send me a  
github pull request).

Thanks.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From ittay.dror at gmail.com  Wed Aug 13 01:50:48 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Wed, 13 Aug 2008 08:50:48 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <489FE6E1.1070102@gmail.com>
References: <489FE6E1.1070102@gmail.com>
Message-ID: <48A27638.3020104@gmail.com>

Is there no interest in the suggestion made below?

Ittay Dror wrote:
> Hi,
>
> I'm running a Buildr build and after 20 recursive prerequisites Ruby's 
> call stack is exhausted and I get a segmentation fault. The number of 
> modules and dependencies is large, so I can't decrease the prerequisites.
>
> How about doing an iterative DFS search on the prerequisites to order 
> them and then invoke them according to order?
>
> There are  a few other benefits, besides not needing recursion:
> 1. it allows to find circular dependencies before starting the invocation
> 2. it allows for rake to utilize threads to invoke the list of tasks 
> (assuming actions don't conflict)
>
> Note that currently tasks can "cheat" and add prerequisites lazily 
> when invoked by overriding invoke_prerequisites. This can be achieved 
> with the above suggestion by letting them override the prerequisites 
> accessor.
>
> Drawbacks:
> This doesn't allow for a task's action to add prerequisites to sibling 
> tasks during the invocation chain (unless an API is provided to allow 
> changing the invocation list during invocation)
>
> What do you think? I don't mind implementing this, but obviously it is 
> a big change.
> Ittay
>

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From Patrick.Bennett at inin.com  Wed Aug 13 11:27:42 2008
From: Patrick.Bennett at inin.com (Bennett, Patrick)
Date: Wed, 13 Aug 2008 11:27:42 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <48A27638.3020104@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
Message-ID: <260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>

>Is there no interest in the suggestion made below?

> Drawbacks:
> This doesn't allow for a task's action to add prerequisites to sibling

> tasks during the invocation chain (unless an API is provided to allow 
> changing the invocation list during invocation)

For me at least, this is a *huge* drawback.  I add new tasks and modify
existing tasks during task execution all the time.
Having the execution order determined all at once up-front would be a
big problem.

Patrick Bennett


From ittay.dror at gmail.com  Wed Aug 13 12:34:25 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Wed, 13 Aug 2008 19:34:25 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
Message-ID: <48A30D11.1010806@gmail.com>



Bennett, Patrick wrote:
>> Is there no interest in the suggestion made below?
>>     
>
>   
>> Drawbacks:
>> This doesn't allow for a task's action to add prerequisites to sibling
>>     
>
>   
>> tasks during the invocation chain (unless an API is provided to allow 
>> changing the invocation list during invocation)
>>     
>
> For me at least, this is a *huge* drawback.  I add new tasks and modify
> existing tasks during task execution all the time.
> Having the execution order determined all at once up-front would be a
> big problem.
>   
The flow is like this:
* you build the task dependency tree as today
* rake starts to invoke the top tasks:
  * instead of letting each task invoke its prerequisites, rake asks it 
to return its prerequisites
     * so here you can override the 'prerequisites' method and add and 
modify tasks
  * now rake orders the prerequisites according to their dependencies 
and executes them

This is just making the flow iterative instead of recursive: explicitly 
maintaining the stack of tasks instead of relying on ruby's call stack. 
I don't think much will change. But, by avoiding recursion, there's no 
risk of exhausting the call stack and there's a much better way of 
parallelizing the build

Ittay
> Patrick Bennett
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>   

-- 
--
Ittay Dror <ittay.dror at gmail.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rake-devel/attachments/20080813/39e58ad1/attachment.html>

From assaf at labnotes.org  Wed Aug 13 12:55:02 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Wed, 13 Aug 2008 09:55:02 -0700
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <48A30D11.1010806@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<48A30D11.1010806@gmail.com>
Message-ID: <5037b6e40808130955me6dece3jfd4d1dd9a26b3c68@mail.gmail.com>

On Wed, Aug 13, 2008 at 9:34 AM, Ittay Dror <ittay.dror at gmail.com> wrote:
>
>
> Bennett, Patrick wrote:
>
> Is there no interest in the suggestion made below?
>
>
>
>
> Drawbacks:
> This doesn't allow for a task's action to add prerequisites to sibling
>
>
>
>
> tasks during the invocation chain (unless an API is provided to allow
> changing the invocation list during invocation)
>
>
> For me at least, this is a *huge* drawback.  I add new tasks and modify
> existing tasks during task execution all the time.
> Having the execution order determined all at once up-front would be a
> big problem.
>
>
> The flow is like this:
> * you build the task dependency tree as today
> * rake starts to invoke the top tasks:
>   * instead of letting each task invoke its prerequisites, rake asks it to
> return its prerequisites
>      * so here you can override the 'prerequisites' method and add and
> modify tasks
>   * now rake orders the prerequisites according to their dependencies and
> executes them

One benefit of Rake is that it's very dynamic.  Invoking one task can
configure the prerequisite for the following task, you can enhance
tasks at any point in time.  In addition, prerequisites can be
calculated based on the existence of files, which require a previous
task to execute and create them.

I don't know how many people take advantage of that, but anyone who
does would have to rewrite their Rakefiles to support this change.

Assaf


>
> This is just making the flow iterative instead of recursive: explicitly
> maintaining the stack of tasks instead of relying on ruby's call stack. I
> don't think much will change. But, by avoiding recursion, there's no risk of
> exhausting the call stack and there's a much better way of parallelizing the
> build
>
> Ittay
>
> Patrick Bennett
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>
>
> --
> --
> Ittay Dror <ittay.dror at gmail.com>
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From jim.weirich at gmail.com  Wed Aug 13 14:38:26 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 13 Aug 2008 14:38:26 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
Message-ID: <BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>


On Aug 13, 2008, at 11:27 AM, Bennett, Patrick wrote:

> For me at least, this is a *huge* drawback.  I add new tasks and  
> modify
> existing tasks during task execution all the time.
> Having the execution order determined all at once up-front would be a
> big problem.

Seems to me it would be possible to switch to an explicitly managed  
task stack without losing the dynamic nature of the task dependencies.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From Patrick.Bennett at inin.com  Wed Aug 13 15:36:46 2008
From: Patrick.Bennett at inin.com (Bennett, Patrick)
Date: Wed, 13 Aug 2008 15:36:46 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
References: <489FE6E1.1070102@gmail.com>
	<48A27638.3020104@gmail.com><260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
Message-ID: <260A0A30F9017945932CC4F7B911B339067AB14D@i3mail1.i3domain.inin.com>

> Seems to me it would be possible to switch to an explicitly managed  
> task stack without losing the dynamic nature of the task dependencies.

Perhaps, but even the slightest change in architecture of rake could
have a huge ripple effect for anyone relying on how and when it decides
to invoke and iterate tasks.  I've got a lot of code that dynamically
creates tasks and adds prerequisites on the fly.  Changes like those
discussed make me nervous.  :) 

Patrick 



From assaf at labnotes.org  Wed Aug 13 16:07:30 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Wed, 13 Aug 2008 13:07:30 -0700
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
Message-ID: <5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>

On Wed, Aug 13, 2008 at 11:38 AM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 13, 2008, at 11:27 AM, Bennett, Patrick wrote:
>
>> For me at least, this is a *huge* drawback.  I add new tasks and modify
>> existing tasks during task execution all the time.
>> Having the execution order determined all at once up-front would be a
>> big problem.
>
> Seems to me it would be possible to switch to an explicitly managed task
> stack without losing the dynamic nature of the task dependencies.

If it's just an issue of Ruby recursion eating up the stack, why not
change the algorithm so it's iterative using a proper stack to
push/pop prerequisites?

Creating a tree of prerequisites before invoking a single task would
change the way you use Rake, I'm one of the people who's code would
get affected.

Assaf


>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From jim.weirich at gmail.com  Wed Aug 13 16:18:28 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 13 Aug 2008 16:18:28 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
Message-ID: <51C99D0D-EF2D-40E4-861A-F985152EE64F@gmail.com>


On Aug 13, 2008, at 4:07 PM, Assaf Arkin wrote:

> If it's just an issue of Ruby recursion eating up the stack, why not
> change the algorithm so it's iterative using a proper stack to
> push/pop prerequisites?

exactly.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From ittay.dror at gmail.com  Wed Aug 13 16:20:34 2008
From: ittay.dror at gmail.com (Ittay Dror (Freiman))
Date: Wed, 13 Aug 2008 23:20:34 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
Message-ID: <667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>

On Wed, Aug 13, 2008 at 11:07 PM, Assaf Arkin <assaf at labnotes.org> wrote:
>
> If it's just an issue of Ruby recursion eating up the stack, why not
> change the algorithm so it's iterative using a proper stack to
> push/pop prerequisites?

right, and do it without recursion (i.e., don't start from the top
task, asking it to push its prerequisites and then ask them to push
their prerequisites).

>
> Creating a tree of prerequisites before invoking a single task would
> change the way you use Rake, I'm one of the people who's code would
> get affected.

the only thing that will be affected is if you have a task that
overrides the 'invoke_prerequisites' so that it takes into account the
results of 'execute' of those prerequisites (someone mentioned in this
thread a task that he wants to get executed if one of its
prerequisites succeeded). note there's a distinction between 'invoke'
and 'execute'.

other than such scenario, i don't think any code will be affected. all
tasks will be 'invoked'. their invocation will be to return their
prerequisites which can be very dynamic, overriden by tasks etc. then,
the resulting list will be iterated and executed. any dynamic
prerequisites code, other than one that examines the execution result,
will work as before

and as i mentioned there are other benefits besides avoiding stack
overflow, mainly, the ability to utilize several cores/cpus without
thrashing the machine and being able to stop the whole execution on
errors.

ittay

>
> Assaf
>
>
>>
>> --
>> -- Jim Weirich
>> -- jim.weirich at gmail.com
>>
>> _______________________________________________
>> Rake-devel mailing list
>> Rake-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rake-devel
>>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From jim.weirich at gmail.com  Wed Aug 13 16:26:42 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 13 Aug 2008 16:26:42 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <260A0A30F9017945932CC4F7B911B339067AB14D@i3mail1.i3domain.inin.com>
References: <489FE6E1.1070102@gmail.com>
	<48A27638.3020104@gmail.com><260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB14D@i3mail1.i3domain.inin.com>
Message-ID: <5F065B9F-CCAF-465D-A7D1-92C864E72CA3@gmail.com>


On Aug 13, 2008, at 3:36 PM, Bennett, Patrick wrote:

> Perhaps, but even the slightest change in architecture of rake could
> have a huge ripple effect for anyone relying on how and when it  
> decides
> to invoke and iterate tasks.  I've got a lot of code that dynamically
> creates tasks and adds prerequisites on the fly.  Changes like those
> discussed make me nervous.  :)


Hmmm.  I will confess that depending on a particular execution order  
of tasks makes me a bit nervous.  (Mainly because I might accidently  
break them on a version change).

This makes me think that I should clearly document exactly what  
ordering rake will guarantee and when dependencies can be added or  
not.   Conversations this weekend at the hoedown reminded me that  
documenting Rakes application API would be a good idea as well.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From jim.weirich at gmail.com  Wed Aug 13 16:28:37 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 13 Aug 2008 16:28:37 -0400
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
	<667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
Message-ID: <EBA4D3E9-4D07-4AE6-BC83-90E7B77C946F@gmail.com>


On Aug 13, 2008, at 4:20 PM, Ittay Dror (Freiman) wrote:

> and as i mentioned there are other benefits besides avoiding stack
> overflow, mainly, the ability to utilize several cores/cpus without
> thrashing the machine and being able to stop the whole execution on
> errors.


Using multiple cores/cpus is not possible with MRI, regardless of what  
rake does. (Or are you using 1.9 or JRuby?)

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From assaf at labnotes.org  Wed Aug 13 16:29:58 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Wed, 13 Aug 2008 13:29:58 -0700
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
	<667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
Message-ID: <5037b6e40808131329q4beeb7cfj77b9e9b2a97dbc86@mail.gmail.com>

On Wed, Aug 13, 2008 at 1:20 PM, Ittay Dror (Freiman)
<ittay.dror at gmail.com> wrote:
> On Wed, Aug 13, 2008 at 11:07 PM, Assaf Arkin <assaf at labnotes.org> wrote:
>>
>> If it's just an issue of Ruby recursion eating up the stack, why not
>> change the algorithm so it's iterative using a proper stack to
>> push/pop prerequisites?
>
> right, and do it without recursion (i.e., don't start from the top
> task, asking it to push its prerequisites and then ask them to push
> their prerequisites).
>
>>
>> Creating a tree of prerequisites before invoking a single task would
>> change the way you use Rake, I'm one of the people who's code would
>> get affected.
>
> the only thing that will be affected is if you have a task that
> overrides the 'invoke_prerequisites' so that it takes into account the
> results of 'execute' of those prerequisites (someone mentioned in this
> thread a task that he wants to get executed if one of its
> prerequisites succeeded). note there's a distinction between 'invoke'
> and 'execute'.

task 'a'=>['b', 'c']

task 'b' do
  task('a').enhance ['d']
end

Assaf

> other than such scenario, i don't think any code will be affected. all
> tasks will be 'invoked'. their invocation will be to return their
> prerequisites which can be very dynamic, overriden by tasks etc. then,
> the resulting list will be iterated and executed. any dynamic
> prerequisites code, other than one that examines the execution result,
> will work as before
>
> and as i mentioned there are other benefits besides avoiding stack
> overflow, mainly, the ability to utilize several cores/cpus without
> thrashing the machine and being able to stop the whole execution on
> errors.
>
> ittay
>
>>
>> Assaf
>>
>>
>>>
>>> --
>>> -- Jim Weirich
>>> -- jim.weirich at gmail.com
>>>
>>> _______________________________________________
>>> Rake-devel mailing list
>>> Rake-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rake-devel
>>>
>> _______________________________________________
>> Rake-devel mailing list
>> Rake-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rake-devel
>>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From assaf at labnotes.org  Wed Aug 13 16:36:30 2008
From: assaf at labnotes.org (Assaf Arkin)
Date: Wed, 13 Aug 2008 13:36:30 -0700
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <EBA4D3E9-4D07-4AE6-BC83-90E7B77C946F@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>
	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>
	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>
	<667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
	<EBA4D3E9-4D07-4AE6-BC83-90E7B77C946F@gmail.com>
Message-ID: <5037b6e40808131336x1d0d8d7fv6e4d93e3a90222b8@mail.gmail.com>

On Wed, Aug 13, 2008 at 1:28 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 13, 2008, at 4:20 PM, Ittay Dror (Freiman) wrote:
>
>> and as i mentioned there are other benefits besides avoiding stack
>> overflow, mainly, the ability to utilize several cores/cpus without
>> thrashing the machine and being able to stop the whole execution on
>> errors.
>
>
> Using multiple cores/cpus is not possible with MRI, regardless of what rake
> does. (Or are you using 1.9 or JRuby?)

You can squeeze more performance if you're spawning processes or doing
I/O, but you might want to consider asynchronous tasks instead: invoke
and separately block waiting for the results.

Assaf

>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From ittay.dror at gmail.com  Thu Aug 14 00:36:04 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Thu, 14 Aug 2008 07:36:04 +0300
Subject: [Rake-devel] wish: better support for multi-threaded builds
Message-ID: <48A3B634.9060502@gmail.com>

Hi,

There are several issues with using MultiTask to parallelize the build:
1. If some top level tasks run in parallel, and each of them recursively 
runs other tasks, and one of the bottom tasks fail, it is impossible to 
stop the other tasks, short of a very ugly abort of all threads.
2. Tasks that run in parallel can't tell when another task's execution 
has failed. They may read a wrong timestamp from the failed task.
3. Threads are created per prerequisite task, rather than a fixed number 
(based initially on the number of cores/cpus), which causes thrashing
4. Even if a thread pool will be utilized, dependency information is 
still hard to take into account. Imagine a task has 2 prerequisites, 
where one depends on the other. Adding the tasks into a thread pool, 
they may be invoked in two different threads, but one waits on the other 
so the thread is not utilized. Maybe add a  "distance" method which 
calculates how far one task if from the other in dependency (adding nil 
if not dependent), so when adding tasks to a queue, they are added to 
the queue where the current tasks have the minimal distance (nil being 
infinite).

Ittay

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From watsonmw at gmail.com  Thu Aug 14 15:14:39 2008
From: watsonmw at gmail.com (Mark Watson)
Date: Thu, 14 Aug 2008 12:14:39 -0700
Subject: [Rake-devel] wish: better support for multi-threaded builds
In-Reply-To: <48A3B634.9060502@gmail.com>
References: <48A3B634.9060502@gmail.com>
Message-ID: <2576e5830808141214i28cc7daqd2214317b7a35b8c@mail.gmail.com>

We use a thread pool version of the multitask for building some c/cpp
libraries.  Works fairly well for this simple case, but does loose
some cycles when one of threads blocks waiting on another thread to
finish.

I would still like to see a 'make -j{num_threads}' like functionality
though.  Sure it would require more care in writing the rakefile to
insure that all the dependencies are setup correctly.  But by default
rake could use the existing task invoke, and only when the minus j
option is specified would a task queue be used to execute the tasks in
parellel.  This would insure that existing rakefiles worked so long as
they weren't executed with rake -j.

Mark

2008/8/13 Ittay Dror <ittay.dror at gmail.com>:
> Hi,
>
> There are several issues with using MultiTask to parallelize the build:
> 1. If some top level tasks run in parallel, and each of them recursively
> runs other tasks, and one of the bottom tasks fail, it is impossible to stop
> the other tasks, short of a very ugly abort of all threads.
> 2. Tasks that run in parallel can't tell when another task's execution has
> failed. They may read a wrong timestamp from the failed task.
> 3. Threads are created per prerequisite task, rather than a fixed number
> (based initially on the number of cores/cpus), which causes thrashing
> 4. Even if a thread pool will be utilized, dependency information is still
> hard to take into account. Imagine a task has 2 prerequisites, where one
> depends on the other. Adding the tasks into a thread pool, they may be
> invoked in two different threads, but one waits on the other so the thread
> is not utilized. Maybe add a  "distance" method which calculates how far one
> task if from the other in dependency (adding nil if not dependent), so when
> adding tasks to a queue, they are added to the queue where the current tasks
> have the minimal distance (nil being infinite).
>
> Ittay
>
> --
> --
> Ittay Dror <ittay.dror at gmail.com>
>
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From adam.q.salter at gmail.com  Fri Aug 15 02:39:18 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Fri, 15 Aug 2008 16:39:18 +1000
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
Message-ID: <D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>

Dear all,
I have created a issue for this, with associated comments and patch:
http://onestepback.org/redmine/issues/show/13

It basically just needs:
a) Windows testing.
b) 1 test is currently failing and it's due to the fact that I  
couldn't work out how to properly mock the test... I'd really  
appreciate any help in this matter, and would be very happy to learn.  
The test is called 'test_load_from_system_rakefile' and it's in the  
patch. You can see what functionality it should have from the test,  
but as stated it doesn't work.

Best,
-Adam

On 28/07/2008, at 12:23 AM, Adam Salter wrote:

> Dear all,
> Here's my attempt at this... I'm working on several other  
> modifications, but wanted to send this through and see it running  
> first. The attached patch works exactly as Jim has requested.
>
> I'm sorry, but I had a little trouble with writing the test mocking  
> for a file in the home directory (if you run the tests you'll see  
> what I mean)... I've updated all other tests to run as expected.
> I'm going out for a couple of days, but will check emails when i get  
> back.
>
> Also not tested on Windows (although I see no reason why it  
> shouldn't work)
>
> <0001-added-system-wide-.rake-functionality.patch>
>
>
> Best,
> -Adam
>
> On 30/06/2008, at 11:53 PM, Luis Lavena wrote:
>
>> Sorry I came late to this topic...
>>
>> On Mon, Jun 30, 2008 at 3:33 PM, Jim Weirich  
>> <jim.weirich at gmail.com> wrote:
>>>
>>> On Jun 30, 2008, at 12:41 AM, Adam Salter wrote:
>>>
>>>> chroot is not really the same thing... ie it's not really a  
>>>> standard or
>>>> normal way of having Rake tasks globally available... ie I can't  
>>>> use it that
>>>> way regularly.
>>>> Rakefile in / does work i guess, but makes me think when i said  
>>>> 'globally
>>>> available' i really meant 'per-user'.
>>>>
>>>> Still no comment from the great and benevolent leader Jim... ;)
>>>
>>> You forgot the easily distractible :)
>>>
>>> I have no strong objection to this change.  Several points:
>>>
>>> (1) Only reads .rake if if finds no other Rakefile.  This is  
>>> important
>>> because you don't want to accidently put important build  
>>> functionality
>>> outside of your project directory.
>>>
>>
>> Good, something like Sake does, you put generic tasks that you usualy
>> run for most of your projects (like log:clear) :-)
>>
>>> (2) If the command line option is given, then the local Rakefile  
>>> should be
>>> ignored.
>>>
>>> (3) Where are you going to put the .rake file on a windows machine?
>>>
>>
>> If home is not defined, then should be HOMEDRIVE + HOMEPATH :-)
>> If there is not HOMEDRIVE+HOMEPATH, that mean is not a user, but a
>> service, then it should look for APPDATA.
>>
>> If no APPDATA there, it should look for ALLUSERSPROFILE
>>
>>> (4) Include tests for all changes.  I am much more likely to  
>>> accept patches
>>> with tests than otherwise.
>>>
>>> Also, I'm planning on putting a git repository of rake on github  
>>> in the very
>>> near future (meant to do it this weekend but ran out of time).   
>>> That should
>>> make it easier for alternate versions.  I'll put an announcement  
>>> here when I
>>> do.
>>>
>>
>> Great news!
>>
>> I'll be able to fork and make all the tests for rake actual pass on
>> Windows and see what other cross-platform bug we found in ruby itself
>> to catch! :-)
>>
>> Thank you Jim for your hard work :-)
>>
>> Regards,
>> -- 
>> Luis Lavena
>> AREA 17
>> -
>> Human beings, who are almost unique in having the ability to learn  
>> from
>> the experience of others, are also remarkable for their apparent
>> disinclination to do so.
>> Douglas Adams
>> _______________________________________________
>> Rake-devel mailing list
>> Rake-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rake-devel
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel

From Daniel.Berger at qwest.com  Fri Aug 15 11:54:46 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Fri, 15 Aug 2008 10:54:46 -0500
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com><CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com><C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com><DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com><71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com><FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>

 > -----Original Message-----
> From: rake-devel-bounces at rubyforge.org 
> [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Adam Salter
> Sent: Friday, August 15, 2008 12:39 AM
> To: Rake Development and Discussion
> Subject: Re: [Rake-devel] ~/.rake file?
> 
> Dear all,
> I have created a issue for this, with associated comments and patch:
> http://onestepback.org/redmine/issues/show/13
> 
> It basically just needs:
> a) Windows testing.

<snip>

> >> If home is not defined, then should be HOMEDRIVE + HOMEPATH :-) If 
> >> there is not HOMEDRIVE+HOMEPATH, that mean is not a user, but a 
> >> service, then it should look for APPDATA.

Actually ENV['APPDATA'] will return the value of whatever user the
service is setup to run as. It just so happens for the LocalSystem
account, it's nil. (I'm not sure what environment variables are set for
the LocalSystem account off the top of my head).

> >> If no APPDATA there, it should look for ALLUSERSPROFILE

I prefer File.join(ENV['APPDATA'], 'Rake'), but it's up to you. This is
how and where software like Adobe, Subversion, and Firefox put
application specific data.

Here's a way to get the app data directory programmatically if you ever
need it:

require 'Win32API'

CSIDL_APPDATA = 0x001A

SHGetFolderPath = Win32API.new('shell32', 'SHGetFolderPath', 'LLLLP',
'L')

buf = 0.chr * 260

if SHGetFolderPath.call(0, CSIDL_APPDATA, 0, 1, buf) == 0
   puts "The app data directory is: " + buf.strip
else
   puts "Unable to find value"
End

This approach reads from the registry instead of using environment data.
Note that when run from a service, it returns
C:\WINNT\system32\config\systemprofile\Application Data, which I guess
is the appdata directory for the LocalSystem account - the default
account for Windows services. Note that you can run a service under a
different account, in which case you'll get the appdata directory for
that account instead.

> >>
> >>> (4) Include tests for all changes.  I am much more likely 
> to accept 
> >>> patches with tests than otherwise.
> >>>
> >>> Also, I'm planning on putting a git repository of rake on 
> github in 
> >>> the very
> >>> near future (meant to do it this weekend but ran out of time).   
> >>> That should
> >>> make it easier for alternate versions.  I'll put an announcement 
> >>> here when I do.
> >>>
> >>
> >> Great news!
> >>
> >> I'll be able to fork and make all the tests for rake 
> actual pass on 
> >> Windows and see what other cross-platform bug we found in 
> ruby itself 
> >> to catch! :-)

Don't do this:

PLATFORM =~ /win32/

First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
advent of alternative implementations like Jruby and IronRuby,
RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
return 'java' for the RUBY_PLATFORM, even if you're on Windows.

Use rbconfig + host_os instead:

require 'rbconfig'

if Config::CONFIG['host_os'] =~ /mswin/I
...

Regards,

Dan

PS - I'll post this to the ticket once (if?) my Redmine account has been
approved there.


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From luislavena at gmail.com  Fri Aug 15 12:19:59 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 15 Aug 2008 18:19:59 +0200
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0808150919n51bb91ebxe4ddd44df4befba5@mail.gmail.com>

On Fri, Aug 15, 2008 at 5:54 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
>  > -----Original Message-----
>> From: rake-devel-bounces at rubyforge.org
>> [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Adam Salter
>> Sent: Friday, August 15, 2008 12:39 AM
>> To: Rake Development and Discussion
>> Subject: Re: [Rake-devel] ~/.rake file?
>>
>> Dear all,
>> I have created a issue for this, with associated comments and patch:
>> http://onestepback.org/redmine/issues/show/13
>>
>> It basically just needs:
>> a) Windows testing.
>
> <snip>
>

<further snip>
>
> Don't do this:
>
> PLATFORM =~ /win32/
>
> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
> advent of alternative implementations like Jruby and IronRuby,
> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>
> Use rbconfig + host_os instead:
>
> require 'rbconfig'
>
> if Config::CONFIG['host_os'] =~ /mswin/I
> ...
>

Don't compare just to mswin either.

That bangs out not only MinGW (mingw) but also bccwin, which even has
no release in long time, there are some users interested in keeping it
running.

So basically, /mswin|mingw/ for your RUBY_PLATFORM needs will work
most of the time.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From dave at pragprog.com  Mon Aug 18 19:13:33 2008
From: dave at pragprog.com (Dave Thomas)
Date: Mon, 18 Aug 2008 18:13:33 -0500
Subject: [Rake-devel] Are rules supposed to honor timestamps?
Message-ID: <54FB96D9-51C4-4431-B6F7-FAC2D1EEDC92@pragprog.com>

Given a rule

    rule '.2' => '.1' do ...

If a.2 doesn't exist and a.1 does exist, then the rule triggers. I'd  
expect this.

If a.2 exists and has a timestamp later than a.1, the rule does not  
fire. I'd expect this.

If a.2 exists but the timestamp is earlier than a.1, the rule does not  
fire. I don't expect this--the target is out of date wrt the source,  
and needs rebuilding.

Also, if the dependencies of a rule is an array, then the entries  
after the first one seem to be ignored.

I've appended a simple Rakefile that demonstrates this.

So, my question: am I misunderstanding how rules are supposed to work?


Dave



- - - Rakefile - - -
def tidy
   rm_rf "rake_test*"
   sh "echo >rake_test.1"
   sh "echo >rake_test_other"
end

def line
   puts "\n\n------------------------------\n\n"
end

task :test do
   tidy

   # Regular build when target doesn't exist
   puts "Should output (In ..)/cat rake_test.1 >rake_test.2"
   sh "rake rake_test.2"

   line

   # Should not rebuild
   puts "Should just output (In ...)"
   sh "rake rake_test.2"

   line

   # Touch the source forces rebuild
   sh "touch rake_test.1"
   puts "Should output (In ..)/cat rake_test.1 >rake_test.2"
   sh "rake rake_test.2"

   line

   # Now touch the second dependency
   sh "touch rake_test_other"
   puts "Should output (In ..)/cat rake_test.1 >rake_test.2"
   sh "rake rake_test.2"
end

rule '.2' => ['.1', 'rake_test_other'] do |t|
   "creating #{t.name} from #{t.source}"
   sh "cat #{t.source} >#{t.name}"
end


From jim.weirich at gmail.com  Mon Aug 18 19:43:56 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 18 Aug 2008 19:43:56 -0400
Subject: [Rake-devel] Are rules supposed to honor timestamps?
In-Reply-To: <54FB96D9-51C4-4431-B6F7-FAC2D1EEDC92@pragprog.com>
References: <54FB96D9-51C4-4431-B6F7-FAC2D1EEDC92@pragprog.com>
Message-ID: <9524BE14-3124-4C42-9135-4E47A7E92638@gmail.com>


On Aug 18, 2008, at 7:13 PM, Dave Thomas wrote:

> So, my question: am I misunderstanding how rules are supposed to work?

Your understanding is correct ... however I believe the time stamp  
resolution on the file system is 1 second (2 seconds on DOS FAT  
files).  In other words, Rake cannot tell that a file is "out of date"  
if they are created in the same second.

Put a "sleep 2" in your Rakefile between each test and you should see  
the proper output.

> Also, if the dependencies of a rule is an array, then the entries  
> after the first one seem to be ignored.

This is a bug in the 0.8.1 release of rake.  If you load the gem from  
the latest build on github, this should be corrected.  I will probably  
release 0.8.2 very soon.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From adam.q.salter at gmail.com  Tue Aug 19 02:59:34 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Tue, 19 Aug 2008 16:59:34 +1000
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <71166b3b0808150919n51bb91ebxe4ddd44df4befba5@mail.gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
	<71166b3b0808150919n51bb91ebxe4ddd44df4befba5@mail.gmail.com>
Message-ID: <61A9AD4C-76B9-44E5-A797-20CE488B2531@gmail.com>

On 16/08/2008, at 2:19 AM, Luis Lavena wrote:

> On Fri, Aug 15, 2008 at 5:54 PM, Berger, Daniel <Daniel.Berger at qwest.com 
> > wrote:
>>> -----Original Message-----
>>> From: rake-devel-bounces at rubyforge.org
>>> [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Adam Salter
>>> Sent: Friday, August 15, 2008 12:39 AM
>>> To: Rake Development and Discussion
>>> Subject: Re: [Rake-devel] ~/.rake file?
>>>
>>> Dear all,
>>> I have created a issue for this, with associated comments and patch:
>>> http://onestepback.org/redmine/issues/show/13
>>>
>>> It basically just needs:
>>> a) Windows testing.
>>
>> <snip>
>>
>
> <further snip>
>>
>> Don't do this:
>>
>> PLATFORM =~ /win32/
>>
>> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
>> advent of alternative implementations like Jruby and IronRuby,
>> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
>> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>>
>> Use rbconfig + host_os instead:
>>
>> require 'rbconfig'
>>
>> if Config::CONFIG['host_os'] =~ /mswin/I
>> ...
>>
>
> Don't compare just to mswin either.
>
> That bangs out not only MinGW (mingw) but also bccwin, which even has
> no release in long time, there are some users interested in keeping it
> running.
>

Why should I care about MinGW? Aren't we just trying to get Windows  
(ie non-Unix)?

-Adam

From luislavena at gmail.com  Tue Aug 19 03:41:54 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 19 Aug 2008 09:41:54 +0200
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <61A9AD4C-76B9-44E5-A797-20CE488B2531@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
	<71166b3b0808150919n51bb91ebxe4ddd44df4befba5@mail.gmail.com>
	<61A9AD4C-76B9-44E5-A797-20CE488B2531@gmail.com>
Message-ID: <71166b3b0808190041s5196014by15089e7f9859bd16@mail.gmail.com>

On Tue, Aug 19, 2008 at 8:59 AM, Adam Salter <adam.q.salter at gmail.com> wrote:
> On 16/08/2008, at 2:19 AM, Luis Lavena wrote:
>
>> On Fri, Aug 15, 2008 at 5:54 PM, Berger, Daniel <Daniel.Berger at qwest.com>
>> wrote:
>>>>
>>>> -----Original Message-----
>>>> From: rake-devel-bounces at rubyforge.org
>>>> [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Adam Salter
>>>> Sent: Friday, August 15, 2008 12:39 AM
>>>> To: Rake Development and Discussion
>>>> Subject: Re: [Rake-devel] ~/.rake file?
>>>>
>>>> Dear all,
>>>> I have created a issue for this, with associated comments and patch:
>>>> http://onestepback.org/redmine/issues/show/13
>>>>
>>>> It basically just needs:
>>>> a) Windows testing.
>>>
>>> <snip>
>>>
>>
>> <further snip>
>>>
>>> Don't do this:
>>>
>>> PLATFORM =~ /win32/
>>>
>>> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
>>> advent of alternative implementations like Jruby and IronRuby,
>>> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
>>> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>>>
>>> Use rbconfig + host_os instead:
>>>
>>> require 'rbconfig'
>>>
>>> if Config::CONFIG['host_os'] =~ /mswin/I
>>> ...
>>>
>>
>> Don't compare just to mswin either.
>>
>> That bangs out not only MinGW (mingw) but also bccwin, which even has
>> no release in long time, there are some users interested in keeping it
>> running.
>>
>
> Why should I care about MinGW? Aren't we just trying to get Windows (ie
> non-Unix)?
>

MinGW:

Minimalist GNU for Windows:

GNU toolchain (GCC, make, binutils) that generate native binaries that
works on Windows. This suite is runtime compatible with Visual C tools
that link to MSVCRT.

So: you should care about it:

http://blog.mmediasys.com/2008/03/29/progress-of-one-click-installer-rubyinstaller/
http://www.akitaonrails.com/2008/7/21/testing-the-new-one-click-ruby-installer-for-windows
http://www.akitaonrails.com/2008/7/26/still-playing-with-ruby-on-windows

Both mswin and mingw runs on Windows:
(ruby -v)

ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]
ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]

Both are the same from the binary perspective, but for Ruby, they are
not (make instead of nmake, gcc.exe instead of cl.exe, etc.)

So that's why RUBY_PLATFORM have different "signature" across them.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From david at vizion2000.net  Tue Aug 19 13:53:40 2008
From: david at vizion2000.net (David Southwell)
Date: Tue, 19 Aug 2008 10:53:40 -0700
Subject: [Rake-devel] Rake bug _ win 64
Message-ID: <200808191053.40569.david@vizion2000.net>

Nobuyoshi Nakada suggests the following problem is due to a rake bug. 
Currently I am unable to install hpricot on a win 64 system. See following 
bug report with response from Nobuyoshi Nakada


Original Bug Report:

Looks like latest version of hpricot is not pathing correctly for installation 
on win 64 systems which have both a C:\Program
Files and C:Program Files (86) directory. On the other hand correct path seems 
to be followed to write the
gem_make.out file.

> gem install hpricot
Building native extensions. This could take a while
ERROR: Error installing hpricot
       ERROR: Failed to build gem native extension.

C:/Program Files (x86)/ruby/bin/ruby.exe extconf.rb install hpricot
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

Gen files will remain installed in C:/Program Files (x86)/ruby/lib/ruby/gems/
1.8/gems/hpricot-0.6.161 for inspection.
Results logged to C:/Program Files (x86)/ruby/lib/ruby/gems/1.8/gems/hpricot-
0.6.161/ext/fast_xs/gem_make.out

gem_make.out:
C:/Program Files (x86)/ruby/bin/ruby.exe extconf.rb install hpricot
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

extconf.rb in same directory:
require 'mkmf'
have_header('stdio.h') or exit
dir_config('fast_xs')
create_makefile('fast_xs')
postaddcomment21591  Add A Comment: Notepad
  
   Please  login 

 
Submit  
  Followup
Message
  Date: 2008-08-19 07:02
Sender: Nobuyoshi Nakada 

I wrote "for *1.9*".
Rake isn't bundled with 1.8 and the gem is not my responsibiilty,
so you have to report the issue to the Rake project.
  Date: 2008-08-19 04:49
Sender: vizion communications

I am still getting same error. Have tried gem update rake. 
This is not fixed for me - I am currently without hpricot. 
Maybe I have missed something??

  Date: 2008-08-18 16:29
Sender: Nobuyoshi Nakada 

Seems like an issue of rake.
Fixed in the repository for 1.9.

From luislavena at gmail.com  Tue Aug 19 14:27:38 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 19 Aug 2008 20:27:38 +0200
Subject: [Rake-devel] Rake bug _ win 64
In-Reply-To: <200808191053.40569.david@vizion2000.net>
References: <200808191053.40569.david@vizion2000.net>
Message-ID: <71166b3b0808191127m1817e5b1vdef919a85a7f234a@mail.gmail.com>

On Tue, Aug 19, 2008 at 7:53 PM, David Southwell <david at vizion2000.net> wrote:
> Nobuyoshi Nakada suggests the following problem is due to a rake bug.
> Currently I am unable to install hpricot on a win 64 system. See following
> bug report with response from Nobuyoshi Nakada
>
>
> Original Bug Report:
>
> Looks like latest version of hpricot is not pathing correctly for installation
> on win 64 systems which have both a C:\Program
> Files and C:Program Files (86) directory. On the other hand correct path seems
> to be followed to write the
> gem_make.out file.
>
>> gem install hpricot
> Building native extensions. This could take a while
> ERROR: Error installing hpricot
>       ERROR: Failed to build gem native extension.
>
> C:/Program Files (x86)/ruby/bin/ruby.exe extconf.rb install hpricot
> 'C:/Program' is not recognized as an internal or external command,
> operable program or batch file.
>
> Gen files will remain installed in C:/Program Files (x86)/ruby/lib/ruby/gems/
> 1.8/gems/hpricot-0.6.161 for inspection.
> Results logged to C:/Program Files (x86)/ruby/lib/ruby/gems/1.8/gems/hpricot-
> 0.6.161/ext/fast_xs/gem_make.out
>

I still don't see how to Rake is blame by Hpricot building?

http://code.whytheluckystiff.net/hpricot/browser/trunk/ext/fast_xs/extconf.rb

> gem_make.out:
> C:/Program Files (x86)/ruby/bin/ruby.exe extconf.rb install hpricot
> 'C:/Program' is not recognized as an internal or external command,
> operable program or batch file.
>
> extconf.rb in same directory:
> require 'mkmf'
> have_header('stdio.h') or exit
> dir_config('fast_xs')
> create_makefile('fast_xs')

It's basically building a plain makefile with mkmf, so the problem is
path quoting/escaping in RubyGems.


Will better if you bring this to rubygems-devel mailing list and I'll
pin it to my inbox along with RubyGems 1.3.0 details for Windows.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From jim.weirich at gmail.com  Tue Aug 19 19:18:39 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Tue, 19 Aug 2008 19:18:39 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
Message-ID: <756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>


On Aug 15, 2008, at 2:39 AM, Adam Salter wrote:

> Dear all,
> I have created a issue for this, with associated comments and patch:
> http://onestepback.org/redmine/issues/show/13
>
> It basically just needs:
> a) Windows testing.
> b) 1 test is currently failing and it's due to the fact that I  
> couldn't work out how to properly mock the test... I'd really  
> appreciate any help in this matter, and would be very happy to  
> learn. The test is called 'test_load_from_system_rakefile' and it's  
> in the patch. You can see what functionality it should have from the  
> test, but as stated it doesn't work.


I'm in the midst of looking over this patch.  The thought occurs to me  
that perhaps ~/.rake shouldn't be a file, but a directory where you  
can drop xxx.rake files into.  This allows stuff from separate sources  
to be integrated without hassle.

Thoughts?

Also, I see you added '.rake' to the list of rakefile names.  I'm not  
sure that is necessary, since we never find ~/.rake when searching for  
rakefiles.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From dsisnero at gmail.com  Tue Aug 19 19:39:05 2008
From: dsisnero at gmail.com (Dominic Sisneros)
Date: Tue, 19 Aug 2008 17:39:05 -0600
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
Message-ID: <c429d15e0808191639w31bcee67lc25957bb2eb971f5@mail.gmail.com>

+1 for directory

On Tue, Aug 19, 2008 at 5:18 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 15, 2008, at 2:39 AM, Adam Salter wrote:
>
>> Dear all,
>> I have created a issue for this, with associated comments and patch:
>> http://onestepback.org/redmine/issues/show/13
>>
>> It basically just needs:
>> a) Windows testing.
>> b) 1 test is currently failing and it's due to the fact that I couldn't
>> work out how to properly mock the test... I'd really appreciate any help in
>> this matter, and would be very happy to learn. The test is called
>> 'test_load_from_system_rakefile' and it's in the patch. You can see what
>> functionality it should have from the test, but as stated it doesn't work.
>
>
> I'm in the midst of looking over this patch.  The thought occurs to me that
> perhaps ~/.rake shouldn't be a file, but a directory where you can drop
> xxx.rake files into.  This allows stuff from separate sources to be
> integrated without hassle.
>
> Thoughts?
>
> Also, I see you added '.rake' to the list of rakefile names.  I'm not sure
> that is necessary, since we never find ~/.rake when searching for rakefiles.
>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel
>

From adam.q.salter at gmail.com  Tue Aug 19 23:45:58 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Wed, 20 Aug 2008 13:45:58 +1000
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
Message-ID: <C9A8846C-40B7-44F5-9B6B-B9E755CCF4BC@gmail.com>


On 20/08/2008, at 9:18 AM, Jim Weirich wrote:

>
> On Aug 15, 2008, at 2:39 AM, Adam Salter wrote:
>
>> Dear all,
>> I have created a issue for this, with associated comments and patch:
>> http://onestepback.org/redmine/issues/show/13
>>
>> It basically just needs:
>> a) Windows testing.
>> b) 1 test is currently failing and it's due to the fact that I  
>> couldn't work out how to properly mock the test... I'd really  
>> appreciate any help in this matter, and would be very happy to  
>> learn. The test is called 'test_load_from_system_rakefile' and it's  
>> in the patch. You can see what functionality it should have from  
>> the test, but as stated it doesn't work.
>
>
> I'm in the midst of looking over this patch.  The thought occurs to  
> me that perhaps ~/.rake shouldn't be a file, but a directory where  
> you can drop xxx.rake files into.  This allows stuff from separate  
> sources to be integrated without hassle.
>
> Thoughts?

also +1 for rake file directory... Only thought is that it will  
probably have to be called something different on Windows.
'.rake' doesn't look so good on Windows...
I think the suggestions was to put it in 'Application Data/Rake'.

> Also, I see you added '.rake' to the list of rakefile names.  I'm  
> not sure that is necessary, since we never find ~/.rake when  
> searching for rakefiles.

I did, it worked as my solution, but i can modify patch to reflect the  
directory and remove this.

I also have to modify the patch for the Windows suggestions re:Windows  
detection, so I'll do them both.

Thanks,
-Adam

From ittay.dror at gmail.com  Wed Aug 20 02:41:40 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Wed, 20 Aug 2008 09:41:40 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <EBA4D3E9-4D07-4AE6-BC83-90E7B77C946F@gmail.com>
References: <489FE6E1.1070102@gmail.com>
	<48A27638.3020104@gmail.com>	<260A0A30F9017945932CC4F7B911B339067AB139@i3mail1.i3domain.inin.com>	<BDA6A7BE-B895-448A-9CE7-F3211DA1CFC5@gmail.com>	<5037b6e40808131307m3a29854i8cbe581adc677e71@mail.gmail.com>	<667c668f0808131320k70c2533aqb204fa2302e5abcb@mail.gmail.com>
	<EBA4D3E9-4D07-4AE6-BC83-90E7B77C946F@gmail.com>
Message-ID: <48ABBCA4.7090809@gmail.com>

Sorry for the late response. Below



Jim Weirich wrote:
>
> On Aug 13, 2008, at 4:20 PM, Ittay Dror (Freiman) wrote:
>
>> and as i mentioned there are other benefits besides avoiding stack
>> overflow, mainly, the ability to utilize several cores/cpus without
>> thrashing the machine and being able to stop the whole execution on
>> errors.
>
>
> Using multiple cores/cpus is not possible with MRI, regardless of what 
> rake does. (Or are you using 1.9 or JRuby?)
Well, it does seem to work for me. I'm running several compilations in 
parallel. In any case, shouldn't Rake at least be ready in its 
architecture when multi-cpu/core support will be available?

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From ittay.dror at gmail.com  Wed Aug 20 02:44:21 2008
From: ittay.dror at gmail.com (Ittay Dror)
Date: Wed, 20 Aug 2008 09:44:21 +0300
Subject: [Rake-devel] recursive task invocation
In-Reply-To: <48A27638.3020104@gmail.com>
References: <489FE6E1.1070102@gmail.com> <48A27638.3020104@gmail.com>
Message-ID: <48ABBD45.1020305@gmail.com>

So the previous ping generated some feedback, but I'm still not sure if 
this is on the roadmap or not. Jim?

Ittay

Ittay Dror wrote:
> Is there no interest in the suggestion made below?
>
> Ittay Dror wrote:
>> Hi,
>>
>> I'm running a Buildr build and after 20 recursive prerequisites 
>> Ruby's call stack is exhausted and I get a segmentation fault. The 
>> number of modules and dependencies is large, so I can't decrease the 
>> prerequisites.
>>
>> How about doing an iterative DFS search on the prerequisites to order 
>> them and then invoke them according to order?
>>
>> There are  a few other benefits, besides not needing recursion:
>> 1. it allows to find circular dependencies before starting the 
>> invocation
>> 2. it allows for rake to utilize threads to invoke the list of tasks 
>> (assuming actions don't conflict)
>>
>> Note that currently tasks can "cheat" and add prerequisites lazily 
>> when invoked by overriding invoke_prerequisites. This can be achieved 
>> with the above suggestion by letting them override the prerequisites 
>> accessor.
>>
>> Drawbacks:
>> This doesn't allow for a task's action to add prerequisites to 
>> sibling tasks during the invocation chain (unless an API is provided 
>> to allow changing the invocation list during invocation)
>>
>> What do you think? I don't mind implementing this, but obviously it 
>> is a big change.
>> Ittay
>>
>

-- 
--
Ittay Dror <ittay.dror at gmail.com>



From jim.weirich at gmail.com  Wed Aug 20 08:54:10 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 20 Aug 2008 08:54:10 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <C9A8846C-40B7-44F5-9B6B-B9E755CCF4BC@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<C9A8846C-40B7-44F5-9B6B-B9E755CCF4BC@gmail.com>
Message-ID: <8851971C-E40B-47F9-AE3D-2C02C51B3890@gmail.com>


On Aug 19, 2008, at 11:45 PM, Adam Salter wrote:

> I also have to modify the patch for the Windows suggestions  
> re:Windows detection, so I'll do them both.

Great, I'll look forward to it.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From transfire at gmail.com  Wed Aug 20 14:51:21 2008
From: transfire at gmail.com (Trans)
Date: Wed, 20 Aug 2008 14:51:21 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
Message-ID: <4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>

On Tue, Aug 19, 2008 at 7:18 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 15, 2008, at 2:39 AM, Adam Salter wrote:
>
>> Dear all,
>> I have created a issue for this, with associated comments and patch:
>> http://onestepback.org/redmine/issues/show/13
>>
>> It basically just needs:
>> a) Windows testing.
>> b) 1 test is currently failing and it's due to the fact that I couldn't
>> work out how to properly mock the test... I'd really appreciate any help in
>> this matter, and would be very happy to learn. The test is called
>> 'test_load_from_system_rakefile' and it's in the patch. You can see what
>> functionality it should have from the test, but as stated it doesn't work.
>
>
> I'm in the midst of looking over this patch.  The thought occurs to me that
> perhaps ~/.rake shouldn't be a file, but a directory where you can drop
> xxx.rake files into.  This allows stuff from separate sources to be
> integrated without hassle.
>
> Thoughts?

May I make a slightly different suggestion here. I know it isn't the
typical way, but I've been trying to promote the idea to of using
shared hidden home directories. Home directories have gotten so
bloated with hidden config files, when I use a file dialog that
doesn't support any way to hide them it is annoying, to say the least.

So to help combat this I've been modeling my app's use of hidden home
locations roughly after FHS. Eg.

  ~/.bin/
  ~/.etc/
  ~/.lib/
  ~/.share/

For rake tasks ~/.lib/ might be the most appropriate, though /.share
is sort of safe bet for anything. So instead of ~/.rake, how about:

  ~/.lib/rake

Of course, both could be supported too.

> Also, I see you added '.rake' to the list of rakefile names.  I'm not sure
> that is necessary, since we never find ~/.rake when searching for rakefiles.

Hmm... Does it matter? Won't rake -T just say "no one home"? Also, the
optional alternative of  "_rake" could work too. That's what Darcs
does to support Windows better.

T.

From jonathan.stott at gmail.com  Thu Aug 21 05:46:46 2008
From: jonathan.stott at gmail.com (Jonathan Stott)
Date: Thu, 21 Aug 2008 10:46:46 +0100
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
Message-ID: <20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>

On Wed, 20 Aug 2008 14:51:21 -0400
Trans <transfire at gmail.com> wrote:
> 
> May I make a slightly different suggestion here. I know it isn't the
> typical way, but I've been trying to promote the idea to of using
> shared hidden home directories. Home directories have gotten so
> bloated with hidden config files, when I use a file dialog that
> doesn't support any way to hide them it is annoying, to say the least.
> 
> So to help combat this I've been modeling my app's use of hidden home
> locations roughly after FHS. Eg.
> 
>   ~/.bin/
>   ~/.etc/
>   ~/.lib/
>   ~/.share/
> 
> For rake tasks ~/.lib/ might be the most appropriate, though /.share
> is sort of safe bet for anything. So instead of ~/.rake, how about:
> 
>   ~/.lib/rake
> 
> Of course, both could be supported too.
> 
> > Also, I see you added '.rake' to the list of rakefile names.  I'm not sure
> > that is necessary, since we never find ~/.rake when searching for rakefiles.
> 
> Hmm... Does it matter? Won't rake -T just say "no one home"? Also, the
> optional alternative of  "_rake" could work too. That's what Darcs
> does to support Windows better.
> 

Perhaps the easiest solution, rather than checking for potentially infinite number of places where people might want to put this, is to have a default (~/.rake seems like a good place) and have the ability to override the default via an environmental variable?

Regards,
Jon

From jim.weirich at gmail.com  Thu Aug 21 09:32:41 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 21 Aug 2008 09:32:41 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
	<20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>
Message-ID: <4D659259-2249-4F41-A6F6-D6E69FBF12C9@gmail.com>


On Aug 21, 2008, at 5:46 AM, Jonathan Stott wrote:

> Perhaps the easiest solution, rather than checking for potentially  
> infinite number of places where people might want to put this, is to  
> have a default (~/.rake seems like a good place) and have the  
> ability to override the default via an environmental variable?


+1

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From transfire at gmail.com  Thu Aug 21 09:36:42 2008
From: transfire at gmail.com (Trans)
Date: Thu, 21 Aug 2008 09:36:42 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <4D659259-2249-4F41-A6F6-D6E69FBF12C9@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
	<20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>
	<4D659259-2249-4F41-A6F6-D6E69FBF12C9@gmail.com>
Message-ID: <4b6f054f0808210636s1b285ab2vf8e5cfe18b153db0@mail.gmail.com>

On Thu, Aug 21, 2008 at 9:32 AM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 21, 2008, at 5:46 AM, Jonathan Stott wrote:
>
>> Perhaps the easiest solution, rather than checking for potentially
>> infinite number of places where people might want to put this, is to have a
>> default (~/.rake seems like a good place) and have the ability to override
>> the default via an environmental variable?
>
>
> +1

Configuration over convention?

T.

From jim.weirich at gmail.com  Thu Aug 21 10:24:44 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 21 Aug 2008 10:24:44 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <4b6f054f0808210636s1b285ab2vf8e5cfe18b153db0@mail.gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
	<20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>
	<4D659259-2249-4F41-A6F6-D6E69FBF12C9@gmail.com>
	<4b6f054f0808210636s1b285ab2vf8e5cfe18b153db0@mail.gmail.com>
Message-ID: <DC57A251-7B71-4835-8E3B-C7D450F79C28@gmail.com>


On Aug 21, 2008, at 9:36 AM, Trans wrote:

> Configuration over convention?

Actually, that would be requiring an environment variable to enable it.

This is very much in line with the Rails convention over configuration  
by providing a default and allowing you to override when you really,  
really want to.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From transfire at gmail.com  Thu Aug 21 10:52:01 2008
From: transfire at gmail.com (Trans)
Date: Thu, 21 Aug 2008 10:52:01 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <DC57A251-7B71-4835-8E3B-C7D450F79C28@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<756A0249-0ED2-4B14-B5D8-0DC4DE7292CC@gmail.com>
	<4b6f054f0808201151h7cb0d876la28988a46997e4cb@mail.gmail.com>
	<20080821104646.178688a8@hzhangpg02.ph.man.ac.uk>
	<4D659259-2249-4F41-A6F6-D6E69FBF12C9@gmail.com>
	<4b6f054f0808210636s1b285ab2vf8e5cfe18b153db0@mail.gmail.com>
	<DC57A251-7B71-4835-8E3B-C7D450F79C28@gmail.com>
Message-ID: <4b6f054f0808210752v19059f2bt7afd7149f704e937@mail.gmail.com>

On Thu, Aug 21, 2008 at 10:24 AM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Aug 21, 2008, at 9:36 AM, Trans wrote:
>
>> Configuration over convention?
>
> Actually, that would be requiring an environment variable to enable it.
>
> This is very much in line with the Rails convention over configuration by
> providing a default and allowing you to override when you really, really
> want to.

I agree. I'm just trying to promote a _better default convention_ than
has previously been the norm (a shared hidden home directory).

T.

From adam.q.salter at gmail.com  Thu Aug 21 23:59:57 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Fri, 22 Aug 2008 13:59:57 +1000
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com><CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com><C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com><DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com><71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com><FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <1DCEDCEA-2ECD-4231-B4EE-801D033D00BD@gmail.com>


On 16/08/2008, at 1:54 AM, Berger, Daniel wrote:

> Don't do this:
>
> PLATFORM =~ /win32/
>
> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
> advent of alternative implementations like Jruby and IronRuby,
> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>
> Use rbconfig + host_os instead:
>
> require 'rbconfig'
>
> if Config::CONFIG['host_os'] =~ /mswin/I
> ...


Can someone please confirm that this is the "absolute" best way to  
check for Windows? There was some discussion that there would be  
different reports for MinGW...

Pending confirmation I'm going to use this method.

Thanks,
-Adam

From transfire at gmail.com  Fri Aug 22 03:03:24 2008
From: transfire at gmail.com (Trans)
Date: Fri, 22 Aug 2008 03:03:24 -0400
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <1DCEDCEA-2ECD-4231-B4EE-801D033D00BD@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
	<1DCEDCEA-2ECD-4231-B4EE-801D033D00BD@gmail.com>
Message-ID: <4b6f054f0808220003o669cd73cq46846c5ae4e5c4b0@mail.gmail.com>

On Thu, Aug 21, 2008 at 11:59 PM, Adam Salter <adam.q.salter at gmail.com> wrote:
>
> On 16/08/2008, at 1:54 AM, Berger, Daniel wrote:
>
>> Don't do this:
>>
>> PLATFORM =~ /win32/
>>
>> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
>> advent of alternative implementations like Jruby and IronRuby,
>> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
>> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>>
>> Use rbconfig + host_os instead:
>>
>> require 'rbconfig'
>>
>> if Config::CONFIG['host_os'] =~ /mswin/I
>> ...
>
>
> Can someone please confirm that this is the "absolute" best way to check for
> Windows? There was some discussion that there would be different reports for
> MinGW...
>
> Pending confirmation I'm going to use this method.

Or maybe 'gem/platform'.

T.

From luislavena at gmail.com  Fri Aug 22 03:26:06 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 22 Aug 2008 09:26:06 +0200
Subject: [Rake-devel] ~/.rake file?
In-Reply-To: <1DCEDCEA-2ECD-4231-B4EE-801D033D00BD@gmail.com>
References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com>
	<CFDE61AA-E4A9-4F86-9642-F390221EC2F8@gmail.com>
	<C24C236C-5009-4CAA-AFFA-3EC45059DA87@gmail.com>
	<DF712E1D-4FA7-4434-A378-820ED0CF1CBF@gmail.com>
	<71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com>
	<FA77149F-28C0-444D-896B-50BA9D4A244C@gmail.com>
	<D98EB00D-032D-42D5-B57B-C907E89AEE4A@gmail.com>
	<7524A45A1A5B264FA4809E2156496CFB023D3473@ITOMAE2KM01.AD.QINTRA.COM>
	<1DCEDCEA-2ECD-4231-B4EE-801D033D00BD@gmail.com>
Message-ID: <71166b3b0808220026i6a729ecen55a5ca69c57ebf73@mail.gmail.com>

On Fri, Aug 22, 2008 at 5:59 AM, Adam Salter <adam.q.salter at gmail.com> wrote:
>
> On 16/08/2008, at 1:54 AM, Berger, Daniel wrote:
>
>> Don't do this:
>>
>> PLATFORM =~ /win32/
>>
>> First, PLATFORM is deprecated instead of RUBY_PLATFORM. But, with the
>> advent of alternative implementations like Jruby and IronRuby,
>> RUBY_PLATFORM is no longer a wise approach. Jruby, for example, will
>> return 'java' for the RUBY_PLATFORM, even if you're on Windows.
>>
>> Use rbconfig + host_os instead:
>>
>> require 'rbconfig'
>>
>> if Config::CONFIG['host_os'] =~ /mswin/I
>> ...
>
>
> Can someone please confirm that this is the "absolute" best way to check for
> Windows? There was some discussion that there would be different reports for
> MinGW...
>
> Pending confirmation I'm going to use this method.
>

Let's make it simple, shall we?

D:\Users\Luis>ruby -rrbconfig -ve "puts RUBY_PLATFORM,
RbConfig::CONFIG['host_os']"

One-Click Ruby Installer:

ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]
i386-mswin32
mswin32


MinGW build:

ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32]
i386-mingw32
mingw32

jRuby:

ruby 1.8.6 (2008-04-22 rev 6555) [x86-jruby1.1.1]
java
mswin32

So:

RUBY_PLATFORM is almost the same than host_os, except for jRuby.

To clear up: the regular expression for Ruby on Windows will be: /mswin|mingw/
Use RbConfig::CONFIG['host_os'] to collect that information.

> Thanks,
> -Adam

HTH,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From jim.weirich at gmail.com  Sun Aug 24 23:11:24 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 24 Aug 2008 23:11:24 -0400
Subject: [Rake-devel] Merging the system .rake changes
Message-ID: <9B0BA747-57E1-4BDA-AC68-FFF480354E7B@gmail.com>

Regarding GitHub commit: http://github.com/adamsalter/rake/commit/352901dfa42a68d683a6834f6fab32b98127bd96

I've looked this over and am about finished merging the code.  There  
seemed to be a number of errors where the tests didn't match the code  
base, but I think I've worked them out.

Some issues and other random comments:

* I want to use the terminology "system rakefiles" (i.e. rakefiles  
defined at a system level) and "project rakefiles" (i.e. the standard  
rakefiles in a project).  With that in mind, I changed references from  
'rake_home_path' to 'system_dir'.  Likewise, I changed 'curdir' to  
'project' in several places.  (BTW, these methods are currently  
defined in TaskManager, that might not be their final destination).

* There was an inconsistency in the name of the win32 method to  
calculate the proper rake system directory on win32 boxes.  I can only  
assume that it wasn't tested on that platform.  I'm going to update  
the github gem in a bit.  If a windows user could grab that and verify  
that it works on the system, I would be extremely grateful.  I'll  
announce the availability of the gem when I upload it.

* There was an inconsistency in the flags passed on the command line.   
The code supported -G/g for system/no-system options, but the tests  
expected -m/-M (notice not only change in letters, but the swapping of  
case).  I think I like -g for --system and -G for --no-system  
(something different both the code AND tests).

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From adam.q.salter at gmail.com  Mon Aug 25 01:24:33 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Mon, 25 Aug 2008 15:24:33 +1000
Subject: [Rake-devel] Merging the system .rake changes
In-Reply-To: <9B0BA747-57E1-4BDA-AC68-FFF480354E7B@gmail.com>
References: <9B0BA747-57E1-4BDA-AC68-FFF480354E7B@gmail.com>
Message-ID: <4B593401-4050-45D7-B974-6A8BF85E20AB@gmail.com>

Jim,
Tested the gem. Works well.

I'm ok with your suggestion:
-g = use system rakefiles
-G = ignore system rakefiles

One thing I did notice is that it seems the "bubble up to rakefile"  
function doesn't work any more. Ie go to rakefile dir, change to  
subdirectory, type 'rake -T'... you get the system rakefile tasks. I  
think it's the order it does the checking for system rakefiles, it  
should bubble first, if no rakefiles found then system, if no system  
files found then exit. I guess this method is better, since it is more  
in line with older systems... I think I prefer the current way though.

Best,

On 25/08/2008, at 1:11 PM, Jim Weirich wrote:

> Regarding GitHub commit: http://github.com/adamsalter/rake/commit/352901dfa42a68d683a6834f6fab32b98127bd96
>
> I've looked this over and am about finished merging the code.  There  
> seemed to be a number of errors where the tests didn't match the  
> code base, but I think I've worked them out.
>
> Some issues and other random comments:
>
> * I want to use the terminology "system rakefiles" (i.e. rakefiles  
> defined at a system level) and "project rakefiles" (i.e. the  
> standard rakefiles in a project).  With that in mind, I changed  
> references from 'rake_home_path' to 'system_dir'.  Likewise, I  
> changed 'curdir' to 'project' in several places.  (BTW, these  
> methods are currently defined in TaskManager, that might not be  
> their final destination).
>
> * There was an inconsistency in the name of the win32 method to  
> calculate the proper rake system directory on win32 boxes.  I can  
> only assume that it wasn't tested on that platform.  I'm going to  
> update the github gem in a bit.  If a windows user could grab that  
> and verify that it works on the system, I would be extremely  
> grateful.  I'll announce the availability of the gem when I upload it.
>
> * There was an inconsistency in the flags passed on the command  
> line.  The code supported -G/g for system/no-system options, but the  
> tests expected -m/-M (notice not only change in letters, but the  
> swapping of case).  I think I like -g for --system and -G for --no- 
> system (something different both the code AND tests).
>
> -- 
> -- Jim Weirich
> -- jim.weirich at gmail.com
>
> _______________________________________________
> Rake-devel mailing list
> Rake-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rake-devel


From jim.weirich at gmail.com  Mon Aug 25 01:38:29 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 25 Aug 2008 01:38:29 -0400
Subject: [Rake-devel] Merging the system .rake changes
In-Reply-To: <4B593401-4050-45D7-B974-6A8BF85E20AB@gmail.com>
References: <9B0BA747-57E1-4BDA-AC68-FFF480354E7B@gmail.com>
	<4B593401-4050-45D7-B974-6A8BF85E20AB@gmail.com>
Message-ID: <4E3F5324-60FE-4C4A-9FD3-1E186B7DFA38@gmail.com>


On Aug 25, 2008, at 1:24 AM, Adam Salter wrote:

> Tested the gem. Works well.

Great!  What platform did you run it on?

> I'm ok with your suggestion:
> -g = use system rakefiles
> -G = ignore system rakefiles

Good.  I'm probably going to change this.

> One thing I did notice is that it seems the "bubble up to rakefile"  
> function doesn't work any more.

Yes, I just noticed that too.

> Ie go to rakefile dir, change to subdirectory, type 'rake -T'... you  
> get the system rakefile tasks. I think it's the order it does the  
> checking for system rakefiles, it should bubble first, if no  
> rakefiles found then system, if no system files found then exit. I  
> guess this method is better, since it is more in line with older  
> systems... I think I prefer the current way though.

The problem is that have_project_rakefile? doesn't bubble up when it  
does the checking.  Rake really needs to do the bubble up checking,  
that's was one of the first features of rake over make that was  
included, and I don't want to lose that.  If you are anywhere in the  
project, you will get project behavior.  Only when you are outside any  
project will you  get the system-wide behavior by default.

I'm working on fixing this.  I just want to make sure we don't do the  
bubble up search more than once.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From adam.q.salter at gmail.com  Mon Aug 25 09:07:58 2008
From: adam.q.salter at gmail.com (Adam Salter)
Date: Mon, 25 Aug 2008 23:07:58 +1000
Subject: [Rake-devel] Merging the system .rake changes
In-Reply-To: <4E3F5324-60FE-4C4A-9FD3-1E186B7DFA38@gmail.com>
References: <9B0BA747-57E1-4BDA-AC68-FFF480354E7B@gmail.com>
	<4B593401-4050-45D7-B974-6A8BF85E20AB@gmail.com>
	<4E3F5324-60FE-4C4A-9FD3-1E186B7DFA38@gmail.com>
Message-ID: <C4F8AB3E-5FC5-4C0F-9975-65A55D59C889@gmail.com>


On 25/08/2008, at 3:38 PM, Jim Weirich wrote:

> On Aug 25, 2008, at 1:24 AM, Adam Salter wrote:
>
>> Tested the gem. Works well.
>
> Great!  What platform did you run it on?

Woops. My bad. Unix (OSX).

>> Ie go to rakefile dir, change to subdirectory, type 'rake -T'...  
>> you get the system rakefile tasks. I think it's the order it does  
>> the checking for system rakefiles, it should bubble first, if no  
>> rakefiles found then system, if no system files found then exit. I  
>> guess this method is better, since it is more in line with older  
>> systems... I think I prefer the current way though.
>
> The problem is that have_project_rakefile? doesn't bubble up when it  
> does the checking.  Rake really needs to do the bubble up checking,  
> that's was one of the first features of rake over make that was  
> included, and I don't want to lose that.  If you are anywhere in the  
> project, you will get project behavior.  Only when you are outside  
> any project will you  get the system-wide behavior by default.
>
> I'm working on fixing this.  I just want to make sure we don't do  
> the bubble up search more than once.

OK. I'm glad you are working on this. I'm not sure I would know where  
to look, initially at least.

Best,
-Adam

From jim.weirich at gmail.com  Sun Aug 31 20:56:36 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Sun, 31 Aug 2008 20:56:36 -0400
Subject: [Rake-devel] Plans for 0.8.2 release
Message-ID: <BFEBFAD4-4EAF-42AA-A157-88E5F189B520@gmail.com>

The code base for 0.8.2 release is mostly feature complete.  I'm going  
to review the code for ruby 1.9 compatibility before the final  
release.  However, if you want to try the latest beta for ruby 1.8,  
you can pull the beta gem from GitHub.  The latest version is 0.8.1.9  
at the moment.

Enjoy.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com