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

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

by Dale Henrichs

Francois, The #stable symbolic version is the key when dealing with a new platform version like pharo 1.4 ... if a configuration does not have a #stable version for #pharo1.4 then it is not likely that the configuration has been tested on pharo1.4 ... If it does have a #stable version then it is likely to have been tested. At this point you have a decision to make ... If your project depends upon particular features or APIs in a project like Zinc or Seaside or FS, then you will be interested in referencing that particular version in your specification. Nonetheless if there is no #stable version specified for the project, then you can't be sure that the project has been ported. On the other hand, if your project uses the standard API and has no special dependencies upon details of the project, then you should reference the #stable version from your configuration ... using #stable means that you don't have to fiddle with your configuration every time a new version is released and using #stable means that your configuration will work with multiple platform versions. Once you have verified that your project is working on pharo1.4, then you should publish a #stable version for #pharo1.4, so that users of your project will know that they can safely move to pharo 1.4 ... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:06:03 PM | Subject: [Pharo-project] How to declare Zinc/FS dependency in Metacello Configuration for 1.4 | | I'm updating some Metacello configurations and I'm wondering how to | declare the dependencies on stuff that have been integrated into | Pharo | 1.4 (e.g., Zinc, FS). | | Should I declare those dependencies into my configuration? If yes, | against with version? | | My gut feeling is that I should create a new baseline that does not | require any Zinc of FS. | That becomes a pain in the ass when developing in parallel for 1.3 | and | 1.4. Is the only place where I can differentiate 1.3 and 1.4 is in | the | stable symbolic version, right? | | What are people generally doing? | | | Cheers, | Francois | |

April 24, 2012

Re: [Pharo-project] JSON, Smalltalk parser and no-point wars

by Camillo Bruni

April 24, 2012

Re: [Pharo-project] SimpleLiteralArray Spec

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:17 AM, Dale Henrichs wrote: > Stef, > > Which is more important: > > implementation or functionality? functionality: how to store meta data of class or method. So far I do not see why I need ston. Now if you tell me that you need a textual serializer then this is another story and scenario. But this is not the one we need to store meta data of class and method. I'm not that approximate to mix the two. Stef > > You appear to be fixated on a particular solution and seem to be ignoring the actual problems. > > 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 3:13:20 PM > | Subject: Re: [Pharo-project] SimpleLiteralArray Spec > | > | > | On Apr 24, 2012, at 1:26 PM, Sven Van Caekenberghe wrote: > | > | > OK, just to get started, let try to write a spec for > | > SimpleLiteralArray, this is based on JSON (and my own STON, not > | > ready for public consumption). It will soon become clear that this > | > is slightly harder than expected, IMO a writer is needed as well. > | > > | > S y n t a x > | > > | > value > | > primitive-value > | > list > | > nil > | > primitive-value > | > number > | > true > | > false > | > symbol > | > string > | > classname > | > | In a literal array a class name is just a symbol > | > | #(Foo) first > | #Foo > | > | > list > | > #() > | > #( elements ) > | > elements > | > value > | > value , elements > | > string > | > '' > | > ' chars ' > | > chars > | > char > | > char chars > | > char > | > any-printable-ASCII-character- > | > except-"-or-\ > | > \" > | > \\ > | > \/ > | > \b > | > \f > | > \n > | > \r > | > \t > | > \u four-hex-digits > | > | why do we need that? > | > | > symbol > | > # chars-limited > | > # ' chars ' > | > chars-limited > | > char-limited > | > char-limited chars-limited > | > char-limited > | > a-z A-Z 0-9 - _ . / > | > classname > | > uppercase-alpha-char alphanumeric-char > | > | there is not need for classname as element > | classname is just a pair that the interpretation should handle if > | necessary > | > | > | > number > | > int > | > int frac > | > int exp > | > int frac exp > | > int > | > digit > | > digit1-9 digits > | > - digit > | > - digit1-9 digits > | > frac > | > . digits > | > exp > | > e digits > | > digits > | > digit > | > digit digits > | > e > | > e > | > e+ > | > e- > | > E > | > E+ > | > E- > | > > | > > | > Questions remain: > | > > | > - is the escaping OK ? > | > | I do not know but in literal array there is no escaping. Now if you > | want to put a cr into a string you probably need that > | > | > - what about symbols without a leading # ? > | > | #(foo) -> #(#foo) > | #(true nil false 1 'n') -> #(true nil false 1 'n') > | > | > - what should be allowed in unquoted symbols ? > | I did not get the question > | > | > - what should be allowed for classnames ? > | Nothing > | > | > - what about namespaces ? > | Nothing no need I do not think that they are in literal arrays. (may > | be in VW but I did not check) > | > | > - do we allow infinite precision integers ? > | Yes > | > | > - maybe the toplevel should always be an array ? > | > | I would say so else this is not a literalArray but a literal. > | > | > | > > | > > | > Now: shoot! > | > > | > > | > Sven > | > > | > > | > -- > | > Sven Van Caekenberghe > | > http://stfx.eu > | > Smalltalk is the Red Pill > | > > | > > | > > | > > | > > | > | > | >

April 24, 2012

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

by StÃ©phane Ducasse

On Apr 25, 2012, at 12:06 AM, Francois Stephany wrote: > I'm updating some Metacello configurations and I'm wondering how to declare the dependencies on stuff that have been integrated into Pharo 1.4 (e.g., Zinc, FS). excellent question. So far you cannot but what we discussed with esteban is that we want to have the configurationOf the project loaded so that when we move to a smaller kernel we do not have to reinvent them and more important we can code against and use them as milestone. > Should I declare those dependencies into my configuration? If yes, against with version? > > My gut feeling is that I should create a new baseline that does not require any Zinc of FS. yes > That becomes a pain in the ass when developing in parallel for 1.3 and 1.4. yes same feeling here. > Is the only place where I can differentiate 1.3 and 1.4 is in the stable symbolic version, right? > > What are people generally doing? grumbling :( May be dale know but I don't > > > Cheers, > Francois >

April 24, 2012

Re: [Pharo-project] [update 2.0] #20009

by Fernando Olivero

great! We should say our farewells to BlockContext and SourceReference, amongst others... On Tue, Apr 24, 2012 at 6:20 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20009 > ----- > > Issue 5564: Â Â Support bit operations on Boolean / Integers > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5564 > > Issue 5641: Â Â Unload Deprecated14 > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=5641 > > > > -- > Marcus Denker -- http://marcusdenker.de > >

April 24, 2012

Re: [Pharo-project] AnnotationPanePlugin for Nautilus

by Esteban Lorenzano

mmm... not convinced :) let's see it tomorrow (if that #Â¢%& vm bug let me do anything else :P) Esteban On Apr 25, 2012, at 12:22 AM, Benjamin wrote: > > On Apr 25, 2012, at 12:15 AM, Esteban Lorenzano wrote: > >> ahhh.... >> >> On Apr 24, 2012, at 11:49 PM, Mariano Martinez Peck wrote: >> >>> 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 } >> >> ...and: >> >> AnnotationPanePlugin class>>#pluginSettings: builder >> <nautilusPlugin> >> builder add: self at: #middle. >> >> >> looks a LOT better for me :) >> >> Esteban >> >> ps: yes, I know... I'm annoying today :P > > It doesn't work like that. > > You can choose dynamically where you wanna put the plugin, and if you want to activate it or not. > > With pragmas, I do not think it can work :) > > > Ben > >> >> >>> >>> cheers, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >

April 24, 2012

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

by Igor Stasenko

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

Re: [Pharo-project] Tirade!

by StÃ©phane Ducasse

On Apr 24, 2012, at 11:58 PM, Dale Henrichs wrote: > 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:) I see the advantage of ston to be able to specify class as in the Bitmap [ ] example Now it means that we will have the parser of ston loaded to load codeâ¦ :( Ston can be a format for objects exchange but I still do not see why VW like literal arrays do not work. > 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] STON (was Re: SimpleLiteralArray Spec)

by H. Hirzel

