[ANN] a new lightweight web framework for GST

Stefan Schmiedl wrote:
No, we don't.  The body of gst-remote is installed in
/usr/share/smalltalk/scripts/Remote.st and it is, in some sense, the
moral equivalent of the drb server and library.  It would be possible
and easy to move the gst-remote client to a package so that other
scripts could act as gst-remote clients.

Note however that drb is not a REPL.  It is more than a REPL in that it
provides distributed objects.  But if I understand correctly it is also
less than a REPL in that you would need anyway to write the logic to
read evals on the client (from the command line) and a server object to
capture stdout and send it back to the client.

I had written a long blurb on gst-remote before writing the above
answer.  It didn't really answer your question but I think it is
interesting anyway, so here it is.

The gst-* binaries (gst-load, gst-sunit, gst-remote, gst-doc, gst-blox,
etc.) are actually all compiled from the same source, gst-tool.c, and
actually they are all hard links to the same executable; they call a
Smalltalk script in /usr/share/smalltalk/scripts depending on argv[0].
I'll call the binaries gst-tool in the rest of this message.

gst and gst-tool are the two clients of libgst.so in the standard
distribution of GNU Smalltalk.  They only differ in the handling of
command-line options; their source code is in main.c for gst and in
gst-tool.c for gst-tool.

There are two reasons for gst-tool's existence.

The first is that most of the gst-* tools care a lot about what image
they are loaded in.  For example, gst-remote does not care much about it
when loaded as a client, but it obviously does when loaded as a server.
  For gst-blox, gst-load and gst-sunit, it would not make sense at all
to not have a -I option.  The -I option however must be processed before
the Smalltalk script is started, so you cannot just use a "#!
/usr/bin/gst -f" line.  Before the gst-tool binary was born, the parsing
of the command-line to separate -I arguments was done with a shell script.

Nowadays, the gst-tool binary does a few more things: it implements
--daemon, and it passes a few of configure's results to the scripts so
that the Smalltalk code can be used with no modification on different
platforms.

The second is that this makes it much easier to deploy Smalltalk scripts
on native Windows, which does not support #! lines.  On native Windows,
a Smalltalk script would anyway need a small stub executable that
started it.  This is especially important for gst-blox, which is a
"real" application that someone may want to link on the desktop or start
menu, rather than invoke from a Cygwin or MSYS shell.

There is a third reason too, though it is more of an historical
background.  Until GNU Smalltalk 3.0 the interface of libgst.so was a
bit fake; main.c was little more than this:

   int
   main(int argc, const char **argv)
   {
     int result;
     gst_smalltalk_args(argc, argv);
     result = gst_init_smalltalk();
     if (result == 0)
       gst_top_level_loop();

     exit(result <= 0 ? 0 : result);
   }

and the parsing of command-line options was entirely in libgst/lib.c.  I
wanted to get rid of this and have a real library interface, and I
needed a use case to test the library interface.  Of course, some
coverage came from moving command-line option parsing was moved from
libgst/lib.c (now libgst/files.c) to main.c, but it would have been nice
to see if the interface was okay for a simpler client that only needed a
handful of settings.  Given how messy the gst-* shell scripts were,
gst-tool was born as an alternative client to clean up the mess and to
see if the new library interface could do the task.

Ciao,

Paolo


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

On Fri, 19 Jun 2009 15:04:20 +0200
Paolo Bonzini <[hidden email]> wrote:

> Stefan Schmiedl wrote:
> > Why do we need a dedicated gst-remote binary?
>
> No, we don't.  The body of gst-remote is installed in
> /usr/share/smalltalk/scripts/Remote.st and it is, in some sense, the
> moral equivalent of the drb server and library.  It would be possible
> and easy to move the gst-remote client to a package so that other
> scripts could act as gst-remote clients.

It would be _very_ convenient to be able to do this.

Since we're currently all so hot about web app servers, I'd
really like to be able to remotely "save" the image (for
backup or debugging) or put the server into "maintenance mode"
for extensive data massage sessions that should not be interrupted
by users. Basically, it's stuff used rarely where I don't
want to provide or need a real GUI for.

> Note however that drb is not a REPL.  It is more than a REPL in that
> it provides distributed objects.  But if I understand correctly it is
> also less than a REPL in that you would need anyway to write the
> logic to read evals on the client (from the command line) and a
> server object to capture stdout and send it back to the client.

My typical use cases would be:
- "execute" a message on the server, where I don't care
  for the result of the evaluation
- "query" the server, where the result is important.
In the query case, it's (of course) my responsibility to
answer something that the client can handle, i.e. "primitive"
objects, or loading necessary definitions into the client
image first.

> I had written a long blurb on gst-remote before writing the above
> answer.  It didn't really answer your question but I think it is
> interesting anyway, so here it is.

Much appreciated. In fact, it should go into the wiki.

Thanks,
s.


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

> Since we're currently all so hot about web app servers, I'd
> really like to be able to remotely "save" the image (for
> backup or debugging) or put the server into "maintenance mode"
> for extensive data massage sessions that should not be interrupted
> by users. Basically, it's stuff used rarely where I don't
> want to provide or need a real GUI for.

