I think once we have the scala console working registering a gogo command to access it should be quite straight forward. Still I think the independent scala console should best be implemented first.
Cheers, reto On Fri, Jul 9, 2010 at 5:56 PM, Derek Baum <[email protected]> wrote: > I've recently been experimenting with adding groovy support for gogo, and I > assume that scala would be similar. > > My use-case is that although gogo is scriptable, it was never intended to > be > used instead of groovy or scala. > > I therefore wanted the ability to run a full blown groovy script from gogo, > giving the script access to my gogo session variables and an OSGi context. > Here's a brief look of what it can do so far: > > [Note: I'm using posh here, which is part of our commercial Nimble product, > but this could easily be ported to gogo] > > % cat hello.groovy > #!/usr/bin/env posh -c groovy > > println "hello, groovy!" > > // access bundle context > println context.bundle > > // run gogo command > def b0 = session.execute("bundle 0") > println "b0=" + b0 > > // concatenate arguments from gogo > def result = "" > > for (arg in this.args) { > println "Argument:" + arg.class + ": " + arg; > result += arg > } > > return result > % > > # now run hello.groovy script from posh/gogo > # note: that arguments and return value are handled correctly > > % groovy hello.groovy $HOME $SHLVL > hello, groovy! > com.paremus.posh.runtime_1.0.21.SNAPSHOT [1] > b0=org.eclipse.osgi_3.6.0.v20100517 [0] > Argument:class java.net.URI: file:/Users/derek/ > Argument:class java.lang.Integer: 1 > % > % echo $_ > file:/Users/derek/1 > % > > > > # now run groovy interactively from posh/gogo > # this is less advanced, as there is no command-line editting or > completion. > # rather than posh/gogo try to provide this, it should be provided by the > scripting environment > # so that gogo/scala shell handles completion/editting in exactly the same > way as the non-OSGi scala shell. > > % groovy > groovy$ println context.bundle(0) > groovy: groovy.lang.MissingMethodException: No signature of method: > org.eclipse.osgi.framework.internal.core.BundleContextImpl.bundle() is > applicable for argument types: (java.lang.Integer) values: [0] > Possible solutions: getBundle(), getBundle(long), getBundles(), > findAll(groovy.lang.Closure), find(groovy.lang.Closure), > use([Ljava.lang.Object;) > groovy$ > groovy$ println context.getBundle(0) > org.eclipse.osgi_3.6.0.v20100517 [0] > groovy$ % > > > Does this have any synergies with what you're want to do, assuming we can > create similar functionality using scala? > > Regards, > > Derek > > > > On 7 July 2010 15:39, Richard S. Hall <[email protected]> wrote: > > > On 7/7/10 3:39, Reto Bachmann-Gmuer wrote: > > > >> On Tue, Jul 6, 2010 at 11:09 PM, Richard S. Hall<[email protected] > >> >wrote: > >> > >> I'm not too familiar with Scala, so pardon my ignorance. > >> > >> > >>> So is the proposal to have some sort of Scala-based console/shell? Does > >>> this mean you can do Scala-based scripting and syntax? Is this > something > >>> that could simply be another shell front end for the Gogo runtime or is > >>> it > >>> somehow completely different? > >>> > >>> > >>> > >> I must admit I'm not familiar with OSGi RFC-147 so I'm not sure if it > >> could > >> be implemented on it. > >> > >> To be as attractive for people currently not using OSGi it should feel > as > >> much as possible like the scala console, this includes: > >> - autocompletion with tab > >> - multi-line expressions (afte an incomplete expression such as one > >> opening, > >> but not closing a bracket a continuation-prompt appears) > >> > >> Once we have this we can add a DSL to more easily do OSGi related tasks > >> (listing services and bundles, accessing services, etc. ) > >> > >> > > > > Well, I still can't say I totally understand what is being proposed, but > > I'm not against having people work on it at Felix if other people think > its > > worthwhile. If it does ultimately blossom into a full-blown shell for > OSGi, > > then there will certainly be some overlap with Gogo, but we can always > look > > for ways to bridge the two... > > > > -> richard > > > > Reto > >> > >> > >> > > >
