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

Re: [Pharo-project] Metacello bleedingEdge question

by StÃ©phane Ducasse

> | It would be good to have specific rules for configurations. > > The Metacello Scripting api is intended to accomplish this particular goal â¦ I was thinking in terms of Slime for Seaside. One PhD student is working on rule and I was thinking that it would be fun to have a kind of Metacello checker. do you have some rule of thumb where to look for potential problems? Because it can be a fun experience. > 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. Excellent > I think you have produced an excellent piece of documentation â¦ Thanks but I want more. I ant you to tell me if I do not write something wrong because people will read it. > While my english language skills may be better than yours, your writing skills are far superior to mine I do not know. I just write so that I can forget :) I need to release the pressure in my mind. > ... 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? Sure Do whatever you want and fit your energy, I just need feedback and I want to close it. I refrain myself to change and rewrite the chapter. I would like it to be more straight to the point but I do not have the energy anymore. > Pointing out factual errors and correcting the english to the best of my ability? perfect to me. I need feedback So if you can spot where I wrote something wrong this is what I need. If you spot englihs mistakes (I certainly do a lot of them) - please let me know I will address them. I have no problem to write. I have problem to write wrong information. > > Dale >

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 20:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > (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). Yes, I am interested ! Any pointers ? -- 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 Sven Van Caekenberghe

On 01 Oct 2012, at 20:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > (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). Yes, I am interested ! Any pointers ? -- 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

On 1 October 2012 20:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: > how much did you contribute to this project igor? > > It's open-source, so stop complaning, start implementing! > Why you taking my mere proposal (or feature request) as a complaint? I dont have energy enough for participating in this project as well. Sorry. But when i will find a time, (and if nobody else will do that before), i would be willing to implement smalltalk-based metainformation syntax. That's why i asking to put a "metadata version" somewhere, so code readers can distinguish, how they should access data stored there. Does that sounds like a complaint? As for the author stamp.. ehhh? it goes back to Squeak. I wanted to change that there.. Because it is plainly wrong idea. Or maybe you disagree with me that encoding 2 data fields inside single one is a BAD idea? And that is (sad raisedToPower: 2) to see a mistake, which replicates itself in a new project, where you free to do things right. I want best for this project, because if i wouldn't care, i would not reply at all. Sadly i cannot afford working directly on it right now. -- Best regards, Igor Stasenko.

Oct. 1, 2012

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

by phil＠highoctane.be

Just a note that may be of interest. I moved off Git and into Fossil. Check it out, it may actually be easier for us to work with since everything lives in a single Sqlite database. No more files everywhere. The author of Fossil is the author of Sqlite. The whole Tcl/Tk source moved into that as well. For me it looks like coherent with the Smalltalk idea of an image and metadata access that is easy. Not really easy to do with a bunch of files. And the commands are pretty much compatible. As an added benefit, you get a free issue tracker and wiki built in to document all of the package. Phil 2012/10/1 Dale Henrichs <dhenrich(a)vmware.com> > Stef, > > I forgot to share with you that at this last ESUG we (Jan Vrany, Martin > Kobetic and myself) agreed that the next version of Filetree will use .ston > files instead of .json files. I am planning on writing a blog post on > this...eventually. > > The Smalltalk/X implementation (Jan Vrany) is using .ston files and > version 2.0 of FileTree will using .ston files and I will be working on > version 2.0 soon. Jan is planning on using Metacello with Smaltalk/X so > I'll need to implement version 2.0 of FileTree to share code with him... > > .json files are on the way out! > > Dale > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo-project(a)lists.gforge.inria.fr Development" < > Pharo-project(a)lists.gforge.inria.fr> > | Sent: Monday, October 1, 2012 10:00:47 AM > | Subject: [Pharo-project] [Another sad day] a nice example of the mess > with json in FileTree > | > | 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] [Another sad day] a nice example of the mess with json in FileTree

by Dale Henrichs

Stef, I forgot to share with you that at this last ESUG we (Jan Vrany, Martin Kobetic and myself) agreed that the next version of Filetree will use .ston files instead of .json files. I am planning on writing a blog post on this...eventually. The Smalltalk/X implementation (Jan Vrany) is using .ston files and version 2.0 of FileTree will using .ston files and I will be working on version 2.0 soon. Jan is planning on using Metacello with Smaltalk/X so I'll need to implement version 2.0 of FileTree to share code with him... .json files are on the way out! Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Monday, October 1, 2012 10:00:47 AM | Subject: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | 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] [Another sad day] a nice example of the mess with json in FileTree

by Camillo Bruni

how much did you contribute to this project igor? It's open-source, so stop complaning, start implementing! On 2012-10-01, at 20:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > oh, and i forgot the most important thing: > > classes should also have a stamp, i.e. author and date (and perhaps mood ;). > Because it feels strange to me, that each method has stamp, even class > comments has stamp, > but not the classes. > What if my sole change is adding/removing variable(s) or changing a superclass? > This information (like who and when did that) is also very useful in > same way as for methods. > > Yes, i know that Squeak/Pharo does not support that, not sure about > other dialects. But we can do better isn't?

Oct. 1, 2012

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

by Frank Shearar

It's all done for you anyway, in the git commit. Who changed what when, it's all done. frank On 1 October 2012 19:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > oh, and i forgot the most important thing: > > classes should also have a stamp, i.e. author and date (and perhaps mood ;). > Because it feels strange to me, that each method has stamp, even class > comments has stamp, > but not the classes. > What if my sole change is adding/removing variable(s) or changing a superclass? > This information (like who and when did that) is also very useful in > same way as for methods. > > Yes, i know that Squeak/Pharo does not support that, not sure about > other dialects. But we can do better isn't? > > -- > Best regards, > Igor Stasenko. >

Oct. 1, 2012

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

by Frank Shearar

Oh, nailed in one. I was going to add less snarkily that there are two options: (a) get a real syntax for Smalltalk or (b) version things at the method level. Since the first rule of open source is "Code or GTFO", I just use FileTree and thank Dale that I don't have to write something. But either way, how many people ACTUALLY go to github and read the code? Or do you just file in a package through your Monticello browser. Because unless you DO ACTUALLY go to github and read the filed out FileTree... you don't really have any right to an opinion. Just use Monticello and pretend you didn't see any JSON. Really. frank On 1 October 2012 19:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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

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

by Igor Stasenko

oh, and i forgot the most important thing: classes should also have a stamp, i.e. author and date (and perhaps mood ;). Because it feels strange to me, that each method has stamp, even class comments has stamp, but not the classes. What if my sole change is adding/removing variable(s) or changing a superclass? This information (like who and when did that) is also very useful in same way as for methods. Yes, i know that Squeak/Pharo does not support that, not sure about other dialects. But we can do better isn't? -- Best regards, Igor Stasenko.

Oct. 1, 2012