About Git support for windows
Locked
12
12
Re: About Git support for windows
 
|
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 > |
|
|
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 >> > |
Re: About Git support for windows
|
|
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 >>> >> > > |
Re: About Git support for windows
|
|
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 >>>> >>> >> >> |
Re: About Git support for windows
|
|
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: About Git support for windows
|
|
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 > > |
|
|
In reply to this post by EstebanLM
On Sun, Sep 10, 2017 at 5:06 PM, Esteban Lorenzano <[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(??). 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
|
Re: About Git support for windows
|
|
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 <[hidden email]> wrote:
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..
#sourceHash is only written to the timestamp file, so such a line is only touched once when the timestamp file is created.
yeah... :) cheers -ben |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |