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

Re: [Pharo-project] shortcuts in PluggableTextMorph

by Tudor Girba

Hi, This is what I am doing right now and it does not work: (PluggableTextMorph on: textModel ...) onKeyStrokeSend: #keystroke:from: to: textModel ... GLMTextModel>>keystroke: anEvent from: aMorph anEvent anyModifierKeyPressed ifTrue: [ "check the do the shortcut work" ] When it gets to GLMTextModel>>keystroke:from:, the text model is already modified. Cheers, Doru On 13 Jul 2011, at 10:45, Lukas Renggli wrote: > Note that your handler method must return either true or false, > depending if it handled the event or not. > > Lukas > > On 13 July 2011 10:43, Lukas Renggli <renggli(a)gmail.com> wrote: >> In OB we use >> >> aPluggableTextMorph textMorph >> on: #keyStroke send: #keyStroke: to: self. >> >> Lukas >> >> On 13 July 2011 10:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I need a bit of help in trying to add some kind of shortcuts to PluggableTextMorph. The following code used to work for shortcuts like "CMD+o": >>> >>> (PluggableTextMorph >>> on: textModel >>> ...) >>> onKeyStrokeSend: #keystroke:from: to: textModel >>> GLMTextModel>>keystroke: anEvent from: aMorph >>> anEvent anyModifierKeyPressed ifTrue: [ "check the do the shortcut work" ] >>> >>> >>> However, in the recent Pharo 1.3, if I press "CMD+o", first the "o" is added to the text as a regular character, and then keystroke:from: is executed. >>> >>> Is there a way of capturing the event before it gets interpreted by the Morph? Or is there another solution? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every now and then stop and ask yourself if the war you're fighting is the right one." >>> >>> >>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

July 13, 2011

[Pharo-project] Fuel vs. StOMP (answer to blog post of Runar Jordahl)

by Mariano Martinez Peck

Hi guys. Several people asked several times the differences between the two "new" serializers Fuel and StOMP. Runar wrote several blog posts about it: http://blog.epigent.com/2011/07/new-smalltalk-object-serializers-fuel.html http://blog.epigent.com/2011/07/comparing-speed-of-stomp-and-fuel.html http://blog.epigent.com/2011/07/fuel-and-stomp-best-of-both.html So I would like to give you my point of view as a Fuel developer. Which are the main differences between Fuel and StOMP? 1) Portability. What that means? "portability" is too wide to just talk without details. For me, portability in this case means two things: portable format and portable code. Portable format: In a dialect/language XXX be able to materialize a stream which was serialized in a dialect/language YYY. Portable code: That the code of the serializer can also work in another dialect/language (not necessary including portable format). Fuel will does not do focus in portable format. At least, we will not do extra effort to support that. Regarding portable code, it is not Fuel first goal to be portable to other dialects but it is not that difficult anyway. In fact, Fuel has been even ported to Newspeak. In the contrary to Fuel, StOMP wants to be portable in both ways, format and code. But of course, it is difficult to find portable representation of certain objects like BlockClosure, MethodContext, Class, Trait, etc. StOMP do not deal which such objects due to the lack of those portable representations. In Fuel, we can serialize those objects but not in a portable way. So...next differences are: 2) In Fuel we want to be able to correctly serialize *any* kind of object. 3) Fuel will try to get the fastest way to serialize or materialize an object. StOMP will use the most fastest available while trying to generate a portable representation. 4) Another important difference is that Fuel is faster in materialization and StOMP in serialization. Why? Because a tool build on top of Fuel will be used for code management and loading is done much more times than saving (think as in parcels). Notice that this doesn't mean we are slow in serialization. We are faster than most of the serializers, but not as much as StOMP. What are the reasons of the differences in performance? because of their design and internals. It is a trade-off. To be faster at materialization, we do some extra work in serialization. StOMP does not do extra optimization for materialization and hence serialization is faster. What is that "extra" we do? Ok, we have wrote a whole paper for IWST 2011 so I won't repeat myself. I will let you know when we get the notifications of the paper so that we can make it public. Regarding your excellent paragraph: "But... A partial solution would be to use an intermediate format for *serialization*. This format would support fast serialization, and therefore be similar to StOMP's format. The intermediate format would for example be used when a user needs to quickly commit changes to a database. Later, the intermediate format could be transformed to a format that is better optimized for *deserialization*. This transformation would typically be done as a background task. The deserializer would be able to (transparently) understand both the intermediate format and the optimized format." I can just tell you that it is an excellent idea and we talked with Martin about it, but I am not sure about how easier it would be. Maybe it is just easier to have 2 serializers with 2 different goals :) Regarding "To me it appears like StOMP has better support for serialization/deserialization "hook" methods<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods>, class renaming<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/renaming> and shape changing<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/shapechangers>. Hopefully, Fuel can learn from StOMP in this field." I totally agree. StOMP's hook methods are awesome and we want to have the same in Fuel. In fact, check the issue tracker and you will see several open issues regarding this :) I think class renaming and shape changing are fine in Fuel. Finally, notice that we are not "competitors". We have sent several private emails between us and Masashi UMEZAWA and we are trying to share as much as possible. -- Mariano http://marianopeck.wordpress.com

