August 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Alien bug fix

by Torsten Bergmann

>Ok so we will have to update the Alien chapter draft Can you send the draft as PDF. Would be interesting. Thx T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Aug. 19, 2011

Re: [Pharo-project] Alien bug fix

by StÃ©phane Ducasse

> > > > > I've answered this many times before. Alien is fine for data representation and callbacks, but not for callouts (too simpleminded, works only on x86). But I have integrated Alien with FFI and will not be developing Alien callouts. Use FFI callouts instead. > > But is FFI not good for representation and callbacks? > My point is why having two systems each with a weak point (if FFI has weak points). > I'm probably too stupid to understand so I will discuss with the guys here because I'm missing something. > > They are now integrated (to a usable extent). One can pass Aliens through the FFI. So to use callbacks with the FFI one creates Alien callbacks and passes them as arguments through FFI calls. Simple. Ok so we will have to update the Alien chapter draft. Stef > > > Stef > > > > > > > Stef (finished to paint house - well nearly finished before running to ESUG). > > > > On Aug 18, 2011, at 7:37 PM, Eliot Miranda wrote: > > > > > Hi All, > > > > > > I've just published Alien-eem.14 to http://www.squeaksource.com/Alien. This fix needs to be integrated into each dialect's version of Alien. The bug causes VM crashes due to trying to free stale pointers from previous runs. > > > > > > Alien-eem.14 > > > Author: eem > > > Time: 18 August 2011, 10:34:20.024 am > > > UUID: 39bedad1-6159-4ba4-be35-277df2a25977 > > > Ancestors: Alien-eem.13 > > > > > > Fix startUp: discarding of stale values from Alien's GCMallocedAliens class var. > > > > > > -- > > > best, > > > Eliot > > > > > > > > > > > > > > > -- > > best, > > Eliot > > > > > > > > -- > best, > Eliot >

Aug. 19, 2011

[Pharo-project] [ANN] Fuel release version 1.6

by Martin Dias

Hello! I want to announce the new release version number 1.6 of Fuel, a binary serialization framework for Pharo that provides extremely fast deserialization. More information on our home page<http://rmod.lille.inria.fr/web/pier/software/Fuel>. Again, I thank ESUG for sponsoring me through the SummerTalk<http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011>program. You can download this version in Pharo 1.2.1 with: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.6') load. This version does not add any new concrete functionality but has two main achievements: a performance improvement and a design clean up. Many changes included in this release are part of a design clean up. They are a necessary step forward to new functionalities that are coming soon. They make code more understandable. They enable simpler extension. Happily they also helped to improve serialization performance by reducing unnecessary interactions. And it is specially important a bottleneck in graph analysis stage we have successfully attacked, obtaining great results. Details: - Removed explicit references to cluster classes scattered around the system. For example, in previous versions Float>>fuelCluster has an explicit reference to FLFloatCluster. This version replaces this by a double dispatch interaction. - Clusters: Better reification. Removed annoying IDs. Removed Singleton instance creation mechanism, now mappers manage uniqueness in a better way. - Mappers: They were simplified. New mapping machanism inspired on Chain of Responsibility pattern. The global objects detection has been optimized considerably. - Analyzer: Part of its behavior and state has been moved to a new abstraction called 'clusterization'. Best regards, MartÃn Dias

Aug. 19, 2011

Re: [Pharo-project] what are the comments of cull: cull: cull:cull: and friends?

by Guillermo Polito

What about making explicit in the comment that the arg is ignored if not needed? Something like cull: anArg "Execute the receiver with one or zero argument. If the receiver needs less than one argument, the argument is ignored. ..." Guille On Thu, Aug 18, 2011 at 4:17 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On Aug 18, 2011, at 8:52 44AM, Philippe Marschall wrote: > > > On 17.08.2011 22:57, Henrik Sperre Johansen wrote: > >> On 17.08.2011 22:29, Philippe Marschall wrote: > >>> On 17.08.2011 22:17, StÃ©phane Ducasse wrote: > >>>> I wrote > >>>> > >>>> > >>>> cull: anArg > >>>> "Execute the receiver with one or zero argument. > >>>> > >>>> [ 1 + 2 ] cull: 5 > >>>> returns 3 > >>>> [ :x | 1+ 2 + x] cull: 5 > >>>> returns 8 > >>>> " > >>>> ^numArgs = 0 > >>>> ifTrue: [self value] > >>>> ifFalse: [self value: anArg] > >>>> > >>> > >>> So it's like #valueWithPossibleArgument:? > >> Almost. > >> cull: raises error if given blocks with too many args, > >> valueWithPossibleArgument(s): evaluates with the extra args as nil. > >>> Why do we need two methods > >>> that do the same thing? > >> Because valueWithPossibleArguments was there first, and we can't simply > >> remove it. > >> cull is more natural to use in 99.9% of the cases. > >> > >> Also, #cull: protocol only goes up to 4 arguments, mirroring #value: > >> (#cullWithArguments: not being present is mostly an oversight though... > ) > > > > So we #valueWithPossibleArgument:? > > > > Cheers > > Philippe > #valueWithPossibleArgument: / #valueWithPossibleArgs: / > #valueWithEnoughArguments: all execute the block with nil args if passed too > few. > #cull:'s raise an error. > Other than that, they are equivalent from a users POV, yes. > > Cheers, > Henry >

