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

Re: [Pharo-project] NB Bug?

by Igor Stasenko

On 15 December 2011 23:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Thu, Dec 15, 2011 at 2:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 15 December 2011 10:28, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >> > On 14.12.2011 02:10, Igor Stasenko wrote: >> >> >> >> On 14 December 2011 01:17, Fernando Olivero<fernando.olivero(a)usi.ch> >> >> Â wrote: >> >>> >> >>> Igor, is this a bug? >> >>> >> >>> When parsing methods that send native functions withouth arguments , >> >>> void, theres a DNU. >> >>> For example in the following method: >> >>> >> >>> ^ self pangoCairoNbCall:#(PangoCairoFontMap >> >>> pango_cairo_font_map_get_default ( void ) ) >> >>> >> >>> >> >>> I fixed it like this: >> >>> >> >>> usesMethodArguments >> >>> "first check wether my single argument is void" >> >>> ^(fnSpec arguments size = 1 ==> Â [fnSpec arguments first class ~= >> >>> NBVoid]) and:[ fnSpec arguments anySatisfy: [:type | type loader >> >>> usesSTStack ] ] >> >>> >> >>> >> >> Well, the function signature syntax are not strictly following C. >> >> Just use empty parens for functions with no arguments. This is quite >> >> archaic C syntax, which is really not important to support. >> >> >> >> Or i can add this patch if you insist. :) >> > >> > >> > So you would say f.ex. >> > http://david.tribble.com/text/cdiffs.htm#C99-empty-parm >> > is incorrect? >> > >> >> in what context we're talking about? if this declaration in C code, >> then of course it could mean that it does not defines the arguments >> yet. >> But if we speaking about signature of function for callout, then i >> think it is clear what it stands for. > > > Are you? Â Since in C () means an unspecified argument list this could be the > way of declaring a varargs function, e.g. > > printf: arguments > Â Â <cdecl: printf ()> > > could insist on arguments being an array and automatically marshall all the > elements in it. > oh please. that's even less obvious usage :) there's a lot of different stuff in C syntax which you can play with. But it doesn't means that you need to routinely support everything in FFI callout specs. as i said, the function signature syntax are close to C syntax, but not strictly C. -- Best regards, Igor Stasenko.

Dec. 16, 2011

Re: [Pharo-project] When is a freeze a bug or me fiddling too much

by Schwab,Wilhelm K

Kasper, With all due respect to nearly everyone else here, and in other groups, (IMNSHO on this point), do not start with a morph. Draw on a bitmap/Form, and then display the result. It does wonders for allowing/forcing you to think about resolutions, resulting in code that has a chance of being reused on non-display devices (Windows has an advantage on that front - as much as I hate to admit they got something right<g>). The pattern I recommended in another post not only helps in reuse and portability to other dialects, it will (if you let it), help you to focus your breakpoints to things that matter to your code *before* the gui gets involved - recursive meltdown should be dramatically less likely as a result. HTH Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, December 16, 2011 3:34 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] When is a freeze a bug or me fiddling too much On 16.12.2011 09:25, Kasper Ãsterbye wrote: > Hi all, > > I have spend some time fiddling with Pharo, wonderful! > > I have always had a tendency to redefine vital methods in ST, and sometimes that kills it (typically it just hangs). Pharo seems a little more prone to that than what I was used to. In particular, I seem to have a tendency to spot methods where inserting a "self halt" will cause the pre-debugger to open a new pre-debugger to open a new pre-debugger to.... > > My question is - are there any guidelines on when I should just live with it, or if it is a bug? > > Best, > > Kasper Halting in a method used to display the debugger will break any smalltalk I regularily use, at least. Which is why I like using haltOnce :) Cheers, Henry

Dec. 16, 2011

Re: [Pharo-project] FFI is broken in Cog - success^2 [WAS] Re: Pharo 1.3 vs 1.2.1 some results for ConfigurationOfODBC - success

