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

[Pharo-project] [ANN] Aida 6.3 Holiday Edition, first beta

by Janko MivÅ¡ek

Dear Smalltalkers, No holidays for Aida! Too many happenings on the web front and we are busy to up-to-date support the new HTML5 features in pure Smalltalk spirit: with simplicity, elegance and consistence in mind. Don't believe? Try it by downloading one-click Pharo image from: http://www.aidaweb.si/download. New features: * HTML5 Geolocation support added, * asynchronous non-blocking tree-like control flow, * security: XSS attack protection, delay after failed login, whitelisted IPs * Jtalk (Smalltalk over JavaScript) library added * sites can be now enabled/disabled, besides start/stop Enhancements: * realtime (WebSocket and Comet) support refactored * hierarchical form support enhanced * stats on sites page update in real-time More in Release notes: http://www.aidaweb.si/release-notes-6.3 Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 12, 2011

[Pharo-project] [Cog] new builds available on hudson

by Igor Stasenko

A new version includes support of rule 41 in BitBlt plugin, which makes a lot of difference when you using freetype. For downloading , follow one of these links: Cog VMs: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Unix/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Mac-Carbon/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog-Win32/ Stack VMs: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM-Mac-Carbon/ https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackWin32/ Mac Cocoa builds will be updated once Esteban verify the build. :) -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

[Pharo-project] [update 1.3] #13286

by Igor Stasenko

13286 ----- Issue 4509: new old Transcript compatibility broken http://code.google.com/p/pharo/issues/detail?id=4509 -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] Another OB2 issue ( Fwd: [RSUG] Ð ÐµÐºÑÑÑÐ¸Ð²Ð½ÑÐµ Ð¾ÑÐ¸Ð±ÐºÐ¸)

by Igor Stasenko

Okay, so the workaround is like this: handleMouseEnter: anEvent controller editor ifNotNil: [ self activeHand newKeyboardFocus: controller editor morph]. anEvent wasHandled: true. How where to commit this patch to OCompletion? Any takers, because i don't have any idea :) -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] Jenkins: build scripts are now in public repository

by Igor Stasenko

On 12 July 2011 16:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Tue, Jul 12, 2011 at 2:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 12 July 2011 10:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Igor, >>> >>> please publish then server versions of build scripts like build13.sh, >> >> build.sh on git is based on build13.sh. The old build.sh was different >> in a way how it handles image stalls. >> There was loop waiting for output from image. And if nothing happens >> it kills VM process. >> Now since in 1.3 this is much less likely to happen (because it using >> non-interactive ui manager), >> we removed that. >> >>> build-kernel.sh etc. too. >>> >> it almost the same as build.sh.. but there are some difference. i >> started to examine it yesterday but >> then came home :) > > I wrote it so I know how it differs ;-) I only want to see the current > version used on server and make it available to others > Yes. i will convert your script to use $WORKSPACE var and push it to git. (and update job accordingly). Once it there you will be able to modify it by yourself. -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] Jenkins: build scripts are now in public repository

by Pavel Krivanek

On Tue, Jul 12, 2011 at 2:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 12 July 2011 10:58, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Igor, >> >> please publish then server versions of build scripts like build13.sh, > > build.sh on git is based on build13.sh. The old build.sh was different > in a way how it handles image stalls. > There was loop waiting for output from image. And if nothing happens > it kills VM process. > Now since in 1.3 this is much less likely to happen (because it using > non-interactive ui manager), > we removed that. > >> build-kernel.sh etc. too. >> > it almost the same as build.sh.. but there are some difference. i > started to examine it yesterday but > then came home :) I wrote it so I know how it differs ;-) I only want to see the current version used on server and make it available to others -- Pavel >> -- Pavel >> >> On Mon, Jul 11, 2011 at 7:47 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 11 July 2011 19:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>>> What I great change. I think I have asked Marcus about them like 10 times :) >>> >>> So, i think you asked for a reason? :) >>> Because now you have commit rights to this repository, nothing >>> prevents you from doing what you wanted to do :) >>> >>> The changes are quite simple: >>> Â - avoid using absolute paths (instead use $WORKSPACE) environment variable >>> all scripts are starting from: >>> >>> if [ -z "$WORKSPACE" ] ; then >>> Â Â Â Â WORKSPACE=`pwd` >>> fi >>> >>> so, you can run them on your local machine, and they will work same on server. >>> Of course if you don't make stupid mistakes... ( bah it's so easy to >>> look like an idiot with these bash scripts. I have bash/sh !!!) >>> >>> When you need to invoke VM , use PHARO_VM environment variable. Which >>> is set on slave to point to VM. >>> Like: >>> exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" -headless >>> >>> Of course, for testing freshly built VMs it may point to another >>> place, but scripts will remain same. >>> >>> (tomorrow i will start migrating VM jobs from hudson to jenkins) >>> Jenkins is more appeal and seems to be less buggy. :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

July 12, 2011

Re: [Pharo-project] Socket objects created twice ?

