October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] the we site does not point to the rc1 image/

by StÃ©phane Ducasse

ok I was wrong. May be should change beta to Release Candidate in the heading. stef On Oct 22, 2009, at 1:58 PM, Adrian Lienhard wrote: > which link do you mean? > > Adrian > > On Oct 22, 2009, at 12:37 , StÃ©phane Ducasse wrote: > >> can somebody fix it? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] found a mac magsafe power adapter

by StÃ©phane Ducasse

Ok I will keep it :) We laugh a lot seeing you coming back like that :) Stef On Oct 22, 2009, at 1:59 PM, Henrik Johansen wrote: > Probably mine, I bought a new one today. > So no problems, if you remember to bring it for the next sprint/ESUG > that'd just be a bonus. > > At least I remembered my luggage in time! :) > > Cheers, > Henry > > On Oct 22, 2009, at 1:45 50PM, StÃ©phane Ducasse wrote: > >> one of the pharo sprinter forgot his adaptor :) >> let me know that we ship it by post >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] found a mac magsafe power adapter

by Johan Brichau

On 22 Oct 2009, at 13:59, Henrik Johansen wrote: > At least I remembered my luggage in time! :) yes, but _just_ in time ;-) ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Oct. 22, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Gerben van de Wiel

Thanks again for the answers. The only thing i am a bit bothered about is the following paragraph i am reading. "Instance variables can be accessed by name in any of the instance methods of the class that defines them, and also in the methods defined in its subclasses. This means that Smalltalk instance variables are similar to protected variables in C++ and Java. However, we prefer to say that they are private, because it is considered bad style in Smalltalk to access an instance variable directly from a subclass." So this paragraph states that accessing ivars from a subclass is bad style. So the previous code example on page 32 are bad style ;). Regards, On Wed, Oct 21, 2009 at 10:01 PM, <csrabak(a)bol.com.br> wrote: > There are two subjects here. Let me start with Oscar's query first. > > Since protocols in Â Smalltalk are a suggestion but not enforceable, I > tend Â to avoid (ii) as much Â as possible and Â use Â instance Â variable > methods with Â lazy initialization as Â much as Â possible to have short > initialize methods. > > Pertaining to Gerben's question, I think an authoritative answer will > be still needing: > > Looking at the class hierarchy Â from SimpleButtonMorph up, you'll see > that Â bounds ivar is Â defined in Morph Â class Â and indeed Â there is a > method Morph>>bounds:, but it is in geometry protocol (meaning is not > in accessing protocol). Â Notice that Â Morph>>bounds: Â does not update > bounds ivar directly, but rather indirectly via Morph>>extent:! > > So in Â this particular case Â using the accessor method would not work > the same way as the code in the book (caveat emptor, I did not test > this assertion!) > > Em 21/10/2009 10:12, Oscar Nierstrasz < oscar(a)iam.unibe.ch > escreveu: > >> >> Â Hi Gerben, >> Â It is Â really a question of Â style. Some people promote Â the use of >> accessors aggressively Â for all Â instance variable access. Â The down >> sides are Â (i) proliferation of accessor methods, Â and (ii) exposure >> of Â private Â state Â to Â other Â objects. Â If you Â do Â decide Â to Â use >> accessors, Â you should Â be sure Â to put Â them in Â a Â protocol called >> "private" to make Â clear that they are only intended Â for use by the >> object itself. >> Â I am curious Â what other people tend to do -- Â do you use accessors >> for inherited ivars, or access them directly? >> Â - on >> >> >> Â On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote: >> >> > Hi, >> > I Â am very new Â to Pharo Â and Smalltalk Â in general. Â When reading >> > through the excellent PBE book Â i was wondering about something on >> > page 32. Â In that piece Â of code the Â LOCell class is Â using some >> > instance variables from it's super classes, and i was wondering if >> > it isn't best practice to Â use message to self using the accessing >> > methods so instead of. >> > bounds Â := 0@0 Â corner: Â 16@16. using Â self Â bounds: (0@0 Â corner: >> > 16@16). >> > or is good Â to use both or is there something Â i don't know (maybe >> > it is faster Â to use instance vars then sending Â a new message and >> > traverse the inheritance tree). >> > regards, >> > Gerben van de Wiel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009

Re: [Pharo-project] HashTable vs Dictionary

by Lukas Renggli

> So this means that by default we have bad performance. no? No. In a fresh Pharo Web image less than 6% of the keys in Dictionaries and less than 10% of the values in Sets have a weak-hashes. Moreover the largest set with weak-hash values has 516 elements (on average only 1.8 elements), the largest dictionary with weak-hash keys has 1002 elements (on average only 4.3 elements). Using HashTable in such a situation would introduce a major speed penalty and waste a lot of memory. It would be cool if the Set and the Dictionary would choose their implementation strategy automatically depending on the use-case. In a standard Pharo image however that would just be the current implementation. There are simply no instances in the image where it would be worthwhile (large amount of data with bad hash) to use a HashMap. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 22, 2009

