- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TaskIT Revealed

by Max Leske

Looks really cool! Everythingâs an object :) Does it run in older images? How hard, do you reckon, would it be to backport TaskIT to e.g. Pharo 1.4? Cheers, Max On 23.06.2014, at 00:39, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > > Hi all, im glad to announce TaskIT. You may already knew about, after all it's not confidential ;) and it has documentation on-going since some months ago. > > Task IT is package that provides a cool way to deal with processes. Even when this version is stable, it still in design and we want to make it consistent and powerfull. > > It counts with a chapter in pharo enterprise book and some cool tests. > > We have moved the main distribution repo to CAR > > http://smalltalkhub.com/#!/~CAR/TaskIT/ > > > The main easy things to do with this revision are: > > " closures " > val := [ 2+2 ] shootIt. > val isKindOf: TKTFuture. > val onSuccess: [: rslt | rslt == 4 ] "async" > val value == 4. " sync " > > rslt := [ 2+2 ] shootIt asResult. > rslt == 4 "sync on demand" > > " objects " > > val := 2 paralellize + 2. > val == 4 "sync on demand" > > > " staying in tune " > > val := [ "some task" ] shootIt asStickyReference. > > val := nil. > " sticky means that if this future is taken by the GC, it will kill the process" > > > > " looping " > > > val := server paralellize looping serveOnce: anyParameter asStickyReference. > > "this will execute in a new process, in a loop, server serveOnce: anyParameter." > > You can stop it by doing > val:= nil. > > "or using a disgusting magic variable, for that check the samples :). But do not rely on that kind of things, because it will not be supported " > > > > For more advanced and cool usages, check the Doc. > > > FAQ: > > 1- Yes, the "sync" on demand is implemented with a proxy and a become. > 2- Yes, we are changing the API of the processes that persist in time. > > CREDITS > All CAR team in general was great inspiration, particularly, Guille Polito full operational commiter and of course is always a good idea to discuss with him, Nick Papoylias, is also great to discuss with him. Luc, Noury, Jannik: several ideas are discussed with them as well, and they always gave me support. > > and from RMOD Esteban Lorenzano, also discussing and proposing. > > Thanks all :). > > > OTHERS: > If you want to go to the darkside (dark because is not documented yet, but in the case of PoolIT, that it has some doc ) you can also add to your combo: > ActIT: a simple Actor extention for taskit. > ForkIT: an extention that runs blocks in background image (it adds a nice button to the test runner, letting you run all your tests in a background image and installing the results after the execution) > PoolIT: it adds a pool of workers, it consumes tasks and ensure you a limited amount of threads. > PlanIT: a basic and not yet full developed algebra for composing processes. > > > > I encourage you to use it, it is being used in PhaROS since a lot of time. And please any bug and enhancements, you can contact us. Since we are working on the next version is a good time to define what features are really needed. > > > Salut. > > > Santiago. . > > > > > >

June 24, 2014

[ANN] Dr. Geo 17.07b

by Hilaire Fernandes

Another release: https://dl.dropboxusercontent.com/u/21633199/DrGeo.app-14.07c.zip I will be happy to read comments from Mac OS X users regarding this bug https://bugs.launchpad.net/drgeo/+bug/1331559 Thanks -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa

June 24, 2014

A Smalltalk job at Yesplan?

by Johan Brichau

Dear Smalltalkers, The Yesplan team is looking for a new development colleague! This is a full time position to be performed on site. We are not looking for a freelancer. Please see [1] for the full description of the vacancy. Dutch speakers can check out the Dutch version [2]. If you are interested, or if you have additional questions, please contact me via johan(a)yesplan.be Also, do not hesitate to forward this email to potential candidates. best regards Johan [1] http://yesplan.be/docs/vacancy-software-engineer.pdf [2] http://yesplan.be/docs/vacature-software-engineer.pdf

June 24, 2014

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Stephan Eggermont

This pull request might be relevant: https://github.com/pharo-project/pharo-vm/pull/49

June 24, 2014

Re: [Pharo-dev] SystemWindow instances can't be garbage-collected

by Max Leske

