- Pharo-dev - lists.pharo.org

[Pharo-project] bug on dictionary?
by Esteban Lorenzano May 14, 2012

May 14, 2012

Hi, I have this issue: Dictionary with: #one->'ONE' with: #two->'TWO' "This gives me a correct Dictionary with keys #one, #two and values 'ONE', 'TWO'" Dictionary withAll: {#one->1 with: #two->2} "This gives me a Dictionary with keys 1,1 and values #one->'ONE', #two->'TWO' So... I think one of both is incorrect... or at least, the API sucks because is too confusing. cheers, Esteban

4 8

[Pharo-project] Singleton access selector
by Sean P. DeNigris May 14, 2012

May 14, 2012

I've noticed we use a buffet of accessors for singletons, like #default, #instance, #current... it'd be nice to just pick one. I like #instance, but could live with any as long as I never have to guess which one from a list again :) Sean -- View this message in context: http://forum.world.st/Singleton-access-selector-tp4630062.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

5 7

[Pharo-project] FileBrowser/FileList rant
by Nicolas Cellier May 14, 2012

May 14, 2012

Hi, it seems that FileBrowser/FileList is never used... And I absolutely don't understand some design choices. 1) Having a single reference inst var for both selectedDirectory and selectedFile : this is a bug factory, see http://code.google.com/p/pharo/issues/detail?id=5881 and http://code.google.com/p/pharo/issues/detail?id=5884 for example of bugs (I could open 1 bug entry per menu item I guess) 2) auto-selecting the file item under pop-up menu click This is a windows thing and anti-Smalltalk-UI-custom This is not at all uniform in the rest of Pharo UI (not even on the directory list) The implementation is buggish (see ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate of ttp://code.google.com/p/pharo/issues/detail?id=5625) There was (and still is) a specific menu when no file is selected... fileListMenu: aMenu reference ifNil: [^ self noFileSelectedMenu: aMenu] ifNotNil: [^ self fileSelectedMenu: aMenu]. I don't want to argue whether or not FileList did deserve a clean-up, I'm quite sure it did. And I also agree that we can temporarily break things in development images. But when the clean-up is so far from anything functional, I just wonder who do you want to eat the dog food? I'm a bit sick of it ;) Nicolas

3 2

[Pharo-project] Nautilus feedback - format of history pulldown combo box
by Ben Coman May 14, 2012

May 14, 2012

In Nautilus there is a combo box spanning and underneath the protocol and method panes which I shall presume to call the 'history pulldown' where items are display like: MyObject -> myMethod: (1) The usual convention in most documentation seems to be: MyObject >> myMethod: (2) Now it strangely feels uncomfortable to getting used to (1). Is there a strong directive to move away from (2), or could this be used instead of (1). cheers -ben

2 1

Re: [Pharo-project] [Seaside] Zinc as static file server
by Sven Van Caekenberghe May 14, 2012

May 14, 2012

On 12 May 2012, at 19:17, Paul DeBruicker wrote: >> BTW, we (or I) definitively need to add If-Modified-Since and 304 Not Modified behavior to ZnZincStaticServerAdaptor. >> > > OK. I added that to the version I just uploaded. I'll have a look later on (I have little time this weekend). We also need at least one simple test (another one of Marcus' quotes; if there is no actively run test, it does not exist). We just need an extra version of #testIfModifiedSinceNotModified directly on a local server, it will require some setup, be it should be doable. >> And I know that you know, but let me repeat that in production situations you definitively have to let apache or nginx serve the statis files, to take load of Seaside. >> > > Yes definitely. > >> Your hack in ZnSeasideStaticServerAdaptorDelegate>>#handleRequest: lets Seaside first try and make an error before you consider static file serving, this almost defeats the purpose of not doing it by Seaside itself. Just a hunch, I haven't tested or benchmarked this. > > Does Seaside have the ability to serve files from disk without loading them into a WAFileLibrary? I couldn't figure that out, or gave up before trying really. I edit all my CSS and JS in emacs and its a pain to reload after saving/committing. And for my use case the performance is fine. Yes, your use case is perfectly valid. Sven

1 1

[Pharo-project] Pharo Kernel job working again
by Pavel Krivanek May 14, 2012

May 14, 2012

Hi, the Pharo Kernel job working again. This two issues are related: http://code.google.com/p/pharo/issues/detail?id=5890&thanks=5890&ts=1336981… http://code.google.com/p/pharo/issues/detail?id=5889&thanks=5889&ts=1336981… Cheers, -- Pavel

1 0

[Pharo-project] [update 2.0] #20073
by Marcus Denker May 14, 2012

May 14, 2012

20073 ----- Issue 5887: Less Sensor hardcoded http://code.google.com/p/pharo/issues/detail?id=5887 Issue 5839: TestRunner Run Coverage fails. http://code.google.com/p/pharo/issues/detail?id=5839 Issue 5876: StringMorphAttributeScanner>>initializeFromStringMorph: http://code.google.com/p/pharo/issues/detail?id=5876 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [squeak-dev] Fun with spock (NativeBoost FFI)
by Marcus Denker May 14, 2012

May 14, 2012

On May 14, 2012, at 12:49 AM, Igor Stasenko wrote: > On 14 May 2012 00:03, Lawson English <lenglish5(a)cox.net> wrote: >> [pharo-project list added back in] >> >> >> On 5/13/12 1:34 PM, Nicolas Cellier wrote: >>> >>> [100000 primeSwingFactorial] timeToRun 3411 [100000 factorial] timeToRun >>> 61219 So gmp is still 40x faster than a reasonably optimized Smalltalk >>> factorial... I think that's fair, because gmp is highly optimized. Since >>> cost is dominated by LargeInteger arithmetic, and since Smalltalk >>> LargeInteger arithmetic in primitives still operates on bytes, I'm not so >>> surprised of the gap... I'd like to see a 64bit image operating on 32 bits >>> positive integers digits, that would already be a progress... Nicolas >> >> >> For me, the most interesting thing would be to figure out how to integrate >> such external libraries more tightly into the language syntax. >> >> Right now, x := 3.14159... always creates a Float, which is stored as a >> double. >> >> x class ===> Float. >> >> What if I wanted to generate a gmplib floating point number (or rational or >> large integer) automatically when the gmplib binding is available? For Floats, there is a GNU project maintained by some groups at Inria: http://www.mpfr.org/ The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for double-precision floating-point arithmetic (53-bit significand). -- Marcus Denker -- http://marcusdenker.de

1 0

May 14, 2012

Hi I'm cleaning Sensor use so that we end up with a better layered system. Now I see this method and I wonder (replacing Sensor by hand does not work. But I do not understand why this methods has to explicitly invoke runStepMethodsâ¦ to me it looks like a broken behavior due probably to the lack of a functionality or ticking behavior. What do you think? fromHand: hand "Let the user draw a polygon, clicking at each vertex, and ending by clicking within 5 of the first point..." "self fromHand: ActiveHand" | p1 poly oldVerts pN opposite | Cursor crossHair showWhile: [[Sensor anyButtonPressed] whileFalse: [self currentWorld displayWorldSafely; runStepMethods]. p1 := Sensor cursorPoint]. opposite := (Display colorAt: p1) negated. opposite = Color transparent ifTrue: [opposite := Color red]. (poly := LineMorph from: p1 to: p1 color: opposite width: 2) openInWorld. oldVerts := {p1}. self currentWorld displayWorldSafely; runStepMethods. [true] whileTrue: [[Sensor anyButtonPressed] whileTrue: [pN := Sensor cursorPoint. poly setVertices: (oldVerts copyWith: pN). self currentWorld displayWorldSafely; runStepMethods]. (oldVerts size > 1 and: [(pN dist: p1) < 5]) ifTrue: [hand position: Sensor cursorPoint. "Done -- update hand pos" ^ (poly setVertices: (poly vertices copyWith: p1)) delete]. oldVerts := poly vertices. [Sensor anyButtonPressed] whileFalse: [pN := Sensor cursorPoint. poly setVertices: (oldVerts copyWith: pN). self currentWorld displayWorldSafely; runStepMethods]].

3 5

Re: [Pharo-project] Strange logic in PolygonMorph>>fromHand: hand
by Fernando Olivero May 13, 2012

May 13, 2012

Indeed is weird. I think it has to explicitly call runStepMethods, because it's not forking , thus taking control of the ui process, does it make sense? I would remove the method (and all the similar ones found in the image, that explicitly reference Sensor and while doing "true whileTrue:[ ...]", if needed it would be have to re-done using the new event model with announcements. Fernando On Sun, May 13, 2012 at 10:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm cleaning Sensor use so that we end up with a better layered system. > Now I see this method and I wonder (replacing Sensor by hand does not work. > But I do not understand why this methods has to explicitly invoke runStepMethodsâ¦ to me it looks like a broken behavior > due probably to the lack of a functionality or ticking behavior. > > What do you think? > > fromHand: hand > Â Â Â Â "Let the user draw a polygon, clicking at each vertex, and ending > Â Â Â Â Â Â Â Â by clicking within 5 of the first point..." > Â Â Â Â "self fromHand: ActiveHand" > > Â Â Â Â | p1 poly oldVerts pN opposite | > Â Â Â Â Cursor crossHair showWhile: > Â Â Â Â Â Â Â Â [[Sensor anyButtonPressed] whileFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [self currentWorld displayWorldSafely; runStepMethods]. > Â Â Â Â Â Â Â Â p1 := Sensor cursorPoint]. > Â Â Â Â opposite := (Display colorAt: p1) negated. > Â Â Â Â opposite = Color transparent ifTrue: [opposite := Color red]. > Â Â Â Â (poly := LineMorph from: p1 to: p1 color: opposite width: 2) openInWorld. > Â Â Â Â oldVerts := {p1}. > Â Â Â Â self currentWorld displayWorldSafely; runStepMethods. > Â Â Â Â [true] whileTrue: > Â Â Â Â Â Â Â Â [[Sensor anyButtonPressed] whileTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [pN := Sensor cursorPoint. > Â Â Â Â Â Â Â Â Â Â Â Â poly setVertices: (oldVerts copyWith: pN). > Â Â Â Â Â Â Â Â Â Â Â Â self currentWorld displayWorldSafely; runStepMethods]. > Â Â Â Â Â Â Â Â (oldVerts size > 1 and: [(pN dist: p1) < 5]) ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [hand position: Sensor cursorPoint. Â "Done -- update hand pos" > Â Â Â Â Â Â Â Â Â Â Â Â ^ (poly setVertices: (poly vertices copyWith: p1)) delete]. > Â Â Â Â Â Â Â Â oldVerts := poly vertices. > Â Â Â Â Â Â Â Â [Sensor anyButtonPressed] whileFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [pN := Sensor cursorPoint. > Â Â Â Â Â Â Â Â Â Â Â Â poly setVertices: (oldVerts copyWith: pN). > Â Â Â Â Â Â Â Â Â Â Â Â self currentWorld displayWorldSafely; runStepMethods]]. > >

2 1