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

[Pharo-project] [update 1.3] #13307

by Marcus Denker

13307 ----- Issue 4548: Explorer wont browse the explored class http://code.google.com/p/pharo/issues/detail?id=4548 -- Marcus Denker -- http://marcusdenker.de

Sept. 13, 2011

Re: [Pharo-project] Zinc HTTPS

by Sven Van Caekenberghe

On 13 Sep 2011, at 13:10, GÃ¶ran Krampe wrote: > I could and will try to squeeze it in, but I am mainly hacking Jtalk these days :) OK >> The cool thing is: all of Zn's +170 unit tests, most doing actual HTTP client and server interactions (some over the internet) succeed using the new Zodiac socket stream implementation. > > Have you also measured performance? Compared to old SocketStream? Just curious. No, not yet, but it feels OK ;-) I think it is quite a challenge to measure socket stream performance objectively. > The earliest SocketStream by Bolot also used an internal object for each "direction" of the stream - a BufferStream I think it was called. And nuking those to make SocketStream operate directly on buffers with the ability to move "pointers" etc was one of the main optimizations in order to minimize copying etc. Yes, one of my goals is to prevent copying and moving bytes around as much as possible. The most optimized version, the one at the bottom of the hierarchy, ZnSocketStream, never copies the data (say a large byte array) that you write, and reads directly into the buffers that you provide - provided you use the right methods of course, i.e. those based on #next: count putAll: collection startingAt: offset and #readInto: collection startingAt: offset count: requestedCount But the first goals are correctness and good unit and functional test coverage.

Sept. 13, 2011

Re: [Pharo-project] should I use cocoa-blessed or cocoa?

by Alexandre Bergel

The last version with all the green tests. Alexandre On 13 Sep 2011, at 04:50, Mariano Martinez Peck wrote: > When you load something with Metacello, what do you want? bleedingEdge or stable? ;) > > On Tue, Sep 13, 2011 at 9:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > on jenkins > > Stef > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2011

Re: [Pharo-project] [update 1.4] #14139

by Alexandre Bergel

Thanks Marcus! Alexandre On 13 Sep 2011, at 08:37, Marcus Denker wrote: > 14139 > ----- > > Issue 4548: Explorer wont browse the explored class > http://code.google.com/p/pharo/issues/detail?id=4548 > > Issue 4786: Tests for System-Support and added Behavior>>referencedClasses > http://code.google.com/p/pharo/issues/detail?id=4786 > > Issue 4789: Improve the way morphs communicate with model > http://code.google.com/p/pharo/issues/detail?id=4789 > > > -- > Marcus Denker -- http://marcusdenker.de > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2011

[Pharo-project] [update 1.4] #14139

by Marcus Denker

14139 ----- Issue 4548: Explorer wont browse the explored class http://code.google.com/p/pharo/issues/detail?id=4548 Issue 4786: Tests for System-Support and added Behavior>>referencedClasses http://code.google.com/p/pharo/issues/detail?id=4786 Issue 4789: Improve the way morphs communicate with model http://code.google.com/p/pharo/issues/detail?id=4789 -- Marcus Denker -- http://marcusdenker.de

Sept. 13, 2011

Re: [Pharo-project] Zinc HTTPS

by GÃ¶ran Krampe

On 09/13/2011 10:20 AM, Sven Van Caekenberghe wrote: > I respect the current SocketStream: it is used by all of us everyday and it works reliably. > The problem is that its code base has grown in all kinds of directions and in complexity. I will have to take a look in Pharo, because I haven't really looked since I rewrote it. > Today it is pretty hard to understand since it is not clear if all code that is there is relevant. > Also, subclassing it to build a secure socket stream is pretty difficult. > > The Zodiac streams are an experiment in rewriting [secure] socket stream. > > I would be honored if you would take some time to look at the code and give some feedback I could and will try to squeeze it in, but I am mainly hacking Jtalk these days :) > The cool thing is: all of Zn's +170 unit tests, most doing actual HTTP client and server interactions (some over the internet) succeed using the new Zodiac socket stream implementation. Have you also measured performance? Compared to old SocketStream? Just curious. The earliest SocketStream by Bolot also used an internal object for each "direction" of the stream - a BufferStream I think it was called. And nuking those to make SocketStream operate directly on buffers with the ability to move "pointers" etc was one of the main optimizations in order to minimize copying etc. regards, GÃ¶ran

Sept. 13, 2011

Re: [Pharo-project] shift of -1@0 when clicking a morph

by Mariano Martinez Peck

