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?
>
> FELIX-1325: gogo doesn't report a command not found error unless an argument
> is supplied
Well it echoes the value ...
> 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.
> 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.
> FELIX-1494: Closure arguments should start at $1
Why?
> FELIX-1506: allow invocation of static methods
Not sure why, easy to facade?
> 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
>>
>>
