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,
>
> 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
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
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
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
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
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
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
[
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
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:
> 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:
>
>>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:
> 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
at
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 Lore
> 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
>>
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
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
>
> 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
eban
>> 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> w
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
ember 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, Stephan
endt: 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...@gm
> 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
> 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 ---
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,
>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
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
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
29 matches
Mail list logo