- Pharo-users - lists.pharo.org

Re: [Pharo-users] deep into pharo(esug 2013) translate to korean draft version.

by Damien Cassou

On Sat, May 24, 2014 at 2:53 PM, peter yoo <onionmixer(a)gmail.com> wrote: > It would be honor to me if you would like to put a URL link to my korean > translation of Deep Into Pharo on your website. what about this: http://deepintopharo.com/ ? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 27, 2014

Re: [Pharo-users] MacOS headless but showing up in dock?

by Esteban Lorenzano

not directly but you can use the Alien ObjC bridge to work with the cocoa libraries and intercept your app. use ConfigurationOfOldAlien from alien repo in squeaksource or in the configurations browser. Esteban On 27 May 2014, at 07:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > is it possible to have Pharo run headless while still showing up in the dock? > > In the same direction, is it possible to add contextual menu items to the dock menu? Or for what matters, to the top system menu? > > Thanks! > > -- > Bernat Romagosa.

May 27, 2014

MacOS headless but showing up in dock?

by Bernat Romagosa

Hi list, is it possible to have Pharo run headless while still showing up in the dock? In the same direction, is it possible to add contextual menu items to the dock menu? Or for what matters, to the top system menu? Thanks! -- Bernat Romagosa.

May 27, 2014

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