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

Re: [Pharo-project] Zinc HTTPS

by GÃ¶ran Krampe

Hi! On 09/12/2011 12:35 PM, Sven Van Caekenberghe wrote: > The problem is that the new SocketStream implementation worked fine for me during development (on Mac), but later I found out that there are subtle but critical problems on the other platforms. Just a few words about the SocketStream implementation. I wrote the current incarnation of SocketStream (unless it has changed under Pharo - haven't looked) and one important aspect of the rewrite was to make it much faster than the old code written originally by Bolot Kerimbaev back in... ancient times. Basically two things make it fast: - As little copying as possible. - Making sure code lands on good primitives. An example of the former is the logic involved in dealing with the buffer growing etc. An example of the latter is upToAll: that could be written naively and end up using next, next for each byte. Ouch. Anyway, there are indeed some methods in SocketStream that "hurts the eyes", like upToAll: but that is mainly because we are lacking a primitive for searching that has a "stopAt" argument. I never got around to extending the one we have with such an argument. regards, GÃ¶ran

Sept. 13, 2011

[Pharo-project] [update 1.4] #14137/#14138

by Marcus Denker

14137 ----- Issue 4596: WeakOrderedColllection array is replaced by an Array instead of a WeakArray (UNDO the UNDO... part1) 14138 ----- Issue 4596: WeakOrderedColllection array is replaced by an Array instead of a WeakArray (UNDO the UNDO... part2). Remove OrderedCollection #grow and #growSize -- Marcus Denker -- http://marcusdenker.de

Sept. 13, 2011

Re: [Pharo-project] vm test volunteers

by Esteban Lorenzano

Hi, El 12/09/2011, a las 4:28p.m., Dave Mason escribiÃ³: > Seems to work on Leopard (loads my image - I think Pharo-1.2). But if I go into Settings and set full-screen mode, Cmd-Tab and keyboard space change keys no longer work. I think that's what is supposed to happen. Or at least, that's what is happening in my system with older vm's too. cheers, Esteban > > ../Dave > > On 2011-Sep-12, at 11:25 , Esteban Lorenzano wrote: > >> I'm testing a new cog build, and I need to see if it works in OSX 10.5 (leopard) and 10.6 (snow leopard). I'm currently own a 10.7, and can't check if it works fine in older versions :( >> can someone check if the build works with older versions? >

Sept. 13, 2011

Re: [Pharo-project] MethodContext #tempScopedNames vs #tempAt

by Eliot Miranda

Hi Phillipe, On Mon, Sep 12, 2011 at 11:06 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > While trying to debug the debugger in Seaside (hi Mike) I stumbled on > something funny. Seaside the following code to work: > > Semaphore forMutualExclusion critical: [ > | sender | > sender := thisContext sender. > sender tempAt: sender tempScopedNames size ] > This just won't work with the Closure compiler. This approach only worked with old blue-book blocks Squeak. Instead you need to look at DebuggerMethodMap, tempNamesForContext:, namedTempAt: et al. > But it doesn't, you get a SubscriptOutOfBounds. #tempScopedNames answers > #('mutuallyExcludedBlock' 'blockValue' 'caught'). The method arguments > (mutuallyExcludedBlock) can be found in > self tempAt: 1 > the temps can be found in > self tempAt: 2 > > Which means that > sender tempNamed: 'blockValue' > will answer #(nil true) instead of the real value (nil). This is very > confusing. > > This is with the latest Pharo 1.3 and Cog .r2489 > > Cheers > Philippe > > > -- best, Eliot

Sept. 12, 2011

Re: [Pharo-project] about keybinder

by Guillermo Polito

Ok, now, you can do the following in a workspace for example: w := SystemWindow new. tm := PluggableTextMorph on: TestObject text: #some accept: #some. w addMorph: tm frame: (0@0 corner: 1@1). w openInWorld. tm textMorph on: $x asShortcut, $a alt do: [UIManager inform: 'works?']. tm textMorph on: $x asShortcut, $x alt do: [UIManager inform: 'true, true']. On Mon, Sep 12, 2011 at 1:23 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Not yet! > > > On Mon, Sep 12, 2011 at 12:54 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: > >> I guess it is still not usable per morph instance, right? >> >> Cheers, >> Doru >> >> >> On 12 Sep 2011, at 17:31, StÃ©phane Ducasse wrote: >> >> > Hi guys >> > >> > we need some beta testers too :) >> > >> > Stef >> > >> > Begin forwarded message: >> > >> >> From: Guillermo Polito <guillermopolito(a)gmail.com> >> >> Date: September 12, 2011 4:21:53 PM GMT+02:00 >> >> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Cc: benjamin Van Ryseghem <benjamin.vanryseghem(a)gmail.com> >> >> Subject: Re: about keybinder >> >> >> >> I've just had success downloading it on 1.4. Try this: >> >> >> >> Gofer it >> >> squeaksource: 'ShortWays'; >> >> package: 'Keymapping-Core'; >> >> package: 'Keymapping-Tests'; >> >> package: 'Keymapping-Settings'; >> >> package: 'Keymapping-Pragmas'; >> >> package: 'Keymapping-Shortcuts'; >> >> load >> >> >> >> BTW, I've only tested it on linux (ubuntu). But I think Laurent and >> Esteban used it on mac. Just in case, you have some test cases. >> >> >> >> Cheers, >> >> Guille >> >> >> >> On Mon, Sep 12, 2011 at 10:58 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> No stress >> >> we all have the same :) >> >> >> >> On Sep 12, 2011, at 3:24 PM, Guillermo Polito wrote: >> >> >> >> > Hi! I'll tell you asap. >> >> > >> >> > These two last weeks I was burning in stuff queued during my absence. >> >> > >> >> > Guille :) >> >> > >> >> > On Mon, Sep 12, 2011 at 9:53 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >> > Hi guillermo >> >> > >> >> > could you let us know if we can load key binder in Pharo 1.4 so that >> we can start to migrate. >> >> > I hope you are going ok. >> >> > >> >> > Stef >> >> > >> >> >> >> >> > >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> >

Sept. 12, 2011

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

by Alain Plantec

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. 12, 2011

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

by Alain Plantec

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). follow #menuBarIn:. Hope that helps a little. Cheers Alain

Sept. 12, 2011

Re: [Pharo-project] vm test volunteers

by Dave Mason

Seems to work on Leopard (loads my image - I think Pharo-1.2). But if I go into Settings and set full-screen mode, Cmd-Tab and keyboard space change keys no longer work. ../Dave On 2011-Sep-12, at 11:25 , Esteban Lorenzano wrote: > I'm testing a new cog build, and I need to see if it works in OSX > 10.5 (leopard) and 10.6 (snow leopard). I'm currently own a 10.7, > and can't check if it works fine in older versions :( > can someone check if the build works with older versions?

Sept. 12, 2011

[Pharo-project] Windows with nested top menu

by Torsten Bergmann

see http://lists.gforge.inria.fr/pipermail/pharo-project/2011-September/053648.… Any comments? -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Sept. 12, 2011

[Pharo-project] MethodContext #tempScopedNames vs #tempAt

by Philippe Marschall

Hi While trying to debug the debugger in Seaside (hi Mike) I stumbled on something funny. Seaside the following code to work: Semaphore forMutualExclusion critical: [ | sender | sender := thisContext sender. sender tempAt: sender tempScopedNames size ] But it doesn't, you get a SubscriptOutOfBounds. #tempScopedNames answers #('mutuallyExcludedBlock' 'blockValue' 'caught'). The method arguments (mutuallyExcludedBlock) can be found in self tempAt: 1 the temps can be found in self tempAt: 2 Which means that sender tempNamed: 'blockValue' will answer #(nil true) instead of the real value (nil). This is very confusing. This is with the latest Pharo 1.3 and Cog .r2489 Cheers Philippe

Sept. 12, 2011