Seaside on Squeak

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

Seaside on Squeak

Chris Muller-3
>>> Hm, I thought Tobias meant "run source.squeak.org's image with SS3
>>> code" rather than "move source.squeak.org's code to the SS3 servers".
>>
>> Porting SS3 from GemStone to Squeak would probably be harder than just
>> upgrading the existing code.
>>
>
> Have you actually looked at SS3?
> I develop SS3 in Squeak (and pharo and gemstone)
> and it always runs on Squeak (as long as Seaside does, for that matter).

Ok, I didn't know that.  I thought SS3 was targeted at GemStone.
You're saying it'll run on Squeak as-is, right now?

> Installer squeaksource
>    project: 'MetacelloRepository';
>    install: 'ConfigurationOfSqueakSource'.
>
> ((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'All'.
> "
>  Or without tests:
> ((Smalltalk classNamed: #'ConfigurationOfSqueakSource') project version: #bleedingEdge) load: 'Full'.

When I tried the above in trunk, it goes for a while before I get an
error which says:  " 'table is already defined in a subclass of nil'".
 Apparently while trying to load "WAEncoder" class...

In Squeak 4.4, is an immediate error.

> Have an image, see for yourself:
> https://dl.dropboxusercontent.com/u/14917452/SS3.zip
> http://localhost:8080/installSS
>
> You know, SS3 is one of the two only reasons I have made the
> Squeak/Seaside all-in-one images. It is as if nobody cared about
> seaside in the squeak world anymore.
> It actually upsets me a little bit.

Me too.  I think people have given up because Seaside has not been
reliably loadable on Squeak for a long time.  That's why I think it
would be good for us as a community to depend on a Squeak-based
web-site so we will keep it maintained like the trunk.

Squeak was a leader of web-dev tech in the early 2000's with Seaside.
But the irony about trying to keep Seaside accessible on all platforms
including Pharo is that it has became a huge, complex beast for all
platforms, and inaccessible on its original platform entirely.

You and I both have done work to try to keep Seaside 3.x loading and
working in Squeak.  Your script above doesn't work and now even my
SqueakMap script for Seaside 3.0.3 no longer works because someone
decided to delete all versions of Grease from SS3 without
understanding or caring about the impacts to Squeak.

(Sigh)  So, in some respects it almost seems easier to just take
charge of our own web-software destiny and fork our own Seaside, in
our own repositories than to beg for cooperation from, ahem, other
groups.

And maybe that is why I thought there may be a case for the good ol'e
days of SS2 on Seaside 2.x.  Much smaller and easier to install and
understand, just a few packages compared to 3.x.  I don't care, I just
think we need control because, if we don't, you can bet, in one week
it won't work anymore.

Maybe web guru's will speak up, I just think we need to do _something_
to wrest back control of our own software-destiny for web-development
for Squeak.  People want to build their OWN images from a base 4.4 /
4.5, not download a special all-in-one "Seaside" image..

Reply | Threaded
Open this post in threaded view
|

re: Seaside on Squeak

ccrraaiigg

> So, in some respects it almost seems easier to just take charge of
> our own web-software destiny and fork our own Seaside, in our own
> repositories than to beg for cooperation from, ahem, other groups.

     Yes.


-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)


Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-3
In reply to this post by Chris Muller-3
> You and I both have done work to try to keep Seaside 3.x loading and
> working in Squeak.  Your script above doesn't work and now even my
> SqueakMap script for Seaside 3.0.3 no longer works because someone
> decided to delete all versions of Grease from SS3 without
> understanding or caring about the impacts to Squeak.

Correction:  It seems there was just a hiccup or something on SS3, the
versions for Grease ARE there, but the registration changed from
"Grease" to "grease".

After fixing that in the SM script, I'm happy to report, Seaside 3.0.3
STILL loads into Squeak 4.4 and it even loads into trunk too.  :)

But that is not the Metacello version you did Tobias, which I guess
loads Seaside 3.1.x, so it's still behind.

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Paul DeBruicker
In reply to this post by Chris Muller-3
Chris Muller-3 wrote
 I think people have given up because Seaside has not been
reliably loadable on Squeak for a long time.  That's why I think it
would be good for us as a community to depend on a Squeak-based
web-site so we will keep it maintained like the trunk.
I thought that its been loadable if you use the canonical ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been maintained by the Seaside community.  Is that not the case?  

Using the canonical ConfigurationOfSeaside3 from here:

MCHttpRepository
        location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'
        user: ''
        password: ''

and running:

ConfigurationOfSeaside3 load.


works in the 4.4 All in one.



Chris Muller-3 wrote
(Sigh)  So, in some respects it almost seems easier to just take
charge of our own web-software destiny and fork our own Seaside, in
our own repositories than to beg for cooperation from, ahem, other
groups.
 
Just to be clear are you arguing that forking and maintaining a project, documentation, finding users and devs plus developing and integrating bugfixes, and creating improvements is easier or more desirable than fixing a build script every now and again?  

Chris Muller-3 wrote
People want to build their OWN images from a base 4.4 /
4.5, not download a special all-in-one "Seaside" image..
As I described above, loading Seaside into a 4.4 image is possible today.  The ConfigurationOfSqueakSource is broken. I'm not sure why.  But to say that Seaside doesn't load or is broken on Squeak  is inaccurate
Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Colin Putney-3
In reply to this post by Chris Muller-3



On Tue, Jan 14, 2014 at 5:54 PM, Chris Muller <[hidden email]> wrote:
 
Maybe web guru's will speak up, I just think we need to do _something_
to wrest back control of our own software-destiny for web-development
for Squeak.  People want to build their OWN images from a base 4.4 /
4.5, not download a special all-in-one "Seaside" image..

Meh. Don't worry about it. Seaside is obsolete anyway. 

Colin
 


Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

timrowledge

On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
> Meh. Don't worry about it. Seaside is obsolete anyway.

Really? I haven’t taken any interest in web development in ages; what’s the replacement for Seaside?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I am the computer your mother warned you about.



Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Colin Putney-3



On Tue, Jan 14, 2014 at 8:29 PM, tim Rowledge <[hidden email]> wrote:

On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
> Meh. Don't worry about it. Seaside is obsolete anyway.

Really? I haven’t taken any interest in web development in ages; what’s the replacement for Seaside?

It's not that there's a replacement. It's more that the problem it solves isn't a problem anymore.  Continuations were a brilliant way to manage apps that were basically dynamically generated web pages connected via links and forms. But Javascript runtimes have gotten way, way faster, more robust and more standardized in the last 10 years.  Modern web apps are more of a client-server model: the UI rendering and interface logic is all done in Javascript running in the browser, and it communicates with the server by shuttling JSON back and forth over HTTP. In that sort of a system, continuations don't provide any benefit, and the drawbacks start to become significant.

Colin


Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-3
In reply to this post by Paul DeBruicker
On Tue, Jan 14, 2014 at 6:32 PM, Paul DeBruicker <[hidden email]> wrote:

> Chris Muller-3 wrote
>>  I think people have given up because Seaside has not been
>> reliably loadable on Squeak for a long time.  That's why I think it
>> would be good for us as a community to depend on a Squeak-based
>> web-site so we will keep it maintained like the trunk.
>
> I thought that its been loadable if you use the canonical
> ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been
> maintained by the Seaside community.  Is that not the case?
>
> Using the canonical ConfigurationOfSeaside3 from here:
>
> MCHttpRepository
>         location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'
>         user: ''
>         password: ''
>
> and running:
>
> ConfigurationOfSeaside3 load.

That worked, thanks.  Can you tell me the expression to load exactly
version 3.1.0, even if stable is beyond that at some point in the
future?

> works in the 4.4 All in one.

And in trunk, great!

> Just to be clear are you arguing that forking and maintaining a project,
> documentation, finding users and devs plus developing and integrating
> bugfixes, and creating improvements is easier or more desirable than fixing
> a build script every now and again?

I had thought MC versions had been deleted from SS3 which were needed
for Seaside in Squeak.  I was wrong about that, but nothing was
showing on the Versions tab for a time and in the meantime I stupidly
expressed a not-very-well-thought-out knee-jerk response to secure a
loadable configuration.  My bad.

>> People want to build their OWN images from a base 4.4 /
>> 4.5, not download a special all-in-one "Seaside" image..
>
> As I described above, loading Seaside into a 4.4 image is possible today.
> The ConfigurationOfSqueakSource is broken. I'm not sure why.  But to say
> that Seaside doesn't load or is broken on Squeak  is inaccurate

Indeed, thanks for the clarification.

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-3
In reply to this post by Colin Putney-3
>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>
>> Really? I haven’t taken any interest in web development in ages; what’s
>> the replacement for Seaside?
>
>
> It's not that there's a replacement. It's more that the problem it solves
> isn't a problem anymore.  Continuations were a brilliant way to manage apps
> that were basically dynamically generated web pages connected via links and
> forms. But Javascript runtimes have gotten way, way faster, more robust and
> more standardized in the last 10 years.  Modern web apps are more of a
> client-server model: the UI rendering and interface logic is all done in
> Javascript running in the browser, and it communicates with the server by
> shuttling JSON back and forth over HTTP. In that sort of a system,
> continuations don't provide any benefit, and the drawbacks start to become
> significant.

Continuations were never good for UI design anyway.  Modal.

What about HTML / DOM, is it still relevant in 2014?

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Colin Putney-3



On Tue, Jan 14, 2014 at 10:10 PM, Chris Muller <[hidden email]> wrote:
 
Continuations were never good for UI design anyway.  Modal.

The *web* wasn't good for UI design back then. But if you were going to do dynamic web sites, continuations were a great way to go about it!
 
What about HTML / DOM, is it still relevant in 2014?

Yes, but  smart phones are really important now, so "responsive design" is the in thing: one UI that scales down to 3" phone and up to 30" monitors. 




Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Frank Shearar-3
In reply to this post by Chris Muller-3
On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:

>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>
>>> Really? I haven’t taken any interest in web development in ages; what’s
>>> the replacement for Seaside?
>>
>>
>> It's not that there's a replacement. It's more that the problem it solves
>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>> that were basically dynamically generated web pages connected via links and
>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>> more standardized in the last 10 years.  Modern web apps are more of a
>> client-server model: the UI rendering and interface logic is all done in
>> Javascript running in the browser, and it communicates with the server by
>> shuttling JSON back and forth over HTTP. In that sort of a system,
>> continuations don't provide any benefit, and the drawbacks start to become
>> significant.
>
> Continuations were never good for UI design anyway.  Modal.

I don't understand - what does UI modal-ness got to do with with
continuations? (Or: the whole of Squeak is fundamentally built on
continuations (Process, ContextPart).)

frank

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Göran Krampe
In reply to this post by Colin Putney-3
Hey!

On 01/15/2014 03:00 AM, Colin Putney wrote:

> On Tue, Jan 14, 2014 at 8:29 PM, tim Rowledge <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > Meh. Don't worry about it. Seaside is obsolete anyway.
>
>     Really? I haven’t taken any interest in web development in ages;
>     what’s the replacement for Seaside?
>
>
> It's not that there's a replacement. It's more that the problem it
> solves isn't a problem anymore.  Continuations were a brilliant way to
> manage apps that were basically dynamically generated web pages
> connected via links and forms. But Javascript runtimes have gotten way,
> way faster, more robust and more standardized in the last 10 years.
>   Modern web apps are more of a client-server model: the UI rendering
> and interface logic is all done in Javascript running in the browser,
> and it communicates with the server by shuttling JSON back and forth
> over HTTP. In that sort of a system, continuations don't provide any
> benefit, and the drawbacks start to become significant.
>
> Colin

And IMHO if you want the Seaside style of development (components, HTML
DSL without templates etc) Amber is what you want - it is the "modern
web" replacement for Seaside.

smalltalkhub.com being the prime example of it.

regards, Göran

PS. But Seaside-REST is still quite slick and useful for createing
RESTful backends. But that is probably easy to split out from the rest
of Seaside.

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Colin Putney-3



On Wed, Jan 15, 2014 at 8:51 AM, Göran Krampe <[hidden email]> wrote:
 
And IMHO if you want the Seaside style of development (components, HTML DSL without templates etc) Amber is what you want - it is the "modern web" replacement for Seaside.

Yes, exactly. 



Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-3
In reply to this post by Frank Shearar-3
Frank, by my limited knowledge, the call: / answer API of Seaside used
a Continuation to allow a modal component to be rendered on top of
other components until #answer: is sent by one of the callbacks.  That
provides stateless web-apps the ability to do desktop-like modal
"dialog" boxes that can return values to the calling component.

On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote:

> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>
>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>> the replacement for Seaside?
>>>
>>>
>>> It's not that there's a replacement. It's more that the problem it solves
>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>> that were basically dynamically generated web pages connected via links and
>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>> more standardized in the last 10 years.  Modern web apps are more of a
>>> client-server model: the UI rendering and interface logic is all done in
>>> Javascript running in the browser, and it communicates with the server by
>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>> continuations don't provide any benefit, and the drawbacks start to become
>>> significant.
>>
>> Continuations were never good for UI design anyway.  Modal.
>
> I don't understand - what does UI modal-ness got to do with with
> continuations? (Or: the whole of Squeak is fundamentally built on
> continuations (Process, ContextPart).)
>
> frank
>

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Frank Shearar-3
Yes, I know. But that just means that implementing a bad idea (modal
dialogs) with some random piece of tech (continuations) is a bad idea.

I thought you meant that continuations _implied_ something negative
about UI design by their very nature. But it sounds like that's not
what you meant. Which is good :).

frank

On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote:

> Frank, by my limited knowledge, the call: / answer API of Seaside used
> a Continuation to allow a modal component to be rendered on top of
> other components until #answer: is sent by one of the callbacks.  That
> provides stateless web-apps the ability to do desktop-like modal
> "dialog" boxes that can return values to the calling component.
>
> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote:
>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>
>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>> the replacement for Seaside?
>>>>
>>>>
>>>> It's not that there's a replacement. It's more that the problem it solves
>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>> that were basically dynamically generated web pages connected via links and
>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>> client-server model: the UI rendering and interface logic is all done in
>>>> Javascript running in the browser, and it communicates with the server by
>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>> significant.
>>>
>>> Continuations were never good for UI design anyway.  Modal.
>>
>> I don't understand - what does UI modal-ness got to do with with
>> continuations? (Or: the whole of Squeak is fundamentally built on
>> continuations (Process, ContextPart).)
>>
>> frank
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Tobias Pape
In reply to this post by Chris Muller-3

On 15.01.2014, at 03:42, Chris Muller <[hidden email]> wrote:

> On Tue, Jan 14, 2014 at 6:32 PM, Paul DeBruicker <[hidden email]> wrote:
>> Chris Muller-3 wrote
>>> I think people have given up because Seaside has not been
>>> reliably loadable on Squeak for a long time.  That's why I think it
>>> would be good for us as a community to depend on a Squeak-based
>>> web-site so we will keep it maintained like the trunk.
>>
>> I thought that its been loadable if you use the canonical
>> ConfigurationOfSeaside3 (or ConfigurationOfSeaside30) that has been
>> maintained by the Seaside community.  Is that not the case?
>>
>> Using the canonical ConfigurationOfSeaside3 from here:
>>
>> MCHttpRepository
>>        location: 'http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'
>>        user: ''
>>        password: ''
>>
>> and running:
>>
>> ConfigurationOfSeaside3 load.
>
> That worked, thanks.  Can you tell me the expression to load exactly
> version 3.1.0, even if stable is beyond that at some point in the
> future?
(ConfigurationOfSeaside3 project version: '3.1.0') load.

Best
        -Tobias




signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-4
In reply to this post by Frank Shearar-3
Continuations are also bad because they leave Mutex's in their wait
state.  That, alone, is a show-stopper for me for using continuations.

On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote:

> Yes, I know. But that just means that implementing a bad idea (modal
> dialogs) with some random piece of tech (continuations) is a bad idea.
>
> I thought you meant that continuations _implied_ something negative
> about UI design by their very nature. But it sounds like that's not
> what you meant. Which is good :).
>
> frank
>
> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote:
>> Frank, by my limited knowledge, the call: / answer API of Seaside used
>> a Continuation to allow a modal component to be rendered on top of
>> other components until #answer: is sent by one of the callbacks.  That
>> provides stateless web-apps the ability to do desktop-like modal
>> "dialog" boxes that can return values to the calling component.
>>
>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote:
>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>>
>>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>>> the replacement for Seaside?
>>>>>
>>>>>
>>>>> It's not that there's a replacement. It's more that the problem it solves
>>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>>> that were basically dynamically generated web pages connected via links and
>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>>> client-server model: the UI rendering and interface logic is all done in
>>>>> Javascript running in the browser, and it communicates with the server by
>>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>>> significant.
>>>>
>>>> Continuations were never good for UI design anyway.  Modal.
>>>
>>> I don't understand - what does UI modal-ness got to do with with
>>> continuations? (Or: the whole of Squeak is fundamentally built on
>>> continuations (Process, ContextPart).)
>>>
>>> frank
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Tobias Pape

On 15.01.2014, at 17:30, Chris Muller <[hidden email]> wrote:

> Continuations are also bad because they leave Mutex's in their wait
> state.  That, alone, is a show-stopper for me for using continuations.

They do what?
Where? Can you enlighten me there…

Best
        -Tobias




signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Frank Shearar-3
In reply to this post by Chris Muller-4
No they don't. Continuations have nothing to with mutexes at all. I'm
not sure that we're talking about the same thing when we say
"continuation".

When _I_ say "continuation" I mean, effectively, the call stack: it's
the thing to which the result of the current activation record will
return a result. You can thus consider a _delimited_ continuation as a
chunk of stack. #on:do: delimits the stack using a primitive (19?). An
_undelimited_ continuation is the entire call stack from the very
beginning of a program. thisContext + all its senders is the closest
we have to such a thing in Smalltalk: since all call stacks eventually
hit nil, they're all delimited by _something_.

And we use continuations _all the time_ in Smalltalk, or things that
may be trivially expressed in delimited continuations: from a CS
perspective delimited continuations and resumable exceptions are
equivalent, in the sense that each may implement the other.

frank

On 15 January 2014 16:30, Chris Muller <[hidden email]> wrote:

> Continuations are also bad because they leave Mutex's in their wait
> state.  That, alone, is a show-stopper for me for using continuations.
>
> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote:
>> Yes, I know. But that just means that implementing a bad idea (modal
>> dialogs) with some random piece of tech (continuations) is a bad idea.
>>
>> I thought you meant that continuations _implied_ something negative
>> about UI design by their very nature. But it sounds like that's not
>> what you meant. Which is good :).
>>
>> frank
>>
>> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote:
>>> Frank, by my limited knowledge, the call: / answer API of Seaside used
>>> a Continuation to allow a modal component to be rendered on top of
>>> other components until #answer: is sent by one of the callbacks.  That
>>> provides stateless web-apps the ability to do desktop-like modal
>>> "dialog" boxes that can return values to the calling component.
>>>
>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote:
>>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>>>
>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>>>> the replacement for Seaside?
>>>>>>
>>>>>>
>>>>>> It's not that there's a replacement. It's more that the problem it solves
>>>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>>>> that were basically dynamically generated web pages connected via links and
>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>>>> client-server model: the UI rendering and interface logic is all done in
>>>>>> Javascript running in the browser, and it communicates with the server by
>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>>>> significant.
>>>>>
>>>>> Continuations were never good for UI design anyway.  Modal.
>>>>
>>>> I don't understand - what does UI modal-ness got to do with with
>>>> continuations? (Or: the whole of Squeak is fundamentally built on
>>>> continuations (Process, ContextPart).)
>>>>
>>>> frank
>>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Seaside on Squeak

