Feature request: recognize the line break in multi line string
The following code:
echo("abcdef1");
echo("abc\ndef2");
echo("abc
def3");
generate:
ECHO: "abcdef1"
ECHO: "abc
def2"
ECHO: "abcdef3" // line break ignored
i.e, line breaks in a multi-line string is ignored. Is it possible to get
openscad to recognize them ?
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
tips: hash( 1 , 2 ), sweep , var
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 09/13/2015 04:13 AM, runsun wrote:
i.e, line breaks in a multi-line string is ignored. Is it possible to get
openscad to recognize them ?
Possible yes, but I'm not sure it's a good idea. With the line
separator having at least 3 variations across platforms, that
could result in unexpected results depending on how the file
was saved.
Actually I'd rather consider that behavior for multi-line strings
a bug ;-). How are other scripting languages coping with that?
At least with bash, the string length differs when changing the
file format.
ciao,
Torsten.
tp3 wrote
Actually I'd rather consider that behavior for multi-line strings
a bug ;-). How are other scripting languages coping with that?
At least with bash, the string length differs when changing the
file format.
In python we can do:
s='''abc
def'''
len(s) ==> 7
s.split('\n') ==> ['abc', 'def']
$ Runsun Pan, PhD
$ -- libs: doctest , faces ( git ), offliner ( git );
tips: hash( 1 , 2 ), sweep , var
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Feature-request-recognize-the-line-break-in-multi-line-string-tp13789p13797.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
The line separator has 2 variations: \n on Macintosh, Linux, BSD, and \r\n
on Windows.
So change the lexer to ignore \r but preserve \n when scanning a string
literal, and the results will be platform independent.
On 13 September 2015 at 06:36, Torsten Paul Torsten.Paul@gmx.de wrote:
On 09/13/2015 04:13 AM, runsun wrote:
i.e, line breaks in a multi-line string is ignored. Is it possible to get
openscad to recognize them ?
Possible yes, but I'm not sure it's a good idea. With the line
separator having at least 3 variations across platforms, that
could result in unexpected results depending on how the file
was saved.
Actually I'd rather consider that behavior for multi-line strings
a bug ;-). How are other scripting languages coping with that?
At least with bash, the string length differs when changing the
file format.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 09/13/2015 10:58 PM, doug moen wrote:
The line separator has 2 variations: \n on Macintosh, Linux, BSD, and \r\n
on Windows.
While newer MacOS does use \n, I would not be surprised to still
find the old \r separator in some cases.
Anyway, I guess the main question is if it should be changed or
not. The risk breaking existing scripts is probably not too
high.
Normalizing to always use \n makes sense and might even be
already done by the QTextStream used in GUI mode, not sure
about command line mode though.
ciao,
Torsten.
On Sun, 13 Sep 2015 16:58:00 -0400
doug moen doug@moens.org wrote:
The line separator has 2 variations: \n on Macintosh, Linux, BSD, and \r\n
on Windows.
So change the lexer to ignore \r but preserve \n when scanning a string
literal, and the results will be platform independent.
There are systems that just use \r.
Just convert the files in format while moving them between systems.
Alan
Alan Cox said "There are systems that just use \r."
Not any more, and not for a long time. Apple dropped support for Mac OS 9
in 2002, and OpenSCAD seems to have started in 2009. Xt has also never
supported MacOS 9. You've never been able to create a text file with \r
line separators on any system that supports OpenSCAD, and those systems
likely only exist in computer museums nowadays.
On Sun, 13 Sep 2015 19:49:53 -0400
doug moen doug@moens.org wrote:
Alan Cox said "There are systems that just use \r."
Not any more, and not for a long time. Apple dropped support for Mac
OS 9 in 2002, and OpenSCAD seems to have started in 2009. Xt has also
never supported MacOS 9. You've never been able to create a text file
with \r line separators on any system that supports OpenSCAD, and
those systems likely only exist in computer museums nowadays.
Less than a month ago, I got an example data file from a company that
was using \r as a line separator. I don't know for sure where they got
it. (Of course a quick one-liner converted it to something reasonable
for me.)
Until that time, I believed that you were correct. Now, I'm not sure I
would discount Alan's comment so quickly.
G. Wade
It's hard enough to find an error in your code when you're looking for
it; it's even harder when you've assumed your code is error-free.
-- Steve McConnell
Well, it turns out that \r line termination was also used by a number of
popular 8 bit operating systems during the 1980s, including Apple II,
Commodore Pet, TRS-80, and OS-9. And it seems that OS 9 continues to be
used for embedded applications like in-car navigation systems and traffic
light control systems.
But I don't know why we should care about supporting users who are editing
their OpenSCAD source files on Apple IIs or embedded traffic light control
computers.
On 13 September 2015 at 21:22, G. Wade Johnson gwadej@anomaly.org wrote:
On Sun, 13 Sep 2015 19:49:53 -0400
doug moen doug@moens.org wrote:
Alan Cox said "There are systems that just use \r."
Not any more, and not for a long time. Apple dropped support for Mac
OS 9 in 2002, and OpenSCAD seems to have started in 2009. Xt has also
never supported MacOS 9. You've never been able to create a text file
with \r line separators on any system that supports OpenSCAD, and
those systems likely only exist in computer museums nowadays.
Less than a month ago, I got an example data file from a company that
was using \r as a line separator. I don't know for sure where they got
it. (Of course a quick one-liner converted it to something reasonable
for me.)
Until that time, I believed that you were correct. Now, I'm not sure I
would discount Alan's comment so quickly.
G. Wade
It's hard enough to find an error in your code when you're looking for
it; it's even harder when you've assumed your code is error-free.
-- Steve McConnell
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sun, 13 Sep 2015 20:22:19 -0500
"G. Wade Johnson" gwadej@anomaly.org wrote:
On Sun, 13 Sep 2015 19:49:53 -0400
doug moen doug@moens.org wrote:
Alan Cox said "There are systems that just use \r."
Not any more, and not for a long time. Apple dropped support for Mac
OS 9 in 2002, and OpenSCAD seems to have started in 2009. Xt has also
never supported MacOS 9. You've never been able to create a text file
with \r line separators on any system that supports OpenSCAD, and
those systems likely only exist in computer museums nowadays.
Less than a month ago, I got an example data file from a company that
was using \r as a line separator. I don't know for sure where they got
it. (Of course a quick one-liner converted it to something reasonable
for me.)
Until that time, I believed that you were correct. Now, I'm not sure I
would discount Alan's comment so quickly.
Ignoring the \r isn't the way to do it. The logic is trivial to do it
right
\r\n -> one newline
else
\r -> one newline
else
\n -> one newline
else
literal character
Alan