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: [LSC Request] End of header meta command - Chris Dee - 2013-02-07

Allen Smith Wrote:The !HISTORY lines in particular belong in CMS metadata; they do not belong in the source file itself.

The textual content of the !HISTORY lines would belong in a Change Management System if the Parts Tracker used one (which it currently doesn't). However, the
Code:
0 !HISTORY YYYY-MM-DD [PTadmin] Official Update YYYY-RR
lines serve as a surrogate for a version number, so do have value to identify which version of an official part you have installed, and since they are programmatically generated are parse-able.


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-06

I'd like to revive this discussion with a very simple suggestion:

What if we terminate the header either at the first instance of a non-type-0 or at the first appearance of
Code:
0 ////

It's simple, fits existing standards, is easy to read algorithmically, and won't cause problems if it appears elsewhere.

Allen> A "needs work" tag is useful as machine-readable as it allows tools e.g. LDFind, to easily point out that a part could do with some touching up. Thus part authors can get a list of parts that they might improve.

Tim


Re: [LSC Request] End of header meta command - Chris Dee - 2014-01-06

The Parts Tracker seems to cope well with identifying the end of the header section as a non-type-0 line OR a 0 BFC INVERTNEXT.


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-06

Except it often gobbles up comments from within the part data. There are reasons to keep those internal comments away from end-users.

I'm certainly not proposing it as a compulsory solution, merely an optional one (and if DATHeader implements it then it will become a de facto standard).

Tim


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-06

Agree. But not double lines as they are too easy to add by mistake. I've suggested "0 ////" below.

Tim


Re: [LSC Request] End of header meta command - Travis Cobbs - 2014-01-06

I don't have a particular problem with an optional end-of-header token, but I don't feel that your proposed one is acceptable. We've already defined 0 // to be a comment which should never, under any circumstances, be treated as meta-information about the file. Your proposal goes against that.


Re: [LSC Request] End of header meta command - Santeri Piippo - 2014-01-06

Tim Gould Wrote:Allen> A "needs work" tag is useful as machine-readable as it allows tools e.g. LDFind, to easily point out that a part could do with some touching up. Thus part authors can get a list of parts that they might improve.

I could implement support for this in LDForge if it is ratified. I also would find the end-of-header meta command particularly useful. I think "////" sounds a little ambigous and unclear though. I'd prefer "0 !END_OF_HEADER" or something like that.


Re: [LSC Request] End of header meta command - Roland Melkert - 2014-01-06

I agree with Travis '0 //' should be protected.

Having reread the thread I'm ok with the original !ENDOFHEADER suggestion.

It should be optional though, when it's not present the header stops when the first 'mesh' related line is read (1..5, bfc, tex, etc).


Re: [LSC Request] End of header meta command - Steffen - 2014-01-06

no, no, no, I still strongly dislike the introduction of a new end-of-header token.

the existing defined semantics are enough to write some simple code to detect the end of the header: it is simply there where the first non-comment line comes, ie that is a line which is of type 1, 2, 3, 4 or 5, or a 0 BFC or 0 !TEXMAP or 0 !COLOUR

let me also question for what _purpose_ such a token would be useful:
1. what is so bad about LDFind if it indexes the whole file instead of just the first bunch of lines? don't you want to find _all_ occurrences of a word in a file?
2. if we're talking about using a revision control system for our parts like git, hg or Perforce, which I strongly suggest, then the _whole_ file will go into it, not just the header. That way our files would really get a lifecycle history of their full contents. We're talking about simple
fulltext files here still, which can easily be stored in tools like that, allowing easy diffing etc like for programming language source code files.

And yes, agreeing to the said things above: using anything that starts with 0 // must not be done under all circumstances,
because it breaks the rule that everything after 0 // is a totally free formatted,
no machine-readable-semantics-carrying human-readable comment.
the only degree of freedom we have here is choosing something that starts with 0 !...


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-06

Which of these things could you not do with an optional end of header token?