On 12 May 2010 15:39, Peter Kriens <[email protected]> wrote:
>
> On 12 mei 2010, at 12:54, Derek Baum wrote:
>
> >> Any other items that should be taken care of?
> >
> > FELIX-1304: Better support for variables evaluation in arguments
> > this introduced ${xxx} as an alternative way to expand variables, useful
> if
> > they are adjacent to other text e.g. $HOMEXXX vs ${HOME}XXX. Gogo now
> also
> > implements the bash-like defaulting: ${HOME:-default} expands to $HOME,
> but
> > if it is null it instead expands to the supplied default.
> Hmm, these can all be implemented as commands, do we need to pollute the
> core language with all those hacks?
>
agreed we could do this via commands like: x = defaultIfNull($HOME,
'default'),
but the ${HOME:-default} syntax will already be familiar to Unix users and
is trivial to implement.
>
> >
> > FELIX-1325: gogo doesn't report a command not found error unless an
> argument
> > is supplied
> Well it echoes the value ...
>
This is a problem in a dynamic environment like OSGi, where you expect some
command to exist, and if it doesn't you'd like it to fail with an exception,
rather than silently returning the name of the unfound command.
Of course, you could also do this with a command like: failIfNotFound
myCommand myArgs..., but as I expect many users would want this behaviour by
default, it becomes rather clumsy to use a failIfNotFound command.
>
> > FELIX-1487: Support for commands on multiple lines
> > this makes NEWLINE an alternative to semicolon (;) as statement separator
> Is not in the spec, part of impls.
>
This is especially useful when you move from writing one-liners
interactively, to writing scripts.
It is useful to only require a ; when separating statements on the same
line.
If this is left as an implementation detail, then scripts that omit
semicolons will not be portable.
>
> > FELIX-1493: automatic expansion of $args in Closure stops direct access
> to
> > $args list this adds $argv variable which can always be accessed as a
> List
> Again, can be added with a command.
>
Hmmm... the command would have to be something like makeArray $args and a
closure that tested its args would look like this:
testargs = {
arglist = makeArray $args
if { $arglist isEmpty } {
throw "Usage: help object"
}
...
}
but this approach won't allow shifting arguments, that can be easily
achieved by direct access to the argument list:
aorb = {
arg1 = $argv remove 0 // also removes from $args
if { $arg1 . equals "-a" } {
echo A $args // $args is already specially handled, so
commandA receives multiple args, rather than a single List argument
} {
echo B $args
}
}
$ aorb -a b c
b c
>
> > FELIX-1494: Closure arguments should start at $1
> Why?
>
To be more familiar to bash users, as shell script args start at $1.
This then leaves $0 available for use as the path (or URI) to the external
script (as in bash)
and both closures and external scripts can consistently access their
arguments starting at $1.
Scripts will also be able to use ($0 resolve relative/path) to access
resources, relative to the location of the script, if $0 is set to the URI
of the script, by the implementation.
> > FELIX-1506: allow invocation of static methods
> Not sure why, easy to facade?
>
This is an implementation detail. The current RFC does not mention calling
static methods.
This Jira allowed gogo to invoke static methods, without any changes to the
language.
A use-case is:
$ addcommand system ((bundle 0) loadclass java.lang.System)
which adds all the public methods on the System class, as commands in the
"system:" scope, and then allows, e.g.
system:property user.name
system:env
etc
>> 'addcommand' is currently in the shell: scope. I think this should be
>> moved to the osgi: scope and defined in the RFC.
>What does addcommand do?
see above. shell:addcommand is contained in the original gogo contribution,
and enables adding multiple methods on an Object as commands, without
registering them as a service with the scope and function attributes.
Regards,
Derek
>
> > Comments on your existing feedback:
> >
> >> 2. FELIX-1473 When the first argument is a string, gogo considers
> it
> > to be a command. The problem is that it leads to unpredictible behavior
> > when using variables
> >> $a length
> > Depending on the type of $a, it will
> > either try to call a command named by the value of $a, or call the length
> > method on the $a object. Felix added a . to force the interpretation to
> be a
> > string. Guess (string $a) length would also work.
> I like that solution, no changes to the language.
>
> > Alternatively, $a length could always be treated as a method call, and we
> > could use some other syntax to indicate we want to treat it as a command,
> > for example: "$a" length, as quoting forces the expansion to a String.
> >
> > However, the FELIX-1473 solution of using . to force a method call is
> > probably easier. It also has the advantage of allowing simpler chaining
> of method calls, for
> > example:
> >
> > % myhost = (((bundle 0) loadclass java.net.InetAddress) localhost)
> hostname
> >
> > is simplified by using the dot notation:
> >
> > % myhost = (bundle 0) . loadclass java.net.InetAddress . localhost .
> hostname
> I am not sure this flies. I think the (string $a) seems best, though have
> to think about this.
>
> >> 4. #49.1 Request to provide Set<String> getCommands. I suggest we
> > create a CommandDescription that is returned. This description will
> provide
> > sufficient info to not only finish the name of the command but also fill
> in
> > parameters and show flags. See annotations later.
> >
> > #49 refers to https://www.osgi.org/bugzilla/show_bug.cgi?id=49
> >
> >> 5. #49.2 Provide access to the variables. Makes a lot of sense.
> >
> >> 6. #49.3 Allow removal of variables. Maybe we should use have a
> > Map<String,Object> getVariables method.
> >
> > yes, this would also allow removal of the CommandSession get() and put()
> > methods, which could be replaced by session.variables().get(k) and
> > session.variables().put(k, v) instead.
> Yup.
>
> >> 7. #49.4 Add boolean isTty(InputStream in); boolean
> > isTty(OutputStream out) so commands can adapt to interactive and piped.
> Not
> > sure, needs discussion. I am not that charmed by commands adapting, that
> is
> > why there are options.
> >
> > another use case for this suggestion is for commands that use ANSI escape
> > sequences to produce coloured output. This method would enable these
> > commands to automatically suppress the ANSI sequences if they are
> outputting
> > to a pipe; otherwise, as you say, they would need some explicit
> "--no-ansi"
> > option.
> I think we need another solution for this. I've been working on a Terminal
> service that handles these issues. Maybe we should go to a curses lib. Not
> sure
> we should try to standardize this here. Lets face, the session has no clue
> about the
> input stream anyway, it might also be redirected.
>
> > 8. #49.5 Add InputStream setInput(InputStream in) for history etc. I
> > disagree. The request behavior can easily be gotten by proxying the input
> > stream, I think. Lets try to keep it simple.
> > I agree. I can work without this.
> >
> >> 9. #52 commands in osgi: scope need to be well defined. They're
> > currently defined as the methods on the BundleContext ... Will work on
> this.
> >
> > The current commands in the osgi: scope in gogo include:
> > methods on Bundle
> > methods on BundleContext
> > methods on PackageAdmin, StartLevel and PermissionAdmin, if service
> > available
> > built-in procedural commands (each, if, tac, new)
> > example commands (cat, echo, grep, etc)
> >
> > Richard Hall has asked me to reduce the default commands registered in
> > the gogo runtime to a minimum. The gogo console or other users of the
> gogo
> > runtime, can then easily register other commands as required.
> >
> > I think the minimum from the above is just the methods on BundleContext,
> and
> > the procedural commands, as this then allows the other commands to be
> added,
> > if required, using a script:
> >
> > % addcommand osgi (bundle 0)
>
> >
> > % service = {
> > refs = osgi:serviceReferences $1 null
> > if {$refs} {osgi:getService ($refs 0)}
> > }
> >
> > paclass = (bundle 0) loadclass
> > org.osgi.service.packageadmin.PackageAdmin
> > paservice = service ($paclass name)
> > % addcommand osgi $paservice $paclass
> >
> > I include 'tac' and 'new' in the group of 'built-in' commands, because
> > the RFC explicitly describes 'tac' as the way to direct output to a file
> and
> > 'new' should leverage the same argument coercion used for method
> invocation.
> >
> > 'addcommand' is currently in the shell: scope. I think this should be
> > moved to the osgi: scope and defined in the RFC.
> What does addcommand do?
>
> Kind regards,
>
> Peter Kriens
> >
> >
> > Derek
> >
> > On 11 May 2010 19:49, Peter Kriens <[email protected]> wrote:
> >
> >> I am updated RFC 147 and prepare it for the meeting next week. I've got
> the
> >> following feedback so far:
> >>
> >>
> >> 1. FELIX-1526 Replace <> embedded execution with (). Originally the ()
> >> were used for filters. I am ok in making this change and not directly
> >> supporting filters.
> >> 2. FELIX-1473 When the first argument is a string, gogo considers it
> to
> >> be a command.
> >> The problem is that it leads to unpredictible behavior when using
> >> variables
> >>
> >>> $a length
> >>
> >> Depending on the type of $a, it will either try to call a command
> named
> >> by the value of $a, or call the length method on the $a object. Felix
> added
> >> a . to force the interpretation to be a string. Guess (string $a)
> length
> >> would also work
> >> 3. FELIX-1536 Reverse priority of statement and pipe. Currently a; b |
> >> c pipes both and b through c. In unix this is different, it only pipes
> b
> >> through c. I think the current syntax is more logical but
> compatibility with
> >> unix is not irrelevant.
> >> 4. #49 Request to provide Set<String> getCommands. I suggest we create
> >> a CommandDescription that is returned. This description will provide
> >> sufficient info to not only finish the name of the command but also
> fill in
> >> parameters and show flags. See annotations later.
> >> 5. #49 Provide access to the variables. Makes a lot of sense.
> >> 6. #49 Allow removal of variables. Maybe we should use have a
> >> Map<String,Object> getVariables method.
> >> 7. #49 Add boolean isTty(InputStream in); boolean isTty(OutputStream
> >> out) so commands can adapt to interactive and piped. Not sure, needs
> >> discussion. I am not that charmed by commands adapting, that is why
> there
> >> are options.
> >> 8. #49 Add InputStream setInput(InputStream in) for history etc. I
> >> disagree. The request behavior can easily be gotten by proxying the
> input
> >> stream, I think. Lets try to keep it simple.
> >> 9. #52 commands in osgi: scope need to be well defined. They're
> >> currently defined as the methods on the BundleContext ... Will work on
> this.
> >> 10. #51 Define command search order. Makes sense to add a PATH
> variable
> >> of type String[].
> >> 11. #53 Command help. Adding the CommandDescriptor would help here.
> >>
> >>
> >> Additionally, there is a development going on in Felix that made me want
> to
> >> add the following areas.
> >>
> >>
> >> 1. Richard and I played with annotations and the type
> conversion/method
> >> coercion. I like to add a new package and then define generic
> annotations
> >> for: Description + a special Parameter annotation. The description is
> >> logical, the Parameter will allow flags (-x), optionality, and will
> allow
> >> steering of type conversion. This made it clear to me that we need a
> type
> >> conversion package that can handle the requirements of Blueprint, TSH,
> and
> >> maybe even DS in the future. Type annotations can be provided to steer
> this
> >> conversion. It seems that this problem pops up in lots of places.
> >>
> >>
> >> Any other items that should be taken care of?
> >>
> >> Kind regards,
> >>
> >> Peter Kriens
> >>
> >>
>
>
