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

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

by Dennis Schetinin

What about making level an object? log: messageString atLevel: levelObject -- Best regards, Dennis Schetinin 2013/5/6 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello. > > What about logging levels? > > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to > split log with levels: "self log info:", "self log debug:", "self log > trace:" > > Best regards, > Denis > > > 2013/5/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> 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 6, 2013

Re: [Pharo-project] Programming interactions with State Machines

by Yanni Chiu

On 05/05/13 8:31 PM, Carla F. Griggio wrote: > > I will keep experimenting with this during the next weeks, and specially > try to compare the pros and cons with regular event handling. I've always been curious to see how state machine transitions would map to Announcements/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 :) Changing the state machine is called "subtype migration" in Shlaer-Mellor parlance. It seems to get tricky when the supertype also has a state machine. > 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. The PostgreSQL Client [1] (a native Smalltalk client connection to a Postgres server) uses an internal state machine to drive the client/server connection. It was built with the Shlaer-Mellor method [2] concepts in mind. There was an accompanying state machine diagram drawn with the Connectors [3] tool (the link from SqueakMap is long dead, but I could try to dig up a copy). The implementation is very awkward around where the public API to make SQL queries interacts with the underlying state machine inside the PGConnection object. There's a loop that continues until a "good" state is reached. Then the result is gathered from the connection object. Since the code making the SQL query is not event-driven, nor is it part of the same state-machine architecture of the postgres client, the result is the awkward loop. I'd really like to see more examples of state machine usage. [1] http://www.squeaksource.com/PostgresV2.html [2] http://en.wikipedia.org/wiki/ShlaerâMellor_method [3] http://wiki.squeak.org/squeak/1773

May 6, 2013

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

by Tudor Girba

I like this proposal. Doru On May 6, 2013, at 8:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > What about logging levels? > > I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:" > > Best regards, > Denis > > 2013/5/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 > -- www.tudorgirba.com "Don't give to get. Just give."

May 6, 2013

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

by Denis Kudriashov

Hello. What about logging levels? I like "logInfo:", "logDebug:", "logTrace:". Or maybe it is better to split log with levels: "self log info:", "self log debug:", "self log trace:" Best regards, Denis 2013/5/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 6, 2013

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

by Max Leske

On 06.05.2013, at 00:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > Ok, cool. > > 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). Thanks for the advice. I'll do that. > > -- > Best regards, > Igor Stasenko. >

May 6, 2013

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

by Sven Van Caekenberghe

On 06 May 2013, at 04:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. That is indeed a funny message ;-)

May 6, 2013

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

by S Krish

I mentioned in another thread. #crLog, #logCr are intuitive and perfectly fine. Also hook Loggers first class into the system ( Toothpick ) and make it default to Transcript with these messages routed to the Logger. Transcript cr / current #crLog is akin to cout / System.out.println .. mostly deprecated in enterprise coding practices. On Mon, May 6, 2013 at 3:04 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 6, 2013

[Pharo-project] WhatsUp from: 2013-05-06 until: 2013-05-19

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2013-05-19 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

May 6, 2013

Re: [Pharo-project] Programming interactions with State Machines

by Igor Stasenko

I did something similar (experiment). I introduced a mode stack for my morphs. So, all morphs has an initial "default" mode on stack. When mouse enters the morph, a new mode "over" pushed on stack. So, the "state" is not singular, it is composite. The intent to use stack of modes was to associate a visual style (and any properties , in general for each mode). For example, in default mode, the morph's color is red, but when 'over' mode pushed on stack, it overrides color property with blue. This means, that to get a property, morph asks top-most mode (on stack) if it defines it, and if not, goes to next one, up until default mode, which responds with default value(s) for all properties. Another example, is "disabled" mode.. when this mode is on stack, it prevents "over" mode to be pushed. So, you can imagine, that when morph being dragged, it has "dragged" mode on stack, or if it in some transition (showing sliding/zooming animation), it has "animated mode" and so on. In my experiment i even made a draw method to be a property of mode.. so morph's draw method looks like: drawOn: aCanvas "Draw a morph by using method, supplied by current mode" | method | method := mode styleAt: #drawMethod. ^ self perform: method with: aCanvas like that, i could able to even control how morph is drawn, not just changing the colors. On 6 May 2013 02:31, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > 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. > -- Best regards, Igor Stasenko.

May 6, 2013

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

by Benjamin

Work for me :( Ben On May 6, 2013, at 4:42 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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