help wanted: normalising LF on tonel for Pharo project

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

help wanted: normalising LF on tonel for Pharo project

EstebanLM
Hi, 

I’ve been wondering how to better fix the problem of having windows and linux/macOS people contributing and the fact that files are written in their native system format (crlf windows, lf for the rest of the world). 

I digged a bit and I found a couple a link that helped me (after trying to understand the doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

and it seems adding a .gitattributes file with this content: 

# Auto detect text files and perform LF normalization
* text=auto
*.st text merge=union eol=lf

could fix the problem?
can someone confirm this?

(I confess this issue confuses me a lot :P)

cheers!
Esteban
Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Esteban A. Maringolo
Not stricly related, or maybe yes, but years ago in InfOil we started
using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
that setting to store code in the repo, we didn't have any issues

The .gitattributes contained this:
*.img binary
*.chg binary
*.sml binary
OurImage.img merge=ours
OurImage.chg merge=ours
*.pax eol=lf
*.cls eol=lf

.pax was the "package definition" and "method extensions" (methods not
belonging to the package) file.
.cls was the 1 file per class+class-side used by this scheme

Even we did everything in Windows for some reason I don't remember (+5
yrs ago) LF was better for Gitlab. What I also don't remember is if
during the checkout in the Gitlab CI some conversion was used or not. I
don't remember a lot of things, but I can ask them if you want.

But I can confirm that this "trick" does work.

Git for Windows even asks you if you want to automatically convert CRLF
to LF during checkin and back to CRLF on checkout.

Regards,


On 10/04/2018 18:05, Esteban Lorenzano wrote:

> Hi, 
>
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world). 
>
> I digged a bit and I found a couple a link that helped me (after trying
> to understand the
> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>
> and it seems adding a .gitattributes file with this content: 
>
> # Auto detect text files and perform LF normalization
> *text=auto
> *.sttext merge=union eol=lf
>
> could fix the problem?
> can someone confirm this?
>
> (I confess this issue confuses me a lot :P)
>
> cheers!
> Esteban

--
Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Peter Uhnák
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

There are config options `core.eol` and `core.autocrlf`, but my impression was that Iceberg was somehow bypassing them?

Peter


On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Not stricly related, or maybe yes, but years ago in InfOil we started
using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
that setting to store code in the repo, we didn't have any issues

The .gitattributes contained this:
*.img binary
*.chg binary
*.sml binary
OurImage.img merge=ours
OurImage.chg merge=ours
*.pax eol=lf
*.cls eol=lf

.pax was the "package definition" and "method extensions" (methods not
belonging to the package) file.
.cls was the 1 file per class+class-side used by this scheme

Even we did everything in Windows for some reason I don't remember (+5
yrs ago) LF was better for Gitlab. What I also don't remember is if
during the checkout in the Gitlab CI some conversion was used or not. I
don't remember a lot of things, but I can ask them if you want.

But I can confirm that this "trick" does work.

Git for Windows even asks you if you want to automatically convert CRLF
to LF during checkin and back to CRLF on checkout.

Regards,


On 10/04/2018 18:05, Esteban Lorenzano wrote:
> Hi, 
>
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world). 
>
> I digged a bit and I found a couple a link that helped me (after trying
> to understand the
> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>
> and it seems adding a .gitattributes file with this content: 
>
> # Auto detect text files and perform LF normalization
> *text=auto
> *.sttext merge=union eol=lf
>
> could fix the problem?
> can someone confirm this?
>
> (I confess this issue confuses me a lot :P)
>
> cheers!
> Esteban

--
Esteban A. Maringolo


Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Guillermo Polito
Yes, that is the thing. Is libgit reading that properties file or not? I'll do some digging..

On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák <[hidden email]> wrote:
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

There are config options `core.eol` and `core.autocrlf`, but my impression was that Iceberg was somehow bypassing them?

Peter


On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Not stricly related, or maybe yes, but years ago in InfOil we started
using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
that setting to store code in the repo, we didn't have any issues

The .gitattributes contained this:
*.img binary
*.chg binary
*.sml binary
OurImage.img merge=ours
OurImage.chg merge=ours
*.pax eol=lf
*.cls eol=lf

.pax was the "package definition" and "method extensions" (methods not
belonging to the package) file.
.cls was the 1 file per class+class-side used by this scheme

Even we did everything in Windows for some reason I don't remember (+5
yrs ago) LF was better for Gitlab. What I also don't remember is if
during the checkout in the Gitlab CI some conversion was used or not. I
don't remember a lot of things, but I can ask them if you want.

