- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Editor focus & hotkeys

by blake

> > Benjamin Van Ryseghem-2 wrote >> >> right arrow :) >> > > Hmm... why not tab? Kind of the gold standard. Also, it's not consistent > because left doesn't go back (and obviously can't if you're in the middle > somewhere). Maybe both (could be nice to have a left and right hand option > on the keyboard)? No, don't change it! Now I know the secret! Others should have to suffer as well! :-) > Also, it'd be nice if the first element in the list is automatically > selected when the focus goes there. The border is hard to see (maybe a > different issue) and it makes for smoother navigation (like Mac finder). Yeah, it's really challenging to figure out where your key presses are gonna go. ===Blake===

April 25, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by Ben Coman

Sven Van Caekenberghe wrote: > Norbert, Dale, et al, > > > On 24 Apr 2012, at 18:43, Norbert Hartl wrote: > > >> What is STON and STON-object syntax? >> > > Arhh, it is not yet finished, I did it for myself, not for trying to convince the world, since that it too hard anyway. > > This is the work-in-progress paper: > > > ------------------------------------------------------------------------ > > > > The code lives here: http://ss3.gemstone.com/ss/STON > > It is a slight variation of JSON, adding some Smalltalk concepts, as well as a solution to the class problem. > > But again, I am not trying to convince anyone to use this, I did it as a proof of concept for myself, and I kind of like it. > > On the other hand, JSON is so ubiquitous that I wonder a bit, why bother ? > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > The human readability is a strong point of JSON & STON, but is there any requirement for "human edit-ability" by which I mean in a text editor? In which case the referencing objects by counting "OrderedCollection [ Point [1, 2], @2, @2 ]" would be fragile, since insertion of an object via text editor would offset all references. Something like "OrderedCollection@1 [ Point@2 [1, 2], @2, @2 ]" would be more robust. However if you expect to never need to edit the STON file in a text editor, this point is mute. The downside of this idea is a bit more cluttered look. However I notice that evaluating #123 in Workspace returns an integer rather than a ByteSymbol. So it would seem that #123 would never be written out in STON format (from Pharo), which means "OrderedCollection#1 [ Point#2 [1, 2], #2, #2 ]" might be a less cluttered option, or perhaps a mix like "OrderedCollection#1 [ Point#2 [1, 2], @2, @2 ]" doesn't detract too much from readability. Actually I think this enhances readability anyhow, since if there are a lot of object references in the STON file, in a text viewer I would have to need to manually count them to follow the references. cheers -ben

April 25, 2012

Re: [Pharo-project] AnnotationPanePlugin for Nautilus

by Sean P. DeNigris

EstebanLM wrote > >> Nautilus pluginClasses add: { AnnotationPanePlugin. #middle } > > something like: > > Nautilus addPlugin: AnnotationPanePlugin at: #middle. > > looks better for me :) > +1. Use the tools to tell us how to use our objects... -- View this message in context: http://forum.world.st/AnnotationPanePlugin-for-Nautilus-tp4584918p4585254.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by Dale Henrichs

Agreed, I think there are valid use cases for both STON and Tirade ... there is some overlap and where there is overlap one or the other can be used ... then again each has some unique characteristics ... I'm glad that I've learned more about Tirade in the process, because it is much clearer to me where Tirade can be applied ... Dale ----- Original Message ----- | From: "GÃ¶ran Krampe" <goran(a)krampe.se> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 5:17:26 PM | Subject: Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec) | | On 04/25/2012 01:11 AM, Dale Henrichs wrote: | > Okay, so Tirade isn't a generic parser for a well-defined syntax | > like STON | | Well... :) I am not sure if you read my whole post but it does do | nested | arrays and associatons etc so it seems to match STON fairly well, if | we | disregard the class mechanism of STON. | | But yes, it is primarily constructed as a "serializer for Smalltalk | messages" and not as a "serializer for Smalltalk objects". | | > and it looks like it really shines when it comes to doing dynamic | > interpretation of streams of messages .... | | Right. | | > now I better understand how Tirade can be applied to deltas or | > creating executable logs that can be replayed ... | | Yes, although in DeltaStreams I do not use it like that - I use it to | serialize objects, but Deltas consists of lots of different Change | objects and each such Change object is serialized using a specific | Tirade message. Thus the reader simply implements all those messages | and | creates the appropriate objects. | | One *very* nice aspect of this is that we do not encode classes in | the | actual files, the reader decides which class to instantiate. Thus the | files are much more robust against change. | | In that sense I am not that fond of putting classes explicitly in the | STON file. | | > At this point in time for disk-based structures that humans and | > computers are expected to understand it seems that a well-defined | > syntax is useful. | > | > Dale | | Sure. And at least it was fun to explain a bit about Tirade. And I | ended | up adding support for literal arrays :) | | regards, GÃ¶ran | |

April 25, 2012