On 24.06.2014, at 15:30, Max Leske <maxleske(a)gmail.com> wrote: > For documentation purposes, this is what I found to be necessary to really clean all window instances. Note that this only works reliably when invoked from a non-UI process (e.g. via WAKom). > > > cleanupWindows > "in general: the gabage collector seems to be unable to resolve all circular dependencies with weak pointers. > This forces us to explicitly remove the weak pointers to enable garbage colltection. > It also seems to be a problem to invoke the cleanup from within a UI process (e.g. from a workspace). > Ergo: > - when invoked from a workspace not all instances may be garbage collected > - when invoked from a non UI process (e.g. WAKom) all instances should have been collected > - performning a manual garbage collection after having invoked this code from a workspace will > (usually) remove the pending instances (new process context)" > | count | > count := 1. > self > cleanupEvents; I forgot: #cleanupEvents is simply âEventManager cleanUp: trueâ > cleanupWorkspaces; > cleanupSystemWindows. > [ Smalltalk garbageCollect. count := count + 1 ] doWhileFalse: [ > SystemWindow allSubInstances isEmpty or: [ count > 5 "arbitrary number" ] ] > > cleanupWorkspaces > PluggableTextMorph allSubInstances do: [ :each | each > hasUnacceptedEdits: false; > askBeforeDiscardingEdits: false; > myDependents: nil ] > > cleanupSystemWindows > [ [ SystemWindow allSubInstances do: [ :window | > window > makeClosable; > delete ] ] > on: Error > do: [ :ex | > "may get here because we're trying to delete a window which has been deleted already." > ex return ]. > Smalltalk garbageCollect. > "already deleted but still hanging aroung (also see #cleanupEvents and #cleanupWorkspaces)" > SystemWindow allSubInstances > select: [ :e | e model isNil and: [ e owner isNil ] ] > thenDo: [ :e | > "clean some known places where references can prevent GC" > UITheme current focusIndicator: nil. > ActiveHand mouseOverHandler initialize. > ActiveHand keyboardFocus: nil. > World cleanseStepList. > "e.g. Workspace has a dependents array wich can point to the window" > (PointerFinder pointersTo: e) do: [ :p | > p class = DependentsArray ifTrue: [ > "the first pointer is the 'main' pointer in about 99% of the cases" > (PointerFinder pointersTo: p) first removeDependent: e ] ] ] > ] on: Error do: [ "ignoreâ ] > > > On 21.06.2014, at 23:11, Max Leske <maxleske(a)gmail.com> wrote: > >> Found the problem, documenting it here in case anybody else ever needs this (remember, this is 1.1.1). >> >> Open a debugger (e.g. by evaluating 1/0), then click into the lower right workspace and type something. OCompletion will now have added an entry to the EventManager actionMap with a ContextVariablesInspector instance as the key. There seems to be a cycle there that canât be resolved by the garbage collector, since I wasnât able to find any non weak global pointers (an OContext is referenced by an MessageSend in the action map. The OContext references a morph which is connected to the SystemWindow. Some of those morphs reference the ContextVariablesInspector as their model). >> Anyhow, it should be safe to send EventManager>>cleanUp: with argument true (actionMaps and their contents get recreated on demand), which will release those entries and allow the garbage collector to collect the SystemWindows, other morphs and the Debugger instances. >> >> Note that this is probably not an issue in later versions (e.g. 3.0 doesnât include EventManager anymore) but it might be relevant for later 1.x versions. >> >> Max >> >> >> On 21.06.2014, at 20:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 21.06.2014, at 18:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> >>>> On 21 Jun 2014, at 17:36, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>>> First off: >>>>> <rant>why do we have an IRC channel if nobody seems to be listening??</rant> >>>>> >>>>> too small community for an irc channel. My experience with irc is that 90-99% of people logged in at least are idle. For its size #pharo is quite active actually. >>>>> >>>> >>>> I am IRC when at work (and not forgetting to start the IRC client). But often when people ask questions it is exactly the wrong moment in time. >>>> I just *canât* instantly drop what I am doing an tend to the IRC channelâ¦ I really wonder how people do itâ¦ do they really stop their work right in the >>>> miiddle to answer questions? How are they productive? >>> >>> I fully agree. I was just momentarily pissed off :) >>> >>>> >>>> Marcus >>>> >>> >> >

June 24, 2014

Re: [Pharo-dev] SystemWindow instances can't be garbage-collected

by Max Leske