But I can confirm that this "trick" does work.

Git for Windows even asks you if you want to automatically convert CRLF
to LF during checkin and back to CRLF on checkout.

Regards,


On 10/04/2018 18:05, Esteban Lorenzano wrote:
> Hi, 
>
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world). 
>
> I digged a bit and I found a couple a link that helped me (after trying
> to understand the
> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>
> and it seems adding a .gitattributes file with this content: 
>
> # Auto detect text files and perform LF normalization
> *text=auto
> *.sttext merge=union eol=lf
>
> could fix the problem?
> can someone confirm this?
>
> (I confess this issue confuses me a lot :P)
>
> cheers!
> Esteban

--
Esteban A. Maringolo





--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

EstebanLM
In reply to this post by Esteban A. Maringolo
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>


Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Nicolai Hess-3-2
How about

git config --system  core.autocrlf input

I use this in my opensmalltalk-vm git repository. (I think I saw this option in the appveyor windows-vm build)

2018-04-10 23:44 GMT+02:00 Esteban Lorenzano <[hidden email]>:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>



Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Guillermo Polito
In reply to this post by Guillermo Polito

On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito <[hidden email]> wrote:
Yes, that is the thing. Is libgit reading that properties file or not? I'll do some digging..

On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák <[hidden email]> wrote:
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

There are config options `core.eol` and `core.autocrlf`, but my impression was that Iceberg was somehow bypassing them?

Peter


On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <[hidden email]> wrote:
Not stricly related, or maybe yes, but years ago in InfOil we started
using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
that setting to store code in the repo, we didn't have any issues

The .gitattributes contained this:
*.img binary
*.chg binary
*.sml binary
OurImage.img merge=ours
OurImage.chg merge=ours
*.pax eol=lf
*.cls eol=lf

.pax was the "package definition" and "method extensions" (methods not
belonging to the package) file.
.cls was the 1 file per class+class-side used by this scheme

Even we did everything in Windows for some reason I don't remember (+5
yrs ago) LF was better for Gitlab. What I also don't remember is if
during the checkout in the Gitlab CI some conversion was used or not. I
don't remember a lot of things, but I can ask them if you want.

But I can confirm that this "trick" does work.

Git for Windows even asks you if you want to automatically convert CRLF
to LF during checkin and back to CRLF on checkout.

Regards,


On 10/04/2018 18:05, Esteban Lorenzano wrote:
> Hi, 
>
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world). 
>
> I digged a bit and I found a couple a link that helped me (after trying
> to understand the
> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>
> and it seems adding a .gitattributes file with this content: 
>
> # Auto detect text files and perform LF normalization
> *text=auto
> *.sttext merge=union eol=lf
>
> could fix the problem?
> can someone confirm this?
>
> (I confess this issue confuses me a lot :P)
>
> cheers!
> Esteban

--
Esteban A. Maringolo





--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Peter Uhnák
In reply to this post by EstebanLM
An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>



Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

EstebanLM
In reply to this post by Nicolai Hess-3-2


On 10 Apr 2018, at 23:47, Nicolai Hess <[hidden email]> wrote:

How about

git config --system  core.autocrlf input

I use this in my opensmalltalk-vm git repository. (I think I saw this option in the appveyor windows-vm build)

that may work too. 
but… I would like to also have a way to configure automatically that (in any case, please use it while the solution arrives).

Esteban


2018-04-10 23:44 GMT+02:00 Esteban Lorenzano <[hidden email]>:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>




Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Guillermo Polito
In reply to this post by Peter Uhnák
It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <[hidden email]> wrote:
An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

EstebanLM
or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

On 10 Apr 2018, at 23:52, Guillermo Polito <[hidden email]> wrote:

It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <[hidden email]> wrote:
An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>






--
   
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Guillermo Polito
Both, the checkbox will be used to set the property in disk at some point :).

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <[hidden email]> wrote:
or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