Re: [Pharo-project] #1339 - ODBC crashes vm

by Henrik Johansen

On Oct 20, 2009, at 4:16 37PM, Mariano Martinez Peck wrote: > > > On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no > > wrote: > This one is caused by an initialization bug of some sort, the > byteSizes of ODBC-structs are incorrect. > > In short, the solution is to do: > ExternalStructure allSubclassesDo: [:each | each compileFields] > after you load a package which defines ExternalStructure subclasses > (like ODBC does). > > > Hi Henrik! Nice to see you arround ;) > > In SqueakDBX I use FFI, I have subclasses of ExternalStructure and > I don't remember having to do that. The only thing I do in those > subclasses is to implement a class side method initialize like this: > > initialize > super initialize. > self defineFields > > > And then, if you see defineFields you will se that at the end, it > does a compileField... > You can see defineFields in FFI documentation: http://wiki.squeak.org/squeak/2426 > > So, in my opinion a better solution may be this. What do you think ? > > Cheers > > Mariano Errr, so in conclusion, you didn't do exactly what I did, but something else which results in doing exactly the same, but in addition define accessors for the fields. So you did have to do that, even though you don't remember it. :P Here's the reasons why I feel the solution you found, by itself, does not constitute a good solution: - If you DON'T remember to do it, the image of people loading your project might crash silently. - Neither FFI itself nor ODBC has remembered to do so (it's done in the loadFFI script in ScriptLoader) - Debugging it if you haven't read some arbitrary wiki-page was a real pain (partly because it doesn't crash as soon as the error is made) - Even you, who had actually read the wikipage, didn't make the association to this issue. A couple of alternative approaches: a) - Returning an error if a basicSize request would return 0 informing that fields have not been properly initialized (Or silently doing a recompile) b) Wait for MC1.6's atomic loader so you can be sure the fields method is compiled when a new external structure is installed :) c) Don't store into compiledSpec if fields is empty, on the presumption it will not be used until fields has been defined. (This won't actually work, as loading from MC will only execute class initialization only if class initialize method is defined in package being loaded (store works the same), but: d) - Do a compileFields: call in ExternalStructure>>initialize, and instead create a createAccessors method which can be overridden if necessary. ) a) and c) will both suffer from the issue that if you load/merge a newer version with additional fields defined, you get the same flaky behaviour as is experienced now. b) is probably some time off in the future, depending on when someone gets the time to implement trait support. a), but without the silent recompile and a helpful error message might be the best short-term option, since it'd remind authors to add class initialize-methods, and tell a user what to do if they've forgotten to do so instead of crashing the image. I've attached a changeset implementing c) to the issue. Cheers, Henry

Oct. 22, 2009

[Pharo-project] thanks to all the sprinters

by stephan＠stack.nl

> could organize one at Fosdem but this is just the beginning of > winter holiday in france :( > > Stef FOSDEM would be good. Saturday 6 and sunday 7 februari 2010, Brussels. Stephan

Oct. 22, 2009

Re: [Pharo-project] found a mac magsafe power adapter

by Henrik Johansen

Probably mine, I bought a new one today. So no problems, if you remember to bring it for the next sprint/ESUG that'd just be a bonus. At least I remembered my luggage in time! :) Cheers, Henry On Oct 22, 2009, at 1:45 50PM, StÃ©phane Ducasse wrote: > one of the pharo sprinter forgot his adaptor :) > let me know that we ship it by post > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009

Re: [Pharo-project] the we site does not point to the rc1 image/

by Adrian Lienhard

which link do you mean? Adrian On Oct 22, 2009, at 12:37 , StÃ©phane Ducasse wrote: > can somebody fix it? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by StÃ©phane Ducasse

Yes or you click on the class and say expand and this means that you inpect it then. Stef On Oct 22, 2009, at 11:41 AM, Johan Brichau wrote: > > On 22 Oct 2009, at 11:03, George Herolyants wrote: > >> 2009/10/21 Johan Brichau <johan.brichau(a)uclouvain.be>: >>> - Do not 'inspect/explore' the class as a normal object but make it >>> jump to a browser instead >> >> I don't agree with it. Class is a normal object and must be inspected >> as all other objects, I think. But, it would be great to have menu >> item or shortcut to open the class being inspected in a browser. > > Of course, inspecting classes as normal objects should still be > possible using the inspector. > In essence, 'Object inspect' should still open the normal inspector. > > My comment relates to having the 'Class' link in the tree. I have > never wanted to inspect the class of an object at that level when > inspecting 'regular objects'. Instead, I want to know the Object's > class and use the convenient class browsers to find which methods the > object understands. > > cheers > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009