- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by Norbert Hartl

Am 24.04.2012 um 23:50 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > We will write a parser because we do not want a JSON syntax. > I started and I will continue. > > Hannes I think that igor did a lot for us and that he knows probably more > than you what is to work for the community. Because Igor could be working for Google > right now without any problem. So let us appreciate to have guys like him in our community. > Stef, the last paragraph has an unfortunate ratio. The last sentence is fine but the first two are not. You have the right to be stubborn but I don't think you have the right to be so arrogant and unfair. Norbert > >> Igor, >> >> Let me rephrase the context. It is that you started this thread >> yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not >> pleased with storing Smalltalk meta data in JSON format. >> >> You gave the example >> >> { >> "category" : "Cypress-Tests", >> "classinstvars" : [ >> ], >> "classtraitcomposition" : "{}", >> "classvars" : [ >> ], >> "commentStamp" : "", >> "instvars" : [ >> ], >> "name" : "CypressPatchTest", >> "pools" : [ >> ], >> "super" : "CypressAbstractTest", >> "traitcomposition" : "{}", >> "type" : "normal" } >> >> The cypress project URL is >> >> https://github.com/CampSmalltalk/Cypress >> >> This is Dale Henrichs' work. >> >> Cypress uses JSON for storing the meta data. >> >> There is a button called 'Fork' on the git hub project. >> >> Dale is willing to take arguments if they are based on code. >> For many people JSON is fine. >> >> HTH :-) >> >> Hannes >> >> On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 24 April 2012 14:17, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >>>> >>>> >>>> Igor Stasenko wrote: >>>>> >>>>> On 24 April 2012 11:54, Dale Henrichs<dhenrich(a)vmware.com> wrote: >>>>>> >>>>>> Stef, >>>>>> >>>>>> There is no Parser class and there is no Compiler class. There is a >>>>>> primitive call that takes method source, class, methodDictionary, etc. >>>>>> and >>>>>> produces a method installed in the methodDictionary. >>>>>> >>>>> so you can take 1st literal from such method and you done. or you >>>>> cannot access method's literals? >>>>> it of course not as simple as parsing the source, but if you cannot >>>>> avoid compilation.. >>>>> >>>>>> ... JSON is and was a pragmatic choice... >>>>>> >>>>> well, i did not realized that GemStone have no own parser/compiler >>>>> written in smalltalk. >>>> >>>> >>>> Neither does Amber in deploy mode, unless I am mistaken. >>>> >>>> Why do you ever think there must be a Smalltalk parser in any Smalltalk? >>>> You >>>> get used to it, I understand, but it is by no means a required thing. >>>> Smalltalk is Smalltalk without parser as well. >>>> >>>> JSON is great choice. Much better than anything proprietary, because of >>>> world-wide interoperability. >>>> >>> >>> Sorry, but you seem even more out of the context than me. >>> We're talking about tools for storing and loading smalltalk code.. >>> which implies having a working smalltalk >>> parser and compiler toolchain. >>> How else you can load smalltalk source code without having the way to parse >>> it? >>> If you don't parse nor compile it, it is just a bunch of letters. >>> >>>> Herby >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> > >

April 25, 2012

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

by Sven Van Caekenberghe

Ben, On 25 Apr 2012, at 05:32, Ben Coman wrote: > 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. Thanks for the feedback, I will think about your idea of explicit numbering. However, a format with numbered references will never be very human friendly I guess. If the goal is to have like a config file, I would make sure there are no such references. Sven

April 25, 2012

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

by Sven Van Caekenberghe

Yummy ! On 25 Apr 2012, at 07:59, Igor Stasenko wrote: > .. and , of course, some screenshots for thirsty people ;) > <Screen Shot 2012-04-25 at 7.52.02 AM.png><Screen Shot 2012-04-25 at 7.58.34 AM.png>

April 25, 2012

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

by Sven Van Caekenberghe

On 25 Apr 2012, at 07:46, phil(a)highoctane.be wrote: > Is it just me or is there a problem? > > Can't get STON from SS3. Doesn't looks like down tough. Apparently the package names themselves have different capitalization: Gofer it url: 'http://ss3.gemstone.com/ss/STON'; package: 'Ston-Core'; package: 'Ston-Tests'; load. Yes, I am confused as well. Sven

April 25, 2012

Re: [Pharo-project] Athens & SVG (was: Re: new icon set )

by Igor Stasenko

.. and , of course, some screenshots for thirsty people ;)

April 25, 2012

[Pharo-project] Athens & SVG (was: Re: new icon set )

by Igor Stasenko

Hi, there i uploaded an alpha version of Athens-SVG package on squeaksource/Athens. Many things are working, and many not yet ;) I testing things by trying to render different svg files using it like that: [1] (ASVGMorph fromFile: 'lion.svg') drawOn: Display getCanvas or like that: [2] (ASVGMorph fromFile: '7-icon-set/Connect$70426968946611.svg') setZoom: 10; drawOn: Display getCanvas (of course you can just use #openInWorld instead of #drawOn:) (and of course you don't have to create a morph.. you can just import svg getting an instance of ASVGRoot class, and then render it on any Athens canvas. [1] http://croczilla.com/bits_and_pieces/svg/samples/lion/lion.svg [2] http://www.tehkseven.net/blog/1/entry-1066-475-free-awesome-high-quality-ic… -- Best regards, Igor Stasenko.

April 25, 2012

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