LDraw.org Discussion Forums
›
Models and Parts
›
Parts Authoring
[LSC Request] End of header meta command
[LSC Request] End of header meta command
[LSC Request] End of header meta command
Hi Tim,
I just read the header spec and it's not what I expected.
If I read the spec right,
1. if the part is a simple color alias, then by design the header should include the single sub-part reference that applies the specific color to the sub-part.
2. if the part needs work, the first file comment should describe what needs doing but
3. if the part does not need work, then the first comment is "implementation comment", describing what's going on in the file.
If we were to add a new meta to delineate the end of the header, how would case 1 work?
(A reasonable answer might be that the sub-part directive for color specification really should not be considered part of the header, I suppose.)
Cheers
Ben
I just read the header spec and it's not what I expected.
If I read the spec right,
1. if the part is a simple color alias, then by design the header should include the single sub-part reference that applies the specific color to the sub-part.
2. if the part needs work, the first file comment should describe what needs doing but
3. if the part does not need work, then the first comment is "implementation comment", describing what's going on in the file.
If we were to add a new meta to delineate the end of the header, how would case 1 work?
(A reasonable answer might be that the sub-part directive for color specification really should not be considered part of the header, I suppose.)
Cheers
Ben
As it happens, I'm pretty sure an algorithm can be made that can exactly determine the extent of the header. That's because the Official Library Header Specification specifies a list of the only meta-commands that are allowed to be in the header. Unfortunately, implementing such an algorithm would be quite tedious, and the list of allowed meta-commands changes over time, so the algorithm would have to be updated every time a new meta-command was added to the list. So I don't think it's reasonble to expect software authors to implement such an algorithm.
You already answered yourself 
and you are right.
This whole think is not worth talking about in my eyes because it only effects the library parts.
I had to deal with this in DATHeader and also in MPDCenter.
DATHeader is, AFAIK, the first application that dealed with the header. All other application needed to just ignore this, as there is only one information of interest !LDRAW_TYPE for displaying.
Let us keep things simple. If a user build a new part he might use the official header, but I doubt.
So you can't relay on such a tag in your code if you divide the header and the body.
For MPDCenter I also had to add some more meta commands to be knows as body portions to let the header editor work there as well. Therefore i added there a special file called BODY_META_COMMANDS that is editable by the user.
So you end up for sure in detecting all those possibilities and now we add one more. Does not make sense to me as the only effect is that the first real body documentation _might_ be visible to the user.
and you are right.This whole think is not worth talking about in my eyes because it only effects the library parts.
I had to deal with this in DATHeader and also in MPDCenter.
DATHeader is, AFAIK, the first application that dealed with the header. All other application needed to just ignore this, as there is only one information of interest !LDRAW_TYPE for displaying.
Let us keep things simple. If a user build a new part he might use the official header, but I doubt.
So you can't relay on such a tag in your code if you divide the header and the body.
For MPDCenter I also had to add some more meta commands to be knows as body portions to let the header editor work there as well. Therefore i added there a special file called BODY_META_COMMANDS that is editable by the user.
So you end up for sure in detecting all those possibilities and now we add one more. Does not make sense to me as the only effect is that the first real body documentation _might_ be visible to the user.
No, it proves that making the statement optional doesn't fix the problem.
It's currently impossible to write an algorithm which BOTH reliably detects the header AND is future-proof with no additional maintenance. Considering how susceptible LDraw is to the incursion-of-real-life-responsibilities problem (myself being the latest victim-in-point), future-proof algorithms are good things.
Allen
It's currently impossible to write an algorithm which BOTH reliably detects the header AND is future-proof with no additional maintenance. Considering how susceptible LDraw is to the incursion-of-real-life-responsibilities problem (myself being the latest victim-in-point), future-proof algorithms are good things.
Allen
I suspect all real arguments have been played out here. Certainly I can't add anything. And there is enough support (I count at least four yeas) from the community to warrant the LSC getting involved.
I formally request that the LDraw Standards Commitee vote on this proposal. I will, of course, abide by whatever decision it makes and never speak of it again
Tim
I formally request that the LDraw Standards Commitee vote on this proposal. I will, of course, abide by whatever decision it makes and never speak of it again
Tim
Steffen Wrote:Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.
If the new syntax is optional, and you anyway have to implement fallback code, then you could use the fallback code from the beginning. That proves the redundancy of the new syntax.
Hi Steffen,
Except: the old fallback code will produce _incorrect output_ some of the time (because the fallback code cannot distinguish between header comments like "this is what needs to be fixed" and implementation comments like "first outer contour of left flange").
So if a programmer cares about correctness of parsing, then the fallback code does not render the new syntax (and new code) redundant because the new code+new syntax fixes an otherwise unfixable bug.
So...I think you can make the argument, if you wish, that the cure is worse than the disease, that this is a small bug and a meta is a big deal, and that the value trade-off is not good.
But I do not think you can make the argument that the syntax does not solve a currently unsolvable problem.
@Allen: I think that not only can you not right a future-proof algorithm, but you can't even parse the headers correctly now. But the point about future-proofing is important too - even if we were to fix this bug by "fixing" the spec (e.g. just saying no comments in the headers, ever) the introduction of new directives and new metas would break parsing.
@Steffen, one last thought: any time new syntax is optional and tries to make things easier, I agree that it does temporarily make things harder for programmers (by putting a second case into the spec).
But such "let's try again" format changes also start a clock; if we hope to ever move to cleaner formatting that allows for simple parsing, better to get the extension sorted out sooner. Then later, the part library can be searched for non-conforming parts, they can be batch-updated, and eventually the optional can be dropped by a new extension. That's a long, slow process, but it's even slower if we defer introducing a syntax fix.
(That's not an argument that this is really important either, of course.)
Cheers
Ben
I agree Ben, but I do understand Steffen's point though.
But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.
But that might raise the need to for a new 'needs work' comment like meta (it's been proposed before if I'm not mistaken).
But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.
But that might raise the need to for a new 'needs work' comment like meta (it's been proposed before if I'm not mistaken).
Roland Melkert Wrote:But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.
Hi Roland,
Right - and that's where Allen's point comes in. If a client needs a complete and inclusive list of header METAs to determine "what is the header", then we break header parsing for all existing clients every time we add a new header meta. :-(
I think the LDraw file format is one where there are:
- lots of clients and
- many clients care about only some of the information and
- the format is going to grow new features (e.g. BFC, TEXMAP, etc.) over time.
So any time parsing the file requires knowing the latest format in its entirety, that's problematic because by definition old apps don't have that info. :-(
cheers
Ben
Roland Melkert Wrote:But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.I like that suggestion better, and it would be much easier to implement formally by only updating those files that have "header comments", rather than updating _every_ file to add an end-of-header meta-statement.
But that might raise the need to for a new 'needs work' comment like meta (it's been proposed before if I'm not mistaken).
Chris (LDraw Parts Library Admin)
The fundemental mistake we made was to allow conventional "0 // ..." comments in the header to describe needs work actions:
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).
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).
Chris (LDraw Parts Library Admin)
That was my plan 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
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
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.
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" ?
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" ?
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
) DATHeader.
It is named for the purpose of the first code
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
Therefore - please do not have a look at the code, it is horrorable - but it works
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
Therefore - please do not have a look at the code, it is horrorable - but it works
Thanks for explaining. Any specifications of the current performance of DATHeader and a summary of what's missing/planned ?
I never stick my nose in other people's code, except the programmer asks me. And not in case of "horrible" written code, except a tool is "horrible sophisticated" and well documented so I could expect a learning gradient for myself :-)
I never stick my nose in other people's code, except the programmer asks me. And not in case of "horrible" written code, except a tool is "horrible sophisticated" and well documented so I could expect a learning gradient for myself :-)
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Arthur Sigg Wrote:Thanks for explaining. Any specifications of the current performance of DATHeader and a summary of what's missing/planned ?
Hmmm....
summary of what's missing/planned
Hmmm...
missing - nothing I hope
planned - currently nothing as exactly that is missing
I guess with performance you are talking about the things that DATHeader cares about?
Below the list of flags that I work with and that are hopefully self explaining.
Code:
Public Enum LDraw_ErrorCode
PovCodeFound = 1
WRITEfound = 2
BFCCERTIFYINVERTNEXTfound = 3
ROTATIONfound = 4
COLORfound = 5
CommentsNotCorrect = 6
NotOnlyLDconfigColors = 7
MatrixAllZero = 8
IdenticalVertices = 9
ColinearVertices = 10
BadVertexSequenze = 11
ConcaveQuads = 12
NonCoplanarQuads = 13
ColorWrongForLinetype = 14
LoopInReference = 15
DoubleLinesfound = 16
ColorForSticker = 17
PartDescriptionLength = 18
PartDescriptionLeadingSpaces = 19
KeywordsLength = 20
KeywordsCorrect = 21
FiletitleMatchesFilename = 22
AuthorRealname = 23
AuthorUsername = 24
BFCset = 25
LicenseSet = 26
PartTypeSet = 27
BFC_CCW_at_Primitive = 28
Keywords_at_Primitives = 29
PartDescriptionWithTab = 30
HelpLength = 31
NewNotUsed = 32
NeedWorkComment = 33
Category = 34
Category_at_Primitives = 35
Primitive48FilenameStartwith48 = 36
PrimitivePartDescriptionStartWithout_orTilde = 37
PartFilenameStartwithout48orS = 38
SubpartFilenameStartWithS = 39
SubpartDescriptionStartWithTilde = 40
SubpartDescriptionStartWithout_ = 41
PartDescriptionStartWithout_ = 42
ShortCutPartDescriptionStartWith_ = 43
ShortCutFilenameContains_d_or_c = 44
NameExtensionIsDAT = 45
NoSpecialCharacterInDescription = 46
LineEndWithCRLF = 47
HistoryEntryAuthorBracket = 48
PrimitiveIsScaled = 49
PrimitiveIsScaledY = 50
BFCINVERTNEXTfollowedbylinetype1 = 51
CorrectRGBvalue = 52
NoMoveToReferenceUsed = 53
NoBFCCERTIFIEDCWorCCWfound = 54
KeywordsUnique = 55
MinifigAccessoryNotFound = 56
FigureAccessoryNotFound = 57
NotNeededInvertNextUsed = 58
TJunctionDetected = 59
SquareBracketsAroundUsername = 60
AliasPartDescriptionStartWithSame = 61
PhysicalColorMentionedInDescription = 62
PhysicalColorPartOnlyLinetype1Used = 63
PhysicalColorPartCorrectColorsUsed = 64
AliasPartOnlyLinetype1Used = 65
AliasPartOnlyOneLinetype1 = 66
AliasPartOnlyColor16Used = 67
AliasPartAliasMentionedInComments = 68
AliasPartAliasNumberInComment = 69
OriginNOTInBoundingBox = 70
AmericanEnglishWords = 71
EmptyLinesAtTheEnd = 72
End EnumAnd here the messages you will see if all is correct:
Code:
Public Sub InitialiseOKMessages()
ReDim FileResultOKMessages([Enum].GetValues(GetType(LDraw_ErrorCode)).Length)
FileResultOKMessages(LDraw_ErrorCode.PovCodeFound) = "OK" & XMPD.MSVB.Tab & "Embedded POV Code not found."
FileResultOKMessages(LDraw_ErrorCode.WRITEfound) = "OK" & vbTab & "'0 WRITE' not found."
FileResultOKMessages(LDraw_ErrorCode.BFCCERTIFYINVERTNEXTfound) = "OK" & vbTab & "'0 BFC CERTIFY INVERTNEXT' not found."
FileResultOKMessages(LDraw_ErrorCode.ROTATIONfound) = "OK" & vbTab & "'0 ROTATION' not found."
FileResultOKMessages(LDraw_ErrorCode.COLORfound) = "OK" & vbTab & "'0 COLOR' not found."
FileResultOKMessages(LDraw_ErrorCode.CommentsNotCorrect) = "OK" & vbTab & "Correct use of '0 //' for comments."
FileResultOKMessages(LDraw_ErrorCode.NotOnlyLDconfigColors) = "OK" & vbTab & "All used colors in LDConfig.ldr."
FileResultOKMessages(LDraw_ErrorCode.MatrixAllZero) = "OK" & vbTab & "Matrix all zero not found."
FileResultOKMessages(LDraw_ErrorCode.IdenticalVertices) = "OK" & vbTab & "Identical vertices not found."
FileResultOKMessages(LDraw_ErrorCode.ColinearVertices) = "OK" & vbTab & "Colinear vertices not found."
FileResultOKMessages(LDraw_ErrorCode.BadVertexSequenze) = "OK" & vbTab & "Bad Vertex Sequence not found."
FileResultOKMessages(LDraw_ErrorCode.ConcaveQuads) = "OK" & vbTab & "Concave quads not found."
FileResultOKMessages(LDraw_ErrorCode.NonCoplanarQuads) = "OK" & vbTab & "Coplanarity."
FileResultOKMessages(LDraw_ErrorCode.ColorWrongForLinetype) = "OK" & vbTab & "Correct color for linetype."
FileResultOKMessages(LDraw_ErrorCode.LoopInReference) = "OK" & vbTab & "Loop in reference not found."
FileResultOKMessages(LDraw_ErrorCode.DoubleLinesfound) = "OK" & vbTab & "Double lines not found."
FileResultOKMessages(LDraw_ErrorCode.ColorForSticker) = "OK" & vbTab & "Correct colors for sticker used."
FileResultOKMessages(LDraw_ErrorCode.PartDescriptionLength) = "OK" & vbTab & "Length of part description."
FileResultOKMessages(LDraw_ErrorCode.PartDescriptionLeadingSpaces) = "OK" & vbTab & "Leading spaces in part description."
FileResultOKMessages(LDraw_ErrorCode.KeywordsLength) = "OK" & vbTab & "Keywords entry length."
FileResultOKMessages(LDraw_ErrorCode.KeywordsCorrect) = "OK" & vbTab & "None of the keyword are used in in part description."
FileResultOKMessages(LDraw_ErrorCode.FiletitleMatchesFilename) = "OK" & vbTab & "Filename matches filetitle."
FileResultOKMessages(LDraw_ErrorCode.AuthorRealname) = "OK" & vbTab & "Author real name is set."
FileResultOKMessages(LDraw_ErrorCode.AuthorUsername) = "OK" & vbTab & "Author user name is set."
FileResultOKMessages(LDraw_ErrorCode.BFCset) = "OK" & vbTab & "BFC is set."
FileResultOKMessages(LDraw_ErrorCode.LicenseSet) = "OK" & vbTab & "License is set."
FileResultOKMessages(LDraw_ErrorCode.PartTypeSet) = "OK" & vbTab & "Part type is set."
FileResultOKMessages(LDraw_ErrorCode.BFC_CCW_at_Primitive) = "OK" & vbTab & "Winding for part type."
FileResultOKMessages(LDraw_ErrorCode.Keywords_at_Primitives) = "OK" & vbTab & "Use of keyword for part type."
FileResultOKMessages(LDraw_ErrorCode.PartDescriptionWithTab) = "OK" & vbTab & "Part description without Tab character."
FileResultOKMessages(LDraw_ErrorCode.HelpLength) = "OK" & vbTab & "HELP entry length."
FileResultOKMessages(LDraw_ErrorCode.NewNotUsed) = "OK" & vbTab & "Word 'new' or 'old' not used in part description."
FileResultOKMessages(LDraw_ErrorCode.NeedWorkComment) = "OK" & vbTab & "Use of (Needs work)."
FileResultOKMessages(LDraw_ErrorCode.Category) = "OK" & vbTab & "Entry for category."
FileResultOKMessages(LDraw_ErrorCode.Category_at_Primitives) = "OK" & vbTab & "Category is not set."
FileResultOKMessages(LDraw_ErrorCode.Primitive48FilenameStartwith48) = "OK" & vbTab & "High-res primitive has to start with '48\'."
FileResultOKMessages(LDraw_ErrorCode.PrimitivePartDescriptionStartWithout_orTilde) = "OK" & vbTab & "Description for primitives should not start with '_' or '~' or '='."
FileResultOKMessages(LDraw_ErrorCode.PartFilenameStartwithout48orS) = "OK" & vbTab & "Filename for parts, shortcuts and primitives should not start with '48\' or 's\' or '8\'."
FileResultOKMessages(LDraw_ErrorCode.SubpartFilenameStartWithS) = "OK" & vbTab & "Filename for subparts has to start with 's\'."
FileResultOKMessages(LDraw_ErrorCode.SubpartDescriptionStartWithTilde) = "OK" & vbTab & "Description for subparts has to start with '~'."
FileResultOKMessages(LDraw_ErrorCode.SubpartDescriptionStartWithout_) = "OK" & vbTab & "Description for subparts should not start with '_' or '='."
FileResultOKMessages(LDraw_ErrorCode.PartDescriptionStartWithout_) = "OK" & vbTab & "Description for parts should not start with '_' or '='."
FileResultOKMessages(LDraw_ErrorCode.ShortCutPartDescriptionStartWith_) = "OK" & vbTab & "Description for shortcuts and/or physical_colour parts has to start with '_'."
FileResultOKMessages(LDraw_ErrorCode.ShortCutFilenameContains_d_or_c) = "OK" & vbTab & "Filename for shortcuts contains usually a 'c' or 'd'."
FileResultOKMessages(LDraw_ErrorCode.NameExtensionIsDAT) = "OK" & vbTab & "Extension is .dat"
FileResultOKMessages(LDraw_ErrorCode.NoSpecialCharacterInDescription) = "OK" & vbTab & "No special characters in description found."
FileResultOKMessages(LDraw_ErrorCode.LineEndWithCRLF) = "OK" & vbTab & "Lines ends with <CR><LF>."
FileResultOKMessages(LDraw_ErrorCode.HistoryEntryAuthorBracket) = "OK" & vbTab & "Author !HISTORY entry has brackets."
FileResultOKMessages(LDraw_ErrorCode.PrimitiveIsScaled) = "OK" & vbTab & "Not scalable primitives are not scaled."
FileResultOKMessages(LDraw_ErrorCode.PrimitiveIsScaledY) = "OK" & vbTab & "Primitives are only scaled in Y direction."
FileResultOKMessages(LDraw_ErrorCode.BFCINVERTNEXTfollowedbylinetype1) = "OK" & vbTab & "First line after BFC INVERTNEXT is linetype 1."
FileResultOKMessages(LDraw_ErrorCode.CorrectRGBvalue) = "OK" & vbTab & "Correct RGB values used."
FileResultOKMessages(LDraw_ErrorCode.NoMoveToReferenceUsed) = "OK" & vbTab & "No '~Moved to' file used."
FileResultOKMessages(LDraw_ErrorCode.NoBFCCERTIFIEDCWorCCWfound) = "OK" & vbTab & "No wrong BFC command found."
FileResultOKMessages(LDraw_ErrorCode.KeywordsUnique) = "OK" & vbTab & "None of the keyword are used twice."
FileResultOKMessages(LDraw_ErrorCode.MinifigAccessoryNotFound) = "OK" & vbTab & "No 'Minifig Accessory' found in part description."
FileResultOKMessages(LDraw_ErrorCode.FigureAccessoryNotFound) = "OK" & vbTab & "No 'Figure Accessory' found in part description."
FileResultOKMessages(LDraw_ErrorCode.NotNeededInvertNextUsed) = "OK" & vbTab & "Usage of 'INVERTNEXT' seems to be ok."
FileResultOKMessages(LDraw_ErrorCode.SquareBracketsAroundUsername) = "OK" & vbTab & "Correct brackets around username used."
FileResultOKMessages(LDraw_ErrorCode.AliasPartDescriptionStartWithSame) = "OK" & vbTab & "Description for alias parts should start with '='"
FileResultOKMessages(LDraw_ErrorCode.PhysicalColorMentionedInDescription) = "OK" & vbTab & "Description for physical_color parts mention the used colors"
FileResultOKMessages(LDraw_ErrorCode.PhysicalColorPartOnlyLinetype1Used) = "OK" & vbTab & "Only linetype 0 and 1 are used in this Physical_Colour part."
FileResultOKMessages(LDraw_ErrorCode.PhysicalColorPartCorrectColorsUsed) = "OK" & vbTab & "No wrong color used for Physical_Colour part"
FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyLinetype1Used) = "OK" & vbTab & "Only linetype 0 and 1 are used in this Alias part."
FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyOneLinetype1) = "OK" & vbTab & "Only one (1) linetype 1 is used in this Alias part."
FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyColor16Used) = "OK" & vbTab & "Only color 16 is used in this Alias part."
FileResultOKMessages(LDraw_ErrorCode.AliasPartAliasMentionedInComments) = "OK" & vbTab & "Alias is mentioned in the comments."
FileResultOKMessages(LDraw_ErrorCode.AliasPartAliasNumberInComment) = "OK" & vbTab & "Number in the Alias comment is correct."
FileResultOKMessages(LDraw_ErrorCode.OriginNOTInBoundingBox) = "OK" & vbTab & "Origin is inside the Boundingbox."
FileResultOKMessages(LDraw_ErrorCode.AmericanEnglishWords) = "OK" & vbTab & "Only Australian English words are used in the part description."
FileResultOKMessages(LDraw_ErrorCode.EmptyLinesAtTheEnd) = "OK" & vbTab & "No more Empty lines at the end as necessary."
End SubFor some of the check standard values are used f.e. identical vertices etc. For more details I would need to have a close look into the code, so if you need some more information, please specify.
I'm leaning toward option 1 too:
But it might be useful to also 'invent' a LDraw spec version meta so we can link the allowed meta list to the spec version. This way software can determine the needed list and has some kind of forwards compatibility for when a new meta gets added to the allowed list it doesn't now of yet.
Based on the version number it knows there might be additional meta's in the header and it could fall back to just including all unknown meta's or something.
Quote: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).
But it might be useful to also 'invent' a LDraw spec version meta so we can link the allowed meta list to the spec version. This way software can determine the needed list and has some kind of forwards compatibility for when a new meta gets added to the allowed list it doesn't now of yet.
Based on the version number it knows there might be additional meta's in the header and it could fall back to just including all unknown meta's or something.
I'm in favor of a formal META for the reasons outlined by Allen. Unless someone come up with a compelling argument against his claims then I'm in his camp. Note that the reason "creates too much work" is null since these changes can be made on the back end by Chris without having to go through the PT.
Well personally I like the idea to have strict info about all meta's allowed in a header. Software compliant with spec verison x then knows what it needs to read / manage from such a header.
Having the !EOH meta will solve the presentation part but allowing anything in the header makes it somewhat hard for software to support editing such a header.
Having the !EOH meta will solve the presentation part but allowing anything in the header makes it somewhat hard for software to support editing such a header.
I do not see the presentation issue big enough
to justify the introduction of a new !EOH keyword.
It's just a small, cosmetic issue which can be easily solved by polishing the affected mentioned 154 parts
and/or extending the PT logic.
We should avoid keyword clutter.
Introducing new keywords can be become an addiction.
to justify the introduction of a new !EOH keyword.
It's just a small, cosmetic issue which can be easily solved by polishing the affected mentioned 154 parts
and/or extending the PT logic.
We should avoid keyword clutter.
Introducing new keywords can be become an addiction.
... keyword clutter ! Never heard such a killer phrase ! That's the hammer on the nail ... unfortunately on the fingernail. This is definitively not the house I can live and work. The endless discussions in this "palaver hall" about the most simple things shows up the worst side of "democracy". I am a little bit disillusioned and somewhat disappointed, but I want to say "thank you" sincerely for all your help and kindness.
Good bye !
Arthur Sigg
Good bye !
Arthur Sigg
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Whoah, Arthur, your reaction is by far too harsh.
I can only ask you to step back a little and reconsider.
Remember that we're discussing here a file standard used by thousands of users.
You must allow that an extensive discussion of such syntax extensions happens,
and also, that opposite opinions to yours are allowed to be said and heard the same way as yours is.
I am not an English native speaker, so when using the wording "keyword clutter" I did not intend a pun alongside with it.
I just wanted to express that we should be careful of minimizing the amount of specified keywords.
And on the introduction of each one, carefully consider.
There's no personal controversy going on here, especially not against you. All being said here is just exchanging
logical / technical arguments and counterarguments.
Take a deep breath and maybe a break of some days and then stay with us.
I can only ask you to step back a little and reconsider.
Remember that we're discussing here a file standard used by thousands of users.
You must allow that an extensive discussion of such syntax extensions happens,
and also, that opposite opinions to yours are allowed to be said and heard the same way as yours is.
I am not an English native speaker, so when using the wording "keyword clutter" I did not intend a pun alongside with it.
I just wanted to express that we should be careful of minimizing the amount of specified keywords.
And on the introduction of each one, carefully consider.
There's no personal controversy going on here, especially not against you. All being said here is just exchanging
logical / technical arguments and counterarguments.
Take a deep breath and maybe a break of some days and then stay with us.
It is still work that needs some manual intervention.
If it were possible to algorithmically determine where to insert the End-of-Header statement, it wouldn't actually need doing. Any files with "0 //" comments immediately following the !HISTORY will need to be reviewed to assess whether those are "Needs work" comments or "part content" comments, and the position of the End-of-Header statement adjusted.
If it were possible to algorithmically determine where to insert the End-of-Header statement, it wouldn't actually need doing. Any files with "0 //" comments immediately following the !HISTORY will need to be reviewed to assess whether those are "Needs work" comments or "part content" comments, and the position of the End-of-Header statement adjusted.
Chris (LDraw Parts Library Admin)
Are you are suggesting a fourth option:
4) Define a "needs work" meta-statement update all (Needs Work) files and 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: medium-high (programmatic plus manual update of probably > 154 official files).
4) Define a "needs work" meta-statement update all (Needs Work) files and 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: medium-high (programmatic plus manual update of probably > 154 official files).
Chris (LDraw Parts Library Admin)
No what I'm saying is either:
a) Have a EOH meta
-or-
b) Have every line in the header be under a meta that is illegal to be found outside of the header. This way once the first line without a header meta is encountered, that's the end of the header.
a is more futureproof that b but b requires less parts reissue. Personally, I don't see a problem with reissuing the entire library but some may object so I offer b as an alternative.
a) Have a EOH meta
-or-
b) Have every line in the header be under a meta that is illegal to be found outside of the header. This way once the first line without a header meta is encountered, that's the end of the header.
a is more futureproof that b but b requires less parts reissue. Personally, I don't see a problem with reissuing the entire library but some may object so I offer b as an alternative.
This problem is designed with our current header and the forced comment for "needs work" explanations.
If we agree on "needs work" comments needs to be mentioned before the !HISTORY lines all our problems are gone.
After the last !HISTORY line the header is finished.
Code:
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change
0 // CommentsIf we agree on "needs work" comments needs to be mentioned before the !HISTORY lines all our problems are gone.
After the last !HISTORY line the header is finished.
Code:
0 // Needs work comments
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change
0 // Comments
This is similar to what I suggested here:
http://forums.ldraw.org/showthread.php?t...33#pid8133
It would solve both the presentation and clutter problem.
http://forums.ldraw.org/showthread.php?t...33#pid8133
It would solve both the presentation and clutter problem.
Orion Pobursky Wrote:a) Have a EOH meta= option 3 here
Orion Pobursky Wrote:b) Have every line in the header be under a meta that is illegal to be found outside of the header. This way once the first line without a header meta is encountered, that's the end of the header.I believe the only untagged header content is "Needs work" comments, so = option 1 here
Chris (LDraw Parts Library Admin)
« Next Oldest | Next Newest »
Users browsing this thread: 6 Guest(s)