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
|

Re: About Git support for windows

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

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

EstebanLM
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>> 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

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

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

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

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Hannes 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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Ben Coman
In reply to this post by EstebanLM


On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano <[hidden email]> wrote:

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. 

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



Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Peter Uhnak
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
Reply | Threaded
Open this post in threaded view
|

Re: About Git support for windows

Ben Coman


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

12