For documentation purposes, this is what I found to be necessary to really clean all window instances. Note that this only works reliably when invoked from a non-UI process (e.g. via WAKom). cleanupWindows "in general: the gabage collector seems to be unable to resolve all circular dependencies with weak pointers. This forces us to explicitly remove the weak pointers to enable garbage colltection. It also seems to be a problem to invoke the cleanup from within a UI process (e.g. from a workspace). Ergo: - when invoked from a workspace not all instances may be garbage collected - when invoked from a non UI process (e.g. WAKom) all instances should have been collected - performning a manual garbage collection after having invoked this code from a workspace will (usually) remove the pending instances (new process context)" | count | count := 1. self cleanupEvents; cleanupWorkspaces; cleanupSystemWindows. [ Smalltalk garbageCollect. count := count + 1 ] doWhileFalse: [ SystemWindow allSubInstances isEmpty or: [ count > 5 "arbitrary number" ] ] cleanupWorkspaces PluggableTextMorph allSubInstances do: [ :each | each hasUnacceptedEdits: false; askBeforeDiscardingEdits: false; myDependents: nil ] cleanupSystemWindows [ [ SystemWindow allSubInstances do: [ :window | window makeClosable; delete ] ] on: Error do: [ :ex | "may get here because we're trying to delete a window which has been deleted already." ex return ]. Smalltalk garbageCollect. "already deleted but still hanging aroung (also see #cleanupEvents and #cleanupWorkspaces)" SystemWindow allSubInstances select: [ :e | e model isNil and: [ e owner isNil ] ] thenDo: [ :e | "clean some known places where references can prevent GC" UITheme current focusIndicator: nil. ActiveHand mouseOverHandler initialize. ActiveHand keyboardFocus: nil. World cleanseStepList. "e.g. Workspace has a dependents array wich can point to the window" (PointerFinder pointersTo: e) do: [ :p | p class = DependentsArray ifTrue: [ "the first pointer is the 'main' pointer in about 99% of the cases" (PointerFinder pointersTo: p) first removeDependent: e ] ] ] ] on: Error do: [ "ignoreâ ] On 21.06.2014, at 23:11, Max Leske <maxleske(a)gmail.com> wrote: > Found the problem, documenting it here in case anybody else ever needs this (remember, this is 1.1.1). > > Open a debugger (e.g. by evaluating 1/0), then click into the lower right workspace and type something. OCompletion will now have added an entry to the EventManager actionMap with a ContextVariablesInspector instance as the key. There seems to be a cycle there that canât be resolved by the garbage collector, since I wasnât able to find any non weak global pointers (an OContext is referenced by an MessageSend in the action map. The OContext references a morph which is connected to the SystemWindow. Some of those morphs reference the ContextVariablesInspector as their model). > Anyhow, it should be safe to send EventManager>>cleanUp: with argument true (actionMaps and their contents get recreated on demand), which will release those entries and allow the garbage collector to collect the SystemWindows, other morphs and the Debugger instances. > > Note that this is probably not an issue in later versions (e.g. 3.0 doesnât include EventManager anymore) but it might be relevant for later 1.x versions. > > Max > > > On 21.06.2014, at 20:44, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 21.06.2014, at 18:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On 21 Jun 2014, at 17:36, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>>> First off: >>>> <rant>why do we have an IRC channel if nobody seems to be listening??</rant> >>>> >>>> too small community for an irc channel. My experience with irc is that 90-99% of people logged in at least are idle. For its size #pharo is quite active actually. >>>> >>> >>> I am IRC when at work (and not forgetting to start the IRC client). But often when people ask questions it is exactly the wrong moment in time. >>> I just *canât* instantly drop what I am doing an tend to the IRC channelâ¦ I really wonder how people do itâ¦ do they really stop their work right in the >>> miiddle to answer questions? How are they productive? >> >> I fully agree. I was just momentarily pissed off :) >> >>> >>> Marcus >>> >> >

June 24, 2014

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Yuriy Tymchuk

Wow, thanks, Guillermo, itâs working. Uko On 24 Jun 2014, at 12:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Actually in latest Pharo keyboard events are extended to get the pressed key: > > key > ^Smalltalk os keyForValue: keyValue > > I tested it in windows, mac and unix some time ago and it used to work :) > > On Tue, Jun 24, 2014 at 10:18 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Jun 24, 2014 at 10:07 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > sorry, if Iâm annoying with this question, but is there a way to handle keyboard events (on mac) in a normal way? Because keyUp and keyDown do not have any information about the key itself. I know that itâs a long story also related with vm but maybe someone made some hacks to solve this problem? > > Cheers > Uko > > The logic is in sqSqueakOSXApplication+events.m > > Now, I do not have the latest version but it is true that keyUp and keyDown are not handled very nicely there. > > KeyDown doesn't seem to have any code (but one could set something there as the code is available). KeyUp has something. > > I do not know why things are done this way. There may be side effects in the VM if one changes the way things are... > > Good luck. > > (void) recordCharEvent:(NSString *) unicodeString fromView: (NSView<sqSqueakOSXView> *) mainView { > sqKeyboardEvent evt; > unichar unicode; > unsigned char macRomanCharacter; > NSInteger i; > NSRange picker; > NSUInteger totaLength; > > evt.type = EventTypeKeyboard; > evt.timeStamp = (int) ioMSecs(); > picker.location = 0; > picker.length = 1; > totaLength = [unicodeString length]; > for (i=0;i < totaLength;i++) { > > > unicode = [unicodeString characterAtIndex: i]; > > if ([mainView lastSeenKeyBoardStrokeDetails]) { > evt.modifiers = [self translateCocoaModifiersToSqueakModifiers: [[mainView lastSeenKeyBoardStrokeDetails] modifierFlags]]; > evt.charCode = [[mainView lastSeenKeyBoardStrokeDetails] keyCode]; > } else { > evt.modifiers = 0; > evt.charCode = 0; > } > > if ((evt.modifiers & CommandKeyBit) && (evt.modifiers & ShiftKeyBit)) { /* command and shift */ > if ((unicode >= 97) && (unicode <= 122)) { > /* convert ascii code of command-shift-letter to upper case */ > unicode = unicode - 32; > } > } > > NSString *lookupString = [[NSString alloc] initWithCharacters: &unicode length: 1]; > [lookupString getBytes: &macRomanCharacter maxLength: 1 usedLength: NULL encoding: NSMacOSRomanStringEncoding > options: 0 range: picker remainingRange: NULL]; > [lookupString release]; > > evt.pressCode = EventKeyDown; > unsigned short keyCodeRemembered = evt.charCode; > evt.utf32Code = 0; > evt.reserved1 = 0; > evt.windowIndex = (int)[[mainView windowLogic] windowIndex]; > [self pushEventToQueue: (sqInputEvent *)&evt]; > > evt.charCode = macRomanCharacter; > evt.pressCode = EventKeyChar; > evt.modifiers = evt.modifiers; > evt.utf32Code = unicode; > > [self pushEventToQueue: (sqInputEvent *) &evt]; > > if (i > 1 || ![mainView lastSeenKeyBoardStrokeDetails]) { > evt.pressCode = EventKeyUp; > evt.charCode = keyCodeRemembered; > evt.utf32Code = 0; > [self pushEventToQueue: (sqInputEvent *) &evt]; > } > } > > interpreterProxy->signalSemaphoreWithIndex(gDelegateApp.squeakApplication.inputSemaphoreIndex); > > } > > --Phil > >

