April 2012 - Pharo-dev - lists.pharo.org

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

by phil＠highoctane.be

Is it just me or is there a problem? Can't get STON from SS3. Doesn't looks like down tough. Phil 2012/4/25 Ben Coman <btc(a)openinworld.com> > 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<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 > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

April 25, 2012

Re: [Pharo-project] Error at startup with the NonInteractiveUIManager

by Francois Stephany

> I have a problem when trying to start an application on a linux server > with the latest cogvm (2550) and Pharo 1.4-14438. I've tried with different VMs but it seems that it's still crashing. Going back to 1.3 solves the problem. I gonna investigate what went wrong.

April 25, 2012

[Pharo-project] Error at startup with the NonInteractiveUIManager

by Francois Stephany

Hi there, I have a problem when trying to start an application on a linux server with the latest cogvm (2550) and Pharo 1.4-14438. > ==== Startup Error: PrimitiveFailed: primitive #primGetPosition: in MultiByteFileStream failed > MultiByteFileStream(Object)>>primitiveFailed: > MultiByteFileStream(Object)>>primitiveFailed > MultiByteFileStream(StandardFileStream)>>primGetPosition: > MultiByteFileStream(StandardFileStream)>>position > MultiByteFileStream(PositionableStream)>>skipStyleChunk > MultiByteFileStream(PositionableStream)>>fileInAnnouncing: in Block: [:bar | ... > NonInteractiveUIManager(CommandLineUIManager)>>progressInitiationExceptionDefaultAction: > ProgressInitiationException>>defaultAction > UndefinedObject>>handleSignal: > MethodContext(ContextPart)>>handleSignal: > Got startup errors: > PrimitiveFailed: primitive #primGetPosition: in MultiByteFileStream failed I haven't identified the cause yet but if anybody had that problem before, i'm all ears ;) Cheers, Francois

April 25, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by blake

Hey, Steph! Thanks! :-) On Tue, Apr 24, 2012 at 2:22 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > May I ask you why you talk about CUIS and Spoon/Pharo? > If you want to work with these systems we do not have any problems. > > We are working on Pharo since 2008. We deliver regularly, we are concerned with > making sure that you can do business with Pharo. And we will continue. > WE want to invent and build OUR future.

April 25, 2012

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