by Igor Stasenko

On 12 July 2011 15:17, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Rather than changing the handle (making it harder to associate the handle with the "real" socket), it would be nicer to have a SocketFinalizer or something - it could even be a subclass of socket?? > I just thought about it after posting previous mail. Yes it would be nice to add an explicit class, named SocketFinalizer and then add an inst var to Socket - a finalizer. Then when you deleting a socket, a socket could tell a finalizer to nil-out handle, instead of asking WeakRegistry to unregister the socket which is much slower. And a finalization action for nilled out handle will be no-op, once already closed socket become garbage. In that way, someday we could eliminate the #remove: protocol from WeakRegistry. -- Best regards, Igor Stasenko AKA sig.

July 12, 2011

Re: [Pharo-project] keymappings question

by Guillermo Polito

Actually, I was thinking that for custom applications, the right way is to attach the shortcuts to the model of your morph/application instead of the morph. Look at how the shortcuts are attached to the TextMorph. They are attached to the SmalltalkEditor or TextEditor (instead of TextMorph), and TextMorph redefines #kmDispatcher to match & delegate to the model. If you still need shortcuts attached to an specific instance, it should not be much difficult but I've no time right now to do it :(. Guille On Tue, Jul 12, 2011 at 5:13 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Ahh, I thought that the latest version of Keymappings handles shortcuts per > morph instance. It looks like it does not, and this is bad news for me :(. > > I want to use them in the context of Glamour and for that I need to control > the shortcuts of morph instances. > > How difficult is it to get it working? > > Cheers, > Doru > > > On 12 Jul 2011, at 01:04, Guillermo Polito wrote: > > > > > > > On Mon, Jul 11, 2011 at 6:24 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi, > > > > I wanted to play with Keymappings, but I got stuck right at the start :). > > > > I have two problems: > > > > 1. I would like to add a simple shortcut (e.g., "$o command") to a text > morph instance. So I have: > > > > textMorph := TextMorph new contents: 'abcdefgh'. > > "what is the magic invocation here ?" > > textMorph openInWindow > > > > The shortcuts are defined via the keymapping pragma. A shortcut is > attached by now to a particular class and not just an instance. Look at the > examples (the ones defined by Camillo, Laurent or me) and tell me if they > are understandable, hehe. > > > > > > The question is what should I write in the second line? > > > > Nothing. Keymappings are "static" right now. > > > > > > > > 2. I would like to disable existing shortcuts from the text morph. How > should I do that? > > > > Look at where the shortcuts are defined for TextMorph and remove the > declarations. And you shold also reset the KMRepository. > > > > But removing keymapping declarations doesn't guarantee the removal in > TextMorph since the default -old- shortcut handling is still there. > Keymapping is just intercepting them by now. > > > > Hope this helps, > > Guille > > > > > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > > > "What we can governs what we wish." > > > > > > > > > > -- > www.tudorgirba.com > > "Value is always contextual." > > > >

July 12, 2011

Re: [Pharo-project] Socket objects created twice ?

by Schwab,Wilhelm K

Rather than changing the handle (making it harder to associate the handle with the "real" socket), it would be nicer to have a SocketFinalizer or something - it could even be a subclass of socket?? ________________________________________ 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: Tuesday, July 12, 2011 8:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket objects created twice ? On 12.07.2011 13:38, Sven Van Caekenberghe wrote: > Hi All, > > I encountered something that I do not understand. I tried this in 1.2.2 and 1.4 with both my normal, older CogVM as well as the lastest one by Estaban. > > In a normal clean image, there would be not Socket instances. > > Socket allInstances size = 0 > > Now create any kind of Socket > > Socket new (or newTCP, newUDP) > > Now > > Socket allInstances size = 2 > > So Smalltalk reports two instances, but it seems they share the same socketHandle and semaphores, so one seems to be a shallow copy of the other. > > (Close the one instance, 3 timesRepeat: [ Smalltalk garbageCollect ] and they are both gone). > > Is this normal ? > Is there really only one OS level socket ? > Does this have to do with Sockets being in a WeakRegistry ? > > It is confusing to say the least. > > Sven Yes it's normal, one is the finalizer of the other. To differentiate them more easily, you could do Socket >> actAsFinalizer socketHandle := socketHandle bitInvert. and finalize self primSocketDestroyGently: socketHandle bitInvert. This will (99.9% likely at least) give a printstring of invalidSocketHandle for the finalizing Socket instance. Cheers, Henry

July 12, 2011

Re: [Pharo-project] Socket objects created twice ?

by Henrik Sperre Johansen

On 12.07.2011 14:54, Sven Van Caekenberghe wrote: > OK thanks, Henry. > > This behavior is then to be expected for all objects registered for finalization I guess. If using the defaults, then yes. It's not a general requirement though, you can specify whichever executor you want by using WeakRegistry#add:executor: to register , change the executor used in #add: by reimplementing #finalizer, etc. Cheers, Henry

July 12, 2011