June 24, 2014

Re: [Pharo-dev] Stepping through with GLORP Proxies

by Esteban Lorenzano

On 24 Jun 2014, at 09:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi Stef, > > 2014-06-24 3:18 GMT-03:00 stepharo <stepharo(a)free.fr>: >> Esteban >> >> I would like to know how different are the Glorp proxies from the ones of >> Mariano. >> Because we are thinking about to get by default a nice proxy system. >> Proxies in the sense of object representing one that is not in the system >> (and not proxies >> as metaobject or representing an object that is around as in the JS >> literature). Ideally I would like >> to unify both. > > There's nothing much special about GLORP proxies, and maybe Mariano > knows better. > They have a common superclass named "AbstractProxy" (no NS), and they > work more like "remote references" than anything else. > > They are true proxies, it is, they hold a reference to the realobject, > but no #become is involved in the process. > Also proxies can "release" the referenced object and materialize it > back when needed (according to the proxy strategy). > > Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns > whether the referenced class is aClass (it is, aProxy isKindOf: Proxy > "false"), #= and #hash causes materialization of the referenced > object. > > Other than that I couldn't find anything else, it's a classical proxy, > with some ORM related stuff. yeah, thatâs why I said is not a problem of GLORP proxies but about our treatment of proxies in general :) Esteban > > Regards! >

June 24, 2014

Re: [Pharo-dev] Stepping through with GLORP Proxies

by Esteban A. Maringolo

Hi Stef, 2014-06-24 3:18 GMT-03:00 stepharo <stepharo(a)free.fr>: > Esteban > > I would like to know how different are the Glorp proxies from the ones of > Mariano. > Because we are thinking about to get by default a nice proxy system. > Proxies in the sense of object representing one that is not in the system > (and not proxies > as metaobject or representing an object that is around as in the JS > literature). Ideally I would like > to unify both. There's nothing much special about GLORP proxies, and maybe Mariano knows better. They have a common superclass named "AbstractProxy" (no NS), and they work more like "remote references" than anything else. They are true proxies, it is, they hold a reference to the realobject, but no #become is involved in the process. Also proxies can "release" the referenced object and materialize it back when needed (according to the proxy strategy). Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns whether the referenced class is aClass (it is, aProxy isKindOf: Proxy "false"), #= and #hash causes materialization of the referenced object. Other than that I couldn't find anything else, it's a classical proxy, with some ORM related stuff. Regards!

June 24, 2014

Re: [Pharo-dev] Handling keyboard eventsâ¦

by Guillermo Polito

Actually in latest Pharo keyboard events are extended to get the pressed key: key ^Smalltalk os keyForValue: keyValue I tested it in windows, mac and unix some time ago and it used to work :) On Tue, Jun 24, 2014 at 10:18 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Jun 24, 2014 at 10:07 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Hi everyone, >> >> sorry, if Iâm annoying with this question, but is there a way to handle >> keyboard events (on mac) in a normal way? Because keyUp and keyDown do not >> have any information about the key itself. I know that itâs a long story >> also related with vm but maybe someone made some hacks to solve this >> problem? >> >> Cheers >> Uko >> > > The logic is in sqSqueakOSXApplication+events.m > > Now, I do not have the latest version but it is true that keyUp and > keyDown are not handled very nicely there. > > KeyDown doesn't seem to have any code (but one could set something there > as the code is available). KeyUp has something. > > I do not know why things are done this way. There may be side effects in > the VM if one changes the way things are... > > Good luck. > > (void) recordCharEvent:(NSString *) unicodeString fromView: > (NSView<sqSqueakOSXView> *) mainView { > sqKeyboardEvent evt; > unichar unicode; > unsigned char macRomanCharacter; > NSInteger i; > NSRange picker; > NSUInteger totaLength; > evt.type = EventTypeKeyboard; > evt.timeStamp = (int) ioMSecs(); > picker.location = 0; > picker.length = 1; > totaLength = [unicodeString length]; > for (i=0;i < totaLength;i++) { > unicode = [unicodeString characterAtIndex: i]; > if ([mainView lastSeenKeyBoardStrokeDetails]) { > evt.modifiers = [self translateCocoaModifiersToSqueakModifiers: [[mainView > lastSeenKeyBoardStrokeDetails] modifierFlags]]; > evt.charCode = [[mainView lastSeenKeyBoardStrokeDetails] keyCode]; > } else { > evt.modifiers = 0; > evt.charCode = 0; > } > if ((evt.modifiers & CommandKeyBit) && (evt.modifiers & ShiftKeyBit)) { > /* command and shift */ > if ((unicode >= 97) && (unicode <= 122)) { > /* convert ascii code of command-shift-letter to upper case */ > unicode = unicode - 32; > } > } > NSString *lookupString = [[NSString alloc] initWithCharacters: &unicode > length: 1]; > [lookupString getBytes: &macRomanCharacter maxLength: 1 usedLength: NULL > encoding: NSMacOSRomanStringEncoding > options: 0 range: picker remainingRange: NULL]; > [lookupString release]; > evt.pressCode = EventKeyDown; > unsigned short keyCodeRemembered = evt.charCode; > evt.utf32Code = 0; > evt.reserved1 = 0; > evt.windowIndex = (int)[[mainView windowLogic] windowIndex]; > [self pushEventToQueue: (sqInputEvent *)&evt]; > evt.charCode = macRomanCharacter; > evt.pressCode = EventKeyChar; > evt.modifiers = evt.modifiers; > evt.utf32Code = unicode; > [self pushEventToQueue: (sqInputEvent *) &evt]; > if (i > 1 || ![mainView lastSeenKeyBoardStrokeDetails]) { > evt.pressCode = EventKeyUp; > evt.charCode = keyCodeRemembered; > evt.utf32Code = 0; > [self pushEventToQueue: (sqInputEvent *) &evt]; > } > } > > interpreterProxy->signalSemaphoreWithIndex(gDelegateApp.squeakApplication.inputSemaphoreIndex); > > } > > --Phil > >

June 24, 2014