From alexch at gmail.com Sun Apr 6 15:14:39 2008 From: alexch at gmail.com (Alex Chaffee) Date: Sun, 6 Apr 2008 12:14:39 -0700 Subject: [Rake-devel] truncated task descriptions Message-ID: <7a93bd340804061214y520601a5kf893ef6efaa3749b@mail.gmail.com> > I understand the rationale behind the truncation of task > descriptions in 'rake -T' but I find the 80 column limit a little too > condensed for my personal tastes. I whipped up a rake task that > displays tasks and allows me to specify my column limit with an > environment variable. Wouldn't it be better to default to the width of the current window? After looking at Reference [1] I believe that the easiest way to figure this out is to check if you're on a unix system, and if so, call "stty size" and parse the result. Here's some code that demonstrates how. I haven't made a test yet since I haven't quite figured out how to mock out RUBY_PLATFORM or %x for a unit test... And I haven't tested it on many platforms but the code is defensive enough that it should gracefully and silently fail back to "80" on Windows etc. References: [1] http://codeidol.com/other/rubyckbk/User-Interface/Determining-Terminal-Size/ [2] http://www.tua.ch/ruby/platform/platform.html [3] http://rubyforge.org/frs/download.php/7486/platform_0_4.rb [4] http://geminstaller.rubyforge.org/svn/trunk/spec/fixture/rubygems_dist/rubygems-1.1.0/lib/rubygems/platform.rb Code (a patch against 0.8.1): Index: lib/rake.rb =================================================================== --- lib/rake.rb (revision 639) +++ lib/rake.rb (working copy) @@ -2010,14 +2010,24 @@ end else width = displayable_tasks.collect { |t| t.name_with_args.length }.max || 10 - max_column = 80 - name.size - width - 7 + max_column = cols - name.size - width - 7 displayable_tasks.each do |t| printf "#{name} %-#{width}s # %s\n", t.name_with_args, truncate(t.comment, max_column) end end end + + def cols + unix? ? (%x{stty size 2>/dev/null}.split.collect { |x| x.to_i }[1]) : 80 + rescue + 80 + end + def unix? + RUBY_PLATFORM =~ /(aix|darwin|linux|(net|free|open)bsd|cygwin|solaris|irix|hpux|)/i + end + def truncate(string, width) if string.length <= width string -- Alex Chaffee - Pivotal Labs alex at PivotalLabs.com From alexch at gmail.com Sun Apr 6 15:21:04 2008 From: alexch at gmail.com (Alex Chaffee) Date: Sun, 6 Apr 2008 12:21:04 -0700 Subject: [Rake-devel] truncated task descriptions In-Reply-To: <7a93bd340804061214y520601a5kf893ef6efaa3749b@mail.gmail.com> References: <7a93bd340804061214y520601a5kf893ef6efaa3749b@mail.gmail.com> Message-ID: <7a93bd340804061221y75a8355ftc5bcb55d6cc3c66d@mail.gmail.com> Here's the patch as a pastie file, since formatting tends to get messed up in email: http://pastie.org/pastes/176151 http://pastie.org/pastes/176151/download - A From edpratomo at yahoo.co.id Wed Apr 9 09:36:00 2008 From: edpratomo at yahoo.co.id (Edwin Pratomo) Date: Wed, 9 Apr 2008 20:36:00 +0700 (ICT) Subject: [Rake-devel] small patch for rake.rb Message-ID: <699534.29199.qm@web58309.mail.re3.yahoo.com> good day all just a small patch. FileUtils::OPT_TABLE in ruby-1.8.6 uses symbols instead of strings. rgds, Edwin. ________________________________________________________ Bergabunglah dengan orang-orang yang berwawasan, di di bidang Anda! Kunjungi Yahoo! Answers saat ini juga di http://id.answers.yahoo.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: rake.rb.patch Type: application/octet-stream Size: 553 bytes Desc: 1373203373-rake.rb.patch Url : http://rubyforge.org/pipermail/rake-devel/attachments/20080409/1127b49f/attachment.obj From jim.weirich at gmail.com Fri Apr 11 20:41:49 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 11 Apr 2008 20:41:49 -0400 Subject: [Rake-devel] Next rake gem release In-Reply-To: <5345B01F-57FB-40AA-A0C3-B9C37CEFEE18@gmail.com> References: <5345B01F-57FB-40AA-A0C3-B9C37CEFEE18@gmail.com> Message-ID: On Mar 27, 2008, at 5:41 AM, Adam Salter wrote: > Jim, > Just wondering if there will be another rake release anytime soon? > I sent a patch to the task args handling, and would like to be able to > use in my publicly available projects... I'm considering a release soon, so go ahead and send your patch. -- -- Jim Weirich -- jim.weirich at gmail.com From dsisnero at gmail.com Fri Apr 11 21:10:53 2008 From: dsisnero at gmail.com (Dominic Sisneros) Date: Fri, 11 Apr 2008 19:10:53 -0600 Subject: [Rake-devel] buildr tasks Message-ID: I was looking at buildr (http://github.com/vic/buildr/tree/master the other day which is a build system using rake and they have a lot of descendants of the FileTask that seem pretty useful. I am willing to see if they would be willing to contribute some of that back to rake if you're interested. dom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rake-devel/attachments/20080411/c3359b62/attachment.html From jim.weirich at gmail.com Fri Apr 11 21:22:12 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 11 Apr 2008 21:22:12 -0400 Subject: [Rake-devel] buildr tasks In-Reply-To: References: Message-ID: <2FF10D05-5C41-48DF-A2A0-1DCCC4EACC5E@gmail.com> On Apr 11, 2008, at 9:10 PM, Dominic Sisneros wrote: > I was looking at buildr (http://github.com/vic/buildr/tree/master > the other day which is a build system using rake and they have a lot > of descendants of the FileTask that > seem pretty useful. I am willing to see if they would be willing to > contribute some of that back to rake if you're interested. If they are generally useful, I would be willing to add them to rake. -- -- Jim Weirich -- jim.weirich at gmail.com From assaf at labnotes.org Fri Apr 11 21:45:23 2008 From: assaf at labnotes.org (Assaf Arkin) Date: Fri, 11 Apr 2008 18:45:23 -0700 Subject: [Rake-devel] buildr tasks In-Reply-To: References: Message-ID: <5037b6e40804111845w244ceaaav6641755e9eec9d9b@mail.gmail.com> On Fri, Apr 11, 2008 at 6:10 PM, Dominic Sisneros wrote: > I was looking at buildr (http://github.com/vic/buildr/tree/master the other > day which is a build system using rake and they have a lot of descendants of > the FileTask that > seem pretty useful. I am willing to see if they would be willing to > contribute some of that back to rake if you're interested. > > dom The sources are distributed under the Apache license, so if you don't mind mixing licenses, and the ASL is very liberal, go right ahead. There are a few things for which I was the sole contributor, I can make those available under the MIT license. Assaf -- http://labnotes.org From jim.weirich at gmail.com Sat Apr 12 08:49:17 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Sat, 12 Apr 2008 08:49:17 -0400 Subject: [Rake-devel] Next rake gem release In-Reply-To: <7a93bd340804112119k1f19f7dbl1b83d84cef236413@mail.gmail.com> References: <5345B01F-57FB-40AA-A0C3-B9C37CEFEE18@gmail.com> <7a93bd340804112119k1f19f7dbl1b83d84cef236413@mail.gmail.com> Message-ID: <37BB3442-6B55-48CE-AF33-C8863611189C@gmail.com> On Apr 12, 2008, at 12:19 AM, Alex Chaffee wrote: > Did you get my patch for the dynamic line endings? I didn't see a > reply from you on the list. Yes, I got the email. Thanks for the feedback. I'm definitely going to do something about the line length (there's been enough negative feedback on that choice). At the very least it will be sensitive to an environment variable. I'm trying to decide on whether or not to include the 'stty size' trick or not. The platform checks seem to me to be fragile. I'm thinking of checking for terminal width in this order: (1) Explicit environment variable (2) stty size output (3) assume 80 characters Open questions: (a) Should I bother with the stty check, given that's it is fragile and won't work on a significant number of platforms? (b) Would it be better to assume infinite width rather than 80? -- -- Jim Weirich -- jim.weirich at gmail.com From alexch at gmail.com Sat Apr 12 12:17:34 2008 From: alexch at gmail.com (Alex Chaffee) Date: Sat, 12 Apr 2008 09:17:34 -0700 Subject: [Rake-devel] Next rake gem release In-Reply-To: <37BB3442-6B55-48CE-AF33-C8863611189C@gmail.com> References: <5345B01F-57FB-40AA-A0C3-B9C37CEFEE18@gmail.com> <7a93bd340804112119k1f19f7dbl1b83d84cef236413@mail.gmail.com> <37BB3442-6B55-48CE-AF33-C8863611189C@gmail.com> Message-ID: <7a93bd340804120917w74d1eecbgbfc0b6fdde475974@mail.gmail.com> The platform checks are indeed fragile, but that's why the code is defensive, and degrades gracefully. And an environment variable will just substitute one brittle width (80) with another, so I'll never use it (since I am constantly fiddling with the size of my terminal windows), but if someone else finds it useful, then it should be checked for first. So I agree with your 1-2-3 list, and I think the default should not be infinite; if people want to see the whole list they can use -D, but if they use -T it's because they want to see one task per line for easy visual scanning. IMHO :-) - A On Sat, Apr 12, 2008 at 5:49 AM, Jim Weirich wrote: > > On Apr 12, 2008, at 12:19 AM, Alex Chaffee wrote: > > > Did you get my patch for the dynamic line endings? I didn't see a > > reply from you on the list. > > > > Yes, I got the email. Thanks for the feedback. I'm definitely going to do > something about the line length (there's been enough negative feedback on > that choice). At the very least it will be sensitive to an environment > variable. I'm trying to decide on whether or not to include the 'stty size' > trick or not. The platform checks seem to me to be fragile. > > I'm thinking of checking for terminal width in this order: > > (1) Explicit environment variable > (2) stty size output > (3) assume 80 characters > > Open questions: > > (a) Should I bother with the stty check, given that's it is fragile and > won't work on a significant number of platforms? > (b) Would it be better to assume infinite width rather than 80? > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > -- Alex Chaffee - Pivotal Labs alex at PivotalLabs.com From jamesmead44 at gmail.com Thu Apr 17 13:38:29 2008 From: jamesmead44 at gmail.com (James Mead) Date: Thu, 17 Apr 2008 18:38:29 +0100 Subject: [Rake-devel] Hooking into rake test tasks Message-ID: <1db558f00804171038r5a84c021q3a4bb23a11394fc7@mail.gmail.com> I'm sure there's probably a better way of doing this, but I've just hacked together a simple patch for Rake which allows the following syntax... Rake::TestTask.new(:units => "db:test:prepare") do |t| t.libs << "test" t.pattern = 'test/unit/**/*_test.rb' t.verbose = true t.on_result = lambda do |ok, status| # do stuff here end end The new bit is the "on_result" bit which allow you to specify a Proc to be executed when the Ruby process executing the tests completes. The ok & status parameters allow you to determine whether or not the tests have all passed or not. The patch makes use of the fact that FileUtils#ruby and FileUtils#sh allow you to pass in a block to be executed after the command runs. Would you be interested in the patch? If yes, is there somewhere to submit it - the normal Tracker stuff on Rubyforge doesn't seem to be enabled for Rake. Or can someone tell me a better way? Thanks. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rake-devel/attachments/20080417/cd96e309/attachment.html From jim.weirich at gmail.com Thu Apr 17 13:46:58 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 17 Apr 2008 13:46:58 -0400 Subject: [Rake-devel] Hooking into rake test tasks In-Reply-To: <1db558f00804171038r5a84c021q3a4bb23a11394fc7@mail.gmail.com> References: <1db558f00804171038r5a84c021q3a4bb23a11394fc7@mail.gmail.com> Message-ID: <421B60CF-087C-45C7-AF61-A7DBD9D523D7@gmail.com> On Apr 17, 2008, at 1:38 PM, James Mead wrote: > I'm sure there's probably a better way of doing this, but I've just > hacked together a simple patch for Rake which allows the following > syntax... [...] > > Would you be interested in the patch? If yes, is there somewhere to > submit it - the normal Tracker stuff on Rubyforge doesn't seem to be > enabled for Rake. Sounds interesting. Yes, I'm interested. Just mail it here. I'm investigating some tracking software for Rake, but don't have anything in place yet. -- -- Jim Weirich -- jim.weirich at gmail.com From jamesmead44 at gmail.com Thu Apr 17 15:04:00 2008 From: jamesmead44 at gmail.com (James Mead) Date: Thu, 17 Apr 2008 20:04:00 +0100 Subject: [Rake-devel] Hooking into rake test tasks In-Reply-To: <421B60CF-087C-45C7-AF61-A7DBD9D523D7@gmail.com> References: <1db558f00804171038r5a84c021q3a4bb23a11394fc7@mail.gmail.com> <421B60CF-087C-45C7-AF61-A7DBD9D523D7@gmail.com> Message-ID: <1db558f00804171204k534298fr3bcc10b4bf917dd1@mail.gmail.com> Great. Here it is - I hope Mailman doesn't strip off the attachment. I'm sorry I couldn't work out how to write a suitable test. On 17/04/2008, Jim Weirich wrote: > > Sounds interesting. Yes, I'm interested. Just mail it here. I'm > investigating some tracking software for Rake, but don't have anything > in place yet. > Thanks. -- James. http://blog.floehopper.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rake-devel/attachments/20080417/52ec9835/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: rake-test-task-on-result-block.patch Type: application/octet-stream Size: 1335 bytes Desc: not available Url : http://rubyforge.org/pipermail/rake-devel/attachments/20080417/52ec9835/attachment.obj From Frank at vanViegen.net Wed Apr 23 09:01:05 2008 From: Frank at vanViegen.net (Frank van Viegen) Date: Wed, 23 Apr 2008 15:01:05 +0200 Subject: [Rake-devel] patch: fail stack In-Reply-To: <94d1df920804230540p33d95765k2ac6e9fb99185ede@mail.gmail.com> References: <94d1df920804230540p33d95765k2ac6e9fb99185ede@mail.gmail.com> Message-ID: <94d1df920804230601v296fee17xe1544b730c31f31b@mail.gmail.com> Small patch that extends the 'fail' method to show the task stack at the moment of the error. It has helped me a lot when debugging complicated rakefiles. -------------- next part -------------- A non-text attachment was scrubbed... Name: rake_fail_stack.diff Type: text/x-patch Size: 843 bytes Desc: not available Url : http://rubyforge.org/pipermail/rake-devel/attachments/20080423/25b71890/attachment.bin From Frank at vanViegen.net Wed Apr 23 09:01:51 2008 From: Frank at vanViegen.net (Frank van Viegen) Date: Wed, 23 Apr 2008 15:01:51 +0200 Subject: [Rake-devel] patch: lazy proc deps In-Reply-To: <94d1df920804230552u2a4e6022m9bfacbe57e286938@mail.gmail.com> References: <94d1df920804230552u2a4e6022m9bfacbe57e286938@mail.gmail.com> Message-ID: <94d1df920804230601o5778011fs23e0f2c97af68d9a@mail.gmail.com> This patch allows tasks to have Proc objects among their dependencies. The Proc is executed on demand; it's return value is interpreted as a list of files to be added to the dependy list. This functionality can save a lot of execution time when using many (automatically generated) file tasks that have slow dependency discovery methods. The alternative, creating a rule for each of them, gets pretty slow when defining more than a few hundred of them, as they need to be regexp matched. -------------- next part -------------- A non-text attachment was scrubbed... Name: rake_lazy_proc_deps.diff Type: text/x-patch Size: 1665 bytes Desc: not available Url : http://rubyforge.org/pipermail/rake-devel/attachments/20080423/0b8e6448/attachment.bin From jim.weirich at gmail.com Wed Apr 23 09:32:58 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Wed, 23 Apr 2008 09:32:58 -0400 Subject: [Rake-devel] patch: lazy proc deps In-Reply-To: <94d1df920804230601o5778011fs23e0f2c97af68d9a@mail.gmail.com> References: <94d1df920804230552u2a4e6022m9bfacbe57e286938@mail.gmail.com> <94d1df920804230601o5778011fs23e0f2c97af68d9a@mail.gmail.com> Message-ID: On Apr 23, 2008, at 9:01 AM, Frank van Viegen wrote: > This patch allows tasks to have Proc objects among their dependencies. > The Proc is executed on demand; it's return value is interpreted as a > list of files to be added to the dependy list. Thanks for the two patches. Do you have any unit tests to go along with these? -- -- Jim Weirich -- jim.weirich at gmail.com From Frank at vanViegen.net Wed Apr 23 10:42:12 2008 From: Frank at vanViegen.net (Frank van Viegen) Date: Wed, 23 Apr 2008 16:42:12 +0200 Subject: [Rake-devel] patch: lazy proc deps Message-ID: <94d1df920804230742n7d4069b0t349a466574a49341@mail.gmail.com> On Apr 23, 2008, at 9:33 AM, Jim Weirich wrote: > Thanks for the two patches. Do you have any unit tests to go along > with these? What would such a unit test look like? Any examples already in the source tree? --Frank From jim.weirich at gmail.com Wed Apr 23 11:15:52 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Wed, 23 Apr 2008 11:15:52 -0400 Subject: [Rake-devel] patch: lazy proc deps In-Reply-To: <94d1df920804230742n7d4069b0t349a466574a49341@mail.gmail.com> References: <94d1df920804230742n7d4069b0t349a466574a49341@mail.gmail.com> Message-ID: <2BFB6B10-8BF7-4116-8BA3-3FC018AF4915@gmail.com> On Apr 23, 2008, at 10:42 AM, Frank van Viegen wrote: > What would such a unit test look like? Any examples already in the > source tree? Rake has 100% code coverage over its base functionality w.r.t unit tests, so there are a lot of examples in the tests directory. -- -- Jim Weirich -- jim.weirich at gmail.com From tphilipp at potion-studios.com Fri Apr 25 06:17:43 2008 From: tphilipp at potion-studios.com (Tassilo Philipp) Date: Fri, 25 Apr 2008 12:17:43 +0200 Subject: [Rake-devel] Advanced rule's proc not executed Message-ID: Hello mailing list, I'm working with rake 0.8.1, and I have a problem with advanced rules as they are outlined in the documentation. In my case, I try to calculate the name of a .c file's path from an .o file path: rule '.o' => [ proc { |p| getCSourcePath(p) } ] do |t| (do some stuff...) end If there is no .o file at all, this works like a charm. The proc will be called calculating the source file's path, etc.. However, if the .o file exists, the rule won't be executed anymore, even with the source file having a more recent timestamp than the object file. Another thing I noticed is that running rake -P doesn't list the source file as a prerequisite of the object file at all. So, to put it in a nutshell, rake only seems to run the proc used to calculate the source file's path if the rule itself will be executed anyway (which seems kind of wrong to me, since it should always check the prerequisites). So, my question is: Do I overlook something obvious, or is this behaviour intended ? Thanks in advance, and thanks for writing rake in the first place, it's a great tool Tassilo -------------- next part -------------- An HTML attachment was scrubbed... URL: