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 resu
>
> 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 timestam
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:
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.
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
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 emai
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 po
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
>
> methodDeclara
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
[ method
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
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-m
> 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-filetre
>>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:
> 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 requ
t;>
>> Esteban
>>
>>>
>>>
>>> Fra: Pharo-dev >> <mailto:pharo-dev-boun...@lists.pharo.org>> på vegne av Esteban Lorenzano
>>> mailto:esteba...@gmail.com>>
>>> Sendt: 9. september 2017 11:39:12
>>> Til
> 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 hav
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
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.
>
> 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
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 på vegne av Esteban
>> Lorenzano
>> Sendt: 9. september 2017 11:39:12
>> Til: Phar
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
t, but if
both modify same line (like the timestamp line), then for sure it will be a
conflict :)
Esteban
>
>
> Fra: Pharo-dev på vegne av Esteban
> Lorenzano
> Sendt: 9. september 2017 11:39:12
> Til: Pharo Development List
> Emne: Re: [Pharo-dev] About Git suppor
ne: Re: [Pharo-dev] About Git support for windows
> 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
> 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
> 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
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, S
>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
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
>
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 ri
29 matches
Mail list logo
