April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Synchronous Spec

by roberto.minelli＠usi.ch

Thanks a lot. Now I'll try what you proposed! On Apr 30, 2013, at 12:33 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It actually acts exactly the same, just StandardWindow is hiding the complexity under the hood :) Which is actually a good thing :) > > If you want the same: > > | ui | > ui := MyUI new. > > World (or whatever morph) openModal: ui openWithSpec window. > > "you will arrive here at MyUI closing" > ui value (idk which info you want). > > > Another tip: > Every Spec widget can be opened in a window (with openWithSpec as you know) but can also be opened in a dialog window (with openDialogWithSpec). > > In this mode, in opens with a ok button and a cancel button, and the support for cancelling properly, and the state of the ok action is partially implemented. > All you need is to override > > MyUI>>initializeDialogWindow: aWindow (or something like this) > " here I have to register the ok action " > > aWindow okAction: [ self ok ]. > > MyUI>>ok > "Here is the action performed when ok is clicked. > Return false to cancel the ok, and leave the window open" > > text accept. > > "Here some random test" > (text text isEmpty or: [ text text = 'This field should not be empty' ]) > ifTrue: [ > text text: 'This field should not be empty'. > ^ false ]. > > returnedValue contents: (MyWrapper with: text text with: dropList selectedItem) > > > > Then you can do > > | ui | > ui := MyUI new. > > World openModal: ui openDialogWithSpec. > > ui returnedValue. "you will arrive here only once the dialog is validated and closed" > > I quickly wrote this example, but I think you can find more in the system (and I can provide you more examples as well) > (Note that in the second part, you do not need your own ok, cancel buttons) > > Ben > > On Apr 30, 2013, at 9:12 AM, roberto.minelli(a)usi.ch wrote: > >> Hi, >> >> As far as I understood, Spec is sort of asynchronous, let me explain. >> >> I implemented my ComposableModel (i.e., MyWindow) as a window with a TextModel, a DropList model, and two buttons: ok and cancel. >> >> The behavior I want to achieve is something that is easily doable with StandardWindow, something like >> >> name := StandardWindow new textEntry: 'Please enter a name'. >> >> Until the window stays open, the call does not return and once ok is pressed the result is stored in the 'name' variable. >> >> Now with Spec I've something like 'MyWindow new openWithSpec', but the call returns immediately. >> >> What is the best way to achieve such behavior? Thanks in advance. >> >> Cheers, >> Roberto >

April 30, 2013

Re: [Pharo-project] about Pharo 3.0 :)

by Igor Stasenko

On 30 April 2013 07:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I thought that Pharo 20 got a lot of improvements but when I see Pharo 30, > it feels like Pharo 30 is already a big step > forward. This is really positive energy. When fernando will arrive we will > move some efforts to Morphic > so thanks you all for this cool feeling. > > Stef > Yes, Opal opened doors for so many improvements... -- Best regards, Igor Stasenko.

April 30, 2013

[Pharo-project] Where are your package configs for Pharo 2.0

by Torsten Bergmann

I heard about RFB already working on Pharo 2.0 I heard about Seaside 3.0.8 already work in Pharo 2.0 I heard about SandstoneDB is now adopted for Pharo 2.0 I heard about ... already work in Pharo 2.0 ... So please: update your ConfigurationOfXXX and put working configs with a #stable definition for Pharo 2.0 into the writable http://ss3.gemstone.com/ss/MetaRepoForPharo20 repo so they show up on Config Browser and can be easily installed. Your packages and projects will never be visible if you hide them on ss, ss3 or SmalltalkHub. Also I hope for a Seaside 3.1 config for Pharo 2.0 which would really be a step forward ... Bye T.

April 30, 2013

Re: [Pharo-project] Synchronous Spec

by Benjamin

