From: Ethan Mallove (ethan.mallove_at_[hidden])
Date: 2007-06-12 18:00:23
On Tue, Jun/12/2007 04:53:21PM, Jeff Squyres wrote:
> On Jun 12, 2007, at 10:50 AM, Ethan Mallove wrote:
>
> >>> eval $btls = MTT::Functions::if(MTT::Functions::regexp
> >>> (MTT::Functions::shell("hostname"), "v440-2|v20z-2"),
> >>> MTT::Functions::enumerate("self,sm,tcp"),
> >>> MTT::Functions::if("MTT::Functions::regexp
> >>> ("MTT::Functions::shell("hostname"), "v440-6"),
> >>> MTT::Functions::enumerate("udapl"),
> >>> MTT::Functions::enumerate("sm", "tcp",
> >>> "sm,tcp", "udapl", "sm,udapl")
> >>> )
> >>> )
> >>
> >> Ah -- I had to think about this a bit before I figured it out/
> >> remembered. I think we won't get the expansion effect if you do it
> >> this way.
> >
> > No expansion effect? As long as the perl code evaluates to
> > an array, couldn't it to work? E.g.,
>
> We'll need to revamp all the current funclets to accept
> arrays and return [potentially] arrays of arrays. What
> if, as a counterproposal, we have a &perl() funclet?
> Then you could do the following:
>
>
>
> btls = &perl("if ($hostname =~ /foo/) { \
> return ("self,sm,tcp"); \
> } elsif ($hostname =~ /bar/) { \
> return ("udapl"); \
> } else { \
> return ("sm", "tcp", "sm,tcp", "udapl", "sm,udapl"); \
> }")
>
>
>
> (or something like that)
>
I like that. Is that in anticipation of having &ksh(),
&zsh(), &python(), &php(), &tcl(), ... ? To reduce some
clutter, maybe a param like this would be fun, e.g.,
default_ini_evaluator = perl
So MTT will assume you mean &perl() if there's
no leading '&'.
Other legal options being ...
default_ini_evaluator = python
default_ini_evaluator = sh
default_ini_evaluator = tcl
default_ini_evaluator = ...
-Ethan
>
>
>
> --
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> mtt-users mailing list
> mtt-users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users