Aug. 19, 2011

Re: [Pharo-project] Alien bug fix

by Eliot Miranda

On Thu, Aug 18, 2011 at 2:08 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Aug 18, 2011, at 10:51 PM, Eliot Miranda wrote: > > > > > > > On Thu, Aug 18, 2011 at 11:30 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Thanks eliot > > > > BTW what is the future of alien compared to FFI. I'm still confused. > > > > I've answered this many times before. Alien is fine for data > representation and callbacks, but not for callouts (too simpleminded, works > only on x86). But I have integrated Alien with FFI and will not be > developing Alien callouts. Use FFI callouts instead. > > But is FFI not good for representation and callbacks? > My point is why having two systems each with a weak point (if FFI has weak > points). > I'm probably too stupid to understand so I will discuss with the guys here > because I'm missing something. > They are now integrated (to a usable extent). One can pass Aliens through the FFI. So to use callbacks with the FFI one creates Alien callbacks and passes them as arguments through FFI calls. Simple. > > Stef > > > > > > > Stef (finished to paint house - well nearly finished before running to > ESUG). > > > > On Aug 18, 2011, at 7:37 PM, Eliot Miranda wrote: > > > > > Hi All, > > > > > > I've just published Alien-eem.14 to > http://www.squeaksource.com/Alien. This fix needs to be integrated into > each dialect's version of Alien. The bug causes VM crashes due to trying to > free stale pointers from previous runs. > > > > > > Alien-eem.14 > > > Author: eem > > > Time: 18 August 2011, 10:34:20.024 am > > > UUID: 39bedad1-6159-4ba4-be35-277df2a25977 > > > Ancestors: Alien-eem.13 > > > > > > Fix startUp: discarding of stale values from Alien's GCMallocedAliens > class var. > > > > > > -- > > > best, > > > Eliot > > > > > > > > > > > > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Aug. 18, 2011

Re: [Pharo-project] Alien bug fix

by StÃ©phane Ducasse

On Aug 18, 2011, at 10:51 PM, Eliot Miranda wrote: > > > On Thu, Aug 18, 2011 at 11:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks eliot > > BTW what is the future of alien compared to FFI. I'm still confused. > > I've answered this many times before. Alien is fine for data representation and callbacks, but not for callouts (too simpleminded, works only on x86). But I have integrated Alien with FFI and will not be developing Alien callouts. Use FFI callouts instead. But is FFI not good for representation and callbacks? My point is why having two systems each with a weak point (if FFI has weak points). I'm probably too stupid to understand so I will discuss with the guys here because I'm missing something. Stef > > > Stef (finished to paint house - well nearly finished before running to ESUG). > > On Aug 18, 2011, at 7:37 PM, Eliot Miranda wrote: > > > Hi All, > > > > I've just published Alien-eem.14 to http://www.squeaksource.com/Alien. This fix needs to be integrated into each dialect's version of Alien. The bug causes VM crashes due to trying to free stale pointers from previous runs. > > > > Alien-eem.14 > > Author: eem > > Time: 18 August 2011, 10:34:20.024 am > > UUID: 39bedad1-6159-4ba4-be35-277df2a25977 > > Ancestors: Alien-eem.13 > > > > Fix startUp: discarding of stale values from Alien's GCMallocedAliens class var. > > > > -- > > best, > > Eliot > > > > > > > > -- > best, > Eliot >

Aug. 18, 2011

Re: [Pharo-project] Alien bug fix

by Eliot Miranda

On Thu, Aug 18, 2011 at 11:30 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Thanks eliot > > BTW what is the future of alien compared to FFI. I'm still confused. > I've answered this many times before. Alien is fine for data representation and callbacks, but not for callouts (too simpleminded, works only on x86). But I have integrated Alien with FFI and will not be developing Alien callouts. Use FFI callouts instead. > Stef (finished to paint house - well nearly finished before running to > ESUG). > > On Aug 18, 2011, at 7:37 PM, Eliot Miranda wrote: > > > Hi All, > > > > I've just published Alien-eem.14 to > http://www.squeaksource.com/Alien. This fix needs to be integrated into > each dialect's version of Alien. The bug causes VM crashes due to trying to > free stale pointers from previous runs. > > > > Alien-eem.14 > > Author: eem > > Time: 18 August 2011, 10:34:20.024 am > > UUID: 39bedad1-6159-4ba4-be35-277df2a25977 > > Ancestors: Alien-eem.13 > > > > Fix startUp: discarding of stale values from Alien's GCMallocedAliens > class var. > > > > -- > > best, > > Eliot > > > > > -- best, Eliot

