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?
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.
···
On May 31, 2006, at 1:03 PM, transfire@gmail.com wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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
···
On May 31, 2006, at 4:03 PM, transfire@gmail.com 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.
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.
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
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.
···
On May 31, 2006, at 4:03 PM, transfire@gmail.com wrote:
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).
···
On Jun 1, 2006, at 8:47 PM, transfire@gmail.com wrote:
Logan Capaldo wrote:
On May 31, 2006, at 4:03 PM, transfire@gmail.com wrote:
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
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?
>
> Logan Capaldo wrote:
>>
>> 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
>
> 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.
>
>
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).
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.
···
On Jun 1, 2006, at 8:47 PM, transfire@gmail.com wrote:
>> On May 31, 2006, at 4:03 PM, transfire@gmail.com wrote: