process_deletion_inverse() called inverse_index::remove_source(), which
walked every record in the file's inverse index to find the ones whose
source is the deleted instance: O(R) per deletion, the dominant cost of
file.remove() on large files now that the lookup side no longer re-sorts.
The records a deleted instance contributed are exactly the entity
references in its own attributes, so walk those with the same visitor
build_inverses_() uses for registration and remove each record with a
targeted binary search instead. remove_source() has no callers left and
is deleted.
Also use the ordered view of batch_deletion_ids_ (a boost multi_index
that already had one) for the is-this-referencer-also-being-deleted
check in process_deletion_(), which was a linear std::find over the
sequenced view: O(b) per referencing instance made batch deletion of b
instances quadratic.
file.remove on 300 IfcPropertySet of a 155 MB IFC4 model (201k IfcRoot)
drops from 3.15 ms to 0.17 ms per call, batched removal of 2000 from
3.34 ms to 0.17 ms per call, root.remove_product on 100 walls from
332 ms to 131 ms per call.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HNrXDmR88wKPCYwGE21SyH
The in-memory inverse_index was one flat vector with a sorted flag. Every
add() cleared the flag and every lookup re-sorted the entire vector, so a
loop that creates an instance and then reads an inverse (api.pset.add_pset,
for one) cost O(R log R) per iteration on a file with R references: 400 ms
per add_pset call on a 155 MB model, against 0.4 ms on v0.8.0.
Split the index into two tiers. The flat vector stays as the base: bulk
loading appends to it and sort() finalizes it once, as before, and removals
tombstone in place. Records added after that go to a delta bucketed by
referenced id, and lookups read the base range followed by the bucket.
compact() folds the delta back and drops tombstones once either outgrows
the live base, so folding is amortised O(1) per mutation.
The four in-memory callers in parse.cpp move from an iterator range to
for_each()/count(). The map-shaped legacy interface that variant_map needs
is kept and materialises from both tiers.
add_pset on the 155 MB model: 400 ms -> 0.25 ms per call. Unit test covers
interleaved create-then-read, repointing across both tiers, deletion of
sources and targets, and tombstoning past the compaction threshold.
This commit was written by an AI coding tool and has not been verified by
a human.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013wcN7XquTfUi4vsKQ4KchL
blender --background exits 0 even when the --python script dies with an
exception, so the reregister smoke test passed over "FATAL ERROR: Unable
to load Bonsai" and a broken build was published to the unstable repo.
--python-exit-code 1 makes every gate script failure fail its step.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CI was failing:
```
The system library `dbus-1` required by crate `libdbus-sys` was not found.
The file `dbus-1.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
The PKG_CONFIG_PATH environment variable is not set.
```
There was an error building a standalone ifcwrap when previously built IfcOpenShell had rocksdb - `_ifcopenshell_wrapper.cpython-314-x86_64-linux-gnu.so: undefined symbol: _ZTV17RocksDbSerializer`.
`IFOPSH_WITH_ROCKSDB` propagated to the build, requiring rocksdb symbols, but `WITH_ROCKSDB` wasn't set and `document_serializer_rdb` target wasn't provided.
Otherwise it will never be able to reach standalone ifcwrap build as in this case ifcopenshell is built first as a dependency without `BUILD_IFCPYTHON`.
When fixing warnings, noticed that was working a bit inproperly - `bnode` always end up being an empty list (because there's no `brick, A, REF.IFCReference` triple), so then passing empty list to `triples` resulted in selecting all nodes isntead of just the expected `bnode` (that's the behaviour `sqlachemy` was sending the warnings about - when empty lists unexpectedly selected everything).
`None, None` assumed by default.
Though this was introduced in Python 3.13, before 3.13 it only breaks if we'd do `typing.Generator[T]` (which is deprecated) -`collections.abc.Generator[T]` works fine, it seems it never had an arity check.
Raising `AttributeError` is definitely wasn't correct here, since it
might push the code to assume it's a wrong entity type. Returning some stub value like `None` also could suggest incorrect derived attribute
value, leading to unexpected behaviour. So adding an error, so it would
propagate and code would need to be adjusted not to rely on derived
attributes, if it actually interacts with sql/stream.
`test_unit` was asserting that derived attr will return `None`, though
it was actually raising `AttributeError`.
Using symlinks just for main libs/pluigins doesn't seems to resolve `$ORIGIN` for some reason - e.g. occt libraries appears to be missing. So symlinking everything, including the dependencies seems to be the way to create a dev environment.
Facet.filter() implementations broad-phase query with
ifc_file.by_type(), then check isinstance(elements, list) to decide
whether a previous facet already narrowed the candidate set. In
v0.9.0, file.by_type() returns a tuple instead of a list, so that
check silently failed and every facet after the first re-scanned the
whole model instead of the already-narrowed (possibly empty) set.
This let a prohibited Entity+Attribute applicability match instances
of the wrong class, e.g. an IfcSlab satisfying an "IFCWALL" Entity
facet's chain. Accept tuples too, matching how by_type() results are
actually returned now.
get_attribute_category() returns 3 for a derived attribute, but
sqlite_entity.__getattr__() only branched on FORWARD (1) and INVERSE
(2), so any derived attribute (e.g. IfcSIUnit.Dimensions) fell
through to the final AttributeError instead of returning None, which
is what SQLite-linked files are documented to do since derived
attributes are not computed for them. Mirrors the DERIVED handling
already present in entity_instance.py's __getattr__.
diff() looked up common elements with self.old.by_id(global_id) /
self.new.by_id(global_id), passing a GlobalId string into a method
that expects a STEP integer id. On v0.8.0 file.by_id() was a Python
wrapper that transparently dispatched strings to by_guid(), so the
bug was silent. v0.9.0's file class binds by_id directly to the
C++ instance_by_id(int), so it now raises
TypeError: in method 'file_by_id', argument 2 of type 'int'.
Runtime plugins are canonically named `ifcopenshell_<kind>_<name>` (decorated_basename() in src/plugin/plugin.cpp, and the OUTPUT_NAME properties of the plugin targets), but the archive collection filtered on the dotted `ifcopenshell.` prefix, which matches only the core shared libraries. Every load-by-name plugin was therefore silently dropped from every win64 / win-arm64 zip.
Accept both prefixes, and extend the geometry-writer exclusion to the underscore form so the per-schema writers keep their existing Python-package-only treatment.
Fixes#9301
* Honour IfcAxis2PlacementLinear Axis/RefDirection in the loft builder
make_loft() (src/ifcgeom/infra_sweep_helper.cpp), shared by
IfcSectionedSolidHorizontal and IfcSectionedSurface, mishandled a cross
section's IfcAxis2PlacementLinear in two ways:
1. A placement carrying Axis but no RefDirection was placed with a fixed
[e_y | e_z | e_x] world-axis permutation that ignored the directrix.
On any directrix not running along +X (e.g. a north-south road
pavement, or anywhere along a curve) the profile came out mis-oriented
or collapsed to a sliver.
2. When two adjacent CrossSectionPositions used direction vectors
inconsistently (a raked RefDirection at one, a plain Axis at the
other) make_loft() logged GEO 42, dropped the rotation for the whole
segment and squared every cap -- and in one configuration left the
sweep frame flipped, so OpenCASCADE failed to build the solid at all.
Now a small profile_basis() helper builds every cross section's frame the
same way: profile Y = Axis, profile normal = RefDirection, and -- when
RefDirection is absent -- profile normal = the directrix tangent, so the
section stays perpendicular to the path (buildingSMART IFC4.x-IF #147).
When the two bracketing placements ask for the same orientation the sweep
frame carries it, built against the curve. When they disagree the sweep
frame stays on the shared Axis (continuous with the neighbouring
consistent segments, so nothing flips) and each end's own authored
orientation is folded into its profile points via a change of basis, so
each end cap still lands exactly as authored while the body in between
keeps following the directrix. The all-equal and no-direction-vector
paths are unchanged.
The two mappings now also carry the raw RefDirection through on
cross_section, alongside the existing rotation matrix.
Adds C++ tests (a raked end logs no GEO 42; a directrix that does not run
along +X still lofts a full-size solid) and Python tests (uniform prism
raked at one end and square at the other; a north-south directrix keeps
its width; OffsetLateral/OffsetVertical are scaled by the model length
unit).
* Renames profile_rotations to profile_axis for consistency with profile_ref_directions
Adopt the reviewer's suggestion on #9396: instead of counting how many
skips each duplicate identity has earned, record which duplicate
identities have already built once. The first occurrence builds, the
rest are skipped. Distinct-identity loops that only become duplicates
after point mapping behave as before. Set semantics are also robust if
the helper is ever driven over the same shell twice, where a consumed
counter would under-build.
Port of #8772 to v0.9.0 (open_cascade_kernel::faceset_helper is the
renamed class, same logic). When an IfcConnectedFaceSet repeats the
same IfcFace, wires() still dropped every occurrence via duplicates_,
leaving a hole in the shell; this counts the redundant occurrences
and skips only those, keeping one copy of each repeated face.