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

Re: [Pharo-project] Issue 3864 in pharo: [Failing Test] 1.3 ImageSegmentTestExport

by pharo＠googlecode.com

Updates: Status: FixToInclude Comment #1 on issue 3864 by marianopeck: [Failing Test] 1.3 ImageSegmentTestExport http://code.google.com/p/pharo/issues/detail?id=3864 To fix this, browse the class WordArrayForSegment and change its superclass to WordArray instead of the Obsolete one. After, evaluate the following: Smalltalk fixObsoleteReferences. BalloonEngine initialize. DataStream initialize. DeflateStream initialize. FastInflateStream initialize. ZipConstants initialize. ZipWriteStream initialize. PNGReadWriter initialize. Once that is done, all ImageSgement tests are green.

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Mariano Martinez Peck

On Fri, Mar 25, 2011 at 7:08 PM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > > What do you think? >>> >> >> I am for... for the JIT is is a monomorphic send to a primitive, so the IC >> will be very effective >> and should take care that the lookup is actually almost never done. (and >> the lookup is the >> only thing the #class bytecode saves, as the target method is a >> primitive). >> > I think that programmers should have the illusion that the VM interacts > with the system through message sends. By being able to overwrite this > particular message you break this illusion. The VM will just fetch the real > class; but the user doesn't get access to it anymore. Telling the system > that this particular message shouldn't be overwritten is probably a good > thing. > > If you want to overwrite the method class, maybe your tools should send > another message than class in the first place? > Of course I can do that. I can also do (ParseNode classVarNamed: 'StdSelectors') removeKey: #class ifAbsent: []. Compiler recompileAll. I don't care. I have it working for my "usage". This was just an example. And don't compare #class with all the boolean methods like #ifNil: and friends or the bytecodes for integer operations....I think #class is sent far less times than those... > > I do however agree that many other optimizations become slightly > superfluous, such as bytecodes for integer operations ... that somehow seems > like compile-time inline-cached behavior without the ability to flush the > cache :) > > cheers, > Toon > >

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Marcus Denker

On Mar 25, 2011, at 7:09 PM, Toon Verwaest wrote: > >>> What do you think? >> >> I am for... for the JIT is is a monomorphic send to a primitive, so the IC will be very effective >> and should take care that the lookup is actually almost never done. (and the lookup is the >> only thing the #class bytecode saves, as the target method is a primitive). > I think that programmers should have the illusion that the VM interacts with the system through message sends. By being able to overwrite this particular message you break this illusion. Why that? I think exactly the opposite is true. If I write self class I think that I send #class to self. But in the current system I do not. If #class is not send, one can never ever do proxies that work for real. A proxy can never stand in for an object as #class always answers "Proxy", even though it should not. Or for a Future it will say "Future". > The VM will just fetch the real class; but the user doesn't get access to it anymore. Telling the system that this particular message shouldn't be overwritten is probably a good thing. > One should take care, but a system that just does not allow things like this *even if you take care* is bad. > If you want to overwrite the method class, maybe your tools should send another message than class in the first place? > So what if it's not a tool? It might be domain code that really does self class == something as part of execution. Now I want ot use a proxy here, but I can not. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 25, 2011

Re: [Pharo-project] Issue 2848 in pharo: Deprecate String>>asUrl

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 2848 by stephane...(a)gmail.com: Deprecate String>>asUrl http://code.google.com/p/pharo/issues/detail?id=2848 I proposed that we do not integrate this one event if this is me that proposed it.

March 25, 2011

Re: [Pharo-project] Issue 3341 in pharo: use #= for integer comparison instead of #==

by pharo＠googlecode.com

Updates: Status: FixToInclude Comment #5 on issue 3341 by stephane...(a)gmail.com: use #= for integer comparison instead of #== http://code.google.com/p/pharo/issues/detail?id=3341 (No comment was entered for this change.)

March 25, 2011

Re: [Pharo-project] Remove #class as a Compiler optimization

by Toon Verwaest

>> What do you think? > > I am for... for the JIT is is a monomorphic send to a primitive, so > the IC will be very effective > and should take care that the lookup is actually almost never done. > (and the lookup is the > only thing the #class bytecode saves, as the target method is a > primitive). I think that programmers should have the illusion that the VM interacts with the system through message sends. By being able to overwrite this particular message you break this illusion. The VM will just fetch the real class; but the user doesn't get access to it anymore. Telling the system that this particular message shouldn't be overwritten is probably a good thing. If you want to overwrite the method class, maybe your tools should send another message than class in the first place? I do however agree that many other optimizations become slightly superfluous, such as bytecodes for integer operations ... that somehow seems like compile-time inline-cached behavior without the ability to flush the cache :) cheers, Toon

March 25, 2011

Re: [Pharo-project] Issue 3718 in pharo: Color class>>wheel: should be (back) on class side

by pharo＠googlecode.com

Updates: Status: Closed Comment #6 on issue 3718 by stephane...(a)gmail.com: Color class>>wheel: should be (back) on class side http://code.google.com/p/pharo/issues/detail?id=3718 in 13111

March 25, 2011

Re: [Pharo-project] Issue 3850 in pharo: remove HTTPServerDirectory PseudoFileStream

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3850 by stephane...(a)gmail.com: remove HTTPServerDirectory PseudoFileStream http://code.google.com/p/pharo/issues/detail?id=3850 in 13111

March 25, 2011

Re: [Pharo-project] [update 1.3] #13110

by Miguel CobÃ¡

El vie, 25-03-2011 a las 18:34 +0100, StÃ©phane Ducasse escribiÃ³: > 13110 > ----- > > - Issue 3881: Problem with Inst var refs.... Thanks Benjamin van Ryseghem. > - Issue 3879: Wipe out positional arguments cruft from compiler. Thanks Igor Stasenko. > - Issue 3859: Pluggin control. Thanks Igor Stasenko. > - Issue 3715: Workspace shouting after switching between shout/unshout. Thanks Benjamin van Ryseghem. > - Cleaning MCPackageManager. > - Fixing some as yet unclassified categories. > > Stef and igor happy integrating and chatting about life :) .. the universe and everything? 42! -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 25, 2011

Re: [Pharo-project] Issue 3850 in pharo: remove HTTPServerDirectory PseudoFileStream

by pharo＠googlecode.com

Comment #1 on issue 3850 by stephane...(a)gmail.com: remove HTTPServerDirectory PseudoFileStream http://code.google.com/p/pharo/issues/detail?id=3850 the file is empty

March 25, 2011