From dsisnero at gmail.com Tue May 18 19:15:16 2010 From: dsisnero at gmail.com (Dominic Sisneros) Date: Tue, 18 May 2010 17:15:16 -0600 Subject: [Rake-devel] Add path ( Pathname to file tasks) Message-ID: I would like to add path to FileTask to make it easier to create file tasks file 'test.txt' do |t| t.path.open('w') do |file| file.puts "It works" end end as opposed to file 'test.txt' do |t| File.open( t.name) do |file| ... class FileTask < Task + attr_reader :path + + def initialize(*args) + super + @path = Pathname.new(name) + end + + The patch also changes directory to use Pathname.ascend so pathname objects can be used. It passes all tests root = Pathname.getwd tmp = root + 'tmp' directory tmp -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pathname.patch Type: application/octet-stream Size: 2938 bytes Desc: not available URL: From hkehoe at budcat.com Wed May 19 13:13:55 2010 From: hkehoe at budcat.com (Heath Kehoe) Date: Wed, 19 May 2010 12:13:55 -0500 Subject: [Rake-devel] Comments from a new rake user Message-ID: <4BF41C53.5030900@budcat.com> Hello all, I have recently implemented a build system based on Rake for a decently-sized project (~8000 source files) which builds code and data for several libraries and applications targeting four separate platforms. I was new to both rake and ruby when I started; and it's a testament to the awesomeness of both that I was able to learn them quickly to be able to implement a fairly complicated system in less than a month. Anyway, I wanted to pass along some comments. Firstly, when I first got stuff building with rake (replacing a build environment that used gnu make) I noticed that a null build (where everything was up to date) took a really long time. I used the ruby profiler and found that approx. half the run time was spent doing file stats (exist? and mtime), with an average of 70 calls *per file* during a rake run. As it runs under Cygwin on Windows those file stat operations are more expensive than they are on Linux. I should note that I'm using ruby 1.8.7 and the rake that gem installed (0.8.7). If you look at the FileTask code, the needed? method calls File.exist? then timestamp, which calls File.exist? then File.mtime. That's three stats in a row right there for the file itself; then each prerequisite is asked for its timestamp which generates two stats for each (for FileTasks that is). My approach was to create a simple global cache that uses the filename as the key and stores the file's mtime. module Rake # Modify Rake's FileTask to use our cached file tests class FileTask < Task def needed? ! File.cached_exist?(name) || out_of_date?(timestamp) end def timestamp if File.cached_exist?(name) File.cached_mtime(name.to_s) else Rake::EARLY end end def execute(args=nil) ret = super File.invalidate_cache(name) ret end end end The invalidate_cache method simply deletes the cache entry for the given file; which is necessary if the file was changed by the task's action. The execute method does this for the FileTasks's own target; if an action creates or modifies other files as a side-effect, I explicitly call invalidate_cache in the action block for each side-effect file to make sure the cache doesn't contain any stale info. This change resulted in an order of magnitude improvement in run-time. Now, I'm not saying rake should adopt this specific optimization; however I think you should consider some type of caching to reduce the quantity of exist?/mtime calls. Perhaps the FileTask could simply cache its own exist?/mtime results (invalidated when execute runs). I have more to say about dependency generation and multitasking, but I'll send those thoughts in separate emails. -Heath ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From antoine at lunar-ocean.com Wed May 19 13:22:48 2010 From: antoine at lunar-ocean.com (Antoine Toulme) Date: Wed, 19 May 2010 10:22:48 -0700 Subject: [Rake-devel] Comments from a new rake user In-Reply-To: <4BF41C53.5030900@budcat.com> References: <4BF41C53.5030900@budcat.com> Message-ID: Hey, what kind of sources were you building ? I'm committer on Buildr and we built on Rake as well. Just curious. Antoine On Wed, May 19, 2010 at 10:13, Heath Kehoe wrote: > Hello all, > > I have recently implemented a build system based on Rake for a > decently-sized project (~8000 source files) which builds code and data for > several libraries and applications targeting four separate platforms. > > I was new to both rake and ruby when I started; and it's a testament to the > awesomeness of both that I was able to learn them quickly to be able to > implement a fairly complicated system in less than a month. > > Anyway, I wanted to pass along some comments. > > Firstly, when I first got stuff building with rake (replacing a build > environment that used gnu make) I noticed that a null build (where > everything was up to date) took a really long time. I used the ruby profiler > and found that approx. half the run time was spent doing file stats (exist? > and mtime), with an average of 70 calls *per file* during a rake run. As it > runs under Cygwin on Windows those file stat operations are more expensive > than they are on Linux. I should note that I'm using ruby 1.8.7 and the rake > that gem installed (0.8.7). > > If you look at the FileTask code, the needed? method calls File.exist? then > timestamp, which calls File.exist? then File.mtime. That's three stats in a > row right there for the file itself; then each prerequisite is asked for its > timestamp which generates two stats for each (for FileTasks that is). My > approach was to create a simple global cache that uses the filename as the > key and stores the file's mtime. > > module Rake > # Modify Rake's FileTask to use our cached file tests > class FileTask < Task > def needed? > ! File.cached_exist?(name) || out_of_date?(timestamp) > end > > def timestamp > if File.cached_exist?(name) > File.cached_mtime(name.to_s) > else > Rake::EARLY > end > end > > def execute(args=nil) > ret = super > File.invalidate_cache(name) > ret > end > end > end > > The invalidate_cache method simply deletes the cache entry for the given > file; which is necessary if the file was changed by the task's action. The > execute method does this for the FileTasks's own target; if an action > creates or modifies other files as a side-effect, I explicitly call > invalidate_cache in the action block for each side-effect file to make sure > the cache doesn't contain any stale info. > > This change resulted in an order of magnitude improvement in run-time. > > Now, I'm not saying rake should adopt this specific optimization; however I > think you should consider some type of caching to reduce the quantity of > exist?/mtime calls. Perhaps the FileTask could simply cache its own > exist?/mtime results (invalidated when execute runs). > > I have more to say about dependency generation and multitasking, but I'll > send those thoughts in separate emails. > > -Heath > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > _______________________________________________ > 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 hkehoe at budcat.com Wed May 19 14:02:45 2010 From: hkehoe at budcat.com (Heath Kehoe) Date: Wed, 19 May 2010 13:02:45 -0500 Subject: [Rake-devel] Comments from a new rake user In-Reply-To: References: <4BF41C53.5030900@budcat.com> Message-ID: <4BF427C5.2060505@budcat.com> On 5/19/2010 12:22 PM, Antoine Toulme wrote: > Hey, > > what kind of sources were you building ? I'm committer on Buildr and > we built on Rake as well. Just curious. > > Antoine C++, along with custom data/asset builders -h ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From hkehoe at budcat.com Wed May 19 14:00:53 2010 From: hkehoe at budcat.com (Heath Kehoe) Date: Wed, 19 May 2010 13:00:53 -0500 Subject: [Rake-devel] Comments about parallel building Message-ID: <4BF42755.9080900@budcat.com> For our project one of the top goals was minimizing build times; so being able to invoke compilers/linkers in parallel to take advantage of multiple-core computers was a necessity. (Since finishing my implementation, I have learned about drake. I intend to take a look at that as a possible alternative approach.) The user specifies "j=N" on the command line, similar to make's -jN. When N>1, tasks are created as MultiTasks. Since FileTasks aren't MultiTasks, when there's a library or application, a MultiTask is created that has all the object files as prerequisistes; then the library/app includes that MultiTask in its prerequisites. This allows the object files to compile in parallel. Since MultiTasks run all their prereqs at the same time, I made a custom version of the 'sh' method which synchronizes using a semaphore; that semaphore is initialized with the j=N value that the user specified. That way, only N commands will be invoked at once. Recently, I tried updating to ruby 1.9.1. My MultiTask approach fell down because it created too many threads. 1.9 uses 'real' threads which consume more resources than 1.8's 'fake' (but very lightweight) threads. When I modified MultiTask to spawn threads in batches to limit their number, it worked but it was many times slower than before, probably due to the additional overhead of creating/joining lots of OS threads. So we're sticking with ruby 1.8 for now. As I said, perhaps drake's approach will be better for 1.9, I'll try that out sometime. -heath ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From antoine at lunar-ocean.com Wed May 19 14:06:27 2010 From: antoine at lunar-ocean.com (Antoine Toulme) Date: Wed, 19 May 2010 11:06:27 -0700 Subject: [Rake-devel] Comments from a new rake user In-Reply-To: <4BF427C5.2060505@budcat.com> References: <4BF41C53.5030900@budcat.com> <4BF427C5.2060505@budcat.com> Message-ID: Cool, let me know if it becomes/is open source, I'd be interested to look at it :) On Wed, May 19, 2010 at 11:02, Heath Kehoe wrote: > > On 5/19/2010 12:22 PM, Antoine Toulme wrote: > >> Hey, >> >> what kind of sources were you building ? I'm committer on Buildr and we >> built on Rake as well. Just curious. >> >> Antoine >> > > C++, along with custom data/asset builders > > > -h > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email______________________________________________________________________ > _______________________________________________ > 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 jftucker at gmail.com Wed May 19 14:42:14 2010 From: jftucker at gmail.com (James Tucker) Date: Wed, 19 May 2010 15:42:14 -0300 Subject: [Rake-devel] Comments from a new rake user In-Reply-To: <4BF41C53.5030900@budcat.com> References: <4BF41C53.5030900@budcat.com> Message-ID: <78CC0BAA-3836-463A-92BB-CBCEBF18C36C@gmail.com> On 19 May 2010, at 14:13, Heath Kehoe wrote: > Hello all, > > I have recently implemented a build system based on Rake for a decently-sized project (~8000 source files) which builds code and data for several libraries and applications targeting four separate platforms. > > I was new to both rake and ruby when I started; and it's a testament to the awesomeness of both that I was able to learn them quickly to be able to implement a fairly complicated system in less than a month. > > Anyway, I wanted to pass along some comments. > > Firstly, when I first got stuff building with rake (replacing a build environment that used gnu make) I noticed that a null build (where everything was up to date) took a really long time. I used the ruby profiler and found that approx. half the run time was spent doing file stats (exist? and mtime), with an average of 70 calls *per file* during a rake run. As it runs under Cygwin on Windows those file stat operations are more expensive than they are on Linux. I should note that I'm using ruby 1.8.7 and the rake that gem installed (0.8.7). Yeah, this is a problem for ruby on windows generally, and somewhat hard to overcome in the generic case. > If you look at the FileTask code, the needed? method calls File.exist? then timestamp, which calls File.exist? then File.mtime. That's three stats in a row right there for the file itself; then each prerequisite is asked for its timestamp which generates two stats for each (for FileTasks that is). My approach was to create a simple global cache that uses the filename as the key and stores the file's mtime. > Now, I'm not saying rake should adopt this specific optimization; however I think you should consider some type of caching to reduce the quantity of exist?/mtime calls. Perhaps the FileTask could simply cache its own exist?/mtime results (invalidated when execute runs). It's a bit hacky and incomplete, but here's an intro implementation... class FileTask < Task NOFILESTAT = File::Stat.allocate class << NOFILESTAT def mtime Rake::EARLY end # TODO fixup other methods that are busted by the fact we had to hack # with allocate. end # Is this file task needed? Yes if it doesn't exist, or if its time stamp # is out of date. def needed? stat == NOFILESTAT || out_of_date?(timestamp) end # Time stamp for file task. def timestamp stat.mtime end def execute(*a) super.tap { @stat = nil } end private def stat(refresh = false) return @stat if @stat && !refresh @stat = begin File.stat(name) rescue Errno::ENOENT NOFILESTAT end end ... From hkehoe at budcat.com Wed May 19 15:23:25 2010 From: hkehoe at budcat.com (Heath Kehoe) Date: Wed, 19 May 2010 14:23:25 -0500 Subject: [Rake-devel] Comments from a new rake user In-Reply-To: References: <4BF41C53.5030900@budcat.com> <4BF427C5.2060505@budcat.com> Message-ID: <4BF43AAD.4080300@budcat.com> Not much chance of it ever being open source, but I should be able to share snippets of rake code, especially those that are modified versions of existing rake methods. -h On 5/19/2010 1:06 PM, Antoine Toulme wrote: > Cool, let me know if it becomes/is open source, I'd be interested to > look at it :) > > On Wed, May 19, 2010 at 11:02, Heath Kehoe > wrote: > > > On 5/19/2010 12:22 PM, Antoine Toulme wrote: > > Hey, > > what kind of sources were you building ? I'm committer on > Buildr and we built on Rake as well. Just curious. > > Antoine > > > C++, along with custom data/asset builders > > > -h > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From hkehoe at budcat.com Thu May 20 11:42:34 2010 From: hkehoe at budcat.com (Heath Kehoe) Date: Thu, 20 May 2010 10:42:34 -0500 Subject: [Rake-devel] Comments about parallel building In-Reply-To: <4BF42755.9080900@budcat.com> References: <4BF42755.9080900@budcat.com> Message-ID: <4BF5586A.7030701@budcat.com> On 5/19/2010 1:00 PM, Heath Kehoe wrote: > So we're sticking with ruby 1.8 for now. As I said, perhaps drake's > approach will be better for 1.9, I'll try that out sometime. > > -heath > > I tried drake, and it is promising, since its compute tree model is much more efficient than the MultiTask model I was using, especially in null builds (no creating/joining of thousands of threads). However, it has a bug that prevents me from deploying it in our project; that bug is it sometimes fails to execute tasks during parallel builds. I created a simple test case and filed a bug on the drake rubyforge tracker. -h ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Brian.Hartin at pearson.com Wed May 26 16:42:29 2010 From: Brian.Hartin at pearson.com (Hartin, Brian) Date: Wed, 26 May 2010 15:42:29 -0500 Subject: [Rake-devel] Rake 0.8.7 broken on Windows Message-ID: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> Hi all, In Rake::AltSystem#repair_command, you're now appending "call " to the beginning of the command. This has the effect of losing the working directory. For example, running 'rake test' from the root directory of a project will fail to find its unit tests. It also causes a lot of gem installation failures, as 'gem install' often seems to run rake from the installed gem directory to complete the installation, and fails to find necessary files. This is not backward compatible, obviously. 1 - Is there a workaround? 2 - Why is the 'call' necessary? Is this part of preserving the linux 'sh' semantics you mentioned? If so, how would one avoid this problem in linux? Thanks, Brian Hartin From luislavena at gmail.com Wed May 26 17:15:20 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 26 May 2010 18:15:20 -0300 Subject: [Rake-devel] Rake 0.8.7 broken on Windows In-Reply-To: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> References: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> Message-ID: On Wed, May 26, 2010 at 5:42 PM, Hartin, Brian wrote: > Hi all, > > In Rake::AltSystem#repair_command, you're now appending "call " to the > beginning of the command. ?This has the effect of losing the working > directory. ?For example, running 'rake test' from the root directory of > a project will fail to find its unit tests. ?It also causes a lot of gem > installation failures, as 'gem install' often seems to run rake from the > installed gem directory to complete the installation, and fails to find > necessary files. > Can you give a concrete example? GitHub repo that can be cloned and see this? I've been using Rake 0.8.7 with 1.8.6, 1.8.7 without issues. 1.9.1 has fixed the system invocations and works to for gem installation and everything. Please provide us more information so we can help determine the real root of the issue. Call preserves the parent process path: C:\Users\Luis>cd && cd Desktop && cd && call cmd.exe /c cd && cd .. && cd C:\Users\Luis C:\Users\Luis\Desktop C:\Users\Luis\Desktop C:\Users\Luis That is true for Ruby too. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From Brian.Hartin at pearson.com Wed May 26 18:17:46 2010 From: Brian.Hartin at pearson.com (Hartin, Brian) Date: Wed, 26 May 2010 17:17:46 -0500 Subject: [Rake-devel] Rake 0.8.7 broken on Windows In-Reply-To: References: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> Message-ID: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCAA3@usiowacncspmx01.NCSP.PEROOT.COM> Luis, I have created three one-line ruby scripts to demonstrate the issue with 'call'. Please note the directory locations: c:\temp\print_working_directory.rb: puts "Working directory is #{Dir.pwd}" c:\temp\invoke_ruby.rb Kernel.system('c:\ruby\bin\ruby.exe c:\temp\print_working_directory.rb') c:\temp\invoke_ruby_using_call.rb Kernel.system('call c:\ruby\bin\ruby.exe c:\temp\print_working_directory.rb') Next, I opened a command window and executed the following commands: c:\>cd c:\temp c:\temp>ruby invoke_ruby.rb (prints "Working directory is C:/temp") c:\temp>ruby invoke_ruby_using_call.rb (prints "Working directory is C:/Documents and Settings/hartbr") When I run 'rake test' from my project directory (C:\workspaces\project), I see the same thing. To demonstrate, here's what you need to do: 1) gem install rake 0.7.3 2) Modify rake_test_loader.rb to print the working directory. 3) Run 'rake:test' from the root directory of any Rails project. You should see that the forked ruby process runs the tests from that directory. 4) Uninstall rake 0.7.3 (Just for clarity's sake) 5) Install rake 0.8.7 6) Repeat step 2 7) Repeat step 3, and I think it will fail to find the unit tests. I traced things from the Rails rake tasks all the way to alt_system.rb, and this doesn't seem to be a Rails issue. Rails correctly assembles the file list, consisting of relative paths like "test/unit/foo_test.rb". The directory issue causes Rake 0.8.7 to fail with a "No such file to load" error. I did a fresh install of Ruby today, to make sure my Ruby installation wasn't part of the problem. Thanks, Brian > -----Original Message----- > From: rake-devel-bounces at rubyforge.org > [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Luis Lavena > Sent: Wednesday, May 26, 2010 4:15 PM > To: Rake Development and Discussion > Subject: Re: [Rake-devel] Rake 0.8.7 broken on Windows > > On Wed, May 26, 2010 at 5:42 PM, Hartin, Brian > wrote: > > Hi all, > > > > In Rake::AltSystem#repair_command, you're now appending > "call " to the > > beginning of the command. ?This has the effect of losing the working > > directory. ?For example, running 'rake test' from the root > directory of > > a project will fail to find its unit tests. ?It also causes > a lot of gem > > installation failures, as 'gem install' often seems to run > rake from the > > installed gem directory to complete the installation, and > fails to find > > necessary files. > > > > Can you give a concrete example? GitHub repo that can be > cloned and see this? > > I've been using Rake 0.8.7 with 1.8.6, 1.8.7 without issues. 1.9.1 has > fixed the system invocations and works to for gem installation and > everything. > > Please provide us more information so we can help determine the real > root of the issue. > > Call preserves the parent process path: > > C:\Users\Luis>cd && cd Desktop && cd && call cmd.exe /c cd && > cd .. && cd > C:\Users\Luis > C:\Users\Luis\Desktop > C:\Users\Luis\Desktop > C:\Users\Luis > > That is true for Ruby too. > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing > more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exup?ry > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel > From luislavena at gmail.com Wed May 26 18:42:47 2010 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 26 May 2010 19:42:47 -0300 Subject: [Rake-devel] Rake 0.8.7 broken on Windows In-Reply-To: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCAA3@usiowacncspmx01.NCSP.PEROOT.COM> References: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCAA3@usiowacncspmx01.NCSP.PEROOT.COM> Message-ID: On Wed, May 26, 2010 at 7:17 PM, Hartin, Brian wrote: > Luis, > > I have created three one-line ruby scripts to demonstrate the issue with 'call'. ?Please note the directory locations: > > c:\temp\print_working_directory.rb: > > ? ? ? ?puts "Working directory is #{Dir.pwd}" > > c:\temp\invoke_ruby.rb > > ? ? ? ?Kernel.system('c:\ruby\bin\ruby.exe c:\temp\print_working_directory.rb') > > c:\temp\invoke_ruby_using_call.rb > > ? ? ? ?Kernel.system('call c:\ruby\bin\ruby.exe c:\temp\print_working_directory.rb') > > Next, I opened a command window and executed the following commands: > > ? ? ? ?c:\>cd c:\temp > ? ? ? ?c:\temp>ruby invoke_ruby.rb (prints "Working directory is C:/temp") > ? ? ? ?c:\temp>ruby invoke_ruby_using_call.rb (prints "Working directory is C:/Documents and Settings/hartbr") > > > When I run 'rake test' from my project directory (C:\workspaces\project), I see the same thing. ?To demonstrate, here's what you need to do: > > 1) gem install rake 0.7.3 > 2) Modify rake_test_loader.rb to print the working directory. > 3) Run 'rake:test' from the root directory of any Rails project. ?You should see that the forked ruby process runs the tests from that directory. > 4) Uninstall rake 0.7.3 (Just for clarity's sake) > 5) Install rake 0.8.7 > 6) Repeat step 2 > 7) Repeat step 3, and I think it will fail to find the unit tests. > > I traced things from the Rails rake tasks all the way to alt_system.rb, and this doesn't seem to be a Rails issue. ?Rails correctly assembles the file list, consisting of relative paths like "test/unit/foo_test.rb". ?The directory issue causes Rake 0.8.7 to fail with a "No such file to load" error. > > I did a fresh install of Ruby today, to make sure my Ruby installation wasn't part of the problem. > The only one reporting me "No such file to load" is Ruby 1.9.2 that do not add "." to the $LOAD_PATH Invoking "rake test" or "rake spec" in any project I've used takes the directory where Rakefile is found and executed. That had worked and still works for me. There was several back and forth on alt_system issues because Ruby 1.8.x is flawed to handle system calls. "call" was required to handle *args calls to system. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From Brian.Hartin at pearson.com Thu May 27 13:39:26 2010 From: Brian.Hartin at pearson.com (Hartin, Brian) Date: Thu, 27 May 2010 12:39:26 -0500 Subject: [Rake-devel] Rake 0.8.7 broken on Windows In-Reply-To: References: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCA9F@usiowacncspmx01.NCSP.PEROOT.COM> <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCAA3@usiowacncspmx01.NCSP.PEROOT.COM> Message-ID: <0A6FA8174BFD3F4EA8D209C7E6C87CBDFFCAA9@usiowacncspmx01.NCSP.PEROOT.COM> Luis, Thanks for your help. There does indeed seem to be something wrong on my end. Kernel.system('call ...') executes in a different directory than Kernel.system('...'), but for my co-worker, it does not. We have the exact same version of ruby, too. Brian > -----Original Message----- > From: rake-devel-bounces at rubyforge.org > [mailto:rake-devel-bounces at rubyforge.org] On Behalf Of Luis Lavena > Sent: Wednesday, May 26, 2010 5:43 PM > To: Rake Development and Discussion > Subject: Re: [Rake-devel] Rake 0.8.7 broken on Windows > > On Wed, May 26, 2010 at 7:17 PM, Hartin, Brian > wrote: > > Luis, > > > > I have created three one-line ruby scripts to demonstrate > the issue with 'call'. ?Please note the directory locations: > > > > c:\temp\print_working_directory.rb: > > > > ? ? ? ?puts "Working directory is #{Dir.pwd}" > > > > c:\temp\invoke_ruby.rb > > > > ? ? ? ?Kernel.system('c:\ruby\bin\ruby.exe > c:\temp\print_working_directory.rb') > > > > c:\temp\invoke_ruby_using_call.rb > > > > ? ? ? ?Kernel.system('call c:\ruby\bin\ruby.exe > c:\temp\print_working_directory.rb') > > > > Next, I opened a command window and executed the following commands: > > > > ? ? ? ?c:\>cd c:\temp > > ? ? ? ?c:\temp>ruby invoke_ruby.rb (prints "Working > directory is C:/temp") > > ? ? ? ?c:\temp>ruby invoke_ruby_using_call.rb (prints > "Working directory is C:/Documents and Settings/hartbr") > > > > > > When I run 'rake test' from my project directory > (C:\workspaces\project), I see the same thing. ?To > demonstrate, here's what you need to do: > > > > 1) gem install rake 0.7.3 > > 2) Modify rake_test_loader.rb to print the working directory. > > 3) Run 'rake:test' from the root directory of any Rails > project. ?You should see that the forked ruby process runs > the tests from that directory. > > 4) Uninstall rake 0.7.3 (Just for clarity's sake) > > 5) Install rake 0.8.7 > > 6) Repeat step 2 > > 7) Repeat step 3, and I think it will fail to find the unit tests. > > > > I traced things from the Rails rake tasks all the way to > alt_system.rb, and this doesn't seem to be a Rails issue. ? > Rails correctly assembles the file list, consisting of > relative paths like "test/unit/foo_test.rb". ?The directory > issue causes Rake 0.8.7 to fail with a "No such file to load" error. > > > > I did a fresh install of Ruby today, to make sure my Ruby > installation wasn't part of the problem. > > > > The only one reporting me "No such file to load" is Ruby 1.9.2 that do > not add "." to the $LOAD_PATH > > Invoking "rake test" or "rake spec" in any project I've used takes the > directory where Rakefile is found and executed. > > That had worked and still works for me. > > There was several back and forth on alt_system issues because Ruby > 1.8.x is flawed to handle system calls. "call" was required to handle > *args calls to system. > > -- > Luis Lavena > AREA 17 > - > Perfection in design is achieved not when there is nothing > more to add, > but rather when there is nothing more to take away. > Antoine de Saint-Exup?ry > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel >