GNU Smalltalk Sprint

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GNU Smalltalk Sprint

MrGwen
Hi All,

The GNU Smalltalk sprint will be done during this week end (11-12 December)
It will be done on IRC #gnu-smalltalk on Freenode (irc.freenode.net)
and it is open to everybody :)

Some proposed tasks:
- VisualGST
- Coverage tool (for method-coverage, it can be based on gst-profile)
- SUnit testcases for CObject and everything not currently covered
- Fixing the compiler (http://smalltalk.gnu.org/project/issue/527)
- Fixing gst-remote (http://smalltalk.gnu.org/project/issue/497 and
http://smalltalk.gnu.org/project/issue/496)
- Fixing GTK on OSX
- Packages (atomic loading, package builder, ...)
- Allow VisualGST to hook up to a headless gst like gst-remote does.
Just imagine how much fun working on a running Iliad app you could
have with this.

The wiki: http://smalltalk.gnu.org/wiki/events

Cheers,
Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk Sprint

Paolo Bonzini-2
On 12/10/2010 11:05 AM, Gwenaël Casaccio wrote:
> - Fixing GTK on OSX

Already done. :)

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk Sprint

Dmitry Matveev
Hello,

Thank you Gwen for the reminder, I have already wanted to ask in the
list about the upcoming event.

Mostly I am interested in making VisualGST able to work with a remote image.

To save more time for implementation, I have prepared a short proposal
"how it could be done" today:
1. To add an abstraction layer to VisualGST, through which it will
receive the list of namespaces/classes/methods/sources.
   I think that Strategy pattern is the most appropriate here and
VisualGST will have two strategies:
   - reflection for thr current image;
   - network protocol for a remote image.

2. To design an network protocol. I think that for a first time we
could leave concurency and to use a syncronious protocol.
   I see entities in the communication: Client (VisualGST) and the
Server (remote image).
   The active member is Client - it will send requests to Server and
Server will respond. Server will not send anything without an
appropriate request (for simplicity).
   I see a set of possible commands:
   - get a list of namespaces;
   - get a list of classes in namespace;
   - get a list of methods in class (instance side or class side);
   - register a new class with the supplied description (comment,
instance/class variable names, ect);
   - remove a class;
   - get a source string of a concrete method in a concrete class;
   - compite a supplied source string for a concrete method in a concrete class.

   I think it would be more than enough for sprint :) Network protocol
could be implemented using XML - I see the following advantages here:
   - easy to serialize;
   - portable, i.e. it would be possible to write a mode for Emacs
that will communicate with image is a SLIME flavour (that's my
dream!).

3. To implement it all :)
   - the client network part that will send requests and receive
responses will be implemented in the appropriate factory;
   - the remote image will have a lightweight smalltalk server running
in a separate Smalltalk process on the selected port. Server will
receive requests and reply with responses.

Looks clear... At least for me. I will start working on the basic
parts (strategies) tonight and _may be_ will publish the first patches
tomorrow.

Any comments ans feedback are welcomed!

Dmitry


2010/12/10, Paolo Bonzini <[hidden email]>:

> On 12/10/2010 11:05 AM, Gwenaël Casaccio wrote:
>> - Fixing GTK on OSX
>
> Already done. :)
>
> Paolo
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk
>

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: GNU Smalltalk Sprint

Paolo Bonzini-2
On 12/10/2010 09:47 PM, Dmitry Matveev wrote:

> 2. To design an network protocol. I think that for a first time we
> could leave concurency and to use a syncronious protocol.
>     I see entities in the communication: Client (VisualGST) and the
> Server (remote image).
>     The active member is Client - it will send requests to Server and
> Server will respond. Server will not send anything without an
> appropriate request (for simplicity).
>     I see a set of possible commands:
>     - get a list of namespaces;
>     - get a list of classes in namespace;
>     - get a list of methods in class (instance side or class side);
>     - register a new class with the supplied description (comment,
> instance/class variable names, ect);
>     - remove a class;
>     - get a source string of a concrete method in a concrete class;
>     - compite a supplied source string for a concrete method in a concrete class.

Yes, that's a subset of the methods of Class (and Behavior via
inheritance), Namespace (and Dictionary, also via inheritance),
CompiledMethod (and MethodInfo via composition).  It can grow as needed.

>     I think it would be more than enough for sprint:)  Network protocol
> could be implemented using XML - I see the following advantages here:
>     - easy to serialize;
>     - portable, i.e. it would be possible to write a mode for Emacs
> that will communicate with image is a SLIME flavour (that's my
> dream!).

That's nice.  It's even possible to plug a more compact format later
(based e.g. on ObjectDumper and proxies, or on Spoon), since the
Strategy pattern should be flexible enough.

Starting to work on the network protocol is good and probably enough for
the sprint, I think.  Also, the strategy pattern implementation could be
a separate package from VisualGST so they can developed independently
with their own unit tests.

Thanks!

Paolo

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