| |
What would be the suggested name for an 11-16 primitive for a cylinder or edge
line since 11-16 contains 5 letters and tacking on edge or cyli at the end would
give a 9 letter name?
|
|
| |
In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> What would be the suggested name for an 11-16 primitive for a cylinder or edge
> line since 11-16 contains 5 letters and tacking on edge or cyli at the end would
> give a 9 letter name?
I would suggest avoiding the problem completely by using a 2-4edge +
3-16edge...
In other instances the name was shortened:
3-16cone19 --> 3-16co19
11-48ring19 --> 11-48r19
Philo
|
|
| |
In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> What would be the suggested name for an 11-16 primitive for a cylinder or edge
> line since 11-16 contains 5 letters and tacking on edge or cyli at the end would
> give a 9 letter name?
I ditto Phillippe's primary suggestion: use multiple files. It's good for
multiple reasons.
However, the current standards allow at least 25 characters in the filename, so
is there a reason to worry about a 9 character primitive name?
Steve
|
|
| |
Hi Steve,
> However, the current standards allow at least 25 characters in the filename, so
> is there a reason to worry about a 9 character primitive name?
One reason: the Parts Tracker still doesn't like >8 names :(
Philo
|
|
| |
In lugnet.cad.dat.parts.primitives, Philippe Hurbain wrote:
> In lugnet.cad.dat.parts.primitives, Mark Kennedy wrote:
> > What would be the suggested name for an 11-16 primitive for a cylinder or edge
> > line since 11-16 contains 5 letters and tacking on edge or cyli at the end would
> > give a 9 letter name?
>
> I would suggest avoiding the problem completely by using a 2-4edge +
> 3-16edge...
>
> In other instances the name was shortened:
> 3-16cone19 --> 3-16co19
> 11-48ring19 --> 11-48r19
These truncated filenames never went past the LSC, and as such should probably
be held. I personally feel that they are inappropriate, but whether or not I
think they are appropriate, I believe that it's the LSC's job to determine
that.
--Travis
|
|
| |
> These truncated filenames never went past the LSC, and as such should probably
> be held. I personally feel that they are inappropriate, but whether or not I
> think they are appropriate, I believe that it's the LSC's job to determine
> that.
Well... imho this should not be an issue at all - if the parts tracker was
updated!
Philo
|
|
| |
In lugnet.cad.dat.parts.primitives, Philippe Hurbain wrote:
> Hi Steve,
>
> > However, the current standards allow at least 25 characters in the filename, so
> > is there a reason to worry about a 9 character primitive name?
>
> One reason: the Parts Tracker still doesn't like >8 names :(
>
> Philo
This is the status quo now for many months. What action has been taken to solve
that problem?
To me it seems only to be a little adjustment to some lines of code (but maybe I
am wrong).
So my question would be: where is the bottleneck that this is still not solved?
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts.primitives, Michael Heidemann wrote:
> So my question would be: where is the bottleneck that this is still not solved?
Parts Tracker-wise (if I remember right, and if nothing's been changed), there's
only one script which needs to be modified to accept 21.3 files instead of 8.3
files.
Organizationally, I dunno if there is actually a hold-up. The specifications
state that the parts library allows file names up to 25 characters long.
One real problem is PARTS.LST. This file is defined in a fixed-width form,
where the part numbers are only allowed 8 characters. I believe some programs
(such as MLCAD?) depend on PARTS.LST. So some backwards-compatible solution
would be needed to shoe-horn 21.3 filenames into the existing PARTS.LST format.
So maybe one of the following:
1) Allow longer filenames for primitives and subparts, but keep parts on the 8.3
standard. This allows longer filenames where they are more needed, and keeps
the PARTS.LST format working. An awkward solution, but the easiest to
implement.
2) Forget backwards compatibility, change the format of PARTS.LST.
3) Create another parts list file in an expanded format (maybe tab-delimited?).
For the existing PARTS.LST, leave out parts with long files names. Truncating
their name to 8 characters is a possibility, but that seems somewhat useless.
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> One real problem is PARTS.LST. This file is defined in a fixed-width form,
> where the part numbers are only allowed 8 characters. I believe some programs
> (such as MLCAD?) depend on PARTS.LST. So some backwards-compatible solution
> would be needed to shoe-horn 21.3 filenames into the existing PARTS.LST format.
When the LSC updated the spec to allow 21.3 filenames, I don't think any of us
were aware that this would create a problem for PARTS.LST. However, looking at
the file, there's a chance that MLCAD will work perfectly well with longer
filenames inside it. The part name text for those lines would start out in the
wrong place, but depending on how it is parsed, that may not be an issue. It
should be straightforward to test.
--Travis
|
|
| |
In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> When the LSC updated the spec to allow 21.3 filenames, I don't think any of us were aware that this would create a problem for PARTS.LST.
Were any other issues anticipated?
> However, looking at the file, there's a chance that MLCAD will work
> perfectly well with longer filenames inside it.
I did a short test of MLCAD with a modified PARTS.LST. The results were mixed -
MLCAD seems OK using an altered-format PARTS.LST file, but re-generating
PARTS.LST from MLCAD results in an invalid file.
For the test, I copied 55706.dat to 55706longfile.dat, and changed the first
line of my PARTS.LST to:
55706longfile.dat Animal Bat Wing 9 x 9 with Axle
(trailing space chars trimmed for this post, but left in the test file)
MLCAD was perfectly happy to use this modified file, and seemed to work just
fine. I examined the parts tree control, dragged the part into the edit panel,
etc.
However, MLCAD's "Scan Part" command did not work as well. It generated a new
PARTS.LST, writing the new line as:
55706longfile.Animal Bat Wing 9 x 9 with Axle
When I exited and re-entered MLCAD, it seemed to ignore this entry -- the part
did not appear in the parts tree.
I also tried running mklist -- it crashed, hard, on the long file name. :(
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
>
> > When the LSC updated the spec to allow 21.3 filenames, I don't think any of us were aware that this would create a problem for PARTS.LST.
>
> Were any other issues anticipated?
>
> > However, looking at the file, there's a chance that MLCAD will work
> > perfectly well with longer filenames inside it.
>
> I did a short test of MLCAD with a modified PARTS.LST. The results were mixed -
> MLCAD seems OK using an altered-format PARTS.LST file, but re-generating
> PARTS.LST from MLCAD results in an invalid file.
>
> For the test, I copied 55706.dat to 55706longfile.dat, and changed the first
> line of my PARTS.LST to:
>
> 55706longfile.dat Animal Bat Wing 9 x 9 with Axle
>
> (trailing space chars trimmed for this post, but left in the test file)
>
> MLCAD was perfectly happy to use this modified file, and seemed to work just
> fine. I examined the parts tree control, dragged the part into the edit panel,
> etc.
>
> However, MLCAD's "Scan Part" command did not work as well. It generated a new
> PARTS.LST, writing the new line as:
>
> 55706longfile.Animal Bat Wing 9 x 9 with Axle
>
> When I exited and re-entered MLCAD, it seemed to ignore this entry -- the part
> did not appear in the parts tree.
>
> I also tried running mklist -- it crashed, hard, on the long file name. :(
>
> Steve
If I understand that, this would mean that we could use a new mklist tool and we
can start using that long filenames.
The possibility to use MLCad for generating PARTS.LST will be away, but this
only a little cut.
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts.primitives, Michael Heidemann wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> >
> > > When the LSC updated the spec to allow 21.3 filenames, I don't think any of us were aware that this would create a problem for PARTS.LST.
> >
> > Were any other issues anticipated?
> >
> > > However, looking at the file, there's a chance that MLCAD will work
> > > perfectly well with longer filenames inside it.
> >
> > I did a short test of MLCAD with a modified PARTS.LST. The results were mixed -
> > MLCAD seems OK using an altered-format PARTS.LST file, but re-generating
> > PARTS.LST from MLCAD results in an invalid file.
> >
> > For the test, I copied 55706.dat to 55706longfile.dat, and changed the first
> > line of my PARTS.LST to:
> >
> > 55706longfile.dat Animal Bat Wing 9 x 9 with Axle
> >
> > (trailing space chars trimmed for this post, but left in the test file)
> >
> > MLCAD was perfectly happy to use this modified file, and seemed to work just
> > fine. I examined the parts tree control, dragged the part into the edit panel,
> > etc.
> >
> > However, MLCAD's "Scan Part" command did not work as well. It generated a new
> > PARTS.LST, writing the new line as:
> >
> > 55706longfile.Animal Bat Wing 9 x 9 with Axle
> >
> > When I exited and re-entered MLCAD, it seemed to ignore this entry -- the part
> > did not appear in the parts tree.
> >
> > I also tried running mklist -- it crashed, hard, on the long file name. :(
> >
> > Steve
>
> If I understand that, this would mean that we could use a new mklist tool and we
> can start using that long filenames.
> The possibility to use MLCad for generating PARTS.LST will be away, but this
> only a little cut.
I could update the mklist sources to work handle filenames with 25 chars
I was going to add a quietmode commandline option this weekend anyhow.
Should I allow 25 chars as the default, and perhaps include an optional
command line arg to force/truncate it to 12 chars for backwards compatibility
with old programs?
Don
option to force/
Don
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> I could update the mklist sources to work handle filenames with 25 chars
That would be good, I think.
> I was going to add a quietmode commandline option this weekend anyhow.
Can you have two levels? Level One that still shows the warnings, but doesn't
stop, and Level Two suppresses all warnings.
> Should I allow 25 chars as the default, and perhaps include an optional
> command line arg to force/truncate it to 12 chars for backwards compatibility
> with old programs?
I'd keep the current line-format for all parts conforming to the 8.3 format, but
for longer names, print the entire filename, a space, and the description. Like
this:
3001.dat Brick 2 x 4
3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
3002.dat Brick 2 x 3
A backwards-compatibility switch is good -- maybe with option to truncate (or
not) the description to fit 80 bytes per line?
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> A backwards-compatibility switch is good -- maybe with option to truncate (or
> not) the description to fit 80 bytes per line?
If it's running in Windows, I think a backwards-compatible switch should use the
Win32 API to get the short filename (with the ~1 at the end, usually, determined
using PathGetShortPath) and use that in place of the long filename.
--Travis
|
|
| |
In lugnet.cad.dat.parts.primitives, Travis Cobbs wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > A backwards-compatibility switch is good -- maybe with option to truncate (or
> > not) the description to fit 80 bytes per line?
>
> If it's running in Windows, I think a backwards-compatible switch should use the
> Win32 API to get the short filename (with the ~1 at the end, usually, determined
> using PathGetShortPath) and use that in place of the long filename.
>
> --Travis
Sounds easy, but I think nobody can read that short filenames that would appear
in the MLCad list!?
cu
mikeheide
|
|
| |
In lugnet.cad.dat.parts.primitives, Michael Heidemann wrote:
> Sounds easy, but I think nobody can read that short filenames that would appear
> in the MLCad list!?
For MLCAD it doesn't matter. Steve said that MLCAD worked fine with long
filenames inside parts.lst. The only reason to put the short filename in is for
other programs that might have problems with the long filename. And as long as
mklist is run on the computer that is going to use the parts.lst file,
PathGetShortFilename will give the correct short filename for the given long
filename. The parts.lst file is then specific to that particular computer, but
that doesn't seem to be a problem if someone is running mklist themselves
anyway.
--Travis
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
>
> > I could update the mklist sources to work handle filenames with 25 chars
>
> That would be good, I think.
>
> > I was going to add a quietmode commandline option this weekend anyhow.
>
> Can you have two levels? Level One that still shows the warnings, but
> doesn't stop, and Level Two suppresses all warnings.
Yeah, I was actually planning a -f to force it to finish and -q for quiet.
> > Should I allow 25 chars as the default, and perhaps include an optional
> > command line arg to force/truncate it to 12 chars for backwards
> > compatibility with old programs?
For now I've added a -8 to make it use the 8.3 format. As per Travis'
suggestion it converts to the canonical short form under Windows. The
function uppercases the filenames, which should work ok for DOS/Windows,
but looks kinda ugly.
> I'd keep the current line-format for all parts conforming to the 8.3
> format, but for longer names, print the entire filename, a space, and
> the description. Like this:
>
> 3001.dat Brick 2 x 4
> 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> 3002.dat Brick 2 x 3
>
> A backwards-compatibility switch is good -- maybe with option to
> truncate (or not) the description to fit 80 bytes per line?
Ok, I'd like to know what you're thinking here. The specs say 25 chars
in the filenames, and I don't really like a ragged left edge on the
descriptions, both visually and because it complicates the sorting code.
So tell me why someone might want that, especially as more long
filenames get released. It's gonna look awful.
Right now, mklist always truncates the description to 64 chars, which
fits on an 80 char line with the 8.3 filenames. I take it you'd like to
(optionally?) make it instead truncate the filename+space(s)+description
to 80 chars when using long filenames. Is there some program that this
will help, or is this so it still fits in an 80 char terminal window?
Don
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > 3001.dat Brick 2 x 4
> > 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> > 3002.dat Brick 2 x 3
> >
> > A backwards-compatibility switch is good -- maybe with option to
> > truncate (or not) the description to fit 80 bytes per line?
>
> Ok, I'd like to know what you're thinking here. The specs say 25 chars
> in the filenames, and I don't really like a ragged left edge on the
> descriptions, both visually and because it complicates the sorting code.
> So tell me why someone might want that, especially as more long
> filenames get released. It's gonna look awful.
My thinking is the 'ragged' format has the least impact - if there are no long
part nambers, then the output PARTS.LST would exactly match the classic format,
without the user having to know anything about long/short part nambers.
Of course, if further MLCAD tests shows that it works with a fixed-format 25
char filename column, then there's less reason to go with the ragged format.
> Right now, mklist always truncates the description to 64 chars, which
> fits on an 80 char line with the 8.3 filenames. I take it you'd like to
> (optionally?) make it instead truncate the filename+space(s)+description
> to 80 chars when using long filenames. Is there some program that this
> will help, or is this so it still fits in an 80 char terminal window?
I was thinking that some old programs depend on the rigid 80 byte record format,
but most programs are line-delimited, and don't care about the exact line
length. Over time, we've seen an increased need for longer, more detailed part
descriptions. In some cases, the 64 char description limit is already an issue
for part naming. For example, a number of the 6100 patterned baseplates break
the 'with ... Pattern' naming convention.
So it would be nice to be able to produce a PARTS.LST with full descriptions if
rigid conformance to 80-byte records is not needed.
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > I'd keep the current line-format for all parts conforming to the 8.3
> > format, but for longer names, print the entire filename, a space, and
> > the description. Like this:
> >
> > 3001.dat Brick 2 x 4
> > 3001c01p01.dat Brick 2 x 4 Some Variation with Pattern
> > 3002.dat Brick 2 x 3
> >
> > A backwards-compatibility switch is good -- maybe with option to
> > truncate (or not) the description to fit 80 bytes per line?
I'm assuming the 80 char lines is what you're aiming for here, so based
on the 64 char limit on descriptions I started the descriptions on the
16th character of the line. That gives room for a 15 character name
and a single space before the description. Anything longer and you'll
get the ragged look and a truncated description. But hey, if we keep
most of the names to 11.3 and under it looks pretty nice:
6028.dat Animal Dragon Tail
6133.dat Animal Dragon Wing
6133longfilename.dat Animal Dragon Wing Long version
4493c00.dat Animal Horse (Complete)
Here's what -8 does to the long filename. Is that ok?
C:\LDraw>diff -b parts.lst parts.long
11c11
< 6133LO~1.DAT Animal Dragon Wing Long version
---
> 6133longfilename.dat Animal Dragon Wing Long version
I put a beta executable here if anyone wants to shake the bugs out.
http://ldglite.sf.net/mklist1_6b1.zip
Don
|
|
| |
Sorry to follow-up my own post, but I did a quick test on MLCAD.
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> Of course, if further MLCAD tests shows that it works with a fixed-format 25
> char filename column, then there's less reason to go with the ragged format.
I had a DUH! moment after posting the previous message. If MLCAD can use a
ragged format file, of course it can use a fixed-25 format file. DOH.
> So it would be nice to be able to produce a PARTS.LST with full descriptions if
> rigid conformance to 80-byte records is not needed.
I prepared a PARTS.LST file with data lines longer and shorter than 80 bytes,
and MLCAD seemed perfectly happy to use the data as presented. In particular,
it could handle longer descriptions without truncating them (I didn't test to
see if it had some longer limit).
Steve
|
|
| |
In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> Sorry to follow-up my own post, but I did a quick test on MLCAD.
>
> In lugnet.cad.dat.parts.primitives, Steve Bliss wrote:
> > Of course, if further MLCAD tests shows that it works with a fixed-format 25
> > char filename column, then there's less reason to go with the ragged format.
>
> I had a DUH! moment after posting the previous message. If MLCAD can use a
> ragged format file, of course it can use a fixed-25 format file. DOH.
>
> > So it would be nice to be able to produce a PARTS.LST with full descriptions if
> > rigid conformance to 80-byte records is not needed.
>
> I prepared a PARTS.LST file with data lines longer and shorter than 80
> bytes, and MLCAD seemed perfectly happy to use the data as presented.
> In particular, it could handle longer descriptions without truncating
> them (I didn't test to see if it had some longer limit).
In the mklist beta I posted there's an undocumented -r switch to turn
off the ragged edges and make room for 25 char filenames. There's also
an undocumented -t to twiddle with the 78 vs 80 character line formats.
But there's nothing yet for allowing descriptions longer than 64 chars.
We can add lots of options, but we also need to decide on the default
output format. And I suspect that should probably target whatever works
best for MLCAD users. Any newer programs currently in development can
create their own mklist type functions.
The -8 setting should produce 8.3 filenames and 80 character lines
(including the <CR><LF>) compatible with any older software out there.
Don
|
|
| |
In lugnet.cad.dat.parts.primitives, Don Heyse wrote:
> I'm assuming the 80 char lines is what you're aiming for here, so based
> on the 64 char limit on descriptions I started the descriptions on the
> 16th character of the line. That gives room for a 15 character name
> and a single space before the description. Anything longer and you'll
> get the ragged look and a truncated description. But hey, if we keep
> most of the names to 11.3 and under it looks pretty nice:
>
> 6028.dat Animal Dragon Tail
> 6133.dat Animal Dragon Wing
> 6133longfilename.dat Animal Dragon Wing Long version
> 4493c00.dat Animal Horse (Complete)
>
> Here's what -8 does to the long filename. Is that ok?
>
> C:\LDraw>diff -b parts.lst parts.long
> 11c11
> < 6133LO~1.DAT Animal Dragon Wing Long version
> ---
> > 6133longfilename.dat Animal Dragon Wing Long version
>
> I put a beta executable here if anyone wants to shake the bugs out.
>
> http://ldglite.sf.net/mklist1_6b1.zip
Hey--that's exactly what I was looking for. Thanks!
Dave!
|
|
|
