May 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] something wrong with get.pharo.org

by Igor Stasenko

curl -L get.pharo.org/30 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2504 0 2504 0 0 41713 0 --:--:-- --:--:-- --:--:-- 65894 Please install curl or wget on your machine :( i have curl ^^, coz how else i could see that message! :) -- Best regards, Igor Stasenko.

May 6, 2013

[Pharo-project] Programming interactions with State Machines

by Carla F. Griggio

Hello everyone! I'm here to tell you that I started experimenting with a Pharo implementation of this idea: http://swingstates.sourceforge.net/. For those into UI programming I really recommend reading the first paper cited in that page. It's for programming user interface interactions with state machines, an approach to avoid the classical "callback spaghetti" that sometimes we get with event handlers everywhere. I have a tiny first step that shows an example for changing the color of a button on mouse over and changing it back to the original color on mouse out. You can download the code from: http://smalltalkhub.com/mc/CarlaGriggio/StateMachines/main Evaluate this for executing the example: SMButton openWithStateMachineInteraction And here is the code of the state machine for that example: SMButton class >> openWithStateMachineInteraction |button stateMachine iddle hover | button := self new. stateMachine := *SMStateMachine* newForWidget: button. iddle := (*SMState* newWithName:'iddle') enter:[:stMachine | stMachine widget color: Color yellow ]; addTransition: ((*SMTransition* forEvent: 'mouse enter' withOutputState: 'hover') transitionAction: [:stMachine | stMachine widget color: Color red ]). hover := (*SMState* newWithName:'hover') addTransition: (*SMTransition* forEvent: 'mouse out' withOutputState: 'iddle'); addTransition: (*SMTransition* forEvent: 'mouse enter' withOutputState: 'hover'). stateMachine addState: iddle; addState: hover. stateMachine attachTo: button. ^button openInWorld That code corresponds to the following states diagram: [image: Inline image 2] I will keep experimenting with this during the next weeks, and specially try to compare the pros and cons with regular event handling. Something cool about this approach is that the same widget could change its interactive behaviour on the fly by just attaching a different interaction state machine to it :) Also, I'm doing this for programming user interface interactions, but it could be useful for anything that can be modelled with a state pattern. Is there something similar out there already working? I was so eager to try this that I didn't look for related existing projects. Cheers! Carla.

May 6, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Igor Stasenko

On 5 May 2013 23:59, Max Leske <maxleske(a)gmail.com> wrote: > > On 05.05.2013, at 23:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 5 May 2013 22:19, Max Leske <maxleske(a)gmail.com> wrote: >>> Thanks Igor. >>> >>> I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? >>> I hope this doesn't seem like a dumb question, I'm just curious. >>> >> err.. im not sure i understand. You either do the type check or you >> don't, and then get error >> if you pass wrong object, or crash. There is no 3rd option :) > > Yes, that was the idea. Only with the thought of doing the type check for the user. Something like this: > > [ <perform call without typecheck> ] on: Error do: [ :e | (type isKindOf: expected) > ifTrue: [ NBCalloutFailed signal: 'expectedâ¦' ] > ifFalse: [ e pass ] ]. > > But that's only cool if possible without more VM crashes. > >> We can, however, introduce an option so you can turn strict type check on/off , >> or turn it off completely. > > That's a pretty cool idea actually. What about extending that idea: > 1. replace current typecheck with an #isKindOf: check > 2. add option to turn typecheck on / off. > > Then we'd have great feedback during development and would still be fast in production by disabling the typecheck. What do you think? > I will add the option. But default will be same like now e.g. strict obj class == class. Btw, what stops you from implementing own marshaller with semantics you want? In your case, make subclass of NBExternalObjectType, override methods there. Then to make your code use new marshaller, if you use MyClass in function signature e.g.: nbCall: #(void foo( MyClass param) ) create a MyClass class>>asNBExternalType: method, which will answer an instance of your new marshaller. (same what NBExternalObject does). -- Best regards, Igor Stasenko.

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Max Leske