[Pharo-project] ENH: Setting to enable two-way halo cycling

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > Now if you have the code I can have a look... > In a few lines of code and one class var, we can all have what we want :) Issue: http://code.google.com/p/pharo/issues/detail?id=5673 Fix in inbox: SLICE-Issue-5673-ENH-Setting-to-enable-two-way-halo-cycling-SeanDeNigris.1 After questions/confusion/discussion on the mailing list and in issues, I created this as a setting, so everyone can be happy without overriding :) The most recent discussions were: * http://forum.world.st/Do-we-get-rid-of-the-KeyDecodeTable-in-InputEventSens… * http://forum.world.st/Stupid-question-about-Fuel-td4558930i20.html Some relevant issues: * Issue 1207: meta-click does not give halo http://code.google.com/p/pharo/issues/detail?id=1207 * Issue 1277: Morphic Halo on workspace malfunction http://code.google.com/p/pharo/issues/detail?id=1277 I first wrote a hack to restore the old behavior (without setting) at http://forum.world.st/How-turn-on-Halo-s-td2227309.html#a4105053 Cheers, Sean -- View this message in context: http://forum.world.st/ENH-Setting-to-enable-two-way-halo-cycling-tp4585241p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by GÃ¶ran Krampe

On 04/25/2012 01:11 AM, Dale Henrichs wrote: > Okay, so Tirade isn't a generic parser for a well-defined syntax like STON Well... :) I am not sure if you read my whole post but it does do nested arrays and associatons etc so it seems to match STON fairly well, if we disregard the class mechanism of STON. But yes, it is primarily constructed as a "serializer for Smalltalk messages" and not as a "serializer for Smalltalk objects". > and it looks like it really shines when it comes to doing dynamic interpretation of streams of messages .... Right. > now I better understand how Tirade can be applied to deltas or creating executable logs that can be replayed ... Yes, although in DeltaStreams I do not use it like that - I use it to serialize objects, but Deltas consists of lots of different Change objects and each such Change object is serialized using a specific Tirade message. Thus the reader simply implements all those messages and creates the appropriate objects. One *very* nice aspect of this is that we do not encode classes in the actual files, the reader decides which class to instantiate. Thus the files are much more robust against change. In that sense I am not that fond of putting classes explicitly in the STON file. > At this point in time for disk-based structures that humans and computers are expected to understand it seems that a well-defined syntax is useful. > > Dale Sure. And at least it was fun to explain a bit about Tirade. And I ended up adding support for literal arrays :) regards, GÃ¶ran

April 25, 2012

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Dale Henrichs

Haha, no problem at all ... glad to help:) Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 4:53:21 PM | Subject: Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 | | Haha you made my day Dale! | I didn't know that you coul specify #'pharo1.3.x' in the baseline. | That's exactly what I was looking for. | | Sorry for the noise! | | On 24/04/12 16:49, Dale Henrichs wrote: | > spec for: #'pharo1.3.x' do: [ | > spec project: 'Zinc' with: [ | > spec | > className: 'ConfigurationOfZinc'; | > versionString: #'stable'; | > repository: 'http://www.squeaksource.com/Metacel | |

April 25, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

On 04/24/2012 11:52 PM, StÃ©phane Ducasse wrote: > Give us a break! I have all respect for you StÃ©phane but you really have a way with words sometimes. regards, GÃ¶ran

April 25, 2012

Re: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4

by Francois Stephany

Haha you made my day Dale! I didn't know that you coul specify #'pharo1.3.x' in the baseline. That's exactly what I was looking for. Sorry for the noise! On 24/04/12 16:49, Dale Henrichs wrote: > spec for: #'pharo1.3.x' do: [ > spec project: 'Zinc' with: [ > spec > className: 'ConfigurationOfZinc'; > versionString: #'stable'; > repository: 'http://www.squeaksource.com/Metacel

April 24, 2012

Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec)

by GÃ¶ran Krampe

On 04/25/2012 01:25 AM, H. Hirzel wrote: > GÃ¶ran > > Thank you for this illustration. > > http://goran.krampe.se/blog/Squeak/Tirade.rdoc > > I understand that > > 1) the Tirade parser parses a subset of regular Smalltalk messages. Exactly. It doesn't do binary messages. And of course, it doesn't do any expressions. > 2) the receiver is not given as it is assumed to be always the Tirade > parser object. Right, but if you use the TiradeReader (which is a bit more experimental) it maintains a stack of objects and will send the next Tirade message to the object on the top of the stack. Then one can register a set of "control messages" and those are always sent to the object first on the stack - which is the TiradeReader itself. As I said, this is an experiment on a generic mechanism for being able to construct complex objects from a series of Tirade messages. > 3) the Tirade parser acts like a builder for objects? The parser actually only parses the Tirade messages, it doesn't try to build anything. But your own subclass of it should implement these messages and typically build something. > 4) It solves problems JSON and STON do not. > > I think this idea is very worth to pursue. The elegancy of messaging is quite powerful and makes it easier to construct a file format that is less fragile and has very little structure. regards, GÃ¶ran

April 24, 2012