m4ssi has quit [Remote host closed the connection]
<sklv>
hi, i want to contribute to solvespace but I'm completely new to the codebase. I thought I'd try debug an issue i'm having, #435.
<sklv>
I've got a breakpoint on it in vs currently, the assertion is failing because the IdList its operating on already contains an entity with the same id
<sklv>
I don't currently have any concrete questions but i might ask for some direction in a bit
<sklv>
just out of interest how did you establish that caused it
<whitequark>
1) it's the only change that fits the nature of the error
<whitequark>
2) i asked people in #435 to try out the previous commit and they say it works
<sklv>
its possible i created the file using a commit prior to that one
<sklv>
but that shouldn't make a difference as what has changed is the runtime entity store
<whitequark>
the runtime entity store is saved into the file
<whitequark>
it's ignored when loading the file, but used when *importing* the same file
<whitequark>
so the bug only fires on assemblies
<sklv>
just out of curiousity, is backwards file format compatibility meant to be supported?
<whitequark>
of course
<whitequark>
that's a major constraint on evolution, for that matter
<sklv>
ughh you even said what to do in the issue :)
<sklv>
i'll try adding dbp to remap
wpwrak has quit [Ping timeout: 244 seconds]
<sklv>
it's okay for remap to contain entries with v=0 right?
<sklv>
as Entity::NO_ENTITY=0
<whitequark>
sklv: interesting
<whitequark>
i'm not sure actually
<whitequark>
can you compare it with the commit before bd84bc1... ?
<sklv>
good idea i'll do that
<sklv>
i am struggling to understand the purpose of remap in general
<sklv>
it appears to contain all entities
<sklv>
but then why is it called *re*map
<whitequark>
let's say you extrude a circle
<whitequark>
you get two new circles, one at the top and one at the bottom surface
<whitequark>
you need to assign them ids
<whitequark>
they should be fixed-size, so they can't be hierarchical
<whitequark>
(consider the case of extruding a translate group)
<whitequark>
they also should stay stable, so they can't be just deterministically assigned
<whitequark>
(consider the case of extruding 2 circles, constraining the second extruded top circle, and deleting the first original circle)
<whitequark>
er, sorry, I made an error before
<whitequark>
17:17 <@whitequark> it's ignored when loading the file, but used when *importing* the same file
<whitequark>
it's the other way around
<whitequark>
it's used when loading the file, but ignored when importing
<sklv>
i thought importing was for dxf,dwg etc, and load was for native slvs. how could I load and import the same file if the formats are mutually exclusive?
<sklv>
hmm the debug build process is single threaded, that's annoying
<whitequark>
oh, sorry
<whitequark>
not importing, linking
<whitequark>
as in new group -> link/assemble
<sklv>
that makes more sense
<sklv>
also i've just realised 'so the bug only fires on assemblies' my file isn't an assembly
<whitequark>
yes, sorry, I'm not feeling very well today and I mixed up a few things
<sklv>
its totally cool, thanks for taking the time to explain stuff