July 13, 2011

Re: [Pharo-project] shortcuts in PluggableTextMorph

by Lukas Renggli

Note that your handler method must return either true or false, depending if it handled the event or not. Lukas On 13 July 2011 10:43, Lukas Renggli <renggli(a)gmail.com> wrote: > In OB we use > > Â aPluggableTextMorph textMorph > Â Â Â on: #keyStroke send: #keyStroke: to: self. > > Lukas > > On 13 July 2011 10:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I need a bit of help in trying to add some kind of shortcuts to PluggableTextMorph. The following code used to work for shortcuts like "CMD+o": >> >> Â (PluggableTextMorph >> Â Â Â Â Â Â Â Â on: textModel >> Â Â Â Â Â Â Â Â ...) >> Â Â Â Â Â Â Â Â onKeyStrokeSend: #keystroke:from: to: textModel; >> GLMTextModel>>keystroke: anEvent from: aMorph >> Â Â Â Â anEvent anyModifierKeyPressed ifTrue: [ "check the do the shortcut work" ] >> >> >> However, in the recent Pharo 1.3, if I press "CMD+o", first the "o" is added to the text as a regular character, and then keystroke:from: is executed. >> >> Is there a way of capturing the event before it gets interpreted by the Morph? Or is there another solution? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every now and then stop and ask yourself if the war you're fighting is the right one." >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

July 13, 2011

Re: [Pharo-project] shortcuts in PluggableTextMorph

by Lukas Renggli

In OB we use aPluggableTextMorph textMorph on: #keyStroke send: #keyStroke: to: self. Lukas On 13 July 2011 10:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I need a bit of help in trying to add some kind of shortcuts to PluggableTextMorph. The following code used to work for shortcuts like "CMD+o": > > Â (PluggableTextMorph > Â Â Â Â Â Â Â Â on: textModel > Â Â Â Â Â Â Â Â ...) > Â Â Â Â Â Â Â Â onKeyStrokeSend: #keystroke:from: to: textModel; > GLMTextModel>>keystroke: anEvent from: aMorph > Â Â Â Â anEvent anyModifierKeyPressed ifTrue: [ "check the do the shortcut work" ] > > > However, in the recent Pharo 1.3, if I press "CMD+o", first the "o" is added to the text as a regular character, and then keystroke:from: is executed. > > Is there a way of capturing the event before it gets interpreted by the Morph? Or is there another solution? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > -- Lukas Renggli www.lukas-renggli.ch

July 13, 2011

[Pharo-project] shortcuts in PluggableTextMorph

by Tudor Girba