Chris Muller-3
I was talking about class Continuation and how its used in the context
of Seaside.  In that context, I have observed, for example, a critical
block being entered prior to snipping a Continuation off the stack (to
be resumed later), thus leaving Mutex's on the stack stuck in their
wait state, and blocking subsequent requests.

On Wed, Jan 15, 2014 at 11:23 AM, Frank Shearar <[hidden email]> wrote:

> No they don't. Continuations have nothing to with mutexes at all. I'm
> not sure that we're talking about the same thing when we say
> "continuation".
>
> When _I_ say "continuation" I mean, effectively, the call stack: it's
> the thing to which the result of the current activation record will
> return a result. You can thus consider a _delimited_ continuation as a
> chunk of stack. #on:do: delimits the stack using a primitive (19?). An
> _undelimited_ continuation is the entire call stack from the very
> beginning of a program. thisContext + all its senders is the closest
> we have to such a thing in Smalltalk: since all call stacks eventually
> hit nil, they're all delimited by _something_.
>
> And we use continuations _all the time_ in Smalltalk, or things that
> may be trivially expressed in delimited continuations: from a CS
> perspective delimited continuations and resumable exceptions are
> equivalent, in the sense that each may implement the other.
>
> frank
>
> On 15 January 2014 16:30, Chris Muller <[hidden email]> wrote:
>> Continuations are also bad because they leave Mutex's in their wait
>> state.  That, alone, is a show-stopper for me for using continuations.
>>
>> On Wed, Jan 15, 2014 at 10:14 AM, Frank Shearar <[hidden email]> wrote:
>>> Yes, I know. But that just means that implementing a bad idea (modal
>>> dialogs) with some random piece of tech (continuations) is a bad idea.
>>>
>>> I thought you meant that continuations _implied_ something negative
>>> about UI design by their very nature. But it sounds like that's not
>>> what you meant. Which is good :).
>>>
>>> frank
>>>
>>> On 15 January 2014 15:56, Chris Muller <[hidden email]> wrote:
>>>> Frank, by my limited knowledge, the call: / answer API of Seaside used
>>>> a Continuation to allow a modal component to be rendered on top of
>>>> other components until #answer: is sent by one of the callbacks.  That
>>>> provides stateless web-apps the ability to do desktop-like modal
>>>> "dialog" boxes that can return values to the calling component.
>>>>
>>>> On Wed, Jan 15, 2014 at 2:34 AM, Frank Shearar <[hidden email]> wrote:
>>>>> On 15 January 2014 03:10, Chris Muller <[hidden email]> wrote:
>>>>>>>> On 14-01-2014, at 5:17 PM, Colin Putney <[hidden email]> wrote:
>>>>>>>> > Meh. Don't worry about it. Seaside is obsolete anyway.
>>>>>>>>
>>>>>>>> Really? I haven’t taken any interest in web development in ages; what’s
>>>>>>>> the replacement for Seaside?
>>>>>>>
>>>>>>>
>>>>>>> It's not that there's a replacement. It's more that the problem it solves
>>>>>>> isn't a problem anymore.  Continuations were a brilliant way to manage apps
>>>>>>> that were basically dynamically generated web pages connected via links and
>>>>>>> forms. But Javascript runtimes have gotten way, way faster, more robust and
>>>>>>> more standardized in the last 10 years.  Modern web apps are more of a
>>>>>>> client-server model: the UI rendering and interface logic is all done in
>>>>>>> Javascript running in the browser, and it communicates with the server by
>>>>>>> shuttling JSON back and forth over HTTP. In that sort of a system,
>>>>>>> continuations don't provide any benefit, and the drawbacks start to become
>>>>>>> significant.
>>>>>>
>>>>>> Continuations were never good for UI design anyway.  Modal.
>>>>>
>>>>> I don't understand - what does UI modal-ness got to do with with
>>>>> continuations? (Or: the whole of Squeak is fundamentally built on
>>>>> continuations (Process, ContextPart).)
>>>>>
>>>>> frank
>>>>>
>>>>
>

12