| |
Hi all...I just found out about MLCAD/Ldraw/Lpub last week, and I've been trying
to figure out all the programs. I was able to create an .mpd of an archway with
a clocktower above it. It seems to work fine in MLCAD, but when I try to build
instruction images using Lpub, it freezes up the program.
My .mpd consists of four .ldr files:
Archway top.ldr
Archway full top.ldr
Clocktower base.ldr
Tunnel base.ldr
1) When I try to build the instruction images through Lpub, an error message
appears--"count_steps: failed to open file Archway for reading". Lpub then
freezes and I have to close it down using task manager
2)There is a single 1 kb file in my models folder called "Archway" (no extension
on the file). If I delete this file, and then try to build instructions, it now
reads: "create_mpd_construction_dats needs to create file
C:\LDRAW\MODELS\Archway, but it already exists"
I tested the building instructions function of Lpub out using a simple ldr file
from the tutorial on ldraw.org, and it worked fine (downloaded POV RAy 3.1,
Mega-POV, and L3P). I'm guessing it is a problem with the way I constructed my
original .mpd, as I was fairly unsure of what I was doing. However, when I
create instruction images using MLCAD on my final .mpd, it seems to work ok.
Anyone have any ideas as to what I'm doing wrong? Thanks, in advance. Feel
free to email me.
Raj
|
|
| |
In lugnet.cad, Rajesh Shah wrote:
> Hi all...I just found out about MLCAD/Ldraw/Lpub last week, and I've been trying
> to figure out all the programs. I was able to create an .mpd of an archway with
> a clocktower above it. It seems to work fine in MLCAD, but when I try to build
> instruction images using Lpub, it freezes up the program.
>
> My .mpd consists of four .ldr files:
>
> Archway top.ldr
> Archway full top.ldr
> Clocktower base.ldr
> Tunnel base.ldr
Try removing the blanks from your file names.
>
> 1) When I try to build the instruction images through Lpub, an error message
> appears--"count_steps: failed to open file Archway for reading". Lpub then
> freezes and I have to close it down using task manager
>
> 2)There is a single 1 kb file in my models folder called "Archway" (no extension
> on the file). If I delete this file, and then try to build instructions, it now
> reads: "create_mpd_construction_dats needs to create file
> C:\LDRAW\MODELS\Archway, but it already exists"
Blanks in file names again.
>
> I tested the building instructions function of Lpub out using a simple ldr file
> from the tutorial on ldraw.org, and it worked fine (downloaded POV RAy 3.1,
> Mega-POV, and L3P). I'm guessing it is a problem with the way I constructed my
> original .mpd, as I was fairly unsure of what I was doing. However, when I
> create instruction images using MLCAD on my final .mpd, it seems to work ok.
> Anyone have any ideas as to what I'm doing wrong? Thanks, in advance. Feel
> free to email me.
I'll work on the blanks in filename problem in LPub.
Kevin
>
> Raj
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
I’ll work on the blanks in filename problem in LPub.
|
That will be so nice. Thank you! That one caught me again just this afternoon.
And I know better. However, I just forgot at one point, added a space to a file
name and.... well you know the rest. :)
Anyway, glad to hear it’s fixable.
Best regards,
Allan B.
The LEGO Builder’s Guide
|
|
| |
In lugnet.cad, Allan Bedford wrote:
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
I’ll work on the blanks in filename problem in LPub.
|
That will be so nice. Thank you! That one caught me again just this
afternoon. And I know better. However, I just forgot at one point, added a
space to a file name and.... well you know the rest. :)
Anyway, glad to hear it’s fixable.
Best regards,
Allan B.
The LEGO Builder’s Guide
|
Hi Allan,
In light of this article:
http://news.lugnet.com/cad/?n=12556
I now have a dilema on this topic. Add code that makes me compatible with
MLCad but violating the specification, or leave it as is and explain to people
that MLCad does allow blanks in file names, but that violates the spec.
Michael, what is your take on this issue?
Kevin
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
In lugnet.cad, Allan Bedford wrote:
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
I’ll work on the blanks in filename problem in LPub.
|
That will be so nice. Thank you! That one caught me again just this
afternoon. And I know better. However, I just forgot at one point, added a
space to a file name and.... well you know the rest. :)
Anyway, glad to hear it’s fixable.
Best regards,
Allan B.
The LEGO Builder’s Guide
|
Hi Allan,
In light of this article:
http://news.lugnet.com/cad/?n=12556
I now have a dilema on this topic. Add code that makes me compatible with
MLCad but violating the specification, or leave it as is and explain to
people that MLCad does allow blanks in file names, but that violates the
spec.
|
I apologize in advance if this is a stupid solution but what about this:
Is there a way for you to check for spaces in the file name as lpub attempts to
open it? If so, can you then abort the file open process and throw a pop-up
message that says something like:
”You are attempting to open a file that contains spaces in the name. Please
rename the file, without spaces, and try opening the file again.“
At the moment the biggest problem (as I see it) is the lack of error handling
when lpub tries to handle a file with spaces. It returns all kinds of messages
but is the real error listed there? If so, I didn’t see it last time it
happened. It was only after manually looking at my filename that I realized
what had happened. If lpub could simply be a bit more pro-active, I feel that
would be the easiest solution to code and also keep you in line with the spec.
I hope that helps. Again, this is just my own opinion on the matter.
Best regards,
Allan B.
|
|
| |
In lugnet.cad, Allan Bedford wrote:
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
In lugnet.cad, Allan Bedford wrote:
| |
In lugnet.cad, Kevin L. Clague wrote:
| |
I’ll work on the blanks in filename problem in LPub.
|
That will be so nice. Thank you! That one caught me again just this
afternoon. And I know better. However, I just forgot at one point, added a
space to a file name and.... well you know the rest. :)
Anyway, glad to hear it’s fixable.
Best regards,
Allan B.
The LEGO Builder’s Guide
|
Hi Allan,
In light of this article:
http://news.lugnet.com/cad/?n=12556
I now have a dilema on this topic. Add code that makes me compatible with
MLCad but violating the specification, or leave it as is and explain to
people that MLCad does allow blanks in file names, but that violates the
spec.
|
I apologize in advance if this is a stupid solution but what about this:
Is there a way for you to check for spaces in the file name as lpub attempts
to open it? If so, can you then abort the file open process and throw a
pop-up message that says something like:
”You are attempting to open a file that contains spaces in the name. Please
rename the file, without spaces, and try opening the file again.“
At the moment the biggest problem (as I see it) is the lack of error handling
when lpub tries to handle a file with spaces. It returns all kinds of
messages but is the real error listed there? If so, I didn’t see it last
time it happened. It was only after manually looking at my filename that I
realized what had happened. If lpub could simply be a bit more pro-active, I
feel that would be the easiest solution to code and also keep you in line
with the spec.
|
You are right, but the error handling problem is larget than just blanks in file
names. All of this boils down to the wimpy method that LPub uses to parse LDraw
files. If you type in a meta-command “0 LPUB PIL”, rather than “0 LPUB PLI”,
lpub just hapilly ignores it.
If you have an add part line:
1 7 x y z a b c d e f g h i file name with blanks
LPub picks up this part and calls it good:
1 7 x y z a b c d e f g h i file
and ignores the rest. This leads me to my feeling that LPub is user hostile.
I want to improve the parsing to make it give you warnings and such, so you have
a clue. LPub should at least check the syntax of the meta-commands it supports,
including MLCad.
It will give much quicker feedback to users than them sending and waiting for
email.
Expecially with LPub’s plethora of new meta-commands related to placement,
syntax checking and feedback has become much more important. I’m finding it
annoying, so that raises the priority ;^)
I’m off to study lex and maybe yacc.
Thanks for the feedback. It is very welcome.
Kevin
| |
I hope that helps. Again, this is just my own opinion on the matter.
Best regards,
Allan B.
|
|
|
| |
In lugnet.cad, Allan Bedford wrote:
snip
| |
| |
| |
Anyway, glad to hear it’s fixable.
|
|
|
snip
| |
”You are attempting to open a file that contains spaces in the name. Please
rename the file, without spaces, and try opening the file again.“
At the moment the biggest problem (as I see it) is the lack of error handling
when lpub tries to handle a file with spaces.
|
snip
| |
I hope that helps. Again, this is just my own opinion on the matter.
|
Allan,
Your opinions are valued. Thanks. I decided to take the pragmatic way out,
and adjust my parsing to support file names with blanks.
I think that warnings will lead to just as many emails as the current
situation (not a lot, but still.... ;^). The content will change to “MLCad
handles this. Why not LPub?”. Rather than spout statements from the spec, I’d
rather the issue just go away.
So you get blanks in file names! Yay!
Kevin
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
> I decided to take the pragmatic way
> out, and adjust my parsing to support file names with blanks.
>
> I think that warnings will lead to just as many emails as the current
> situation (not a lot, but still.... ;^). The content will change to "MLCad
> handles this. Why not LPub?". Rather than spout statements from the spec,
> I'd rather the issue just go away.
>
> So you get blanks in file names! Yay!
I think you made the right decision, but I have a question. Do the
filenames with embedded spaces have quotes around them, or do they just
use up all the space to the end of the LDRAW type 1 command line? The
reason I ask is because I seem to recall some programs treating extra
stuff after the end of the LDRAW commands as comments. It's briefly
mentioned here.
http://news.lugnet.com/cad/dev/?n=7696
FWIW Ldlite has allowed file names with embedded spaces for years
as long as they're "in quotes". Unfortunately for me, the l3 parser
in ldglite only allows this on the command line, not inside the files.
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > I decided to take the pragmatic way
> > out, and adjust my parsing to support file names with blanks.
> >
> > I think that warnings will lead to just as many emails as the current
> > situation (not a lot, but still.... ;^). The content will change to "MLCad
> > handles this. Why not LPub?". Rather than spout statements from the spec,
> > I'd rather the issue just go away.
> >
> > So you get blanks in file names! Yay!
>
> I think you made the right decision, but I have a question. Do the
> filenames with embedded spaces have quotes around them, or do they just
> use up all the space to the end of the LDRAW type 1 command line? The
> reason I ask is because I seem to recall some programs treating extra
> stuff after the end of the LDRAW commands as comments. It's briefly
> mentioned here.
>
> http://news.lugnet.com/cad/dev/?n=7696
>
> FWIW Ldlite has allowed file names with embedded spaces for years
> as long as they're "in quotes". Unfortunately for me, the l3 parser
> in ldglite only allows this on the command line, not inside the files.
Hi Don,
Using MLCad as a benchmark, the name with blanks is *not* enclosed in quotes.
I use the remainder of the line, sans end of line as the file name.
Alas, my efforts are for naught. L3P quietly ignores the lines that have names
with blanks in them, so I added a check to LPub to flag this as an error and
stop processing.
If the new L3P allows blanks in file names, I can easily remove the check. It
is only in one place in the code. Once removed, the rest of the code is ready
for blanks in file names.
>
> Don
Kevin
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
> If the new L3P allows blanks in file names, I can easily remove the check. It
> is only in one place in the code. Once removed, the rest of the code is ready
> for blanks in file names.
I am currently going through the L3P code and I have now added support for
filenames with spaces, both in linetype 1 and in "0 FILE xxx".
It now uses the rest of the line as the filename.
It also accepts filenames in double-quotes.
/Lars
|
|
| |
Hmmm, I'm not sure if this effort is actually making things more
compatible.
In lugnet.cad, Lars C. Hassing wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > Using MLCad as a benchmark, the name with blanks is *not* enclosed
> > in quotes. I use the remainder of the line, sans end of line as
> > the file name.
I just did a little testing myself. MLCad seems to strip off any
whitespace (tabs and space characters) at the end of the line when
it grabs the filename. Is that what you meant by "sans end of line"?
I'm not sure what happens if you actually manage to create a file
with trailing white space, something like "my file.ldr ".
> > If the new L3P allows blanks in file names, I can easily remove the
> > check. It is only in one place in the code. Once removed, the
> > rest of the code is ready for blanks in file names.
>
> I am currently going through the L3P code and I have now added support
> for filenames with spaces, both in linetype 1 and in "0 FILE xxx".
> It now uses the rest of the line as the filename.
> It also accepts filenames in double-quotes.
Well, that's ok for l3p because it doesn't create any new ldr files.
But MLCad doesn't seem to accept filenames in double quotes. (It
treats the quotes as part of the filename). So what do I do if I
want to write a program that creates new ldraw files. We now have
some programs that accept filenames in double-quotes and treat the
remainder of the line as comments. We have some programs that accept
everything but trailing whitespace as the filename. And we have some
other programs that try to do both. It's still an incompatible mess.
How about an official recommendation from ldraw.org?
FWIW, I prefer the quotes because it's less ambiguous. Consider the
possibility that you might want a meta command where the filename is
in the middle. When you don't use the quotes you don't know where the
filename ends and the meta command picks up. Kevin, I think this may
be a problem with the way you were planning on using the MLCAD group
command.
Anyhow, that's my 2 cents. Have fun,
Don
|
|
| |
In lugnet.cad, Don Heyse wrote:
> Hmmm, I'm not sure if this effort is actually making things more
> compatible.
>
> In lugnet.cad, Lars C. Hassing wrote:
> > In lugnet.cad, Kevin L. Clague wrote:
> > > Using MLCad as a benchmark, the name with blanks is *not* enclosed
> > > in quotes. I use the remainder of the line, sans end of line as
> > > the file name.
>
> I just did a little testing myself. MLCad seems to strip off any
> whitespace (tabs and space characters) at the end of the line when
> it grabs the filename. Is that what you meant by "sans end of line"?
> I'm not sure what happens if you actually manage to create a file
> with trailing white space, something like "my file.ldr ".
I'll do the same.
>
> > > If the new L3P allows blanks in file names, I can easily remove the
> > > check. It is only in one place in the code. Once removed, the
> > > rest of the code is ready for blanks in file names.
> >
> > I am currently going through the L3P code and I have now added support
> > for filenames with spaces, both in linetype 1 and in "0 FILE xxx".
> > It now uses the rest of the line as the filename.
> > It also accepts filenames in double-quotes.
>
> Well, that's ok for l3p because it doesn't create any new ldr files.
> But MLCad doesn't seem to accept filenames in double quotes. (It
> treats the quotes as part of the filename). So what do I do if I
> want to write a program that creates new ldraw files. We now have
> some programs that accept filenames in double-quotes and treat the
> remainder of the line as comments. We have some programs that accept
> everything but trailing whitespace as the filename. And we have some
> other programs that try to do both. It's still an incompatible mess.
> How about an official recommendation from ldraw.org?
>
> FWIW, I prefer the quotes because it's less ambiguous. Consider the
> possibility that you might want a meta command where the filename is
> in the middle. When you don't use the quotes you don't know where the
> filename ends and the meta command picks up. Kevin, I think this may
> be a problem with the way you were planning on using the MLCAD group
> command.
Hi Don,
Nice post.
GROUP commands are defined outside the LDraw spec, but I'd guess that the
naming issues are the same. I just made a minor change to:
0 PLIST BEGIN SUB <file> // depricated
0 LPUB PLI BEGIN SUB <file>
This original version supports sub-model files within the working directory.
I now allow a variant format:
0 LPUB PLI BEGIN SUB <color> <file>
Where you can specify an alternate LDraw part (e.g. retracted pistons instead of
extended pistons.) This part requires a color. I put color first for two
reasons:
1. This is the same order specified in a type 1 text line.
2. It supports blanks in file names without the need for double quotes.
The only strike against double quotes is backward compatibility. Isn't it too
late to make this a requirement?
Kevin
>
> Anyhow, that's my 2 cents. Have fun,
>
> Don
|
|
| |
In lugnet.cad, Kevin L. Clague wrote:
> The only strike against double quotes is backward compatibility.
Well, technically ldlite has been around since well before MLCad,
and it supports the double quotes, but MLCad is more widely used.
So I guess you could make that argument either way.
> Isn't it too late to make this a requirement?
I only asked for a recommendation, not a requirement. But I would
like some sort of decision to move forward with. Also, I suspect
that filenames with embedded spaces are not all that widely used
at this point because of the lack of any kind of standard. If you
look, you'll see everytime someone has mentioned it, the suggestion
was not to use them.
Anyhow, how about if the Ldraw Standards Committee folks have a
round of emails and give some direction. I don't really care all
that much what gets picked, just pick something so we can code it
and expect other programs to read it. Here's some choices.
1. Everything to the end of line except trailing whitespace.
2. Accept filenames with surrounding quotes (and whitespace inside).
3. Both 1 and 2 are acceptable.
4. Same as 3, but prefer 1.
5. Same as 3, but prefer 2.
6. 8.3 filenames only. Curses upon you if you do anything else.
How about it? Enjoy,
Don
|
|
| |
> > Isn't it too late to make this a requirement?
>
> I only asked for a recommendation, not a requirement. But I would
> like some sort of decision to move forward with. Also, I suspect
> that filenames with embedded spaces are not all that widely used
> at this point because of the lack of any kind of standard. If you
> look, you'll see everytime someone has mentioned it, the suggestion
> was not to use them.
I used them until I got a VERY bizarre image of the 10016 tanker in
L3p/PovRay. I promptly switched to using hyphens prefixed by the model id :)
--
Dean Earley, Dee (dean@earlsoft.co.uk)
irc: irc://irc.blitzed.org/
web: http://personal.earlsoft.co.uk
phone: +44 (0)780 8369596
|
|
| |
In lugnet.cad, Don Heyse wrote:
>
> 1. Everything to the end of line except trailing whitespace.
> 2. Accept filenames with surrounding quotes (and whitespace inside).
> 3. Both 1 and 2 are acceptable.
> 4. Same as 3, but prefer 1.
> 5. Same as 3, but prefer 2.
> 6. 8.3 filenames only. Curses upon you if you do anything else.
>
> How about it? Enjoy,
There are other possibilities too, for example:
7. You can exceed 8.3 but don't embed spaces or other sorts of whitespace
8. Limit filenames to only the character set legal for BrickShelf folders
Not meant to be exhaustive, just to get thinking going.
|
|
| |
In lugnet.cad, Don Heyse wrote:
>
> 1. Everything to the end of line except trailing whitespace.
> 2. Accept filenames with surrounding quotes (and whitespace inside).
> 3. Both 1 and 2 are acceptable.
> 4. Same as 3, but prefer 1.
> 5. Same as 3, but prefer 2.
> 6. 8.3 filenames only. Curses upon you if you do anything else.
You could also define an escape character, to accept the character following
(including spaces) as part of the string. However, as the standard allows both /
and \ as directory separators, it would require some character other than \ (a
common choice) to be used. But as long as you use a character that is currently
invalid, it would be backward compatible.
ROSCO
|
|
| |
"Kevin L. Clague" <kevin_clague@yahoo.com> wrote in message
[ ... snipped ... ]
>
> I'm off to study lex and maybe yacc.
[ ... snipped ... ]
I highly recommend the O'Reilly "lex and yacc" book, I found it very helpful
for a project I did at work a number of years ago. The moderated
"comp.compilers" newsgroup is also an excellent resource for lex and yacc
questions. IMHO, if you use lex, you ought to use yacc as well, they really
go hand in hand.
Mike
--
Mike Walsh - mike_walsh at mindspring.com
http://www.ncltc.cc - North Carolina LEGO Train Club
http://www.carolinatrainbuilders.com - Carolina Train Builders
http://www.bricklink.com/store.asp?p=mpw - CTB/Brick Depot
|
|
|
