[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/b3103bd30be11dd8063aa9ce212a368... 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.
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@inria.fr> wrote:
Hi guys
I was browsing (at least trying) to have a look at mist https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a368...
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.
On 01 Oct 2012, at 19:44, H. Hirzel <hannes.hirzel@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
On 1 October 2012 18:54, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 01 Oct 2012, at 19:44, H. Hirzel <hannes.hirzel@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
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.
Let's have a look, UUH it's a fucking BIKE SHED! On 2012-10-01, at 20:28, Igor Stasenko <siguctua@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.
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@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@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.
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.
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@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.
On 1 October 2012 20:44, Frank Shearar <frank.shearar@gmail.com> wrote:
It's all done for you anyway, in the git commit. Who changed what when, it's all done.
right, but same applies to methods. so why storing method's stamps but not classes? either you consistently do all the turtles way down, or end up with zoo full of alien species, where nobody can tell where are they came from and why :) I don't have a readily available solution of how we can painlessly migrate from stamps -> git commit stamps. Maybe we don't need stamps for classes in the form like methods have it, because maybe one day (especially for fresh projects), we can just git stamps for everything. And, sure thing, it doesn't related to filetree alone, because our development tools and metamodel inside images also lacks this information. But since we're talking about metainformation i wanted to note about that as well, if nobody else noticed that our information about system changes would be incomplete without this.
frank
On 1 October 2012 19:42, Igor Stasenko <siguctua@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.
-- Best regards, Igor Stasenko.
On 1 October 2012 20:48, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 October 2012 20:44, Frank Shearar <frank.shearar@gmail.com> wrote:
It's all done for you anyway, in the git commit. Who changed what when, it's all done.
right, but same applies to methods. so why storing method's stamps but not classes?
Yes, that's what I understood to be your annoyance: why store timestamps for all THESE things, but not THAT thing? I just mention git commits because they do just that: everything always has an author/timestamp. frank
either you consistently do all the turtles way down, or end up with zoo full of alien species, where nobody can tell where are they came from and why :)
I don't have a readily available solution of how we can painlessly migrate from stamps -> git commit stamps. Maybe we don't need stamps for classes in the form like methods have it, because maybe one day (especially for fresh projects), we can just git stamps for everything.
And, sure thing, it doesn't related to filetree alone, because our development tools and metamodel inside images also lacks this information. But since we're talking about metainformation i wanted to note about that as well, if nobody else noticed that our information about system changes would be incomplete without this.
frank
On 1 October 2012 19:42, Igor Stasenko <siguctua@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.
-- Best regards, Igor Stasenko.
The methodProperties.json file is a stopgap until we have proper integration with git...it will eventually go away... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, October 1, 2012 12:55:50 PM | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | On 1 October 2012 20:48, Igor Stasenko <siguctua@gmail.com> wrote: | > On 1 October 2012 20:44, Frank Shearar <frank.shearar@gmail.com> | > wrote: | >> It's all done for you anyway, in the git commit. Who changed what | >> when, it's all done. | >> | > | > right, but same applies to methods. so why storing method's stamps | > but | > not classes? | | Yes, that's what I understood to be your annoyance: why store | timestamps for all THESE things, but not THAT thing? I just mention | git commits because they do just that: everything always has an | author/timestamp. | | frank | | > either you consistently do all the turtles way down, or end up with | > zoo full of alien species, where nobody can tell where are they | > came | > from and why :) | > | > I don't have a readily available solution of how we can painlessly | > migrate from stamps -> git commit stamps. | > Maybe we don't need stamps for classes in the form like methods | > have | > it, because maybe one day (especially for fresh projects), we can | > just | > git stamps for everything. | > | > And, sure thing, it doesn't related to filetree alone, | > because our development tools and metamodel inside images also | > lacks | > this information. | > But since we're talking about metainformation i wanted to note | > about | > that as well, if nobody else noticed that our information about | > system | > changes would be incomplete without this. | > | > | >> frank | >> | >> On 1 October 2012 19:42, Igor Stasenko <siguctua@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. | >>> | >> | > | > | > | > -- | > Best regards, | > Igor Stasenko. | > | |
Yes our meta model could be improved. May be foo <author: StephaneDucasse> <time: > and the Browser could hide them but this is not great Stef
It's all done for you anyway, in the git commit. Who changed what when, it's all done.
right, but same applies to methods. so why storing method's stamps but not classes? either you consistently do all the turtles way down, or end up with zoo full of alien species, where nobody can tell where are they came from and why :)
I don't have a readily available solution of how we can painlessly migrate from stamps -> git commit stamps. Maybe we don't need stamps for classes in the form like methods have it, because maybe one day (especially for fresh projects), we can just git stamps for everything.
And, sure thing, it doesn't related to filetree alone, because our development tools and metamodel inside images also lacks this information. But since we're talking about metainformation i wanted to note about that as well, if nobody else noticed that our information about system changes would be incomplete without this.
frank
On 1 October 2012 19:42, Igor Stasenko <siguctua@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.
-- Best regards, Igor Stasenko.
Hi, I like the project, but I second the concerns of Stef. But, as I understand, there seems to be consensus in this regard. One thing I still do not quite understand why we keep on having version information inside the structural information. Why is it not enough to let it only be the responsibility of the versioning system? As it is now, we are versioning the versions. If I understand correctly, the only reason is to accommodate legacy version information. If this is the case, I guess a possibility would be to just simulate this information in an initial commit, if we need it at all. Do I miss something? Cheers, Doru On Mon, Oct 1, 2012 at 10:03 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Yes our meta model could be improved.
May be
foo <author: StephaneDucasse> <time: >
and the Browser could hide them but this is not great
Stef
It's all done for you anyway, in the git commit. Who changed what when, it's all done.
right, but same applies to methods. so why storing method's stamps but not classes? either you consistently do all the turtles way down, or end up with zoo full of alien species, where nobody can tell where are they came from and why :)
I don't have a readily available solution of how we can painlessly migrate from stamps -> git commit stamps. Maybe we don't need stamps for classes in the form like methods have it, because maybe one day (especially for fresh projects), we can just git stamps for everything.
And, sure thing, it doesn't related to filetree alone, because our development tools and metamodel inside images also lacks this information. But since we're talking about metainformation i wanted to note about that as well, if nobody else noticed that our information about system changes would be incomplete without this.
frank
On 1 October 2012 19:42, Igor Stasenko <siguctua@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.
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Every thing has its own flow"
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, October 1, 2012 1:22:41 PM | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | Hi, | | I like the project, but I second the concerns of Stef. But, as I | understand, there seems to be consensus in this regard. | | One thing I still do not quite understand why we keep on having | version information inside the structural information. Why is it not | enough to let it only be the responsibility of the versioning system? | | As it is now, we are versioning the versions. | | If I understand correctly, the only reason is to accommodate legacy | version information. If this is the case, I guess a possibility would | be to just simulate this information in an initial commit, if we need | it at all. | | Do I miss something? Doru, The only point that you are missing is that the method timestamps are being included in the files themselves as a temporary measure until we have better git integration ... The original version of FileTree didn't have timestamps and for a short period I added them back in and then removed them again until this conversation occurred[3]. At that point it seemed like a good idea at the time to preserve the timestamps until they could be properly replaced by the underlying versioning system ... Cami Bruni and Max Leske are working on solving the git integration problem[1] ... as soon as we have good integration we'll be nuking the time stamp information from FileTree... Frank Shearar is working on an implementation of "the initial commit"[2] that allows one to duplicate the full Monticello history of a project in a git repository... Dale [1] https://github.com/dalehenrich/FSGit [2] http://www.lshift.net/blog/2012/08/20/monticello-git [3] http://forum.world.st/preserving-version-creator-timestamp-in-filetree-td463...
Great. I guess this is what happens if one misses too many ESUGs :). Thanks, Doru On Mon, Oct 1, 2012 at 11:44 PM, Dale Henrichs <dhenrich@vmware.com> wrote:
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, October 1, 2012 1:22:41 PM | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | Hi, | | I like the project, but I second the concerns of Stef. But, as I | understand, there seems to be consensus in this regard. | | One thing I still do not quite understand why we keep on having | version information inside the structural information. Why is it not | enough to let it only be the responsibility of the versioning system? | | As it is now, we are versioning the versions. | | If I understand correctly, the only reason is to accommodate legacy | version information. If this is the case, I guess a possibility would | be to just simulate this information in an initial commit, if we need | it at all. | | Do I miss something?
Doru,
The only point that you are missing is that the method timestamps are being included in the files themselves as a temporary measure until we have better git integration ...
The original version of FileTree didn't have timestamps and for a short period I added them back in and then removed them again until this conversation occurred[3]. At that point it seemed like a good idea at the time to preserve the timestamps until they could be properly replaced by the underlying versioning system ...
Cami Bruni and Max Leske are working on solving the git integration problem[1] ... as soon as we have good integration we'll be nuking the time stamp information from FileTree...
Frank Shearar is working on an implementation of "the initial commit"[2] that allows one to duplicate the full Monticello history of a project in a git repository...
Dale
[1] https://github.com/dalehenrich/FSGit [2] http://www.lshift.net/blog/2012/08/20/monticello-git [3] http://forum.world.st/preserving-version-creator-timestamp-in-filetree-td463...
-- www.tudorgirba.com "Every thing has its own flow"
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@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?
On 1 October 2012 20:44, Camillo Bruni <camillobruni@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.
Don't say that camillo because this is the ultimate argument against communication. Stef On Oct 1, 2012, at 8:44 PM, Camillo Bruni wrote:
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@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?
Am 01.10.2012 um 21:29 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
Don't say that camillo because this is the ultimate argument against communication.
Uh? Come on, Steph. That is something you can read frequently on the mailing list. This times just the roles have switched. So please be fair. Norbert
On Oct 1, 2012, at 8:44 PM, Camillo Bruni wrote:
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@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?
Don't say that camillo because this is the ultimate argument against communication.
Uh? Come on, Steph. That is something you can read frequently on the mailing list. This times just the roles have switched. So please be fair.
Did you see me saying no feedback? Or only if you do you can give feedback? No and this is where the difference is. Of course doing is better and more difficult. If I remind correctly we value feedback, else I would not spend my satruday afternoon looking for bugs I do not have immediate value. Stef
On 01 Oct 2012, at 20:28, Igor Stasenko <siguctua@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
On 1 October 2012 21:11, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 01 Oct 2012, at 20:28, Igor Stasenko <siguctua@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 ?
wow. you're twice as interested (posted twice). Okay, i will fileout the experimental implementation and write in separate post about it :)
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
-- Best regards, Igor Stasenko.
On 01 Oct 2012, at 20:28, Igor Stasenko <siguctua@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
Hi, Göran Krampe wrote a blog post about Smalltalk alternatives for JSON: [1] http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/ Jan. On Mon, Oct 1, 2012 at 9:14 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 01 Oct 2012, at 20:28, Igor Stasenko <siguctua@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
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@inria.fr> | To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@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/b3103bd30be11dd8063aa9ce212a368... | | 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. |
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@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@inria.fr> | To: "Pharo-project@lists.gforge.inria.fr Development" < Pharo-project@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/b3103bd30be11dd8063aa9ce212a368... | | 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. |
On 10/1/12, phil@highoctane.be <phil@highoctane.be> wrote:
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.
Thank you for reminding me of this.
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.
http://fossil-scm.org/fossil/doc/trunk/www/webui.wiki
Phil
2012/10/1 Dale Henrichs <dhenrich@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@inria.fr> | To: "Pharo-project@lists.gforge.inria.fr Development" < Pharo-project@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/b3103bd30be11dd8063aa9ce212a368... | | 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. |
On Oct 1, 2012, at 8:52 PM, Dale Henrichs wrote:
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.
Excellent! What I learned from the discussions and my own rage is that I would prefer to add a literal syntax for objects to have a JSON one. If people need a literal syntax why not.
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!
I love to hear that. Stef
Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Pharo-project@lists.gforge.inria.fr Development" <Pharo-project@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/b3103bd30be11dd8063aa9ce212a368... | | 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. |
Sorry I should not have sent this mail. I'm silly. Stef On Oct 1, 2012, at 7:00 PM, Stéphane Ducasse wrote:
Hi guys
I was browsing (at least trying) to have a look at mist https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a368...
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.
Well, looks like a passionate person having had a bad day to me. Nothing to fret about, right? 2012/10/1 Stéphane Ducasse <stephane.ducasse@inria.fr>
Sorry I should not have sent this mail. I'm silly.
Stef
On Oct 1, 2012, at 7:00 PM, Stéphane Ducasse wrote:
Hi guys
I was browsing (at least trying) to have a look at mist
https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a368...
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.
No it was quite ok :) Working at home, good music, view on my garden, flower and butterfly. Stef
Well, looks like a passionate person having had a bad day to me.
Nothing to fret about, right?
2012/10/1 Stéphane Ducasse <stephane.ducasse@inria.fr> Sorry I should not have sent this mail. I'm silly.
Stef
On Oct 1, 2012, at 7:00 PM, Stéphane Ducasse wrote:
Hi guys
I was browsing (at least trying) to have a look at mist https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a368...
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.
On 01.10.2012 22:01, Stéphane Ducasse wrote:
No it was quite ok :) Working at home, good music, view on my garden, flower and butterfly.
Stef Sounds like a Halloween trailer. Everything is peaceful and idyllic, then; JSON!
;) Cheers, Henry
:) ----- Original Message ----- | From: "Henrik Sperre Johansen" <henrik.s.johansen@veloxit.no> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, October 2, 2012 1:10:11 AM | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | On 01.10.2012 22:01, Stéphane Ducasse wrote: | > No it was quite ok :) | > Working at home, good music, view on my garden, flower and | > butterfly. | > | > Stef | Sounds like a Halloween trailer. | Everything is peaceful and idyllic, then; JSON! | | ;) | | Cheers, | Henry | |
No it was quite ok :) Working at home, good music, view on my garden, flower and butterfly.
Stef Sounds like a Halloween trailer. Everything is peaceful and idyllic, then; JSON!
yes totally scary, orange and black, and screaming :)
The parser should be named "Voorhees". On Tue, Oct 2, 2012 at 12:01 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
No it was quite ok :) Working at home, good music, view on my garden, flower and butterfly.
Stef Sounds like a Halloween trailer. Everything is peaceful and idyllic, then; JSON!
yes totally scary, orange and black, and screaming :)
participants (13)
-
blake -
Camillo Bruni -
Dale Henrichs -
Frank Shearar -
H. Hirzel -
Henrik Sperre Johansen -
Igor Stasenko -
Jan van de Sandt -
Norbert Hartl -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba