- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] Re: change n same words in browser with one action

by Igor Stasenko

On 29 September 2012 10:17, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2012-09-29, at 10:04, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >> I agree with Igor and want to add, that a newbie will not be disturbed by shortcuts and can use the dialogs. It is the normal way, if you learn a new system, you get to know one thing after the other and someday, you get to know the shortcuts and they help to work faster. >> >> As you can see in the screenshot (left side), the feature is documented. >> At the right side you can see, that it is not implemented ;.) >> >> Perhaps it is possible to implement it in one of the next releases? >> > > I don't think replacements on a textual basis make much sense: > > 1. methods are only a few lines of code, thus limiting the usefulness > of such replacements > 2. besides renaming temporaries, most renames should be applied to > other methods as well. For instance inst-var renames, or method renames.. > > Though I would like to see on-the-fly variable renaming. For instance as > soon as you start typing on the name of the variable definition it will > automatically rewrite all the other accesses to that variable in the current > method. But for that we need a decent AST-based text editor. > > So unless you are a pro-pharo-shortcut user, think about the time you > loose otherwise by point-and-clicking with your mouse ;), a little search > and replace dialog interaction won't add too much :) > no, Cami, with cmd-j you don't need to click and point. you just keep pressing cmd-j till all old occurrences is replaced with one which you over-typed. but i agree, that this feature has limited use in smalltalk code, knowing that most of methods is 1-liner and, i would say, if you need such thing, most of the times it is a sign that you violating DRY principle somehow and should really think how to refactor your code, instead of changing single variable name/expression 10 times. > best > cami -- Best regards, Igor Stasenko.

Sept. 29, 2012

Re: [Pharo-project] [Seaside] Re: change n same words in browser with one action

by Igor Stasenko

On 29 September 2012 07:28, Chris Muller <ma.chris.m(a)gmail.com> wrote: >>> You should not expect that -- Pharo used to have it but it was removed >>> in favor of a more mainstream editor look-and-feel -- so that it be >>> would more attractive to new users. Command+J / Control+J are just >>> two of several powerful code-editing capabilities Pharo originally >>> inherited from Squeak, along with my other favorites Command+E = >>> Exchange the last two selections and Command+[, (, {, or | = Surround >>> the highlighted text with that bracket-type pair. (not sure if those >>> are still there in Pharo). >> >> Now what would be really cool is to have a documentation about all >> those, and make them easily >> discoverable. I worked with Squeak long enough, and didn't saw >> anything close to that. >> I said that it is 'command-g' instead 'command-j' exactly because of >> that, because you never know... >> And for me it was always felt like: >> - let user discover shortcuts by pressing random key combinations and >> see what happens. >> And then tell me, what are the chances that people will understand >> what exactly cmd-j does without >> reading documentation? In 99% of cases it will be 'oh.. what was just happen' .. >> This is about "more attractive". >> And if you hiding knowledge behind sealed doors, don't be surprised >> that someone will come and build a new library with open doors, >> replacing yours. > > You didn't look hard enough -- it's under the "help" menu. Squeak 3.0 > is the earliest I have on my HD but.. yes, it was there then and its > still there now. Maybe i didn't look hard enough (well actually i did, cause i remember looking for the code which implements/introduces them).. Still since you cannot remember all shortcuts at once , unless they are catching your eye (in context menus/elsewhere), you tend to forget/not using them. What i can say about Pharo 2.0 today, that yes, a new shortcut is a bit alienating (because many you need to learn from scratch), but in other turn they are much easier to discover. And if you try Nautilus, you can figure, that you can do everything without even touching a mouse. I can hardly characterize this as "newbie-friendly"/anti-poweruser approach, but IMO it is much more friendly to power-users.. once you learn shortcuts, of course. Still, this is a work-in-progress, but i like the way guys doing it.. we'll see the end result once dust settles :) > Ok, I know you just forgot we miss you too Igor. ;) > but i cannot spend my time on everything, everywhere. I need to focus on stuff i do :) > I admire Pharo blazing new trails but notice a pattern in some of the > "gold" feedback from Pharo customers which worth taking to heart. > Like: > > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-May/064702.html > What can i say, it is of course not nice when you breaking old habits, unless you have a good reasons for doing so, and when you don't provide alternative(s). >> This is, what i think, happens with shortcuts changes in Pharo, except >> form those which was remapped. >> >>> Pharo favors _familiarity_ for new users somewhat at the cost of >>> productivity for its experienced users. It somewhat resembles eclipse >>> -- with pop-up dialogs and a seemingly "modal" philosophy. Squeak, by >>> constrast, has kept pushing the "simple-but-powerful" philosphy of its >>> IDE to near extremes. While it's less familiar for new uesrs, once >>> learned, general navigation and editing require _far fewer_ gestures. >>> >> Another thing, is that i first time hear that pharo is in favor of >> newcomers at expense of experienced users. >> I am not involved in changes to key bindings / shortcuts, but i doubt >> that people, who doing that, making changes having such strange aim. >> I think they are focused on making it good for newcomers and >> experienced users both. Otherwise i don't see much sense in doing this >> at all, and would be first who will be against it. > > Ok, glad to hear that. I would rather have the best system possible > than one with the most mainstream acceptance. i can say you, it has nothing to do with mainstream: it is just new people , who learned things differently, and of course their preferences influencing the choices they do. i , for instance, i a long-time windows user. And many things in squeak were alien to me, like using alt-key instead of control key for most of shortcuts. Still, it doesn't matters as long as they meeting two key criteria: - consistent - easy to learn. -- Best regards, Igor Stasenko.

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Sven Van Caekenberghe

On 29 Sep 2012, at 20:09, Igor Stasenko <siguctua(a)gmail.com> wrote: > In case of Zn server, apparently, it is not absolutely necessary to > bind socket(s) during startup phase, because image will function > properly with or without them. So deferring this action after startup > is finished, is the right way to do it. --- Name: Zinc-HTTP-SvenVanCaekenberghe.307 Author: SvenVanCaekenberghe Time: 29 September 2012, 9:00:49.72 pm UUID: 9387492b-daa2-4ebf-a49d-44950586bda3 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.306 Modified ZnServer class>>#startUp: to use a deferred startup action to start all registered servers; this should allow for normal error handling when something goes wrong initializing server sockets (thanks Igor Stasenko for the fix; thanks Denis Kudriashov for the error report) --- -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 29, 2012

Re: [Pharo-project] Fuel and Tanker in older Pharo images [WAS] Re: How to try Shapes and Gaucho?

by Mariano Martinez Peck

On Sat, Sep 29, 2012 at 8:32 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 September 2012 14:57, Fernando Olivero <fernando.olivero(a)usi.ch> > wrote: > > Cool! Thanks Mariano for the summary, and all the others for this > > much needed features! Looking forward to adopt such a process, to have > > a minimal Pharo image, customized to my needs. > > > > indeed, sometimes even i forgetting why we doing things we do.. > But we also have the Pharo vision document for that :) https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf > and then people who are poorly informed about our end goals, making > wrong assumptions > about where Pharo moves, bashing us for killing compatibility, > breaking what was not broken, etc etc > > So, Mariano's summary is good rehearsal of our aims :) > > > Fernando > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Sept. 29, 2012

Re: [Pharo-project] Fuel and Tanker in older Pharo images [WAS] Re: How to try Shapes and Gaucho?

by Igor Stasenko

On 29 September 2012 14:57, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Cool! Thanks Mariano for the summary, and all the others for this > much needed features! Looking forward to adopt such a process, to have > a minimal Pharo image, customized to my needs. > indeed, sometimes even i forgetting why we doing things we do.. and then people who are poorly informed about our end goals, making wrong assumptions about where Pharo moves, bashing us for killing compatibility, breaking what was not broken, etc etc So, Mariano's summary is good rehearsal of our aims :) > Fernando -- Best regards, Igor Stasenko.

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Igor Stasenko

On 29 September 2012 19:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Igor, > > On 29 Sep 2012, at 18:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 29 September 2012 14:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> Hello. >>> >>> I try it for latest pharo2.0 one click. Same results. I am on Windows 7. >>> >>> First I register ZnServer at workspace: >>> >>> server := ZnServer on: 10025. >>> server start. >>> server register >>> server isRunning & server isListening. >>> >>> Then save image. When I reopen image server is running. >>> Now if I run other application at same port and try to open pharo It will >>> closed with pharoDebug about anable to create socket. No chance to debug and >>> fix it. >>> >>> I think it is very bad behaviour because it make impossible to run my image >>> at different computers just because another application holds socket. >>> >>> There is one strange thing. When I open another ZnServer on another image >>> both images works nice. "server isRunning & server isListening." returns >>> true for both. >>> And same happens if I doing it from one single image. >>> It is possible to create two ZnServer's for same port. Only one accept >>> requests from webbrowser for example. But when I closed it another ZnServer >>> start accept requests. >>> I think I just don't know something about sockets but it looks very strange >>> to me. >> >> About sockets: only one process in system can listen for particular >> socket address. >> Others will fail if you try to bind to it. >> But there's a socket option "SO_REUSEADDR" which allows you to bind to >> same address, >> i don't remember, however what exactly mechanism happens when you doing this. >> >> About image startup: during image startup, if something bad happens, >> it should capture a postmortem >> error and show you it with debugger once startup finished. >> But this style of error catching is enabled only for a Process which >> executing actual startup, >> not for any other [forked] processes, of course. >> If any of such process (like ZnServer) getting control before startup >> phase finished and throws the unhandled exception there, it will quit >> to OS. This is what you actually observing, because ZnServer lacks any >> exception handler in its #listenLoop : > > Hmm, not really, it lacks error handling around the creation of the server socket, > not further down in #listenLoop. > >> ZnSingleThreadedServer>>start >> "Start me. I will start listening on my port for incoming HTTP connections. >> If I am running, I will first stop and thus effectively restart" >> >> self stop. >> self log info: [ 'Starting ', self serverProcessName ]. >> self class default = self ifTrue: [ self register ]. >> process := [ [ self listenLoop ] repeat ] >> forkAt: Processor highIOPriority >> named: self serverProcessName >> >> >> The way how to fix that: >> >> - put an exception handler , and handle all exceptions not letting ui >> manager default error handler >> to decide what to do for you. > > I am not sure that is a good idea: the error has to be reported. no ? > Else we get a silent failure. > of course, it depends on the specific case. in case of ZnServer, this might be not a good idea. But i just described why it happens and how to prevent it. >> - defer initiating/rebinding socket connections untill a system will >> finish startup using >> Smalltalk addDeferredStartupAction: [ .... ] like following: >> >> >> ZnServer class >> startUp: resuming >> "Our system startUp hook: start all servers we manage" >> >> (resuming or: [ self alwaysRestart ]) >> ifTrue: [ >> Smalltalk addDeferredStartupAction: [ >> self managedServers do: [ :each | each start ] ] ] >> >> like that, >> if image runs headless, it will still quit to OS, since nobody >> handling the exception(s) when server cannot bind to specified port, >> while if you run image headful, it will open a debugger. > > OK, I didn't know about deferred startup actions, that sounds like a good idea indeed. > I'll try to add that. The rationale behind this is following: in startup you put things which is _absolutely neccessary_ for image to function properly. Like that, any registered service which failed to startup properly, renders an image invalid/non-functional, which of course means, that any error (if it happens) is unrecoverable, and it makes little sense to continue running image (since one of its basic services are faulted) and hence we the only choice we have is to quit graciously: dump error(s) to log and quitting to OS. (For example, imagine that event handling startup is failed, in this case you will get an unresponsive image, which don't reacts to any user input). What you will prefer: a log file , showing what happen, or unresponsive image without any clue what happens (and which you have to kill manually anyways)? In case of Zn server, apparently, it is not absolutely necessary to bind socket(s) during startup phase, because image will function properly with or without them. So deferring this action after startup is finished, is the right way to do it. Unless, again, you interested in running only image(s) which were able to successfully bound socket(s) to desired port(s). > > Thanks a lot for the input ! > > Sven > -- Best regards, Igor Stasenko.

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Sven Van Caekenberghe

Igor, On 29 Sep 2012, at 18:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 September 2012 14:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hello. >> >> I try it for latest pharo2.0 one click. Same results. I am on Windows 7. >> >> First I register ZnServer at workspace: >> >> server := ZnServer on: 10025. >> server start. >> server register >> server isRunning & server isListening. >> >> Then save image. When I reopen image server is running. >> Now if I run other application at same port and try to open pharo It will >> closed with pharoDebug about anable to create socket. No chance to debug and >> fix it. >> >> I think it is very bad behaviour because it make impossible to run my image >> at different computers just because another application holds socket. >> >> There is one strange thing. When I open another ZnServer on another image >> both images works nice. "server isRunning & server isListening." returns >> true for both. >> And same happens if I doing it from one single image. >> It is possible to create two ZnServer's for same port. Only one accept >> requests from webbrowser for example. But when I closed it another ZnServer >> start accept requests. >> I think I just don't know something about sockets but it looks very strange >> to me. > > About sockets: only one process in system can listen for particular > socket address. > Others will fail if you try to bind to it. > But there's a socket option "SO_REUSEADDR" which allows you to bind to > same address, > i don't remember, however what exactly mechanism happens when you doing this. > > About image startup: during image startup, if something bad happens, > it should capture a postmortem > error and show you it with debugger once startup finished. > But this style of error catching is enabled only for a Process which > executing actual startup, > not for any other [forked] processes, of course. > If any of such process (like ZnServer) getting control before startup > phase finished and throws the unhandled exception there, it will quit > to OS. This is what you actually observing, because ZnServer lacks any > exception handler in its #listenLoop : Hmm, not really, it lacks error handling around the creation of the server socket, not further down in #listenLoop. > ZnSingleThreadedServer>>start > "Start me. I will start listening on my port for incoming HTTP connections. > If I am running, I will first stop and thus effectively restart" > > self stop. > self log info: [ 'Starting ', self serverProcessName ]. > self class default = self ifTrue: [ self register ]. > process := [ [ self listenLoop ] repeat ] > forkAt: Processor highIOPriority > named: self serverProcessName > > > The way how to fix that: > > - put an exception handler , and handle all exceptions not letting ui > manager default error handler > to decide what to do for you. I am not sure that is a good idea: the error has to be reported. no ? Else we get a silent failure. > - defer initiating/rebinding socket connections untill a system will > finish startup using > Smalltalk addDeferredStartupAction: [ .... ] like following: > > > ZnServer class >> startUp: resuming > "Our system startUp hook: start all servers we manage" > > (resuming or: [ self alwaysRestart ]) > ifTrue: [ > Smalltalk addDeferredStartupAction: [ > self managedServers do: [ :each | each start ] ] ] > > like that, > if image runs headless, it will still quit to OS, since nobody > handling the exception(s) when server cannot bind to specified port, > while if you run image headful, it will open a debugger. OK, I didn't know about deferred startup actions, that sounds like a good idea indeed. I'll try to add that. Thanks a lot for the input ! Sven > -- > Best regards, > Igor Stasenko. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Sven Van Caekenberghe

Hi Denis, Thanks a lot for the testing and the error report; we need more Windows people. I just tested the same sequence on Mac OS X 10.8.2 with Pharo 20315 and for me the image never crashes when the port is already in use. It just doesn't work, the socket isValid but isListening is false because of the self serverSocket localPort = self port clause. The same about starting two servers on the same port in one image. Actually that is why I originally added the #isListening test. It all comes down to how the primitives are implemented, and for sockets they are for sure different on each platform. Sven On 29 Sep 2012, at 14:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I try it for latest pharo2.0 one click. Same results. I am on Windows 7. > > First I register ZnServer at workspace: > > server := ZnServer on: 10025. > server start. > server register > server isRunning & server isListening. > > Then save image. When I reopen image server is running. > Now if I run other application at same port and try to open pharo It will closed with pharoDebug about anable to create socket. No chance to debug and fix it. > > I think it is very bad behaviour because it make impossible to run my image at different computers just because another application holds socket. > > There is one strange thing. When I open another ZnServer on another image both images works nice. "server isRunning & server isListening." returns true for both. > And same happens if I doing it from one single image. > It is possible to create two ZnServer's for same port. Only one accept requests from webbrowser for example. But when I closed it another ZnServer start accept requests. > I think I just don't know something about sockets but it looks very strange to me. > > Best regards, > Denis > > 2012/9/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Mon, Sep 24, 2012 at 10:44 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > The behavior you are seeing is standard behavior for a headless image, are you running headless or not ? > > I think that if the problem comes from the startUp processing, this is the standard behavior whether it is headless or not. But I may be wrong.... > Igor/Esteban? I remember discussing this.... > > > On 24 Sep 2012, at 10:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > I am on Windows 7 > > > > 2012/9/24 Denis Kudriashov <dionisiydk(a)gmail.com> > > Ok, I will look at mails. > > > > In short: > > Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. > > It should close immediately. > > > > I have pharoDebug with > > THERE_BE_DRAGONS_HERE > > Error: Cannot create socket on port 10025 > > 24 September 2012 12:18:00.807 pm > > > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > > Image: Pharo1.4 [Latest update: #14456] > > > > > > > > 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Check the mailing-list because this was already discussed. > > igor and other spent time to streamline this process in particular in headless mode. > > > > So can you tell us a bit more what you are doing and when? > > > > Stef > > > > > >> Hello. > >> > >> I found very bad behaviour. > >> I use Pharo1.4. > >> And when there is some errors at startup Image just closed. It is horrible > >> > >> I have image with seaside application which open socket at startup. > >> So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. > >> > >> What you think about it? Is it fixed already at pharo 2.0? > >> > >> Best regards > >> Denis > > > On 24 Sep 2012, at 10:21, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > I am on Windows 7 > > > > 2012/9/24 Denis Kudriashov <dionisiydk(a)gmail.com> > > Ok, I will look at mails. > > > > In short: > > Start new seaside image. Add new zinc adaptor on port 10025 (for example). Save and close image. Block this port by firewall. Start image. > > It should close immediately. > > > > I have pharoDebug with > > THERE_BE_DRAGONS_HERE > > Error: Cannot create socket on port 10025 > > 24 September 2012 12:18:00.807 pm > > > > VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.161 uuid: 8e0c22c3-b48d-4d8d-a7f9-8a75dc246f28 Jul 11 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 8eb3f452262d1b213fd1b6fd3cb682e292945ccf Date: Mon Jul 9 15:23:19 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > > Image: Pharo1.4 [Latest update: #14456] > > > > > > > > 2012/9/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Check the mailing-list because this was already discussed. > > igor and other spent time to streamline this process in particular in headless mode. > > > > So can you tell us a bit more what you are doing and when? > > > > Stef > > > > > > > Hello. > > > > > > I found very bad behaviour. > > > I use Pharo1.4. > > > And when there is some errors at startup Image just closed. It is horrible > > > > > > I have image with seaside application which open socket at startup. > > > So when I move to another computer where this port is busy (or closed by firewall) Pharo opened and immediately closed. No chance to debug and fix it. > > > > > > What you think about it? Is it fixed already at pharo 2.0? > > > > > > Best regards > > > Denis -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Igor Stasenko

On 29 September 2012 18:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 September 2012 14:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> Hello. >> >> I try it for latest pharo2.0 one click. Same results. I am on Windows 7. >> >> First I register ZnServer at workspace: >> >> server := ZnServer on: 10025. >> server start. >> server register >> server isRunning & server isListening. >> >> Then save image. When I reopen image server is running. >> Now if I run other application at same port and try to open pharo It will >> closed with pharoDebug about anable to create socket. No chance to debug and >> fix it. >> >> I think it is very bad behaviour because it make impossible to run my image >> at different computers just because another application holds socket. >> >> There is one strange thing. When I open another ZnServer on another image >> both images works nice. "server isRunning & server isListening." returns >> true for both. >> And same happens if I doing it from one single image. >> It is possible to create two ZnServer's for same port. Only one accept >> requests from webbrowser for example. But when I closed it another ZnServer >> start accept requests. >> I think I just don't know something about sockets but it looks very strange >> to me. >> > > About sockets: only one process in system can listen for particular > socket address. > Others will fail if you try to bind to it. > But there's a socket option "SO_REUSEADDR" which allows you to bind to > same address, > i don't remember, however what exactly mechanism happens when you doing this. > > About image startup: during image startup, if something bad happens, > it should capture a postmortem > error and show you it with debugger once startup finished. > But this style of error catching is enabled only for a Process which > executing actual startup, > not for any other [forked] processes, of course. > If any of such process (like ZnServer) getting control before startup > phase finished and throws the unhandled exception there, it will quit > to OS. This is what you actually observing, because ZnServer lacks any > exception handler in its #listenLoop : > > > ZnSingleThreadedServer>>start > "Start me. I will start listening on my port for incoming HTTP connections. > If I am running, I will first stop and thus effectively restart" > > self stop. > self log info: [ 'Starting ', self serverProcessName ]. > self class default = self ifTrue: [ self register ]. > process := [ [ self listenLoop ] repeat ] > forkAt: Processor highIOPriority > named: self serverProcessName > > > The way how to fix that: > > - put an exception handler , and handle all exceptions not letting ui > manager default error handler > to decide what to do for you. > -- OR -- (but if you do both it won't hurt either ;) > - defer initiating/rebinding socket connections untill a system will > finish startup using > Smalltalk addDeferredStartupAction: [ .... ] like following: > > > ZnServer class >> startUp: resuming > "Our system startUp hook: start all servers we manage" > > (resuming or: [ self alwaysRestart ]) > ifTrue: [ > Smalltalk addDeferredStartupAction: [ > self managedServers do: [ :each | each start ] ] ] > > like that, > if image runs headless, it will still quit to OS, since nobody > handling the exception(s) when server cannot bind to specified port, > while if you run image headful, it will open a debugger. > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by Igor Stasenko

On 29 September 2012 14:39, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I try it for latest pharo2.0 one click. Same results. I am on Windows 7. > > First I register ZnServer at workspace: > > server := ZnServer on: 10025. > server start. > server register > server isRunning & server isListening. > > Then save image. When I reopen image server is running. > Now if I run other application at same port and try to open pharo It will > closed with pharoDebug about anable to create socket. No chance to debug and > fix it. > > I think it is very bad behaviour because it make impossible to run my image > at different computers just because another application holds socket. > > There is one strange thing. When I open another ZnServer on another image > both images works nice. "server isRunning & server isListening." returns > true for both. > And same happens if I doing it from one single image. > It is possible to create two ZnServer's for same port. Only one accept > requests from webbrowser for example. But when I closed it another ZnServer > start accept requests. > I think I just don't know something about sockets but it looks very strange > to me. > About sockets: only one process in system can listen for particular socket address. Others will fail if you try to bind to it. But there's a socket option "SO_REUSEADDR" which allows you to bind to same address, i don't remember, however what exactly mechanism happens when you doing this. About image startup: during image startup, if something bad happens, it should capture a postmortem error and show you it with debugger once startup finished. But this style of error catching is enabled only for a Process which executing actual startup, not for any other [forked] processes, of course. If any of such process (like ZnServer) getting control before startup phase finished and throws the unhandled exception there, it will quit to OS. This is what you actually observing, because ZnServer lacks any exception handler in its #listenLoop : ZnSingleThreadedServer>>start "Start me. I will start listening on my port for incoming HTTP connections. If I am running, I will first stop and thus effectively restart" self stop. self log info: [ 'Starting ', self serverProcessName ]. self class default = self ifTrue: [ self register ]. process := [ [ self listenLoop ] repeat ] forkAt: Processor highIOPriority named: self serverProcessName The way how to fix that: - put an exception handler , and handle all exceptions not letting ui manager default error handler to decide what to do for you. - defer initiating/rebinding socket connections untill a system will finish startup using Smalltalk addDeferredStartupAction: [ .... ] like following: ZnServer class >> startUp: resuming "Our system startUp hook: start all servers we manage" (resuming or: [ self alwaysRestart ]) ifTrue: [ Smalltalk addDeferredStartupAction: [ self managedServers do: [ :each | each start ] ] ] like that, if image runs headless, it will still quit to OS, since nobody handling the exception(s) when server cannot bind to specified port, while if you run image headful, it will open a debugger. -- Best regards, Igor Stasenko.

Sept. 29, 2012