So you mean making a small Seaside app that does the same kind of
"Transcript multiplexing" as gst-remote?  That shouldn't be hard at all,
and should only require a handful of lines from scripts/Remote.st.

>> I had written a long blurb on gst-remote before writing the above
>> answer.  It didn't really answer your question but I think it is
>> interesting anyway, so here it is.
>
> Much appreciated. In fact, it should go into the wiki.

Or in the FAQ.  I'll do that on Monday, I'm leaving now.

Paolo


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

On Fri, 19 Jun 2009 14:35:14 +0200
Paolo Bonzini <[hidden email]> wrote:

Why is that? Technical considerations or the need for
more control over what happens when?

> Stephen Compall would be the right person to look into it (he was the
> one stress-testing the Smalltalk compiler to the point that it became
> usable for gst-remote), but he's not been active for a while.

maybe, if we make enough noise, he'll hear us :-)

s.


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

On Fri, 19 Jun 2009 15:34:06 +0200
Paolo Bonzini <[hidden email]> wrote:

duh ... of course ... set up a different app with a large
input box ... good idea :-)

> >> I had written a long blurb on gst-remote before writing the above
> >> answer.  It didn't really answer your question but I think it is
> >> interesting anyway, so here it is.
> >
> > Much appreciated. In fact, it should go into the wiki.
>
> Or in the FAQ.  I'll do that on Monday, I'm leaving now.

have a nice weekend,
s.


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

>> P.S.: I could help, writing something like a small tutorial (if you'd
>> like), but I have to understand a bit more of it first.
>
> Yes, that would be wonderful :)

I think, I'll start tomorrow (where I have a little more time than this
week) writing a bit about iliad.

But please don't expect a fully featured howto in the beginning. I will
start using it and write about the things I dicover or which I find
usefull/interesting to tell about...

(And if you think, I chatter to much in the blog, don't hesitate to tell
me that! [Maybe that already happend...])

Regards,
Joachim.


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

Le vendredi 19 juin 2009 à 15:53 +0200, Joachim Jaeckel a écrit :
> >> P.S.: I could help, writing something like a small tutorial (if you'd
> >> like), but I have to understand a bit more of it first.
> >
> > Yes, that would be wonderful :)
>
> I think, I'll start tomorrow (where I have a little more time than this
> week) writing a bit about iliad.

Great!
>
> But please don't expect a fully featured howto in the beginning. I will
> start using it and write about the things I dicover or which I find
> usefull/interesting to tell about...

That's perfectly fine. Writing doc while you learn Iliad would be very
useful to others I think.

Do not hesitate to ask questions!

Cheers!

Nico

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

>> Indeed.  gst uses the builtin compiler (written in C), while
>> gst-remote uses the Parser and Compiler packages.
>
> Why is that? Technical considerations or the need for
> more control over what happens when?

It is a bit easier to use a Smalltalk parser and compiler.  For
example the C compiler runs each evaluation in a different process,
which makes it harder to direct the Transcript output to the
appropriate socket.

Paolo


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

Le dimanche 21 juin 2009 à 11:57 +0200, Joachim Jaeckel a écrit : Elements are just stateless objects that know how to build themselves in
HTML.

So if you have a view method where you don't need widgets, just write it
with elements only:

index [
        <category: 'views'>
        ^[:e |
                e h1: 'Hello world'.
                e text: 'Thi part of my application is obviously stateless. I don''t
need widgets here']
]


> (I haven't currently found another class of
> elements, which provide the #contents method, or do I have to handle
> elements in a different way?)

No, just use them in view methods, you don't have to create subclasses.

>
> Maintaining state means also, if I #show another widget, and would like
> to go back afterwards to the same dialog...?

Yes, that, but not only. Take a look at the counter widget. It maintains
state to the client: it's count value.

If this counter wasn't saved as an instance variable of the application,
a new one would be built for each request, so it wouldn't work...

>
> That would also mean, that widgets need to #build only once? (Mmmhh, no,
> #build is the process to build the page-content, isn't it?)

#build is the process of building HTML. each widget can be built
separately, and that's actually what is happening when a widget is
updated with an AJAX request, only the updated widget is rebuilt.

>
> If I need a statefull widget in one place, then all the parent-pages
> should also be a widget.
Yes, that's the idea. Widgets are stateful hight level html builders.
ELements are just low level objects for building html.

>
>
> Yesterday evening, I wrote another blog-post about Iliad, would it be
> possible for you, to have a look at it (even for the future, for new
> posts), that mistakes which I probably do in using the framework attract
> attention as early as possible?

Another cool post :) Thanks!

The blog post great, don't worry. Maybe you could show how to use
actions in links and in forms? this mechanism is the basis of stateful
ressources in Iliad.

 If you don't know how to use action blocks, I can provide you several
examples, but looking at this:

entries do: [ :each |
                (ul listItem anchor) text: each key; action: each value

It seems that you already know that ;)

Cheers!

Nico

>
> Regards,
> Joachim.

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

Hello Nico,

thanks for the clarification!

 > The blog post great, don't worry. Maybe you could show how to use
 > actions in links and in forms? this mechanism is the basis of stateful
 > ressources in Iliad.


Next thing that I want to do for the blog, is to have a Login and a
Register dialog...

Joachim.


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