It actually acts exactly the same, just StandardWindow is hiding the complexity under the hood :) If you want the same: | ui | ui := MyUI new. World (or whatever morph) openModal: ui openWithSpec window. "you will arrive here at MyUI closing" ui value (idk which info you want). Another tip: Every Spec widget can be opened in a window (with openWithSpec as you know) but can also be opened in a dialog window (with openDialogWithSpec). In this mode, in opens with a ok button and a cancel button, and the support for cancelling properly, and the state of the ok action is partially implemented. All you need is to override MyUI>>initializeDialogWindow: aWindow (or something like this) " here I have to register the ok action " aWindow okAction: [ self ok ]. MyUI>>ok "Here is the action performed when ok is clicked. Return false to cancel the ok, and leave the window open" text accept. "Here some random test" (text text isEmpty or: [ text text = 'This field should not be empty' ]) ifTrue: [ text text: 'This field should not be empty'. ^ false ]. returnedValue contents: (MyWrapper with: text text with: dropList selectedItem) Then you can do | ui | ui := MyUI new. World openModal: ui openDialogWithSpec. ui returnedValue. "you will arrive here only once the dialog is validated and closed" I quickly wrote this example, but I think you can find more in the system (and I can provide you more examples as well) (Note that in the second part, you do not need your own ok, cancel buttons) Ben On Apr 30, 2013, at 9:12 AM, roberto.minelli(a)usi.ch wrote: > Hi, > > As far as I understood, Spec is sort of asynchronous, let me explain. > > I implemented my ComposableModel (i.e., MyWindow) as a window with a TextModel, a DropList model, and two buttons: ok and cancel. > > The behavior I want to achieve is something that is easily doable with StandardWindow, something like > > name := StandardWindow new textEntry: 'Please enter a name'. > > Until the window stays open, the call does not return and once ok is pressed the result is stored in the 'name' variable. > > Now with Spec I've something like 'MyWindow new openWithSpec', but the call returns immediately. > > What is the best way to achieve such behavior? Thanks in advance. > > Cheers, > Roberto

April 30, 2013

Re: [Pharo-project] RE : RE : cannot modify class comments on Linux

by Nicolas Cellier

Yes, you are right with current implementation. But if changes is not a code repository anymore, there is no need to record the position. So if we open in mode 'a' or 'a+', we could be back to an atomic primitive operation (if the primitive is blocking and can't fail/retry - which would be another option for async IO). If reading is restricted to recovery tool, the whole need for state-sharing-via-file will vanish. A readOnlyCopy/flush pair would perfectly work in this restricted case. The flush could eventually be triggered by the recovery tool itself. 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > Not so sure. Even with un-interruptible primitives, the RemoteString is > wrong. > > It should be something like write chunk in a lock, return chunk final > position once done. Then the RemoteString instance can compute the start > position and store it. No more race condition for that one. > > An, for anything which takes a readOnlyCopy, try to flush the RW one > before (or just remove that optimisation of opening multiple streams; > anything which tries to do data sharing via external files is asking for > trouble). > > Thierry > > > ------------------------------ > *De :* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Nicolas > Cellier [nicolas.cellier.aka.nice(a)gmail.com] > *Date d'envoi :* mardi 30 avril 2013 11:24 > *Ã :* Pharo Development > *Objet :* Re: [Pharo-project] RE : cannot modify class comments on Linux > > I think this was written with write once, read many restriction... > However, > - If the write stream would just append and not mess with position: > - And if the whole chunk was written in a single primitive call, > Then the write could still be safe, because primitive are currently > un-interruptible. > Otherwise, as for every shared ressource, proper locking should be used... > > But let's not do it: > Indeed, if the changes is no more a code repository, but just becomes a > failsafe change log, then we don't need anymore to log the content of code > we import (with MC or fileIn or other means...). > Logging the root action should be enough (MCLoaderOrSomething > loadFromURL: '....'!). > Thus, there would be no need for background logging, only the UI process > would log things and thus the write once model would be simple enough. > So, IMO, it's not usefull to waste cycles on something complex here. > Thoughts? > > Nicolas > > > 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > >> I confirm, it's 1) >> >> Adding a flush just before reopening the file R-O for the RemoteString >> instance solves this problem. However, this isn't obvious (i.e. the R-O >> opening is lazily triggered by another RemoteString method). >> >> I don't like, from a threading point of view, the RemoteString writing >> code. It takes the stream position before writing stuff in it, opening an >> opportunity window for a race condition. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik >> Johansen [henrik.s.johansen(a)veloxit.no] >> Date d'envoi : lundi 29 avril 2013 11:54 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] cannot modify class comments on Linux >> >> On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: >> >> > To be perfectly clear, does the bug occurs >> > 1) because we open a new file descriptor for read without flushing the >> old one for write, >> > 2) or does it occur with a single file descriptor opened 'rw' ? >> > >> > If 1), then this is probably our fault. >> > If 2), then I wouldn't expect such behavior. >> >> 1), different streams are used for reading/writing, to reduce threading >> errors in relation to position usage. >> RemoteStrings have an unusual tendency to jump around a lot in the >> streams they're linked to, which is no fun if you, say, try and write new >> source at the same time in a different thread. >> >> Cheers, >> Henry >> >> >

