From jim.weirich at gmail.com Sun Nov 11 03:25:34 2012 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 10 Nov 2012 22:25:34 -0500 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 Message-ID: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. -- -- Jim Weirich -- jim.weirich at gmail.com From luislavena at gmail.com Sun Nov 11 03:26:51 2012 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 11 Nov 2012 00:26:51 -0300 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 In-Reply-To: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> References: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 12:25 AM, Jim Weirich wrote: > I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. > I was just about to run tests against Ruby 1.9.3, 2.0.0 on Windows, on both x86 and x64 configurations. Will send the results in a bit. -- 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 luislavena at gmail.com Sun Nov 11 03:49:55 2012 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 11 Nov 2012 00:49:55 -0300 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 In-Reply-To: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> References: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 12:25 AM, Jim Weirich wrote: > I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. > Hello Jim, Can you confirm which branch is each of the versions? Is not clear to me which one represents version 0.9.3 (guess next-major-release is 10.0.0) Please confirm so I can provide you test results. Thank you. -- 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 luislavena at gmail.com Sun Nov 11 04:34:47 2012 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 11 Nov 2012 01:34:47 -0300 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 In-Reply-To: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> References: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> Message-ID: On Sun, Nov 11, 2012 at 12:25 AM, Jim Weirich wrote: > I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. > The following patches fix 1 failure and one noisy output during tests: https://gist.github.com/4053715 The noisy output should be using the "skip" instead, so I've changed it. This happens on both master and next-major-release branches. With patches applied: next-major-release (10.0.0) ruby 1.9.3p327 (2012-11-10) [i386-mingw32] 455 tests, 1298 assertions, 0 failures, 0 errors, 1 skips ruby 2.0.0dev (2012-11-10 trunk 37612) [i386-mingw32] 455 tests, 1298 assertions, 0 failures, 0 errors, 1 skips ruby 2.0.0dev (2012-11-10 trunk 37612) [x64-mingw32] 455 tests, 1298 assertions, 0 failures, 0 errors, 1 skips master (0.9.3): ruby 1.9.3p327 (2012-11-10) [i386-mingw32] 474 tests, 1389 assertions, 0 failures, 0 errors, 1 skips ruby 2.0.0dev (2012-11-10 trunk 37612) [i386-mingw32] 474 tests, 1389 assertions, 0 failures, 0 errors, 1 skips ruby 2.0.0dev (2012-11-10 trunk 37612) [x64-mingw32] 474 tests, 1389 assertions, 0 failures, 0 errors, 1 skips Shouldn't 10.0.0 have more tests than 0.9.3? Either way, let me know if you prefer a pull request to fix the bogus failures. Thank you. -- 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 jim.weirich at gmail.com Sun Nov 11 04:48:05 2012 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 10 Nov 2012 23:48:05 -0500 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 In-Reply-To: References: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> Message-ID: On Nov 10, 2012, at 10:49 PM, Luis Lavena wrote: > On Sun, Nov 11, 2012 at 12:25 AM, Jim Weirich wrote: >> I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. >> > > Hello Jim, > > Can you confirm which branch is each of the versions? > > Is not clear to me which one represents version 0.9.3 (guess > next-major-release is 10.0.0) 0.9.3 is master 10.0.0 is next-major-release After the release I will promote master to 10.0.x -- -- Jim Weirich -- jim.weirich at gmail.com From jim.weirich at gmail.com Sun Nov 11 04:48:37 2012 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 10 Nov 2012 23:48:37 -0500 Subject: [Rake-devel] Planning on Releasing on Monday: Rake 0.9.3 and 10.0.0 In-Reply-To: References: <1E1C8537-E754-4486-819A-35DEB0F32717@gmail.com> Message-ID: <921E7BF0-DB76-46ED-8458-68246065EF96@gmail.com> On Nov 10, 2012, at 11:34 PM, Luis Lavena wrote: > On Sun, Nov 11, 2012 at 12:25 AM, Jim Weirich wrote: >> I'm planning on publishing Rake 0.9.3 and 10.0.0 on Monday, so's here's the last chance on reporting any bugs in either of those versions. >> > > The following patches fix 1 failure and one noisy output during tests: Thanks for the patch! -- -- Jim Weirich -- jim.weirich at gmail.com From mbishop at me.com Wed Nov 21 03:36:09 2012 From: mbishop at me.com (Michael Bishop) Date: Tue, 20 Nov 2012 22:36:09 -0500 Subject: [Rake-devel] Why do MultiTask and Task send different args to their prerequisites? Message-ID: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> Hello everyone, I've been looking at something that has been confusing me for a while. It appears that MultiTask and Task send different arguments to their prerequisites and I can't figure out the reason why. I'm hoping someone on the list will know right away. I've looked and the code for each case and expanded it and they are basically identical except for this last remaining functional difference between the two: TASK @prerequisites.collect { |p| prereq = lookup_prerequisite(p) # returns a task prereq_args = args.new_scope(prereq.arg_names) prereq.invoke_with_call_chain(prereq_args, invocation_chain) } MULTITASK @prerequisites.collect do |p| prereq = lookup_prerequisite(p) # returns a task prereq.invoke_with_call_chain(args, invocation_chain) end Why the extra prereq_args = args.new_scope(prereq.arg_names) in the TASK case? How does its absence affect MultiTask argument processing? Shouldn't they be the same? Any ideas? Thank you, _ michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.weirich at gmail.com Wed Nov 21 17:08:28 2012 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 22 Nov 2012 04:08:28 +1100 Subject: [Rake-devel] Why do MultiTask and Task send different args to their prerequisites? In-Reply-To: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> References: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> Message-ID: <90073DA1-1AA8-4AF7-85D4-0FC0AC34B2B3@gmail.com> On Nov 21, 2012, at 2:36 PM, Michael Bishop wrote: > Hello everyone, > > I've been looking at something that has been confusing me for a while. It appears that MultiTask and Task send different arguments to their prerequisites and I can't figure out the reason why. I'm hoping someone on the list will know right away. > > I've looked and the code for each case and expanded it and they are basically identical except for this last remaining functional difference between the two: > > TASK > > @prerequisites.collect { |p| > prereq = lookup_prerequisite(p) # returns a task > prereq_args = args.new_scope(prereq.arg_names) > prereq.invoke_with_call_chain(prereq_args, invocation_chain) > } > > MULTITASK > > @prerequisites.collect do |p| > prereq = lookup_prerequisite(p) # returns a task > prereq.invoke_with_call_chain(args, invocation_chain) > end > > > Why the extra > > prereq_args = args.new_scope(prereq.arg_names) > > in the TASK case? How does its absence affect MultiTask argument processing? Shouldn't they be the same? I have no memory of why task has it and multitask doesn't. I'll have to research this and refresh my memory on the whole task arguments implementation before being able to answer. Stubbing out new_scope to just return the original arguments does cause a test to fail, so evidently its good for something. I suspect that multitask just didn't get updated when the new_scope was introduced. -- -- Jim Weirich -- jim.weirich at gmail.com From mbishop at me.com Wed Nov 21 17:33:49 2012 From: mbishop at me.com (Michael Bishop) Date: Wed, 21 Nov 2012 12:33:49 -0500 Subject: [Rake-devel] Why do MultiTask and Task send different args to their prerequisites? In-Reply-To: <90073DA1-1AA8-4AF7-85D4-0FC0AC34B2B3@gmail.com> References: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> <90073DA1-1AA8-4AF7-85D4-0FC0AC34B2B3@gmail.com> Message-ID: <7E7A95D8-15A1-4846-8957-0E2C5F89561D@me.com> I made a patch in my branch to make these the same. The test-suite runs to completion, but I'm still wary of it since I don't know if there are good reasons for them to be different :) https://github.com/michaeljbishop/rake/commit/ca283160b610c95e1f28cf561af8811fd37d10c3 _ michael On Nov 21, 2012, at 12:08 PM, Jim Weirich wrote: > > On Nov 21, 2012, at 2:36 PM, Michael Bishop wrote: > >> Hello everyone, >> >> I've been looking at something that has been confusing me for a while. It appears that MultiTask and Task send different arguments to their prerequisites and I can't figure out the reason why. I'm hoping someone on the list will know right away. >> >> I've looked and the code for each case and expanded it and they are basically identical except for this last remaining functional difference between the two: >> >> TASK >> >> @prerequisites.collect { |p| >> prereq = lookup_prerequisite(p) # returns a task >> prereq_args = args.new_scope(prereq.arg_names) >> prereq.invoke_with_call_chain(prereq_args, invocation_chain) >> } >> >> MULTITASK >> >> @prerequisites.collect do |p| >> prereq = lookup_prerequisite(p) # returns a task >> prereq.invoke_with_call_chain(args, invocation_chain) >> end >> >> >> Why the extra >> >> prereq_args = args.new_scope(prereq.arg_names) >> >> in the TASK case? How does its absence affect MultiTask argument processing? Shouldn't they be the same? > > I have no memory of why task has it and multitask doesn't. I'll have to research this and refresh my memory on the whole task arguments implementation before being able to answer. > > Stubbing out new_scope to just return the original arguments does cause a test to fail, so evidently its good for something. I suspect that multitask just didn't get updated when the new_scope was introduced. > > -- > -- 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 Nov 21 17:58:40 2012 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 22 Nov 2012 04:58:40 +1100 Subject: [Rake-devel] Why do MultiTask and Task send different args to their prerequisites? In-Reply-To: <7E7A95D8-15A1-4846-8957-0E2C5F89561D@me.com> References: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> <90073DA1-1AA8-4AF7-85D4-0FC0AC34B2B3@gmail.com> <7E7A95D8-15A1-4846-8957-0E2C5F89561D@me.com> Message-ID: On Nov 22, 2012, at 4:33 AM, Michael Bishop wrote: > I made a patch in my branch to make these the same. The test-suite runs to completion, but I'm still wary of it since I don't know if there are good reasons for them to be different :) > > https://github.com/michaeljbishop/rake/commit/ca283160b610c95e1f28cf561af8811fd37d10c3= I like the commit. It makes the concurrent path look much more like the non-concurrent one. The new_scope is making a task argument object that is tailored for each task. For example: if task a with args x and y call prerequisite b with argument x, then task a gets an argument list with "x" and "y" in it and task b gets an argument list with just "x" (and initialized to the value of the the "x" from task a). The weird thing is that trying to lookup y will still work because of the parent link in the task args. I'm not sure I like the parent link idea, but that's another issue for another time. So yes, the multitask path should also invoke new_scope. If you make this a pull request, I'll merge it. -- -- Jim Weirich -- jim.weirich at gmail.com From mbishop at me.com Wed Nov 21 18:18:31 2012 From: mbishop at me.com (Michael Bishop) Date: Wed, 21 Nov 2012 13:18:31 -0500 Subject: [Rake-devel] Why do MultiTask and Task send different args to their prerequisites? In-Reply-To: References: <35444603-AD2A-4E9D-8454-DC858BA60F01@me.com> <90073DA1-1AA8-4AF7-85D4-0FC0AC34B2B3@gmail.com> <7E7A95D8-15A1-4846-8957-0E2C5F89561D@me.com> Message-ID: Done. Thanks for the explanation of the code. _ michael On Nov 21, 2012, at 12:58 PM, Jim Weirich wrote: > > On Nov 22, 2012, at 4:33 AM, Michael Bishop wrote: > >> I made a patch in my branch to make these the same. The test-suite runs to completion, but I'm still wary of it since I don't know if there are good reasons for them to be different :) >> >> https://github.com/michaeljbishop/rake/commit/ca283160b610c95e1f28cf561af8811fd37d10c3= > > I like the commit. It makes the concurrent path look much more like the non-concurrent one. > > The new_scope is making a task argument object that is tailored for each task. For example: if task a with args x and y call prerequisite b with argument x, then task a gets an argument list with "x" and "y" in it and task b gets an argument list with just "x" (and initialized to the value of the the "x" from task a). > > The weird thing is that trying to lookup y will still work because of the parent link in the task args. I'm not sure I like the parent link idea, but that's another issue for another time. > > So yes, the multitask path should also invoke new_scope. > > If you make this a pull request, I'll merge it. > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > > > > > _______________________________________________ > Rake-devel mailing list > Rake-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rake-devel