|
|
 | | Re: 11-16 primitives?
|
| (...) 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 (15 years ago, 25-Sep-09, to lugnet.cad.dat.parts.primitives)
| | | | | Re: 11-16 primitives?
|
| (...) Were any other issues anticipated? (...) 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. (...) (15 years ago, 25-Sep-09, to lugnet.cad.dat.parts.primitives)
| | | | | Re: 11-16 primitives?
|
| (...) 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 (...) (15 years ago, 25-Sep-09, to lugnet.cad.dat.parts.primitives)
| | | | | Re: 11-16 primitives?
|
| (...) 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 (...) (15 years ago, 25-Sep-09, to lugnet.cad.dat.parts.primitives)
| | | | | Re: 11-16 primitives?
|
| (...) 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 (...) (15 years ago, 25-Sep-09, to lugnet.cad.dat.parts.primitives)
|
|
