September 2012 - Pharo-users

Re: [Pharo-users] modal dialog

by StÃ©phane Ducasse

Florent We are not happy of the current design. UIManager allows us to control window request in headless mode. Now this is not really satisfactory. Facades are often bad smells to me. There is UITheme and othersâ¦ and the responsibilities are unclear. Now you do not have to subclass you can extend it. Still I'm not happy about the overall design. For example, some logic of the debugger building should be located in the Debugger class and not in UIManager or whatever class. This is why we are working on Spec and its UIBuilder and we want to rewrite all the tools. But it takes time. We will get there after 20 is out probably. Stef > Thank you, it works well ! I had seen openModal: but did not know how to use it. > > Sven, thank you too. I had seen the UIManager>>request: but was afraid to have to subclass such a class when in need for a simple special dialog design. > > Florent > > Date: Wed, 26 Sep 2012 16:57:14 -0300 > From: lemuus(a)gmail.com > To: pharo-users(a)lists.gforge.inria.fr > Subject: Re: [Pharo-users] modal dialog > > You can do something like this: > > dialog := TextEntryDialogWindow new. > World openModal: dialog. > dialog cancelled ifFalse: [self createAndWrite: dialog entryText]. > > but I am not sure if this is the correct way to do it. > -- > Daniel Galdames > > El miÃ©rcoles, 26 de septiembre de 2012 a las 15:58, Florent Arrignon escribiÃ³: > Hi Pharoers, > > I'm a beginner with Pharo and try to dive into Morph. My question is trivial as I want to open a modal dialog to catch some text and save it in a file. > > I use the following code: > dialog := TextEntryDialogWindow new. > dialog openInWorld. > dialog canceled ifFalse: [self createAndWrite: dialog entryText]. > > In Cincom Smalltalk, the same code opened a dialog modally , but here, not, as it seems suggested in the DialogWindow class comment. I don't know how to change this, I tried to include it as submorph in another morph, but it failed (still system modal). I also tried to tell currentWorld to set the ModalWindow to Dialog, without success. Any hint? > > Thank you > > Florent

Sept. 27, 2012

Welcome to newcomers

by StÃ©phane Ducasse

Hi guys Since there are regularly new comers, here is a little ad-hoc welcome message :). First: Welcome! welcome and welcome Second: our goal is to create an ecosystem around pharo: if you need material to teach, if you have idea or needs for business or anything else just let us know. Our goal is to be able to reinvent our system and at the same time make sure that we can all create wealth at all levels. Third: we are working hard to get our vision: a nice, little and powerful reflective system. If you want to understand what we are doing please read the document Pharo vision on http://www.pharo-project.org/community/consortium You will understand our current effort. Four: you can get an impact on Pharo :) There are a lot of different ways to contribute. - feedback - bugs idea for enhancements see http://code.google.com/p/pharo/issues/list - book participation (we are working on deep into pharo http://rmod.lille.inria.fr/pbe2/ - translation - adding comments - building great stuff - using packagesâ¦. So welcome. Stef PS: Pharo is not the end, Pharo is the mean to create a powerful clean, lean system with a great community.

Sept. 27, 2012

Re: [Pharo-users] modal dialog

by Florent Arrignon

Thank you, it works well ! I had seen openModal: but did not know how to use it. Sven, thank you too. I had seen the UIManager>>request: but was afraid to have to subclass such a class when in need for a simple special dialog design. Florent Date: Wed, 26 Sep 2012 16:57:14 -0300 From: lemuus(a)gmail.com To: pharo-users(a)lists.gforge.inria.fr Subject: Re: [Pharo-users] modal dialog You can do something like this: dialog := TextEntryDialogWindow new.World openModal: dialog.dialog cancelled ifFalse: [self createAndWrite: dialog entryText]. but I am not sure if this is the correct way to do it.-- Daniel Galdames El miÃ©rcoles, 26 de septiembre de 2012 a las 15:58, Florent Arrignon escribiÃ³: Hi Pharoers, I'm a beginner with Pharo and try to dive into Morph. My question is trivial as I want to open a modal dialog to catch some text and save it in a file. I use the following code: dialog := TextEntryDialogWindow new. dialog openInWorld. dialog canceled ifFalse: [self createAndWrite: dialog entryText]. In Cincom Smalltalk, the same code opened a dialog modally , but here, not, as it seems suggested in the DialogWindow class comment. I don't know how to change this, I tried to include it as submorph in another morph, but it failed (still system modal). I also tried to tell currentWorld to set the ModalWindow to Dialog, without success. Any hint? Thank you Florent

Sept. 26, 2012

Re: [Pharo-users] modal dialog

by Sven Van Caekenberghe

Hi Florent, On 26 Sep 2012, at 20:58, Florent Arrignon <florent_arrignon(a)hotmail.fr> wrote: > I'm a beginner with Pharo and try to dive into Morph. My question is trivial as I want to open a modal dialog to catch some text Maybe this is not what you are looking for, but a very easy way is like this: UIManager default request: 'Enter some text'. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 26, 2012

