April 2012 - 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 25.04.2012 um 00:26 schrieb Igor Stasenko <siguctua(a)gmail.com>: > On 24 April 2012 23:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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, i see nothing disrespectful in Hannes reply. > Also, i'd prefer to be not put in a role of high authority. If i could > work on Google, it doesn't makes > any of my arguments stronger or weaker. > Exactly. And google is no indicator of quality. Sure it is said that they hire the best ones. But first you need a certain degree in information science otherwise they won't employ you. It is that easy. To be honest the most clever guys I met in my life had no degree at all ;) Norbert >> Stef >> >>> 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. >>>> >>>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 25, 2012

Re: [Pharo-project] Have you played with Ameba?

by HwaJong Oh

SORRY FOR 5 MONTH LATE REPLY Sounds great! HwaJong Oh -- View this message in context: http://forum.world.st/Have-you-played-with-Ameba-tp3585624p4585724.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] Have you played with Ameba?

by HwaJong Oh

SORRY FOR 5 MONTH LATE REPLY I don't no what "Spring Layout" is. If it is a layout object of Morph, then no. DeterministicAni is an periodic number interpolator with blocks. HwaJong Oh -- View this message in context: http://forum.world.st/Have-you-played-with-Ameba-tp3585624p4585722.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 25, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Yes! I agree with you. Now let us make progress on that point. On Apr 25, 2012, at 2:00 AM, GÃ¶ran Krampe wrote: > 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] 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