<J1A84>
i thought about a hex grid mesh and then remove rand hex maybe created with recursion so longer paths emerge .. but that result was already ok
juri_ has quit [Ping timeout: 268 seconds]
juri_ has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
<peepsalot>
hmm, i'm getting a weird semi-reproducable segfault from a specific piece of code, just having it in the editor and commenting out part of it
<peepsalot>
yeah i was just about to link that, hehe
<InPhase>
I knew this was familiar.
<peepsalot>
but this is a bit different
<InPhase>
I would hope, given that it was "fixed". But maybe not fully.
<peepsalot>
its just that this time requires no preview and is nondeterministic
<InPhase>
Brain storming, we also have some GSoC-originating code that does some manual parsing to support some features like the scrolling up and down of integers and floats...
<InPhase>
Might it have to do with "no-ops" you were also doing like scrolling?
<InPhase>
I wouldn't be shocked if a crash bug got left in that by accident.
<peepsalot>
i don't think I did any scrolling specifically
<peepsalot>
the snippet is short enough that it fits in one screen
<InPhase>
I'm not able to create the crash from that example, but I might not be waving the dead chicken quite right.
<peepsalot>
maybe try backspacing on the comment closing and rewriting it once or twice, pause a second between characters, something like that
<peepsalot>
this is specifically for 2021.01 release and nightly, on Linux Mint 22. i also tried my own debug build which was much harder to reproduce on
<InPhase>
Oh, I was doing my own build.
<InPhase>
Although a release build.
<InPhase>
And I tried those extra steps, but no crash.
<InPhase>
Should I preview first?
<peepsalot>
nope
<InPhase>
So just those 6 lines, a blank space on 7, and then /**/ typed slowly?
<InPhase>
s/blank space/blank line/
<peepsalot>
no, copy the whole ECHO parts too. and wrap those in block comment
<InPhase>
Oh.
<InPhase>
Well that's different. I will try.
<InPhase>
Open /* right to the left of E in ECHO, and */ touching the 6 in the last value?
<InPhase>
I have added and removed the last / slowly many times, and 50+ times rapidly.
<InPhase>
I'm testing on the 2021.01 release now.
<InPhase>
Not sure how differently I could poke it.
<InPhase>
I guess I'm happy it doesn't crash, but that doesn't solve the problem. :)
<InPhase>
I do see elements in that comment that could be hit by either our customizer parser or the float change parser if these ran, but they shouldn't be running in this usage.
<InPhase>
The editor is docked normally, and "docking in different places" is turned off.
<InPhase>
No other settings strike me as possibly relevant. Let me know if there's anything else I can test.
<InPhase>
Ubuntu 22.04, but running as OpenSCAD-2021.01-x86_64.AppImage
<peepsalot>
idk, i keep reproducing with slightly different actions before it actually happens. i just set my settings to match yours and reproduced again
<peepsalot>
there were only a couple minor differences to begin with
<peepsalot>
i'm gonna reboot to just rule out that my computer is in some insane state
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #openscad
<teepee>
I don't think I've seen crashes lately, only that annoying effect where it deletes selected text on keypress of some modifier like shift or control
<InPhase>
I typically unhide the editor only when someone reports a bug.
<InPhase>
But I will keep monitoring for bugs in automatic reload and preview. :)
<teepee>
ah, yes. good :)
<teepee>
I'm not using that normally
<peepsalot>
this is definitely the weirdest crash i've encountered. i got it to crash once after rebooting, but it definitely took a lot longer with a bunch of random inputs
<peepsalot>
i wonder if it is something WM specific, being on Cinnamon, and just recently upgrading to Mint 22 a few days ago
<InPhase>
peepsalot: xfce here
<InPhase>
I don't see how it could be. But it could be.
<InPhase>
After those wacky Mint font issues some time back, I'm always open to that narrative.
<InPhase>
peepsalot: Maybe I should port my segfault-handler stack trace output routines over to OpenSCAD. Maybe we'd get lucky.
<InPhase>
Because yes, you can do that. It even actually works a majority of the time.
<InPhase>
Oh! In the middle: 0x00007ffff4a30d7c in malloc_printerr (str=str@entry=0x7ffff4b69764 "free(): invalid pointer") at ./malloc/malloc.c:5664
<InPhase>
So that's probably in fact the same bug.
<InPhase>
Two bits pointing to dangling pointer in a QWidget.
<InPhase>
Was this your release compile of 2021.01, or the AppImage of it?
<peepsalot>
its the install from ubuntu repos
<InPhase>
Two logical steps are to see if you can reproduce with the AppImage to match what I did, and to see if it still happens without that theme. Maybe in that order.
<JordanBrown>
The git://github.com/openscad/openscad.git URL isn't working, says connection timed out. https://github.com/openscad/openscad.git is working. I don't know what the git: scheme does; maybe it's not encrypted and authenticated and they decided to move to https only.
<InPhase>
JordanBrown: git: does ssh
<JordanBrown>
fatal: unable to connect to github.com:
<JordanBrown>
github.com[0: 192.30.255.112]: errno=Connection timed out
<JordanBrown>
:-(
<JordanBrown>
Like I said, https:// works, but means I should maybe update the Windows build instructions.
<InPhase>
JordanBrown: "git clone git@github.com:openscad/openscad.git deletemegit" This has worked correctly for me.
<peepsalot>
InPhase: AppImage seems to override Qt theme anyways
<InPhase>
JordanBrown: That's the standard notation.
<InPhase>
JordanBrown: If the instructions don't match that, you can update them to that for people with github accounts, or https for people without github accounts.
<InPhase>
The git@ will only work once you have setup a github key, which is perhaps only half of the people who might be following build instructions.
<JordanBrown>
Right. Not, at the moment, including me :-)
<InPhase>
What instruction set were you following?
<InPhase>
My eyes would have glazed over those if I ever saw them.
<JordanBrown>
I don't know where I got the git:// URL when I updated the Windows page. It was probably what was there before. And yes, github itself advertises the https:// URL.
<JordanBrown>
Already tested, https:// works.
<JordanBrown>
Did anybody ever file an issue about the performance problems with ASCII STL export?
<JordanBrown>
I don't immediately find one, and I want to get rid of the temporary tweaks I made to investigate it.
<teepee>
ah, nice, tests green. I'm not a huge fan of the name of the parameter, but if that's the outcome of the long discussion that's fine
<JordanBrown>
Seems to be the least bad answer that anybody has come up with.
<teepee>
I should go through the discussion again but in general I don't expect any blockers
<JordanBrown>
What's annoying is that IMHO cap-height is the most obvious height metric, at least for European languages, but isn't the standard way to represent it and the current "size=" only accidentally approximates it.
<teepee>
probably not going to be today, not sure I can collect enough brain to do that. not actually stressful but we did some production rollout at work where we got time window of 0 - 7 am sunday and random meetings afterwards
<teepee>
so I'm not really tired but not that much awake either ;-)
<JordanBrown>
No real hurry - it's just been waiting for a while and so wanted to nudge.
<teepee>
that's good, it helps :)
<JordanBrown>
Thanks.
<teepee>
I guess size= is more like "sort-of useful but not really typographic"
<teepee>
so I tend to think we'll keep both "forever"
<teepee>
unless someone brings up more / better info
<JordanBrown>
And it's upsetting that it's only accidentally useful.
<JordanBrown>
It's a total coincidence that two errors roughly canceled each other out.
<teepee>
well, I suppose it's not that accidentally useful, it's just that due to that intention the problematic did not appear
<JordanBrown>
But we're stuck with it; introducing a ~30% change in text size is a non-starter for compatibility.
Colere has quit [Ping timeout: 268 seconds]
<JordanBrown>
There were two errors, and they canceled out such that the result was more or less useful.
<teepee>
yes, and probably not even worth deprecating it
Colere has joined #openscad
<JordanBrown>
I think I'd put more words in the docs to explain what the two variations mean, and perhaps explicitly mention the fact that "size" isn't right.
<teepee>
yep, there's a clip in penguins of madagascar describing that well ;-)
Furor has joined #openscad
<JordanBrown>
huh? they talk about typography?
<teepee>
not specifically
<teepee>
but it's a bit like math teacher giving a bad mark for producing the correct result but not the full calculation
<JordanBrown>
Luke: I can't. It's too big.
<JordanBrown>
Yoda: Size matters not. Look at me. Judge me by my size, do you? Hmm? Hmm.
Colere has quit [Ping timeout: 268 seconds]
<JordanBrown>
I'd say that it's producing the correct result using the incorrect calculation.
<JordanBrown>
For a fuzzy definition of "correct result".
<J1A84>
my Text module has "hp" and "cap" size via textmetrics but not sure if i ever use them .. cap might be nice for capital letters only but it is still smaller than an "O"
<JordanBrown>
Which textmetric values did you use to get cap height?
<J1A84>
typography is just so weird and voll of ancient ballast
<JordanBrown>
Yes.
<J1A84>
cap height callculates by "HTAME" letters
<JordanBrown>
We, or at least I, think that it should be rigid and mathematical, but really it's art.
<J1A84>
first i wondered that O or Q are bigger than cap height but all rounded Letters need this to look equal - and the definition of cap height is like "M"
<J1A84>
that is where "hp" comes in - which is the max height of Letters
<JordanBrown>
Especially the inset on the right starting "Typefaces are born from the struggle between rules and results".
<J1A84>
i mean you already get this "baseline" which doesn't let you center letters
<J1A84>
or why centered "Tp" looks different to centered "T" "p"
<JordanBrown>
Yeah, but once you're talking about centering you probably need to be looking at the specific characters involved, and then looking at the bounding box, rather than trying to deduce an answer from font metrics.
<JordanBrown>
If you don't have any descenders, you probably don't want to include them in your centering calculation.
Furor is now known as Colere
<J1A84>
it is what the text() does when valign="center" it is not the center of a boundingbox (Em) but from the actual letters
<JordanBrown>
Even if you *do* have descenders, you might not want to include them - I expect that if you include descenders in your centering calculation, but you only have a few relative to the rest of the text, it will look more "right" if you don't include them.
<JordanBrown>
It centers based on the bounding box of the actual text.
<J1A84>
If you make Name tags with valign center - the all end up differently depending on the names
<JordanBrown>
But that's why textmetrics() and fontmetrics() try to tell you everything you might want to know, so that you can choose your own definitions for what "centered" means.
<J1A84>
so if you are not willing to study this . .just leave 20% above and below and use baseline and it should be fine
<JordanBrown>
Yes, I think that centering the capital letters and letting descenders go "too low" is probably the rightest answer.
<J1A84>
font metrics is very strange as it extends far beyond A-Z a-z 0-9 so you end up with very big spaces ..
<JordanBrown>
Yes. But it's what the font says...
<J1A84>
sure like the man in the balloon and the microsoft manager .. the answer is technical correct but no use at all Ü
<JordanBrown>
Yes.
<InPhase>
peepsalot: That particular design is one of the ones that triggers this stupid little bonus popup. I don't know why, but that has been happening on some things for a while now, and I do not understand the pattern: https://i.imgur.com/pOyF83Y.png
<InPhase>
peepsalot: That's with my personal master release build.
<InPhase>
I hadn't reported it as I don't have any actionable information other than "this happens sometimes".
<peepsalot>
InPhase: something related to font cache rebuilding? somehow I don't think I ever see it, but that's the main popup i've heard of
<JordanBrown>
J1A84: I'm happy to add additional metrics, if they are available from the font or from the processing of the actual text. I reported almost everything that seemed to be available. The PR discussed above, as a bonus, adds underline position and size.
<peepsalot>
does it freeze like that? or you can close the popup and continue?
<InPhase>
Nope, it works fine. I close and continue.
<peepsalot>
but there's no text displayed inside it?
<InPhase>
Not that I can see.
<peepsalot>
can you focus on the popup and try ctrl-c, i think that sometimes will copy the entire contents (or is that a Windows feature i'm thinking of?)
<InPhase>
It's a window that doesn't update itself.
<J1A84>
JordanBrown i think the "hp" size would be the only usefull thing as you get the real size of Text
<InPhase>
Like if I try to enlarge it, it just picks up stuff behind it.
<InPhase>
So I think it's some sort of orphaned widget or something.
<JordanBrown>
J1A84: what is "hp" size?
<JordanBrown>
Top of h to bottom of p?
<InPhase>
peepsalot: I'm getting this on console at the same time: https://bpa.st/WVAA
<InPhase>
peepsalot: But I am getting that now from master even if that doesn't pop up.
<J1A84>
JordanBrown yes it is a real thing in typography
<InPhase>
I don't know why for that either. :) I don't know if these are related, or if they're related to your other Qt weirdness. Could all be 3 separate things, could be symptoms of one thing.
<peepsalot>
so it sounds like our Qt code is just FUBAR
<InPhase>
lol
<InPhase>
I agree negative sizes are not possible. I wish Qt wouldn't even USE signed types so such nonsense isn't possible.
<Friithian>
I know of some people who are… oddly against non-signed types
<Friithian>
no no they're from #c++-general, InPhase you may remember one of those… arguments?
<InPhase>
peepsalot: We only call setMinimumSize manually twice in the code, both in QWordSearchField.cc
<JordanBrown>
J1A84: yeah, I just found that one, after wading through stuff about Hewlett-Packard.
<JordanBrown>
"Conclusion: We know that we know nothing."
<InPhase>
Friithian: Yes, I've engaged repeatedly with such people. The arguments for signed sizes do not hold water.
<Friithian>
I still dont understand those people
<InPhase>
Friithian: If you start with the assumption that all inputs to functions should have well-defined behavior, the next logical conclusion is to do whatever you can with types to reduce the number of errors you need to handle and respond to. It's pretty simple.
<Friithian>
yup
<J1A84>
JordanBrown a "hp" square always fit exactly the text independent from font/design so from a technical point this is what you want today.
<J1A84>
but sure webdings or fullblocks etc will not fit in there
<InPhase>
Friithian: Unfortunately we lose a lot of C++ developers out there on "all inputs to funtions should have well-defined behavior". They do not want to write robust code, and do not value it or understand its merit. They think they will get to this state by just running some tests rather than engineered design, they observe the repeated failures, and they don't put the two things together as causal.
<JordanBrown>
J1A84: But I don't think the hp size is available from the font, and I'm not going to go measuring things in case somebody wants them. You can use textmetrics("hp") to measure it.
<JordanBrown>
InPhase: yes, many people do not understand the value of strong typing.
<Friithian>
funny thing is, I think one of the first things you should learn while programming is taking user input which inherently requires a lot of checking and safety
<JordanBrown>
I'm not a C++ guy, but one consideration is that C has some truly obnoxious behavior when you might signed and unsigned values.
<JordanBrown>
s/might/mix/
<J1A84>
probably also just for latin not asian glyphs but in case you write text or logos ..
<InPhase>
Some 90% of crashes and security issues in modern code would not happen if C and C++ programmers adopted this philosophy in all the upstream libraries and application code.
<InPhase>
JordanBrown: It's pretty easy to avoid by not mixing them. The solution is not to make everything signed. The solution is to make things their proper type.
<JordanBrown>
The ripple effects can be ugly.
<InPhase>
I often keep on warnings for mixing signed and unsigned. These exist, and then you get used to it.
<JordanBrown>
Especially for established programs.
<JordanBrown>
Yeah, I've tried turning all of those warnings on and then cleaning them up. It can be pretty overwhelming.
<InPhase>
But I don't trip them up too often, because I make things the type they are. Sizes are unsigned, and so are indices. Then you just stick with that. Comparing an index to a size? Not a problem, you defined them the same.
<JordanBrown>
Quick: what's the result of 1U > -1?
<Friithian>
-Wall -Wextra -pedantic -Werror is fun
<InPhase>
It's not for (int i=0; ...) it's for (size_t i=0; ...)
<Friithian>
InPhase: for(auto &i: …) :D
<InPhase>
Friithian: That will give you int.
<Friithian>
:, not ;
<InPhase>
Oh, :, well then e. :)
<InPhase>
But most often I need indices for numerical work. But size_t indexing works very well, and you don't hit stupid bugs after 2 billion elements.
<InPhase>
Every time I see an int index I cringe a little.
<Friithian>
I've been told off for using the correct type in a for loop
<JordanBrown>
In my professional life (Oracle Solaris development) we turn on as many warnings as we can stand, and have a group actively developing static analysis tools. But alas we have staff-millenia of legacy.
<InPhase>
Yeah, I start with -Wall -Wextra -Werror, and turn off a few stupid ones.
<JordanBrown>
millennia
<InPhase>
-pedantic doesn't usually help me out.
<Friithian>
-pedantic is more for being standard rather than for stuff working correctly
<InPhase>
This is my current standard working set: -Wall -Wextra -Wno-error=unused -Wno-error=unused-but-set-variable -Wno-error=unused-variable -Wno-unused-parameter -Wnull-dereference -Werror
<Friithian>
what, you don't like your compiler screaming at you because you create a variable but haven't used it becaues you haven't gotten there yet :D
<InPhase>
Unused variables are usually me being halfway through an implementation, and I don't want that erroring out. Unused parameters are usually me standardizing an interface, and is not an error for me.
<InPhase>
-Wnull-dereference should absolutely be an error... I can't imagine why you wouldn't want it.
<InPhase>
Most it will miss, but if the compiler can find one, then you've really screwed up.
<JordanBrown>
https://labs.oracle.com/pls/apex/f?p=94065:12:111044413911706:245 is our high-end analyzer, finds all kinds of null-deference and out-of-bounds errors. But alas while it appears that we have published papers on it, it does not appear to be available externally.
<J1A84>
funny the square and circle example is not working for me .. guess i am using too much scad so my vision/perception is trained to see equal objects
<J1A84>
fun starts if you add a triangle that doesn't fit into the raster
<InPhase>
Looks like that patent will finally be expiring in 2 years. (I never got any royalties from it anyway.)
<InPhase>
Mostly that method was used by a company contracting my old employer, paying them a bunch of money to analyze their code and the upstream libraries it depends upon, and then giving them a report of where all the weak spots are that are likely to indicate problems. It also demonstrates how to wrap the internal weak spots for hardening without a rewrite.
<InPhase>
But, you can also just take the philosophy to heart and write code with that in mind in the first place. But few people want to do it.
<Scopeuk>
High integrity code takes much longer to write and validate
* Scopeuk
has done a lot of avionics work, Swiss cheese theory all over
<Scopeuk>
multiple layers of design, strict coding standards with static and dynamic analysis (generated at low level test), testing of all levels of design/requirement from unit through to full system integration, everything with peer review
<Scopeuk>
and hard requirement decomposition traceability from top level right down to implementing function(s)
<Scopeuk>
its expensive, its slow but its pretty dependable
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
snakedGT has quit [Ping timeout: 244 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
snakedGT has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
snakedGT has quit [Ping timeout: 255 seconds]
snakedGT has joined #openscad
califax has quit [Ping timeout: 268 seconds]
califax has joined #openscad
<JordanBrown>
InPhase: interesting stuff.
<JordanBrown>
I read once that the Shuttle on-board computer system was about 3M lines and had about 300 bugs found after release, a rate of one bug per 10K lines. That's very good. But it was also expensive; it cost $3B and so cost $1K per line.
<JordanBrown>
(Not making any particular point, just an interesting statistic related to the "high quality software" topic.)
<Scopeuk>
JordanBrown a rought order of magnitude was about 10k to fix a single line bug that escaped through full lifecycle for the avionics stuff I worked on
<Scopeuk>
Most stuff was found during one of the levels of testing, and most stuff that's found is so minor no one would ever notice
<JordanBrown>
I believe it.
snakedGT has quit [Ping timeout: 268 seconds]
snakedGT has joined #openscad
<InPhase>
Scopeuk: At $10k to fix a single line bug, $1k to write them reliably is a bargain. (Although these are not inflation matched numbers.)
<InPhase>
A good process following good principles, good architectures, and good modern thinking in general when done by properly experienced people can really drive those costs down. But even after it all, reliability really is capped by the amount of programmer time that one is willing to invest in a project.
<InPhase>
I'm pretty convinced by now that a team of more expensive skilled senior-level experts costs much less per line of reliable code than a much larger team with more junior programmers. Process cannot patch up certain things without a ton of extra work. Boeing really demonstrated that one on its Max fiasco.
<JordanBrown>
InPhase: Yes. Unfortunately, it's hard to get senior-level people without having junior-level people first.
<InPhase>
Yeah, somebody has to train them. :) I do my best at work to train my people.
<JordanBrown>
I enjoy writing JavaScript and, to a lesser extent, Python, but I shudder to think that people are using them for large-scale development because they are so resistant to static analysis.
snakedGT has quit [Ping timeout: 244 seconds]
<InPhase>
Yeah. :)
<Scopeuk>
Max was a process fail too
<Scopeuk>
The safety case was not revisited for a control authority change
<Scopeuk>
But I do agree a more "expensive" experienced team is frequently cheaper and faster over full project
JordanBrown_ has joined #openscad
JordanBrown has quit [Ping timeout: 268 seconds]
snakedGT has joined #openscad
<JordanBrown_>
In C++, is it generally legal to make a copy of an iterator and then refer to it later, to "save your place" in an iteration?
<InPhase>
Sure, as long as you are mindful of the MANY operations that invalidate iterators.
<JordanBrown_>
In C, an iterator is not-unlikely to be a pointer to the structure that actually has the iteration state, and so saving and reusing the pointer doesn't work. But that doesn't seem to be the case for C++.
<InPhase>
I can take a look later. Need to make the kids some dinner. Perhaps you can point me to the location for when I get back.
<linext>
hey teepee, can you show me how to you connect to IRC? i want to keep my hostname/IP address separate
<linext>
when i tried to use VPN, it says i need to specify my email, which is not what i want to make public