On 10 Apr 2018, at 23:52, Guillermo Polito <[hidden email]> wrote:

It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <[hidden email]> wrote:
An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>






--
   
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: +33 06 52 70 66 13




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Peter Uhnák
In reply to this post by EstebanLM
or a .iceberg file?

Why not use `.properties`?

{
#format : #tonel,
#eol: #lf
}

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano <[hidden email]> wrote:
or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

On 10 Apr 2018, at 23:52, Guillermo Polito <[hidden email]> wrote:

It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák <[hidden email]> wrote:
An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano <[hidden email]> wrote:
hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo <[hidden email]> wrote:
>
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world).
>>
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>> (I confess this issue confuses me a lot :P)
>>
>> cheers!
>> Esteban
>
> --
> Esteban A. Maringolo
>






--
   
Guille Polito
Research Engineer


Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - http://www.cnrs.fr

Phone: +33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Images, VMs and 32 vs 64bit

Pharo Smalltalk Developers mailing list
In reply to this post by EstebanLM
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
Reply | Threaded
Open this post in threaded view
|

Re: Images, VMs and 32 vs 64bit

Peter Uhnák
> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.
Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


Reply | Threaded
Open this post in threaded view
|

Re: Images, VMs and 32 vs 64bit

Pharo Smalltalk Developers mailing list
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself.  As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!


-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:


> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.
Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


Reply | Threaded
Open this post in threaded view
|

Re: Images, VMs and 32 vs 64bit

Guillermo Polito
VMs share most of the code. At least the basic interpreter, primitives and garbage collector.
But there are some platform specificities such as how some plugins are managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself.  As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!


-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:


> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.
Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Images, VMs and 32 vs 64bit

philippeback
But once you are using an image on a given platform it may not work on another one just like that (e.g. FreeType will give trouble).

Phil

On Wed, Apr 11, 2018, 08:52 Guillermo Polito <[hidden email]> wrote:
VMs share most of the code. At least the basic interpreter, primitives and garbage collector.
But there are some platform specificities such as how some plugins are managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself.  As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!


-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:


> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.
Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Images, VMs and 32 vs 64bit

Nicolas Cellier
In reply to this post by Guillermo Polito
The general principle is that the VM insulate almost every OS specific feature: the image sees the same virtual machine.
So you can save a 32bits image on an OS, and restart it on another.
The images effectively share the same code base whatever the OS.
There might be a plugin or two which are not present on all platforms though.
If FFI is used then a few more differences will generally creep in image side
That means that some OS dependent subclasses will care of implementation details at image side.
An image carries the implementation for all platforms, but only one is active at a time.
See senders of os osVersion osName platformName

For Squeak, the image code base is the same for 32 and 64bits and I presume it's also the case for Pharo.
But you cannot save on 32 bits and restart on 64bits et vice et versa.
There are again very few implementation details that are present at image side.
For example SmallInteger maxVal changes, there are also instances of SmallFloat64 on a 64bits image, but this should be mostly transparent.
See wordSize and senders for discovering a few parts of the image sensitive to the word size... (on Squeak, FFI/Alien, image segments, ...).

Concerning the underlying OS, , so it's again the same code base, you can save an image on an OS and restart it on another.
For the VM, as Guile said, there are more changes, because there you will find a lot more implementation details.
Since the VM is implemented in (mostly) in Smalltalk, if you load VMMaker then you will see abstract superclass, and 32/64 bits specializations for some part of the VM.

2018-04-11 8:51 GMT+02:00 Guillermo Polito <[hidden email]>:
VMs share most of the code. At least the basic interpreter, primitives and garbage collector.
But there are some platform specificities such as how some plugins are managed.
Also there are different JIT backends, one per platform.
I don't know if a VM comes shipped with all of them or just the one needed.

For more details, better ask the vm-dev mailing list.

On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>, "Peter Uhnák" <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:39:16 +0000 (UTC)
Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
Thanks!

I don't really care about the image format, my question was more oriented towards the code itself.  As I don't have a Mac, I was curious as to whether there would be code differences between platforms, VMs and 32 vs 64bit distributions, code-wise!


-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <[hidden email]> wrote:


> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that there's some "platform-specific" code, but the image contains the code for all platforms at once.
Generally speaking you can code on one platform, copy the image files to another and continue your work (although doing this can cause trouble, as e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6 images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <[hidden email]> wrote:


---------- Forwarded message ----------
From: Benoit St-Jean <[hidden email]>
To: Pharo Development List <[hidden email]>
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 +0000 (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all have the exact same code base or some classes/methods are in some and not in others or different?

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)






--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: help wanted: normalising LF on tonel for Pharo project

Ben Coman
In reply to this post by EstebanLM


On 11 April 2018 at 05:05, Esteban Lorenzano <[hidden email]> wrote:
Hi, 

I’ve been wondering how to better fix the problem of having windows and linux/macOS people contributing and the fact that files are written in their native system format (crlf windows, lf for the rest of the world). 


 

I digged a bit and I found a couple a link that helped me (after trying to understand the doc): https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

and it seems adding a .gitattributes file with this content: 

# Auto detect text files and perform LF normalization
* text=auto

I see a few posts around that recommend reading http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
which about the above line says... "This is certainly better than requiring everyone to be on the same global setting for core.autocrlf, but it means that you really trust Git to do binary detection properly. In my opinion it is better to explicitly specify your text files that you want normalized."

and  https://tinyurl.com/ya9xsprx  says "We had a repo with * text=auto, and Git guessed wrong for an image file that it was a text file, causing it to corrupt it as it replaced CR + LF bytes with LF bytes in the object database."

I'm unsure.  Without it the system is subject to different users' different global settings
and I'd guess that may be a more frequent problem than Git guessing wrong. The latter 
can be fixed by a user adding an extra  .gitattributes  entry explicitly specifying the file was binary,
whereas the former seems to introduce a confounding factor. 
So probably a good line to have.

 
*.st text merge=union eol=lf

could fix the problem?
can someone confirm this?

"eol=lf"   looks appropriate...

Most editors on Windows transparently handle LF line endings.


" merge=union" I am not familiar with, but I read at...   https://git-scm.com/docs/gitattributes
"union = Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. 
This tends to leave the added lines in the resulting file in random** order and the user should verify the result. 
Do not use this if you do not understand the implications."

What are the implications of lines being merged in a random order?


btw, has doing a callback from libgit to a custom merge driver in Pharo been considered?

btw2, I found (https://githubengineering.com/move-fast/interesting...
saying... "Despite being a C library, libgit2 contains many powerful abstractions to accomplish complex tasks that Git simply cannot do. One of these features are indexes that exist solely in memory and allow work-tree related operations to be performed without an actual working directory. [...]  With the in-memory index, libgit2 is capable of merging two trees in a repository without having to check out any of their files on disk."



On 11 April 2018 at 05:55, Esteban Lorenzano <[hidden email]> wrote:
or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

Do you mean Iceberg would clone a repo, and from its included  .iceberg  file 
a matching  .gitattributes  file would be created?  
That seems like double handling. 
Why not have the user edit the  .gitattributes  file directly from Iceberg?
Iceberg might provide some appropriate templates.


cheers -ben

12