May 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] name selector

by Norbert Hartl

+ 1 Norbert Am 26.05.2014 um 19:19 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Object>>#name should be removed, it is possible, I tried it once. > Most senders of #name are asking for the name of a class. > > On 26 May 2014, at 18:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Do I understand correctly that name is to be understood as inspectorName >> and so should never be implemented as subclass responsibility? >> >> Stephan >> > >

May 27, 2014

Re: [Pharo-users] 3D with Pharo and OpenGL ?

by darrinm

OK, I've found the R3StateTracker and am working from that. -- View this message in context: http://forum.world.st/3D-with-Pharo-and-OpenGL-tp4760029p4760466.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 26, 2014

Re: [Pharo-users] name selector

by Johan Fabry

On May 26, 2014, at 3:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-05-26 15:14 GMT-03:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: >> >> +1 on the removal of Object>>#name. > > Everybody got bitten by the accessor creation of #name: and #name1 :) Bitten? No. Annoyed? Yes yes yes. :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

May 26, 2014

Re: [Pharo-users] name selector

by Sergi Reyner

2014-05-26 20:08 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-05-26 15:14 GMT-03:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > > > +1 on the removal of Object>>#name. > > Everybody got bitten by the accessor creation of #name: and #name1 :) > I hear you!

May 26, 2014

Re: [Pharo-users] name selector

by Esteban A. Maringolo

2014-05-26 15:14 GMT-03:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > +1 on the removal of Object>>#name. Everybody got bitten by the accessor creation of #name: and #name1 :) Esteban A. Maringolo

May 26, 2014

Re: [Pharo-users] name selector

by Johan Fabry

+1 on the removal of Object>>#name. On May 26, 2014, at 1:19 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Object>>#name should be removed, it is possible, I tried it once. > Most senders of #name are asking for the name of a class. > > On 26 May 2014, at 18:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Do I understand correctly that name is to be understood as inspectorName >> and so should never be implemented as subclass responsibility? >> >> Stephan >> > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

May 26, 2014

Re: [Pharo-users] storeOn:/readFrom: symmetrical?

by Esteban A. Maringolo

I wouldn't rely on such symmetry. Given the fact #printOn: is the only printing "instrumentation" available to show objects in debuggers, inspectors, etc. Most of the times it just shows a short representation of the object, not very useful to recreate an instance from such short string. Regards, Esteban A. Maringolo 2014-05-26 14:11 GMT-03:00 Rick Kitts <rkitts(a)loudhouse.org>: > I wanted to take a second to close the book on this. It turns out that > storeOn:/readFrom: are not supposed to be symmetrical. printOn:/readFrom: > are supposed to be symmetrical. > > storeOn: generates a string that can be fed into the interpreter/compiler > such that when it is executed an instance that is equal to the receiver of > the storeOn: message is created. Iâm trying to figure out how to do that now > so I can convert a bunch of questionable tests of storeOn:. > > Thanks for taking the time. I probably should have RTFMed this a little > better before troubling the list. > > âRick > > On May 23, 2014 at 11:15:43 PM, stepharo (stepharo(a)free.fr) wrote: > > > On 23/5/14 19:58, Rick Kitts wrote: > > Hi. A basic question I hope someone can answer. This works: > > â cut here --- > | stream aInt | > > stream := (String new:20) writeStream. > aInt := 23. > (aInt storeOn:stream) = (aInt class readFrom:(stream contents)) > > â cut here --- > > This doesnât (generates an error): > > â cut here --- > | stream aTime | > > stream := (String new:20) writeStream. > aTime := Time now. > (aTime storeOn:stream) = (aTime class readFrom:(stream contents)) > > â cut here --- > > To the question then. Assuming the second case isnât wrong in some fashion I > donât understand, is it the case that storeOn:/readFrom: is supposed to be > symmetrical for all classes? I ask it that way because there are a couple of > Kernel classes where Iâve seen this to not be the case. > > > > It would be nice that they get symmetric. because the goal of storeOn: is to > recreate the same object. > So if you have a fix please > - sign the license agreement > - open a bug entry > - publish the fix. > > > TIA, > âRick > > > > >

May 26, 2014

Re: [Pharo-users] Block Recursion

by ClÃ©ment Bera

Hello, Closures were implemented in Squeak/Pharo according to the blue book, so they were not real closures, up to 2008. Then the VM and the compiler were changed to support real closures. The code you showed should work both on latest Squeak and on latest Pharo fine. Old version of Squeak and/or Pharo may not work. Last time I tried, it worked on Squeak 4.5 and it works at least since Pharo 1.4. About compiler warnings you can disable them in the setting browser. Then you won't have the modal dialog that you find annoying. Regards. 2014-05-26 18:42 GMT+02:00 Bob Williams <rwilliams19(a)cox.net>: > I read that Blocks in Squeak and Pharo, since it was derived from Squeak > did not implement true block closures and would not support block > recursion. On one count the statement was correct, but not on the other. I > tried: > > | a f | > a := 0. > f := [ Transcript show: a. (a < 5)ifTrue:[a := a + 1. f value ] ]. > f value. > a inspect. > > A Workspace DoIt did not work in Squeak, it failed complaning that the > block was being evaluated. In Pharo, it works but with the annoying modal > dialog asking to run since f was not assigned a value. If blocks are to be > used recursively, a better way must be found to flag but not stop execution. > > This example points out that porting from Squeak to Pharo is fine, but the > reverse might be questionable. > > bw >

May 26, 2014

Re: [Pharo-users] name selector

by Sven Van Caekenberghe

Object>>#name should be removed, it is possible, I tried it once. Most senders of #name are asking for the name of a class. On 26 May 2014, at 18:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > Do I understand correctly that name is to be understood as inspectorName > and so should never be implemented as subclass responsibility? > > Stephan >

May 26, 2014

Re: [Pharo-users] storeOn:/readFrom: symmetrical?

by Rick Kitts

I wanted to take a second to close the book on this. It turns out that storeOn:/readFrom: are not supposed to be symmetrical. printOn:/readFrom: are supposed to be symmetrical. storeOn: generates a string that can be fed into the interpreter/compiler such that when it is executed an instance that is equal to the receiver of the storeOn: message is created. Iâm trying to figure out how to do that now so I can convert a bunch of questionable tests of storeOn:. Thanks for taking the time. I probably should have RTFMed this a little better before troubling the list. âRickÂ On May 23, 2014 at 11:15:43 PM, stepharo (stepharo(a)free.fr) wrote: On 23/5/14 19:58, Rick Kitts wrote: Hi. A basic question I hope someone can answer. This works: â cut here --- | stream aInt | stream := (String new:20) writeStream. aInt := 23. (aInt storeOn:stream) = (aInt class readFrom:(stream contents)) â cut here --- This doesnât (generates an error): â cut here --- | stream aTime | stream := (String new:20) writeStream. aTime := Time now. (aTime storeOn:stream) = (aTime class readFrom:(stream contents)) â cut here --- To the question then. Assuming the second case isnât wrong in some fashion I donât understand, is it the case that storeOn:/readFrom: is supposed to be symmetrical for all classes? I ask it that way because there are a couple of Kernel classes where Iâve seen this to not be the case. It would be nice that they get symmetric. because the goal of storeOn: is to recreate the same object. So if you have a fix please Â Â Â - sign the license agreement Â Â Â - open a bug entry Â Â Â - publish the fix. TIA, âRick

May 26, 2014