Re: [Pharo-users] modal dialog

by Daniel Galdames

You can do something like this: dialog := TextEntryDialogWindow new. World openModal: dialog. dialog cancelled ifFalse: [self createAndWrite: dialog entryText]. but I am not sure if this is the correct way to do it. -- Daniel Galdames El miÃ©rcoles, 26 de septiembre de 2012 a las 15:58, Florent Arrignon escribiÃ³: > Hi Pharoers, > > I'm a beginner with Pharo and try to dive into Morph. My question is trivial as I want to open a modal dialog to catch some text and save it in a file. > > I use the following code: > dialog := TextEntryDialogWindow new. > dialog openInWorld. > dialog canceled ifFalse: [self createAndWrite: dialog entryText]. > > In Cincom Smalltalk, the same code opened a dialog modally , but here, not, as it seems suggested in the DialogWindow class comment. I don't know how to change this, I tried to include it as submorph in another morph, but it failed (still system modal). I also tried to tell currentWorld to set the ModalWindow to Dialog, without success. Any hint? > > Thank you > > Florent

Sept. 26, 2012

modal dialog

by Florent Arrignon

Hi Pharoers, I'm a beginner with Pharo and try to dive into Morph. My question is trivial as I want to open a modal dialog to catch some text and save it in a file. I use the following code: dialog := TextEntryDialogWindow new. dialog openInWorld. dialog canceled ifFalse: [self createAndWrite: dialog entryText]. In Cincom Smalltalk, the same code opened a dialog modally , but here, not, as it seems suggested in the DialogWindow class comment. I don't know how to change this, I tried to include it as submorph in another morph, but it failed (still system modal). I also tried to tell currentWorld to set the ModalWindow to Dialog, without success. Any hint? Thank you Florent

Sept. 26, 2012

Re: [Pharo-users] how to find 'knownName'?

by Peter K.H. Gragert

Dear Paul and Sven In Squeak 1.4 there is indeed top right a searchbox. The image with running Laser-Game is first not for developers, but changing there is no searchbox to be seen. Luckily I discovered to open flaps (which I would like to have in Pharo too ;-) and there on the Tools-flap there was a 'find methods' possibility: so knownName found ;-) Now trying in (NBCoc)PHaro ;-) command m for 'implementors' found :;) Thanks guys! Peter 2012/9/26 Sven Van Caekenberghe <sven(a)stfx.eu> > In Pharo, you can just command-click on it, or select it and press > command-m, or use the menu. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > On 26 Sep 2012, at 07:49, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > > You want the 'Implementors' of # knownName (every place knownName is > defined). > > > > In Squeak 4.3 you can search for them by typing knownName and hitting > enter into the search box at the top right or by selecting the method name > and right-clicking and choosing 'implementors' > > > > Which version of squeak are you using? > > > > > > > > > > > > > > On Sep 25, 2012, at 10:12 PM, "Peter K.H.tion N"<pkhgragert(a)gmail.com> > wrote: > > > >> Hallo, > >> Trying to implement the Laser-Game to Pharo I am at the moment stuck at > >> [code]findLaserPathCounter > >> ^ self allMorphs > >> detect: [:t1 | t1 knownName = 'laserPath'] > >> ifNone: [] > >> [/code] > >> > >> It works in Squeak (1.4) > >> My question is: How do I find the definition of knownName in Squeak ( > to fileout and transfer to Pharo)??? > >> > >> It seems to be a method for Morphs but I think I need to know how to > question Smalltalk to find a definition > >> of a method with the help of a 'Systembrowser' ? > >> > >> Greets > >> Peter > > > > >

Sept. 26, 2012

Re: [Pharo-users] Collections : abstract class stepping around bad request in code subclass should implement ?

by Robert Shiplett

Oh thanks - glad to see there has been discussion around this. I spend a lot of my time serializing objects in the Curl web content language these days, which has its own issues ;-) i.e. Curl classes can be declared serializable and there is a compiler setting for "strict serialization" but a CharClass object cannot be serialized and so it goes ( or whatever it was Kurt Vonnegut would have us all recall ;-) And the relevant code is not yet open source ! At least I am away from CORBA C-style declarations for marshalling objects (for the time being ... ) R space-like separations, time-like separations, strreamed-CLUNK-separations

Sept. 26, 2012

Re: [Pharo-users] XDisplayControlPlugin location?

by Igor Stasenko

