Euphoria Ticket #789: t_literals failing

I am seeing problems involving underscore style strings These are 'extended string literal D' and 'extended string literal E'.

Details

Type: Bug Report Severity: Normal Category: Interpreter
Assigned To: SDPringle Status: Fixed Reported Release:
Fixed in SVN #: View VCS: none Milestone:

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

Search



Quick Links

User menu

Not signed in.

Misc Menu