Re: Tomcat or PHP in ST ?

On May 15, 4:16 am, "David Griswold" <[email protected]> wrote:
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Colin Putney
> > Sent: Monday, May 14, 2007 6:59 AM
> > To: [email protected]
> > Subject: Re: Tomcat or PHP in ST ?
>
> > On May 13, 2007, at 5:41 PM, prunedtree wrote:
>
> > > The issue is mainly that it uses dialect-specific code
> > > (thisContext...), not the semantics it uses.
>
> > Well, that's a bit misleading. thisContext was part of Smalltalk-80,
> > and is described in the Blue Book. It's only dialect-specific in that
> > some dialects don't conform to the Blue Book.
>
> > > There are going to be some limits to continuation support in
> > > strongtalk simply because strongtalk supports callbacks, and thus you
> > > can get volatile frames on the stack. Expecting that you can blindly
> > > serialize anything in a system that interacts with the external world
> > > doesn't sound like a good idea.
>
> > Blindly? Seaside's implementation of continuations is suited the
> > platform it runs on. On Squeak, activation contexts are uniform, and
> > the implementation is simple. If Strongtalk supported thisContext,
> > I'd expect the implementation would be more complicated, in order to
> > deal with calls in and out of foreign code.  That's fine. If only
> > stacks with purely Smalltalk contexts can be serialized, that's fine,
> > too. Gemstone implemented continuations with VM support as part of
> > their Seaside port. It seems to work fine.
>
> > Continuations aren't that scary, and Seaside/Strongtalk would be an
> > awfully nice combination.
>
> As a matter of design, Strongtalk attempts to separate the language from the
> 'system/environment' and reflective code, so syntax like thisContext is not
> supported, and all reflection on contexts and activations is done through
> 'mirrors' (an idea borrowed from Self).  So at the syntactic level this is
> one of the areas where Strongtalk is not Blue-book compatible, although
> there are mirror classes for reflecting on contexts and activations.
>
> So basically, you can think of Strongtalk as being Blue-Book compatible for
> non-reflective code, except where the library interfaces have been cleaned
> up to improve subtyping semantics (e.g. such as use of include: for
> collections instead of add:).
>
> For reflective code Strongtalk is almost completely *incompatible* with
> Blue-Book, except for a few of the most common things like
> Object>>isKindOf:, although most of the same reflective facilities are
> offered in other ways.  We simply didn't believe that reflective code
> belongs in the normal object interfaces.
>
> It's not clear yet what facilities the Strongtalk VM is missing that would
> be needed for manipulating activations.  They can be examined, but no one
> has looked into what is there for creating/modifying activations from
> Smalltalk.  It may be all there, but I suspect that the mutation side of the
> reflective interface is where the difficulties would lie.  I just don't have
> time to go look at this; anyone who wants to can go ahead.
>
> -Dave- Hide quoted text -
>
> - Show quoted text -

I think the main thing is to get something like Tomcat up and running.
I don't think continuations are important at all. I'm curious about
how difficult it will be to get a multithreaded application server for
ST. Does "supports native threads" mean you are writing C++ code to
implement a multithreaded server ?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---