- Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec: why is there an initialize in ClassMethodBrowser and none in MethodBrowser example?

by Benjamin

If you have questions, I will be glad to answer :) Ben On Feb 19, 2013, at 12:24 AM, phil(a)highoctane.be wrote: > Thanks. > > Still, when I do not have the initialize in the ClassMethodBrowser, > the thing doesn't work as the models aren't initialized properly. > > I'll check again. I am trying to recreate the example from scratch to > understand how all of this works. > > Regards, > Phil > > 2013/2/19 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: >> The initialise method should not exists anymore. >> >> Probably the rest of an old refactoring. >> >> The "right" way is to use initialize for initialising your inst var (other >> than sub widgets), >> initializeWidgets for initialising sub widgets (instantiate them, set them, >> etc) and >> initializePresenter to specify the interactions between sub widgets. >> >> Thanks for the report :) >> >> Ben >> >> On Feb 18, 2013, at 9:53 PM, phil(a)highoctane.be wrote: >> >> MethodBrowser works without that initialize (and uses >> initializeWidgets for the instantiation) where ClassMethodBrowser >> requires one (doesnt work without as models are nil). >> >> ClassMethodBrowser>>initialize >> "Initialization code for ClassMethodBrowser" >> >> super initialize. >> >> listModel := self instantiate: ListComposableModel. >> methodModel := self instantiate: MethodBrowser. >> >> self focusOrder >> add: listModel; >> add: methodModel. >> >> listModel whenSelectedItemChanged: [:selection | >> selection >> ifNotNil: [:class | >> methodModel methods: (class methodDict values sort: [:a :b | a >> selector < b selector]). >> methodModel listModel resetSelection ]]. >> >> methodModel wrapWith: [:method | method selector ]. >> >> And >> >> ClassMethodBrowser>>initializeWidgets >> >> self instantiateModels: #( >> listModel ListComposableModel >> methodModel MethodBrowser ). >> >> self focusOrder >> add: listModel; >> add: methodModel. >> >> methodModel displayBlock: [:method | method selector ]. >> >> has the instantiateModels. >> >> There seems to be a double instantiation in here... >> >> What is the right way to proceed? The Spec Report of June 2012 and the >> Spec tex thing in the SCM aren't right, so I wonder what the right way >> to do things is. >> >> TIA >> >> Phil >> >> >

Feb. 18, 2013

Re: [Pharo-users] Spec: why is there an initialize in ClassMethodBrowser and none in MethodBrowser example?

by phil＠highoctane.be

Thanks. Still, when I do not have the initialize in the ClassMethodBrowser, the thing doesn't work as the models aren't initialized properly. I'll check again. I am trying to recreate the example from scratch to understand how all of this works. Regards, Phil 2013/2/19 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > The initialise method should not exists anymore. > > Probably the rest of an old refactoring. > > The "right" way is to use initialize for initialising your inst var (other > than sub widgets), > initializeWidgets for initialising sub widgets (instantiate them, set them, > etc) and > initializePresenter to specify the interactions between sub widgets. > > Thanks for the report :) > > Ben > > On Feb 18, 2013, at 9:53 PM, phil(a)highoctane.be wrote: > > MethodBrowser works without that initialize (and uses > initializeWidgets for the instantiation) where ClassMethodBrowser > requires one (doesnt work without as models are nil). > > ClassMethodBrowser>>initialize > "Initialization code for ClassMethodBrowser" > > super initialize. > > listModel := self instantiate: ListComposableModel. > methodModel := self instantiate: MethodBrowser. > > self focusOrder > add: listModel; > add: methodModel. > > listModel whenSelectedItemChanged: [:selection | > selection > ifNotNil: [:class | > methodModel methods: (class methodDict values sort: [:a :b | a > selector < b selector]). > methodModel listModel resetSelection ]]. > > methodModel wrapWith: [:method | method selector ]. > > And > > ClassMethodBrowser>>initializeWidgets > > self instantiateModels: #( > listModel ListComposableModel > methodModel MethodBrowser ). > > self focusOrder > add: listModel; > add: methodModel. > > methodModel displayBlock: [:method | method selector ]. > > has the instantiateModels. > > There seems to be a double instantiation in here... > > What is the right way to proceed? The Spec Report of June 2012 and the > Spec tex thing in the SCM aren't right, so I wonder what the right way > to do things is. > > TIA > > Phil > >

Feb. 18, 2013

Re: [Pharo-users] Exception signaling and processes

by Norbert Hartl

Am 18.02.2013 um 23:38 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > An established connection can always disappear for any number of reasons. Just clean up and start over. One extra note. I think that is exactly what I'm trying to achieve. In order to cleanup you have to know when or you do it all the time. As I don't get a notice when the connection is no longer valid I try at certain moments to check the validity of the server socket. At that moment I like to have the chance to see it, clean up and start over. Norbert

Feb. 18, 2013

Re: [Pharo-users] Spec - openWithSpecLayout: vs. openWithSpec:

by Benjamin

opwnWithSpec: takes a selector as argument (the method which produce the SpecLayout instance when openWithSpecLayout: take the SpecLayout instance directly Maybe a refactor here is needed (the first one should maybe use the second one) Ben On Feb 18, 2013, at 11:48 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > What's the difference? > > > > -- > View this message in context: http://forum.world.st/Spec-openWithSpecLayout-vs-openWithSpec-tp4670560.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Feb. 18, 2013

Re: [Pharo-users] Spec: why is title on the class side for a ComposableModel

by Benjamin

Title is defined on both side. By default the instance side method points to the class side method. But you can override the instance side method without any problem :) (by example DualChangeSorterApplication redefine title according of the instance) Ben PS: if your title is dependent of the state of your model (by example title ^ self selectedMethod selector you can use self updateTitle to update the title) On Feb 18, 2013, at 10:18 PM, phil(a)highoctane.be wrote: > Why is the title of the ComposableModel on the class side? > > That's annoying if I need multiple windows each having a different > title when I do an openWithSpec. > > TIA > Phil >

Feb. 18, 2013

Re: [Pharo-users] Spec: why is there an initialize in ClassMethodBrowser and none in MethodBrowser example?

by Benjamin

The initialise method should not exists anymore. Probably the rest of an old refactoring. The "right" way is to use initialize for initialising your inst var (other than sub widgets), initializeWidgets for initialising sub widgets (instantiate them, set them, etc) and initializePresenter to specify the interactions between sub widgets. Thanks for the report :) Ben On Feb 18, 2013, at 9:53 PM, phil(a)highoctane.be wrote: > MethodBrowser works without that initialize (and uses > initializeWidgets for the instantiation) where ClassMethodBrowser > requires one (doesnt work without as models are nil). > > ClassMethodBrowser>>initialize > "Initialization code for ClassMethodBrowser" > > super initialize. > > listModel := self instantiate: ListComposableModel. > methodModel := self instantiate: MethodBrowser. > > self focusOrder > add: listModel; > add: methodModel. > > listModel whenSelectedItemChanged: [:selection | > selection > ifNotNil: [:class | > methodModel methods: (class methodDict values sort: [:a :b | a > selector < b selector]). > methodModel listModel resetSelection ]]. > > methodModel wrapWith: [:method | method selector ]. > > And > > ClassMethodBrowser>>initializeWidgets > > self instantiateModels: #( > listModel ListComposableModel > methodModel MethodBrowser ). > > self focusOrder > add: listModel; > add: methodModel. > > methodModel displayBlock: [:method | method selector ]. > > has the instantiateModels. > > There seems to be a double instantiation in here... > > What is the right way to proceed? The Spec Report of June 2012 and the > Spec tex thing in the SCM aren't right, so I wonder what the right way > to do things is. > > TIA > > Phil >

Feb. 18, 2013

Re: [Pharo-users] Exception signaling and processes

by Norbert Hartl

Sven, thanks for the answer. Comments inline! Am 18.02.2013 um 23:38 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Norbert, > > [ Continuing our private email conversation ] > > On 18 Feb 2013, at 17:55, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm doing a project using WebSockets at the moment and I have trouble making it work. I'm not sure I fully understand the problem. So here is my attempt in explaining what happens: >> >> A tablet computer connects via WebSocket to a pharo image. On connection time a session object is created and a little later a user is associated to that session object. On login time I check if the user is already logged in to another tablet. This is by checking any session that has a user associated. So far so good. >> >> In order to make the service reliable I test it by switching on/off the flight mode of the tablet just to simulate network problems. WebSockets use TCP and the problem appears that the server does not get notice that the connection went away. At the time the client reconnects it detects that there is an active session with a user and complains about it. >> >> Handling of sessions is automatic. There are exception handlers that remove bogus sessions automatically. In order to solve the inactive session problem I do the following: If I find a session with a particular user I try to access the socket so an exception will be triggered if the connection isn't valid anymore. Theoretically it would work. >> >> When accessing the socket the exception isn't signalled in my current process but in the process that created the socket (I'm not 100% sure of this). The other process is suspended so the signalling does not occur. My second check for a session therefor sees that it is still there. But shortly after my process returns control the other process runs and removes the session from the list while handling the exception. >> >> What would be a good way to tackle this? I tried a bit using yielding the active process, resuming the other process but all doesn't feel to be quite right to solve the problem. Is there a way to let the other process run or can I have the signalled exception in my current process? Anything else? >> >> Any hints appreciated. Thanks, >> >> Norbert > > The WebSocket protocol starts as a regular HTTP request/response that gets 'upgraded', which is fancy speak for the fact that the existing TCP connection used for that request/response is now being used as it is, with a new protocol. That means that in this initial request/response you can do anything that you can do with a normal HTTP request/response, including normal authentication and HTTP session management (typically using cookies). > > The main Zinc HTTP server spawns a new worker process for each HTTP connection. The WebSocket handler typically keeps on using that process by means of WebSocket>>#runWith: (but strictly speaking this does not have to be so, although any other approach is experimental). > > So yes, in the ZnWebSocketChatroomHandler example, and in your code as you describe it, at one point there will be two processes accessing a web socket: one reading, one writing. I don't think that has to be a problem, I have never seen exception being handled in the other process, but I can imagine that it could happen (who knows what's going on in the socket plugin, it certainly is different on all 3 major platforms). Since both will probably have a handler doing a cleanup, the result should be the same. > I'm not even sure that it is the case what I've described. It is really hard to debug and/or the be sure to draw the right conclusions. But at least I can read from your mail that you would expect the exception just to signal in the current process. That is what I've expected, too. It just doesn't happen. Anyone has some insights how this can happen? > Now, I think, from your descriptions, that you try to make too much of a problem from trying to control one client accessing the server twice. If the previous connection died somehow (and is cleaned up eventually), who cares ? This should be the same as a normal web app with a session and login semantics. HTTP semantics are typically such that the switch from one kept-alive connection to the next, or one session to the next happens transparently. > > The same should be possible with WebSockets. The initiative to create one lies with the client. An established connection can always disappear for any number of reasons. Just clean up and start over. The main trick/problem to me seems to be that you have to make this transparent in the client GUI. At the protocol level, I can't immediately see a problem. Like in any app, the same user could theoretically log in twice - as long as s/he is authenticated and access to internal shared data is dealt with correctly. > Agreed. Except the fact that having each user logged in only once is a requirement :) And I think that WebSockets being permanent are quite different from normal http connects. So, after seeing the odd signalling behaviour I wasn't sure if there are conditions where exceptions are signalled that way. At the moment I solve it in a way that in the conflict case the client is instructed to resend the logon command. In the meantime other processes run the signalling happens and on resend the bogus socket is gone. I just would like to do the same without reconnecting. Ah..and yes I would like to understand how this works/misbehaves. thanks, Norbert

Feb. 18, 2013

Spec - openWithSpecLayout: vs. openWithSpec:

by Sean P. DeNigris

What's the difference? -- View this message in context: http://forum.world.st/Spec-openWithSpecLayout-vs-openWithSpec-tp4670560.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 18, 2013

Re: [Pharo-users] Exception signaling and processes

by Sven Van Caekenberghe

Hi Norbert, [ Continuing our private email conversation ] On 18 Feb 2013, at 17:55, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm doing a project using WebSockets at the moment and I have trouble making it work. I'm not sure I fully understand the problem. So here is my attempt in explaining what happens: > > A tablet computer connects via WebSocket to a pharo image. On connection time a session object is created and a little later a user is associated to that session object. On login time I check if the user is already logged in to another tablet. This is by checking any session that has a user associated. So far so good. > > In order to make the service reliable I test it by switching on/off the flight mode of the tablet just to simulate network problems. WebSockets use TCP and the problem appears that the server does not get notice that the connection went away. At the time the client reconnects it detects that there is an active session with a user and complains about it. > > Handling of sessions is automatic. There are exception handlers that remove bogus sessions automatically. In order to solve the inactive session problem I do the following: If I find a session with a particular user I try to access the socket so an exception will be triggered if the connection isn't valid anymore. Theoretically it would work. > > When accessing the socket the exception isn't signalled in my current process but in the process that created the socket (I'm not 100% sure of this). The other process is suspended so the signalling does not occur. My second check for a session therefor sees that it is still there. But shortly after my process returns control the other process runs and removes the session from the list while handling the exception. > > What would be a good way to tackle this? I tried a bit using yielding the active process, resuming the other process but all doesn't feel to be quite right to solve the problem. Is there a way to let the other process run or can I have the signalled exception in my current process? Anything else? > > Any hints appreciated. Thanks, > > Norbert The WebSocket protocol starts as a regular HTTP request/response that gets 'upgraded', which is fancy speak for the fact that the existing TCP connection used for that request/response is now being used as it is, with a new protocol. That means that in this initial request/response you can do anything that you can do with a normal HTTP request/response, including normal authentication and HTTP session management (typically using cookies). The main Zinc HTTP server spawns a new worker process for each HTTP connection. The WebSocket handler typically keeps on using that process by means of WebSocket>>#runWith: (but strictly speaking this does not have to be so, although any other approach is experimental). So yes, in the ZnWebSocketChatroomHandler example, and in your code as you describe it, at one point there will be two processes accessing a web socket: one reading, one writing. I don't think that has to be a problem, I have never seen exception being handled in the other process, but I can imagine that it could happen (who knows what's going on in the socket plugin, it certainly is different on all 3 major platforms). Since both will probably have a handler doing a cleanup, the result should be the same. Now, I think, from your descriptions, that you try to make too much of a problem from trying to control one client accessing the server twice. If the previous connection died somehow (and is cleaned up eventually), who cares ? This should be the same as a normal web app with a session and login semantics. HTTP semantics are typically such that the switch from one kept-alive connection to the next, or one session to the next happens transparently. The same should be possible with WebSockets. The initiative to create one lies with the client. An established connection can always disappear for any number of reasons. Just clean up and start over. The main trick/problem to me seems to be that you have to make this transparent in the client GUI. At the protocol level, I can't immediately see a problem. Like in any app, the same user could theoretically log in twice - as long as s/he is authenticated and access to internal shared data is dealt with correctly. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 18, 2013

Spec: why is title on the class side for a ComposableModel

by phil＠highoctane.be

Why is the title of the ComposableModel on the class side? That's annoying if I need multiple windows each having a different title when I do an openWithSpec. TIA Phil

Feb. 18, 2013