<Friithian>
like, it literally is just gunqqer @ friithian.dev so very obvious ``oh where could I possibly email this guy at''
<InPhase>
I figured the email address concealment ship sailed when I started putting it in peer reviewed journal articles. People will probably be able to dig out my email address 200 years after I die, if they really wanted to.
<InPhase>
But I refuse to respond to any emails after death. You have to draw some sort of line.
<Friithian>
for enough money I'll respond to email after death
<JordanBrown_>
I use throw-away addresses for almost everything.
<JordanBrown_>
It limits the damage when one of them is compromised.
<Friithian>
given I run my own mail server I usually just make a unique address and if it is over and done if someone attempts to email me at that they get a nice ``550 fuck off'' error message
<JordanBrown_>
I have a similar situation; I don't *run* the server but it is my domain and I administer the e-mail handling on it. If some address starts getting an unreasonable amount of spam, I kill it.
<JordanBrown_>
A *human* could probably easily guess my primary address - the one I use for general friends - but I am not worried about humans.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
<InPhase>
JordanBrown_: To your earlier comment about pointers, most C++ iterators are in fact just pointers, or if they aren't, are backed by a pointer internally with some extra behavior assigned.
<JordanBrown_>
Being a pointer into the list is OK. Being a pointer to an iterator object that maintains the iteration state, not so much.
<InPhase>
JordanBrown_: The usage pattern of iterators in that #4274 seems valid. The vector is unmodified, and everything seems to stay within a proper lifetime.
<JordanBrown_>
OK thanks.
<InPhase>
auto low_v = it; This for example is like making a copy of the pointer value.
<InPhase>
It's equivalently valid as long as the pointer is still pointing to a valid thing.
<JordanBrown_>
Right... again, fine if it's a pointer into the list, not if it's a pointer to an iterator object that will change as you advance through the list.
<JordanBrown_>
That is, where the object will change.
<InPhase>
I don't at all like code like this. :) But Michael did that part right as far as I can see.
<InPhase>
I consider this to be some of the messy risky parts of C++. But it is a very common approach.
<InPhase>
And, Michael was integrating with low disruption into an existing approach, it seems.
<JordanBrown_>
Imagine, for instance, an iterator that is walking all of the entries in a list of lists. That iterator needs to maintain two "current" pointers - one to the current list, and one to the current entry in that list. In C you might well implement that as an allocated object, with the iterator that
<JordanBrown_>
ject. In such an implementation, it wouldn't be useful to save and restore the caller-visible iterator.
<JordanBrown_>
the caller sees being a pointer to that iterator ob
<JordanBrown_>
Yes, though in the previous version it was saving the *values*, not the *iterators*.
<JordanBrown_>
I am basically happy with the change. I think there's a little that's more complex than required (the explicit use of .operator*() rather than just using multiplication), and I am unsure about the error handling.
<JordanBrown_>
The error handling either seems like too little (because a bunch of it is only against the first entry in the array) or too much (because the underlying arithmetic, vector indexing, et cetera will already handle errors).
<JordanBrown_>
I just posted my review.
LordOfBikes has quit [Ping timeout: 252 seconds]
<InPhase>
I'm compiling it right now to see if I can crash it. :)
<JordanBrown_>
I have seriously mixed feelings about the type checking. On the one hand, I want to detect as many bugs as possible, ref our discussions above. On the other hand, this isn't static analysis where checking doesn't hurt performance, and a lot of checking is, I believe, done automatically by the
<JordanBrown_>
But: (a) the underlying operations aren't going to check the [1] values that don't end up being used, and (b) I'm not a big fan of "return undef on error" because that undef can propagate for a long time before it kills you, and so the problem can be hard to diagnose.
<JordanBrown_>
underlying operations.
<JordanBrown_>
But recursively checking all of the [1] values for compatibility seems unduly expensive, both in implementation complexity and in performance.
LordOfBikes has joined #openscad
J1A8458 has joined #openscad
J1A84 has quit [Ping timeout: 252 seconds]
buZz has quit [Ping timeout: 244 seconds]
buZz has joined #openscad
buZz is now known as Guest5968
Guest5968 is now known as buZz
<InPhase>
JordanBrown_: You've maybe thought enough about it to have an opinion... I modified a copy of the lookup-tests.scad example with the part between "Start bad" and "End bad". https://bpa.st/UL5Q producing output in the relevant section of: https://bpa.st/L6HQ
<InPhase>
JordanBrown_: Now, obviously that's "bad" so I labeled it such. But one view could be that this is within the OpenSCAD standards of handling bogus data.
<InPhase>
JordanBrown_: Also, side-note... I was unable to make it crash with attempted abuse, so it passes a rigor check.
<InPhase>
JordanBrown_: Additionally, the previous version seems to have had no data integrity checks. One data integrity check was added here, but it only checks the first element of the lookup table.
<InPhase>
While we could consider this an improvement, it is sort of a weird behavior.
<JordanBrown_>
Yes to all of that.
<JordanBrown_>
The "bad" results are ... not a crash, but do not seem ... robust. But I suspect that they are also what "naturally" falls out of the processing done.
<JordanBrown_>
BTW, you could probably make the second entry be [3, "aardvark"] and it would have done something silly but unsurprising.
<JordanBrown_>
Would that output have captured warnings?
<JordanBrown_>
I'm a little surprised that line 4 didn't trigger a warning, since it's doing
<JordanBrown_>
vector*number + number*number
<JordanBrown_>
and thus vector + number
<JordanBrown_>
and that triggers a warning.
JordanBrown_ is now known as JordanBrown
<JordanBrown>
(ignore)
<JordanBrown>
(That is, ignore the (ignore). I was just checking to see if I had gotten rid of the underscore in my name.)
<JordanBrown>
It seems unfortunate that the entries aren't required to be in order, because if they were then we could do a binary search. But alas.
<InPhase>
If we had any type info on lookup tables we could sort, but we don't, so we can't.
<InPhase>
Well. Actually I suppose we could cache a sorted copy at the first lookup.
<InPhase>
Use some not-a-valid-name convention to stash a sorted copy in the context.
<InPhase>
Whether or not that speeds things up depends on usage patterns, I suppose.
<JordanBrown>
We have the type of the [0], and that's what we'd need to sort on. But I would be dubious about a sort-and-cache scheme being a win. Unless there is a fast way to recognize that the second call is on the very same array you'd have to compare the arrays, and that would be way more expensive than
<JordanBrown>
doing the existing linear search.
<peepsalot>
github just went down
<peepsalot>
nm, back up
siege has quit [*.net *.split]
Fleck has quit [*.net *.split]
raboof has quit [*.net *.split]
siege has joined #openscad
raboof has joined #openscad
Fleck has joined #openscad
<InPhase>
peepsalot: I didn't see your message, because I was too busy typing up a post on github and not noticing the outage. ;)
<JordanBrown>
InPhase: it's not that much of a game changer... my replacement is 5 lines. Decompose the table into x, y, and z components, call lookup three times, reassemble into a coordinate.
<JordanBrown>
But it is better not to have to do that.
<InPhase>
JordanBrown: By that point I wouldn't use lookup.
<InPhase>
I've done a lot of multi-phase animations, but I'm convinced that vectorizing the lookups is going to be enough of a convenience that I would design many of them around this capability.
<JordanBrown>
Er, OK. https://bpa.st/2ZLA seems like a lot simpler than DIY find-and-interpolate.
<InPhase>
JordanBrown: This was my "prove it works" test: https://bpa.st/R3SA
<JordanBrown>
And, looking at that, I must have written that when I knew less than I do now, because it could be simpler.
<InPhase>
JordanBrown: You have to admit that's a really clean way to specify phased animation behavior.
<JordanBrown>
Absolutely. Why do you think that I wrote xyzinterp()?
<InPhase>
Oh, I just parsed now what it does.
<InPhase>
But yeah, good to build that in.
<JordanBrown>
I have atranslate(table) { ... }, arotate(table) { ... }, and a couple of simple cases a2translate(p1, p2) and a2rotate(p1, p2) that use fixed tables to move something from a start position to an end position and then back.
gwillen has quit [*.net *.split]
gwillen has joined #openscad
gwillen has joined #openscad
gwillen has quit [Signing in (gwillen)]
<InPhase>
angular interpolation might be an interesting special case with proper handling of wrap-around, but I would not do that as a built-in.
<JordanBrown>
Or as a simple solution, just don't wrap. Keep going past 360.
<peepsalot>
you mean slerp? (i get to say slerp once again)
<InPhase>
Well I was thinking just proper angular interpretation of degrees values. But sure, a slerp might be nice as well.
<InPhase>
peepsalot: I guess a general slurp type interpolation for animation requires thought though if it's going to handle changing radii, because you have to think about what you want to happen at the transitions. :)
<InPhase>
And I should be asleep, so I will try to go do that.
<JordanBrown>
I've used xyzinterp() for two basic kinds of animations:
<JordanBrown>
1) Animating parts between their print positions and their assembled positions.
<JordanBrown>
2) In conjunction with a couple more functions, to control the camera for a fly-through of the model.
<ali1234>
i seem to have made a design that breaks roof in openscad nightly
<ali1234>
or it could just be taking a very long time to render
<ali1234>
but normally the gui doesn't respond during rendering
<ali1234>
it's still using CPU so i will leave it for a while
<ali1234>
ah it finished. 7 minutes
<ali1234>
also: WARNING: GeometryEvaluator: Node didn't fit into cache.
<ali1234>
i guess it was too high fn (and fs/fa seems to cause issues with roof)
<J1A8458>
yes known error
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
<J1A8458>
oh that is strange rendering with fastCSG lead to "EXPORT-ERROR: Can't add triangle to 3MF model." when a certain size is reached .. but normal render exports fine
<J1A8458>
ah damn we already had this .. something about data conversion from fast CSG
Guest88 has joined #openscad
Guest88 has quit [Client Quit]
TheAssassin has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
snakedGT has quit [Ping timeout: 268 seconds]
castaway has quit [Ping timeout: 268 seconds]
castawayc has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
castaway has joined #openscad
castawayc has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
teepee_ has joined #openscad
J1A8458 has quit [Quit: Client closed]
J1A8458 has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
la1yv_b has quit [Ping timeout: 244 seconds]
splud has quit [Ping timeout: 255 seconds]
lostapathy has quit [Quit: WeeChat 3.5]
lostapathy has joined #openscad
lostapathy has quit [Client Quit]
lostapathy has joined #openscad
ur5us has quit [Ping timeout: 256 seconds]
splud has joined #openscad
ur5us has joined #openscad
ghee has joined #openscad
ghee has quit [Remote host closed the connection]
snakedGT has joined #openscad
p3ck has joined #openscad
J1A8458 has quit [Quit: Client closed]
J1A8458 has joined #openscad
ur5us has quit [Ping timeout: 256 seconds]
snakedGT has quit [Remote host closed the connection]
snakedGT has joined #openscad
snakedGT has quit [Quit: Leaving]
<J1A8458>
overwriting a variable causes a warning .. but if the variable was defined in a lib you can overwrite it without - which is correct .. but you can now overwrite the overwrite without a warning ..
teepee has quit [Quit: bye...]
teepee has joined #openscad
<peepsalot>
teepee: i dont think so, as I'm not on wayland
<teepee>
ah, ok
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
aiyion has quit [Remote host closed the connection]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
aiyion has joined #openscad
p3ck has quit [Ping timeout: 256 seconds]
snaked has joined #openscad
p3ck has joined #openscad
califax has quit [Ping timeout: 268 seconds]
califax has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 268 seconds]
ndnihil is now known as nihil
nihil is now known as ndnihil
ur5us has joined #openscad
teepee_ has joined #openscad
aiyion has quit [Remote host closed the connection]