Forum: Ruby Tasks with Parameters: Can it be done?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2006-06-01 00:05
(Received via mailing list)
I've been working on a task library, on the surface similiar to Rake,
but generalized for use on a per module level --hence usable anywhere
in one's code. The basic principle of the library is that a TASK IS A
METHOD WITH DEPENDENCIES.

But there's a problem with using a notion like that of Rake's. Since
the dependencies are designated by a list of task names there is no way
to pass parameters to those dependencies and hence tasks can't have
parameters at all. Eg.

  task :t1 => [ :t2 ] do
    ...
  end

  task :t2 do |x|
    ...
  end

Clearly it doesn't work for task t2 to have the parameter x since t1
can't pass a parameter using just a symbol list, [:t2].

Since my premise is that tasks are just methods with dependencies I am
considering an alternative notation.

  def t1
    t2( 'yes' )
    ...
  end

  def t1(a)
    ...
  end

  task :t1, :t2

The question is, can the dependency structure be managed properly with
a notation like this? I'm not sure how. Some of you might recall I
suggested using memoize/cache awhile back, but it was pointed out to me
(by Ara I believe) that the dependencies were not handled properly, due
to DAG issues and the possibility of external calls cutting off the
dependency cycle.

So does any one have any idea how it might be done, or perhaps an
alternative way ot supplying parameters to tasks?

Thanks,
T.
Eric H. (Guest)
on 2006-06-01 01:07
(Received via mailing list)
On May 31, 2006, at 1:03 PM, removed_email_address@domain.invalid wrote:

> I've been working on a task library, on the surface similiar to Rake,
> but generalized for use on a per module level --hence usable anywhere
> in one's code. The basic principle of the library is that a TASK IS A
> METHOD WITH DEPENDENCIES.
>
> But there's a problem with using a notion like that of Rake's. Since
> the dependencies are designated by a list of task names there is no
> way
> to pass parameters to those dependencies and hence tasks can't have
> parameters at all. Eg.

[...]

> So does any one have any idea how it might be done, or perhaps an
> alternative way ot supplying parameters to tasks?

Rake does it this way:

$ ri Rake::TestTask
---------------------------------------- Class: Rake::TestTask < TaskLib
      Create a task that runs a set of tests.

      Example:

        Rake::TestTask.new do |t|
          t.libs << "test"
          t.test_files = FileList['test/test*.rb']
          t.verbose = true
        end

      If rake is invoked with a "TEST=filename" command line option,
then
      the list of test files will be overridden to include only the
      filename specified on the command line. This provides an easy way
      to run just one test.

      If rake is invoked with a "TESTOPTS=options" command line option,
      then the given options are passed to the test process after a
'--'.
      This allows Test::Unit options to be passed to the test suite.

      Examples:

        rake test                           # run tests normally
        rake test TEST=just_one_file.rb     # run just one test file.
        rake test TESTOPTS="-v"             # run in verbose mode
        rake test TESTOPTS="--runner=fox"   # use the fox test runner

See also tsort.rb.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Logan C. (Guest)
on 2006-06-02 01:01
(Received via mailing list)
On May 31, 2006, at 4:03 PM, removed_email_address@domain.invalid wrote:

>
>
>   end
>
>   task :t1, :t2
>

This may be the Lisp I just ate talking but...

task :t1 => [ [:t2, arg1, arg2, argetc], [ :t3 ] ] do
    ...
end

task :t2 do |a1, a2, *aetc|
   ...
end

You can even do is_a? Symbol (I know, not ducktype-y enough) and not
have to use a nested-array for tasks with no args
e.g.

task :t7 => [ :t1, :t3, [:t4, "one", "two"], :t6 ] do
  ...
end
unknown (Guest)
on 2006-06-02 04:50
(Received via mailing list)
Logan C. wrote:
> end
>
> You can even do is_a? Symbol (I know, not ducktype-y enough) and not
> have to use a nested-array for tasks with no args
> e.g.
>
> task :t7 => [ :t1, :t3, [:t4, "one", "two"], :t6 ] do
>   ...
> end

Oh right. A clear solution that didn;t even occur to me (duh). But
that's probably b/c you are right. At that point it gets too Lispy. I
really would like a way to do it in the code of the method somehow
though. As I mentioned, using memoize get very close to such a
solution, but the trick is it has to be a sort of "relative cache" i.e.
cacheing in a sort of namespace relative to the initiating task. And I
don't know if that's possible. I imagine trying to control it with
something lije this:

  task :t7 do
    preq { t1; t2; t4("one", "two"); t6 }
    ...
  end

But how would one monitor which methods have been executed?

T.
Logan C. (Guest)
on 2006-06-02 22:42
(Received via mailing list)
On Jun 1, 2006, at 8:47 PM, removed_email_address@domain.invalid wrote:

>> task :t2 do |a1, a2, *aetc|
>
>   task :t7 do
>     preq { t1; t2; t4("one", "two"); t6 }
>     ...
>   end
>
> But how would one monitor which methods have been executed?
>
> T.
>
>

Maybe make tasks objects....

task :t7 do
   preq t1, t2, t4['one', 'two'], t6
end


def preq(*args)
   args.each do |task|
    if task.executed?
        ...
     else
        task.call
        ...
     end
end



#[] can set some sort of @args var that gets nil-ed on execution. (Or
maybe it returns a new object with references to the task and list of
args).
unknown (Guest)
on 2006-06-03 16:43
(Received via mailing list)
Logan C. wrote:
> >> end
> >>   ...
> > something lije this:
> >
>     if task.executed?
> maybe it returns a new object with references to the task and list of
> args).

Hmm... Yea I suppose one could do something like that. You particuklar
syntax wouldn't work tough, but it could be done with something like:

  task :t7 do
     task_send :t1
     task_send :t2
     task_send :t4, 'one', 'two'
     task_send :t6
  end

T.
This topic is locked and can not be replied to.