TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
rawgreaze has quit [Client Quit]
ur5us has quit [Ping timeout: 244 seconds]
rawgreaze has joined #openscad
rawgreaze has quit [Client Quit]
<JordanBrown[m]>
Does anybody happen to know why OpenSCAD uses boost::program_options instead of QCommandLineParser? The reason that I ask is that QApplication() appears to do the right thing to retrieve non-ASCII command line arguments (at least on Windows), and it integrates better with QCommandLineParser.
epony has quit [Ping timeout: 252 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
ur5us has joined #openscad
<JordanBrown[m]>
QString to go to the rest of the program - and that copy back into QString could use fromUtf8 because we knew that they were already translated. (It's simpler than that sounds.)
<JordanBrown[m]>
I found a fairly simple incantation that correctly carries Unicode names from both the MSYS2 and cmd.exe command lines (in both cp437 and cp65001) all the way through opening the file. As I mentioned, QApplication does the right thing to get the arguments into the program. I copied those QString arguments into a newly allocated argv, replacing the original, let boost::program_options process them, and then copied them back into
<JordanBrown[m]>
The new-today stuff is in the last diff block, at lines 92-100 of that diff block. The rest is the stuff from a few days ago that straightened out the interface with the Launch screen; the only change there is using fromUtf8 instead of fromLocal8Bit to copy the command line arguments.
<JordanBrown[m]>
(I haven't checked what OpenSCAD's policy is on failing malloc. I didn't bother to put in checks because it wasn't necessary for the experiment.)
<JordanBrown[m]>
Bedtime now.
<peepsalot>
it has been possible in the past to build a no-gui / headless version of openscad. not sure if that has been kept working that way. but Qt dependencies are currently consiered "gui"
<peepsalot>
although, i don't know if anyone uses the nogui builds at all. does webassembly?
<peepsalot>
and secondly, it is also feasible that we could have a nogui build which only includes Qt::core, if we want to go that route
<peepsalot>
JordanBrown[m]: per the latest project restructuring, all files which depend on Qt should be under src/gui
<peepsalot>
i tried to maintain headless builds for a while in the faint hope that it would encourage thingivers to update their version, or that some other website would integrate it
epony has joined #openscad
ur5us has quit [Ping timeout: 244 seconds]
pa has quit [Quit: quit.]
pah has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
ur5us has joined #openscad
<gbruno>
[github] kwikius edited issue #4351 (Feature request : Extend array syntax to allow indices to be generally accessible via '.' syntax by allowing optional names for elements) https://github.com/openscad/openscad/issues/4351
<gbruno>
[github] kwikius edited issue #4351 (Feature request : Extend array syntax to allow indices to be generally accessible via '.' syntax by allowing optional names for elements) https://github.com/openscad/openscad/issues/4351
<Scopeuk>
the no-gui stuff avoiding the qt dependency rings a bell for me too
<Scopeuk>
the boost function claims to have automatic translation support between Unicode and local representations https://www.boost.org/doc/libs/1_58_0/doc/html/program_options/howto.html#idp337869408 there is a not about setting locale::global(locale("")); and a whole wall of caveats, no known problems I can see. it does also seam to suggest unless our
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
<teepee>
we *really* need the headless now, WASM is not going to have Qt
<teepee>
also currently WASM implies NULLGL which implies HEADLESS
<teepee>
hopefully at some point the NULLGL can go away
<Scopeuk>
ok, so unfortunately swapping out to the qt parser as per JordanBrown[m]'s suggesting is probably a no go
t-paul[m] has quit [Quit: You have been kicked for being idle]
ur5us has quit [Ping timeout: 248 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
pah is now known as pa
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
fling has joined #openscad
aiyion has quit [Ping timeout: 258 seconds]
aiyion has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
Guest16 has joined #openscad
Guest16 has quit [Quit: Client closed]
snaked has quit [Ping timeout: 250 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
fling has quit [Remote host closed the connection]
califax has quit [Remote host closed the connection]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
califax has joined #openscad
fling has joined #openscad
<peepsalot>
qt has some support for wasm: https://doc.qt.io/qt-5/wasm.html I remember a discussion some time in the past, for using Qt core even in headless builds
<peepsalot>
i'm not really advocating for or against it though. since I don't know anything about it, such as potential benefits or drawbacks
<peepsalot>
i don't really understand all the QPA stuff
<InPhase>
I'm not sure if a portable-between-windows-computers solution exists other than using wmain. Otherwise you're stuck chasing locale issues in a complicated manner.
<InPhase>
The only logical fully portable solution would be for Windows to standardize around utf-8 for main, but I suppose they are in no rush to do that given all the backwards incompatibility issues that would cause with their previous hacky approaches.
<InPhase>
They could have ripped that bandaid off long ago, but they delayed it a very long time and now it's a bigger problem that, unless I missed something, you have to side-step around.
<InPhase>
The locale approaches are one of those things that you can get to pass testing, but then results may vary if you use a different method to launch it, like a different kind of terminal or a different scripting environment.
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
<Scopeuk>
I suppose we have the windows command line wrapper in the com file to exist as a single source of pain for all of this stuff
<Scopeuk>
I guess any changes in there intrinsically don't break or complicate anything else
<teepee>
at this point the wrapper is only for stdout/stdin handling which for historical windows reasons is a compile time option
<teepee>
but if the issue could be solved there, that could be an option
<teepee>
that said, there's other long standing issues with boost-filesystem
<JordanBrown[m]>
InPhase: arguably the problem is not the lack of portable Unicode infrastructures... it's that there are too many of them. I think there may be as many as four of them in play here (Qt, boost, MSYS2/Mingw, MSVCRT).
fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown[m]>
Qt orients theirs around converting everything to QString. Boost seems to orient theirs around parallel support for char and wchar_t. Surprisingly, neither of them seem oriented around UTF-8.
<InPhase>
Yeah. That is indeed a mess.
<InPhase>
I'm quite ready for a Qt replacement.
<InPhase>
That project has too much legacy, too much commercialism trying to make it seem not open, and keeps vectoring in unfavorable directions of development.
<InPhase>
It just held onto somewhat of a near monopoly for a while, so there has not been a space for competitors to thrive in. But now would be a good time I think.
<JordanBrown[m]>
So far the only things where I'm unhappy with Qt are (a) that there's no QString(std::string), and (b) that cout << QString doesn't work. And, so far, that I haven't found a straightforward local-portable replacement for cout/cerr, but maybe I haven't looked enough.
<InPhase>
A monopoly mostly driven by choice, so it was a fair space I think. But still, of the sort where few people attempted to consolidate efforts around alternatives. I think however that the post-C++11 world opened up a space for a much simpler more focused gui solution. There is no need to reinvent so much for a toolkit now that so much is standardized. Only a few extra things need to be added, and
<InPhase>
they should be done with modern standards. One of these being utf8.
<JordanBrown[m]>
My gut reaction is yes, UTF-8 for all internals, translating at the perimeters. However, there's a decent argument for UTF-32 for internals since then indexing works easily and you can easily throw around single values that represent characters. (Except for combining marks and things like the magic country-code code points, argh.)
<JordanBrown[m]>
Critically, "foo" has to just work, as does "turkey:\u1f983" or something equivalent. And you need to throw those around in something with a name a lot like "std::string".
<InPhase>
Yeah, utf-32 is a weird combo of guaranteed indexing except the indexing isn't guaranteed to mean anything. Which in the end makes it not really semantically different from utf-8 indexing. :)
<InPhase>
We don't typically work with codepoints anyway at the application level.
<JordanBrown[m]>
When you say the indexing doesn't mean anything, do you mean with respect to combining marks and those magic code points?
<InPhase>
Well what you might want to know is things like data size, and display length.
<InPhase>
Even if you're using monospaced fonts, utf32 count is not display length.
little_blossom has quit [Quit: little_blossom]
<InPhase>
There is no solution to display length other than to iterate through the elements.
<JordanBrown[m]>
I guess it depends on how monospaced your monospaced fonts are :-)
little_blossom has joined #openscad
<InPhase>
(Although it could be stored after iterating once.)
<JordanBrown[m]>
How should a zero-width space display in monospace? :-)
<InPhase>
As zero space, is the standard.
<JordanBrown[m]>
But everything is the same size! (Head explodes.)
<JordanBrown[m]>
Yeah, if you want display size you have to measure it in the context of a font selection.
<InPhase>
Yes, but then 0 and 1 space are your units. Combination marks are smashed into one space typically for monospace. (Although sometimes smashed poorly and with bleedover into nearby spaces, but those are implementation errors.)
<JordanBrown[m]>
But I'm not sure how you can say that we don't work with code points. We pull strings apart character-by-character all the time.
<InPhase>
Yep. And code points aren't characters.
<JordanBrown[m]>
They're a lot closer than UTF-8 bytes are!
<InPhase>
Not really. Only in some languages.
<InPhase>
This is one of those things they try to hammer into you in "how to work with unicode" guides. i.e., stop trying to think about codepoints as characters, because there are too many exceptions to this.
<InPhase>
It's frustrating, but it's the reality of it. :)
<InPhase>
So all the questions you'd want to ask about characters, you have to put into libraries that understand all these exceptions.
<JordanBrown[m]>
NFC comes close for most practical purposes, but indeed you can put combining marks on anything.
<JordanBrown[m]>
Or maybe you decide that combining marks are *not* part of the thing that they combine with, that they are separate characters in their own right.
<InPhase>
Fortunately we can still avoid all those questions for text where we really need to work with characters by simply using restricted subsets of unicode.
<JordanBrown[m]>
Yes, if you can stay in NFC you can cover most of the world's languages and keep it more or less simple.
<InPhase>
But, in those scenarios, utf8 and utf32 aren't presenting any differences.
<InPhase>
(Except storage space.)
<JordanBrown[m]>
Well, except that in UTF-8 it's hard to say "give me the third character".
<JordanBrown[m]>
It's not even trivial to say "give me the first character".
<InPhase>
Well that depends on what character you're looking for.
<InPhase>
Are you parsing for a space, or a period, or a semicolon? Just iterate, it will be fine.
<InPhase>
Are you using a unicode smiley as your parsing token? Question your life choices, and then have an iterator that returns utf-32 codepoints for each element. Whether it is stored as utf8 or utf32 doesn't matter much for writing such an iterator.
<JordanBrown[m]>
Maybe not. The OpenSCAD language treats U+00A0 No-Break Space the same as space.
teepee has quit [Remote host closed the connection]
califax has quit [Read error: Connection reset by peer]
califax has joined #openscad
<JordanBrown[m]>
Supporting curly quotes isn't silly. In fact, it might be syntactically sensible, since they are matched and you can't get the out-of-sync problems that many languages are susceptible to.
<JordanBrown[m]>
And supporting the full range of Unicode letters in identifiers seems inevitable.
teepee has joined #openscad
<JordanBrown[m]>
To be clear: I mostly agree with the notion of UTF-8 being the standard form, for the pragmatic reason that it's the clear winner in the file-format and tty-format arenas. But it does have its problems.
<InPhase>
Yeah, it does. On balance I think it's the best API interface default and storage default for the vast majority of workflows. And then sometimes you need some special case conversions. Although I think UTF-32 is only for a subset of those and is most valuable if you're specializing things that are normally internals of a unicode library. If you truly want characters, you need types that represent a
<InPhase>
sequence of codepoints.
<InPhase>
And a sequence of codepoints can be stored in either of the storage types.
<JordanBrown[m]>
Yes. (Mostly, I think combining marks and the magic country codes are Just A Bad Idea.)
<InPhase>
Thus, the type of a unicode character can be vector<uint8_t> wrapped up with some occlusion and special features for comparison. (As even byte comparisons do not mean equality in unicode.)
<JordanBrown[m]>
Yeah, and you really want case insensitivity for most comparisons, and then you're better off if you just don't let people from Turkey use your product.
<InPhase>
On the whole I question a lot of the wisdom of unicode. But, it is trying to solve a complexity problem that predates computers.
<InPhase>
Thus I both recognize the issues and lack a superior alternative that could have been made while still achieving the core objectives.
<JordanBrown[m]>
Right. It is in many ways horrible, and the best thing available.
<InPhase>
The best solution from a practical standpoint would be to maximize standardization of interfaces and put as much as we can into standardized libraries to resolve all the practical questions we need to ask about what particular elements or sections of text means in terms of content and representation.
<JordanBrown[m]>
When you say "we" here do you mean the industry, or OpenSCAD?
<InPhase>
The field as a whole.
<InPhase>
OpenSCAD should use utf-8 and hope other people solve these hard problems.
<InPhase>
Well, utf-8 for storage when it's not using QStrings for display.
<InPhase>
It's straightforward enough to go into and out of QStrings from utf-8.
<JordanBrown[m]>
Yes.
<JordanBrown[m]>
But it's not obvious how to go from argv to either of those without going through QString. And without pulling in *another* portability library in the form of Boost's nowide.
<JordanBrown[m]>
(Which I need to look into a bit more, but am prejudiced against simply because of the name. We need infrastructures that *hide* wide, MBCS, et cetera, not that put the distinction front-and-center.)
<JordanBrown[m]>
Similarly, it's not obvious how to go from utf-8 to locale-sensitive standard out without going through QString or nowide.
Guest52 has joined #openscad
<Guest52>
my sidebar dispersed were i enter in the code.
<Scopeuk>
window -> editor should bring it back
<Guest52>
how can i get it back
<Scopeuk>
go to the window menu and untick hide editor is the proper way I suppose
<Guest52>
perfect thanks!
Guest52 has quit [Client Quit]
califax has quit [Remote host closed the connection]
califax has joined #openscad
<InPhase>
JordanBrown[m]: I think that nowide solution is probably a pretty good choice for solving that particular problem, if this has become integrated into boost now.
<peepsalot>
i can't tell if its something we should care about
teepee_ has joined #openscad
<JordanBrown[m]>
Something like mbstate_t would make sense for C, but seems surprising in C++ where the converter object can maintain the state. Maybe their mental model is that the converter object is *purely* a converter, and doesn't maintain state, that you could use the same converter object for converting several data streams, perhaps even in parallel.
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
<JordanBrown[m]>
InReach: agree, nowide is less offensive when integrated into boost proper rather than requiring us to import 20+ files.
<JordanBrown[m]>
But I would (and will) still try to find a way to avoid propagating the "nowide" word throughout the program.
<phryk>
z is up, y is forward/back?
<phryk>
mhh, seems like it.
<JordanBrown[m]>
A quick glance at boost::nowide makes me wonder whether it works properly for non-UTF-8 UNIX locales.
<JordanBrown[m]>
phryk: Yes, look at the little red/green/blue axis indicator in the lower-left corner of the main window.
<phryk>
JordanBrown[m]: I did, but that only points out where the axes are going, I'm kinda lacking an absolute reference frame.^^
<JordanBrown[m]>
What does "absolute" mean? If you're looking at the space so that +Z is up and +X is to the right, then +Y is into the screen. If you turn it so that +Y is to the right, then +X is out of the screen. Neither of those is more "correct" than the other.
<JordanBrown[m]>
In fact, I think the default is that +X is to the right and slightly out of the screen, and +Y is into the screen and slightly to the right.
<JordanBrown[m]>
And, for that matter, the default +Z is up and somewhat out of the screen.
<JordanBrown[m]>
But yes, if you throw a model at something with a more rigidly defined view - a 3D printer, for instance - unless you rotate later in the pipeline +Z will normally be up, +X to the right, and +Y away from you.
<phryk>
JordanBrown[m]: great, that's a good explainer as I only have very little experience with physical production. :)
<phryk>
currently mainly worried about if the thing i design makes sense for other people opening the .scad as this is gonna be a modular desk where production won't be automated :P
kwikius has joined #openscad
kwikius has quit [Quit: Client closed]
ran has joined #openscad
<ran>
are there any other parameters I can pass to roof() besides method="voronoi"?
<ran>
like are there other methods I can use?
<teepee>
ran: not really, I think the other method is the default
<teepee>
ah, no, it seems voronoi is the default, the other one is "straight"
<ran>
hmm
<ran>
when I pass method="straight" it segfaults
<ran>
I'm on the latest snapshot
<teepee>
:(
fling has quit [Ping timeout: 258 seconds]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined #openscad
Colere is now known as LoupGris
<ran>
do you want me to submit a bug report/
<teepee>
if there's none existing yet and the example is reasonably short, that would be nice
<teepee>
I think there's some issues for roof() but not sure if also a crashing one
<ran>
I'm trying to isolate the issue
<ran>
my code is fairly complex
GNUmoon has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
<ran>
this is really bizarre
<ran>
it seems to get triggered only when I try to read a large vector from a second file, and it only gets triggered when I use the "stright" type for roof()
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
linext has quit [Read error: Connection reset by peer]
geoff has joined #openscad
geoff has quit [Client Quit]
geoffder has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
Xeha has quit [Ping timeout: 260 seconds]
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
<JordanBrown[m]>
phryk: Is this something where you want to show both what individual pieces look like and what the assembled result looks like? If so, the Customizer is a good way to make it easy for a user to pick which view to get. At the very top of your file (after comments is OK), say "assembled=true;". In your model, construct the model one way or the other depending on whether "assembled" is true. Then on the Window menu, turn off "Hide
<JordanBrown[m]>
Customizer". Notice that there's a checkbox for "assembled". Checking and unchecking it will show the two variations.
fling has joined #openscad
<phryk>
JordanBrown[m]: holy hell, i coulda used that months ago, when I translated the THAM12 subwoofer plans to openscad :'D
<JordanBrown[m]>
Do you need a demo, or is that enough explanation?
<phryk>
i think it's enough, i also see that there seems to be actual documentation for the customizer. will get back if i have questions. for now i'm just building the thing quick and dirty and will have to refactor later anyhow. :)
<phryk>
is it a new feature? never heard of it before…
<JordanBrown[m]>
It's in 2021.01. I don't know about the version before that.
<phryk>
ooh and there's a customizable customization form – so i don't actually have to use ALL_SCREAMY_CONFIG_VARS to make my models customizable but can have customization through the openscad UI? D: