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

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Camillo Bruni

Let's have a look, UUH it's a fucking BIKE SHED! On 2012-10-01, at 20:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > For me it was clear that JSON is bad, from many different sides. > I don't like that in order to load this code, my image will need JSON parser. > But Stephane, its easy to say what you don't like and more difficult > to provide a plausible alternative. > > GemStone lacks own parser, and this was (as i heard) the reason to > bring another parser into circle. > > I don't want to go and repeat myself on how you could do the same > using plain smalltalk literal syntax. > (If someone interested, lately we invented a "smalltalk object > literals" which allow you to store any object into a textual file(s) > using plain smalltalk array literal syntax, and read them back, but > for this, of course, you will need smalltalk parser). > > Anyways, leaving aside JSON syntax, here's my feedback: > > In, methodProperties.json , a method metainformation is stored like: > > { > "class" : { > "compiler:" : "MartinMcClure 10/14/2010 20:35" }, > > "instance" : { > "compiler:" : "MartinMcClure 10/14/2010 20:35", > "isNotClobbered:" : "MartinMcClure 6/18/2011 08:24", > "nextAvailableLocation" : "MartinMcClure 10/14/2010 20:40" } } > > Please, guys, do not repeat mistakes of the past, lets separate the > Author field from date stamp. > Then we don't need to enforce rules like "you can put anything into > author name, as long as it contains no spaces nor punctuation > characters" and other weirdness imposed by the way how data is stored. > Or you prefer writing full name without spaces? I'm not. But i forced > to do so, exactly because of things like that. > It would be much nicer to have this field separate, then, for instance > we could use email(s) as an author name, i.e. > "Igor Stasenko" <siguctua at gmail dot com>. > Years are passing, and who knows who will be looking at our code or > why, but as to me, if people could quickly find a way to > contact/identify original author, it would be a good plus. > > Same goes to "commentStamp" field, of course. > > And , of course, since it is git, and each method stored in separate > file, having method's stamp in another file seems a bit superfluous. > But i understand that letting git tracking this may be complicated for > legacy code. If code would be born on git repository, you would not > need any stamps aside git's ones. > > So, what i would propose , for a future perspective it to have a > special file, containing 'meta-meta' information, like "what is the > (version) of the format used to translate metainformation". So, later > , if we would want to use different storage format for metainfo, we > can easily migrate it without breaking everything. Even if we stick > with json, we might require that (like migrating from one method stamp > to another one, or adding extra meta-info etc). > > P.S. For me it is more important to have a working solution right now. > So, we can rebase our code on git. > I want to use it for our VM source code. Having everything stored in > git repo is much nicer than having C pieces stored on git but > smalltalk on monticello/metacello.. > Managing this mess takes a share of time , every time we need to > release new version. > With Git it would be much much simpler: single repository to store all .. > > P.P.S. And keep going guys. :) > > -- > Best regards, > Igor Stasenko. >

Oct. 1, 2012

[Pharo-project] Status of SmallPOS

by Stephan Eggermont

I noticed the SmallPOS on ss3 is under MIT license. AFAIK, it was GPLv3. When did this relicensing happen? Stephan

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Frank Shearar

On 1 October 2012 18:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 01 Oct 2012, at 19:44, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >> please calm down. http://mist-project.org/ looks like an interesting project. >> Actually thank you for the pointer. > > It sounds interesting, but there are other "we will start over from scratch" Smalltalk implementations that did not (yet) get anywhere, even after many years. We'll see. Fragmentation is never good. Although not as bad as in the Lisp world where literally everybody has its own implementation at one point ;-) > >> XML is not crap. JSON neither. You always talk about red pills and >> stuff.... :-) >> >> And the last time in May this year we had a lively discussion about >> JSON you wanted to write a parser for literal arrays. You are right >> that you can express the same thing in Smalltalk. Maybe we should just >> do it. >> >> Some people however do not mind to do mappings from one data format to another. > > Yeah, Stef is more sensitive/vocal to this issue than others, but he has a point. > > Even though the mappings are indeed harmless (I wrote many parsers and stuff in my life), you have to agree on 2 facts: > > - one of Smalltalk strengths is its beautifull, simple yet powerful syntax Smalltalk has a top level syntax? Oh, right. GNU Smalltalk. frank > - one of Java/whatever's ugly points is precisely the use of hunderds of lines of XML to do what is actually missing in the language > > Even though JSON is nicer that XML, it might lead to similar problems. > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Igor Stasenko

For me it was clear that JSON is bad, from many different sides. I don't like that in order to load this code, my image will need JSON parser. But Stephane, its easy to say what you don't like and more difficult to provide a plausible alternative. GemStone lacks own parser, and this was (as i heard) the reason to bring another parser into circle. I don't want to go and repeat myself on how you could do the same using plain smalltalk literal syntax. (If someone interested, lately we invented a "smalltalk object literals" which allow you to store any object into a textual file(s) using plain smalltalk array literal syntax, and read them back, but for this, of course, you will need smalltalk parser). Anyways, leaving aside JSON syntax, here's my feedback: In, methodProperties.json , a method metainformation is stored like: { "class" : { "compiler:" : "MartinMcClure 10/14/2010 20:35" }, "instance" : { "compiler:" : "MartinMcClure 10/14/2010 20:35", "isNotClobbered:" : "MartinMcClure 6/18/2011 08:24", "nextAvailableLocation" : "MartinMcClure 10/14/2010 20:40" } } Please, guys, do not repeat mistakes of the past, lets separate the Author field from date stamp. Then we don't need to enforce rules like "you can put anything into author name, as long as it contains no spaces nor punctuation characters" and other weirdness imposed by the way how data is stored. Or you prefer writing full name without spaces? I'm not. But i forced to do so, exactly because of things like that. It would be much nicer to have this field separate, then, for instance we could use email(s) as an author name, i.e. "Igor Stasenko" <siguctua at gmail dot com>. Years are passing, and who knows who will be looking at our code or why, but as to me, if people could quickly find a way to contact/identify original author, it would be a good plus. Same goes to "commentStamp" field, of course. And , of course, since it is git, and each method stored in separate file, having method's stamp in another file seems a bit superfluous. But i understand that letting git tracking this may be complicated for legacy code. If code would be born on git repository, you would not need any stamps aside git's ones. So, what i would propose , for a future perspective it to have a special file, containing 'meta-meta' information, like "what is the (version) of the format used to translate metainformation". So, later , if we would want to use different storage format for metainfo, we can easily migrate it without breaking everything. Even if we stick with json, we might require that (like migrating from one method stamp to another one, or adding extra meta-info etc). P.S. For me it is more important to have a working solution right now. So, we can rebase our code on git. I want to use it for our VM source code. Having everything stored in git repo is much nicer than having C pieces stored on git but smalltalk on monticello/metacello.. Managing this mess takes a share of time , every time we need to release new version. With Git it would be much much simpler: single repository to store all .. P.P.S. And keep going guys. :) -- Best regards, Igor Stasenko.

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Stephan Eggermont

Hannes wrote: > Some people however do not mind to do mappings from one data format to another. That is right, and I prefer to keep my meditation separate from my programming. Stephan Eggermont

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Sven Van Caekenberghe

On 01 Oct 2012, at 19:44, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > please calm down. http://mist-project.org/ looks like an interesting project. > Actually thank you for the pointer. It sounds interesting, but there are other "we will start over from scratch" Smalltalk implementations that did not (yet) get anywhere, even after many years. We'll see. Fragmentation is never good. Although not as bad as in the Lisp world where literally everybody has its own implementation at one point ;-) > XML is not crap. JSON neither. You always talk about red pills and > stuff.... :-) > > And the last time in May this year we had a lively discussion about > JSON you wanted to write a parser for literal arrays. You are right > that you can express the same thing in Smalltalk. Maybe we should just > do it. > > Some people however do not mind to do mappings from one data format to another. Yeah, Stef is more sensitive/vocal to this issue than others, but he has a point. Even though the mappings are indeed harmless (I wrote many parsers and stuff in my life), you have to agree on 2 facts: - one of Smalltalk strengths is its beautifull, simple yet powerful syntax - one of Java/whatever's ugly points is precisely the use of hunderds of lines of XML to do what is actually missing in the language Even though JSON is nicer that XML, it might lead to similar problems. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by H. Hirzel

Good evening Stephan, please calm down. http://mist-project.org/ looks like an interesting project. Actually thank you for the pointer. XML is not crap. JSON neither. You always talk about red pills and stuff.... :-) And the last time in May this year we had a lively discussion about JSON you wanted to write a parser for literal arrays. You are right that you can express the same thing in Smalltalk. Maybe we should just do it. Some people however do not mind to do mappings from one data format to another. --Hannes On 10/1/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I was browsing (at least trying) to have a look at mist > https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a36… > > and this is so nice to see json code in the middle of Smalltalk methods. > Look for class definitions there are > great. Yes it will help newcomers to jump into Smalltalk. So great. > We avoided the XML crap as in VW but apparently we will not avoid the shit > of JSON. > > May be this is the clear indication that we should all stop to code in > Smalltalk (a dead language anyway) and all switch to Javascript > in a plain happiness. Have a look this is great to read class definitions > and method categories like that. I love FileTree. I love JSON. > > What is terribly fun is that JSON could be good if we would not have a > declarative syntax for exactly the same but > new is always better. So long life to FileTree and JSON. > > Stef > PS: Of course you can all piss on me, do it if this helps you. > Now tell me that I do not have to use GitHub to browse code and all kind of > nice argumentsâ¦ > while at the same time, people are telling me the inverse. > > Yes I can stick with my old crappy browser and we will explain to our > students that we were not able to use > the syntax of our language to express nicely the same. > > PSPS: so do not ask me any help and support for such idea. >

Oct. 1, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Dale Henrichs

----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, September 30, 2012 11:25:28 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | OK | so we should not talk about it anymore and ban it from all the | configurations. | It would be good to have specific rules for configurations. The Metacello Scripting api is intended to accomplish this particular goal ... the scripting api does not send class-side messages to configurations ... with the scripting api, the configuration reverts back to its original role of specification and #latestVersion isn't part of the specification. | | BTW: what do we do with the chapter I'm working on the new book and | now I'm puzzled | because I have invested a large amount of time and I get a chapter | that you never gave feedback on and | that is probably not correct or up to date. So may be the only thing | I can do is to drop it. | And after people will tell that pharo does not have documentation but | I often fell alone. I think you have produced an excellent piece of documentation ... While my english language skills may be better than yours, your writing skills are far superior to mine ... I am a very poor writer ... I keep approaching the chapter as a writer and I want to completely rewrite things ... perhaps I should just act as a fact checker and copy editor? Pointing out factual errors and correcting the english to the best of my ability? Dale

Oct. 1, 2012

[Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by StÃ©phane Ducasse

Hi guys I was browsing (at least trying) to have a look at mist https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a36… and this is so nice to see json code in the middle of Smalltalk methods. Look for class definitions there are great. Yes it will help newcomers to jump into Smalltalk. So great. We avoided the XML crap as in VW but apparently we will not avoid the shit of JSON. May be this is the clear indication that we should all stop to code in Smalltalk (a dead language anyway) and all switch to Javascript in a plain happiness. Have a look this is great to read class definitions and method categories like that. I love FileTree. I love JSON. What is terribly fun is that JSON could be good if we would not have a declarative syntax for exactly the same but new is always better. So long life to FileTree and JSON. Stef PS: Of course you can all piss on me, do it if this helps you. Now tell me that I do not have to use GitHub to browse code and all kind of nice argumentsâ¦ while at the same time, people are telling me the inverse. Yes I can stick with my old crappy browser and we will explain to our students that we were not able to use the syntax of our language to express nicely the same. PSPS: so do not ask me any help and support for such idea.

Oct. 1, 2012

Re: [Pharo-project] detect if image was saved with Cog

by Sven Van Caekenberghe

OK, thanks guys, I learrned new things today. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 01 Oct 2012, at 17:08, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 01.10.2012 16:56, Sven Van Caekenberghe wrote: >> On 01 Oct 2012, at 16:33, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On 01.10.2012 14:43, Sven Van Caekenberghe wrote: >>>> On 01 Oct 2012, at 14:01, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>>> Endianness in header depends on the platform the image was saved on. >>>>> Which for all practical purposes, means little-endian these days. >>>> How can an image be cross-platform, but the header not ? >>>> >>> IIRC, because the VM checks which endianness the header is written in (by comparing to known image formats in big and little-endian format), and then triggering a swap of all pointers/variableWord objects when loading the image on a differing platform. >> Thanks for the answer, I suspected something like that. >> >> But that means that the image format on disk, being binary, is native only to one endianess and not the other, > Yes >> making startup or saving a image faster/slower depending on whether the conversion needs to be done, right ? Or is this automagically fixed with the first save ? >> > Swapping happens at startup, so penalty is only when loading a big-endian image on little-endian platform or vice versa. > Without saving, that happens every time, it is not automatically saved if a conversion takes place when loading. > > When saving, it saves in the platform endianness (which is the same as is in memory), and incur no extra penalty. > > Incidentally, that's the same approach I suggested Mariano use in fuel. > IMHO, it really is most optimal approach when platform endianness changes are rare, and the penalty can easily be avoided by simply saving the image on the platform it is intended to be used. > > Cheers, > Henry > >

Oct. 1, 2012