On Tue, Sep 13, 2011 at 11:27 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Have you checked to morph's bounds in case the origin/corner has non > Integer values? > I've seen odd behaviour when they are Floats or Fractions. > > yes, like putting them into a PointArray. Floats for example will lose the decimal part. > (just a stab-in-the-dark, worth checking though) > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> > To: <Pharo-project(a)lists.gforge.**inria.fr<Pharo-project(a)lists.gforge.inria.fr> > > > Sent: Saturday, September 10, 2011 7:34 PM > Subject: Re: [Pharo-project] shift of -1@0 when clicking a morph > > > > Just to stress this issue a bit more: > > The problem is critical for getting Mondrian to work properly with Glamour > (be able to get the interaction from the visualization in the surrounding > browser), and it is a show stopper for releasing Moose 4.6. Any help would > be appreciated. > > Cheers, > Doru > > > On 10 Sep 2011, at 08:40, StÃ©phane Ducasse wrote: > > >> On Sep 10, 2011, at 2:06 AM, Alexandre Bergel wrote: >> >> Hi! >>> >>> In Pharo 1.3 13287 I am experiencing something very strange. Apparently, >>> when I click a morph the mouseOver: event has a x value reduced by 1. This >>> happens only when I click. Subsequent mouseOver: are fine. This triggers an >>> odd behavior in Mondrian. >>> >> >> Strange indeed. >> >> >>> In Pharo 1.4 14112, this strange behavior has disappeared. >>> >>> I tried to load some more recent packages of Morphic, Graphics, >>> Polymorph... without success (either I get an emergency debugger or the >>> image freezes). >>> >>> Maybe: http://code.google.com/p/**pharo/issues/detail?id=4503<http://code.google.com/p/pharo/issues/detail?id=4503>? But I could not find the Slice. >>> >> >> No I do not think this is related >> >> Stef >> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~**:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.**;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> >> > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the > right one." > > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 13, 2011

Re: [Pharo-project] Windows with nested top menu

by Gary Chambers

Hi See UITheme class>>exampleWindowWithToolbars. There is support in (Toggle)MenuItems for "keyText" (showing a description of a keyboard shortcut) though the actual keyboard handling must be implemented yourself where it is required. Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec(a)yahoo.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 12, 2011 9:18 PM Subject: Re: [Pharo-project] Windows with nested top menu > On 12/09/2011 21:35, Alain Plantec wrote: >> On 12/09/2011 20:59, Torsten Bergmann wrote: >>> see >>> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-September/053648.… >>> >>> >>> Any comments? >> Hi Torsten, >> >> The settings has a menu (only one menu button). > The SettingBrowser has a menu ... >> follow #menuBarIn:. >> Hope that helps a little. >> Cheers >> Alain >> >> >> > >

Sept. 13, 2011

Re: [Pharo-project] shift of -1@0 when clicking a morph

by Gary Chambers

Have you checked to morph's bounds in case the origin/corner has non Integer values? I've seen odd behaviour when they are Floats or Fractions. (just a stab-in-the-dark, worth checking though) Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, September 10, 2011 7:34 PM Subject: Re: [Pharo-project] shift of -1@0 when clicking a morph Just to stress this issue a bit more: The problem is critical for getting Mondrian to work properly with Glamour (be able to get the interaction from the visualization in the surrounding browser), and it is a show stopper for releasing Moose 4.6. Any help would be appreciated. Cheers, Doru On 10 Sep 2011, at 08:40, StÃ©phane Ducasse wrote: > > On Sep 10, 2011, at 2:06 AM, Alexandre Bergel wrote: > >> Hi! >> >> In Pharo 1.3 13287 I am experiencing something very strange. Apparently, >> when I click a morph the mouseOver: event has a x value reduced by 1. >> This happens only when I click. Subsequent mouseOver: are fine. This >> triggers an odd behavior in Mondrian. > > Strange indeed. > >> >> In Pharo 1.4 14112, this strange behavior has disappeared. >> >> I tried to load some more recent packages of Morphic, Graphics, >> Polymorph... without success (either I get an emergency debugger or the >> image freezes). >> >> Maybe: http://code.google.com/p/pharo/issues/detail?id=4503 ? But I could >> not find the Slice. > > No I do not think this is related > > Stef >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Sept. 13, 2011

[Pharo-project] HashProof

by HwaJong Oh

At page 202 in the book Pharo by Exmaple, it says: "A difficult error to spot is when you redefine = but not hash. The symptoms are that you will lose elements that you put in sets or other strange behaviour. ..." I have come up of an idea that can blow this away. HashProof is a trait that guarantees that #hash and #= are defined correctly. If you file in this http://forum.world.st/file/n3809543/HashProof.st HashProof.st , You will see HashProofTrait computes #= and #hash by using an array answered by the trait user by sending message #gettersForEquality. HashProofUser uses HashProofTrait. Try example below, u := HashProofUser new. u x:1. u y:2. u z:3. v := HashProofUser new. v x:1. v y:2. v z:3. u = v. User of the HashProofTrait is meets an error undefined message #gettersForEquality, when it was first sent #= or #hash. Therefore, it is very clear what he has to do to make #= and #hash work flawlessly. HwaJong Oh -- View this message in context: http://forum.world.st/HashProof-tp3809543p3809543.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 13, 2011