Gah, how did datums get busted?!?!
looks like minortype is correct (44).. majortype is 255, though, and that's not right
yeah, it's supposed to be 1 (majortype BRLCAD)
Busted in 7-30-2-1
works in 7-26-0
looks like the datum_in code has never set the majortype but worked, so either extra validation checks were added or majortype setting was removed from someplace common to multipl types
OK, you're deeper than I am - want me to add a regression test while you're hunting?
can you see what the majortype is in 26.0?
what's a quick way to print that?
does the datum from 26 open in 30?
Opens in trunk, actually - draws too
okay, so it's not extra validation then
just to confirm, you can try running: gex file.g
see if there's an unknown majortype listed (assuming you didn't create invalid and valid ones)
===============================================
Objects found in BRL-CAD V5 database: datum.g
===============================================
Object DLI type/major/minor type: 1/ 0/ 0 name: (none)
Object DLI type/major/minor type: 0/ 2/ 0 name: _GLOBAL
Has one or more attributes.
Object DLI type/major/minor type: 0/ 1/ 44 name: datum.s
Has one or more attributes.
==========================================
Summary for BRL-CAD V5 database: datum.g
==========================================
Found 3 objects:
free space: 0
named : 2
other : 1
2 objects have one or more attributes.
Object DLI types (the main category: defined in H Flags):
0 (APPLICATION_DATA_OBJECT) : 2
1 (HEADER_OBJECT) : 1
Object major types:
0 (RESERVED) : 1
1 (BRLCAD) : 1
2 (ATTRIBUTE_ONLY) : 1
Object minor types:
0 (RESERVED) : 2
44 (unknown) : 1
Note: file read ended normally at EOF.
yeah that looks right
created prior to my fix creates:
Object major types:
0 (RESERVED) : 4
1 (BRLCAD) : 14
2 (ATTRIBUTE_ONLY) : 1
9 (BINARY_UNIF) : 1
255 (unknown) : 1
ah, right, there it is: Object DLI type/major/minor type: 0/ 1/ 44 name: datum.s
vs Object DLI type/major/minor type: 0/255/ 44 name: datum
busted in rel-7-28-2
this is where having a database with all objects in the regression suite would have triggered a failure, caught it
.. @Thusal Ranawaka can you make sure you add datums to your list? :)
rel-7-26-4 works
@Sean Is r76443 the full fix? I'll have to start bisecting if you want me to ID which commit actually broke it
May want to put out a patch release with that fix - trunk would be a heck of a jump just for that...
Working as of r71000
Sean said:
.. Thusal Ranawaka can you make sure you add datums to your list? :)
@Sean Roger that! :police:
Found it - I did it, commit r71953
I don't think we need to bisect the cause
oh, I see you found it, great
so what that might imply is that other 'in' command primitives could be busted. we should check them since this reared its head
/me agrees
most manually set, but I did see at least two other commits where the type was added back in, presumably to fix a released error
also implies a NEWS item will be in order for those types
/me nods - I'm thinking a 7.30.10 patch release? Should be easy to backport the changes for this issue...
Last updated: Jan 09 2025 at 00:46 UTC