Re: [Pharo-users] Problem with ZnWebSocket and closed connections

[Sven Van Caekenberghe]

Hi Davide,

First I'll explain why you see a difference in behaviour, then I'll give you a 
solution.

Network connections are expensive resources, most servers try to close them as 
soon as possible when they are not used.

Zinc HTTP Components does not normally close connections by itself, although 
timeouts do naturally occur.

The WebSocket code normally loops on the server side when timeouts occur while 
waiting for incoming messages (more specifically in ZnWebSocket>>#runWith:). 
Note that even though it loops, there is no actual communication.

Both previous facts, not closing unused connections and looping on timeouts, 
result in a working echo/chat example, when run locally.

When you put a proxy in front of this, the proxy (like nginx) might decide to 
close an unused connection. This is allowed and it is what you are seeing. This 
is not an error and thus normal.

Of course, you might want to keep such connection open for longer, even if they 
are not used. This can be done by keeping them alive. Note however that this 
might result in many open connections.

How do you keep a connection alive ?

One solution is to do this at the application level. ZnWebSocketStatusHandler 
does this by sending a message every second.

The WebSocket protocol (https://tools.ietf.org/html/rfc6455) does define a 
number of control messages, all which were already implemented as such. Two of 
these messages, ping & pong, are meant to be used for implementing keep alive. 
Client side, this was already done (ZnWebSocket>>#handleControlFrame:).

I now added automatic keep alive message sending server side as well.

This can be seen in the updated implementation of ZnWebSocket>>#runWith: 

https://github.com/svenvc/zinc/commit/9073acc2fad197c2787c6cd0f4d315981ebb98b5

Now, whenever the read times out (as defined by the socket stream's timeout, a 
Zn setting), a ping control packet is sent to keep the connection alive, the 
client will answer with a pong, and then the server loops.

This should be sufficient to solve your issue (but both the proxy's as well as 
the Zn timeout need to be compatible, Zn's needs to be smaller).

Please let me know if this works for you.

Regards,

Sven

> On 23 Feb 2020, at 18:19, Davide Varvello via Pharo-users 
>  wrote:
> 
> 
> From: Davide Varvello 
> Subject: Re: Problem with ZnWebSocket and closed connections
> Date: 23 February 2020 at 18:19:02 GMT+1
> To: pharo-users@lists.pharo.org
> 
> 
> Hi,
> 
> I put nginx as a websocket proxy and I run the ZnWebSocketEchoHandler.
> Unfortunately also with this configuration the connection closes it after a
> couple of minutes of inactivity
> 
> Cheers
> Davide
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
> 
> 

[Pharo-users] [ANN] Next Pharo Sprint: Feb 28

[Marcus Denker]

We will organize a Pharo sprint / Moose dojo Feb 28, starting at

10:00am. (Local Time Paris). 

Goals of this sprint:

- Pharo 8: Fix issues from tracker 
https://github.com/pharo-project/pharo/issues

Remote Sprint: Remotely, you can join us on Discord. During the sprint, we 
synchronize local and remote Pharo sprinters:

http://pharo.org/contribute-events

We have added a Board to coordinate the work:
https://github.com/orgs/pharo-project/projects/9

Known Local Sprint meetings

- Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD 
offices). 
As the building is not open to the public, please contact us before if you plan 
to come

A list of all Pharo Event of the year an be found here: 
https://association.pharo.org/events

Re: [Pharo-users] [ANN] Round 3 Results Are In

[horrido]

Your critique is perfectly valid; I have no problem with it. Ben nicely
expanded on my point. Like I said, if I wanted to serve your purpose, then
yes, I'd make your video. Your critique would be very helpful.

This video didn't need a soundtrack either, but adding it made the video
immeasurably better:  Roassal3  
. Ditto for this video:  We Are Smalltalk   .

This video has utter silence and it simply does not work for me:  Virtual
Reality Live at Thales with Pharo
  .

The purpose of my video is to drum up excitement for JRMPC. I'm trying to
make JRMPC a special "event." I'm trying to make JRMPC look like a cool
contest. I hope people will be drawn into exploring this event further and
be exposed to Smalltalk. Perhaps then they'll give Smalltalk a try.

If they know nothing about Smalltalk, showing them the Pharo IDE in action
will have very little meaning. That's why I didn't do it. It didn't fit my
purpose.

I could be wrong, but I think a lot of people think this competition is
pretty cool. Mission accomplished.



Richard O'Keefe wrote
> There doesn't need to *be* a soundtrack.  Everyone can handle silence,
> no?  What purpose *does* the current video serve?
> 
> On Mon, 24 Feb 2020 at 07:42, horrido <

> horrido.hobbies@

> > wrote:
>>
>> My video serves one purpose; your video serves another. If I wanted to
>> serve
>> your purpose, then yes, I'd make your video.
>>
>> As to the sound track, the truth is, you can't choose one that appeals to
>> everyone. Musical tastes vary. I have no doubt that regardless of my
>> choice,
>> somebody will always have an issue with it.
>>
>>
>>
>> Richard O'Keefe wrote
>> > This is meant to be constructive, but won't seem that way at first.
>> >
>> > (1) The sound track very nearly drove me away in the first few seconds.
>> > I'm deadly serious about that.  I'm not on the spectrum, but my elder
>> > daughter is, and sensory sensitivities are very common amongst ASD
>> > people.  I'm rather sensitive to noise myself.  Now if the sound track
>> > were *relevant* to the message, I'd put up with it, but I can't for the
>> > life of me see any connection between the sound track banging away
>> > and what's happening on the screen.
>> >
>> > (2) Above all, it was a *missed opportunity*.  Here was the chance to
>> > add a narration telling us what we are seeing and what it all *means*.
>> > Something not unlike Code Bullet, maybe?
>> > https://www.youtube.com/watch?v=WSW-5m8lRMs
>> >
>> > (3) I don't give a tinker's curse for the score.  It's just a number
>> > without
>> > any context.  The scores for *all* the teams might be more interesting.
>> > The numbers that really matter are TIME, EFFORT, and SIZE.  How
>> > long did it take each team?  How much code did they end up with?  How
>> > much were they able to re-use?  How many false starts had to be thrown
>> > away?
>> >
>> > (4) The other missed opportunity was the chance to show some of the
>> > Pharo IDE in action.  Click on a cell, bring up the halo, explore the
>> > data structure, show some code, jump around in it.
>> >
>> > As it is, this clip shows me
>> >  - unknown code
>> >  - solving an unfamiliar problem
>> >  - written by people I know nothing about
>> >  - using unknown tools
>> >  - with no evidence that Smalltalk helped in any way.
>> >
>> > If I were a Blub programmer, I'd probably ignore this
>> > completely.  At best, I'd look for the problem specification,
>> > then say "who cares, I can do that easily in Blub".
>> >
>> > If you want to show that Smalltalk is the best thing since
>> > sliced cheese, you have to show that *Smalltalk* is relevant
>> > in some way.
>> >
>> >
>> > On Sun, 23 Feb 2020 at 03:53, Richard Kenneth Eng
>> > <
>>
>> > horrido.hobbies@
>>
>> > > wrote:
>> >>
>> >> https://www.youtube.com/watch?v=iNyu-3Y2arg
>> >>
>> >> This time, the teams must deal with Jump cells, Warp cells, and Death
>> >> cells. If you land on a Death cell, you die and the simulation
>> >> terminates.
>> >>
>> >> Next week is the most exciting round yet. Multiple teams will be
>> >> competing on the same board! This will look so damn cool on YouTube.
>> >>
>> >> Richard
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Problem with ZnWebSocket and closed connections

[Davide Varvello via Pharo-users]

--- Begin Message ---
Hi Sven,
Thanks for your reply.
I supposed that the ping/pong feature would have helped (I'm not an expert,
but I found something about it on the net).
Tomorrow I'm gonna try your updated runWith: and I'll feedback you.

Thanks
Davide


Sven Van Caekenberghe-2 wrote
> Hi Davide,
> 
> First I'll explain why you see a difference in behaviour, then I'll give
> you a solution.
> 
> Network connections are expensive resources, most servers try to close
> them as soon as possible when they are not used.
> 
> Zinc HTTP Components does not normally close connections by itself,
> although timeouts do naturally occur.
> 
> The WebSocket code normally loops on the server side when timeouts occur
> while waiting for incoming messages (more specifically in
> ZnWebSocket>>#runWith:). Note that even though it loops, there is no
> actual communication.
> 
> Both previous facts, not closing unused connections and looping on
> timeouts, result in a working echo/chat example, when run locally.
> 
> When you put a proxy in front of this, the proxy (like nginx) might decide
> to close an unused connection. This is allowed and it is what you are
> seeing. This is not an error and thus normal.
> 
> Of course, you might want to keep such connection open for longer, even if
> they are not used. This can be done by keeping them alive. Note however
> that this might result in many open connections.
> 
> How do you keep a connection alive ?
> 
> One solution is to do this at the application level.
> ZnWebSocketStatusHandler does this by sending a message every second.
> 
> The WebSocket protocol (https://tools.ietf.org/html/rfc6455) does define a
> number of control messages, all which were already implemented as such.
> Two of these messages, ping & pong, are meant to be used for implementing
> keep alive. Client side, this was already done
> (ZnWebSocket>>#handleControlFrame:).
> 
> I now added automatic keep alive message sending server side as well.
> 
> This can be seen in the updated implementation of ZnWebSocket>>#runWith: 
> 
> https://github.com/svenvc/zinc/commit/9073acc2fad197c2787c6cd0f4d315981ebb98b5
> 
> Now, whenever the read times out (as defined by the socket stream's
> timeout, a Zn setting), a ping control packet is sent to keep the
> connection alive, the client will answer with a pong, and then the server
> loops.
> 
> This should be sufficient to solve your issue (but both the proxy's as
> well as the Zn timeout need to be compatible, Zn's needs to be smaller).
> 
> Please let me know if this works for you.
> 
> Regards,
> 
> Sven
> 
>> On 23 Feb 2020, at 18:19, Davide Varvello via Pharo-users <

> pharo-users@.pharo

> > wrote:
>> 
>> 
>> From: Davide Varvello <

> varvello@

> >
>> Subject: Re: Problem with ZnWebSocket and closed connections
>> Date: 23 February 2020 at 18:19:02 GMT+1
>> To: 

> pharo-users@.pharo

>> 
>> 
>> Hi,
>> 
>> I put nginx as a websocket proxy and I run the ZnWebSocketEchoHandler.
>> Unfortunately also with this configuration the connection closes it after
>> a
>> couple of minutes of inactivity
>> 
>> Cheers
>> Davide
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
>> 
>>





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

[Pharo-users] Loading Bootstrap in Pharo 8

[syzygy]

I am testing the new image of Pharo 8 (Pharo Contribution Jenkins) with
pre-installed seaside. When trying to load the Torsten Bootstrap:

Gofer new
 url: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main';
 package: 'ConfigurationOfBootstrap';
 load

(Smalltalk at: #ConfigurationOfBootstrap) project stableVersion load

I get the following error: Name not found: Seaside-Pharo-Development

My question is: is this supposed to work on Pharo 8?

Thank you,
Martin.




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] What is the difference between a form and a morph?

[Steve Quezadas]

Ben,

I checked, [Form] is inherited from class [DisplayMedium]. So in
smalltalk, the inheritence pattern is:
Object -> DisplayObject -> DisplayMedium -> Form

The inheritence pattern of ImageMorph is:
Object -> Morph -> ImageMorph

One does not inherit the other and is not a wrapper, at least in Pharo8

On Sun, Feb 23, 2020 at 10:11 PM Ben Coman  wrote:

> On Mon, 24 Feb 2020 at 04:31, Steve Quezadas  wrote:
>
>> I usually like to go through the source code to answer my own question,
>> but I can't tell by reading it.
>>
>> [Morph], from what I understand, deals with manipulating graphics on
>> smalltalk. But when I use ZnEasy to get a jpeg file, I notice that it
>> returns a [Form] and not a [Morph] to display a jpeg. Spec2 also wants
>> [Form] for displaying images rather than [Morph].
>>
>> So what is the difference between a [Form] and a [Morph] since they both
>> seem to deal with graphics?
>>
>
> I don't know the exact answer, but if you review method ImageMorph>>form
> you will see that the ImageMorph is a wrapper around a Form.
>
> So some simple differences that may be inferred.
> - Many morphs are not bitmaps.
> - Morphs are GUI elements, i.e. interact with mouse and keyboard
> - Forms are not GUI elements
> - Forms can be manipulated without displaying them.
>
> In some other graphics system, an analogy could be putting an image on a
> button and asking "what is the difference between an 'image' and a 'button'
> ?"
>
> wrt Spec2, Morph is one backend that Spec2 might use to display a Form,
> or Spec2 might display the Form using a GTK widget.
>
> cheers -ben
>

Re: [Pharo-users] [ANN] Next Pharo Sprint: Feb 28

[Steve Quezadas]

This is interesting. How many people usually go to these code sprint
things?

I am learning pharo and roassal and I perused Moose and it looks very
interesting!

On Mon, Feb 24, 2020 at 4:52 AM Marcus Denker 
wrote:

> We will organize a Pharo sprint / Moose dojo Feb 28, starting at
>
> 10:00am. (Local Time Paris).
>
> Goals of this sprint:
>
> - Pharo 8: Fix issues from tracker
> https://github.com/pharo-project/pharo/issues
>
> Remote Sprint: Remotely, you can join us on Discord. During the sprint, we
> synchronize local and remote Pharo sprinters:
>
> http://pharo.org/contribute-events
>
> We have added a Board to coordinate the work:
> https://github.com/orgs/pharo-project/projects/9
>
> Known Local Sprint meetings
>
> - Lille/France: It will be at the Inria Lille, Building B, third floor
> (RMoD offices).
> As the building is not open to the public, please contact us before if you
> plan to come
>
> A list of all Pharo Event of the year an be found here:
> https://association.pharo.org/events
>

Re: [Pharo-users] What is the difference between a form and a morph?

[Markus Stumptner]

Normally, there should not be an inheritance relationship between 
wrapper and wrappee, but I agree that describing Morphs as wrappers 
around Forms seems to miss the point. The notion of wrapper usually 
implies that there is little modification to the protocol of the 
wrappee, a wrapper should not need a lot of code. But Morphs are a 
completely different level of the architecture, with a large and complex 
protocol that's very different from Forms. So let's start again.


Forms are images (implemented as rectangular pixel arrays, as stated).

Morphs are the objects that describe how the graphical interface works, 
they control displaying (for which they use Forms), handling of user 
input (mouse clicks, dragging etc) and above all the internal structure 
of the interface (for example the different regions that make up a 
window on the screen are Morphs). Note that the user display side of the 
Pharo interface is handled by class DisplayScreen, which is a subclass 
of Form.  So the Morphs in the user interface display themselves by 
inserting their Forms in the proper places on the Form that is the 
internal representation of the screen.


So, as Subbu said, you don't convert Morphs to Forms, they serve 
different purposes.  Morphs (some Morphs) have instance variables that 
allow them to refer to the Form that they use for displaying.  Hope that 
helps a bit.


I note that all of this (plus some more) you can essentially get from 
the class comments of the two.


Markus

On 25/2/20 12:22 pm, Steve Quezadas wrote:

Ben,

I checked, [Form] is inherited from class [DisplayMedium]. So in
smalltalk, the inheritence pattern is:
Object -> DisplayObject -> DisplayMedium -> Form

The inheritence pattern of ImageMorph is:
Object -> Morph -> ImageMorph

One does not inherit the other and is not a wrapper, at least in Pharo8

On Sun, Feb 23, 2020 at 10:11 PM Ben Coman > wrote:


On Mon, 24 Feb 2020 at 04:31, Steve Quezadas mailto:steve...@gmail.com>> wrote:

I usually like to go through the source code to answer my own
question, but I can't tell by reading it.

[Morph], from what I understand, deals with manipulating
graphics on smalltalk. But when I use ZnEasy to get a jpeg
file, I notice that it returns a [Form] and not a [Morph] to
display a jpeg. Spec2 also wants [Form] for displaying images
rather than [Morph].

So what is the difference between a [Form] and a [Morph] since
they both seem to deal with graphics?


I don't know the exact answer, but if you review method
ImageMorph>>form
you will see that the ImageMorph is a wrapper around a Form.

So some simple differences that may be inferred.
- Many morphs are not bitmaps.
- Morphs are GUI elements, i.e. interact with mouse and keyboard
- Forms are not GUI elements
- Forms can be manipulated without displaying them.

In some other graphics system, an analogy could be putting an
image on a button and asking "what is the difference between an
'image' and a 'button' ?"

wrt Spec2, Morph is one backend that Spec2 might use to display a
Form,
or Spec2 might display the Form using a GTK widget.

cheers -ben