Additional context information for people who will come late to this thread: We are discussing a human-readable-format, so neither something like SIXX, nor a binary data exchange format. On 4/25/12, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 4/24/12, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Very cool! >> >> Let's see ... export the pharo implementation of STON in Cypress package >> format (using FileTree), then port STON to other dialects and voila:) the >> next generation of Cypress can use STON in place of JSON! >> >> Dale > > Yes, this is promising. > > First of all STON has a good name > 'Smalltalk Object Notation'. People who know JSON will be instantly > familiar with the general idea. Sven writes this in the document > attached as a PDF at the beginning of this thread. [1] > > Second > STON offers more than JSON > shared objects and cycles in the object graph are supported in STON. > more data types > > Third > STON seems to be superset of JSON. Sven writes above that he > implemented this today in a new version. > > Fourth > It is literal Smalltalk if we accept a dictionary type {} as done > in Amber Smalltalk. > > -- Hannes > > > [1] Sven Van Caekenberghe > If you have ever seen JSON (Javascript Object Notation) 1 , you will be > instantly familiar with Smaltalk Object Notation. It uses similar > primitive values, with the addition of a symbol type. Some details are > slightly > different though. For object values an optional class tag precedes a > representation that is either a list of values or a map of keys and > values. Exactly > how each class is represented is up to the implementation, although this > document suggests some conventions for well known classes. > > > >> ----- Original Message ----- >> | From: "Sven Van Caekenberghe" <sven(a)beta9.be> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Tuesday, April 24, 2012 1:14:08 PM >> | Subject: Re: [Pharo-project] STON (was Re: SimpleLiteralArray Spec) >> | >> | >> | On 24 Apr 2012, at 21:40, Sven Van Caekenberghe wrote: >> | >> | > Apart from the fact that I used single quotes for strings in STON, >> | > it already works (and I could enhance the parser to accept both I >> | > guess). >> | >> | --- >> | Name: Ston-Core-SvenVanCaekenberghe.27 >> | Author: SvenVanCaekenberghe >> | Time: 24 April 2012, 10:13:07 pm >> | UUID: dd7c16b2-950c-4246-bf60-130de447cddf >> | Ancestors: Ston-Core-SvenVanCaekenberghe.26 >> | >> | extended the parser to allow either single or double quotes as String >> | delimiters which gives us JSON backward compatibilty ! (thanks Dale >> | Henrichs for this great idea). >> | --- >> | >> | >> | >> | >> >> >

April 24, 2012

Re: [Pharo-project] JSON, Smalltalk parser and no-point wars

by Dale Henrichs

Stef, The smalltalk tools have no more business poking around in the "internals" of the disk-based package format than they do unzipping and rummaging around inside a .mcz file. Once the package is in the image you are working with Cypress or FileTree definitions that look an awful lot like Monticello definitions ... you'll be hard-pressed to find any json in those classes ... you will find some Dictionaries ... and those are the classes that the smalltalk tools should be using ... As I have said (something like a 100 times so far) the Cypress format will be changing over time so it will be a major mistake for any image-based tools to be monkeying with the internals of the disk-based package format ... 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 3:03:05 PM | Subject: Re: [Pharo-project] JSON, Smalltalk parser and no-point wars | | | On Apr 24, 2012, at 5:34 PM, Miguel CobÃ¡ wrote: | | > Friends, | > | > what energy! But I don't know why are we discussing this point of | > JSON | > choice so long. | > It is an implementation detail. | > If he choose to use XML, so be. It is Dale's time and Dale's code. | > Remember his projects is not to build a inter-dialect metadata | > format. | > His project is all about building an inter-dialect package format | > to | > store smalltalk. And in that goal he is succeeding! Lets no make a | > flame | > war about his choices. | > What is matters now is to show to as many smalltalk dialects as | > possible, that code interchange is possible. That is the fucking | > point. | | No! | Because really fast we will have a lot of Smalltalk code on github | and we will have | to have JSON parser to build tools. While we can simply use our | parser. So I'm writing a parser | not for us but for gemstone basically right now. | | > If after that, because the implementation is slow, or some other | > real | > after-use problem is detected, then is the time to discuss how to | > better | > address that specific problem. Until then, this is a bikeshedding | > like | > inane problem. | > | > Remember make it work, make it right, make it fast! | | Yes but in that case using the gemstone parser should have worked | too. | I thought that making it secure was after make it work. | | | > Dale is in make it work. | > Every other not putting code on the project is trying to make it | > right | > (intelectually and upfront). | > | > Lets not stop the work of others by discussing the best way to do | > it | > instead of doing it. Some famous people around here made an analogy | > about a mountain and the people trying to climb it. Don't forget | > that! | | Do you think that we forget when we are daily improving our system? | | | > | > Cheer to all. | > -- | > Miguel CobÃ¡ | > http://twitter.com/MiguelCobaMtz | > http://miguel.leugim.com.mx | > | > | > | > | | |

April 24, 2012