<teepee>
peeps[win]: ok, I've updated MXE so we get latest official boost and also updated double-conversion
<teepee>
oh, and CGAL-5.4
ur5us has joined #openscad
<peeps[zen]>
cool. is there something special about latest boost?
<teepee>
nope, not that I know of
<teepee>
just no need for a custom boost-1.77 anymore
<teepee>
they did ship a very old version last time MXE was upgrade
<teepee>
d
<teepee>
well, there is something special going on :)
<teepee>
as far as I heard, they are moving to cmake
<peeps[zen]>
ah, nice
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
snakedGT has quit [Ping timeout: 240 seconds]
snakedGT has joined #openscad
<teepee>
oh, oops, no gcc11 plugin anymore
<teepee>
that probably means gcc11 is the default now
lastrodamo has quit [Quit: Leaving]
<teepee>
lets see if that maybe also fixes the win7 issue, the compiler uses --with-default-win32-winnt=0x0600 which in theory should be Vista
snakedGT has quit [Ping timeout: 240 seconds]
snakedGT has joined #openscad
<linext>
i did a openscad video demo remotely using a screen share this morning for about 90 minutes
<teepee>
cool, introduction or advanced use?
J225 has joined #openscad
<linext>
mainly basic with some intermediate features
<linext>
the guy tried to start the project himself and had about 8 lines written
<linext>
cube, cylinder, difference, hull, module, translate, rotate, text, linear_extrude were used
<linext>
ended up being about 50 lines of code
<teepee>
sounds like a good start
<linext>
also color, #, and % were used to see through the parts
<linext>
a question i got a couple times was, how can i be sure the hollow part is exactly X millimeters?
<linext>
my answer was to make a ruler using a cube, or import into netfabb basic
J22 has quit [Ping timeout: 256 seconds]
<teepee>
yeah, the measure topic would be great to be solved
<linext>
also it was a little confusing that text() renders 3d in preview but fails to render in final
<linext>
i had to lookup linear_extrude to explain why
<J225>
all 2D will look 3D in preview
<J225>
a way to ensure a void is x mm is to make a difference with an object that is x mm .. color that object red and you will see red everywhere it removes something
<linext>
i'm getting so bored
<peeps[zen]>
i got a list of about 628 things you could do :P
<teepee>
well, it's basically VNC into on docker and openscad running in a second one, on the local net just some testing it was pretty good
<teepee>
but then that's similar to the setup I'm using for 2 years now at work :)
<peeps[zen]>
btw i've noticed an odd delay in opening the GUI on windows. between selecting a file or "new" from the splash screen, to the main window displaying, there's like 10s of nothing
<teepee>
I can't even start my windows VM currently, I had to reset the bios of the desktop pc I'm using for docker and VMs and that seems to has disabled virtualization support
<teepee>
hmm, I've seen that delay at some point on Linux, but that went away after a reboot
<teepee>
could that be some network drive not being connected?
<peeps[zen]>
no, i don't mess with network drives on that machine
<teepee>
the only other thing that comes to mind would be the font-cache but that should not happen without some file loaded
<teepee>
and also show that info dialog
<teepee>
o_O
<teepee>
just looked into the cgal 5.4 release notes a bit closer
<teepee>
"The kernel providing exact constructions and exact predicates (CGAL::Exact_predicates_exact_constructions_kernel) is now thread-safe. See changes in 2D and 3D Linear Geometry Kernel for more details."
<teepee>
Epeck is the one we are using, no?
<teepee>
heh, in the detail section, there's quite some limits to what actually is thread-safe
<peeps[zen]>
i think we use Epick actually for most of it?
<teepee>
I think that reference was just removed in the latest PR :)
<teepee>
ah, yes, the removed line has Epeck
<teepee>
so why are they working on the wrong kernel?
<peeps[zen]>
the Epeck mentioned there is for 2D, and I don't even think its used anywhere in code
PovilasCNC has joined #openscad
<InPhase>
peeps[zen]: So in that time window between selecting a file and app.exec() we have hidapi, spnav, joystick, qgamepad, and dbus. My money is on dbus, because I've seen it lag for 10 seconds or so from initialization failures in other programs before.
<teepee>
there should be no dbus on windows
<InPhase>
Did anybody tell cmake that?
<peeps[zen]>
oh, i didn't think about controllers. i might have been charging a wireless/USB gamepad over USB at the time... i would go test again, but there is a cat in my lap
<teepee>
I think there's no dbus support in Qt
<teepee>
that's fine, cats always have priority :)
<InPhase>
teepee: It seems dbus in Qt has worked in Windows for some time now.
<InPhase>
Although I don't know if it's turned on or off in various Qt builds peeps[zen] might be using.
<teepee>
oh? interesting, then disabling that would be a good test too
<InPhase>
But he probably doesn't have a dbus server. Which is precisely the sort of thing that sometimes makes it sit around and wait forever.
<teepee>
who's shipping that server? WSL?
<InPhase>
I remember these issues on Linux from before dbus stabilized there.
<teepee>
cool, remote control interface solved then :)
<peeps[zen]>
KDE is on windows?
<InPhase>
KDE apps, probably moreso than the entire environment.
<InPhase>
There are a whole 15 people in #kde-windows on here. :)
<peeps[zen]>
so qt and gtk apps then...
othx has quit [Ping timeout: 256 seconds]
othx has joined #openscad
<peeps[zen]>
am I just being pedantic?
RichardP_ has quit [*.net *.split]
ToAruShiroiNeko has quit [*.net *.split]
drfff has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
JakeSays has quit [*.net *.split]
ccox has quit [*.net *.split]
Joel has quit [*.net *.split]
cbmuser_ has quit [*.net *.split]
sinned6915 has quit [*.net *.split]
Scopeuk has quit [*.net *.split]
peeps[zen] has quit [*.net *.split]
juri_ has quit [*.net *.split]
muesli has quit [*.net *.split]
noonien has quit [*.net *.split]
Virindi has quit [*.net *.split]
ToAruShiroiNeko has joined #openscad
ccox has joined #openscad
RichardP_ has joined #openscad
sinned6915 has joined #openscad
cbmuser_ has joined #openscad
drfff has joined #openscad
Scopeuk has joined #openscad
peeps[zen] has joined #openscad
Joel has joined #openscad
JakeSays has joined #openscad
TheCoffeMaker has joined #openscad
juri_ has joined #openscad
noonien has joined #openscad
muesli has joined #openscad
Virindi has joined #openscad
foul_owl has quit [Ping timeout: 256 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
foul_owl has joined #openscad
<Scopeuk>
I'm not trying to remember if KDE's cross target notifications system was dbus underneath. it was definitely network aware. I did last use that when I was in school though. which is erm... not recent
<Scopeuk>
s/not/now
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openscad
<Scopeuk>
hmm actually it must have carried through to my university days because I had my laptop. enough reminiscing
lastrodamo has joined #openscad
walterwhip has joined #openscad
drkow has joined #openscad
drfff has quit [Ping timeout: 256 seconds]
walterwhip has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
GNUmoon has quit [Ping timeout: 276 seconds]
walterwhip has joined #openscad
walterwhip has quit [Client Quit]
CB82 has joined #openscad
CB82 has quit [Client Quit]
CB78 has joined #openscad
CB78 has quit [Ping timeout: 256 seconds]
GNUmoon has joined #openscad
<JakeSays>
so isn't 'each' a thing in oscad?
<JakeSays>
ah. docs on it are hard to find
califax has quit [Ping timeout: 276 seconds]
califax has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
PovilasCNC has quit [Read error: Connection reset by peer]
<Scopeuk>
JakeSays sounds like you found it but you can do vectorVar = [0,1,3,5]; for (i = vectorVar ){ echo(i); }
<peeps[zen]>
that page was the 2nd google result for: openscad each
<Scopeuk>
at some point I will hand some mind share to learning and understanding the list comprehension stuff
<Scopeuk>
today is not that day
<peeps[zen]>
[1,2,3,4,5] == [1, each [2,3,4], 5]
<InPhase>
Scopeuk: The list comprehensions are actually super simple. Just a for loop inside brackets where the thing after the for() determines each element in the list.
<InPhase>
The fancy comprehensions have a long let with comma separated assignments, evaluated in sequence. At that point you're doing imperative programming along the list of let assignments, and a wise implementer breaks those out one on each line and treats it like an imperative procedure bundled inside let. Then you close the let and put the result for each element. So sometimes they look massively
<InPhase>
complicated, but that's about all there is to them.
<InPhase>
The only real difference between a let list and normal imperative programming is that you can only assign each value once, but that's not really a limiting thing.
<InPhase>
each variable name, I mean
<InPhase>
If I run out of useful names, I usually just do something like r1 = .... , r2 = ..... , r3 = ....
snakedGT has quit [Ping timeout: 240 seconds]
snakedGT has joined #openscad
<J225>
and end up with r31 and r32 and each is a list of 6 variables .. and then your variable is a list of list of list and ...
<InPhase>
This is why the supreme overlords gave us C style list comprehensions and recursive functions. :)
califax has quit [Remote host closed the connection]
califax has joined #openscad
<teepee>
meh, and we should eventually fix c-style list comprehensions
<teepee>
can we agree that this annyoing warning issue is actually never going to cause a problem?
<peeps[zen]>
which warning?
<peeps[zen]>
still without knowing the question, i'm guessing the answer is: yes except for nophead
<teepee>
and peeps[zen] even suggested a language extension for it :)
<InPhase>
I don't understand. It IS doing it C style, right?
<InPhase>
If I wrote that in C I would get the same output.
<teepee>
the output is not the problem
<teepee>
I don't have good words for the issue, with strict indexing it's fine, e.g. l = [1, 2, 3]; echo([for (a = 0;a < len(l);a = a + 1) l[a] ]);
<teepee>
but going through lists, it's often tricky to prevent out of bounds access without putting undef or length checks everywhere
<InPhase>
Ah, that.
<InPhase>
Well this is mostly just a problem because we want to abuse the C-style for loops to do more than a for loop should.
<InPhase>
So it's not appropriate to try to change the for loop to support more abuse. There should be other ways that actually make sense for doing that sort of thing, outside of the loop. :)
<peeps[zen]>
the problem with C style loops is that often you want to do something at the end (post-loop) with a variable that was calculated within the loop. but since we aren't C, there's no way to access anything from a post-loop statement
<InPhase>
What is being desired here in peeps[zen]'s sum example, is not really a list comprehension. It wants a final result.
<peeps[zen]>
...or at least that's my interpretation of the issue
<InPhase>
In fact he's adding extra abuse with that if check to explicitly throw out most of the list and take only the one element. And, I've done this abuse too, but it's clearly not the right language structure for supporting this type of thing.
<InPhase>
It explicitly should not be a list comprehension.
<InPhase>
For clever hacks at implementation time, yes we do this. But at language design time we should think better about sensible structures for a use case I think.
<peeps[zen]>
i don't think its an abuse. what if instead of a final sum, you wanted a running sum. is it still an abuse to try to use a loop for that?
<teepee>
I think the "finally" is an extra topic, and maybe a useful extension
<teepee>
I think the simpler issue is that we calculate the next value before the condition
<teepee>
so it's calculated, gives a warning but is not used then as the break condition triggers
<teepee>
what the first example of the comment from peeps[zen] shows
<teepee>
echo(sum([1,2,3]));
<teepee>
function sum(x) = [for(i=0, s = x[0]; i<len(x);i=i+1, s=s+x[i]) s];
<teepee>
slightly simplified
<teepee>
this gives the undefined warning as it does s = s + x[3]
<teepee>
but that s is never used, due to 3 < len(x) breaking the recursion
<InPhase>
Well it's supposed to be calculated. The flaw is that we're putting s = s+x[i] inside the for loop when it's not the iterator, it's imperative iterative content that belongs outside of the loop.
<InPhase>
sumf_what_the_masses_want seems to be the recursive function behavior that people want out of something like sum_couldwork
<InPhase>
Although I have a side question... I have two redundant let statements I had to put there in the recursive function, and I do not understand why it fails if I remove the second one... Shouldn't that first let statement carry into the context at which the s is evaluated?
<InPhase>
Oof, my bad. :) I stared at that for a while, and I just had a typo.
<InPhase>
I got fooled by the bad set of test numbers.
<InPhase>
Naturally I then see it clearly 5 seconds after asking.
<teepee>
I think I need to finish my coffee before looking closer :)
<teepee>
just mailing with Keith about a shared GSOC project adding some stuff to support the FreeCAD importer
snakedGT has quit [Ping timeout: 240 seconds]
snakedGT has joined #openscad
<peeps[zen]>
i just don't think that making loops a warning-exempt zone is a good idea, nor am I sure how that would even work without completely rolling back the undefined operation warnings in general
<peeps[zen]>
so my proposed solution is that:
<peeps[zen]>
1) any loop "counter" should be always reassigned/incremented *after* any values which depend on it. This is up to the script author to enforce upon themselves.
<peeps[zen]>
AND 2) A "finally" clause would allow the (optional) usage of the last iteration's calculations.
<peeps[zen]>
i really don't see any other way around it other than to declare c-style loops an abomination and deprecate/remove them
<linext>
anyone want to collaborate on a design?
J225 has quit [Quit: Client closed]
J225 has joined #openscad
<peeps[zen]>
would it make sense to change loop behavior so that e.g. this running sum example would re-assign "a" recursively and give the intended result? function rsum(v) = let(a=0) [for(x=v) let(a=a+x) a ]; echo(rsum([1,2,3,4,5]));
linext has quit [Quit: Leaving]
linext has joined #openscad
<peeps[zen]>
i guess that might break a ton of scripts though, i don't know. i actually thought it might work that way already, but it doesn't. neither does using "$a" instead of "a"
<teepee>
I'm a bit confused about that mail though, I got 2 mails yesterday and both seemed to be via github
<InPhase>
if (triangle_count > 4294967295)
<teepee>
but only one of them shows up in the github issue, the other one only in my inbox
J225 has quit [Quit: Client closed]
<InPhase>
So some compiler is mapping that to a signed integer??
J225 has joined #openscad
<InPhase>
I shall consult the standard.
<teepee>
quote> While picking through the source, I also noticed [src/export_stl.cc: if (triangle_count > 4294967295)] comparison is _always_ false due to the limited range of triangle_count in 32bit architecture. I believe there are several places in openscad
<teepee>
where 64bit integers are assumed implicitly.
<teepee>
which did surprise me actually as I a) thought the size is not different for those and b) would have hoped one of the static code analysis would tell about it
<InPhase>
Oh, always false.
<teepee>
I might be wrong and maybe the analyzers complain somewhere where it's not obvious :)
<InPhase>
Ah, because of size_t shrinking.
<teepee>
so size_t is different?
<InPhase>
Yeah.
<InPhase>
It's been like 10-15 years since I did any 32-bit code so that didn't even cross my mind.
J22529 has joined #openscad
<InPhase>
This should be a uint64_t then.
<teepee>
yeah, I did not consider that before either. I sort-of assumed he's right with his comment
<InPhase>
Is that in an issue somewhere?
<InPhase>
Trivial fix. I'll leave myself a note to PR that tonight.
<InPhase>
So it will never happen on 32-bit runs anyway, because the OpenSCAD process is not allowed to have enough memory to create that many triangles in the first place.
<InPhase>
So it's a bug that's specifically impossible to trigger. :)
<InPhase>
But I will fix it anyway.
J225 has quit [Ping timeout: 256 seconds]
<teepee>
:)
<teepee>
impossible bug
<InPhase>
size_t is definitionally required to cover the scope of memory that can be allocated, so it's not even a platform-specific limit, but mandated by the language specification that it never trigger.
<InPhase>
(Unless I've misread some small detail.)
<Scopeuk>
hmm I wonder if any of the weird 64 on 32 memmory access stuff could make an edge case
<Scopeuk>
although that works with memory paging as far as I'm aware
snakedGT has quit [Ping timeout: 256 seconds]
snakedGT has joined #openscad
aiyion has quit [Remote host closed the connection]