Aug. 18, 2011

Re: [Pharo-project] Typo in Pragma class comment

by Marcus Denker

On Aug 18, 2011, at 9:25 PM, Igor Stasenko wrote: > thanks=4659 ? > :))) > this is the URL that the browser shows after submitting the report... which strangely does not show what it shows after submitting, but just nothing. A good link is this: http://code.google.com/p/pharo/issues/detail?id=4659 > On 18 August 2011 18:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 18, 2011, at 11:26 AM, Dennis Schetinin wrote: >> >>> Look for "browsse". >>> >>> Sorry, if this is incorrect place to report this kind of things. >>> >>> >> >> The best is always to add a tracker entry like this: >> >> http://code.google.com/p/pharo/issues/list?thanks=4659 >> >> This way it will just be fixed with the next update.. >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Marcus Denker -- http://marcusdenker.de

Aug. 18, 2011

Re: [Pharo-project] Typo in Pragma class comment

by Igor Stasenko

thanks=4659 ? :))) On 18 August 2011 18:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 18, 2011, at 11:26 AM, Dennis Schetinin wrote: > >> Look for "browsse". >> >> Sorry, if this is incorrect place to report this kind of things. >> >> > > The best is always to add a tracker entry like this: > > Â Â Â Â http://code.google.com/p/pharo/issues/list?thanks=4659 > > This way it will just be fixed with the next update.. > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 18, 2011

[Pharo-project] Squeak/Pharo on touchscreen: requesting opinions

by Dimitry Golubovsky

Hi, As I am progressing through the Stack Cog port for Android (basically I can load a recent PharoCore or Squeak image althoug some stability issues still exist), I would like to collect opinions from prospective users, which is a better way to interact with Squeak (meaning Pharo and others as well) on a touch screen. 9" tabet screen is not much smaller than say EEE PC netbook's, so at 800x480 px resolution menus and other Squeak GUI elements are well readable, and can be easily pointed at with a stylus. So Squeak environment itself can be as well used even on my rather cheap device. Squeak requires a lot of mousing to interact. On an Android device, there is a touch screen, and possibly several hardware buttons. In the current implementation taps on the screen are treated as "red" clicks, and pressing one of hardware buttons prior to tapping the screen change click color just for one click: see this picture: http://wiki.squeakvm-tablet.googlecode.com/hg/pics/pdn-land.jpg That is, in order to get a context menu in Squeak, one has to press the "Yellow" hardware button (in PharoCore it is the "Blue" button), and then tap the screen; the menu appears. See the whole explanation at http://code.google.com/p/squeakvm-tablet/wiki/TestDrive This is how the classic (based on Andreas' code) Squeak VM port works now, and I have the same working in Stack Cog. Advantages of this method: it is close to the way traditional mobile applications interact. In a Squeak application, a Morph has to set proper handling of red button clicks in order to enable interaction with user. Morph drag can be done with one hand (however by a reason I could not explain, morphs disappear from the screen while being dragged, and reappear in new location only when tap is released). Disadvantages: current mouse position is unknown/invisible to the user, mouse over is impossible (hence no balloon help). Also due to high touchscreen sensitivity, holding a finger/stylus on the screen may generate many events within short period of time, since even one pixel change in touch position causes an event to be generated, and some involuntary finger movements always take place. Such frequently reported events may "choke" the interpreter, given the CPU is slow, and Android OS quickly kills it due to unresponsiveness. While I am trying to address these issues in various ways, there seems to be another way to interact via touchscreen. This method has not been implemented yet, and I would like to hear from the community whether it could be good to have. A mouse pointer is displayed as part of the activity interface (maybe even done entirely in Java, so mouse movement itself will not put any load on the interpreter). Finger movements on the screen move the pointer, but new position is reported (with button mask 0) only when the screen tap is released. So mouse over becomes possible: just leave the pointer where needed. The hardware buttons are used as before (one becomes Red, another Blue, and a chord would be Yellow), but clicks only are reported when those buttons are pressed or released*. To drag a Morph, one would have to hold one of the hardware buttons, and slide their finger/stylus on the screen. So this hypothetical mode is more like laptops' trackpads work. One obvious advantage of this method is less load on the interpreter in terms of the frequency of events, and hence greater stability, although less convenience. Again, to run an end-user application, the former mouse tracking method may be enabled. I am asking your opinion here (as much of opinion can be had about something only imaginary) - is the latter method worth implementing: would one like to use it if available? Thanks. ------------------------- * or long taps may be recognized as red clicks -- Dimitry Golubovsky Anywhere on the Web

Aug. 18, 2011