Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fc... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message: ----------- Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message: ----------- Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c48...
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fc... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c48...
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351...
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/
9fd4e371ae0895078fce13ea35c491daf0e448e0
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1
liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/
c4881946c2bb8b7da7b191489dbf7ae180b05f51
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm
into Cog
vm/compare/bfe983b7a720...c4881946c2bb
2017-04-27 23:38 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ 57c9ef837f7b0914351c4836734d1df3c880c288
and of course, I forgot the comparison to this:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/bc2f9bbf14e06fe07fd...
In the second form we can review via github web interface, lay comments on diffs, use the social thing... So unless of good grief, I'd like to keep github friendly LF (until we convince github team to support CR, which is a bigger effort IMO).
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd
4e371ae0895078fce13ea35c491daf0e448e0
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1
liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c48
81946c2bb8b7da7b191489dbf7ae180b05f51
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmallta
lk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/
bfe983b7a720...c4881946c2bb
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ 57c9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd
4e371ae0895078fce13ea35c491daf0e448e0
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1
liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c48
81946c2bb8b7da7b191489dbf7ae180b05f51
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmallta
lk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/
bfe983b7a720...c4881946c2bb
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c 9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them.
CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
[1] https://en.wikipedia.org/wiki/Newline
cheers -ben
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd
4e371ae0895078fce13ea35c491daf0e448e0
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface
(1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c48
81946c2bb8b7da7b191489dbf7ae180b05f51
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmallta
lk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bf
e983b7a720...c4881946c2bb
-- _,,,^..^,,,_ best, Eliot
On 27-04-2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
Err, yeah. It’s how Smalltalk works.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
On Fri, Apr 28, 2017 at 10:10 AM, tim Rowledge tim@rowledge.org wrote:
On 27-04-2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
Is there something particularly Smalltalk related I'm not aware of that
makes CR-only line endings preferable?
Err, yeah. It’s how Smalltalk works.
I only skimmed quickly, but I don't see a reference to it here ... http://wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf
cheers -ben
On Thu, Apr 27, 2017 at 07:10:58PM -0700, tim Rowledge wrote:
On 27-04-2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
Err, yeah. It???s how Smalltalk works.
tim
Right.
If you insist on using an operating system that does not understand the concept of a record oriented file system, then you need to simulate it with some sort of agreed convention for line ending.
Emphasis on "agreed convention".
One possible way to achieve the agreed convention is to insist that every human person in the universe must use UNIX(tm), or some derivative thereof.
But the agreed convention for representing "end of line" in Smalltalk happens to be different from the equally arbitrary convention on Unix, which also happens to be different from the even more awkward but equally arbitrary convention for MS-DOS (aka Windows).
So - the agreed convention for Smalltalk is and always has been to use CR to represent end of line. And if we choose to display Smalltalk source in some way that requires line endings, such as (for example) a diff on GitHub, then it should be the responsibility of the tools on GitHub to figure out what is "a line of text" in the diff.
But we might not be able to influence the conventions on GitHub. In that case we may need to suffer the indignity of converting our line end conventions to UNIX(tm) for storage on GitHub, and converting them back to the original format when we use them in Smalltalk.
Ick. But it works, and it makes diffs display nicely on GitHub.
Dave
On 28.04.2017, at 04:10, tim Rowledge tim@rowledge.org wrote:
On 27-04-2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
Err, yeah. It’s how Smalltalk works.
Well, GemStone begs to differ for quite a while now…
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I am still waiting for the advent of the computer science groupie.
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351...
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back. Is it really that problematic?
CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
[1] https://en.wikipedia.org/wiki/Newline
cheers -ben
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fc... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c48...
-- _,,,^..^,,,_ best, Eliot
On 28.04.2017, at 07:47, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.comwrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351...
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
(in .vimrc)
set fileformats=unix,mac,dos
It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back. Is it really that problematic?
CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
[1] https://en.wikipedia.org/wiki/Newline
cheers -ben
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fc... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c48...
-- _,,,^..^,,,_ best, Eliot
On Fri, Apr 28, 2017 at 09:39:28AM +0200, Tobias Pape wrote:
On 28.04.2017, at 07:47, Eliot Miranda eliot.miranda@gmail.com wrote: On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
(in .vimrc)
set fileformats=unix,mac,dos
Tobias,
Thank you! I can't believe I have gone so many years without ever knowing about this simple editor setting.
Dave
Hi Tobias,
_,,,^..^,,,_ (phone)
On Apr 28, 2017, at 12:39 AM, Tobias Pape Das.Linux@gmx.de wrote:
On 28.04.2017, at 07:47, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.comwrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351...
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
(in .vimrc)
set fileformats=unix,mac,dos
Cool! I've found a link here: http://vim.wikia.com/wiki/File_format
"The 'fileformats' option is global and specifies which file formats will be tried when Vim reads a file (unless otherwise specified, Vim attempts to automatically detect which file format should be used to read a file). The first file format in 'fileformats' is also used as the default for a new buffer."
and there are lots of tips on the page. My three liner goes into the bin tomorrow. Thanks :-)
It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back. Is it really that problematic?
CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
[1] https://en.wikipedia.org/wiki/Newline
cheers -ben
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fc... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b... Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c48...
-- _,,,^..^,,,_ best, Eliot
2017-04-28 7:47 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c 9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back. Is it really that problematic?
CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
[1] https://en.wikipedia.org/wiki/Newline
cheers -ben
Ben, There's no need to have three ways to do the same thing, line ending. So Smalltalk has chosen one and stick to it. it was CR. Thus you will see a message #cr used everywhere in the code base (either sent to Character or to a WriteStream to write an end of line). Also, carriage return is used thru a CR variable in TextConstants pool dictionary.
The wisdom was that connections to/from outside world (external streams like files/sockets...) should do the conversion in/out the Smalltalk space. But this has been inequally applied, especially in Squeak/Pharo where the zoo of Stream is not so well engineered (it's a mess!).
Since the boundary was messy, I've taken the responsibility to introduce the complexity inside the code base by: - changing display of LF and adding hacks to display a single end of line in case of CR-LF pair - introduce nextLine et a few other methods to deal with the zoo of line endings I'm still not completely sure that it was a good idea... Maybe
If we want to change our conventions to be more fashioned, we must get rid of cr message in the code base and replace it with something like eol (end of line). Cuis has changed the CR to LF inside the image.
Nicolas
2017-04-27 23:28 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Please revert this. It is easy to write a wrapper around your favourite editor to map returns. These scripts should be in CR endings.
_,,,^..^,,,_ (phone)
On Apr 27, 2017, at 12:32 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd
4e371ae0895078fce13ea35c491daf0e448e0
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M .gitattributes M image/BuildSpurReader64Image.st M image/BuildSpurTrunk64Image.st M image/BuildSqueakSpurTrunkVMMakerImage.st M image/CompiledMethod-usesAlternateBytecodeSet.st M image/FT2Constants.st M image/LoadReader.st M image/LoadSistaSupport.st M image/Object-performwithwithwithwithwith.st M image/RunATestClass.st M image/StartReader.st M image/UpdateSqueakTrunkImage.st
Log Message:
Use LF instead of CR as image/*.st line ending
This is to be able to review/blame/ etc... from GitHub web interface
(1 liner with 500+ columns is not tool friendly)
Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c48
81946c2bb8b7da7b191489dbf7ae180b05f51
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: 2017-04-27 (Thu, 27 Apr 2017)
Changed paths: M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
Log Message:
Merge branch 'Cog' of https://github.com/OpenSmallta
lk/opensmalltalk-vm into Cog
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bf
e983b7a720...c4881946c2bb
-- _,,,^..^,,,_ best, Eliot
On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c 9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
I'd advocate going to LF EOL, but if its really important, a bit of research dug up how git can work with CR-line-ending Here is a recipe to demonstrate the effect.
First restore one commit back from "Use LF instead of CR as image/*.st line ending" $ git status # && git stash # if required $ git checkout 9fd4e371~1 HEAD detached at 11d990e nothing to commit, working directory clean $ git diff no output, okay.
Make a change in directory opensmalltalk-vm/image/ $ vi StartReader.st insert a line "comment 1" $ git diff @@ -1 +1 @@ -Transcript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1 +"comment 1"^MTranscript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1^M
yuck!
Add a git filter for ST files... $ vi opensmalltalk-vm/.git/config append... [filter "crLineEnd"] clean = tr '\r' '\n' smudge = tr '\n' '\r' $ vi opensmalltalk-vm/.gitattributes append... *.st filter=crLineEnd
Commit file so that EOLs are updated to LF internal to git. In directory opensmalltalk-vm/image/ ... $ git add StartReader.st $ git commit -m "apply filter - test only, throw away"
Now make a second change... $ vi StartReader.st insert line "comment 2" $ git diff @@ -1,4 +1,5 @@ "comment 1" +"comment 2" Transcript clear. Smalltalk snapshot: true andQuit: true. [[Processor activeProcess bindToThreadId: 2]
Better! I didn't test it on github, but IIUC it just uses `git diff`
It's a three liner to wrap vi in a script that converts from CR to LF,
invokes vi and then concerts back. Is it really that problematic?
Its not immediately obvious to me how to do that (maybe sed or tr to a temporary file that vi then edits?) So "three lines" is not really a measure of the effort required to work out how to implement it, and test that doesn't conflict with normal 'vi' usage. All this breaks from the context of what I was doing.
Anyhow Tobias's vimrc advice works.
On Fri, Apr 28, 2017 at 8:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Apr 28, 2017 at 09:39:28AM +0200, Tobias Pape wrote:
(in .vimrc)
set fileformats=unix,mac,dos
Tobias,
Thank you! I can't believe I have gone so many years without ever knowing about this simple editor setting.
Dave
Also thx Tobias. So many little corners of knowledge. This works good for me. Still not so good for the next newcomer that doesn't know this.
CR-only line endings are sooooooo last century, for machines like:
Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
On Fri, Apr 28, 2017 at 3:48 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ben, There's no need to have three ways to do the same thing, line ending.
So Smalltalk has chosen one and stick to it. it was CR.
Back when Smalltalk was created, I guess CR was the dominant platform line ending and so was the choice was "align with the dominant convention". Now that the dominant convention has progressed, the question arises whether to follow to reduce friction with other systems. The trouble of course being that there are two competing line endings LF & CRLF.
Thus you will see a message #cr used everywhere in the code base (either sent to Character or to a WriteStream to write an end of line).
Ahh. I never made that connection before.
Also, carriage return is used thru a CR variable in TextConstants pool dictionary.
The wisdom was that connections to/from outside world (external streams like files/sockets...) should do the conversion in/out the Smalltalk space. But this has been inequally applied, especially in Squeak/Pharo where the zoo of Stream is not so well engineered (it's a mess!).
Since the boundary was messy, I've taken the responsibility to introduce the complexity inside the code base by:
- changing display of LF and adding hacks to display a single end of line
in case of CR-LF pair
- introduce nextLine et a few other methods to deal with the zoo of line
endings I'm still not completely sure that it was a good idea... Maybe
If we want to change our conventions to be more fashioned, we must get rid
of cr message in the code base and replace it with something like eol (end of line).
Cuis has changed the CR to LF inside the image.
I guess Cuis aligned closely with git since thats its main mechanism for its sources (??). GNU Smalltalk uses LF (its aligned with Unix). Dolphin uses CRLF (its aligned with Windows)
Theoretically, a move to the Unicode Line Separator U+2038 might solve all problems, http://unicode.org/standard/reports/tr13/tr13-5.html but practically it doesn't (yet) seem supported by vim or emacs And of course, there is this about Standards... https://xkcd.com/927 .
cheers -ben
2017-05-01 16:44 GMT+02:00 Ben Coman btc@openinworld.com:
On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c 9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
I'd advocate going to LF EOL, but if its really important, a bit of research dug up how git can work with CR-line-ending Here is a recipe to demonstrate the effect.
First restore one commit back from "Use LF instead of CR as image/*.st line ending" $ git status # && git stash # if required $ git checkout 9fd4e371~1 HEAD detached at 11d990e nothing to commit, working directory clean $ git diff no output, okay.
Make a change in directory opensmalltalk-vm/image/ $ vi StartReader.st insert a line "comment 1" $ git diff @@ -1 +1 @@ -Transcript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1 +"comment 1"^MTranscript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1^M
yuck!
Add a git filter for ST files... $ vi opensmalltalk-vm/.git/config append... [filter "crLineEnd"] clean = tr '\r' '\n' smudge = tr '\n' '\r' $ vi opensmalltalk-vm/.gitattributes append... *.st filter=crLineEnd
Commit file so that EOLs are updated to LF internal to git. In directory opensmalltalk-vm/image/ ... $ git add StartReader.st $ git commit -m "apply filter - test only, throw away"
Now make a second change... $ vi StartReader.st insert line "comment 2" $ git diff @@ -1,4 +1,5 @@ "comment 1" +"comment 2" Transcript clear. Smalltalk snapshot: true andQuit: true. [[Processor activeProcess bindToThreadId: 2]
Better! I didn't test it on github, but IIUC it just uses `git diff`
Thanks for the tip. Sounds like a viable way to not change our line end policy. The only thing I wonder: is unixy tr available on every client? (think windows...)
It's a three liner to wrap vi in a script that converts from CR to LF,
invokes vi and then concerts back. Is it really that problematic?
Its not immediately obvious to me how to do that (maybe sed or tr to a temporary file that vi then edits?) So "three lines" is not really a measure of the effort required to work out how to implement it, and test that doesn't conflict with normal 'vi' usage. All this breaks from the context of what I was doing.
Anyhow Tobias's vimrc advice works.
On Fri, Apr 28, 2017 at 8:03 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Apr 28, 2017 at 09:39:28AM +0200, Tobias Pape wrote:
(in .vimrc)
set fileformats=unix,mac,dos
Tobias,
Thank you! I can't believe I have gone so many years without ever knowing about this simple editor setting.
Dave
Also thx Tobias. So many little corners of knowledge. This works good for me. Still not so good for the next newcomer that doesn't know this.
CR-only line endings are sooooooo last century, for machines like:
Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1]. These dogs died a long time ago ;)
Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?
On Fri, Apr 28, 2017 at 3:48 PM, Nicolas Cellier <nicolas.cellier.aka. nice@gmail.com> wrote:
Ben, There's no need to have three ways to do the same thing, line ending.
So Smalltalk has chosen one and stick to it. it was CR.
Back when Smalltalk was created, I guess CR was the dominant platform line ending and so was the choice was "align with the dominant convention". Now that the dominant convention has progressed, the question arises whether to follow to reduce friction with other systems. The trouble of course being that there are two competing line endings LF & CRLF.
Thus you will see a message #cr used everywhere in the code base (either sent to Character or to a WriteStream to write an end of line).
Ahh. I never made that connection before.
Also, carriage return is used thru a CR variable in TextConstants pool dictionary.
The wisdom was that connections to/from outside world (external streams like files/sockets...) should do the conversion in/out the Smalltalk space. But this has been inequally applied, especially in Squeak/Pharo where the zoo of Stream is not so well engineered (it's a mess!).
Since the boundary was messy, I've taken the responsibility to introduce the complexity inside the code base by:
- changing display of LF and adding hacks to display a single end of line
in case of CR-LF pair
- introduce nextLine et a few other methods to deal with the zoo of line
endings I'm still not completely sure that it was a good idea... Maybe
If we want to change our conventions to be more fashioned, we must get rid
of cr message in the code base and replace it with something like eol (end of line).
Cuis has changed the CR to LF inside the image.
I guess Cuis aligned closely with git since thats its main mechanism for its sources (??). GNU Smalltalk uses LF (its aligned with Unix). Dolphin uses CRLF (its aligned with Windows)
Theoretically, a move to the Unicode Line Separator U+2038 might solve all problems, http://unicode.org/standard/reports/tr13/tr13-5.html but practically it doesn't (yet) seem supported by vim or emacs And of course, there is this about Standards... https://xkcd.com/927 .
Hmm, yet another line ending... To me it sounds too much like what I call a "Trojan badger"... (from the sketch of Monty Python Holly Grail where the knights of the round table forgot to climb into the Trojan rabbit, and after a blank, one suggest to build a wooden badger)
cheers -ben
On Tue, May 2, 2017 at 5:23 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2017-05-01 16:44 GMT+02:00 Ben Coman btc@openinworld.com:
Theoretically, a move to the Unicode Line Separator U+2038 might solve all
problems, http://unicode.org/standard/reports/tr13/tr13-5.html but practically it doesn't (yet) seem supported by vim or emacs And of course, there is this about Standards... https://xkcd.com/927 .
Hmm, yet another line ending... To me it sounds too much like what I call a "Trojan badger"... (from the sketch of Monty Python Holly Grail where the knights of the round table forgot to climb into the Trojan rabbit, and after a blank, one suggest to build a wooden badger)
btw, Monty Python put their whole catalogue on youtube... https://youtu.be/tS_JBDRk8o0?t=177
cheers -ben
On Tue, May 2, 2017 at 5:23 PM, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
2017-05-01 16:44 GMT+02:00 Ben Coman btc@openinworld.com:
On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Eliot, it's not about my favourite editor, it's about the universally available one:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c 9ef837f7b0914351c4836734d1df3c880c288
The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF. Could you explain?
It's ok. I give up. This is another example of the tail wagging the dog, which gets on my nerves. But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.
Its not github! When looking into Sophie's issue, opening those ST scripts were unreadable when opened in `vi` . It was a pain that I had to break context to hunt for a GUI text app to read them
I'd advocate going to LF EOL, but if its really important, a bit of research dug up how git can work with CR-line-ending Here is a recipe to demonstrate the effect.
First restore one commit back from "Use LF instead of CR as image/*.st line ending" $ git status # && git stash # if required $ git checkout 9fd4e371~1 HEAD detached at 11d990e nothing to commit, working directory clean $ git diff no output, okay.
Make a change in directory opensmalltalk-vm/image/ $ vi StartReader.st insert a line "comment 1" $ git diff @@ -1 +1 @@ -Transcript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1 +"comment 1"^MTranscript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M on: Error^M do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1^M
yuck!
Add a git filter for ST files... $ vi opensmalltalk-vm/.git/config append... [filter "crLineEnd"] clean = tr '\r' '\n' smudge = tr '\n' '\r' $ vi opensmalltalk-vm/.gitattributes append... *.st filter=crLineEnd
Commit file so that EOLs are updated to LF internal to git. In directory opensmalltalk-vm/image/ ... $ git add StartReader.st $ git commit -m "apply filter - test only, throw away"
Now make a second change... $ vi StartReader.st insert line "comment 2" $ git diff @@ -1,4 +1,5 @@ "comment 1" +"comment 2" Transcript clear. Smalltalk snapshot: true andQuit: true. [[Processor activeProcess bindToThreadId: 2]
Better! I didn't test it on github, but IIUC it just uses `git diff`
Thanks for the tip. Sounds like a viable way to not change our line end policy. The only thing I wonder: is unixy tr available on every client? (think windows...)
Reading around this, it depends
If building in a Cygwin environment, then I guess that should have `tr`. But that doesn't help for building natively with MSVC.
Git For Windows (reasonably popular??) includes a bash shell + cygwin, so that should have `tr`. * https://git-for-windows.github.io/
GitHub for Windows includes PoshGit, based on Powershell * https://desktop.github.com/ and apparently you `tr` can be emulated in Powershell like this... * http://five.agency/powershell-tips-for-bash-users/
But maintaining separate scripts and determining which to install for users of random git software could get awkward. see "Why won't git hooks work on Windows" here... * https://tygertec.com/git-hooks-practical-uses-windows/
So perhaps the conversion to LFs remains a practical path forward. :shrugs:
Alternatively, although I don't quite grok these files... * https://github.com/git/git/blob/master/userdiff.c * https://github.com/git/git/blob/master/t/t4034-diff-words.sh * https://github.com/git/git/blob/master/t/t4018-diff-funcname.sh perhaps Smalltalk could be added to them, to presumably provide a "built in" gitattributes pattern... * https://git-scm.com/docs/gitattributes
cheers -ben
P.S. [off-topic] btw, Babun caught my eye as an interesting option. First I;ve heard of it... Hipsterising Windows: cygwin vs babun vs git bash vs powershell – the Onion scale https://macyves.wordpress.com/2014/09/18/hipsterising-windows-cygwin-vs-babu...
Babun - a windows shell you will love https://github.com/babun/babun
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Eliot Miranda -
GitHub -
Nicolas Cellier -
tim Rowledge -
Tobias Pape