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@inria.fr> | To: Pharo-project@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 | > | > | > | > | | |