<JordanBrown[m]>
(Hmm. Looks like it may currently coerce non-strings into being strings. It should stop doing that.)
<JordanBrown[m]>
Actually, come to think of it, allowing non-strings as keys may answer my "where does the geometry go" question. It can go into the element where the key is undef.
<JordanBrown[m]>
So given o = { cube(10); }
<JordanBrown[m]>
o[undef] is the geometry.
<InPhase>
peepsalot: I have reservations about "undef", but maybe that has some utility.
<InPhase>
peepsalot: I suppose we have left undef equality well-defined.
<InPhase>
peepsalot: But yeah, I think in general your list is the sensible list, and I agree with both your statements on range.
<InPhase>
function and object are the more questionable ones, with object being the most questionable.
<InPhase>
function is weird because f = function(x) x+2; and g = function(y) y+2; would probably be different functions, yet are behaviorally identical.
<InPhase>
And if you try to special-case variable names I'll come at you with a halting-problem level of equality checks that you'll find very challenging to solve. ;)
<peepsalot>
yep, that's why iirc function equality only checks if the pointers are the same. also because you'd have to track enclosed variables
<peepsalot>
er "captured" variables
snaked has joined #openscad
<InPhase>
Right.
<InPhase>
I forgot about that, but also true.
<InPhase>
Which again is one of those things that kind of makes it useless.
<InPhase>
A dictionary is primarily useful when you find yourself independently generating the same thing twice but in a different way.
<InPhase>
Sometimes from lists, and structured storage, like coordinates to faces might be. In theory maybe someone has something like that for functions. But I can't imagine it at the moment.
<InPhase>
So if we do functions and objects at all, maybe pointer matching is the right solution. But it's simpler to just not support it and defer the decision to a point where a use case is understood.
<InPhase>
You don't want to fence the future into a useless behavior.
<InPhase>
peepsalot: So what are your thoughts on that [i] = i*i comprehension type syntax? Do you think this is the way to merge objects and dicts? Or do you think they should be separate? Or do you think they should be merged but we invent a different approach to comprehensions?
<peepsalot>
one other thing that's been on my mind is if dict and/or objects could be made as "persistent data structures", having the same benefits as our lists concat and each in O(1). where merging two would not necessarily have to deep copy both
<InPhase>
In theory this could also be used like: d = { ["a"] = 97; };
<InPhase>
Then d["a"] == 97
<peepsalot>
or if its worth the headache to even try
<InPhase>
Although in this case that could have been a variable.
<InPhase>
d = { [97] = "a"; };
<InPhase>
There only a key value lookup.
<JordanBrown[m]>
The [expr]=... syntax looks weird to me, but I understand it.
<InPhase>
Yeah, it's not something I've seen before, but I wanted a clear distinction that aligns with some existing mentality for it.
<JordanBrown[m]>
My bigger concern (in a message that perhaps you haven't gotten to yet) is that the object comprehension syntax
<JordanBrown[m]>
{ for (k=o) [k] = something; }
<InPhase>
Gotten but not read.
<JordanBrown[m]>
is alarmingly similar to the "normal" for syntax
<JordanBrown[m]>
{ for (k=0) text(k); }
<JordanBrown[m]>
oops 0 should be o.
<JordanBrown[m]>
and everybody knows that nothing can escape from a child.
<JordanBrown[m]>
They are syntactically distinguishable. Rather to my surprise, assignments aren't allowed as children.
<JordanBrown[m]>
Should you be able to say
<JordanBrown[m]>
translate([1,1,1]) ["x"] = 4;
<JordanBrown[m]>
?
<JordanBrown[m]>
Or even
<JordanBrown[m]>
translate([1,1,1]) x=4;
<JordanBrown[m]>
?
<peepsalot>
InPhase: the [] syntax feels a little clunky. would using ':' instead of '=' get rid of the need for square brackets?
<peepsalot>
i'm honestly not sure if or how these proposals would result in ambiguous syntax rules
J1A844 has joined #openscad
<JordanBrown[m]>
I'm pretty sure that my proposals do not have ambiguous syntax.
<JordanBrown[m]>
(Though I haven't nailed down how you add a geometry data item to the model, and some variations there are syntactically questionable.)
<peepsalot>
JordanBrown[m]: my only objection to your proposal is that i'm not sure how it would work with some form of object or dict comprehension
<JordanBrown[m]>
I'm increasingly convinced that it really wouldn't. But I'd be OK with that, because you can get an equivalent effect using object() and list comprehension.
<JordanBrown[m]>
As for using ":" as an alternative to "=", I think that would work but I think that it might be too obscure.
<JordanBrown[m]>
Would anybody ever guess that
<JordanBrown[m]>
x = "a";
<JordanBrown[m]>
x : 123;
<JordanBrown[m]>
is the same as
<JordanBrown[m]>
a = 123;
<JordanBrown[m]>
x = "a";
<JordanBrown[m]>
?
J1A84 has quit [Ping timeout: 252 seconds]
<ndnihil>
if only there were some sort of character you could use to identify a variable
<ndnihil>
like, I dunno, a $ or something
<ndnihil>
a=123; x=$a
<ndnihil>
;
<JordanBrown[m]>
The specific case of $ is already taken in OpenSCAD.
<ndnihil>
that would make it too easy to differentiate from a string
<JordanBrown[m]>
$a is not the same variable as a.
<JordanBrown[m]>
But, hypothetically, you could say that @expr uses expr to name a variable, so that
<JordanBrown[m]>
x="a";
<JordanBrown[m]>
@x = 123;
<JordanBrown[m]>
sets the variable a to 123.
snakedGT has joined #openscad
snaked has quit [Ping timeout: 244 seconds]
Guest47 has left #openscad [#openscad]
fling has quit [Write error: Connection reset by peer]
califax has quit [Read error: Connection reset by peer]
fling has joined #openscad
califax has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
LordOfBikes has quit [Ping timeout: 268 seconds]
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
ur5us has joined #openscad
LordOfBikes has joined #openscad
<InPhase>
JordanBrown[m]: lol. @ becomes a stringly typed pointer syntax?
<InPhase>
@ is not bad in my head, since it means "at".
<InPhase>
peepsalot: I could also accept : in that structure.
<InPhase>
peepsalot: We just need to make sure we don't setup any confusion with ranges... But I think it's okay.
<InPhase>
peepsalot: However, note that if we accept :, then d = { 1 : "foo"; 5 : "bar"; }; becomes also dictionary definition syntax. I think whatever we allow in the comprehension thing we should allow plain by itself.
<InPhase>
Rewriting this just to see it: ascii_map = { for (c=[ord(a):ord(z)]) chr(c) : c; }
<InPhase>
dual_ascii_map = { for (c=[ord(a):ord(z)]) chr(c) : c; for (c=[ord(a):ord(z)]) c : chr(c); };
<InPhase>
And yeah... ord("a")
<InPhase>
But basically that. :)
<peepsalot>
a couple other general questions: should it be an error for an object comprehension to set a key more than once?
<peepsalot>
should there be an special "this" object to allow string based access to the current scope?
<peepsalot>
also same question but for the top level, much like javascript global object "window" or "document"
<InPhase>
Setting a key more than once would be a warning like doing so with any other variable.
<InPhase>
And then the last one wins, by the same logic.
califax has quit [Ping timeout: 258 seconds]
<InPhase>
Oh, current scope for strings is a bit of a mess. I've been trying to avoid needing a "this" or "self", and this is not required with the object proposal on the wiki. But it is required if we try to smash dictionary behavior in there.
califax has joined #openscad
<InPhase>
The problem is "this" is not appropriate, because we have lexical scope.
<InPhase>
We could maybe use : for assignment, but @ for scope lookup, like @["24chickens"]
<peepsalot>
also re: <JordanBrown[m]> o[undef] is the geometry.
<peepsalot>
i really don't like that
<peepsalot>
would rather see o._geometry or something
<InPhase>
I missed that. But please don't do that. :)
<InPhase>
Also, broadly speaking, no definition for access to the geometry as a variable is best.
<peepsalot>
can you rephrase that? having trouble parsing what you mean
<peepsalot>
do you mean its best not to allow access to an object's geometry at all?
<InPhase>
Correct, no direct access to it as a CSG tree. Only the ability to instantiate the geometry and the ability to access a rendered form of it with data = render(obj); should be supported.
<InPhase>
There have been zero good use-cases put forward for direct CSG tree perusal, and it's harmful to expose that to programs because then we lock it down as part of the language API and it suddenly becomes something we can't change.
<InPhase>
It is important to reserve some flexibility on the internal representation, and not throw away that flexibility frivolously
qeed has joined #openscad
qeed_ has quit [Ping timeout: 250 seconds]
<peepsalot>
yeah i wasn't really thinking about tree introspection or anything, more like just a reference to the geometry on its own, but the object itself is already close enough to that i guess
<JordanBrown[m]>
Yeah, I was thinking of a way to access it as an opaque data value. I'm not quite sure why, as distinct from the object itself, other than that doing so would make the object "uniform": every aspect of it would be a key-value pair. Also it would answer some questions of how to do some modifications of the object - e.g., how do you grab the geometry from one object and glue some different name-value pairs onto it.
<InPhase>
Yeah. In the wiki proposal the free "obj;" means "geometry here" and "each obj;" means "geometry and variables here".
<InPhase>
So the geometry is sort of the default if nothing else is said.
<JordanBrown[m]>
o.geometry, o. geometry, and o. were the first three reserved names that came to mind, but I really dislike stealing anything from the namespace.
<JordanBrown[m]>
argh.
<JordanBrown[m]>
that's o.geometry, o.<underscore>geometry, and o.<underscore>
<InPhase>
JordanBrown[m]: Keyboard broken? :)
<JordanBrown[m]>
Markdown
<InPhase>
Oh. Matrix bridge issue?
<JordanBrown[m]>
Did it not come through as italics?
<InPhase>
No.
<InPhase>
"o.geometry, o.geometry, and o. were"
<JordanBrown[m]>
So it processed the markdown but then your client didn't see the formatting.
<InPhase>
IRC typically does not have italics.
<JordanBrown[m]>
When I tried it the other day with multiple clients running, my IRC client did see the italics.
JordanBrown has joined #openscad
<JordanBrown[m]>
Brought up the IRC client, trying italics now.
<JordanBrown[m]>
yeah, it came through the IRC client as italics.
JordanBrown1 has joined #openscad
<JordanBrown[m]>
Brought up Hexchat, italics again.
<InPhase>
Where? Nothing but ascii is even in the log.
<peepsalot>
InPhase: I know I argued hard for "obj;" to mean geometry here. but what do you think about the fact that module and function "namespaces" become mixed by doing that?
<JordanBrown[m]>
Those three clients all saw italics.
<InPhase>
peepsalot: obj = foo(); obj; would be a function call. [foo()][0]; could make a geometry (although a silly way to do it).
<JordanBrown[m]>
I would probably allow func(); but with the same kind of disambiguation that we have for functions in expression context.
<InPhase>
JordanBrown[m]: What are your IRC clients connecting to? Directly to libera servers, or some sort of bouncer or matrix thing?
<JordanBrown[m]>
Once we dragged variables into being function references, the dam started leaking.
<JordanBrown[m]>
My primary at the moment is Element, via Matrix.
<InPhase>
JordanBrown[m]: "20 69 74 61 6c 69 63 73 20" The hex code around your "italics" word.
<InPhase>
JordanBrown[m]: There's nothing even there for a client to interpret. :)
<JordanBrown[m]>
Previously was IceChat, via libera, and before that HexChat, also via libera.
califax has quit [Ping timeout: 258 seconds]
<JordanBrown[m]>
Don't know, don't know beans about IRC.
<peepsalot>
InPhase: ok, got it. so a function call by itself is not valid statement, regardless of its return type. i must have skimmed over the part where you mention that.
califax has joined #openscad
<InPhase>
JordanBrown[m]: I suppose it's possible I have some sort of filter on the logging system too. I don't mind if I do, as I hate what people do with formatting. But I don't recall ever enabling such a thing.
<JordanBrown[m]>
Fired up Wireshark, let's see what it sees with italics.
<JordanBrown[m]>
Capture everything.
<JordanBrown[m]>
One more try.
<JordanBrown[m]>
Icechat seems to be using TLS, but Hexchat doesn't. Wireshark says:
<JordanBrown[m]>
Trailer: One \035more\017 try.
<JordanBrown[m]>
That's Ctrl+] and Ctrl+O.
<JordanBrown[m]>
0000 4f 6e 65 20 1d 6d 6f 72 65 0f 20 74 72 79 2e One .more. try.
qeed_ has joined #openscad
JordanBrown has quit [Quit: Beware of programmers who carry screwdrivers.]
JordanBrown1 has quit [Quit: Leaving]
<JordanBrown[m]>
As soon as we have module references the v(); syntax pretty much becomes required.
<InPhase>
JordanBrown[m]: It seems to yield a parser error at present. But so does my [foo()][0]; example. The values need to be assigned to something it seems.
<InPhase>
module _(o){} _(foo()); This creates a function-launcher _() that can be used to make objects. :)
<InPhase>
Oh wait. That won't make it. That will eat it.
<InPhase>
I suppose it needs to be module _(o){o;}
<DenKn[m]>
two thougts about your discussions about types in keys and the syntax:
<DenKn[m]>
lua and ruby supports mixed any types as keys: { 48 => "0", "0" => 48, } || { [48] = "0", ["0"] = 48 }
<DenKn[m]>
and you can see, lua has the syntax with brackets.
<DenKn[m]>
any types, but not mixed in one dict, are supported by many laguages: c++, java, go, rust, ...
<DenKn[m]>
but they have a more complex syntax or no syntax for creation.
<DenKn[m]>
the most extrem would be smalltalk.
<DenKn[m]>
if we compare them to objects, lua acts like javascript, there are no differences.
<DenKn[m]>
but all the other languages are totaly different: most of them, the attributes are accessible by ’obj.attr’ instead of obj["0"]
<DenKn[m]>
objects are structures with attributes to access data and methods. dicts are storages for data.
<DenKn[m]>
dicts with only string-keys supports space in strings, while attribute-names couldn't.
<DenKn[m]>
so, i would be happy, if there were dicts in openscad, i miss them really. i would be happy with ‘a={["0"] = val }; a["0"]‘ syntax.
hrberg has joined #openscad
<DenKn[m]>
but i would be happy with objects, too.
<DenKn[m]>
you could use something like: ‘object a { a = val };‘ compared to functions.
ran has quit [Remote host closed the connection]
califax has quit [Remote host closed the connection]
califax has joined #openscad
ur5us has joined #openscad
califax has quit [Ping timeout: 258 seconds]
califax has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
Guest24 has joined #openscad
<Guest24>
hello... anyone here?
Guest24 has quit [Client Quit]
<J1A844>
öh
M6piz7wk[m] has quit [Quit: Reconnecting]
M6piz7wk[m] has joined #openscad
M6piz7wk[m] is now known as KREYREN
<J1A844>
hm if a "×" is in a filename scad can't open it from recent file list
<J1A844>
it says "can't finde file" when saving the × is a ?diamond symbol but when opening it is displayed correct but the titel says × instead of the ×
snakedGT has quit [Quit: Leaving]
<ndnihil>
does the rest of your OS cope with the extended character set?
<ndnihil>
works fine here
<J1A844>
when clicking the file in explorer (win) it opens .. it is just not working from the recent files in openscad
Guest66 has joined #openscad
<dalias>
it's probably windows badness
Guest66 has quit [Client Quit]
<dalias>
do you have a new enough windows that it can be set to utf8 as the native locale encoding?
<dalias>
i don't know how you do that but microsoft finally caved and added that option a couple years back
<dalias>
after decades of making excuses why you couldn't use utf-8
<J1A844>
other software can open files with "×" without problems so does openscad if not clicked from the "recent" list
<dalias>
well it's going to be a matter of what interfaces it uses. it sounds like something is getting wrongly interpreted as latin1 here
<dalias>
which likely wouldn't happen if the windows-native "codepage" weren't set to latin1
<J1A844>
via "open" is also not working
<dalias>
yeah
<dalias>
i think it's probably that openscad uses the standard C++ interfaces for opening files by name, which takes normal byte strings, not the wacky windows-specific interfacs that use utf-16 "WCHAR" strings
<dalias>
the right solution is to fix windows so that it works with the standard interfaces
<dalias>
rather than write code special-cased for the old way microsoft tried to make everyone do for 3 decades
<J1A844>
yeah stop developing windows software - Ü
<dalias>
well stop developing "windows software" and develop "software that works everywhere, including windows, using standard programming interfaces"
<J1A844>
i would assume that if you compile software for an OS it is compiled in a way that it works for that OS
<dalias>
i'm surprised Qt isn't abstracting around some workaround for this tho. maybe it's that the openscad core isn't Qt, just the UI, and part of the problem is that the UI's idea is mismatched from the underlying core's idea
<dalias>
you'd have similar problems if you tried to set the character encoding to some legacy hell on linux, too, i think
<dalias>
the only difference is that windows has it set wrong by default :-p
<dalias>
and linux distros fixed this like 8-10 years ago
<ndnihil>
oh, winderps
<ndnihil>
yeah, can confirm on the leenookses it's works lovely
<ndnihil>
s/it's/it/
<J1A844>
I mean CURA can deal with it, and why is this working when opened directly from the file. When i saved the file the console "file saved" msg already contained an undefined (? diamond) character. That shouldn't happen
<J1A844>
and as the recent list seems to check if files are available - it checks and finds it, but something unexpected happens when opening
<ndnihil>
upgrade to debian
<dalias>
if a program is not written *specifically* to work around windows wrong handling of non-ascii filename access, and isn't written on top of a layer that abstracts that away for you (as cura is, since it's written in python)
<J1A844>
i have linux on a different boot - so finding workarounds is not part of QA testing Ü
<dalias>
then it's going to be unable to access non-ascii filenames right unless you set the windows locale encoding to utf-8
<dalias>
*because windows had really poor support for non-ascii filenames* until the utf-8 option was added
<dalias>
now maybe you want to ask openscad to work around this for you. my position is that we should discourage software from doing that, especially now that there's an easy option to fix it on the system side on windows
<dalias>
btw: maybe openscad can make a call at startup to fix the per-process windows locale to utf-8, without requiring the system config to be changed? if so that would be a non-invasive fix
<J1A844>
So i have 2 windows openscad one with the filename correct and one with a wrong one .. so scad can handle this but just not how the recent list/file open dialog accesses it.
<dalias>
(vs special-casing all the filesystem access to convert to WCHAR[] and use the w* functions on windows)
<dalias>
and yes, it *is* now possible to build applications so that they get the right default regardless of what the system setting is. see the linked answer
<dalias>
so, someone on the openscad side should incorporate this into the windows build
<dalias>
and then it all should work right
<J1A844>
this is also happening with ÄÖÜäöü characters that are commonly used in german language. It is like back in the 90s where you kept filenames short and ascii only - Ü
<dalias>
YES
<dalias>
we know
<dalias>
and i just told them how to fix it non-invasively
J1A844 has quit [Quit: Client closed]
J1A844 has joined #openscad
<JordanBrown[m]>
In a sense, UNIX derivatives never had this problem because the kernel (at least historically) didn't know anything about encoding. You give it a name consisting of a sequence of bytes, it gives you a file. It doesn't know what the bytes mean.
<JordanBrown[m]>
There were only two special values: 0x00 and 0x2f.
<dalias>
well that's one way of looking at it. but the problem started when MS decided to break things.
<J1A844>
interesting after i changed to the "beta UTF-8 " via intl.cpl i can open it via "open" and recent from within openscad but not via the recent file list - maybe need to restart
<dalias>
yeah you need to restart the app i think
teepee_ has joined #openscad
<J1A844>
no the startup screen from scad doesn't work with it .. maybe if i restart the OS
<JordanBrown[m]>
With the MSYS2 build it works OK, except that the console font doesn't know the characters.
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
<dalias>
j1a844, what do you mean startup screen doesn't work?
<dalias>
it might have saved the names already with the wrong encoding, so that selecting one from there is now mismatching
<dalias>
i would start fresh, not using any old "recent" entries and just opening files
<dalias>
and see if the newly-added-to-recents ones work
<J1A844>
the welcome screen from open scad .. if i use the recent list there or the open dialog it is not working
<JordanBrown[m]>
Hmm. The console font is set to Arial, which should have nearly everything.
<dalias>
jordanbrown[m], what characters fonts have is NOT the issue at all
<JordanBrown[m]>
Ah, interesting. All is well inside OpenSCAD proper. It's just the Welcome screen that is in trouble. And, as I noted, the console font.
<J1A844>
Saved design 'E:/Delete/�tf8.scad'.
<JordanBrown[m]>
And I'm wrong, that's not the MSYS2 build, it's the development snapshot.
<JordanBrown[m]>
but other UIs are properly showing it as a ä.
<dalias>
fun. i suspect Qt is trying to do some weird windows workaround stuff and openscad core isn't in on that
<J1A844>
Loaded design 'E:/Delete/�tf8.scad'.
<dalias>
:/
<dalias>
this should really be opened as an issue on github for all the information to be well-collected so someone can act on it
<JordanBrown[m]>
That too is a font problem. Or at least something tied to the display. I bet you'll find that the file has the right name.
<JordanBrown[m]>
But the Welcome screen does indeed get it wrong.
<J1A844>
from within openscad i now can open it (which failed before the win beta utf activation) but from the welcome screen i end with Failed to open file E:/Delete/Ütf8.scad:
<J1A844>
so when the console lists the name correct - it failes to load, but if the name is wrong in the console it works
<InPhase>
What we need is a frustrated non-English-native windows-using programmer to swoop in and fix it.
<JordanBrown[m]>
The Welcome screen properly shows my ä.scad and my 🦃.scad, but when I try to have the Welcome screen open ä.scad it tries to open a different name that looks like a UTF-8 name interpreted as ISO-8859-1.
<JordanBrown[m]>
Yeah, confirmed, that's what the two garbage characters are.
<JordanBrown[m]>
Perversely, the console displays the name "correctly" when it says that it can't access it.
<JordanBrown[m]>
But once inside OpenSCAD proper, not from the Welcome screen, everything seems OK except the console.
<J1A844>
well ill stop using non-ascii like it was in the 80s - i think no engl. native speaker understands how weird it is for to use a different language so your computer works - I am always telling pupils "only use english language when saving files - it is just to be save
<JordanBrown[m]>
But the console does properly handle echo("🦃");.
<JordanBrown[m]>
and echo("ä").
<InPhase>
J1A844: The only thing I have to avoid is spaces in filenames.
<ndnihil>
only noobs and monsters put spaces in file or directory names
<ndnihil>
they should all be keelhauled
<dalias>
j1a844, that's not what you should have to do, but it's probably the easiest for now. hopefully this will get fixed
<InPhase>
J1A844: But, I fully endorse proper utf-8 support everywhere on filenames.
<JordanBrown[m]>
Why do you have to avoid spaces in file names?
<JordanBrown[m]>
I use spaces in file and directory names all the time.
<J1A844>
right space was also that strange thing .. it was feeling so strange when OS started to support longer names and spaces (i still try not to use it)
<InPhase>
JordanBrown[m]: Spaces in filenames mess up hastily written bash scripts.
<ndnihil>
and anyone who doesn't timestamp with YYYYMMDDhhmmss should be punched right in the mouth
<JordanBrown[m]>
Well, yeah, but that's not OpenSCAD's fault.
<InPhase>
ndnihil: Hopefully you accept - and _ spacers in there without violence. :)
<JordanBrown[m]>
I like punctuation in my timestamps, but I agree on the order.
<ndnihil>
- and _ are perfectly acceptable, they aren't spaces
<dalias>
i don't think it really helps knowing who to blame, but really, this is a problem microsoft created in the early 90s that we're still stuck with. and openscad being a mix of portable, non-ui-specific C++ (for the core/backend) and Qt GUI, where Qt probably has hacks to work around the old way windows handled this stuff, means there are a lot of interface surfaces where things can go wrong :/
<JordanBrown[m]>
Programs that can't handle spaces are just sloppy.
<dalias>
jordanbrown[m], make :)
<JordanBrown[m]>
Yes, probably make.
<dalias>
not using spaces is mainly motivated by wanting to automate your workflows with make
<dalias>
which is a very useful thing to do with openscad
<InPhase>
dalias: Modern Windows has utf-8 hooks for all of its filesyste actions, it is just a shockingly recent addition.
<JordanBrown[m]>
Make is from the 1970s. It's a wonder that it handles file names longer than 14 characters.
<dalias>
inphase, "hooks"? do you just mean the ability to set utf-8 locale?
<JordanBrown[m]>
That's because Windows had non-ASCII support long before almost anything else did, and before UTF-8 became common.
<InPhase>
dalias: I mean that for every Windows API call about the filesystem, there's now a utf-8 version.
<dalias>
that's what we were talking about above. but i suspect Qt isn't playing nice with that...
<dalias>
inphase, that's not helpful.
<dalias>
the need is for the *standard* functions to accept that byte strings are utf-8 not some legacy "codepage" associated with the user's language
<dalias>
so that you're not stuck writing windows-specific code for everything
<dalias>
and windows now *can* do that too
<dalias>
either by setting the locale to utf-8 at the system level, or by the means in the link i posted above
<InPhase>
dalias: Yes, as it is a recent addition it has not percolated into library support and standard behavior and such.
<JordanBrown[m]>
Obviously there are parts of OpenSCAD that do it in a way that works, and parts that don't, and we just need to have the parts that don't, do.
<dalias>
jordanbrown[m], yep. i'm pretty sure the parts that don't are Qt :-p
<InPhase>
dalias: I concur it is a frustrating long term problem. I see hope on the horizon within another decade. :)
<dalias>
like Qt has probably hard-coded "this is windows, so even though you told me that string is utf-8 it must actually be latin1" >_<
<dalias>
inphase, the link provides source-level and linker-level options to make windows binaries use utf-8, *even on pre-utf8-system-locale versions of windows* if you static link the runtime
<dalias>
i think that's probably a viable solution for openscad
<JordanBrown[m]>
Let's find the problem before designing the solution.
<JordanBrown[m]>
Given that it works in large parts of the program, it is unlikely that the problem is global.
<JordanBrown[m]>
It appears to misbehave identically in the MSYS2 version.
tachoknight has joined #openscad
<JordanBrown[m]>
Well this is ominous:
<JordanBrown[m]>
auto qsDir = QString::fromLocal8Bit(absoluteBaseDir.generic_string().c_str());
<JordanBrown[m]>
auto qsFile = QString::fromLocal8Bit(fileName.c_str());
<JordanBrown[m]>
But I need to run now. Will look more later.
<dalias>
yeah that's the culprit most likely
<dalias>
especially if "fromLocal8Bit" doesn't support utf-8
<InPhase>
"On Unix systems this is equivalen to fromUtf8(), on Windows the systems current code page is being used."
<InPhase>
(That was a copy/paste, the typo is in the original. Not my fault!)
<InPhase>
I believe fromUtf8 is the solution here.
<InPhase>
fromLocal8Bit appears in 4 places in the code.
<JordanBrown[m]>
So, yes, that's what messes up the file name. Interestingly, the normal open doesn't go through that function. Probably the resolution is to figure out what path a normal open takes, and have the LaunchingScreen open go through that same path.
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<JordanBrown[m]>
The problem is in how file names passed in from the command line (as vector<string>) are combined with file names from the LaunchingScreen (as QString). The QStrings are currently converted into string, and then back again, and that's an uncertain process.
<JordanBrown[m]>
I have it correctly handling LaunchingScreen selections. (Got std::string out of that processing path.)
<JordanBrown[m]>
Names passed on the command line are still in trouble.
<JordanBrown[m]>
Part of that is that they are already in trouble by the time they get to the functions involved here. It looks like something before the wild-card processing mishandles them, because my 🦃.scad turns into ??.scad and then gets expanded as a wild card, all before this function. That could be unique to the MSYS2 build.
<JordanBrown[m]>
But even if that was OK, there would still probably be a problem here because the fromLocal8Bit is still there; I just moved it so that it only applies to argv and not to the names from the LaunchingScreen.
<JordanBrown[m]>
Opening ä.scad from the command line works OK, but I don't know if that's because it's clean all the way, or if it's getting converted to 8859-1 and then back to QString.
p3ck has quit [Ping timeout: 268 seconds]
<JordanBrown[m]>
Yeah, something in the MSYS2 startup is doing that wild-card processing htat is breaking 🦃.scad from the command line.
<JordanBrown[m]>
It's bad coming into main().
rawgreaze_ has joined #openscad
rawgreaze has quit [Ping timeout: 268 seconds]
rawgreaze_ is now known as rawgreaze
<JordanBrown[m]>
Something in startup is converting to 8859-1. When I say ä.scad on the command line, what shows up in argv is an E4, which is 8859-1 for ä.
<JordanBrown[m]>
It is then unsurprising that it does bad things to 🦃, which has no 8859-1 equivalent. My guess would be that Windows gives it UTF-16LE, and that (a) it doesn't understand the two-word UTF-16LE sequence required for that symbol and so thinks that it is two characters, and (b) is then unable to convert either of them to 8859-1 and so substitutes a "?".
rawgreaze has quit [Read error: Connection reset by peer]
<dalias>
it's not a surrogate pair in utf-16
<JordanBrown[m]>
Why do you say that it's not a surrogate pair?
<dalias>
only extended cjk, emoji, random arcane ancient scripts linguists geek out over, etc. are outside the BMP
<JordanBrown[m]>
And 🦃 is not an emoji?
<JordanBrown[m]>
It's U+1F983
<dalias>
oh sorry i thought you were talking about ä
<dalias>
but i'm not sure "outside the BMP" is what's relevant even then. it might just be "not representable in the 8bit codepage"
rawgreaze has joined #openscad
<JordanBrown[m]>
Two wrong things happen to 🦃
<JordanBrown[m]>
it gets turned into *two* question marks.
<JordanBrown[m]>
That suggests that (a) it gets misinterpreted as two characters, and (b) each one of them can't be converted.
<JordanBrown[m]>
π.scad gets helpfully turned into p.scad.
<JordanBrown[m]>
ə.scad appears to have been turned into ?.scad and then expanded.
<JordanBrown[m]>
Yes. (Changed it to scadx so that it didn't match anything.)
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<JordanBrown[m]>
MSYS2's ls shows 🦃.scad as ??.scad.