September 2012 - Pharo-users

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

by Mariano Martinez Peck

I think this issue is related: http://code.google.com/p/pharo/issues/detail?id=2230 On Wed, Sep 26, 2012 at 12:19 PM, Robert Shiplett <grshiplett(a)gmail.com>wrote: > yes, 2.0 has that odd duplicate code (see my prev misplaced msg below ...) > > A lot of time spent in expression-based languages leaves me > uncomfortable that ^self is used for this NOP condition which looks > like an unmessaged/unsignalled failure that should never arise. > > I ask just me: why is this not Error material ? Should there not be a > flag to test against as to whether this is non-recoverable > non-completion of task ? > > The opponents of nil checks spend too little time in happily > back-tracking Icon dialects ? ( yes ... there is now expression-based > ObjectIcon - and it is Unicode ) > > Of course the real question is how this code gets to stay there at all > even in 2.0 - or shoudl I be asking why a Trait was not the cure here > ? > > The really good news: it was not a copy-n-paste ! > > But seriously ... when this failure occurs, what flags that it is > harmless ? Compare messaging model of RTOS QNX where the cost of this > advice is low. > > Or is this all safely covered by unit testing ? ( yes, that is my > twisted sense of almost-humour ... ) > > > > > In 1.4 ArrayedCollection we have > > > > this > > > > self class isPointers | self class isWords not ifTrue: [^self]. > > > > in >>restoreEndianness > > > > but this in > > > > >>writeOn: > > > > (self class isPointers or: [ self class isWords not ]) ifTrue: > [^ self ]. > > > > It gets called once per task in both and should be a correct method, > > right ? The former does not even look correct at a glance. > > > > I have no time today to go check if this odd duplication remains in > > 2.0 as I must run > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2012

Collections : abstract class stepping around bad request in code subclass should implement ?

by Robert Shiplett

yes, 2.0 has that odd duplicate code (see my prev misplaced msg below ...) A lot of time spent in expression-based languages leaves me uncomfortable that ^self is used for this NOP condition which looks like an unmessaged/unsignalled failure that should never arise. I ask just me: why is this not Error material ? Should there not be a flag to test against as to whether this is non-recoverable non-completion of task ? The opponents of nil checks spend too little time in happily back-tracking Icon dialects ? ( yes ... there is now expression-based ObjectIcon - and it is Unicode ) Of course the real question is how this code gets to stay there at all even in 2.0 - or shoudl I be asking why a Trait was not the cure here ? The really good news: it was not a copy-n-paste ! But seriously ... when this failure occurs, what flags that it is harmless ? Compare messaging model of RTOS QNX where the cost of this advice is low. Or is this all safely covered by unit testing ? ( yes, that is my twisted sense of almost-humour ... ) > > In 1.4 ArrayedCollection we have > > this > > self class isPointers | self class isWords not ifTrue: [^self]. > > in >>restoreEndianness > > but this in > > >>writeOn: > > (self class isPointers or: [ self class isWords not ]) ifTrue: [^ self ]. > > It gets called once per task in both and should be a correct method, > right ? The former does not even look correct at a glance. > > I have no time today to go check if this odd duplication remains in > 2.0 as I must run >

Sept. 26, 2012

Re: [Pharo-users] XDisplayControlPlugin location?

by Igor Stasenko

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.. > Dave -- Best regards, Igor Stasenko.

Sept. 26, 2012

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

by Sven Van Caekenberghe

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] how to find 'knownName'?

by Paul DeBruicker

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

how to find 'knownName'?

by Peter K.H. Gragert

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] XDisplayControlPlugin location?

by David T. Lewis

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 ;) Dave

Sept. 26, 2012

Re: [Pharo-users] XDisplayControlPlugin location?

by Igor Stasenko

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? 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). -- Best regards, Igor Stasenko.

Sept. 26, 2012

Re: [Pharo-users] XDisplayControlPlugin location?

by David T. Lewis

On Tue, Sep 25, 2012 at 03:52:08PM -0400, David T. Lewis wrote: > On Tue, Sep 25, 2012 at 12:23:38PM -0700, Paul DeBruicker wrote: > > Hi- > > > > Where can I find the latest XDisplayControlPlugin? Is this it: > > http://wiki.squeak.org/squeak/3350 ? > > > > That's my original "home page" for XDisplayControlPlugin. The code is > now kept on SqueakSource: > > http://www.squeaksource.com/XDCP > > > > > > I was trying to run > > > > UnixProcess saveImageInBackgroundNicely > > > > > > in Pharo-1.4 using both Eliots and the inria vm's but can't because I > > don't have the aforementioned plugin. > > > > I'm not sure if this works on Cog. I think it should work, but I'm > away and can't check for sure. But FYI #forkSqueak has some limitations > on Cog, e.g. you cannot fork a vm/image and reopen the display in > the child. Paul, Sorry I had forgotten the details on this. Yes, it is necessary to have XDisplayControlPlugin in order to do a saveImageInBackgroundNicely, because the interaction with the X11 server must be turned off in the child VM process. Without that, the child will do things that interfere with the original VM, leading to a VM crash. XDisplayControlPlugin will compile and run under Cog, but the necessary hooks are not in place in the support code, and the primitives will fail. The bottom line is that at the present time #saveImageInBackgroundNicely works only on an interpreter VM. Dave

Sept. 25, 2012

Re: [Pharo-users] Problems with a Morph that accepts File Dropping in Pharo 1.3+

by Helene Bilbo

Ok, i just tried everything and it works perfectly. Thank you again. -- View this message in context: http://forum.world.st/Problems-with-a-Morph-that-accepts-File-Dropping-in-P… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 25, 2012