From jim.weirich at gmail.com Wed Jul 2 21:08:20 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Wed, 2 Jul 2008 21:08:20 -0400 Subject: [Rake-devel] Git Repository for Rake on GitHub Message-ID: I have pushed a git repository for Rake up to github. You can find it at: http://github.com/jimweirich/rake I am going to start using this as my main remote repository. I will probably push updates to the RubyForge SVN repository on releases (at least for a while), but eventually the SVN repo will probably be disabled. Enjoy. -- -- Jim Weirich -- jim.weirich at gmail.com From ittay.dror at gmail.com Tue Jul 15 02:19:46 2008 From: ittay.dror at gmail.com (Ittay Dror (Freiman)) Date: Tue, 15 Jul 2008 09:19:46 +0300 Subject: [Rake-devel] [NEWBIE] task prerequisits and failures Message-ID: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> Hello, I hope this is the proper place to ask newbie questions, if not, please direct me. I'm looking at the source of rake.rb and it looks like rake doesn't pay attention to whether prerequisites were executed ok before executing the task itself (in invoke_with_callchain: 'execute' just follows 'invoke_prerequisites' and both don't seem to raise any exceptions). How can I stop invocation of dependent tasks? By raising an exception from the prerequisite action? Thank you, Ittay From assaf at labnotes.org Tue Jul 15 04:48:10 2008 From: assaf at labnotes.org (Assaf Arkin) Date: Tue, 15 Jul 2008 01:48:10 -0700 Subject: [Rake-devel] [NEWBIE] task prerequisits and failures In-Reply-To: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> References: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> Message-ID: <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> On Mon, Jul 14, 2008 at 11:19 PM, Ittay Dror (Freiman) wrote: > Hello, > > I hope this is the proper place to ask newbie questions, if not, > please direct me. > > I'm looking at the source of rake.rb and it looks like rake doesn't > pay attention to whether prerequisites were executed ok before > executing the task itself (in invoke_with_callchain: 'execute' just > follows 'invoke_prerequisites' and both don't seem to raise any > exceptions). > > How can I stop invocation of dependent tasks? By raising an exception > from the prerequisite action? If the task fails, raise an exception. That will just bubble up and get Rake to dump the exception and stop executing. -- Assaf http://labnotes.org > > > Thank you, > Ittay > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ittay.dror at gmail.com Tue Jul 15 07:06:02 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Tue, 15 Jul 2008 14:06:02 +0300 Subject: [Rake-devel] [NEWBIE] task prerequisits and failures In-Reply-To: <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> References: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> Message-ID: <487C849A.30107@gmail.com> Assaf Arkin wrote: > > How can I stop invocation of dependent tasks? By raising an exception > from the prerequisite action? > > > If the task fails, raise an exception. That will just bubble up and > get Rake to dump the exception and stop executing. Is there a way for a dependent task to ignore failures in the dependency tasks? > > -- Assaf > http://labnotes.org > > > > > Thank you, > Ittay > _______________________________________________ > 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 -- -- Ittay Dror -------------- next part -------------- An HTML attachment was scrubbed... URL: From assaf at labnotes.org Tue Jul 15 12:09:12 2008 From: assaf at labnotes.org (Assaf Arkin) Date: Tue, 15 Jul 2008 09:09:12 -0700 Subject: [Rake-devel] [NEWBIE] task prerequisits and failures In-Reply-To: <487C849A.30107@gmail.com> References: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> <487C849A.30107@gmail.com> Message-ID: <5037b6e40807150909u5c7f56dft22e81e85ec617d6f@mail.gmail.com> On Tue, Jul 15, 2008 at 4:06 AM, Ittay Dror wrote: > > > Assaf Arkin wrote: > > > How can I stop invocation of dependent tasks? By raising an exception >> from the prerequisite action? > > > If the task fails, raise an exception. That will just bubble up and get > Rake to dump the exception and stop executing. > > Is there a way for a dependent task to ignore failures in the dependency > tasks? > You can invoke the dependent task directly and just catch the error. Assaf > > > > -- Assaf > http://labnotes.org > > >> >> >> Thank you, >> Ittay >> _______________________________________________ >> Rake-devel mailing list >> Rake-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rake-devel >> > > ------------------------------ > _______________________________________________ > Rake-devel mailing listRake-devel at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rake-devel > > > -- > -- > Ittay Dror > > > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgs at dmu.ac.uk Tue Jul 15 13:48:53 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 15 Jul 2008 18:48:53 +0100 (BST) Subject: [Rake-devel] [NEWBIE] task prerequisits and failures In-Reply-To: <5037b6e40807150909u5c7f56dft22e81e85ec617d6f@mail.gmail.com> References: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> <487C849A.30107@gmail.com> <5037b6e40807150909u5c7f56dft22e81e85ec617d6f@mail.gmail.com> Message-ID: Pardon my top posting, but the layout below is (at least for me) confusing. It looks like Assaf Arkin has answered his own question and asked another. Could people use the long established convention of preceding quoted lines with "> " or "| ", please? As far as I can see there is no command line option to tell rake that certain tasks are considered up to date, so don't need executing. ISTR Gnu make can do that, so maybe split the rakefile, and invoke using gnu make? There's probably a better answer, though. Hugh On Tue, 15 Jul 2008, Assaf Arkin wrote: > > On Tue, Jul 15, 2008 at 4:06 AM, Ittay Dror wrote: > > > Assaf Arkin wrote: > > How can I stop invocation of dependent > tasks? By raising an exception > from the prerequisite action? > > > If the task fails, raise an exception. ?That will just bubble up > and get Rake to dump the exception and stop executing. > > Is there a way for a dependent task to ignore failures in the > dependency tasks? > > > You can invoke the dependent task directly and just catch the error. > > Assaf > ? > > > > -- Assaf > http://labnotes.org? > ? > > > Thank you, > Ittay > _______________________________________________ > 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 > > > -- > -- > Ittay Dror > > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > > > > From assaf at labnotes.org Tue Jul 15 20:27:30 2008 From: assaf at labnotes.org (Assaf Arkin) Date: Tue, 15 Jul 2008 17:27:30 -0700 Subject: [Rake-devel] [NEWBIE] task prerequisits and failures In-Reply-To: References: <667c668f0807142319q3bcdf491r151caa9a8d30bc94@mail.gmail.com> <5037b6e40807150148u3bfbe90en26e8289ca41c3546@mail.gmail.com> <487C849A.30107@gmail.com> <5037b6e40807150909u5c7f56dft22e81e85ec617d6f@mail.gmail.com> Message-ID: <5037b6e40807151727o146b745amc8c1129b1b7501e5@mail.gmail.com> On Tue, Jul 15, 2008 at 10:48 AM, Hugh Sasse wrote: > > Pardon my top posting, but the layout below is (at least for me) confusing. > It looks like Assaf Arkin has answered his own question and asked another. > Could people use the long established convention of preceding quoted lines > with "> " or "| ", please? Sorry about that. It reads fine in HTML, but for some reason don't get translated in the plain text sent along with the email, so I switched to plain text. > > As far as I can see there is no command line option to tell rake that certain > tasks are considered up to date, so don't need executing. ISTR Gnu make > can do that, so maybe split the rakefile, and invoke using gnu make? There's > probably a better answer, though. Shouldn't the be the responsibility of the task? A task can decide if it needs executing and return true/false from needed?(). Assaf > > Hugh > > On Tue, 15 Jul 2008, Assaf Arkin wrote: > >> >> On Tue, Jul 15, 2008 at 4:06 AM, Ittay Dror wrote: >> >> >> Assaf Arkin wrote: >> >> How can I stop invocation of dependent >> tasks? By raising an exception >> from the prerequisite action? >> >> >> If the task fails, raise an exception. That will just bubble up >> and get Rake to dump the exception and stop executing. >> >> Is there a way for a dependent task to ignore failures in the >> dependency tasks? >> >> >> You can invoke the dependent task directly and just catch the error. >> >> Assaf >> >> >> >> >> -- Assaf >> http://labnotes.org >> >> >> >> Thank you, >> Ittay >> _______________________________________________ >> 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 >> >> >> -- -- >> Ittay Dror >> >> _______________________________________________ >> 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 mjcurry at gmail.com Thu Jul 17 12:09:45 2008 From: mjcurry at gmail.com (Matthew Curry) Date: Thu, 17 Jul 2008 12:09:45 -0400 Subject: [Rake-devel] Setting a task's working directory on task definition Message-ID: <75b4567b0807170909w3449fcb3g709062da98c79155@mail.gmail.com> Hello rake devs: I wrote some code (as a redefinition of Rake classes) to support a new function called dirspace. Give dirspace a directory and a block as arguments, and each rake task defined until the end of the block will invoke and/or execute itself within that directory. I wrote it because I was including several .rake files into one large Rakefile at the top of my project, but still wanted the tasks defined within each .rake to be 'anchored' at that file's directory. Useless for Rails people I suppose, but more helpful as a general Make replacement as a way around respawning rake for each directory. Obviously the code needs some cleaning up, but any comments are welcome. Use similar to a namespace: dirspace "/tmp" do task :clean_tmp do Dir.glob('*').each do |f| rm_f f end end end And now the clean_tmp task will always execute in the /tmp directory. -Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: dirspace.rb Type: application/x-ruby Size: 1535 bytes Desc: not available URL: From ittay.dror at gmail.com Sun Jul 20 02:15:54 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Sun, 20 Jul 2008 09:15:54 +0300 Subject: [Rake-devel] Take 'invoke' out of Task Message-ID: <4882D81A.40001@gmail.com> Hi, Are there any plans to create an external execution engine that can then run tasks in parallel? MultiTask is helpful, but: 1. it is only local to one task 2. it creates threads per prerequisite, but it is better to only run thread-per-cpu 3. the threads continue to invoke other tasks, if several tasks rely on the same one, this creates unnecessary locking between the treads. an execution engine would run the relied on task and then run those tasks that depend on it in parallel without concern over synchronization. Btw, if not the full execution engine, can MultiTask be made into a module (mixin)? That way I can use it in a FileTask task. Thank you, Ittay -- -- Ittay Dror From ittay.dror at gmail.com Tue Jul 22 12:01:53 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Tue, 22 Jul 2008 19:01:53 +0300 Subject: [Rake-devel] makefile loader bu Message-ID: <48860471.8060008@gmail.com> when parsing dependency files in the format of make (generated by unix compilers), the file_task variable (actually, the file name) is not stripped. so if it contains spaces, it means it represents a different task than what you'd expect. here's the patch to solve this: --- rake/loaders/makefile.rb.orig 2008-07-22 19:01:11.000000000 +0300 +++ rake/loaders/makefile.rb 2008-07-22 18:55:59.000000000 +0300 @@ -29,6 +29,7 @@ # Process one logical line of makefile data. def process_line(line) file_task, args = line.split(':') + file_task.strip! return if args.nil? dependents = args.split file file_task => dependents -- -- Ittay Dror From ittay.dror at gmail.com Tue Jul 22 12:29:09 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Tue, 22 Jul 2008 19:29:09 +0300 Subject: [Rake-devel] makefile loader bu In-Reply-To: <48860471.8060008@gmail.com> References: <48860471.8060008@gmail.com> Message-ID: <48860AD5.4060706@gmail.com> I found that reading the whole file in one go and then parsing it is twice as fast as reading it line by line. Here's the patch: --- rake/loaders/makefile.rb.orig 2008-07-22 19:01:11.000000000 +0300 +++ rake/loaders/makefile.rb 2008-07-22 19:27:03.000000000 +0300 @@ -9,16 +9,10 @@ def load(fn) buffer = '' open(fn) do |mf| - mf.each do |line| - next if line =~ /^\s*#/ - buffer << line - if buffer =~ /\\$/ - buffer.sub!(/\\\n/, ' ') - state = :append - else - process_line(buffer) - buffer = '' - end + lines = mf.read + lines.gsub!(/\\\n/, ' ') + lines.split("\n").each do |line| + process_line line end end process_line(buffer) if buffer != '' Ittay Dror wrote: > when parsing dependency files in the format of make (generated by unix > compilers), the file_task variable (actually, the file name) is not > stripped. so if it contains spaces, it means it represents a different > task than what you'd expect. > > here's the patch to solve this: > --- rake/loaders/makefile.rb.orig 2008-07-22 19:01:11.000000000 +0300 > +++ rake/loaders/makefile.rb 2008-07-22 18:55:59.000000000 +0300 > @@ -29,6 +29,7 @@ > # Process one logical line of makefile data. > def process_line(line) > file_task, args = line.split(':') > + file_task.strip! > return if args.nil? > dependents = args.split > file file_task => dependents > > -- -- Ittay Dror From jim.weirich at gmail.com Tue Jul 22 19:14:16 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 22 Jul 2008 19:14:16 -0400 Subject: [Rake-devel] makefile loader bu In-Reply-To: <48860AD5.4060706@gmail.com> References: <48860471.8060008@gmail.com> <48860AD5.4060706@gmail.com> Message-ID: <1BD9A413-53BB-42DC-B9D1-32318939BE4A@gmail.com> On Jul 22, 2008, at 12:29 PM, Ittay Dror wrote: > when parsing dependency files in the format of make (generated by > unix compilers), the file_task variable (actually, the file name) is > not stripped. so if it contains spaces, it means it represents a > different task than what you'd expect. [and] > I found that reading the whole file in one go and then parsing it is > twice as fast as reading it line by line. Thanks. I've added these items to the Rake todo list. Do you have a test for the parsing bug? -- -- Jim Weirich -- jim.weirich at gmail.com From ittay.dror at gmail.com Tue Jul 22 23:55:52 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 23 Jul 2008 06:55:52 +0300 Subject: [Rake-devel] makefile loader bu In-Reply-To: <1BD9A413-53BB-42DC-B9D1-32318939BE4A@gmail.com> References: <48860471.8060008@gmail.com> <48860AD5.4060706@gmail.com> <1BD9A413-53BB-42DC-B9D1-32318939BE4A@gmail.com> Message-ID: <4886ABC8.2040602@gmail.com> Jim Weirich wrote: > On Jul 22, 2008, at 12:29 PM, Ittay Dror wrote: >> when parsing dependency files in the format of make (generated by >> unix compilers), the file_task variable (actually, the file name) is >> not stripped. so if it contains spaces, it means it represents a >> different task than what you'd expect. > > [and] > >> I found that reading the whole file in one go and then parsing it is >> twice as fast as reading it line by line. > > Thanks. I've added these items to the Rake todo list. Do you have a > test for the parsing bug? > Great. The parsing bug happened when generating files with 'g++ -MD' on ubuntu 8.04. It happened for several .cpp files only. The file starts with a backslash, newline, then the obj file name is preceded with a space. I don't know exactly why those files. Ittay -- -- Ittay Dror From ittay.dror at gmail.com Wed Jul 23 01:27:32 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 23 Jul 2008 08:27:32 +0300 Subject: [Rake-devel] timestamp checking is slow? Message-ID: <4886C144.7010408@gmail.com> Hi, I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm loading dependencies on header files. The total amount of dependencies is 869 on 142 obj files. The issue I'm seeing is that it takes a lot of time for Rake to timestamp these files to reach a conclusion that it has nothing to do. Compared to make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the creation of the dependencies (but still leave the loading and parsing of the files) rake takes 1 second. I understand that 2 seconds seem like not a long time, but the project I'm working on has over 1000 of source files, so I expect the time to be much larger. Do you think anything can be done to make Rake closer to make? note that without the timestamp checking, the rest of the work doesn't amount to a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that is the cause of the problem (but maybe poor implementation of File(file).mtime?) Thank you, Ittay -- -- Ittay Dror From watsonmw at gmail.com Wed Jul 23 04:15:19 2008 From: watsonmw at gmail.com (Mark Watson) Date: Wed, 23 Jul 2008 01:15:19 -0700 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <4886C144.7010408@gmail.com> References: <4886C144.7010408@gmail.com> Message-ID: <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> I ran into a similar issue, the way i got around it was by caching the timestamp the first time File.mtime is called. This brings about its own problems because you don't necessarily know that the file won't be modified outside the file task. If you have a task that generates several files the cached timestamps won't be updated. I tried using Windows API directly instead of File.mtime but this wasn't much faster. I didn't get a chance to look into what make is doing, but i suspect it is caching the timestamps too. Make does allow you to specify several files as the output of one task, possibly as a way around the problems with caching the timestamp. # File task with timestamp speedup. The regular file task will query # the File.mtime for every task that depends on this file. Typically # when compiling c/c++ some header files are included very often, and # if a a regular file task is used to represent header files then the # File.mtime function will be called each time a source file depends # on the header. By caching the timestamp we insure that this # operation occurs only once for each header file. On typical c/c++ # projects where most files depend on a core set of headers, a ~3x # speedup on rake startup time can be expected with this patch. # # WARNING: Caching the timestamp may cause problems if the file is # generated/updated by another task as a side effect. # class Rake::FastFileTask < Rake::FileTask # Time stamp for file task. def timestamp # Cache the timestamp since it is accessed often if instance_variable_defined?(:@timestamp) @timestamp else # exist? and mtime can be done together with one call to File.stat, but # for some reason this takes longer on Windows. Ruby is probably making # several Win32 calls. Opimization would be to call GetFileAttributesEx() # directly. Using Win32API module this is slightly faster, making the # call via a c extension would probably be faster again. if File.exist?(name) @timestamp = File.mtime(name.to_s) # Update the time stamp when the task is executed enhance do @timestamp = Time.now end @timestamp else # Build me! Rake::EARLY end end end end 2008/7/22 Ittay Dror : > Hi, > > I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm > loading dependencies on header files. The total amount of dependencies is > 869 on 142 obj files. > > The issue I'm seeing is that it takes a lot of time for Rake to timestamp > these files to reach a conclusion that it has nothing to do. Compared to > make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the > creation of the dependencies (but still leave the loading and parsing of the > files) rake takes 1 second. > > I understand that 2 seconds seem like not a long time, but the project I'm > working on has over 1000 of source files, so I expect the time to be much > larger. Do you think anything can be done to make Rake closer to make? note > that without the timestamp checking, the rest of the work doesn't amount to > a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that > is the cause of the problem (but maybe poor implementation of > File(file).mtime?) > > Thank you, > Ittay > > -- > -- > Ittay Dror > > > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > From ittay.dror at gmail.com Wed Jul 23 05:31:14 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 23 Jul 2008 12:31:14 +0300 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> References: <4886C144.7010408@gmail.com> <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> Message-ID: <4886FA62.4030907@gmail.com> I applied your change and it sped up the execution by 0.1s :-(. I then just added a 'return Rake::EARLY' at the start of #timestamp. This also didn't improve time. So it must be something with the rake code that calls the timestamp method. Ittay Mark Watson wrote: > I ran into a similar issue, the way i got around it was by caching the > timestamp the first time File.mtime is called. This brings about its > own problems because you don't necessarily know that the file won't be > modified outside the file task. If you have a task that generates > several files the cached timestamps won't be updated. > > I tried using Windows API directly instead of File.mtime but this > wasn't much faster. I didn't get a chance to look into what make is > doing, but i suspect it is caching the timestamps too. Make does > allow you to specify several files as the output of one task, possibly > as a way around the problems with caching the timestamp. > > # File task with timestamp speedup. The regular file task will query > # the File.mtime for every task that depends on this file. Typically > # when compiling c/c++ some header files are included very often, and > # if a a regular file task is used to represent header files then the > # File.mtime function will be called each time a source file depends > # on the header. By caching the timestamp we insure that this > # operation occurs only once for each header file. On typical c/c++ > # projects where most files depend on a core set of headers, a ~3x > # speedup on rake startup time can be expected with this patch. > # > # WARNING: Caching the timestamp may cause problems if the file is > # generated/updated by another task as a side effect. > # > class Rake::FastFileTask < Rake::FileTask > # Time stamp for file task. > def timestamp > # Cache the timestamp since it is accessed often > if instance_variable_defined?(:@timestamp) > @timestamp > else > # exist? and mtime can be done together with one call to File.stat, but > # for some reason this takes longer on Windows. Ruby is probably making > # several Win32 calls. Opimization would be to call GetFileAttributesEx() > # directly. Using Win32API module this is slightly faster, making the > # call via a c extension would probably be faster again. > if File.exist?(name) > @timestamp = File.mtime(name.to_s) > # Update the time stamp when the task is executed > enhance do > @timestamp = Time.now > end > @timestamp > else > # Build me! > Rake::EARLY > end > end > end > end > > 2008/7/22 Ittay Dror : > >> Hi, >> >> I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm >> loading dependencies on header files. The total amount of dependencies is >> 869 on 142 obj files. >> >> The issue I'm seeing is that it takes a lot of time for Rake to timestamp >> these files to reach a conclusion that it has nothing to do. Compared to >> make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the >> creation of the dependencies (but still leave the loading and parsing of the >> files) rake takes 1 second. >> >> I understand that 2 seconds seem like not a long time, but the project I'm >> working on has over 1000 of source files, so I expect the time to be much >> larger. Do you think anything can be done to make Rake closer to make? note >> that without the timestamp checking, the rest of the work doesn't amount to >> a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that >> is the cause of the problem (but maybe poor implementation of >> File(file).mtime?) >> >> Thank you, >> Ittay >> >> -- >> -- >> Ittay Dror >> >> >> _______________________________________________ >> 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 > -- -- Ittay Dror -------------- next part -------------- An HTML attachment was scrubbed... URL: From ittay.dror at gmail.com Wed Jul 23 05:42:32 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 23 Jul 2008 12:42:32 +0300 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <4886FA62.4030907@gmail.com> References: <4886C144.7010408@gmail.com> <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> <4886FA62.4030907@gmail.com> Message-ID: <4886FD08.7020902@gmail.com> More dicoveries: It looks like 'File.exists' is slow. I did two changes: - comment the first line in FileTask#needed? - change FileTask#timestamp to: begin File.stat(name).mtime rescue Rake::EARLY end this shaved 0.5 second (20% from the whole run time, or 30% from the time added after adding the header dependencies). ittay Ittay Dror wrote: > I applied your change and it sped up the execution by 0.1s :-(. > > I then just added a 'return Rake::EARLY' at the start of #timestamp. > This also didn't improve time. So it must be something with the rake > code that calls the timestamp method. > > Ittay > > Mark Watson wrote: >> I ran into a similar issue, the way i got around it was by caching the >> timestamp the first time File.mtime is called. This brings about its >> own problems because you don't necessarily know that the file won't be >> modified outside the file task. If you have a task that generates >> several files the cached timestamps won't be updated. >> >> I tried using Windows API directly instead of File.mtime but this >> wasn't much faster. I didn't get a chance to look into what make is >> doing, but i suspect it is caching the timestamps too. Make does >> allow you to specify several files as the output of one task, possibly >> as a way around the problems with caching the timestamp. >> >> # File task with timestamp speedup. The regular file task will query >> # the File.mtime for every task that depends on this file. Typically >> # when compiling c/c++ some header files are included very often, and >> # if a a regular file task is used to represent header files then the >> # File.mtime function will be called each time a source file depends >> # on the header. By caching the timestamp we insure that this >> # operation occurs only once for each header file. On typical c/c++ >> # projects where most files depend on a core set of headers, a ~3x >> # speedup on rake startup time can be expected with this patch. >> # >> # WARNING: Caching the timestamp may cause problems if the file is >> # generated/updated by another task as a side effect. >> # >> class Rake::FastFileTask < Rake::FileTask >> # Time stamp for file task. >> def timestamp >> # Cache the timestamp since it is accessed often >> if instance_variable_defined?(:@timestamp) >> @timestamp >> else >> # exist? and mtime can be done together with one call to File.stat, but >> # for some reason this takes longer on Windows. Ruby is probably making >> # several Win32 calls. Opimization would be to call GetFileAttributesEx() >> # directly. Using Win32API module this is slightly faster, making the >> # call via a c extension would probably be faster again. >> if File.exist?(name) >> @timestamp = File.mtime(name.to_s) >> # Update the time stamp when the task is executed >> enhance do >> @timestamp = Time.now >> end >> @timestamp >> else >> # Build me! >> Rake::EARLY >> end >> end >> end >> end >> >> 2008/7/22 Ittay Dror : >> >>> Hi, >>> >>> I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm >>> loading dependencies on header files. The total amount of dependencies is >>> 869 on 142 obj files. >>> >>> The issue I'm seeing is that it takes a lot of time for Rake to timestamp >>> these files to reach a conclusion that it has nothing to do. Compared to >>> make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the >>> creation of the dependencies (but still leave the loading and parsing of the >>> files) rake takes 1 second. >>> >>> I understand that 2 seconds seem like not a long time, but the project I'm >>> working on has over 1000 of source files, so I expect the time to be much >>> larger. Do you think anything can be done to make Rake closer to make? note >>> that without the timestamp checking, the rest of the work doesn't amount to >>> a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that >>> is the cause of the problem (but maybe poor implementation of >>> File(file).mtime?) >>> >>> Thank you, >>> Ittay >>> >>> -- >>> -- >>> Ittay Dror >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > -- > Ittay Dror > -- -- Ittay Dror -------------- next part -------------- An HTML attachment was scrubbed... URL: From watsonmw at gmail.com Wed Jul 23 14:30:01 2008 From: watsonmw at gmail.com (Mark Watson) Date: Wed, 23 Jul 2008 11:30:01 -0700 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <4886FD08.7020902@gmail.com> References: <4886C144.7010408@gmail.com> <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> <4886FA62.4030907@gmail.com> <4886FD08.7020902@gmail.com> Message-ID: <2576e5830807231130u38043ce2t8408c34b695ab437@mail.gmail.com> I should say that I'm running on WindowsXP. On WindowsXP I found pretty much the opposite, minimizings calls to File.exist? provided a tiny improvement, but the change to File.mtime provided a large speedup :p What OS are you running on? Also it may depend on the project, i.e. the total number of headers and how the dependencies are distributed among the source files. 2008/7/23 Ittay Dror : > More dicoveries: > It looks like 'File.exists' is slow. I did two changes: > - comment the first line in FileTask#needed? > - change FileTask#timestamp to: > begin > File.stat(name).mtime > rescue > Rake::EARLY > end > > this shaved 0.5 second (20% from the whole run time, or 30% from the time > added after adding the header dependencies). > > ittay > > Ittay Dror wrote: > > I applied your change and it sped up the execution by 0.1s :-(. > > I then just added a 'return Rake::EARLY' at the start of #timestamp. This > also didn't improve time. So it must be something with the rake code that > calls the timestamp method. > > Ittay > > Mark Watson wrote: > > I ran into a similar issue, the way i got around it was by caching the > timestamp the first time File.mtime is called. This brings about its > own problems because you don't necessarily know that the file won't be > modified outside the file task. If you have a task that generates > several files the cached timestamps won't be updated. > > I tried using Windows API directly instead of File.mtime but this > wasn't much faster. I didn't get a chance to look into what make is > doing, but i suspect it is caching the timestamps too. Make does > allow you to specify several files as the output of one task, possibly > as a way around the problems with caching the timestamp. > > # File task with timestamp speedup. The regular file task will query > # the File.mtime for every task that depends on this file. Typically > # when compiling c/c++ some header files are included very often, and > # if a a regular file task is used to represent header files then the > # File.mtime function will be called each time a source file depends > # on the header. By caching the timestamp we insure that this > # operation occurs only once for each header file. On typical c/c++ > # projects where most files depend on a core set of headers, a ~3x > # speedup on rake startup time can be expected with this patch. > # > # WARNING: Caching the timestamp may cause problems if the file is > # generated/updated by another task as a side effect. > # > class Rake::FastFileTask < Rake::FileTask > # Time stamp for file task. > def timestamp > # Cache the timestamp since it is accessed often > if instance_variable_defined?(:@timestamp) > @timestamp > else > # exist? and mtime can be done together with one call to File.stat, > but > # for some reason this takes longer on Windows. Ruby is probably > making > # several Win32 calls. Opimization would be to call > GetFileAttributesEx() > # directly. Using Win32API module this is slightly faster, making the > # call via a c extension would probably be faster again. > if File.exist?(name) > @timestamp = File.mtime(name.to_s) > # Update the time stamp when the task is executed > enhance do > @timestamp = Time.now > end > @timestamp > else > # Build me! > Rake::EARLY > end > end > end > end > > 2008/7/22 Ittay Dror : > > > Hi, > > I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm > loading dependencies on header files. The total amount of dependencies is > 869 on 142 obj files. > > The issue I'm seeing is that it takes a lot of time for Rake to timestamp > these files to reach a conclusion that it has nothing to do. Compared to > make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the > creation of the dependencies (but still leave the loading and parsing of the > files) rake takes 1 second. > > I understand that 2 seconds seem like not a long time, but the project I'm > working on has over 1000 of source files, so I expect the time to be much > larger. Do you think anything can be done to make Rake closer to make? note > that without the timestamp checking, the rest of the work doesn't amount to > a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that > is the cause of the problem (but maybe poor implementation of > File(file).mtime?) > > Thank you, > Ittay > > -- > -- > Ittay Dror > > > _______________________________________________ > 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 > > > -- > -- > Ittay Dror > > > -- > -- > Ittay Dror > > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > From ittay.dror at gmail.com Wed Jul 23 14:44:05 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 23 Jul 2008 21:44:05 +0300 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <2576e5830807231130u38043ce2t8408c34b695ab437@mail.gmail.com> References: <4886C144.7010408@gmail.com> <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> <4886FA62.4030907@gmail.com> <4886FD08.7020902@gmail.com> <2576e5830807231130u38043ce2t8408c34b695ab437@mail.gmail.com> Message-ID: <48877BF5.5030206@gmail.com> Mark Watson wrote: > I should say that I'm running on WindowsXP. On WindowsXP I found > pretty much the opposite, minimizings calls to File.exist? provided a > tiny improvement, but the change to File.mtime provided a large > speedup :p > Well, both changes improve, so why not apply both? > What OS are you running on? > Linux (Ubuntu) > Also it may depend on the project, i.e. the total number of headers > and how the dependencies are distributed among the source files. > > 2008/7/23 Ittay Dror : > >> More dicoveries: >> It looks like 'File.exists' is slow. I did two changes: >> - comment the first line in FileTask#needed? >> - change FileTask#timestamp to: >> begin >> File.stat(name).mtime >> rescue >> Rake::EARLY >> end >> >> this shaved 0.5 second (20% from the whole run time, or 30% from the time >> added after adding the header dependencies). >> >> ittay >> >> Ittay Dror wrote: >> >> I applied your change and it sped up the execution by 0.1s :-(. >> >> I then just added a 'return Rake::EARLY' at the start of #timestamp. This >> also didn't improve time. So it must be something with the rake code that >> calls the timestamp method. >> >> Ittay >> >> Mark Watson wrote: >> >> I ran into a similar issue, the way i got around it was by caching the >> timestamp the first time File.mtime is called. This brings about its >> own problems because you don't necessarily know that the file won't be >> modified outside the file task. If you have a task that generates >> several files the cached timestamps won't be updated. >> >> I tried using Windows API directly instead of File.mtime but this >> wasn't much faster. I didn't get a chance to look into what make is >> doing, but i suspect it is caching the timestamps too. Make does >> allow you to specify several files as the output of one task, possibly >> as a way around the problems with caching the timestamp. >> >> # File task with timestamp speedup. The regular file task will query >> # the File.mtime for every task that depends on this file. Typically >> # when compiling c/c++ some header files are included very often, and >> # if a a regular file task is used to represent header files then the >> # File.mtime function will be called each time a source file depends >> # on the header. By caching the timestamp we insure that this >> # operation occurs only once for each header file. On typical c/c++ >> # projects where most files depend on a core set of headers, a ~3x >> # speedup on rake startup time can be expected with this patch. >> # >> # WARNING: Caching the timestamp may cause problems if the file is >> # generated/updated by another task as a side effect. >> # >> class Rake::FastFileTask < Rake::FileTask >> # Time stamp for file task. >> def timestamp >> # Cache the timestamp since it is accessed often >> if instance_variable_defined?(:@timestamp) >> @timestamp >> else >> # exist? and mtime can be done together with one call to File.stat, >> but >> # for some reason this takes longer on Windows. Ruby is probably >> making >> # several Win32 calls. Opimization would be to call >> GetFileAttributesEx() >> # directly. Using Win32API module this is slightly faster, making the >> # call via a c extension would probably be faster again. >> if File.exist?(name) >> @timestamp = File.mtime(name.to_s) >> # Update the time stamp when the task is executed >> enhance do >> @timestamp = Time.now >> end >> @timestamp >> else >> # Build me! >> Rake::EARLY >> end >> end >> end >> end >> >> 2008/7/22 Ittay Dror : >> >> >> Hi, >> >> I'm using Rake (actually Buildr) to compile C++ files. As part of that I'm >> loading dependencies on header files. The total amount of dependencies is >> 869 on 142 obj files. >> >> The issue I'm seeing is that it takes a lot of time for Rake to timestamp >> these files to reach a conclusion that it has nothing to do. Compared to >> make that takes 0.7 seconds to run, Rake takes 3 seconds. If I remove the >> creation of the dependencies (but still leave the loading and parsing of the >> files) rake takes 1 second. >> >> I understand that 2 seconds seem like not a long time, but the project I'm >> working on has over 1000 of source files, so I expect the time to be much >> larger. Do you think anything can be done to make Rake closer to make? note >> that without the timestamp checking, the rest of the work doesn't amount to >> a lot of overhead, so I am hoping it is not the dynamic nature of Ruby that >> is the cause of the problem (but maybe poor implementation of >> File(file).mtime?) >> >> Thank you, >> Ittay >> >> -- >> -- >> Ittay Dror >> >> >> _______________________________________________ >> 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 >> >> >> -- >> -- >> Ittay Dror >> >> >> -- >> -- >> Ittay Dror >> >> _______________________________________________ >> 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 > -- -- Ittay Dror -------------- next part -------------- An HTML attachment was scrubbed... URL: From watsonmw at gmail.com Wed Jul 23 15:16:23 2008 From: watsonmw at gmail.com (Mark Watson) Date: Wed, 23 Jul 2008 12:16:23 -0700 Subject: [Rake-devel] timestamp checking is slow? In-Reply-To: <48877BF5.5030206@gmail.com> References: <4886C144.7010408@gmail.com> <2576e5830807230115i25796a9elb28d6dafcac829a4@mail.gmail.com> <4886FA62.4030907@gmail.com> <4886FD08.7020902@gmail.com> <2576e5830807231130u38043ce2t8408c34b695ab437@mail.gmail.com> <48877BF5.5030206@gmail.com> Message-ID: <2576e5830807231216m7adacc7epe9a4d4565042c9ae@mail.gmail.com> > Well, both changes improve, so why not apply both? Totally agree that minimizing calls to File.mtime and File.exist is a really good idea. I'm a bit concerned that the changes above will brake things for other rake users, so I favour having a special file task with the optimizations for the time being. The other option is to think though all the cases and make sure the changes don't break FileTask. This is more work, but better in the long run :p From tony.strauss at designingpatterns.com Fri Jul 25 13:57:37 2008 From: tony.strauss at designingpatterns.com (Tony Strauss) Date: Fri, 25 Jul 2008 13:57:37 -0400 Subject: [Rake-devel] Stop rake from passing in the 'html' template to rdoc by default Message-ID: http://github.com/DesigningPatterns/rake/tree/master contains a small change to rdoctask.rb that stops rake from specifying the html template to rdoc by default. I think that this is a reasonable change because: 1.) rdoc already defaults to the html template, so rake also defaulting to the html template has no effect. 2.) rake's defaulting to the html template means that it always specifies a template to rdoc, which overrides any template specified in the RDOCOPT environment variable. This change allows rdoc when invoked through rake to output to different templates based on the RDOCOPT environment variable, even if the rake tasks (like those provided by hoe) do not allow the specification of an rdoc template. Tony -- Tony Strauss Designing Patterns, LLC http://www.designingpatterns.com http://blogs.designingpatterns.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.q.salter at gmail.com Sun Jul 27 10:23:25 2008 From: adam.q.salter at gmail.com (Adam Salter) Date: Mon, 28 Jul 2008 00:23:25 +1000 Subject: [Rake-devel] ~/.rake file? In-Reply-To: <71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com> References: <16F8446D-EBF2-485F-AE76-A19D5E9AAFF4@gmail.com> <71166b3b0806300653y3accd271u6c5b1c78f3ba8ee@mail.gmail.com> Message-ID: 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-added-system-wide-.rake-functionality.patch Type: application/octet-stream Size: 5258 bytes Desc: not available URL: -------------- next part -------------- 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 > 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 From adamm at zombino.com Sun Jul 27 16:54:44 2008 From: adamm at zombino.com (Adam Majer) Date: Sun, 27 Jul 2008 15:54:44 -0500 Subject: [Rake-devel] Current rake version number? Message-ID: <488CE094.9070904@zombino.com> Hi, 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 reading the list will view rubyforge as current source. Please remove the subversion repository and have a comment about current project location on github. Then there is the interesting entries in CHANGES that contradict .gitignore comments. CHANGES lists current version as pre-0.8.2, but .gitignore lists 0.8.1.3. Are 0.8.1.x development snapshots? Or bugfixes? Which one should be used? 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. Cheers, Adam -- Mail Etiquette ============== * Quote properly or not at all. Top posters, this applies to you! * When replying to posts on mailing lists, only address the mailing list unless poster explicitly requested you include them in CC From jim.weirich at gmail.com Mon Jul 28 00:45:13 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 28 Jul 2008 00:45:13 -0400 Subject: [Rake-devel] Current rake version number? In-Reply-To: <488CE094.9070904@zombino.com> References: <488CE094.9070904@zombino.com> Message-ID: <4C0671AE-452A-4F82-89DE-15A30F62031D@gmail.com> 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 > reading the list will view rubyforge as current source. Please remove > the subversion repository and have a comment about current project > location on github. 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? > Then there is the interesting entries in CHANGES that contradict > .gitignore comments. CHANGES lists current version as pre-0.8.2, but > .gitignore lists 0.8.1.3. Are 0.8.1.x development snapshots? Or > bugfixes? Which one should be used? All official Rake releases will have a 3-level revision tag. A 4- level revision tag indicates an intermediate release (i.e. all 0.8.1.x revision are pre 0.8.2) for either internal use or sometimes released as a beta (from http://onestepback.org/betagems). > 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. -- -- Jim Weirich -- jim.weirich at gmail.com From ittay.dror at gmail.com Wed Jul 30 03:02:44 2008 From: ittay.dror at gmail.com (Ittay Dror) Date: Wed, 30 Jul 2008 10:02:44 +0300 Subject: [Rake-devel] SIGSEGV: @prerequisites use of FileList Message-ID: <48901214.3050701@gmail.com> Hi, I'm using Buildr to build several modules of c++ code. I'm using ruby 1.8.7 (p22) and all the latest gems. I compiled ruby on my machine. I'm seeing segmentation faults (that may or may not have happened with ruby 1.8.6) which seem to be related to Task at prerequisites being a FileList. When I replace @prerequisites = FileList[] with @prerequisites = [] everything works. Do you think you can help me investigate this? Thank you, Ittay -- -- Ittay Dror