re-loading code

Greetings,

I'm looking into writing another webapp with gst/iliad.

Given that I keep my code in one file per class, and that I define
a namespace for my package via package.xml, what is the best way
to reload the code for a single class so that I don't have to
walk the "gst-remote --kill ; gst-package ; gst-remote --server"
path so often?

As an example consider the following workflow

  gst iliad/scripts/PackageBuilder.st -a package.st > package.xml
  gst-package -t ~/.st package.xml
  echo "PackageLoader fileInPackage: 'Iliad'; fileInPackage: 'App'. ObjectMemory snapshot: 'iliad.im'" | gst
  gst-remote --server --port $PRIVATE_PORT -I iliad.im 2>&1 | tee iliad.log &
  vi MyWidget.st
  ???

How do I get the updated MyWidget code into the running iliad.im
so that the next invocation actually uses the new code?

I just can't see it.

Time for a walk, obviously,
s.


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

On 01/22/2011 03:55 PM, Stefan Schmiedl wrote:
> Greetings,

> How do I get the updated MyWidget code into the running iliad.im
> so that the next invocation actually uses the new code?

In general i think this is something where GNU Smalltalk could be a lot
better. When you try to use FileStream fileIn: 'Source' you will need to
manually set the right namespace.

What I tend to do is to either:
a)
    $ Smalltalk removeFeature: #MyMod. PackageLoader fileInPackage: #MyMod
b)
    When developing the module just load everything from the module in
    the current namespace with 'FileStream fileIn' and then load new code
    again.


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

On Sat, 22 Jan 2011 16:15:27 +0100
Holger Hans Peter Freyther <[hidden email]> wrote:

> On 01/22/2011 03:55 PM, Stefan Schmiedl wrote:
> > Greetings,
>
> > How do I get the updated MyWidget code into the running iliad.im
> > so that the next invocation actually uses the new code?
>
> In general i think this is something where GNU Smalltalk could be a lot
> better.

I hope that it's just a matter of finding the correct sequence of message
sends and then encapsulating them into something short :-)

> When you try to use FileStream fileIn: 'Source' you will need to
> manually set the right namespace.

which I should be able to do by providing some wrapper.

>
> What I tend to do is to either:
> a)
>     $ Smalltalk removeFeature: #MyMod. PackageLoader fileInPackage: #MyMod

Aha. I was missing the removeFeature: message. Obviously I need to read
the docs again. Having a bad memory is a two-edged sword, as I end
up in newbie-situations more often than usual ;->

What happens to instances of classes defined in package MyMod during
removeFeature? Are they kept around and migrated somehow to the new structure
when that is loading?

> b)
>     When developing the module just load everything from the module in
>     the current namespace with 'FileStream fileIn' and then load new code
>     again.
>

Oh. Now that you've said it, it's as obvious as the invention of the catflap.

Thanks!

s.

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

On Sat, 22 Jan 2011 16:52:16 +0100
Stefan Schmiedl <[hidden email]> wrote:

Looks like it.

> > What I tend to do is to either:
> > a)
> >     $ Smalltalk removeFeature: #MyMod. PackageLoader fileInPackage: #MyMod
>
> What happens to instances of classes defined in package MyMod during
> removeFeature? Are they kept around and migrated somehow to the new structure
> when that is loading?

Yep, they are! I had the "usual" counter counting to 6, then I changed
the ++ and -- methods to perform the calculations for the Collatz sequence
(n -> n/2 on --, n -> 3n+1 on ++) and ran:

gst-remote --eval "Smalltalk removeFeature: #App. PackageLoader fileInPackage: 'App'"

and, big cheer, -- led me to 3, then ++ gave me a 10.

Grinning insanely,
s.

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

On 01/22/2011 04:52 PM, Stefan Schmiedl wrote:

>> When you try to use FileStream fileIn: 'Source' you will need to
>> manually set the right namespace.
>
> which I should be able to do by providing some wrapper.

Yes, it is possible to manually set the namespace... i normally don't do it.

>

> What happens to instances of classes defined in package MyMod during
> removeFeature? Are they kept around and migrated somehow to the new structure
> when that is loading?

st> Smalltalk class decompile: #removeFeature:
'removeFeature: aFeature [
        "Remove the aFeature feature to the Features set"

        <category: ''special accessing''>
        Features class == Set ifFalse: [Features := Features asSet].
        Features remove: aFeature ifAbsent: []
    ]'

For our concern here it is just a Set that is used by the PackageLoader to
decide if it needs to load something or not.


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

On 01/22/2011 04:52 PM, Stefan Schmiedl wrote:
>> >  When you try to use FileStream fileIn: 'Source' you will need to
>> >  manually set the right namespace.
>
> which I should be able to do by providing some wrapper.

I'm going to add #fileIntoNamespace: soon to both FilePath and Stream,
which will give you

    'Source' asFile fileIntoNamespace: Foo

Paolo

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