Creating "echo" in GNU Smalltalk

Hi.

Well, I've set out to create a tutorial. But, found that I wasn't able
to do it right at any moment.

I would like to create the program "echo". Without any of the fancy
commandline flags, just the bare core, so:

Smalltalk arguments do: [ :a| Transcript nextPutAll: a] separatedBy: [
Transcript nextPutAll: ' ']!

That takes care of the source. Now the hard parts...
- How do I create a usable, distributable image without distributing
the source. (My source is hopelessly distributed over hundreds of
files with allot of secrets ;-) )
- How could I make it replace my current echo binary (although not
currently possible, without the extra flags). In short: make it
'self-contained' or executable.

Bram

PS and Offtopic: is there a way to load another image and call an
object within that image? Effectively using other images as libraries?


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> - How do I create a usable, distributable image without distributing
> the source. (My source is hopelessly distributed over hundreds of
> files with allot of secrets ;-) )
I'd not.  Remember the "Scripting" part of GNU Smalltalk.  But if you
really want, create a class EchoMain, and add a method to get the
#returnFromSnapshot update from ObjectMemory:

Object subclass: #EchoMain
       instanceVariableNames: ''
       classVariableNames: ''
       poolDictionaries: ''
       category: 'Language-Implementation'!

!EchoMain class methodsFor: 'foo'!

update: aspect
    aspect == #returnFromSnapshot ifTrue: [
        Smalltalk arguments = #('--repl') ifFalse: [
            self main: Smalltalk arguments.
            ObjectMemory quit ] ]!

main: argv
     "I love Java names!"
    argv
        do: [ :a| Transcript nextPutAll: a]
        separatedBy: [ Transcript nextPutAll: ' '].
    Transcript nl! !

ObjectMemory addDependent: EchoMain.
ObjectMemory snapshot: 'echo.im'!

Run this script and it will create an echo.im image.  If you have gst in
your path, you can just do "chmod +x echo.im" and then "./echo.im abc def".

I've placed a small hook, in that "./echo.im --repl" will bring the
standard read-eval-print loop up.
> - How could I make it replace my current echo binary (although not
> currently possible, without the extra flags). In short: make it
> 'self-contained' or executable.
If you have an image, of course it's just "cp echo.im /bin/echo" (not
suggested :-).  If you have a script, add "#! /usr/bin/env gst -f" at
the head of it, or this:

#! /bin/sh
"exec" "gst" "-f" "$0" "$@"
> PS and Offtopic: is there a way to load another image and call an
> object within that image? Effectively using other images as libraries?
No, though in principle what you are describing is an RPC server.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Bram Neijt wrote:
> That takes care of the source. Now the hard parts...
> - How do I create a usable, distributable image without distributing
> the source. (My source is hopelessly distributed over hundreds of
> files with allot of secrets ;-) )

With file-ins the source is not actually contained in the image, but as
a reference to the source file. Run strings on your image to check, but
I think you're safe.

> - How could I make it replace my current echo binary (although not
> currently possible, without the extra flags). In short: make it
> 'self-contained' or executable.

chmod a+x echo.im

> PS and Offtopic: is there a way to load another image and call an
> object within that image? Effectively using other images as libraries?

I think that this is something akin to loading an image segment, ie.
incorporating compiled Smalltalk into your image. That's not possible,
but I'll go off on a little digression here, if you don't mind :)

Wouldn't it be nicer if you instead ran the other image and then
communicated with it by sending messages, maybe via http, for example?
Sure, it will be a little slower, but the image could even be located on
a remote server. It would also mean that your client wouldn't actually
have to be Smalltalk itself. Hmmm...

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk