September 2012 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Metacello bleedingEdge question

by Dale Henrichs

Stef, #latestVersion is there for backward compatibility. The #stable symbolic version is the preferred mechanism for declaring the "latest version". Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, September 28, 2012 11:37:30 AM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | dale | | at the end do we really need latestVersion because I'm still confused | by it. | | On Sep 28, 2012, at 3:42 PM, Dale Henrichs wrote: | | > #latestVersion is defined as the latest version whose blessing is | > neither #baseline nor #development. | | |

Sept. 29, 2012

[Pharo-project] [update 2.0] #20315

by Marcus Denker

20315 ----- Issue 6747: Unicode class has wrong CaseMapping http://code.google.com/p/pharo/issues/detail?id=6747 Issue 6696: Gofer Repository Improvements http://code.google.com/p/pharo/issues/detail?id=6696 Issue 5856: Add possiblity to skip a test http://code.google.com/p/pharo/issues/detail?id=5856 -- Marcus Denker -- http://marcusdenker.de

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 3:42 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Sep 29, 2012 at 2:20 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Sat, Sep 29, 2012 at 12:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: >> >>> 2012/9/29 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>>> >>>> >>>> On Fri, Sep 28, 2012 at 11:31 PM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> >>>>> Hello >>>>> >>>>> ss3 repo for Shapes and Gaucho closed for reading or maybe empty. >>>>> So is it possible to get it somewhere? maybe there is prepared image? >>>>> >>>>> Actually I gather migrate our applications to last Pharo and use >>>>> latest achievemens like fuel and tanker. >>>>> >>>> >>>> Hi. I don't want to go offtopic in the original thread so I opened this >>>> one. >>>> Of course it is usually a good idea to migrate to latest stable Pharo >>>> release so that you don't stay with a very old image. Anyway, what I wanted >>>> to say is that Fuel DOES WORK in previous images. In fact, it works from >>>> Pharo 1.1 to 2.0. And Tanker right now works in 2.0 only by just because >>>> by default we use the new ClassBuilder. But this can be easily changed for >>>> those who want to use it in older versions. Anyway, Tanker is still a >>>> little bit green ;) For more details read my answer to this comment: >>>> http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/#comm… >>>> >>> >>> Hello and thank's for response. >>> >>> Actually I want use Tanker to deploy my applications with "bootstrap >>> way" where only kernel minimal image existed and all application loaded at >>> startup. >>> It will simplify delivering application updates to slow remote targets. >>> I can just upload small tanker files and load it seamlessly because its >>> really fast. >>> And without image saves no corrupt images due to something bad at middle >>> of image save. >>> >> >> Hi Denis. I want to say a couple of things about this. First, you are not >> the only one wanting this. In fact, that scenario is one of the reasons we >> are investing a lot of time in the infrastructure: >> >> 1) Pavel Krivanek has been working a lot in making the image more >> modular, being able to cleanly unload and reload packages. This was the >> first step. >> 2) Jannik Laval continue that effort trying to remove lots of >> cyclic dependencies between packages. >> 3) Guillermo Polito started to work in the bootstrap. He is now able to >> bootstrap images from scratch (contrary to Pavel's PharoKernel where he was >> unloading packages). >> 4) Esteban Lorenzano is working on a new ConfigurationOfPharo that will >> let you take a kernel/bootstraped/minimal image and load just the packages >> you want. >> 5) Camilo Bruni, Martin Dias, Guillermo Polito, and Toon Verwaest have >> been working in a new class builder based on layouts. The "old >> ClassBuilder" is really difficult to maintain, understand, fix, etc. When >> you load packages, the class builder takes an important role. Therefore, >> they were working in a new class builder, which, from my point of view, is >> way better, object-oriented, tested, etc. >> 6) Martin Dias and Me were working in Tanker, a tool to export/import >> packages of code using Fuel without Compiler. >> >> > And the list can of course continue: > > 7) Dale did Metacello, which is a great package management system (needed > by 4) and for all the rest of the projects) > 8) Fuel, as it is needed by 6) > 9) RPackage also improves a lot the loading time (because it avoids the PackageInfo calculation...) > ..... > and so on... > > >> So.....as you can see there is/was a lot of work going on related to what >> you need :) It is not 100% ready, but we are getting there. >> >> Cheers, >> >> >>> Best regards, >>> Denis >>> >>> >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- 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 Mariano Martinez Peck

On Sat, Sep 29, 2012 at 2:20 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Sep 29, 2012 at 12:59 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > >> 2012/9/29 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >>> >>> >>> On Fri, Sep 28, 2012 at 11:31 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>> > wrote: >>> >>>> Hello >>>> >>>> ss3 repo for Shapes and Gaucho closed for reading or maybe empty. >>>> So is it possible to get it somewhere? maybe there is prepared image? >>>> >>>> Actually I gather migrate our applications to last Pharo and use latest >>>> achievemens like fuel and tanker. >>>> >>> >>> Hi. I don't want to go offtopic in the original thread so I opened this >>> one. >>> Of course it is usually a good idea to migrate to latest stable Pharo >>> release so that you don't stay with a very old image. Anyway, what I wanted >>> to say is that Fuel DOES WORK in previous images. In fact, it works from >>> Pharo 1.1 to 2.0. And Tanker right now works in 2.0 only by just because >>> by default we use the new ClassBuilder. But this can be easily changed for >>> those who want to use it in older versions. Anyway, Tanker is still a >>> little bit green ;) For more details read my answer to this comment: >>> http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/#comm… >>> >> >> Hello and thank's for response. >> >> Actually I want use Tanker to deploy my applications with "bootstrap way" >> where only kernel minimal image existed and all application loaded at >> startup. >> It will simplify delivering application updates to slow remote targets. I >> can just upload small tanker files and load it seamlessly because its >> really fast. >> And without image saves no corrupt images due to something bad at middle >> of image save. >> > > Hi Denis. I want to say a couple of things about this. First, you are not > the only one wanting this. In fact, that scenario is one of the reasons we > are investing a lot of time in the infrastructure: > > 1) Pavel Krivanek has been working a lot in making the image more modular, > being able to cleanly unload and reload packages. This was the first step. > 2) Jannik Laval continue that effort trying to remove lots of > cyclic dependencies between packages. > 3) Guillermo Polito started to work in the bootstrap. He is now able to > bootstrap images from scratch (contrary to Pavel's PharoKernel where he was > unloading packages). > 4) Esteban Lorenzano is working on a new ConfigurationOfPharo that will > let you take a kernel/bootstraped/minimal image and load just the packages > you want. > 5) Camilo Bruni, Martin Dias, Guillermo Polito, and Toon Verwaest have > been working in a new class builder based on layouts. The "old > ClassBuilder" is really difficult to maintain, understand, fix, etc. When > you load packages, the class builder takes an important role. Therefore, > they were working in a new class builder, which, from my point of view, is > way better, object-oriented, tested, etc. > 6) Martin Dias and Me were working in Tanker, a tool to export/import > packages of code using Fuel without Compiler. > > And the list can of course continue: 7) Dale did Metacello, which is a great package management system (needed by 4) and for all the rest of the projects) 8) Fuel, as it is needed by 6) ..... and so on... > So.....as you can see there is/was a lot of work going on related to what > you need :) It is not 100% ready, but we are getting there. > > Cheers, > > >> Best regards, >> Denis >> >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Sept. 29, 2012

[Pharo-project] [update 2.0] #20314

by Marcus Denker

20314 ----- Issue 6720: Improve Trait usage in Tools http://code.google.com/p/pharo/issues/detail?id=6720 -- Marcus Denker -- http://marcusdenker.de

Sept. 29, 2012