LDraw.org Discussion Forums
[LSC Request] End of header meta command - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: [LSC Request] End of header meta command (/thread-8081.html)

Pages: 1 2 3 4 5 6 7 8 9


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Roland Melkert - 2014-01-08

I'm not sure we can, like I asked here:

http://forums.ldraw.org/showthread.php?tid=11760&pid=11760#pid11760


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Travis Cobbs - 2014-01-11

I think that, whether or not we can, we should wait for the new election to complete, and let the new LSC take care of it. Tim, would you mind re-asking this after there is a new LSC?


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Chris Dee - 2014-01-11

The fundemental mistake we made was to allow conventional "0 // ..." comments in the header to describe needs work actions:
Header spec Wrote:If the description includes "(Needs Work)", a comment must be added to the file immediately following the official header describing the work that needs to be done.

I'm not sure we have a single proposal to vote on. I see three options implicitly suggested:

1) Define a "needs work" meta-statement and update all such files.
The end-of header algorithm would then be the detection of a "0 // ..." comment or "0 BFC INVERTNEXT" or a non-type 0 line.
Algorithm clarity: medium, Implementation effort: low (154 official files).

2) Define an end-of-header meta statement and apply it to every part that has part content comments or a BFC statement immediately after the header.
The end-of header algorithm would then be the detection of that statement or a non-type 0 line.
Algorithm clarity: medium, Implementation effort: medium (probably > 154 official files).

3) Define an end-of-header meta statement and apply it to every part.
The end-of header algorithm would then be the detection of that statement. This would require the re-issue of the entire library in a Parts Update.
Algorithm clarity: high, Implementation effort: high (7930 part files).


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-11

That was my plan Smile And if people see fit to elect me I'll propose it myself.

Adding a reminder link (for myself) to Chris' post because he has spelled out all the options so clearly.

Tim


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Allen Smith - 2014-01-12

Chris Dee Wrote:The fundemental mistake we made was to allow conventional "0 // ..." comments in the header to describe needs work actions

I think the fundamental mistake was not scoping the header to begin with.

Without a defined end-of-header marker, you must know either:
a) every type 0 meta command that could ever possibly be in the header
b) every type 0 meta command which will ever exist and never be in the header.

The problem is that neither can possibly be known. The header specification may sprout new header metas in the future, or the language may gain additional valid meta-commands which were not anticipated. Problem (b) has already happened, and I'm pretty sure case (a) has been bandied about, if not actually done.


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Arthur Sigg - 2014-01-12

And if the solution comes to

3) Define an end-of-header meta statement and apply it to every part

and if you (all) will find this helpful I would offer to overtake the work of editing following your instructions for the whole library.
In this way you could focus on definining parts and perfecting the system (what I'm not able to do at the moment).

Constitutional principle :: From my point of view every "block" of informations of a specific type in a DAT file should start with an appropiate KEYWORD and end with END or ENDKEYWORD or ENDOFKEYWORD, independent of what will be packed inside, e.g.

0 !HEADER
:
0 !END

or

0 !HEADER
:
0 !ENDHEADER

or

0 !HEADER
:
0 !ENDOFHEADER

BTW Question: Is there a tool which checks a DAT file automatically for "correctness" ?


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Orion Pobursky - 2014-01-12

Arthur Sigg Wrote:BTW Question: Is there a tool which checks a DAT file automatically for "correctness" ?

Yes. Mike Heideman's (increasingly inaccurately named Wink ) DATHeader.


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Michael Heidemann - 2014-01-12

It is named for the purpose of the first code Smile

My idea for DATHeader rised in the moment where a standarized header has been applied to the library.
"Who can remember all those things?" - me not.
So I started to write a tool that eliminates first the "BFC CERTIFY INVERTNEXT" and "ROTATION" lines that will be stored by MLCad. The design idea has been - open a file - save the file and it can be submitted to the pt.
More and more correction could be done over the time and where automatically corrected.

Starting from version 3 also the task for reviewing parts on the PT could be done with DATHeader. But there are still in the background the automatic correction that happens, so in some special tasks it is not easy today to implement only the check of a specific attribute in the file Smile
Therefore - please do not have a look at the code, it is horrorable - but it works Smile


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Orion Pobursky - 2014-01-12

Might I suggest a rename for the next major version to DATValidator, DATVerify, or something more apt?


Re: Call for LSC Vote Re: [LSC Request] End of header meta command - Michael Heidemann - 2014-01-12

From my point of view there will be no major update within the next years. Nearly all aspects are already covert.

Also I do not think that a rename will change anything. If someone is looking for such a tool he will find it - like now Smile