April 30, 2013

Re: [Pharo-project] RE : RE : cannot modify class comments on Linux

by Sven Van Caekenberghe

On 30 Apr 2013, at 11:55, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > It should be something like write chunk in a lock, return chunk final position once done. Then the RemoteString instance can compute the start position and store it. No more race condition for that one. Without knowing the details, I feel that it should work like that. Sven

April 30, 2013

[Pharo-project] RE : RE : cannot modify class comments on Linux

by GOUBIER Thierry

Not so sure. Even with un-interruptible primitives, the RemoteString is wrong. It should be something like write chunk in a lock, return chunk final position once done. Then the RemoteString instance can compute the start position and store it. No more race condition for that one. An, for anything which takes a readOnlyCopy, try to flush the RW one before (or just remove that optimisation of opening multiple streams; anything which tries to do data sharing via external files is asking for trouble). Thierry ________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Date d'envoi : mardi 30 avril 2013 11:24 Ã : Pharo Development Objet : Re: [Pharo-project] RE : cannot modify class comments on Linux I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used... But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts? Nicolas 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr<mailto:thierry.goubier@cea.fr>> I confirm, it's 1) Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method). I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] de la part de Henrik Johansen [henrik.s.johansen(a)veloxit.no<mailto:henrik.s.johansen@veloxit.no>] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Objet : Re: [Pharo-project] cannot modify class comments on Linux On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: > To be perfectly clear, does the bug occurs > 1) because we open a new file descriptor for read without flushing the old one for write, > 2) or does it occur with a single file descriptor opened 'rw' ? > > If 1), then this is probably our fault. > If 2), then I wouldn't expect such behavior. 1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry

April 30, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Igor Stasenko

On 30 April 2013 11:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>wrote: > I think this was written with write once, read many restriction... > However, > - If the write stream would just append and not mess with position: > - And if the whole chunk was written in a single primitive call, > Then the write could still be safe, because primitive are currently > un-interruptible. > Otherwise, as for every shared ressource, proper locking should be used... > > But let's not do it: > Indeed, if the changes is no more a code repository, but just becomes a > failsafe change log, then we don't need anymore to log the content of code > we import (with MC or fileIn or other means...). > Logging the root action should be enough (MCLoaderOrSomething loadFromURL: > '....'!). > Thus, there would be no need for background logging, only the UI process > would log things and thus the write once model would be simple enough. > So, IMO, it's not usefull to waste cycles on something complex here. > Thoughts? > > Just to say i have same thoughts: system should log only user's direct actions which causing changes, not every single change. > Nicolas > > > 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > >> I confirm, it's 1) >> >> Adding a flush just before reopening the file R-O for the RemoteString >> instance solves this problem. However, this isn't obvious (i.e. the R-O >> opening is lazily triggered by another RemoteString method). >> >> I don't like, from a threading point of view, the RemoteString writing >> code. It takes the stream position before writing stuff in it, opening an >> opportunity window for a race condition. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik >> Johansen [henrik.s.johansen(a)veloxit.no] >> Date d'envoi : lundi 29 avril 2013 11:54 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] cannot modify class comments on Linux >> >> On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: >> >> > To be perfectly clear, does the bug occurs >> > 1) because we open a new file descriptor for read without flushing the >> old one for write, >> > 2) or does it occur with a single file descriptor opened 'rw' ? >> > >> > If 1), then this is probably our fault. >> > If 2), then I wouldn't expect such behavior. >> >> 1), different streams are used for reading/writing, to reduce threading >> errors in relation to position usage. >> RemoteStrings have an unusual tendency to jump around a lot in the >> streams they're linked to, which is no fun if you, say, try and write new >> source at the same time in a different thread. >> >> Cheers, >> Henry >> >> > -- Best regards, Igor Stasenko.

