Subject:
|
Re: "Well-Formed" LDraw (Was: regular expressions for DAT file subpart lines)
|
Newsgroups:
|
lugnet.off-topic.geek, lugnet.cad.dev
|
Date:
|
Thu, 24 Jun 1999 13:27:58 GMT
|
Viewed:
|
81 times
|
| |
|
|
On Wed, 23 Jun 1999 22:09:53 GMT, Sproaticus <jsproat@geocities.com> wrote:
> Steve Bliss wrote:
> > Oops, I forgot a few other odd things. I *think* your expression allows
> > these, but I'm not sure:
> > .1
> Nope, won't take a fraction w/o the integer part; gotta fix that
>
> > -.1
> Nope, same reason as above
Both of the above are common output from LDAO code.
> > 1E
> Nope, I can't even figure out what this is supposed to be without the
> mantissa! Is it just 1?
Well, I was just throwing stuff out. I don't know if LDraw would take that
one, or not.
> The hard part about using a single regular expression to detect scientific
> notation is that it might allow things like "+.E." to represent a number,
> which any respectable atoi() would choke on. I gotta think about this some
> more, see if it's even worth my time at the moment...
Darned context-sensitive constructions.
> > BTW, the color-code can be in scientific notation. The line-type can't, at
> > least, it can't in LDLite. I'm betting LDraw would recognize 1E0 as a
> > valid line-type.
>
> Hmmm... But LEdit doesn't output scientific notation in these areas. I'm
> inclined to be more liberal than restrictive, but some of these cases don't
> make any sense; i.e. fractional colors.
I didn't say they made sense. Just that they were valid input to LDraw.
> > What about line-breaks? LDraw allows those in the middle of the line. And
> > anything extra after the filename is ignored, I think. At least, on
> > line-types 2 through 5, anything after the last parameter and before a line
> > break is ignored.
>
> Arg. Broken lines would obviate a line-based parser. Pascal parsers tend
> to be character-based, while Perl makes it much easier to write line-based
> parsers.
Yep. LDraw's parser consists of the Pascal read() and readln() functions.
> I wonder if we should start to differentiate between "valid" and
> "well-formed" LDraw files, a la XML...?
That might be a useful distinction. I assume "valid" means LDraw will
render it correctly, and "well-formed" means it follows the expected forms?
"Well-formed" would not allow the following:
- Mid-command line-breaks
- Scientific notation for line-types and color codes
- Leading zeroes on values (except when the value is between 0 and 1)
Hmmm. Going outside of regular expressions, using some personal flavor of
grammar notation (and not claiming this a well-written grammar):
Start -> <command> <br> <Start>
| null
command -> 1 <ws> <subfile>
| 2 <ws> <line>
| 3 <ws> <triangle>
| 4 <ws> <quad>
| 5 <ws> <cond_line>
| 0 <ws> <meta_command>
| <ws> ; not sure this one is necessary
br -> [\cr\lf]+
subfile -> <int> <ws> (<real> <ws>){12} <filename> <ws>*
line -> <int> <ws> (<real> <ws>){5} <real> <ws>*
triangle -> <int> <ws> (<real> <ws>){8} <real> <ws>*
quad -> <int> <ws> (<real> <ws>){11} <real> <ws>*
cond_line -> <int> <ws> (<real> <ws>){11} <real> <ws>*
meta_command -> <keyword> <string>
| <string>
keyword -> PRINT
| WRITE
| STEP
| CLEAR
| SAVE
| PAUSE
| CLS
string -> {any string of text, excluding \cr and \lf}
real -> <sign> <float>
| <sign> <float> E <sign> <float>
int -> [1-9][0-9]*
| 0
float -> <int>
| <int> .
| <int> . <int>
| . <int>
sign -> +
| null
ws -> [\32\9]+ ; sorry if my escape-notation is weird
|
|
Message has 1 Reply:
Message is in Reply To:
 | | "Well-Formed" LDraw (Was: regular expressions for DAT file subpart lines)
|
| (...) Nope, won't take a fraction w/o the integer part; gotta fix that (...) Nope, same reason as above (...) Nope, won't take a fraction w/o the fraction part, gotta fix that (...) Nope, same reason as above (...) Yep! Woo-Hoo!!! :-, (...) Nope, I (...) (25 years ago, 23-Jun-99, to lugnet.off-topic.geek, lugnet.cad.dev)
|
9 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
