Hi all At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits. He is waiting at Wien and is probably checking everything right now. It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :) Stef
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! Can someone post the grammar or a description of the syntax asap?
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
From memory one class of class/trait and one for extension
In class/Trait "class / trait comments comment" Special STON order for classes to minimic our logical order (ie package tag add the end). Class { } or Trait { name: #T } + Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ] + STON for meta data {category : "printing"} Since I do not know STON all the above can be wrong but this is the idea. Stef On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
for example here https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph.... and it also shows one downside --- up until now we didn't care much about how many methods are in class (because it was just another file), but now we have 10000 lines of code class. On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
From memory one class of class/trait and one for extension
In class/Trait
"class / trait comments
comment"
Special STON order for classes to minimic our logical order (ie package tag add the end).
Class {
}
or
Trait { name: #T }
+
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ]
+
STON for meta data
{category : "printing"}
Since I do not know STON all the above can be wrong but this is the idea.
Stef
On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
On 8 Sep 2017, at 22:35, Peter Uhnák <i.uhnak@gmail.com> wrote:
for example here
https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph....
but this is still WIP: for example timestamp needs to go to avoid conflicts.
and it also shows one downside --- up until now we didn't care much about how many methods are in class (because it was just another file), but now we have 10000 lines of code class.
I do not think this is a huge problem since the format is not intended to be for direct edition, but yes, this is a downside... no format will be perfect. Esteban
On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: From memory one class of class/trait and one for extension
In class/Trait
"class / trait comments
comment"
Special STON order for classes to minimic our logical order (ie package tag add the end).
Class {
}
or
Trait { name: #T }
+
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ]
+
STON for meta data
{category : "printing"}
Since I do not know STON all the above can be wrong but this is the idea.
Stef
On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
Hi Esteban,
On Sep 8, 2017, at 7:08 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 8 Sep 2017, at 22:35, Peter Uhnák <i.uhnak@gmail.com> wrote:
for example here
https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph....
but this is still WIP: for example timestamp needs to go to avoid conflicts.
If there is still time to change the syntax slightly I would get rid of the white space around the method source so instead of Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ] specify it must be Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2] because trailing white space will only accumulate, something I see in Pharo and Squeak code. Alternatively have the output add white space if required and the input remove any and all trailing white space.
and it also shows one downside --- up until now we didn't care much about how many methods are in class (because it was just another file), but now we have 10000 lines of code class.
I do not think this is a huge problem since the format is not intended to be for direct edition, but yes, this is a downside... no format will be perfect.
I don't think it's even a problem. It's a benefit.. It's /much/ more convenient to be able to edit a single file than edit many different files if editing is required. We already know the advantage it has in getting selectors out of file names :-) The main issue with a file containing many methods is method order stability. So sort by alphabetical order of method selector, not by protocol.
Esteban
On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote: From memory one class of class/trait and one for extension
In class/Trait
"class / trait comments
comment"
Special STON order for classes to minimic our logical order (ie package tag add the end).
Class {
}
or
Trait { name: #T }
+
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ]
+
STON for meta data
{category : "printing"}
Since I do not know STON all the above can be wrong but this is the idea.
Stef
On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2]
because trailing white space will only accumulate, something I see in Pharo and Squeak code.
Alternatively have the output add white space if required and the input remove any and all trailing white space.
in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was methodDeclaration [ methodBody ] but now Iâm digging also into methodDeclaration [ methodBody ] (always keeping the identity of sources idea) cheers! Esteban
Hi esteban for me having space around [ ] improves readibility. I preferred methodDeclaration [ methodbody ] over methodDeclaration [ methodbody ] Especially in case of method body is blockish like while true/exception. But this is ok if people prefer methodDeclaration [ methodbody ] Now I do not like methodDeclaration [ methodbody ] Stef On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2]
because trailing white space will only accumulate, something I see in Pharo and Squeak code.
Alternatively have the output add white space if required and the input remove any and all trailing white space.
in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was
methodDeclaration [ methodBody ]
but now Iâm digging also into
methodDeclaration [ methodBody ]
(always keeping the identity of sources idea)
cheers! Esteban
heh⦠the format I propose is like this: methodDeclaration [ methodbody ] I think that keeps good readability and I can parse it easily.
On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi esteban for me having space around [ ] improves readibility. I preferred
methodDeclaration [ methodbody ]
over
methodDeclaration [ methodbody ]
Especially in case of method body is blockish like while true/exception.
But this is ok if people prefer
methodDeclaration [ methodbody ]
Now I do not like
methodDeclaration [ methodbody ]
Stef
On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2]
because trailing white space will only accumulate, something I see in Pharo and Squeak code.
Alternatively have the output add white space if required and the input remove any and all trailing white space.
in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was
methodDeclaration [ methodBody ]
but now Iâm digging also into
methodDeclaration [ methodBody ]
(always keeping the identity of sources idea)
cheers! Esteban
Yes and this is not really good for method with multiple and long selectors because you have to spot the end of the line Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] On Sun, Sep 10, 2017 at 6:51 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
heh⦠the format I propose is like this:
methodDeclaration [ methodbody ]
I think that keeps good readability and I can parse it easily.
On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi esteban for me having space around [ ] improves readibility. I preferred
methodDeclaration [ methodbody ]
over
methodDeclaration [ methodbody ]
Especially in case of method body is blockish like while true/exception.
But this is ok if people prefer
methodDeclaration [ methodbody ]
Now I do not like
methodDeclaration [ methodbody ]
Stef
On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2]
because trailing white space will only accumulate, something I see in Pharo and Squeak code.
Alternatively have the output add white space if required and the input remove any and all trailing white space.
in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was
methodDeclaration [ methodBody ]
but now Iâm digging also into
methodDeclaration [ methodBody ]
(always keeping the identity of sources idea)
cheers! Esteban
So if you follow eliot suggestion methodDeclaration [ methodbody ] put the start in another line. because with methodDeclaration [ methodbody ] we do not identify the body as a rectangle I do not think that [ on the first line is a good idea. Remember that people will send code in email and that one day one guy (me) will extend the code browser and change my books. Stef On Mon, Sep 11, 2017 at 7:25 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes and this is not really good for method with multiple and long selectors because you have to spot the end of the line
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].]
vs.
Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ]
On Sun, Sep 10, 2017 at 6:51 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
heh⦠the format I propose is like this:
methodDeclaration [ methodbody ]
I think that keeps good readability and I can parse it easily.
On 10 Sep 2017, at 18:23, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi esteban for me having space around [ ] improves readibility. I preferred
methodDeclaration [ methodbody ]
over
methodDeclaration [ methodbody ]
Especially in case of method body is blockish like while true/exception.
But this is ok if people prefer
methodDeclaration [ methodbody ]
Now I do not like
methodDeclaration [ methodbody ]
Stef
On Sun, Sep 10, 2017 at 10:25 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Sep 2017, at 19:35, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2]
because trailing white space will only accumulate, something I see in Pharo and Squeak code.
Alternatively have the output add white space if required and the input remove any and all trailing white space.
in fact, Iâm working to remove the extra trailings this format can add. The idea is that parsed text == original text. Then, originally my format was
methodDeclaration [ methodBody ]
but now Iâm digging also into
methodDeclaration [ methodBody ]
(always keeping the identity of sources idea)
cheers! Esteban
I read all the morph class and I like the ending ] at the beginning of the line (even if I know the rectangle concern for ifTrue beck formatting) Why because it identifies really well the end of a method. It is especially good for method finishing with conditionals. ] Esteban could you generate the same class with MethodDeclaration [ .... ] I would like to browse it to see how the eye catch fast. because MethodDeclaration [ .... ] is not that nice so may be MethodDeclaration [ .... ] is a good compromise (because end of method is more important to spot that beginning. Stef
A note: Both variants below do not look nice because of the code starting at the first column. Some of the method body code lines start in the first column: Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] What about adding 4 leading spaces, easy to remove when parsing. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].] vs. Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [ "Allow the user to supply a point to serve as an arrowhead size. Answer nil if we fail to get a good point" | result | result := UIManager default request: aPrompt initialAnswer: defaultPoint asString. result isEmptyOrNil ifTrue: [^ nil]. ^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil]. ] --Hannes On 9/11/17, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I read all the morph class and I like the ending ] at the beginning of the line (even if I know the rectangle concern for ifTrue beck formatting) Why because it identifies really well the end of a method.
It is especially good for method finishing with conditionals.
]
Esteban
could you generate the same class with
MethodDeclaration [ .... ]
I would like to browse it to see how the eye catch fast.
because
MethodDeclaration [ .... ] is not that nice
so may be
MethodDeclaration [ .... ]
is a good compromise (because end of method is more important to spot that beginning.
Stef
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
but this is still WIP: for example timestamp needs to go to avoid conflicts.
why/how would this cause conflicts versus other changes? ________________________________ Fra: Pharo-dev <pharo-dev-bounces@lists.pharo.org> på vegne av Esteban Lorenzano <estebanlm@gmail.com> Sendt: 9. september 2017 11:39:12 Til: Pharo Development List Emne: Re: [Pharo-dev] About Git support for windows
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
On 9 Sep 2017, at 12:28, Henrik Nergaard <draagren@outlook.com> wrote:
but this is still WIP: for example timestamp needs to go to avoid conflicts. why/how would this cause conflicts versus other changes?
two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :) Esteban
Fra: Pharo-dev <pharo-dev-bounces@lists.pharo.org> på vegne av Esteban Lorenzano <estebanlm@gmail.com> Sendt: 9. september 2017 11:39:12 Til: Pharo Development List Emne: Re: [Pharo-dev] About Git support for windows
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
Hi Esteban,
On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 9 Sep 2017, at 12:28, Henrik Nergaard <draagren@outlook.com> wrote:
but this is still WIP: for example timestamp needs to go to avoid conflicts. why/how would this cause conflicts versus other changes?
two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :)
I think this is a serious mistake. Time stamps and author marks are important (even more important if the unit of commit is a single file for the whole class). I'm always irritated when Monticello commits carelessly edit a method back instead of reverting, hence lost my the original time stamp. I want to know who edited a method when so I can ask them for help. I don't want to see spurious changes. So making if a conflict and preserving time stamps remains important to me.
Esteban
Fra: Pharo-dev <pharo-dev-bounces@lists.pharo.org> på vegne av Esteban Lorenzano <estebanlm@gmail.com> Sendt: 9. september 2017 11:39:12 Til: Pharo Development List Emne: Re: [Pharo-dev] About Git support for windows
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
Hi!
On 9 Sep 2017, at 19:43, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Esteban,
On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 9 Sep 2017, at 12:28, Henrik Nergaard <draagren@outlook.com <mailto:draagren@outlook.com>> wrote:
but this is still WIP: for example timestamp needs to go to avoid conflicts. why/how would this cause conflicts versus other changes?
two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :)
I think this is a serious mistake. Time stamps and author marks are important (even more important if the unit of commit is a single file for the whole class). I'm always irritated when Monticello commits carelessly edit a method back instead of reverting, hence lost my the original time stamp. I want to know who edited a method when so I can ask them for help. I don't want to see spurious changes. So making if a conflict and preserving time stamps remains important to me.
thing is: we need to obtain that information in a different way than just put it there as text, because of conflicts. But I do not want to lose that information either⦠just get it in a different way. Esteban
Esteban
Fra: Pharo-dev <pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>> på vegne av Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> Sendt: 9. september 2017 11:39:12 Til: Pharo Development List Emne: Re: [Pharo-dev] About Git support for windows
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
On 09-09-17 19:43, Eliot Miranda wrote:
I think this is a serious mistake. Time stamps and author marks are important (even more important if the unit of commit is a single file for the whole class).
When converting repos from monticello to git we could add extra commits for groups of time stamp and author ranges. I'd expect them to be most common for the first monticello commits. I would expect git based commits to be one-author only. When converting, we could also fix back-edited to reverts. Stephan
Hi! I live very very much this idea! I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
Hi!
Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <alexandre.bergel@me.com>:
Hi!
I live very very much this idea!
I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information?
the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. Norbert
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
On 10 Sep 2017, at 09:50, Norbert Hartl <norbert@hartl.name> wrote:
Hi!
Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <alexandre.bergel@me.com>:
Hi!
I live very very much this idea!
I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information?
the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience.
thatâs the real problem. Thatâs why we need to find ways to have the correct timestamp using git tooling (like using git blame or something like that)
Norbert
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi all
At ESUG we discussed with Esteban, martin mcClure, Dale and (many many others :), esteban designed a nice class file format. So that we will not have 2Gb of space on harddisc, problems with long method names and sluggish commits.
Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban!
Can someone post the grammar or a description of the syntax asap?
I will commit it with a spec next week. and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects.
Esteban
He is waiting at Wien and is probably checking everything right now.
It is a nice format because we will be able to use it to communicate by emails using it. So readable, compact and I like it :)
Lovely! Details please :-)
Stef
Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order
Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 10 Sep 2017, at 10:56, Henrik-Nergaard <draagren@outlook.com> wrote:
Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order <https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order>
thatâs not related. Timestamp conflicts are related two different users touching exactly same part of source: conflict guaranteed, no matter the order. btw, Tonel export order is deterministic and it will always output same data in same way. Esteban
Best regards, Henrik
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 10 Sep 2017, at 10:56, Henrik-Nergaard <draagren@outlook.com> wrote:
Everyone who used filetree with metadata can tell it is super annoying and
destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree- metadata-in-order
thatâs not related. Timestamp conflicts are related two different users touching exactly same part of source: conflict guaranteed, no matter the order.
Just a random idea, how about each time writing timestamps to a different file name "timestamps.$HashOfClassSourceFile" Then git would never complain of a conflict(??). I haven't thought that through a lot. I guess with a git merge you end up with two "timestamps" files with different stamps for the same method so its unclear which to use - so the timestamps file might include the hash of the method source, so regardless of the mechanism to merge the ClassSourceFile, you can work back to the timestamp. For example... Morph class>>announcer { #sourceHash : '264011013dab93d02fb5c0f0f68eaa64063bc750', #category : #accessing, #timestamp : ' 8/31/2017 05:26:11' } where... (SHA1 new hashMessage: '[ ^ announcer ifNil: [ announcer := Announcer new ]. ]') hex " ==> '264011013dab93d02fb5c0f0f68eaa64063bc750' " Maybe a lot of holes in the idea, but I thought it worth stimulating a few neurons out there. cheers -ben
btw, Tonel export order is deterministic and it will always output same data in same way.
Esteban
Best regards, Henrik
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Just a random idea, how about each time writing timestamps to a different file name "timestamps.$HashOfClassSourceFile" Then git would never complain of a conflict(??).
If I understand your proposal correctly, that would imo result in the following: accumulating endless list of timestamps.XXX files (there are no conflicts and thus no mechanism to get rid of them) still having conflict, because the #sourceHash is different (any two independent changes to a line will trigger conflict) plus added complexity and a lot more reading/processing CPU/disk required P
On Tue, Sep 12, 2017 at 11:23 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Just a random idea, how about each time writing timestamps to
a different file name "timestamps.$HashOfClassSourceFile" Then git would never complain of a conflict(??).
If I understand your proposal correctly, that would imo result in the following:
accumulating endless list of timestamps.XXX files (there are no conflicts and thus no mechanism to get rid of them)
The Smalltalk code writing the class & timestamp files would take care of removing old timestamp files, so linearly git would see one file added and one removed, or after a merge, more than one timestamp file removed..
still having conflict, because the #sourceHash is different (any two independent changes to a line will trigger conflict)
#sourceHash is only written to the timestamp file, so such a line is only touched once when the timestamp file is created.
plus added complexity and a lot more reading/processing CPU/disk required
yeah... :) cheers -ben
Hi Henrik, Le 10/09/2017 à 10:56, Henrik-Nergaard a écrit :
Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. There has been a fix for this on the issue tracker for some time: https://pharo.fogbugz.com/f/cases/20251/Write-out-filetree-metadata-in-order
Could you add an issue on FileTree (github.com://dalehenrich/filetree)? It is of interest to all users of FileTree, and other things than git. Regards, Thierry
Best regards, Henrik
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
participants (12)
-
Alexandre Bergel -
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
H. Hirzel -
Henrik Nergaard -
Henrik-Nergaard
-
Norbert Hartl -
Peter Uhnák -
stephan -
Stephane Ducasse -
Thierry Goubier