nomike has quit [Remote host closed the connection]
nomike has joined #openscad
leptonix has quit [Server closed connection]
leptonix has joined #openscad
chris64 has quit [Ping timeout: 260 seconds]
chris64 has joined #openscad
hyperair has quit [Ping timeout: 268 seconds]
hyperair has joined #openscad
guso78k has quit [Ping timeout: 272 seconds]
J25k40 has joined #openscad
J25k85 has quit [Ping timeout: 272 seconds]
<gbruno>
[github] Zenmaster43 opened issue #6027 (OpenSCAD doesn't bring window to front or switch spaces on "Next Window" or "Previous Window" menu selection) https://github.com/openscad/openscad/issues/6027
_whitelogger has joined #openscad
sculptor has quit [Ping timeout: 272 seconds]
ToAruShiroiNeko has quit [Read error: Connection reset by peer]
ToAruShiroiNeko has joined #openscad
bitbasher_ has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
GNUmoon has quit [Write error: Connection reset by peer]
GNUmoon has joined #openscad
bitbasher_ has quit [Ping timeout: 272 seconds]
bitbasher_ has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
nomike has quit [Ping timeout: 252 seconds]
howiemnt1 has quit [Remote host closed the connection]
bitbasher_ has quit [Ping timeout: 260 seconds]
howiemnt1 has joined #openscad
howiemnt has joined #openscad
howiemnt1 has quit [Ping timeout: 252 seconds]
howiemnt1 has joined #openscad
howiemnt has quit [Ping timeout: 252 seconds]
ToAruShiroiNeko has quit [Ping timeout: 260 seconds]
To_Aru_Shiroi_Ne has joined #openscad
To_Aru_Shiroi_Ne has quit [Read error: Connection reset by peer]
<guso78k>
if pasing a windows file with \r\n, each line will count as 2w
<bitbasher_>
if you are on Windows the \r\n is treated like a single line .. on unix YMMV
<bitbasher_>
and by treated .. shell functions and app text function take it into account
<InPhase>
All platforms should read all data generated on any platform identically, regardless of which platform it is.
<InPhase>
There should be no platform specific IO routines.
<InPhase>
Doing it differently by platform was an old pre-Internet philosophy, which should only rear its head again in the case of needing to interact directly with a platform-specific routine.
Guest49 has joined #openscad
Guest49 has quit [Client Quit]
guso78k has quit [Quit: Client closed]
ccox_ has joined #openscad
TheAssassin has quit [Ping timeout: 244 seconds]
ccox has quit [Ping timeout: 260 seconds]
TheAssassin has joined #openscad
guso79 has joined #openscad
<guso79>
I got a complicated testcase where Error Line Numbers are Doubled, top High. /R Processing does Not appear to Work as you describe. When i dont process /R in the Lex File, i get General Syntax Errors. IS there a setting to check?
guso79 has quit [Quit: Client closed]
bitbasher_ has quit [Ping timeout: 252 seconds]
bitbasher_ has joined #openscad
guso79 has joined #openscad
guso79 has quit [Client Quit]
J25k40 has quit [Quit: Client closed]
J25k40 has joined #openscad
<JordanBrown>
I have an issue and maybe PR somewhere for this matter. I don't remember what stalled it.
<JordanBrown>
What stalled it was that one of the test cases 2
cbmuser has quit [Ping timeout: 272 seconds]
<JordanBrown>
(oops) included an error message with the full path to the build area, which of course mismatched on other systems.
<JordanBrown>
Not a killer by any means, just enough to stall some work that wasn't very exciting.
<JordanBrown>
InPhase is right that input processing should not be platform-specific. But that doesn't mean that the platform-independent processing that is needed to handle all file variants is trivial...
<InPhase>
Agreed. It can be tricky at times.
<InPhase>
The central principle for text is generally to always output with '\n', and to always accept '\n' or "\r\n". Except for http which is the one prominent non-windows-API protocol requiring "\r\n".
<InPhase>
And there are certain clipboard interaction cases where "\r\n" must be created in a platform specific manner to work right.
<InPhase>
With one of the Windows updates during Windows 10, notepad gained the ability to process \n line endings, ending the last major user-confusion for files with \n endings.
<JordanBrown>
Standard Internet protocols for text all require \r\n; that's the NVT-ASCII definition dating back to the 1980s or maybe earlier.
<JordanBrown>
But that doesn't really affect us.
<InPhase>
I haven't encountered it outside of http, but yeah, there is a networking standard lurking there for some protocols.
<JordanBrown>
Pretty much originates with Telnet.
TylerTork has joined #openscad
<JordanBrown>
With respect to *reading* text, there's theoretically a question about what to do with a bare \r; there have been a few systems over time that used that as their line break. They can probably be ignored, but all other things being equal they might as well be supported.
cbmuser has joined #openscad
<JordanBrown>
With respect to *generating* text... much less sure about that. I would still generate text platform-specifically.
<InPhase>
JordanBrown: In most cases I've gone with eat and ignore for \r to avoid double-counting \r\n.
<InPhase>
Counting \r, counting \n, but single-counting \r\n is a whole lot more complicated to handle. :)
<JordanBrown>
To be precise, I would open for writing in "text" mode, and then write \n and let the library add \r if appropriate for the platform.
<InPhase>
Ah, I specifically advocate to never do that.
<InPhase>
Well not never, but usually I think it's a bad idea.
<InPhase>
It breaks consistency, and introduces comparison problems.
TylerTork has quit [Client Quit]
<JordanBrown>
Consistent with the platform is more important than consistent between platforms.
<InPhase>
The most prominent \r is pre-osx macs it seems, but we haven't had to deal with that in a while I suppose.
<InPhase>
JordanBrown: Well, that's the thing that I think has changed.
<InPhase>
JordanBrown: I think on principle we're all so connected and sharing so much, that consistency between platforms matters more than consistency with the platform. The platforms need to just get their act together and be compatible.
<InPhase>
JordanBrown: Like when OpenSCAD makes a file, there's a good chance 100 to 1000 more people are going to access that file from all sorts of platforms, and this is massively dominant over whatever platform it was generated on.
Guest47 has joined #openscad
<JordanBrown>
There is a larger chance that it will be accessed by the same user on the same platform.
Guest47 has quit [Client Quit]
<JordanBrown>
The question is to what extent Windows can handle \n files.
<InPhase>
But so many problems are created if it has issues when sharing, that we just need things to be interoperable.
<JordanBrown>
If you have universal read support, other than binary compare there's no problem with platform-specific write support.
<InPhase>
Windows can handle \n now. Really Windows handled \n just fine in almost all programs except Notepad. It was this one text editor not being updated that kept people using \r\n so long on Windows.
<InPhase>
I do remember a clipboard issue requiring \r\n, but that memory is from 13 years ago and pre-Windows 10 when Microsoft decided to start handling standard \n.
<JordanBrown>
Cool. Visual Studio recognizes CRLF, LF, U+0085, U+2028, and U+2029.
<InPhase>
I haven't booted up a Windows machine and run those clipboard tests again.
<InPhase>
On Windows git is configurable to checkout source code as \n, or auto add and remove \r\n. But it's probably for the best to set git on windows to always checkout \n, because I've hit some weird problems with doing a git clone on Windows, and moving those files around on thumbdrives, and then there are massive repo conflict issues if you end up trying to use git on those same files from another
<InPhase>
platform.
<InPhase>
Because like I've been saying, it's a cross-platform world. And files move a lot. :)
<pca006132>
well WSL is enough :P
<InPhase>
And as in the usual story, establishing cross-platform behavior often involves "do the standard thing, and figure out how to handle Windows too." lol
<InPhase>
Windows was the one hold-out on \r\n, and the one hold-out on us not having a C++ ABI.
<JordanBrown>
As of 2022 (a couple of years after the Notepad change):
<JordanBrown>
>The built in Win32 edit control requires \r\n (Windows) for newline characters. It doesn't support the \n (Unix) variant. Also ensure that the control itself has multiline enabled otherwise they will both be ignored. When inserting text into the control that may have Unix newlines you have to convert them to Windows newlines.
<JordanBrown>
Raymond Chen is normally very sharp, but misses the boat on one point there. He says that UNIX adopted the LF-only style "probably as an economy, since it saves one byte per line". I don't have a reference, but I don't think so - I think it was to avoid needing to process two characters (and handle the one-character variants somehow).
<JordanBrown>
The one who got it really wrong was Apple, also going to a single character but choosing CR.
<JordanBrown>
The problem is that LF with no CR is not very interesting, producing stair-step text, so repurposing LF as NL doesn't cost anything, but CR with no LF is useful for overprinting.
<JordanBrown>
For the original question, we don't need to discuss the output side. I think everybody agrees "be liberal in what you accept".
<JordanBrown>
Anyhow, if somebody wants to pick up #4895... go for it. I don't think I'll have time until September.
sculptor has joined #openscad
sculptor has quit [Changing host]
sculptor has joined #openscad
bitbasher_ has quit [Ping timeout: 248 seconds]
<InPhase>
I guess it makes sense that there were some die-hard adherents to some sort of principle that kept Windows from adapting to \n only for so long. I understand the notion of CR+LF, but we're not doing cursor positioning by teletype, and this hasn't been the critical parameter for a while. The abstraction of "lines" has been something that simply needs a divider for a while. Things like being able to
<InPhase>
split by this divider character are of much more value.
guso78k has joined #openscad
<guso78k>
i am now counting \n and ignoring \r and i am sure this will work fine for windows and linux
<guso78k>
and yes, i am aware, that mac might become an issue. lets see
<guso78k>
with that fix error line numbers look correct to me
<teepee>
that will break macos though
<teepee>
so that seems a strange solution
<guso78k>
will it break all macs or old macs ?
<teepee>
that said, I'm not sure there's a good solution other than cursing those people who invented that mess
<teepee>
no idea, maybe just old macs, or just some editors
<teepee>
maybe in 200 years we'll have full utf-8 support everywhere and things get better
<guso78k>
i am wondering if was possible to preprocess all text for line endings before feeding it to lex+yacc. is there an one and only exact algorithm which handles all platforms ?
<teepee>
lex should be able to collect \r\n first and collapse those and then combine that with single \r and \n
<teepee>
lex/flex and yacc/bison are bad solutions anyways as they don't have native support for utf-8 which is also very annoying
<teepee>
unless that changed in the maybe last 3 years since I looked at that last time
<guso78k>
yes, this works in the beginning of my testcase, but later, after parsing code in 3 sublevels(use, use) things work differently.
<guso78k>
i suspect very much, that some of my code misconfigured lexx and yacc to change this setting by writing into wrong memory accidently
<teepee>
using a more modern parsing framework would be nice, but that's not an easy switch probably
<guso78k>
lex+yacc defines all syntax of openscad. you would not want to redo it unless you want to invent a new language ;)
<teepee>
oh, I certainly would like to do that but I don't have time for that :)
<guso78k>
in later builds i got a strange compiler warning which worryies me. its about boost::container::small_vector<int, 4>;
<guso78k>
i am just wondering if it can be switched off or its a real threat
<guso78k>
builtin_polyedron uses same semantic, but does not issue a warning.
<teepee>
if it's real, it's bad
<teepee>
it claims to read 1 byte too much
<guso78k>
let me analize that ;)
bitbasher_ has joined #openscad
<bitbasher_>
actually u have to give the Windows devs props for sticking to the intent of the ASCII control codes .. to move a printer to the start of the next line you need \r\n .. using either one by itself is not canon
<bitbasher_>
and when the first folks started programming for a 24 line x 72 or 80 char screen they just went with the printer codes cause their display code was stream of characters
<bitbasher_>
i was writing some of that code back in the day ..
<bitbasher_>
there were people working early forms of Unix when i was at U 0f Waterloo and they knew that their screen drivers could be smarter about handling control codes .. they emitted the numbers that told the display where to draw the text so using a single code for newline made sense to them
Chancer has joined #openscad
nomike has joined #openscad
Non-ICE has quit [Quit: Screw you guys, im going home!]
Non-ICE has joined #openscad
<guso78k>
this error is triggered by doing std::vector<IndexedTriangle> . push_back(IndexedTriangle> IN ANOTHER PLACE
<guso78k>
in the other place the error is not shown BTW
<guso78k>
for me it looks like that this error is thrown with a certain probability. I i use the push_back too much, chances increase to see this error,
cbmuser has quit [Ping timeout: 276 seconds]
<guso78k>
i am using |gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1)
cbmuser has joined #openscad
teepee_ has joined #openscad
<JordanBrown>
That PR handles all of the CRLF cases, including the CR-only case. But there's a lot to be said for just ignoring CR.
<guso78k>
JordanBrown, I am happy to undo my commit once your PR merged AND my special testcase is clean
teepee has quit [Ping timeout: 244 seconds]
teepee_ is now known as teepee
<JordanBrown>
Like I said, there is a good chance that I won't have time to pursue it until September.
<JordanBrown>
I've got two weeks until I go on vacation for a month, and I've got a number of things (over and above work!) that I need to do in that time.
<guso78k>
My understanding is that it failed due to a bad test and therefore not merged , later stalled ?
<JordanBrown>
Yes.
<JordanBrown>
I wrote a test for the various cases, but one of the errors that I triggered has a full path to the problematic file... and of course that full path is different for different builds.
<guso78k>
not a stopper for me. but i am not bold enough to steal other repo's PRs :')
snaked has quit [Remote host closed the connection]
<JordanBrown>
Which is probably not a big deal to fix, probably by changing it to *not* use a full path, but it was enough to distract me and the problem wasn't so bad that I was forced back to it.
<JordanBrown>
Er... why not?
snaked has joined #openscad
<guso78k>
sorry, its not the way i act. Skin PR was offered to openSCAD. but happily i got the PR, too
sculptor has quit [Ping timeout: 260 seconds]
howiemnt1 has quit [Ping timeout: 260 seconds]
sculptor has joined #openscad
howiemnt has joined #openscad
<JordanBrown>
When you say "steal other repo's PRs", do you mean that you wouldn't take over a PR proposed by a different developer?
<guso78k>
Nope, I was wrong. Maybe i should have sayed, that i would not use a foreign PR from another developer without having asked him.
<guso78k>
But we are discussing and you seem to agree, that I can use it for pythonscad X-P
<teepee>
I have not folled the discussion, but totally crazy idea... update it to merge into openscad?
<guso78k>
Yep, it would be more logical and easier to me. issue is that JordanBrown stated we would not have time next 2 month ...
Chancer has quit [Quit: Connection closed for inactivity]