<InPhase>
Perhaps the permission update cronjob failed out for some reason.
<ccox>
Was it running on AWS? <evil grin>
<InPhase>
Maybe teepee mis-pelled ClimbingCircles
<Jack21>
haha
<Jack21>
seems that AWS issue was solved
<ccox>
yes, but a lot of services are still recovering/syncing.
<InPhase>
It's running on github servers. github is owned by Microsoft. And don't they still run a competitor to AWS? :)
<Jack21>
one day recover will cause another outage so everything went down
<ccox>
yes, they still have this Azure thing.... not sure if it's comparable ;-)
<InPhase>
It used to be you could traceroute to see where things are hosted, but traceroute doesn't work so well these days.
<Jack21>
.. and all telephones will ring the same time
<Jack21>
lf94 will hate this .. this are cubes .. i thought extrudes but a lot of cubes
<InPhase>
Yes, I've been waiting patiently for lf94's reaction video to this one. :)
<Jack21>
8000 cubes
<lf94>
I'll see soon
<lf94>
walking to gym
ferdna has joined #openscad
<Jack21>
12438 .. Ü
<Jack21>
in under .5 sec
<InPhase>
There. I just added a zero-overhead max memory usage logger to my OpenSCAD launcher script. This will help me be able to go back and check how much memory each design took. I now get neat little log entries like: 2021-12-07 22:19:09 2596.090 MB, openscad Ornaments.scad
<ccox>
good
<InPhase>
If I just leave that in place for a couple years, I'll be able to spot regressions. :)
<ccox>
Logging all allocations/frees is slowing things down a bit.
<ccox>
SO far the render has taken 42 minutes, and I don't think it's hit peak memory usage yet.
<InPhase>
https://bpa.st/5WDQ This is the script. I saved as log_scad_mem, and my launcher script (the one in the tips and tricks) now does essentially: log_scad_mem openscad "$@"
<Jack21>
this is strange the climbing circles give a nan when r =14 and step in the loop is 0.07
<InPhase>
Jack21: Probably from here: pow((r*r - z*z), 1/2)
<Jack21>
yes it gets negative
ur5us has joined #openscad
<InPhase>
Perhaps a floating point error from that step size.
<Jack21>
but that would mean x is bigger r
<Jack21>
i know .07 is a bitch
<InPhase>
Jack21: Is that with release or master? I remember peeps made some clever updates to the looping, but I forget which month/year.
<Jack21>
19.10
<InPhase>
That would be before them.
<InPhase>
I bet it doesn't give the nan on a nightly.
<Jack21>
oh we have new snapshots
juri_ has joined #openscad
<InPhase>
I think what he did was something like turn the steps into an integer process so weirdnesses don't emit like that? Something along those lines. I'd have to check logs or PRs to jog my memory.
<Jack21>
it would be easier to spot if echo isn't loosing precision
<Jack21>
so it reads 196 - 196 = -1.13687e-13
<InPhase>
echo((r*r-z*z));
<InPhase>
Yeah.
<Jack21>
still wondering why these gaps in the circles occure
<Jack21>
ah ok he entering floats into the loop
<InPhase>
Well it's a loop over x, so that's the same as the gaps in SphereEquation.scad
<InPhase>
Just packed tighter so there's only the one stretch.
<InPhase>
... If anybody is grabbing my memory logging script above, I put hours and minutes backwards. :) Swap %H and %M.
<InPhase>
My first test run was at 19:19 so I didn't notice.
<InPhase>
I sure noticed though at my test run from 41:19
<Jack21>
with increased r by .05 y = pow((max(r*r - x*x,+0.05)), 1/2); is closing the gaps
<Jack21>
this feels terrible
<InPhase>
This is why angles were invented. :)
<InPhase>
Jack21: Look ahead to Snowballs.scad, line 113. Faced with the same scenario, I stepped by angle and converted to linear from the angle.
<Jack21>
did you ever worked with quarternions in scad?
<InPhase>
Not in scad, but for some Unity-related work.
<Jack21>
yeah in unity this is normal
<Jack21>
i have a case of gimbal lock for calculating the angle between two vectors
<InPhase>
Did you try the dot product formula?
<Jack21>
and when they are on top (same xy different z) i get strange rotations .. so either i use a different calculation or thought quartenions could help
<Jack21>
worked with atan2
<lf94>
it's available in 3 minutes right
<InPhase>
-61 minutes
<Jack21>
maybe i can use cross()
<InPhase>
Jack21: Are you just wanting the angle? Or are you trying to get the rotations that will move another object in that direction?
<Jack21>
isn't this the same .. in the end i need to orient something towards the vector
<InPhase>
Somewhere I wrote a RotateTo(vector) module...
<InPhase>
Or maybe FromTo
<InPhase>
Let's see if I can find it.
<Jack21>
mine is working fine for everything that is not vertically aligned
<InPhase>
Yes. Let's see if I addressed or ignored that case.
<Jack21>
.oO already wrote that quarternions converter
<InPhase>
Jack21: If it fails for your specific case, point out what it was. It was some time ago I made this.
<InPhase>
Oh, hm. The date at the top says this year. Must have been very early this year at least.
<Jack21>
it is similar to mine .. when things are vertical and slightly change x and y you get large rotations around z
<Jack21>
(although i don't understand why you need so many rotations .. i am only using two angles)
<InPhase>
Jack21: I didn't leave any comments, but I remember why. There's obviously an arbitrary axis left for the rotation about the initial vector itself. Mine is designed to preference preserving the original xy plane orientation.
<InPhase>
So if you'll notice, my cubes are pointed in the target direction, but they are still "level" in xy. They didn't tip over sideways.
<lf94>
day 8 is broken for me
<lf94>
403
<Jack21>
lf94 yeah we feel you
<InPhase>
lf94: Yes, we already pinged teepee who is the only one who can fix the permissions error.
<InPhase>
Jack21: I spent a bit of time thinking about usage options for rotation, and I really think that xy-preserving choice for rotating to a vector is probably the most generally useful for most things one would want to design, as so much of our existence is in a gravity field. :)
<Jack21>
inPhase yes you work (i work) with a declination and azimut angle
<InPhase>
Jack21: Although it might not be the right choice for your particular scenario, which sounds like it might be more spherically unbiased art or something.
<InPhase>
lf94: I'm not sure if the original implementer of Day 2 intended an armadillo pattern, but that was definitely what that one reminded me of. :)
<InPhase>
lf94: So does curv do animation yet?
<InPhase>
lf94: This is what's coming next for you.
<lf94>
Yes curv does animation
<lf94>
Each shape is passed a time parameter, and what it does is up to me
<lf94>
Remember, curv was supposed to be an openscad competitor / "replacement"
<InPhase>
That's why I added the "yet". :)
<InPhase>
But good to hear.
<lf94>
So far the only thing openscad has over curv is the damn unions but this will be resolved very soon.
<lf94>
I guess also being able to do hull and minkowski.
<lf94>
This curv will probably never be able to do
<lf94>
You could probably implement minkowski in some way but it'd be painful I think
<InPhase>
I think for minkowski you would need to use vector functions instead of distance functions.
<InPhase>
But I'm not sure if anyone has ever attempted this.
<lf94>
Someone out there probably has
<lf94>
Some crazy math person
<lf94>
:D
<InPhase>
I suppose technically you could do this with a gradient on the distance functions... As long as every distance function is a true distance function, and not a hack like the icosahedron example you hit.
<InPhase>
But to keep that true distance function one would need some extreme discipline on simple things like scaling operations...
<InPhase>
JakeSays: An sdf openscad-like with significantly different syntax.
<InPhase>
lf94: Yes, I have in fact considered it.
<JakeSays>
lf94: that would be a really bad idea
<InPhase>
lf94: To the point where I think it might be a good idea, but I can't prove it is a good idea yet.
<JakeSays>
InPhase: it's not
<JakeSays>
InPhase: why would you want to move away from qt?
<InPhase>
JakeSays: Because Qt broke centralized exception handling in Qt6 which I consider an unforgiveable and unmitigable design flaw.
<JakeSays>
InPhase: what do you mean by centralized exception handling
<InPhase>
JakeSays: One of the major points of exceptions is that if you do not immediately handle them, you allow them to propagate up to a higher level section of the code where you will handle them centrally. This is why exceptions are better than manually checking error codes all over the place.
<JakeSays>
InPhase: well, that's a matter of opinion.
<InPhase>
That's pretty much the key difference.
<JakeSays>
exceptions used as true exceptions, yes, but that rarely happens.
<JakeSays>
most of the time exceptions are used as control flow
<InPhase>
JakeSays: In Qt, for like 15+ years, the standard method of doing this was to use QApplication subclasses to catch exceptions in the notify method that launched events, permitting all event handlers to have a centralized process for handling exceptions.
<JakeSays>
so is this a pattern that's used heavily in oscad?
<InPhase>
In Qt6 they decided that this was hazardous because it meant you had to shut down threads before closing the program. (Of course you do!) So they wiped out all exception propagation from events and declared that any exception propagated out of an event will simply crash the program.
<JakeSays>
well, qt has always considered threads to be long lived
<JakeSays>
which isn't a valid assumption
<InPhase>
This means you cannot combine Qt, exception handling, and reliability. It's a "choose 2" scenario, and the 2 that matter more to me are exception handling and reliability.
<JakeSays>
why do you want to throw exceptions out of an event?
<JakeSays>
that doesn't make sense to me
<InPhase>
This is important to all my Qt code, some making use of this quite prolifically. I would rather replace the gui toolkit entirely than remove reliable exception handling architectures.
<JakeSays>
hmm
<JakeSays>
ok
<InPhase>
OpenSCAD just happens to be another program I work on that uses Qt, so I've contemplated whether or not it would be worth replacing it here also.
<JakeSays>
what would you use in its place?
<JakeSays>
because there aren't many ui kits on par with qt
<InPhase>
And there are some nice additional benefits to Dear Imgui it seems, that might make it more suitable for browser use as well. But I haven't had time to actually try using it. The people who do seem quite fond of it though.
<JakeSays>
imgui is for very simple UI's
<InPhase>
Qt on the other hand is something people use because it has for a long time been the only real C++ choice.
<JakeSays>
it still is
<InPhase>
But not because they actually like Qt.
af has quit [Ping timeout: 256 seconds]
<JakeSays>
trust me - i've been looking for years.
<JakeSays>
there's nothing that comes close
<InPhase>
The Dear ImGui interfaces don't really look any simpler. Although every example screenshot is dark-themed, but that is presumably a matter of choice rather than requirement. :)
<JakeSays>
well, it would be a disaster
<InPhase>
Why?
<JakeSays>
it's not a UI kit for a desktop productivity app, which is what openscad is
<InPhase>
Well people also use it for that.
<InPhase>
I'm aware it originated from game UIs, but that's not all it's used for these days.
<JakeSays>
of course. people use html too. neither produce apps worth a shit
<InPhase>
JakeSays: Have you tried it or looked into it within the last year or two? Most of the good features for supporting desktop apps appear to be fairly recent additions from my recent reading about it.
<JakeSays>
we use it for a few debug tools in an embedded product. it's been probably 8-10 months since i've looked at its feature set
<InPhase>
And what do you think impedes its use?
<InPhase>
From videos it looks to me to have all the same essential interface elements, except that they are more responsive.
<InPhase>
Qt on the other hand is laggy with updates as it reprocesses through the object hierarchy.
<JakeSays>
hmm. it does have a lot of third party additions
<JakeSays>
a bit? and that's pretty much the caliber of every imgui i've seen
<JakeSays>
hmm. i am going to try that slicer though
<JakeSays>
on linux it runs in an X window.
<InPhase>
The majority of imgui examples out there are ugly interfaces. But... the majority of Qt examples out there are really ugly too when I use the same sort of search process.
<JakeSays>
oh i've seen some gorgeous qt ui's
<InPhase>
Just the dominant color for imgui is light grey on black, while the dominant color for Qt is black on light grey.
<InPhase>
Oh me too.
<InPhase>
But the difference seems to be in how people use it. :)
<InPhase>
So I'm optimistic there is a way to use imgui elegantly as well.
<InPhase>
I'm not a crazy person though. I wouldn't port an app without trying to make a few elegant testcases first.
<JakeSays>
i think you would spend a hell of a lot of time getting imgui to look as good as a good qt ui
<JakeSays>
or just get openscad to look on par with what it does now
<InPhase>
Qt gives me a lot of layout grief as-is, with portability layout issues that can be rough to resolve, and change in how you have to resolve them with every version bump.
<JakeSays>
i've been using this slicer for about 15 minutes now and the ui is already diving me nuts
<InPhase>
What OpenSCAD gets from Qt is actually not that much.
<InPhase>
If we momentarily ignore the editor, it's a set of dropdown menus that you couldn't possibly screw up, an OpenGL window that Qt doesn't help with, a row of buttons, a text display window, and two tab selectors.
<JakeSays>
hmm. i expected this slicer to be more responsive when rendering the sliced model.
<InPhase>
The editor is not unmanageable either, as Scintilla has already been ported to run on Dear ImGui by some ambitious person a few years ago.
<JakeSays>
well, i dunno. i'm sure you could make it work but i'm not sure it'd be worth the effort.
<InPhase>
I'm not sure it would be worth the effort either. :)
<InPhase>
But, I'm mad at Qt's terrible design decision directions, and that's why I said yes to the question of whether or not I thought about it.
<JakeSays>
i still dont understand why you would allow an exception to propagate out of an event
<InPhase>
Would you allow an exception to propagate out of a function call?
<InPhase>
How is this any different?
<JakeSays>
of course, but an event isn't semantically the same thing.
<InPhase>
The question is simple: What do you want unhandled exceptions to do in your program?
<InPhase>
1) Crash it. 2) Be ignored. 3) Be logged. 4) Notify the user. 5) Something else.
<JakeSays>
i expect the event handler to catch all exceptions, and then deal with them out of band
<JakeSays>
most likely post to a message queue, etc
<InPhase>
So in event handlers do you write catch-alls for std::exception and some sort of generic logging and notification code in every single one?
<InPhase>
Multiplied times 1000?
<JakeSays>
i have methods that are called with the passed exceptions
<InPhase>
And so for 1000 events you try/catch/call in every single event?
<JakeSays>
but honestly i rarely use exceptions, so when an exception is thrown its almost always fatal
<InPhase>
See that's where the disconnect comes in.
<InPhase>
Fatal is not an option in reliable code...
<InPhase>
Every exception MUST be caught in every possible path. It's not optional to ignore them and conclude some don't matter or are unlikely except in cases not worth dealing with.
<JakeSays>
i didn't say anything about ignoring them.
<JakeSays>
i said that the exceptions that i throw (or allow to be thrown) are such that something has happened that is catastrophic.
<InPhase>
And exceptions can come from absolutely anywhere in the code. Something goes wrong with a user input and an object tries to allocate an oversized array? Exception. But the program is still not supposed to crash.
<JakeSays>
that's a poor example as that allocation should never have been done in the first place
<InPhase>
The number of possible exceptions thrown by the stdlib is pretty intense. Use a few C++ libraries and it goes up a lot.
<JakeSays>
not really.
<InPhase>
"should never have been done" does not solve the problem of responding reliably to it.
<JakeSays>
yes, it does.
<JakeSays>
the size should've been validated before the alloc ocurred
<InPhase>
"Don't do any action that will cause an exception" is not a very viable C++ design strategy.
<InPhase>
But, dealing with them at recovery points is.
<JakeSays>
it is actually.
<InPhase>
The event loop is an extremely natural recovery point, because it's literally a loop that will go back around and do the next thing after handling the failed event.
<JakeSays>
indeed
<JakeSays>
hmm. this slicer allows me to change infill on a layer by layer basis
<ccox>
This is why professional apps have multiple levels of try/catch -- some for handling simple errors (ie: file IO) close to the event, some for handing at a high level but still knowing what command is in process "the blur command failed", some around libraries that can throw exceptions across boundaries (EVIL!), and some last minute "we don't know what happened/Program Error".
<ccox>
Sadly, I have some game dev. friends who still think setjmp/longjmp are the way to handle errors (when all they do is cause more pain and slower runtimes).
<JakeSays>
lol
<InPhase>
ccox: Yeah, multi-level is the way I try to consistently do it. At location for everything recoverable at location, a little higher up for specific handling of a problem, and top level recovery points for "this can never/should never crash, do something reasonable".
<JakeSays>
InPhase: what would be considered "something reasonable"
<InPhase>
JakeSays: Log and/or notify, then for programs where possible, try to do the next thing that can be done, or be ready to receive new instructions from a user or a remote system.
<ccox>
Good approach. Though it is weird when working on another team's code to find they have different definitions of where error handling should go (one team embraced "crash often and leave a description stack crawl")
<JakeSays>
lol @ crash often
<JakeSays>
InPhase: ok yeah that's what i would consider reasonable as well
<ccox>
Yeah, I never really understood their approach. I made my code for them bulletproof, never got a bug report after 10 years.
<JakeSays>
i work on several systems that don't allow exceptions at all.
<InPhase>
I have three categories of production-level code: "This is not allowed to crash", "This should never crash or it will shame my ancestors", and "It's basically a shell script".
<ccox>
LOL!
GNUmoon has quit [Ping timeout: 276 seconds]
<JakeSays>
hmm. i like how customizable this slicer is
<JakeSays>
wish it were open source
<JakeSays>
InPhase: hey have you ever compared icesl's modeling features with openscad?
GNUmoon has joined #openscad
<InPhase>
Nope.
snakedGT has joined #openscad
snaked has quit [Ping timeout: 265 seconds]
Jack21zzz62 has quit [Ping timeout: 256 seconds]
Jack21 has joined #openscad
<Jack21>
teepee ?
Guest1627 has joined #openscad
Guest1627 has quit [Client Quit]
<Scopeuk>
teepee todays advent appears to have failed on permissions
lastrodamo has joined #openscad
<Jack21>
try to reach out for 9h now
Zauberfisch has quit [Ping timeout: 256 seconds]
Zauberfisch has joined #openscad
<Scopeuk>
he does work, and he's on CET timezon iirc so its still reasonably early
<Scopeuk>
not sure who else would have permissions to resolve it
Zauberfisch has quit [Read error: Connection reset by peer]
Zauberfisch has joined #openscad
mhroncok has joined #openscad
Buanderie has joined #openscad
<Buanderie>
hey hello :)
<Scopeuk>
Hi
<Scopeuk>
teepee day 8 appears fixed
<Jack21>
big question - by itself or did teepee fixed it
<Buanderie>
hey... I have a question. Why can't I edit the value inside this array ? https://pastebin.com/FdicptjE (on line 7)
<Buanderie>
I get "ERROR: Parser error: syntax error in file test1.scad, line 14"
<Buanderie>
thing is, I can READ the value from the array and assign it to a variable
<Buanderie>
but can't assign a value to the array ? :/
<Scopeuk>
openscad isn't procedural, unlike most common use languages things are not executed sequentially
<Scopeuk>
your example essentially tells that array value to have two different values and the parser rejects that
<Scopeuk>
what are you trying to achieve?
<Buanderie>
Scopeuk, the array is a 2d array of 3d points used for a NURBS surface... I would like to add noise to the Z values of points, to create variations
<Scopeuk>
ok I suspect that this may be best done with an array of 2d points and and array (or random function) for the 3'rd axis and then using list comprehension to build the final vector. list comprehension is not really my speciality but some of the other folks here are very good with it
<teepee>
Jack21: I did, root cause was: printf: 08: invalid octal number
<teepee>
welcome in 1980 :)
<Scopeuk>
ahh c will we ever learn
<Scopeuk>
leading 0 means octal is a "personal favourite"
<teepee>
so now I need a new way of getting the current date without leading 0
<Scopeuk>
Buanderie your other option would be something like https://pastebin.com/tRh9XKMt which is in my opinion harder to understand but does make the inputs simpler
<Scopeuk>
teepee what language?
<teepee>
bash
<teepee>
date +%e does space padding which is also not helping
<Scopeuk>
can we stick 10# on the front of the string to coerce it to decimal instead
<Buanderie>
Scopeuk, I see... might be more error-prone imo. unless there is a gap performance-wise, I will stick to the other solution I think
<Buanderie>
but thanks :)
mhroncok is now known as mhroncok|afk
<Scopeuk>
teepee date +%-e it is
<teepee>
aha, assigning to a variable strips the extra space :)
<teepee>
ah, even better
<teepee>
I did not see that, cool
<Scopeuk>
date has an alarming number of options
<Jack21>
so 07 is ok but 08 is an octal number ..
<teepee>
yep
<Jack21>
what were they thinking? ..glad you could fix it
<teepee>
well, I know that exists in C but did not expect this in shell/bash stuff
<Scopeuk>
Jack21 07 octal and 07 decimal are the same number
<teepee>
but I suppose the printf command line program literally just calls printf()
<Scopeuk>
its just 08 ocatal is invalid
<Scopeuk>
we've been working is octal up untill now
<Scopeuk>
flash backs to blackberries getting sms dates wrong because they used binary year rather than BCD year
<teepee>
yeah 8 dec = 10 oct - the leading 0 marks it as octal - well in 1980 at least ;-)
<Scopeuk>
at least we got away from first letter of variable name sets type
<Scopeuk>
C improved on Fortran, but it still has its qwirks
<teepee>
right, date +%-d works too :)
<Scopeuk>
in that regard (don't want to upset the grey beards :P)
<Scopeuk>
that syntax is quite special
<Jack21>
i still like to believe my own date format is superior to all
<teepee>
so the magic incantation now is: date +setDay.%-d,
<Scopeuk>
the months thing is becouse a coupple of egotistic romans inserted there own names into the middle
<Scopeuk>
december was month 10
* Scopeuk
googles apparently this is a bone of contention amongst people that study why the romans did things. I wonder if they ever talk to people who study why we do things now, applying logic might well be a losing battle
<Jack21>
ah yes Sylvester was that consul term start thing
<Jack21>
although the roman calendar days are so messed up
mhroncok|afk is now known as mhroncok
GNUmoon has quit [Ping timeout: 276 seconds]
GNUmoon has joined #openscad
unrust[m] has joined #openscad
pah has joined #openscad
pa has quit [Ping timeout: 265 seconds]
<unrust[m]>
Hey, I’ve been using OpenSCAD for a few years and am starting to make a small library of parts now. I was wondering if there are are plans to extend the language to make thing kind of thing easier?
<unrust[m]>
Like, adding enums for example
<unrust[m]>
Would be really useful for making eg options in modules better than “specify a string and try to match on that in the body”
<teepee>
as OpenSCAD has no user types how would that work?
<teepee>
the bigger plan is more in direction of objects/structures
<teepee>
well, "plan", there's just some people doing stuff, not a project plan in the classic sense
<unrust[m]>
Well that’s what I mean, the ability to add user types
<teepee>
If you have a nice idea how to handle the enum case that could happen too :)
<unrust[m]>
I have done some PL dev in the past, so was wondering if it would be a welcome addition :)
<teepee>
my view on that is that it would be nice to have, *if* it can be added in a way that does not break every single existing script
<unrust[m]>
Yeah, of course. Can you point me in the direction of the existing struct/object work?
<unrust[m]>
Trying to get a sense of where things are at as of now