On 05.05.2013, at 23:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 May 2013 22:19, Max Leske <maxleske(a)gmail.com> wrote: >> Thanks Igor. >> >> I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? >> I hope this doesn't seem like a dumb question, I'm just curious. >> > err.. im not sure i understand. You either do the type check or you > don't, and then get error > if you pass wrong object, or crash. There is no 3rd option :) Yes, that was the idea. Only with the thought of doing the type check for the user. Something like this: [ <perform call without typecheck> ] on: Error do: [ :e | (type isKindOf: expected) ifTrue: [ NBCalloutFailed signal: 'expectedâ¦' ] ifFalse: [ e pass ] ]. But that's only cool if possible without more VM crashes. > We can, however, introduce an option so you can turn strict type check on/off , > or turn it off completely. That's a pretty cool idea actually. What about extending that idea: 1. replace current typecheck with an #isKindOf: check 2. add option to turn typecheck on / off. Then we'd have great feedback during development and would still be fast in production by disabling the typecheck. What do you think? > >> >> On 05.05.2013, at 17:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 5 May 2013 12:14, Max Leske <maxleske(a)gmail.com> wrote: >>>> I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. >>>> >>>> Here's my use case: >>>> >>>> self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >>>> >>>> This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: >>>> >>>> self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >>>> >>>> But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. >>>> Being able to use a superclass would just be awesome! >>>> >>>> Cheers, >>>> Max >>> >>> As i told before, i am not using membership test, because it costs >>> extra cycles e.g.. >>> >>> object isKindOf: CommonSuperClass >>> >>> is much slower than >>> >>> object class == SomeSpecificClass >>> >>> if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: >>> it only checks that object belongs to specific class, doing >>> self verifyClassOf: oop is: objectClass generator: gen. >>> >>> The InterpreterProxy has >>> #includesBehavior:ThatOf: >>> method, which can be used to test if given class has some specific >>> ancestor in its inheritance chain. >>> >>> The main reason why i did not implemented the code that way is performance. >>> It is not that hard to implement this kind of test (see attached) >>> =========== >>> >>> Btw, we have a problem: >>> >>> - NativeBoost-Core in my 3.0 image shows that last version of it is >>> EstebanLorenzano.116 >>> there is not such package in NB repository. It is in Pharo30 repository.. >>> but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117 >>> >>> Name: NativeBoost-Core-EstebanLorenzano.118 >>> Author: EstebanLorenzano >>> Time: 23 April 2013, 5:52:38.099 pm >>> UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 >>> Ancestors: NativeBoost-Core-cb.117 >>> >>> which is not there. >>> Now i cannot merge with code which is in project repository. >>> >>> We should discuss, how we manage updates for NB.. because searching >>> packages located in >>> multiple repositories is tedious and counterproductive. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> <NBExternalType-verifyClassOfisMemberOfgenerator.st> >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 5, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by Sven Van Caekenberghe

On 05 May 2013, at 21:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. > > I still want to remove all the use of Transcript show: > > Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: > > Now I do not like traceCr: because it is not a cool message. > > So what do we do: > > 1) we use crLog:, logCr: > and deprecated log: > > > 2) we use crTrace:, trace: and traceCr: > > I really prefer solution 1 but I would like to hear from you. > > Stef I am for 1 as well, but I find #crLog: or #logCr: confusing - there should only be one system wide approach. Also, whether or not to add a Cr to a log message (or before or after it) is not a decision a client/user should have to make. Maybe Cr makes no sense, for example when log messages are added to a collection. So I am for #log: as a simple and clear message. The conflict with Number>>#log: is less important than that IMHO. Either we live with the conflict or we rename Number>>#log: to Number>>#logBase: or something like that. I also like the convention of #value being sent by #log: to its argument. That allows for blocks that are not evaluated when logging is disabled. My 2c. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Igor Stasenko

On 5 May 2013 22:19, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Igor. > > I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? > I hope this doesn't seem like a dumb question, I'm just curious. > err.. im not sure i understand. You either do the type check or you don't, and then get error if you pass wrong object, or crash. There is no 3rd option :) We can, however, introduce an option so you can turn strict type check on/off , or turn it off completely. > > On 05.05.2013, at 17:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 5 May 2013 12:14, Max Leske <maxleske(a)gmail.com> wrote: >>> I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. >>> >>> Here's my use case: >>> >>> self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >>> >>> This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: >>> >>> self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >>> >>> But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. >>> Being able to use a superclass would just be awesome! >>> >>> Cheers, >>> Max >> >> As i told before, i am not using membership test, because it costs >> extra cycles e.g.. >> >> object isKindOf: CommonSuperClass >> >> is much slower than >> >> object class == SomeSpecificClass >> >> if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: >> it only checks that object belongs to specific class, doing >> self verifyClassOf: oop is: objectClass generator: gen. >> >> The InterpreterProxy has >> #includesBehavior:ThatOf: >> method, which can be used to test if given class has some specific >> ancestor in its inheritance chain. >> >> The main reason why i did not implemented the code that way is performance. >> It is not that hard to implement this kind of test (see attached) >> =========== >> >> Btw, we have a problem: >> >> - NativeBoost-Core in my 3.0 image shows that last version of it is >> EstebanLorenzano.116 >> there is not such package in NB repository. It is in Pharo30 repository.. >> but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117 >> >> Name: NativeBoost-Core-EstebanLorenzano.118 >> Author: EstebanLorenzano >> Time: 23 April 2013, 5:52:38.099 pm >> UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 >> Ancestors: NativeBoost-Core-cb.117 >> >> which is not there. >> Now i cannot merge with code which is in project repository. >> >> We should discuss, how we manage updates for NB.. because searching >> packages located in >> multiple repositories is tedious and counterproductive. >> >> >> -- >> Best regards, >> Igor Stasenko. >> <NBExternalType-verifyClassOfisMemberOfgenerator.st> > > -- Best regards, Igor Stasenko.

May 5, 2013

[Pharo-project] looks like move to class side forgets the class message on the instance side

by StÃ©phane Ducasse

Hi I got SLLogObject>>error "To convey an error." level := self errorLevelString SLLogObject>>errorLevelString ^ 'error' then I did move to class side and â¦. SLLogObject>>error "To convey an error." level := self errorLevelString stayed the same. Does anybody encounter this problem? Stef

May 5, 2013

Re: [Pharo-project] [NativeBoost] Allow hierarchy of objects in function definition

by Max Leske

Thanks Igor. I wonder if it would be possible instead to simply accept any object and only use type checks in case of an error? In that case, extra cycles don't matter. Or would an incompatible object crash the VM? I hope this doesn't seem like a dumb question, I'm just curious. On 05.05.2013, at 17:43, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 May 2013 12:14, Max Leske <maxleske(a)gmail.com> wrote: >> I have a wish for NativeBoost (which is probably on your list anyway Igor, just wanted to put it out there): function definitions should be able to understand that I want to accept any object of a hierarchy. >> >> Here's my use case: >> >> self call: #(git_return_t git_object_lookup(LGitCommitExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> This function takes a pointer to any of LGitCommitExternal, LGitTreeExternal and LGitBlobExternal. The obvious way for me to do this was to create a superclass LGitObjectExternal and use that superclass in the function like so: >> >> self call: #(git_return_t git_object_lookup(LGitObjectExternal * object, git_repository_ptr repo, git_oid_ptr id, git_otype type)) >> >> But that gives me an error. So for now I can either use a dummy object (like NBExternalObject) and then convert from that or I have to implement the same function thrice in the different object flavors. >> Being able to use a superclass would just be awesome! >> >> Cheers, >> Max > > As i told before, i am not using membership test, because it costs > extra cycles e.g.. > > object isKindOf: CommonSuperClass > > is much slower than > > object class == SomeSpecificClass > > if you look at NBExternalObjectType>>pushAsValue: / pushAsPointer: > it only checks that object belongs to specific class, doing > self verifyClassOf: oop is: objectClass generator: gen. > > The InterpreterProxy has > #includesBehavior:ThatOf: > method, which can be used to test if given class has some specific > ancestor in its inheritance chain. > > The main reason why i did not implemented the code that way is performance. > It is not that hard to implement this kind of test (see attached) > =========== > > Btw, we have a problem: > > - NativeBoost-Core in my 3.0 image shows that last version of it is > EstebanLorenzano.116 > there is not such package in NB repository. It is in Pharo30 repository.. > but when i open it, it shows that it has ancestor NativeBoost-Core-cb.117 > > Name: NativeBoost-Core-EstebanLorenzano.118 > Author: EstebanLorenzano > Time: 23 April 2013, 5:52:38.099 pm > UUID: d256a011-ce1f-4959-b5ed-37de2c7f3b84 > Ancestors: NativeBoost-Core-cb.117 > > which is not there. > Now i cannot merge with code which is in project repository. > > We should discuss, how we manage updates for NB.. because searching > packages located in > multiple repositories is tedious and counterproductive. > > > -- > Best regards, > Igor Stasenko. > <NBExternalType-verifyClassOfisMemberOfgenerator.st>

May 5, 2013

Re: [Pharo-project] Pharo: an AMAZING community

by Benjamin

We also react this fast because we (I) know it will help a bunch of really cool guys :) Ben On May 5, 2013, at 4:13 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I sometimes take for granted how extraordinary our community is. This > morning, it sunk in a bit how magical it truly is... I brought up two issues > I was having (not even bugs)... in the middle of the night... on a > Saturday... And like the Smalltalk fairy had come and snuck a solution under > my pillow while I dreamt, Sven and Benjamin added enhancements which solved > my dilemma! Thank you both :) And thank you to everyone that's contributed > over these years to make Pharo and its community so special :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-an-AMAZING-community-tp4685837.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 5, 2013

[Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by StÃ©phane Ducasse

Hi guys Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. I still want to remove all the use of Transcript show: Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: Now I do not like traceCr: because it is not a cool message. So what do we do: 1) we use crLog:, logCr: and deprecated log: 2) we use crTrace:, trace: and traceCr: I really prefer solution 1 but I would like to hear from you. Stef

May 5, 2013