by Ben Coman

Dec. 16, 2011

[Pharo-project] [update 1.4] #14259

by Marcus Denker

14259 ----- Issue 5107: Warning: The method DialogItemsChooser>>openInWorld has been deprecated. http://code.google.com/p/pharo/issues/detail?id=5107 Issue 4949: Integer should be polymorphic with Fraction http://code.google.com/p/pharo/issues/detail?id=4949 -- Marcus Denker -- http://marcusdenker.de

Dec. 16, 2011

Re: [Pharo-project] When is a freeze a bug or me fiddling too much

by Henrik Sperre Johansen

On 16.12.2011 09:25, Kasper Ãsterbye wrote: > Hi all, > > I have spend some time fiddling with Pharo, wonderful! > > I have always had a tendency to redefine vital methods in ST, and sometimes that kills it (typically it just hangs). Pharo seems a little more prone to that than what I was used to. In particular, I seem to have a tendency to spot methods where inserting a "self halt" will cause the pre-debugger to open a new pre-debugger to open a new pre-debugger to.... > > My question is - are there any guidelines on when I should just live with it, or if it is a bug? > > Best, > > Kasper Halting in a method used to display the debugger will break any smalltalk I regularily use, at least. Which is why I like using haltOnce :) Cheers, Henry

Dec. 16, 2011

[Pharo-project] When is a freeze a bug or me fiddling too much

by Kasper Ãsterbye

Hi all, I have spend some time fiddling with Pharo, wonderful! I have always had a tendency to redefine vital methods in ST, and sometimes that kills it (typically it just hangs). Pharo seems a little more prone to that than what I was used to. In particular, I seem to have a tendency to spot methods where inserting a "self halt" will cause the pre-debugger to open a new pre-debugger to open a new pre-debugger to.... My question is - are there any guidelines on when I should just live with it, or if it is a bug? Would there be anyone interested in me collecting a list of the things that I stumble upon that make the image freeze? Best, Kasper

Dec. 16, 2011

Re: [Pharo-project] Old smalltalker is slightly lost

by Kasper Ãsterbye

Thanks all, It was in essence the drawOn: method I had not been able to figure out as the key, and some misunderstandings on the corners specifications of nested morphs. All your hints summarized to me getting going (and of cause the browsing of all the stuff in the image). Best, Kasper

Dec. 16, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Levente Uzonyi

