Euphoria
Ticket #789:
t_literals failing
-
Reported by
SDPringle
Sep 26, 2012
I am seeing problems involving underscore style strings These are 'extended string literal D' and 'extended string literal E'.
Details
1. Comment by mattlewis
Sep 26, 2012
I just built a fresh 4.1, and t_literals.e is all passing for me. Could you add some detail about the failures (which version, failure messages)?
2. Comment by DerekParnell
Sep 26, 2012
Matt, that just makes it too easy ... where's the challenge in that!?
3. Comment by SDPringle
Sep 26, 2012
I found the problem. The line endings were CRLF. I think read_line() should convert the line endings. As you know, LINUX's doesn't do that when you open with "r".
4. Comment by mattlewis
Sep 26, 2012
The line endings in the t_literals.e file? For me (on Linux) line endings are unix format.
5. Comment by jimcbrown
Sep 26, 2012
Could this be an hg setting? I recall something similar with svn, where Shawn had to set some svn property on each file to get native line endings on all source code files.
6. Comment by mattlewis
Sep 26, 2012
Possibly. I think we have it set up to store everything as unix line endings, and then on Windows you need to enable an extension to get automagic DOS line endings. I suppose it's possible that he has that extension enabled on a Linux hosted repo.
Checking...I see that in the extensions section of my Windows and Linux repos, I have "eol ="..
7. Comment by SDPringle
Sep 26, 2012
Ah, but we should have the interpreter be agnostic to the line ending types. Don't you agree?
8. Comment by jimcbrown
Sep 26, 2012
As a stubborn old unix hand, I really really really want to disagree ... if it's good enough for the Bourne shell, it should be good enough for Euphoria!
...
...
...
That said, having Euphoria ignore line ends on source code is probably the most user friendly thing to do. Perhaps it should even treat \r as a line ending to be mac friendly.
I (very relucantly) agree.
9. Comment by mattlewis
Sep 26, 2012
This discussion sounds very familiar. Looking in scanner.e, in ExtendedString() I see:
if ch != '\r' then
-- Ok, so its not a perfect 'raw' literal string.
-- All carriage returns are removed.
string_text &= ch
So...what's really going on here? Derek did this 3 years ago, saying:
changeset 2466:ecbc102cf652
* Raw string literals will now never contain a carriage return character. Any found are simply removed.
10. Comment by SDPringle
Sep 26, 2012
Okay, while inside the string this is done before the trimming it isn't done. It is better to do this in read_line() when we read from the file.
11. Comment by mattlewis
Sep 26, 2012
Do we really care? Is this really a bug? I'm not seeing it. Have you figured out why the tests are failing for you?
12. Comment by SDPringle
Sep 26, 2012
See: hg:euphoria/rev/9a37df04dbd4
changeset: 5688:9a37df04dbd4 branch: 4.0 user: Shawn Pringle <shawn.pringle@gmail.com> date: Wed Sep 26 16:23:14 2012 -0300 files: source/scanner.e description:
- make scanner EOL agnostic
- fixes ticket 789
13. Comment by SDPringle
Sep 28, 2012
See: hg:euphoria/rev/d69594cbac16
changeset: 5695:d69594cbac16 branch: 4.0 tag: tip user: Shawn Pringle <shawn.pringle@gmail.com> date: Fri Sep 28 19:37:20 2012 -0300 files: docs/release/4.0.5.txt description:
- document fix for ticket 789