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

[Pharo-project] GSoC news: we have 13 projects!

by Janko MivÅ¡ek

Dear Smalltalkers! We have 13 GSoC projects and let we welcome to all students whose proposals were accepted: 1. Santiago Bragagnolo Concrete Type Inference -- Call graph http://gsoc2012.esug.org/projects/type-inference 2. Lars Wassermann ARM jitter for Squeak VM http://gsoc2012.esug.org/projects/arm-jitter 3. Facundo Mainere Interactive & social online Smalltalk tutorial http://gsoc2012.esug.org/projects/interactive-tutorial 4. Benjamin Van Ryseghem Nautilus http://gsoc2012.esug.org/projects/nautilus 5. MartÃn Dias Package management with Fuel http://gsoc2012.esug.org/projects/fuel-packages 6. Guillermo Polito Bootstrapping the core-Hazelnut http://gsoc2012.esug.org/projects/hazelnut 7. Pablo Estefo TestSurgeon http://gsoc2012.esug.org/projects/testsurgeon 8. Daniel Uber SciSmalltalk http://gsoc2012.esug.org/projects/sci-smalltalk 9. Rustem Khubbatov HMI (Human-Machine Interface) with Amber http://gsoc2012.esug.org/projects/mmi-amber 10. Juan Pablo Sandoval Alcocer Rizel - Multidimensional Profiler http://gsoc2012.esug.org/projects/rizel 11. Saurav Bhattacharya Export Excel files and other spreadsheet related goodies http://gsoc2012.esug.org/projects/excel-export 12. Steve Granda Finish Physical Etoys port to Sugar http://gsoc2012.esug.org/projects/etoys-sugar 13. Paul Kuzovkin Esse, a framework for visualizing, storing and exploring ideas http://gsoc2012.esug.org/projects/esse 5 students from Argentina, 2 from Chile, 2 from Russia, 1 from Sweden, France, USA and let we specially welcome our first Indian student! Now a Community bonding period started, when students get to know mentors, read documentation, get up to speed to begin working on their projects. Until 21.May when coding begin. Good luck to everyone! Janko @ Carla -- Smalltalk GSoC Admin Team http://gsoc2012.esug.org

April 24, 2012

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

by Fernando Olivero

That's a good point. I regularly see that Stef and others harvest enhancements and fixes from Squeak and CUIS. Surely, the other way around is also true. We simply have to live with the fact that many forks exist, and each of them is maintained by a small set of people who put a lot of energy into their own system. And sometimes they will collaborate, and sometimes not. The community behind Pharo, shouldnt be required to always be aware of external enhancements. And vice-versa for the remaining forks. Fernando On Tue, Apr 24, 2012 at 12:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Now I do not see the points related to spoon and cuis. I do not understand what is the point. >>> If people wants to collaborate with us this is ok now we do not count on that for our future. >>> >>> You do not have to reply. Just think about what you want to build and your future. Everybody >>> make choices and is free. >> >> I see the point behind Cuis/Spoon discussion in a wish to avoid >> duplication efforts in Smalltalk community. A wish to hear from you a >> word, something like: "yes we will look in Cuis to see if we can reuse >> some ideas or even code". To express just a will to look at achievements >> of others would help here. I think this is what many of us wants to hear. > > Did you notice that we ***already*** harvested some of the CUIS items? > Now it does not make sense to stay compatible for the sake of it. > Look CUIS changes the class definition meta data and this is ok. Now nobody went to say > to Juan that he should not â¦ blablbalbalba > > Stef > >> Best regards >> Janko >> >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > >

April 24, 2012

Re: [Pharo-project] new icon set

by Esteban Lorenzano

but, Norbert, I don't see the point. In a server you will not have (or *should* not have) a display... so rendering time, etc. is non an issue, because it will not be any... or I'm missing something? cheers, Esteban On Apr 24, 2012, at 2:02 PM, Norbert Hartl wrote: > > Am 24.04.2012 um 12:50 schrieb Igor Stasenko: > >> On 24 April 2012 11:44, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Am 24.04.2012 um 11:35 schrieb Geert Claes: >>> >>>> >>>> Norbert Hartl wrote >>>>> >>>>> Of course, if there is an ugly replacment that can be used if the system >>>>> is minimised. Having two icon sets introduces the possibility to make the >>>>> ugly one consume even less memory, e.g. make it black and white. >>>>> >>>> >>>> I have no idea what you just tried to say :) When you say ugly replacement, >>>> are you talking about the current ugly icons or do you find Esteban's >>>> suggested icons not appealing enough? >>>> >>> It is just an addition to my first statement. If we call the current icon set medium in the sense of medium cutiness and medium memory consumption than there is a new situation with the new nice icons. Igor is right, if the vector world is coming to pharo then it is easy to make really good looking icons in the image. But the memory consumption and CPU intensity will be raised. That contradicts to usage of pharo in a server environment. So what I was saying is that I think that the new icons are great. But then there should be a replacement for it when the image is shrinked. The same happens with the fonts if you shrink. And if the icons are replaced they could even be replaced by something really basic that saves additional memory. On a server with VNC or the like the icons aren't that important and maybe can be removed completely. >>> >>> More clear now? >>> >>> Norbert >>> >>> >> >> did i miss something? since when memory consumption for vector >> graphics takes more space? >> look at the size of .svg files and compare them with size of .png >> files for same icons. > > There is a difference between storage size and in-memory size. The storage size is important if you put the resource class-based. For the rest you need to decide. Either you render the icon every update from source or you do cache and from then on you have storage size + in-memory size for your icons. If you do fancy stuff automatically which means it probably uses a lot of colors so this can be quite big. > >> Vector data are much more compact. >> So, actually if you really want to shrink things down, you need to >> operate with vectors :) > > Yes, and then you need a lot of cpu cycles. Just what I said. > >> More CPU for rendering vector graphics? Perhaps. >> It is of course more expensive than just copying memory from one >> bitmap to another. >> But desktop environment requires a lot more complex operations that >> just copying bits from one form over >> another one. >> And also consider the cases where you need to use 5 different >> operations to simulate just one. >> (look at famous corner rounder hack). > > Again what I said. It is feasible to have good looking stuff. But everything you said is unimportant on a server. I'm just begging you not to forget that. That's all. Nothing against any of your plans. It will make pharo better. > > Norbert

April 24, 2012

Re: [Pharo-project] new icon set

by Norbert Hartl

Am 24.04.2012 um 12:50 schrieb Igor Stasenko: > On 24 April 2012 11:44, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 24.04.2012 um 11:35 schrieb Geert Claes: >> >>> >>> Norbert Hartl wrote >>>> >>>> Of course, if there is an ugly replacment that can be used if the system >>>> is minimised. Having two icon sets introduces the possibility to make the >>>> ugly one consume even less memory, e.g. make it black and white. >>>> >>> >>> I have no idea what you just tried to say :) When you say ugly replacement, >>> are you talking about the current ugly icons or do you find Esteban's >>> suggested icons not appealing enough? >>> >> It is just an addition to my first statement. If we call the current icon set medium in the sense of medium cutiness and medium memory consumption than there is a new situation with the new nice icons. Igor is right, if the vector world is coming to pharo then it is easy to make really good looking icons in the image. But the memory consumption and CPU intensity will be raised. That contradicts to usage of pharo in a server environment. So what I was saying is that I think that the new icons are great. But then there should be a replacement for it when the image is shrinked. The same happens with the fonts if you shrink. And if the icons are replaced they could even be replaced by something really basic that saves additional memory. On a server with VNC or the like the icons aren't that important and maybe can be removed completely. >> >> More clear now? >> >> Norbert >> >> > > did i miss something? since when memory consumption for vector > graphics takes more space? > look at the size of .svg files and compare them with size of .png > files for same icons. There is a difference between storage size and in-memory size. The storage size is important if you put the resource class-based. For the rest you need to decide. Either you render the icon every update from source or you do cache and from then on you have storage size + in-memory size for your icons. If you do fancy stuff automatically which means it probably uses a lot of colors so this can be quite big. > Vector data are much more compact. > So, actually if you really want to shrink things down, you need to > operate with vectors :) Yes, and then you need a lot of cpu cycles. Just what I said. > More CPU for rendering vector graphics? Perhaps. > It is of course more expensive than just copying memory from one > bitmap to another. > But desktop environment requires a lot more complex operations that > just copying bits from one form over > another one. > And also consider the cases where you need to use 5 different > operations to simulate just one. > (look at famous corner rounder hack). Again what I said. It is feasible to have good looking stuff. But everything you said is unimportant on a server. I'm just begging you not to forget that. That's all. Nothing against any of your plans. It will make pharo better. Norbert

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

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] About Cypress [Was: Re: [ANN] Styled Text Editor for Cuis 4.0 Smalltalk]

by H. Hirzel

In this sense I agree with you, Igor, and I actually had your position in the discussion on the 11th and 12 April on the metacello list (I made a small example as you, and I added XML as a third option) As I am not going to implement neither JSON, nor XML nor a Smalltalk solution I have to say that anything is fine for me. However the discussion is about Cypress and the project is moving on. See https://github.com/CampSmalltalk/Cypress/wiki --Hannes =========================================================== For ease of Reference here the full email of Dale from April 12th, 2012 See my emphasis with +++++++++++++++++ =========================================================== Guys, Guys, Guys... this is my last post on this topic ... I have not read any of the overnight posts ... I am not interested in talking about what format the property files should use. I made the decision (weeks ago) and no amount of arguing on this list will change the current implementation and the only thing that will change a future implementation is CODE. I have stated that whatever format you want to invent it should include a "literal dictionary format", because the existing code is expecting to work with Dictionaries. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I have also stated that any code produced be portable to all of the dialects participating in the project. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you meet these two requirements, it is likely that the project maintainers will just fold it in ... if it takes too much work to use your format, then you'll have to do it yourself. 1) FileTree/Cypress is using JSON 2) the current implementation is functioning just fine 3) FileTree/Cypress is designed to be flexible in terms of format, at some future date, you will be free to fork the projects and introduce your own favorite format and you are free to make the changes that are necessary in the source code for all of the dialects or use your own custom package structure on just your own projects. We are all programmers. We all understand that the data can be represented in an infinite number of formats. We all understand that it is just a small matter of writing code to implement readers and writers for this infinite number of formats. We all understand that the data is much more important than the disk format .... We should all understand that there is no right answer to the format question ... every conceivable format will work (with the appropriate amount of supporting software) ... We all have an opinion and I understand that each of you has your own opinion about what the format should be and I understand that the folks who are continuing to argue over this are not happy with my decision... That's just too bad. If you are interested in being able to use git and github and are excited at the prospect of being able to not only share code across dialects, but to collaborate on cross dialect projects, then stop worrying about the format of the file and put your energy into writing code in support of this goal (see point 3 and read it 5 times in a row). If you are arguing on these points, you are showing that you have passion ... I don't fault you for having strong opinions ... I just ask you to channel your energy into writing code on this issue or focussing on some of the harder problems that do exist... I do not intend to read any responses to this mail as far as I am concerned I am moving on to some of the much more important issues that need attention ... Dale On 4/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > you know, it is like C and their makefiles.. > in C world they cannot express the project metadata using C syntax.. > that's why they using this weird > makefiles (and many other .project formats) to glue things together.. > But hey, we can express things in smalltalk. So, why adding extra tool > to the toolchain? > > My point is not about whether it is better to use JSON over another > format. My point is that we can use smalltalk all the way down. > Because it means less dependencies and simpler tool chain (you need to > have only smalltalk parser to handle everything stored in your files, > and no extra stuff). > Because tomorrow, other guy could say: hey i love xml and i want to > store this in xml.. and provide same arguments: > it is used worldwide, and can be used for interoperability with other > languages... and so on, so on. > And he will be totally right, except from the fact that we don't need it. > > My argument is purely pragmatic: it is better having just one parser > to parse all data than two or more. > More formats, more syntax(es) means more things to worry about, and > maintain. > > > On 24 April 2012 13:02, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 24 April 2012 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >>>> Hi Igor, >>>> >>>> It is pretty clear that JSON is slowly replacing even XML elsewhere and >>>> if I for instance have to chose between XML and JSON, I'd certainly >>>> choose later. Our chunk format is, well, ours only. VW is using XML, >>>> others are using anything else. >>> >>> In a really really bad way. Because the tags are used in a non sense way. >>> You still have to parse method to get the selector :) So VW is far from >>> an example. And we are not talking about the method format, just method >>> metadata. >>> >>>> Something as neutral and as simple as >>>> JSON-based format can therefore become a bridge even between us. >>>> >>>> JSON is now becoming defacto standard for any interoperability scenario >>>> in cloud world, so IMO Dale did a right decision to choose it. We will >>>> be much closer to other words with Smalltalk that way >>> >>> Not at all. Do you really think that somebody will be interested by >>> Smalltalk just because >>> metadata of methods are stored in JSON :) >>> Come on. >> >> yeah. lets store our metadata in SQL syntax.. so we are closer to SQL >> databases.. >> LOL :) >> >>> >>>> and even more by >>>> using GitHub for code repository. >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > >

April 24, 2012

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

by Juan Vuletich (mail lists)

Hi Dale, Quoting Dale Henrichs <dhenrich(a)vmware.com>: > Bernhard and Juan, > > I was curious enough about Cypress and Cuis to start a Cypress port > to Cuis[1]. Loaded code and started working through tests: > > 19 run, 6 passed, 3 failed, 10 errors > > We'll see if I get any farther tonight:) > > Dale > > [1] https://github.com/CampSmalltalk/cuis-cypress This is great, thank you! I took a look at your format when thinking on how to do Cuis package format, and I think that for a Cuis specific package format, a single file per package will be easier to diff / merge by Git. But I really welcome and thank you for this format for cross-dialect packages! Cheers, Juan Vuletich > ----- Original Message ----- > | From: "Dale Henrichs" <dhenrich(a)vmware.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, April 23, 2012 1:57:57 PM > | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 > Smalltalk > | > | Bernhard, > | > | With regards to sharing code between dialects, I'd like to recommend > | that you look into porting Cypress to Cuis (I'm willing to help as > | much as I can). > | > | The Cypress project is aimed from the get go to enable sharing of > | packages between Smalltalk dialects with a recognition that possibly > | the most important aspect is a shared VCS (git/github). > | > | If you look at the current code base in Cypress, you will see a > | reference implementation written against Pharo. The reference > | implementation is a work in progress and the initial implementation > | was done for Amber[2]. > | > | Cypress has Monticello-like packages, but other than taking a few > | ideas from Monticello (definitions, packages and snapshots ... more > | than a few:)) the code base is independent of Monticello. The fact > | that Cypress runs on top of Amber (sans file system access) speaks > | volumes for it's portability. > | > | To paraphrase a point from my STIC talk[3] on this subject: > | > | Cypress is not intended to be the primary version control > | system for any dialect, however, if you want to share code > | between dialects you should allow your developers to import > | and export code using the Cypress package format. > | > | If you are interested, there are bits and pieces of code in a few > | other projects that I would want to pull into the Cypress project > | and couple other things that I'd like to move out of the Cypress > | project before tackling another port ... > | > | We can correspond via private email if you'd like to take me up on > | the offer of help:) > | > | Dale > | > | [1] https://github.com/CampSmalltalk/Cypress > | [2] https://github.com/CampSmalltalk/amber-cypress > | [3] > | http://portal.sliderocket.com/vmware/STIC-2012-Practical-Git-for-Smalltalk > | > | ----- Original Message ----- > | | From: "Bernhard Pieber" <bernhard(a)pieber.com> > | | To: Pharo-project(a)lists.gforge.inria.fr > | | Sent: Monday, April 23, 2012 9:53:35 AM > | | Subject: Re: [Pharo-project] [ANN] Styled Text Editor for Cuis 4.0 > | | Smalltalk > | | > | | Hi GÃ¶ran, > | | > | | Thanks for your question! I have posted the announcement of the > | | Styled Text Editor to the Pharo list as well because I still have > | | not given up on the idea to port it to Squeak and Pharo. It is not > | | straightforward but I consider it possible. > | | > | | Currently the Styled Text Editor is an external package which is > | | loaded on top of Cuis 4.0. The API it uses is quite specific to > | | Cuis > | | so to port it alone is probably too much effort. What I think can > | | be > | | done is the following: > | | Split Cuis into three parts, > | | a) the parts which are not needed for Styled Text Editor, like the > | | Cuis tools > | | b) the parts of Cuis Morphic the Styled Text Editor depends on ? > | | this > | | is in my opinion the most valuable part of Cuis because Juan spent > | | years cleaning it > | | c) the Smalltalk kernel below > | | > | | The idea is to port only part b) and the Styled Text Editor. And it > | | has to be done automatically by a tool which creates packages for > | | Squeak and Pharo, always from the latest code base. In addition you > | | will probably need small Cuis portability packages done manually, > | | one for Squeak and one for Pharo. > | | > | | Being able to always load the latest code base of Styled Text > | | Editor > | | and Cuis Morphic as an external package in Pharo is a prerequisite > | | to look into possibilities of sharing more of the code. > | | > | | I plan to write a more detailed proposal and then to approach ESUG > | | and ask for support for the funding. Any ideas for other sources of > | | funding are highly welcome and could speed things up considerably, > | | of course! ;-) > | | > | | I for one have not given up on the idea that it might be possible > | | to > | | develop substantial components as you called it ? thank you for > | | that > | | as well ? in a more Squeak-dialect-independent way. ;-) > | | > | | Finally, I would like to take the opportunity and kindly ask > | | everyone > | | who has not done so yet: Please check out Cuis 4.0 and the Styled > | | Text Editor and give us feedback, even if it does not (yet) run on > | | your favourite Squeak dialect! Thank you! > | | > | | Peace, > | | Bernhard > | | > | | P.S. Thanks to GÃ¶ran and Janko for trying to establish different > | | threads for the rather off-topic discussions that my announcement > | | posting has caused. > | | > | | Am 23.04.2012 um 16:04 schrieb GÃ¶ran Krampe: > | | > Hi! > | | > > | | > On 04/23/2012 03:40 PM, StÃ©phane Ducasse wrote: > | | >>> Just cloning it off into Pharo and forking seems... less > | | >>> optimal. > | | >>> Any ideas or thoughts? > | | >> > | | >> I do not get what you mean. I just want to work on our roadmap > | | >> and > | | >> make it getting real. > | | >> It is hard enough to get some momentum and to deliver for real. > | | >> So can you help us to get focused? > | | >> People can do what they want. I wrote a vision document. We have > | | >> a > | | >> roadmap > | | >> and we will do it. > | | > > | | > Ok, let me clarify. I was just wondering how the Pharo community > | | > wants to handle a case where a substantial component (in this > | | > case, this new editor) is not *primarily* developed in Pharo (in > | | > this case Cuis). > | | > > | | > The simple route is to just copy and fork. But IMHO this doesn't > | | > leverage the team already around this editor, right? We (Pharo) > | | > can't just go around and forking everything and maintaining > | | > everything for ourselves, right? > | | > > | | > I just got interested in that problem - now, later replies > | | > indicated that it would still need a substantial rewrite for > | | > Pharo, so perhaps the situation I am describing is not really > | | > applicable in this case. > | | > > | | > regards, GÃ¶ran > | | > > | | > | | > | | > | > >

April 24, 2012

Re: [Pharo-project] Tirade!

by GÃ¶ran Krampe

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 Igor Stasenko

you know, it is like C and their makefiles.. in C world they cannot express the project metadata using C syntax.. that's why they using this weird makefiles (and many other .project formats) to glue things together.. But hey, we can express things in smalltalk. So, why adding extra tool to the toolchain? My point is not about whether it is better to use JSON over another format. My point is that we can use smalltalk all the way down. Because it means less dependencies and simpler tool chain (you need to have only smalltalk parser to handle everything stored in your files, and no extra stuff). Because tomorrow, other guy could say: hey i love xml and i want to store this in xml.. and provide same arguments: it is used worldwide, and can be used for interoperability with other languages... and so on, so on. And he will be totally right, except from the fact that we don't need it. My argument is purely pragmatic: it is better having just one parser to parse all data than two or more. More formats, more syntax(es) means more things to worry about, and maintain. On 24 April 2012 13:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 April 2012 12:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi Igor, >>> >>> It is pretty clear that JSON is slowly replacing even XML elsewhere and >>> if I for instance have to chose between XML and JSON, I'd certainly >>> choose later. Our chunk format is, well, ours only. VW is using XML, >>> others are using anything else. >> >> In a really really bad way. Because the tags are used in a non sense way. >> You still have to parse method to get the selector :) So VW is far from >> an example. And we are not talking about the method format, just method metadata. >> >>> Something as neutral and as simple as >>> JSON-based format can therefore become a bridge even between us. >>> >>> JSON is now becoming defacto standard for any interoperability scenario >>> in cloud world, so IMO Dale did a right decision to choose it. We will >>> be much closer to other words with Smalltalk that way >> >> Not at all. Do you really think that somebody will be interested by Smalltalk just because >> metadata of methods are stored in JSON :) >> Come on. > > yeah. lets store our metadata in SQL syntax.. so we are closer to SQL > databases.. > LOL :) > >> >>> and even more by >>> using GitHub for code repository. >> >> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 24, 2012

[Pharo-project] SimpleLiteralArray Spec

by Sven Van Caekenberghe

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 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 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 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 ? - what about symbols without a leading # ? - what should be allowed in unquoted symbols ? - what should be allowed for classnames ? - what about namespaces ? - do we allow infinite precision integers ? - maybe the toplevel should always be an array ? Now: shoot! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

April 24, 2012