April 30, 2013

Re: [Pharo-project] RE : cannot modify class comments on Linux

by Nicolas Cellier

I think this was written with write once, read many restriction... However, - If the write stream would just append and not mess with position: - And if the whole chunk was written in a single primitive call, Then the write could still be safe, because primitive are currently un-interruptible. Otherwise, as for every shared ressource, proper locking should be used... But let's not do it: Indeed, if the changes is no more a code repository, but just becomes a failsafe change log, then we don't need anymore to log the content of code we import (with MC or fileIn or other means...). Logging the root action should be enough (MCLoaderOrSomething loadFromURL: '....'!). Thus, there would be no need for background logging, only the UI process would log things and thus the write once model would be simple enough. So, IMO, it's not usefull to waste cycles on something complex here. Thoughts? Nicolas 2013/4/30 GOUBIER Thierry <thierry.goubier(a)cea.fr> > I confirm, it's 1) > > Adding a flush just before reopening the file R-O for the RemoteString > instance solves this problem. However, this isn't obvious (i.e. the R-O > opening is lazily triggered by another RemoteString method). > > I don't like, from a threading point of view, the RemoteString writing > code. It takes the stream position before writing stuff in it, opening an > opportunity window for a race condition. > > Thierry > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik > Johansen [henrik.s.johansen(a)veloxit.no] > Date d'envoi : lundi 29 avril 2013 11:54 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] cannot modify class comments on Linux > > On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: > > > To be perfectly clear, does the bug occurs > > 1) because we open a new file descriptor for read without flushing the > old one for write, > > 2) or does it occur with a single file descriptor opened 'rw' ? > > > > If 1), then this is probably our fault. > > If 2), then I wouldn't expect such behavior. > > 1), different streams are used for reading/writing, to reduce threading > errors in relation to position usage. > RemoteStrings have an unusual tendency to jump around a lot in the streams > they're linked to, which is no fun if you, say, try and write new source at > the same time in a different thread. > > Cheers, > Henry > >

April 30, 2013

[Pharo-project] RE : cannot modify class comments on Linux

by GOUBIER Thierry

I confirm, it's 1) Adding a flush just before reopening the file R-O for the RemoteString instance solves this problem. However, this isn't obvious (i.e. the R-O opening is lazily triggered by another RemoteString method). I don't like, from a threading point of view, the RemoteString writing code. It takes the stream position before writing stuff in it, opening an opportunity window for a race condition. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Henrik Johansen [henrik.s.johansen(a)veloxit.no] Date d'envoi : lundi 29 avril 2013 11:54 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] cannot modify class comments on Linux On Apr 26, 2013, at 8:06 PM, Nicolas Cellier wrote: > To be perfectly clear, does the bug occurs > 1) because we open a new file descriptor for read without flushing the old one for write, > 2) or does it occur with a single file descriptor opened 'rw' ? > > If 1), then this is probably our fault. > If 2), then I wouldn't expect such behavior. 1), different streams are used for reading/writing, to reduce threading errors in relation to position usage. RemoteStrings have an unusual tendency to jump around a lot in the streams they're linked to, which is no fun if you, say, try and write new source at the same time in a different thread. Cheers, Henry

April 30, 2013