Re: [Help-smalltalk] Newbie questions: use blox with local image; jit segfault

[Bonzini Paolo]

>  1. How to run the graphical browser for my *own* image?
> 
> I can run:'gst -qK blox/Run.st' fine. I get the graphical
> browser. However, if I remember correctly, all image modifications are
> store in the local shared image (in /usr/local): not very cool!

Save a snapshot after you loaded the browser (Smalltalk snapshot:
'FILENAME') and then use that image (gst -I FILENAME).  The idea is that
the shared image provides a base.

> It is written in the doc that gst as an internal path of needed kernel
> files. Isn't it true for blox related files?

Blox-related files are in ../blox, relative to the kernel path.  To run
the image you can load blox/Run.st from your .stinit file, or specify the
full path to it on the command line (the -K switch is just a shortcut) or
copy its contents to .stinit, or create a small class and register it with
ObjectMemory before saving the image:

    Object subclass: #LoadBlox
        etc....!

    !LoadBlox class methodsFor: 'ObjectMemory'!

    update: aspect
        aspect == #returnFromSnapshot ifTrue: [
            BrowserMain new initialize
            "or something like that, just copy from Blox/Run.st"
        ]! !

    ObjectMemory addDependent: LoadBlox!

> Is it mandatory to have a fie named package? If true, what should I do
> to include standard gst packages?

In the development version the file is in the parent of the kernel
directory, which solves many problems with local images.  The file is
mandatory to load packages into an image, but not if you build the image
after having loaded the necessary package.  Anyway, copy it from
/usr/local/share/...

>  2. gst with jit enabled segfault when accesing the menu of the
>     graphical Transcript:
> 
> address@hidden:~$ which gst
> /usr/local/Installed/GNU-Smalltalk-1.95.10-jit/bin/gst
> address@hidden:~$ gst -qK blox/Run.st
> GNU Smalltalk Ready
> 
> /usr/local/Installed/GNU-Smalltalk-1.95.10-jit/share/smalltalk/blox/Run.st:39:
>  Segmentation violation
> BlockContext class>>#fromClosure:parent:
> Erreur de segmentation <--- Segfault in French :)

Probably a GC bug (basically if GC is triggered before a method
establishes an execution context for itself, the method's translation
can be GCed and after GC the virtual machine jumps to nowhere).

Paolo