Re: [Pharo-dev] About Git support for windows

[Ben Coman]

On Tue, Sep 12, 2017 at 11:23 PM, Peter Uhnák  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

Re: [Pharo-dev] About Git support for windows

[Peter Uhnák]

>
> 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

Re: [Pharo-dev] About Git support for windows

[Ben Coman]

On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano 
wrote:

>
> On 10 Sep 2017, at 10:56, Henrik-Nergaard  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
>
>
>

Re: [Pharo-dev] About Git support for windows

[H. Hirzel]

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  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
>
>

Re: [Pharo-dev] About Git support for windows

[Stephane Ducasse]

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

Re: [Pharo-dev] About Git support for windows

[Stephane Ducasse]

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
 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  
> 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  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  
>>> wrote:

 On 9 Sep 2017, at 19:35, Eliot Miranda  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

>>>
>>
>>

Re: [Pharo-dev] About Git support for windows

[Stephane Ducasse]

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  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  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  
>> wrote:
>>>
>>> On 9 Sep 2017, at 19:35, Eliot Miranda  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
>>>
>>
>
>

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

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  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  
> wrote:
>> 
>> On 9 Sep 2017, at 19:35, Eliot Miranda  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
>> 
> 

Re: [Pharo-dev] About Git support for windows

[Stephane Ducasse]

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  wrote:
>
> On 9 Sep 2017, at 19:35, Eliot Miranda  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
>

Re: [Pharo-dev] About Git support for windows

[stephan]

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

Re: [Pharo-dev] About Git support for windows

[Thierry Goubier]

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

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 10 Sep 2017, at 10:56, Henrik-Nergaard  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. 

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
> 

Re: [Pharo-dev] About Git support for windows

[Henrik-Nergaard]

>>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

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 9 Sep 2017, at 19:35, Eliot Miranda  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

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

Hi!

> On 9 Sep 2017, at 19:43, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> 
> Hi Esteban,
> 
> 
> On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <esteba...@gmail.com 
> <mailto:esteba...@gmail.com>> wrote:
> 
>> 
>>> On 9 Sep 2017, at 12:28, Henrik Nergaard <draag...@outlook.com 
>>> <mailto:draag...@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-boun...@lists.pharo.org 
>>> <mailto:pharo-dev-boun...@lists.pharo.org>> på vegne av Esteban Lorenzano 
>>> <esteba...@gmail.com <mailto:esteba...@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.mira...@gmail.com 
>>> > <mailto:eliot.mira...@gmail.com>> wrote:
>>> > 
>>> > Hi All,
>>> > 
>>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.s...@gmail.com 
>>> >> <mailto:stepharo.s...@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
>>> >> 
>>> > 
>> 

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 10 Sep 2017, at 09:50, Norbert Hartl  wrote:
> 
> Hi! 
> 
>> Am 10.09.2017 um 05:44 schrieb Alexandre Bergel :
>> 
>> 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  wrote:
>>> 
>>> 
 On 8 Sep 2017, at 22:02, Eliot Miranda  wrote:
 
 Hi All,
 
> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  
> 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
> 
 
>>> 
>>> 
> 

Re: [Pharo-dev] About Git support for windows

[Norbert Hartl]

Hi! 

> Am 10.09.2017 um 05:44 schrieb Alexandre Bergel :
> 
> 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  wrote:
>> 
>> 
>>> On 8 Sep 2017, at 22:02, Eliot Miranda  wrote:
>>> 
>>> Hi All,
>>> 
 On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  
 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
 
>>> 
>> 
>> 

Re: [Pharo-dev] About Git support for windows

[Alexandre Bergel]

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  wrote:
> 
> 
>> On 8 Sep 2017, at 22:02, Eliot Miranda  wrote:
>> 
>> Hi All,
>> 
>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  
>>> 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
>>> 
>> 
> 
> 

Re: [Pharo-dev] About Git support for windows

[Peter Uhnák]

>
> I don't think it's even a problem
>

I do remember that I hated long classes because of git conflicts, but I
suppose if we have good tooling for that it shouldn't be such a pain. Git
can sometimes make the diff really weirdly...

Peter

Re: [Pharo-dev] About Git support for windows

[Eliot Miranda]

Hi Esteban,


> On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <esteba...@gmail.com> wrote:
> 
> 
>> On 9 Sep 2017, at 12:28, Henrik Nergaard <draag...@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-boun...@lists.pharo.org> på vegne av Esteban 
>> Lorenzano <esteba...@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.mira...@gmail.com> wrote:
>> > 
>> > Hi All,
>> > 
>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.s...@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
>> >> 
>> > 
> 

Re: [Pharo-dev] About Git support for windows

[Eliot Miranda]

Hi Esteban,

> On Sep 8, 2017, at 7:08 PM, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 8 Sep 2017, at 22:35, Peter Uhnák  wrote:
>> 
>> for example here
>> 
>> https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph.class.st
>> 
> 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 1 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  
>>> 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  
>>> wrote:
>>> > Hi All,
>>> >
>>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  
>>> >> 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
>>> >>
>>> >
>>> 
>> 

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 9 Sep 2017, at 12:28, Henrik Nergaard <draag...@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-boun...@lists.pharo.org> på vegne av Esteban 
> Lorenzano <esteba...@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.mira...@gmail.com> wrote:
> > 
> > Hi All,
> > 
> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.s...@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
> >> 
> > 

Re: [Pharo-dev] About Git support for windows

[Henrik Nergaard]

>> 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-boun...@lists.pharo.org> på vegne av Esteban 
Lorenzano <esteba...@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.mira...@gmail.com> wrote:
>
> Hi All,
>
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.s...@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
>>
>

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 8 Sep 2017, at 22:02, Eliot Miranda  wrote:
> 
> Hi All,
> 
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  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
>> 
> 

Re: [Pharo-dev] About Git support for windows

[Esteban Lorenzano]

> On 8 Sep 2017, at 22:35, Peter Uhnák  wrote:
> 
> for example here
> 
> https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph.class.st
> 
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 
> 1 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  
>> 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  
>> wrote:
>> > Hi All,
>> >
>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  
>> >> 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
>> >>
>> >
>> 
> 

Re: [Pharo-dev] About Git support for windows

[Peter Uhnák]

for example here

https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph.class.st

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 1 lines of code class.



On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse 
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 
> wrote:
> > Hi All,
> >
> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse 
> 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
> >>
> >
>
>

Re: [Pharo-dev] About Git support for windows

[Stephane Ducasse]

>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  wrote:
> Hi All,
>
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  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
>>
>

Re: [Pharo-dev] About Git support for windows

[Eliot Miranda]

Hi All,

> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse  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
>