- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > Â Â process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > +1 i am also missing: someThing ifTrue: 1 ifFalse: 0 > cheers > > Nicolas > > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

[Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

A current implementation of this method remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) ifNil: [ exceptionBlock value ] simply removes a previously registered object from registry and voila. Now lets get back to our discussion about multiple finalizers per object and using them in weak subscriptions etc. Suppose i am added a socket to weak registry, and suppose i am added a weak subscription to it. Now, if i do 'socket close' , it tells weak registry to remove it from list. And what we'll have: - socket handle is closed - socket is wiped from weak registry - but weak subscription still listed somewhere in a list of subscriptions My suggestion is, that upon #remove:, a weak registry should notify all executors that object of interest are no longer takes part in finalization scheme, so they should not count on receiving #finalize eventually. In other words: remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ | executor | executor := valueDictionary removeKey: oldObject ifAbsent: nil. executor discardFinalization. ]) ifNil: [ exceptionBlock value ] -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Esteban Lorenzano

Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > Hi, > > I cannot reproduce this. I took a PharoDev 1.1.1 and executed: > > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. > > Opening the System Settings browser works just fine. > > Cheers, > Doru > > > On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > >> Hi, >> I'm loading Glamour into a PharoDev 1.1.1 >> >> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >> load: 'Glamour' version: '2.0-beta.7'. >> >> and then try to open the settings browser... it raises a DNU >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

[Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. Thus we cannot write this xtream sentence process ifNotNil: #terminate. When the argument is not a block, Compiler should avoid inlining and just send a normal message. cheers Nicolas

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I cannot reproduce this. I took a PharoDev 1.1.1 and executed: Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. Opening the System Settings browser works just fine. Cheers, Doru On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > Hi, > I'm loading Glamour into a PharoDev 1.1.1 > > Gofer project repository: 'http://www.squeaksource.com/Glamour'; > load: 'Glamour' version: '2.0-beta.7'. > > and then try to open the settings browser... it raises a DNU > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Oct. 10, 2010

[Pharo-project] OCompletion usability

by Nicolas Cellier

Hi all, Thanks to Levente, I activated OCompletion in trunk. It's nice when typing a text from scratch (like in a workspace). But when modifying an existing text, not that great. The feature I most miss is the ability to overwrite a word fragment and hit cmd+j to repeat the replacement. Would it be possible to restore this behavior ? Nicolas

Oct. 10, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

OKay, now i see what the problem: <weak registry protected> <finalize items> <HostSystemMenusProxy>>finalize> .... <HostSystemMenusProxy class>>unregister> <weak registry protected> In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock. Then following piece: WeakRegistry>>finalizeValues self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. should be rewritten as: | expired | expired := OrderedCollection new. self protected: [ valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] ]. expired do: #finalizeValues. But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless. -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

[Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Esteban Lorenzano

Hi, I'm loading Glamour into a PharoDev 1.1.1 Gofer project repository: 'http://www.squeaksource.com/Glamour'; load: 'Glamour' version: '2.0-beta.7'. and then try to open the settings browser... it raises a DNU Cheers, Esteban

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Nicolas Cellier

2010/10/10 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, Nicolas Cellier wrote: > >> >> THE STATUS OF TESTS: >> >> Tests do not all pass. There seems to be a bug in Squeak >> #replace:from:to:with: when the replacement is the collection itself, >> moved to the right (this is with a COG VM). > > #replace:from:to:with: is not supposed to work for moves. IIRC the primitive > version uses memcpy (or strncpy), so moving to the left works just because > the undelying C function supports it. I used to (ab)use this feature though. > > > Levente > OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy. I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point. Nicolas

Oct. 10, 2010

[Pharo-project] Adding a new font in System like DejaVu fonts

by nullPointer

Now I know is possible add a new font, for use cross platform like DejaVu. I know Juan Vuletich did that but I donÂ´t know found the place of that is explained. Is heard do that? takes very space of image when the font is added? Many thanks for answers. -- View this message in context: http://forum.world.st/Adding-a-new-font-in-System-like-DejaVu-fonts-tp29701… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 10, 2010