On 26 September 2012 13:44, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Sep 26, 2012 at 11:55:25AM +0200, Igor Stasenko wrote: >> On 26 September 2012 03:53, David T. Lewis <lewis(a)mail.msen.com> wrote: >> > On Wed, Sep 26, 2012 at 03:24:51AM +0200, Igor Stasenko wrote: >> >> As i understood, this features doing a snaphot in forked child process. >> >> Is this involves doing #shutdown on image side in forked process, or shutdown >> >> done in parent image? >> > >> > It just forks an identical copy of the VM and image in a background process >> > running at lower priority, and does the image save in the background process >> > so there is no effect on the main image. Each of the two images knows if >> > it is parent or child, so the child evaluates a block (to do the image >> > save) then exits. >> > >> >> Alas, the complexity of VM works against us in this case :/ >> >> It is not just object memory, but open files, sockets and god knows >> >> what else (other external resources used by image). >> >> >> > >> > It is not the Cog VM that is too complex, it's the use of pthreads in >> > the support code for basic timer support that makes it tricky. I'm sure >> > it can be done, but it's not trivial. >> > >> > Handling the socket connection to the X11 server was a challenge, but >> > I was able to do that with XDisplayControlPlugin. The remaining file >> > handles are just shared between the processes and do not cause any >> > immediate problem. Signal handlers were also an issue, mainly for >> > the timer interrupts. >> > >> > I don't think you should be surprised that it does not work in Cog, >> > instead you should be surprised that it works at all on any VM ;) >> > >> >> Yes, this is mainly what i expected to hear. >> Fork is very easy to use for a simple and small command-line programs, >> but once you start using things like pthreads, external connection(s), >> and FFI this getting more and more complicated, if not impossible, >> because you need a single point in your program which knows everything >> about all external resources/handles claimed by your program and the >> way how to properly disconnect them (as well as invalidate pointers to >> it) when forked.. >> > > It certainly is complex, and gets more so as additional external factors > are added (e.g. pthreads). But it will never become impossible for the > following reason: The image already has, and must have, a mechanism for > snapshotting itself and resuming in another process space (that's what > happens every time you start your image from disk). So I expect there > is always going to be some way to make #forkSqueak work on a unix-based > system. Of course I am not volunteering to actually *do* that, just > saying ... ;) > > BTW, there is no need to invalidate pointers. The virtual address space > remains valid after a fork. Most things "just work" after a unix process > fork, but you do need to think about things like two processes holding > references to the same socket connection to an X server, hence the > use of XDisplayControlPlugin to disconnect the X display and reconnect > to the X11 server after the fork. > By pointers i meant references to external resources, like open files, sockets etc. They surely require additional handling, (some might remain open, but some should be closed ASAP), all this doesn't contributes to simplicity of implementation :) And handling properly X11 connection is just a single piece of puzzle. > Dave -- Best regards, Igor Stasenko.

Sept. 26, 2012

Re: [Pharo-users] XDisplayControlPlugin location?

by David T. Lewis

On Wed, Sep 26, 2012 at 11:55:25AM +0200, Igor Stasenko wrote: > On 26 September 2012 03:53, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Wed, Sep 26, 2012 at 03:24:51AM +0200, Igor Stasenko wrote: > >> As i understood, this features doing a snaphot in forked child process. > >> Is this involves doing #shutdown on image side in forked process, or shutdown > >> done in parent image? > > > > It just forks an identical copy of the VM and image in a background process > > running at lower priority, and does the image save in the background process > > so there is no effect on the main image. Each of the two images knows if > > it is parent or child, so the child evaluates a block (to do the image > > save) then exits. > > > >> Alas, the complexity of VM works against us in this case :/ > >> It is not just object memory, but open files, sockets and god knows > >> what else (other external resources used by image). > >> > > > > It is not the Cog VM that is too complex, it's the use of pthreads in > > the support code for basic timer support that makes it tricky. I'm sure > > it can be done, but it's not trivial. > > > > Handling the socket connection to the X11 server was a challenge, but > > I was able to do that with XDisplayControlPlugin. The remaining file > > handles are just shared between the processes and do not cause any > > immediate problem. Signal handlers were also an issue, mainly for > > the timer interrupts. > > > > I don't think you should be surprised that it does not work in Cog, > > instead you should be surprised that it works at all on any VM ;) > > > > Yes, this is mainly what i expected to hear. > Fork is very easy to use for a simple and small command-line programs, > but once you start using things like pthreads, external connection(s), > and FFI this getting more and more complicated, if not impossible, > because you need a single point in your program which knows everything > about all external resources/handles claimed by your program and the > way how to properly disconnect them (as well as invalidate pointers to > it) when forked.. > It certainly is complex, and gets more so as additional external factors are added (e.g. pthreads). But it will never become impossible for the following reason: The image already has, and must have, a mechanism for snapshotting itself and resuming in another process space (that's what happens every time you start your image from disk). So I expect there is always going to be some way to make #forkSqueak work on a unix-based system. Of course I am not volunteering to actually *do* that, just saying ... ;) BTW, there is no need to invalidate pointers. The virtual address space remains valid after a fork. Most things "just work" after a unix process fork, but you do need to think about things like two processes holding references to the same socket connection to an X server, hence the use of XDisplayControlPlugin to disconnect the X display and reconnect to the X11 server after the fork. Dave

Sept. 26, 2012