On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote: > On 16.12.2011 00:40, Henrik Sperre Johansen wrote: >> On 15.12.2011 23:35, Mariano Martinez Peck wrote: >>> Well...it is much slower :( it seems that the cost of (aKey identityHash >>> + ( aKey mareaClass identityHash bitShift: 12) + (aKey basicSize bitShift: >>> 24) >>> is bigger than the colisions. >>> Anyway, thanks for the nice thread. I learned. >>> >>> Cheers >>> >> Well, first of all, that always creates a largeInteger, since identityHash >> is already shifted by 22... You'd want to be using basicIdentityHash. >> 2nd off, basicSize is useless for non-variable classes, which I guess is >> the common case. >> 3rd, putting class hash in the high bits won't really help much if you're >> serializing many instances of the same class, as they will all occupy a >> sequential hash range. >> >> So if I were you, I'd try with something like >> obj basicIdentityHash << 12 + (obj class basicIdentityHash) >> before discarding it outright due to computation cost. >> >> Cheers, >> Henry >> > Note: This is not portable to Squeak. > They kept the old version of identityHash (renamed to basicIdentityHash in > Pharo), and introduced scaledIdentityHash (doing the same as identityHash in > Pharo), due to backwards compatability concerns for users explicitly relying > on #identityHash returning a value in range [0, 4095]. I saw no benefit (and I still don't see any) of changing the behavior of #identityHash and using #basicIdentityHash, so I didn't integrate Martin's suggestion. It's just a side effect that "old code" still works in Squeak. Levente > > Cheers, > Henry > >

Dec. 16, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Levente Uzonyi

On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote: > On 16.12.2011 00:40, Henrik Sperre Johansen wrote: >> On 15.12.2011 23:35, Mariano Martinez Peck wrote: >>> Well...it is much slower :( it seems that the cost of (aKey identityHash >>> + ( aKey mareaClass identityHash bitShift: 12) + (aKey basicSize bitShift: >>> 24) >>> is bigger than the colisions. >>> Anyway, thanks for the nice thread. I learned. >>> >>> Cheers >>> >> Well, first of all, that always creates a largeInteger, since identityHash >> is already shifted by 22... You'd want to be using basicIdentityHash. >> 2nd off, basicSize is useless for non-variable classes, which I guess is >> the common case. >> 3rd, putting class hash in the high bits won't really help much if you're >> serializing many instances of the same class, as they will all occupy a >> sequential hash range. >> >> So if I were you, I'd try with something like >> obj basicIdentityHash << 12 + (obj class basicIdentityHash) >> before discarding it outright due to computation cost. >> >> Cheers, >> Henry >> > A few more points: > 1) don't use PluggableSets. Block activations are costly, and you REALLY need > specialized data/hash functions for it to be worth using. > 2) Even with a subclass of IdentitySet, it's hardly worth it: > > PluggableSet: > n := 1000000. > set := PluggableSet new: n. > set hashBlock: [:obj | obj basicIdentityHash << 12 + (obj class > basicIdentityHash) ]. > set equalBlock: [ :a :b | a == b ]. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] 18828 > > The one I suggested in a custom subclass: > n := 1000000. > set := PseudoIdentitySet new: n. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] 14182 > > Usual identitySet: > n := 1000000. > set := IdentitySet new: n. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] 4595 > > Custom subclass with a slightly modified hash (anObject identityHash + > (anObject class basicIdentityHash bitShift: 6)): > n := 1000000. > set := PseudoIdentitySet2 new: n. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] 3694 > Why 6 you ask? Because I'm worth it. > > Not really enough to justify the extra compexity, imho. How about my numbers? :) "Preallocate objects, so we won't count gc time." n := 1000000. objects := Array new: n streamContents: [ :stream | n timesRepeat: [ stream nextPut: Object new ] ]. set := IdentitySet new: n. Smalltalk garbageCollect. [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "4949" set := LargeIdentitySet new. Smalltalk garbageCollect. [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "331" set := (PluggableSet new: n) hashBlock: [ :object | object identityHash * 4096 + object class identityHash * 64 ]; "Change this to #basicIdentityHash in Pharo" equalBlock: [ :a :b | a == b ]; yourself. Smalltalk garbageCollect. [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "5511" I also have a LargeIdentityDictionary, which is relatively fast, but not as fast as LargeIdentitySet, because (for some unknown reason) we don't have a primitive that could support it. If we had a primitive like primitive 132 which would return the index of the element if found or 0 if not, then we could have a really fast LargeIdentityDictionary. Levente > > Cheers, > Henry > >

Dec. 16, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Henrik Sperre Johansen

On 16.12.2011 01:06, Henrik Sperre Johansen wrote: > > Usual identitySet: > n := 1000000. > set := IdentitySet new: n. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] > 4595 > > Custom subclass with a slightly modified hash (anObject identityHash + > (anObject class basicIdentityHash bitShift: 6)): > n := 1000000. > set := PseudoIdentitySet2 new: n. > Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] > 3694 > Why 6 you ask? Because I'm worth it. > > Not really enough to justify the extra compexity, imho. > > Cheers, > Henry > To put that a bit more in perspective, the extra cost for not preallocating to a sane value: n := 1000000. set := IdentitySet new. Time millisecondsToRun: [1 to: n do: [:waste | set add: Object new.]] 6872 Cheers, Henry

Dec. 16, 2011