About Git support for windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About Git support for windows

Stephane Ducasse-3
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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Eliot Miranda-2
Hi All,

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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Stephane Ducasse-3
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 <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Peter Uhnak
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 10000 lines of code class.



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


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM


On 8 Sep 2017, at 22:35, Peter Uhnák <[hidden email]> wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM
In reply to this post by Eliot Miranda-2

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


Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> på vegne av Esteban Lorenzano <[hidden email]>
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 <[hidden email]> wrote:
>
> Hi All,
>
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> 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
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM

On 9 Sep 2017, at 12:28, Henrik Nergaard <[hidden email]> 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 <[hidden email]> på vegne av Esteban Lorenzano <[hidden email]>
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 <[hidden email]> wrote:
> 
> Hi All,
> 
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> 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
>> 
> 
Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Eliot Miranda-2
In reply to this post by EstebanLM

Hi Esteban,

On Sep 8, 2017, at 7:08 PM, Esteban Lorenzano <[hidden email]> wrote:



On 8 Sep 2017, at 22:35, Peter Uhnák <[hidden email]> wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Eliot Miranda-2
In reply to this post by EstebanLM
Hi Esteban,


On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <[hidden email]> wrote:


On 9 Sep 2017, at 12:28, Henrik Nergaard <[hidden email]> 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 <[hidden email]> på vegne av Esteban Lorenzano <[hidden email]>
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 <[hidden email]> wrote:
> 
> Hi All,
> 
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> 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
>> 
> 
Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Peter Uhnak
In reply to this post by Eliot Miranda-2
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 
Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

abergel
In reply to this post by EstebanLM
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 <[hidden email]> wrote:
>
>
>> On 8 Sep 2017, at 22:02, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi All,
>>
>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> 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
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

NorbertHartl
Hi!

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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM
In reply to this post by Eliot Miranda-2
Hi!

On 9 Sep 2017, at 19:43, Eliot Miranda <[hidden email]> wrote:

Hi Esteban,


On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <[hidden email]> wrote:


On 9 Sep 2017, at 12:28, Henrik Nergaard <[hidden email]> 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 <[hidden email]> på vegne av Esteban Lorenzano <[hidden email]>
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 <[hidden email]> wrote:
> 
> Hi All,
> 
>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <[hidden email]> 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
>> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM
In reply to this post by Eliot Miranda-2

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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Henrik-Nergaard
In reply to this post by NorbertHartl
>>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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Thierry Goubier
In reply to this post by Henrik-Nergaard
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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Stephan Eggermont-3
In reply to this post by Eliot Miranda-2
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


12