1. value() problem maybe
- Posted by slowmaker Feb 25, 2013
- 1725 views
I think value() may be choking on back ticks.
If the error is mine, could someone please help me find it?
To me, if the value() routine does not choke on debug1 (below), then it should not choke on debug2. It should just evaluate the string objects to new string objects with the following character contents:
""" eval a triple-full-quote string """
` eval a back tick string `
However, only the first one works. As far as I can tell, any simple sequence starting with the back tick will make value() fail.
I have not tried get() yet.
sequence debug1 = `""" eval a triple-full-quote string """ ` sequence debug2 = """` eval a back tick string ` """ integer debug3 = '`' include std/io.e include std/get.e sequence evaluated = value(debug1, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug1}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug1}) end if puts(1,"\n") evaluated = value(debug2, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug2}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug2}) end if puts(1,"\n") evaluated = value({debug3}, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug3}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug3}) end if puts(1,"\n")
2. Re: value() problem maybe
- Posted by SDPringle Feb 25, 2013
- 1694 views
value() has not caught up to the newer 4.0 style literals. Use Euphoria 3.1 literals instead. If you really want it, you can always look at the code in std/get.e and fix it yourself if it is not a builtin now.
Shawn Pringle
I think value() may be choking on back ticks.
If the error is mine, could someone please help me find it?
To me, if the value() routine does not choke on debug1 (below), then it should not choke on debug2. It should just evaluate the string objects to new string objects with the following character contents:
""" eval a triple-full-quote string """
` eval a back tick string `
However, only the first one works. As far as I can tell, any simple sequence starting with the back tick will make value() fail.
I have not tried get() yet.
sequence debug1 = `""" eval a triple-full-quote string """ ` sequence debug2 = """` eval a back tick string ` """ integer debug3 = '`' include std/io.e include std/get.e sequence evaluated = value(debug1, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug1}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug1}) end if puts(1,"\n") evaluated = value(debug2, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug2}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug2}) end if puts(1,"\n") evaluated = value({debug3}, 1, GET_LONG_ANSWER) if evaluated[1] = GET_SUCCESS then puts(1, "evaluated okay this time! Heres what it evaluated to:\n") printf(1,"%s\n",{debug3}) else printf(1,"DID NOT EVAL SUCCESSFULLY! Only got %d characters when evaluating this:\n%s\n",{evaluated[3], debug3}) end if puts(1,"\n")
4. Re: value() problem maybe
- Posted by slowmaker Feb 26, 2013
- 1581 views
I feel a little stupid now, for not thinking about just looking at the source to see what was going on. Thanks, guys, I'll take a look at it.
5. Re: value() problem maybe
- Posted by mattlewis (admin) Feb 26, 2013
- 1559 views
See also ticket:638
I just pushed up a change to add multi-line string support. You can download the updated std/get.e here.
It doesn't cover everything in the ticket, since it doesn't handle new comment styles or dollar terminators.
Matt
6. Re: value() problem maybe
- Posted by jimcbrown (admin) Feb 26, 2013
- 1545 views
See also ticket:638
I just pushed up a change to add multi-line string support. You can download the updated std/get.e here.
It doesn't cover everything in the ticket, since it doesn't handle new comment styles or dollar terminators.
Matt
AFAIK get.e never handled comments.
7. Re: value() problem maybe
- Posted by mattlewis (admin) Feb 26, 2013
- 1540 views
See also ticket:638
I just pushed up a change to add multi-line string support. You can download the updated std/get.e here.
It doesn't cover everything in the ticket, since it doesn't handle new comment styles or dollar terminators.
AFAIK get.e never handled comments.
According to the documentation it ignores comments like whitespace. There is a local function, read_comment() in std/get.e, but it only deals with line comments. It's been there since at least 2008.
Matt
8. Re: value() problem maybe
- Posted by jimcbrown (admin) Feb 26, 2013
- 1548 views
According to the documentation it ignores comments like whitespace. There is a local function, read_comment() in std/get.e, but it only deals with line comments. It's been there since at least 2008.
Matt
Oh. Odd. Wonder how I missed that. So that was new to 4.0...
9. Re: value() problem maybe
- Posted by slowmaker Apr 10, 2013
- 1429 views
value() has not caught up to the newer 4.0 style literals. Use Euphoria 3.1 literals instead. If you really want it, you can always look at the code in std/get.e and fix it yourself if it is not a builtin now.
Shawn Pringle
Okay, here's the start of my attempt: http://openeuphoria.org/pastey/209.wc (do we have a way to attach files? not sure pastey is the appropriate thing for me to do here)
I took a swing at updating get.e to match the documentation. Here are the changes in this version:
modified char() type range in get_ch(), changed: if ch = GET_EOF then to if ch != GET_EOF then in skip_blanks(), changed to a function returning count of whitespace skipped changed Get2() to get_verbose() and made it mostly a call to Get() with only the extra data manipulation occuring in get_verbose() added support for: sequence terminator $ new escape sequences \e, \E, \0, \b, \x, \u, \U raw strings (built around Matt Lewis's get_heredoc()) """ """, ` ` hex string specifiers x"FEED" binary string specifiers b"BEEF" ignoring block comments /* */ underline spacers in numbers 123_999_000 binary number notation 0b10101010 hex number notation 0xBEADFADE octal number notation 0t01234567 decimal number notation 0d9876543210 various other changes made necessary and/or convenient by the changes listed above; new support functions, miscellaneous tweaks made while bug chasing (WinMerge, diff, etc. will make your life easier there).
I also made one change (mistakenly) that does not match the docs but which I decided to keep and make into a feature request http://openeuphoria.org/ticket/865.wc:
This version does not require whitepace between Euphoria objects, except where the nature of the object automatically enforces it (e.g. if you butt two numbers together, obviously they will be interpreted as one, which you presumably don't want; neither this version or the old one is telepathic, can't foresee that...).
This was originally simple forgetfulness. I didn't remember that requirement from the docs, and just assumed it should be able to handle stuff like 1234"string" as two consecutive objects. By the time I noticed that part of the docs, I already had it working, so I am requesting that everybody mull that one over as a possible official behavior change (ticket should hopefully be entered by the time you read this).
So...bug reports definitely welcome; I have only done rudimentary bug testing. I will try to attend to them when and as I can, just bear in mind that my screen name is fairly accurate.
10. Re: value() problem maybe
- Posted by slowmaker Apr 17, 2013
- 1311 views
Changed my mind about the whitespace preference. Here's the updated version; should now be in full compliance with the documentation for get(), as well as a few more bug fixes.