Hi, I need a bit of help in trying to add some kind of shortcuts to PluggableTextMorph. The following code used to work for shortcuts like "CMD+o": (PluggableTextMorph on: textModel ...) onKeyStrokeSend: #keystroke:from: to: textModel; GLMTextModel>>keystroke: anEvent from: aMorph anEvent anyModifierKeyPressed ifTrue: [ "check the do the shortcut work" ] However, in the recent Pharo 1.3, if I press "CMD+o", first the "o" is added to the text as a regular character, and then keystroke:from: is executed. Is there a way of capturing the event before it gets interpreted by the Morph? Or is there another solution? Cheers, Doru -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

July 13, 2011

Re: [Pharo-project] Python like generators for Pharo

by Lukas Renggli

Hi Max, See the Generator package in http://source.lukas-renggli.ch/continuations. IMHO, generators are pretty useless in Smalltalk though. Lukas On 13 July 2011 10:14, Max Leske <maxleske(a)gmail.com> wrote: > Hi folks > I've been reading a bit about Python generators and I think they're awesome. > So I quickly looked for a Smalltalk implementation and found that GNU > Smalltalk has one (http://smalltalk.gnu.org/blog/bonzinip/fun-generators) > Now, I was wondering if there's an implementation for Pharo / Squeak (since > I didn't find one on SqueakSource) and if not, if there might be any > interest in one. > If you're curious you should take a look at these: > > Generator Tricks for Systems Programmers - Version 2.0 > A Curious Course on Coroutines and Concurrency > http://www.dabeaz.com/generators-uk/GeneratorsUK.pdf > > Cheers, > Max -- Lukas Renggli www.lukas-renggli.ch

July 13, 2011

[Pharo-project] Python like generators for Pharo

by Max Leske

Hi folks I've been reading a bit about Python generators and I think they're awesome. So I quickly looked for a Smalltalk implementation and found that GNU Smalltalk has one (http://smalltalk.gnu.org/blog/bonzinip/fun-generators) Now, I was wondering if there's an implementation for Pharo / Squeak (since I didn't find one on SqueakSource) and if not, if there might be any interest in one. If you're curious you should take a look at these: Generator Tricks for Systems Programmers - Version 2.0 A Curious Course on Coroutines and Concurrency http://www.dabeaz.com/generators-uk/GeneratorsUK.pdf Cheers, Max

July 13, 2011

[Pharo-project] Main OS window top most property?

by Denis Kudriashov

Hello. Is it possible to setup main pharo OS window always top most property? For example In fullscreen mode I need no OS messages appear on top of pharo. Best regards, Denis

July 13, 2011

Re: [Pharo-project] ZeroMQ support

by Franz Josef Konrad

Have you looked at <http://www.squeaksource.com/ZeroMQ/>? Perhaps it is what you are looking for. I haven't used it so I can't give you a advice if it is useful. Regards, Franz Josef Am 13.07.2011 02:34, schrieb John Toohey: > Hi all, > Wondering if anyone here is working on adding binding for ZeroMQ > (http://www.zeromq.org/) to Pharo? I think this type of enterprise > support is something that would greatly benefit Pharo. In one of my > systems today, I use Stomp over a socket in Pharo to send and receive > messages to and from ActiveMQ, and from there to my servers. This > works, but is fragile, and I would love to be able to use zeromq here. > > I use zeromq in my Clojure based servers, but have no experience of > writing bindings for C libraries in Smalltalk. I would be more than > happy to help out, if such a project was started. >

July 13, 2011

[Pharo-project] Moose at GotoCon Aarhus / registration discount

by Tudor Girba

Hi, This fall I will give a talk at GotoCon Aarhus (Oct 9-14) on "Humane assessment with Moose": http://gotocon.com/aarhus-2011/speaker/Tudor+Girba GotoCon used to be named JAOO. It is a large industrial software development conference that might of interest to some of you. As part the speaker package I have the possibility to offer discounts to interested participants. So, if you want to go to GotoCon Aarhus and are interested in a discount of about 170 EUR, please send me an email and I will provide the promotion code. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

July 13, 2011