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

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

by Dale Henrichs

Stef, We are all on the same side ... I like to say that we are in "screaming agreement"... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 2:50:51 PM | Subject: Re: [Pharo-project] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk] | | 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 | | > 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 24, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

Thanks! I really want to have a look at your changes to learned. I cleaned the <on> <off> menu items handling. Now no string generation and string parsing anymore :) I let the code to be compatible and in 2.1 we can flush them. Stef > Finally found the time to package out. > Have tested a bit after fixing some conflicts. > A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). > > Attached cs and description of changes > > Regards, Gary > <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>

April 24, 2012

Re: [Pharo-project] Tirade!

by Dale Henrichs

Stef, It is starting to look like STON will be a good option ... it has the advantage of having an existing implementation and provides much more functionality than a simple literal array parser ... Oh and it looks a lot like Smalltalk ... BTW, I am still interested in seeing how Tirade would provide the same functionality as STON... I suggest that you take a deep breath and relax a bit:) Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 2:52:05 PM | Subject: Re: [Pharo-project] Tirade! | | Give us a break! | | Stef | | On Apr 24, 2012, at 1:39 PM, GÃ¶ran Krampe wrote: | | > On 04/24/2012 01:06 PM, H. Hirzel wrote: | >> On 4/24/12, Igor Stasenko<siguctua(a)gmail.com> wrote: | >>> can you name just one which can be useful in this context??? | >>> what tools, except written in smalltalk and used by smalltalkers | >>> you | >>> are expecting to use | >>> with smalltalk source code stored in source code repositories? | >> | >> JavaScript :-) in connection with Amber. And couchDB. | > | > I do notice that Igor mentions a specific use case here, but let me | > ignore that and just reflect on JSON in general: | > | > And Riak. And quite a few other NoSQL dbs use JSON. And lots of | > RESTful RPC backends tend to use JSON, we do in our C# backend | > here at my customer. And almost all web APIs on the net use JSON. | > | > And JSON pops up everywhere in fact. So personally, while I did | > actually implement Tirade, JSON is still a very nice format due to | > its ubiquity. | > | > The main reason I made Tirade was because JSON didn't handle | > linefeeds in strings so I couldn't store source code in JSON in a | > reasonably readable way. At least not per true JSON spec. | > | > Also, Tirade supports more atomic Smalltalk datatypes. And since it | > encodes keyword messages it simply offers more structure than JSON | > does. And it is streamable. And perhaps one or two more things. | > | > But in summary - JSON is generally a very good choice and IMHO | > Pharo should be *great* at handling JSON. It's not going away :) | > | > regards, GÃ¶ran | > | | |

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

I do not think it works for gemstone because apparently they cannot access the parser or at least wants to make sure that you cannot write code that can break the server scenario: you are mean that you write a strange meta data that is executed on the server so I will take tirade parser and make sure that we get one that only parse literal arrays. On Apr 24, 2012, at 3:23 PM, Igor Stasenko wrote: > Here the the snippet to parse array literals.. based on existing parser.. > i only had to add a #parseNode accessor to Parser to make it work: > > > | parser| > parser := > (Parser new > init: '#(1 2 3 (ab bc de))' readStream notifying: nil failBlock: [] > ). > > parser encoder initScopeAndLiteralTables. > parser primaryExpression. > parser parseNode key > > > > On 24 April 2012 15:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> goran could I extract the parser? and rename it in another package? >> >> Stef >> >> On Apr 24, 2012, at 12:00 PM, GÃ¶ran Krampe wrote: >> >>> On 04/24/2012 11:52 AM, GÃ¶ran Krampe wrote: >>>> On 04/24/2012 11:51 AM, GÃ¶ran Krampe wrote: >>>>> On 04/24/2012 11:46 AM, StÃ©phane Ducasse wrote: >>>>>> Where is the code? >>>>> >>>>> On SS. But it seems... down? Project is called "Tirade". >>>> >>>> http://www.squeaksource.com/Tirade.html >>> >>> Eh, oops. I just realized that TiradeParser uses dynamic arrays { } and does not have current support for literal Arrays. Duh. Sorry about that, but feel free to use the code anyways, adding #parseLiteralArray should not be hard. >>> >>> regards, GÃ¶ran >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 24, 2012

Re: [Pharo-project] Editor focus & hotkeys

by Sean P. DeNigris

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)? 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). Sean -- View this message in context: http://forum.world.st/Editor-focus-hotkeys-tp4584350p4584934.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Thanks. I saw that #(tire ) is interpreted as true so I will check and improve that. tef On Apr 24, 2012, at 3:18 PM, GÃ¶ran Krampe wrote: > Ok, I spent some time adding support for literal arrays to Tirade. > It probably has bugs and I haven't written tests for them but it does parse this correctly: > > > (TiradeParser parse: 'keyword: #(1 -2 3.4 -4.5 ''asd'' (2 nil true false 3) #jupp jupp jupp:tup: #''ju li'' jup:tu 2).') last value first > > ...produces this: > > #(1 -2 3.4 -4.5 'asd' #(2 nil true false 3) #jupp #jupp #jupp:tup: #'ju li' #'jup:tu' 2) > > So it handles integers, floats, nil, true, false, nested literal arrays and symbols. In fact it does handle some more than a true literal array does since Tirade supports { bla . bla } arrays also (but only of literals) and also treats key -> value as a literal syntax. > > Thus for example these work too: > > (TiradeParser parse: 'keyword: #(1->2 3->#ad).') last value first > > (TiradeParser parse: 'keyword: #({2 . 4}).') last value first > > > regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

I saw and I started to extract parts that I need and writing some texts. Stef > On 04/24/2012 12:57 PM, StÃ©phane Ducasse wrote: >> Ok I will have a look. Because it would solve our problem. > > I just added first stab at supporting literal arrays, the following works: > > (TiradeParser parse: 'keyword: #(1 3.4 ''asd'' #jupp 2).') last value first print it => > > #(1 3.4 'asd' #jupp 2) > > The "last value first" is just because the result from TiradeParser contains Associations between the keyword and an array of arguments. It could in fact return instances of Message, that might be nice :) > > ...but nesting needs a bit more thought since one can ommit the # when nesting literal arrays inside literal arrays. > > regards, GÃ¶ran

April 24, 2012

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

Give us a break! Stef On Apr 24, 2012, at 1:39 PM, GÃ¶ran Krampe wrote: > On 04/24/2012 01:06 PM, H. Hirzel wrote: >> On 4/24/12, Igor Stasenko<siguctua(a)gmail.com> wrote: >>> can you name just one which can be useful in this context??? >>> what tools, except written in smalltalk and used by smalltalkers you >>> are expecting to use >>> with smalltalk source code stored in source code repositories? >> >> JavaScript :-) in connection with Amber. And couchDB. > > I do notice that Igor mentions a specific use case here, but let me ignore that and just reflect on JSON in general: > > And Riak. And quite a few other NoSQL dbs use JSON. And lots of RESTful RPC backends tend to use JSON, we do in our C# backend here at my customer. And almost all web APIs on the net use JSON. > > And JSON pops up everywhere in fact. So personally, while I did actually implement Tirade, JSON is still a very nice format due to its ubiquity. > > The main reason I made Tirade was because JSON didn't handle linefeeds in strings so I couldn't store source code in JSON in a reasonably readable way. At least not per true JSON spec. > > Also, Tirade supports more atomic Smalltalk datatypes. And since it encodes keyword messages it simply offers more structure than JSON does. And it is streamable. And perhaps one or two more things. > > But in summary - JSON is generally a very good choice and IMHO Pharo should be *great* at handling JSON. It's not going away :) > > regards, GÃ¶ran >

April 24, 2012

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

by StÃ©phane Ducasse

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 > 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 24, 2012

[Pharo-project] AnnotationPanePlugin for Nautilus

by Mariano Martinez Peck

Hi Igor/Ben. I don't know if it was the correct path, but I commited NautilusCommon-MarianoMartinezPeck.58 which adds a new plugin: AnnotationPanePlugin. It is based on Igors one and taken the class from OB. For me this is really usful beacuse it shows for each method its author, timestamp, mcz version, category, number of implementors, etc. It does not show the number of senders because it is slow. So...is that fine? ahh btw, if you wonder how to do a script to enable plugins: Nautilus pluginClasses add: { AnnotationPanePlugin. #middle } cheers, -- Mariano http://marianopeck.wordpress.com

April 24, 2012