fling has quit [Remote host closed the connection]
fling has joined #openscad
ali12341 has joined #openscad
ali1234 has quit [Ping timeout: 268 seconds]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
LordOfBikes has quit [Ping timeout: 268 seconds]
Guest28 has joined #openscad
snaked has joined #openscad
LordOfBikes has joined #openscad
<Guest28>
Hello all. I did not have problems with OpenSCAD on Linux (-: excepted some givup of the sofware). But the final design does not run at all on Windows 11, past the problem of pathes. Now, I have no path error (I think !) but the design is not displayed, like it was on Linux (of course). OpenDCAD indicate a syntax error wher I dont see anything
<Guest28>
and where I did not have problem on Linux... Does someone has an idea ? Thank you for helping...
<InPhase>
Guest28: Can you take your design that is giving you a problem and paste it on https://bpa.st and then provide us with the resulting link?
<InPhase>
Guest28: Make sure to copy and paste it FROM the Windows 11 machine to do this.
cbmuser has quit [Ping timeout: 268 seconds]
cbmuser has joined #openscad
<Guest28>
InPhase But it is rather huge ! A lot of files, some of them being ".xdf" !
<Guest28>
InPhase But it is rather huge ! A lot of files, some of them being ".dxf" files !
<Guest28>
https://bpa.st/FZFA ... I put the "main" only ! The red bullet is on line 367 and the red character is on th 'n of convexity...
<Guest28>
OpenSCAD just says :
<Guest28>
Parsing design (AST generation)...
<Guest28>
ERROR: Parser error: syntax error in file test.scad, line 368
<Guest28>
Execution aborted
<Guest28>
I know that the problem(s) can come from included files, but was included the same way on my Linux box...
<Guest28>
Seing the pathes, you guess that I did it from Windows machin.
<peepsalot>
Guest28: you can't finish a string with \" because that means insert the double quote character in the string. line 342
<peepsalot>
the syntax highlighter gives a hint, since the rest of the lines after that are all the same color "as if they are in a string literal"
<peepsalot>
i think you should be able to use a forward slash though
<peepsalot>
some of your other paths are a mix of forward and backslash
<Guest28>
Ok. I try so soon...
<peepsalot>
and line 368 is the next line where it sees " to finish the string
<Guest28>
The other problem is that Windows is not UTF8 ready... And I used the Ø in a file name !
<Guest28>
No error but no preview... Retarting OpenSCAN...
<Guest28>
Restarted, OpenSCAN gives more details...
<Guest28>
WARNING: Can't open DXF file 'C:/Users/PATRICK/Desktop/Va/Dev\C:UsersPATRICKDesktopVa/Visserie/Ecrou_M3_55_brut.dxf'.
<Guest28>
for exemple... the ', character, I suppose...
<Guest28>
But nooooo !!! The path i repeated !
<Guest28>
See line 368 : "rootPath". But its not repeated, realy...
<peepsalot>
Guest28: that DXF path has C:/ twice
<peepsalot>
C: i mean
<Guest28>
Windows changed mi keyboard
<Guest28>
What a bullshit that system. Sorry about that::: I hqve a spanish KBD
<Guest28>
Changed all back / with / and its OK
<Guest28>
Uffff Finished with Windows Bye and thqnk you 1
<Guest28>
Got back the spanish keyboard. Indead, the Windows system run in frensh, and I have a spanish keyboard. I'm frensh living in Peru !!!
<Guest28>
All the \ changed in / and all is OK. I wonder finaly if its Windows or OpenSCAD that does not deal with UTF8 ???
<Guest28>
By and thanks again.
Guest28 has quit [Quit: Client closed]
J1A84420 has joined #openscad
J1A844 has quit [Ping timeout: 244 seconds]
ur5us has quit [Ping timeout: 272 seconds]
ur5us has joined #openscad
<JordanBrown[m]>
Hmm. I duplicate a problem including a file with a non-ASCII name.
<JordanBrown[m]>
Generally speaking both OpenSCAD and Windows are Unicode-capable, but there are some rough edges at the interface between the two.
<JordanBrown[m]>
I have a file 🦃.scad. Windows is perfectly happy with it. I can open it with OpenSCAD and edit it, with the only problem being that the console messages for loading and saving it say ??.scad instead of 🦃.scad. But
<JordanBrown[m]>
include <🦃.scad>
<JordanBrown[m]>
yields
<JordanBrown[m]>
WARNING: Can't open include file '🦃.scad'.
<JordanBrown[m]>
(That's with 2021.01 on Windows.)
<InPhase>
It's correct to mark an error on the later part, because that's where the error occurs from the parser's perspective. It's just confusing from the user's perspective if they made a typo of that sort.
<InPhase>
JordanBrown[m]: We should not have to reseed to get randoms that keep on being random.
<InPhase>
JordanBrown[m]: But let me see what has happened to this section. I recall this PR I did which had the goal of RNG consistency between animation runs: https://github.com/openscad/openscad/pull/3144
<InPhase>
JordanBrown[m]: Oh... I see. I missed that you're seeding in the second one.
<InPhase>
JordanBrown[m]: The two goals are not incompatible. My PR there has the express goal of consistency within a run, so that rands calls with one seed within run track to subsequent rands calls within the run, so a seed persists. And the implementation of this was done by making it a global rng, which makes it persistent between runs as a side-effect.
<InPhase>
Applying an extra seed would not break animation runs.
<linext_>
hmmm....
<linext_>
if there's only one line, it underlines the first line
<linext_>
i think i'll try to find the previous non-commented line, and underline that
<JordanBrown>
Sigh. The Matrix-IRC bridge is introducing time warps again.
<JordanBrown[m]>
Inphase The problem is that in the example given, they *don't* keep on being random. The second line of the example reseeds to a constant. I think it's entirely understandable that that reseed affects the rest of the run (though others have disagreed), but it's somewhat surprising that it affects the *next* run too.
<JordanBrown[m]>
Right. And that seed controls the first call in the next run.
<InPhase>
JordanBrown[m]: Agreed, I concur with your issue report and proposed solution now that I've assessed the detail.
<InPhase>
JordanBrown[m]: Just keep an eye that it stays at a "before run" and does not alter within run behavior.
<JordanBrown[m]>
I'm not sure that I really believe there's a use case for mixing non-seeded and seeded calls, but it *is* weird.
<JordanBrown>
[ Again, note that the Matrix-IRC bridge is introducing time warps. The stuff that's making it to IRC now is stuff that I typed 15 minutes ago. ]
<InPhase>
Oh there's definitely a use case. Animations with procedural generation require seeded data, but might also want random content.
<JordanBrown[m]>
That is, it seems like for the entire model you would want either un-repeatable random numbers, or repeatable random numbers, not a mix of the two.
<JordanBrown[m]>
Right.
<JordanBrown>
Yes, absolutely, should not reseed during a run.
<InPhase>
My PR was motivated by the calendar entry of the spinning Christmas tree.
<JordanBrown[m]>
Each run, at least until it explicitly reseeds, should get non-repeatable random numbers. They should not depend on what a previous run did.
<JordanBrown>
Hmm, note that there are implications for MT processing. Theoretically, once you have processed the assignments in a given block, you can process the module invocations in parallel - but not if you are depending on repeatable random numbers. But mostly that's a theoretical problem because
<JordanBrown>
lelizing.
<JordanBrown>
execution time is normally quite small and not worth paral
<JordanBrown[m]>
Better than using the fourth arg to rands() might have been to have an explicit function or module that reseeds. I was having a conversation where the person was surprised that supplying a seed to one call affected the next (no-seed) call.
<JordanBrown>
Well, I guess echo and assert are issues for that too.
<InPhase>
And in fact that tree relies on randomness prior to applying the seed to make the sparkles shown here: https://imgur.com/a/G6CaUAy
<InPhase>
So I'm slightly confused about how exactly that worked given the behavior of the seed persisting between runs. :)
<JordanBrown[m]>
But this is a unique case in OpenSCAD; I think it's the only operation in the entire language that has global effect.
<JordanBrown>
Remember that it is not that the seed persists, but that it's the same random stream.
<InPhase>
Yeah. There have been a few erroneous cases with render caching, but most of those are bugs (other than the performance gain).
<JordanBrown>
If it can take different paths, then it can get different sequences of random numbers.
<JordanBrown[m]>
Well, maybe the camera-control variables. I don't know what they do if set at other than the top level, or if set more than once in different scopes.
<JordanBrown>
Or at least I think it can.
<InPhase>
It seems in current OpenSCAD, my detailed tree sparkles are in fact broken.
<JordanBrown[m]>
It does seem like we need an explicit global-effect mechanism. It would be applicable to this, to camera control, and to lighting control. Maybe also to letting the program have some control over exports, e.g. supplying a default export name.
<JordanBrown>
Hmm, no, unless your post-seeding actions depend on pre-seeding randomness, the pre-seeding stuff will remain constant.
<InPhase>
Oooh.
<InPhase>
No, they do work, but because I cheated. :)
<JordanBrown>
hmm?
<InPhase>
And only if you animate...
<InPhase>
_sparkles = rands(0,1,1,$t);
<InPhase>
Time seed. ;)
<JordanBrown>
Hah!
<JordanBrown[m]>
Maybe, analogous to $ variables having call-stack scope, @ variables could have global scope. Attempting to set them twice, anywhere in the model, would be an error. Well, argh, except that you *should* be able to reseed twice.
<InPhase>
Your suggestion is a better fix. I suppose at the time I thought I was fixing an esoteric problem with one design only.
<InPhase>
Which, it was, because it was the only design that used persistence of rands, as it did not exist as a feature. But now that it is a feature, we should make it better in the way you describe.
<JordanBrown>
We are stuck with it now, but did rands take that optional fourth argument before your change, and just apply it only to that one call?
<InPhase>
Correct.
<InPhase>
Which was really hard to work with.
<linext_>
hmm...
<JordanBrown>
Perhaps it would be clearer if we had an explicit reseed call, and deprecated the fourd argument.
<InPhase>
I would have no objection.
<linext_>
so the actual openscad program follows the same error marking object
<linext_>
if you forget the ';' at the end of the line, the parser will find the next real line of code and mark it
<linext_>
not sure i should fix it
<JordanBrown>
linext_ sure, because that's where the program becomes clearly wrong.
<linext_>
other IDEs like Visual Studio or Eclipse would underline the line missing the ;
<InPhase>
They're doing some elaborate code parsing to detect that error.
<linext_>
i wonder if the .AST file can be used for hinting at where the error really is
<InPhase>
Consider multi-line calls with parentheses, and the error is on the 3rd line. Do you want to mark the first? Maybe, sometimes. What if it's 20 lines?
<InPhase>
You can do some wild nesting.
<JordanBrown>
I'm dubious of any automaton's ability to point out the *actual* error point.
<linext_>
block comments make it difficult
<InPhase>
The IDEs are basically parsing for a few common mistakes.
<InPhase>
If it can't find a common one, I'm sure it falls back to where the parser failed.
<linext_>
maybe i should make the message say, error on or before line #
<InPhase>
Sure.
<JordanBrown>
yes, maybe
<InPhase>
Programmers all know that by heart, but OpenSCAD caters to non-programmers.
<JordanBrown>
Truly right would probably be to mark the entire block from the last time it was known OK to the point where it's known wrong.
<InPhase>
But you do want to emphasize where the parser failed.
<JordanBrown>
But even then, note that a missing or extra close brace might be detected hundreds of lines after the actual point of the error.
<InPhase>
Yeah, that.
<JordanBrown>
The point where it's known wrong, the end of the marked block, *is* where the parser failed.
<InPhase>
You can do a lot of successful parsing in between the problem point and the parser failing.
<InPhase>
So last known good is not really automatable.
<linext_>
i'd need a lot of test cases to get this to get close to working
<InPhase>
Well, I guess maybe if the parser was recursing down somewhere, maybe sometimes.
<linext_>
i was hoping there was a feature in monaco editor to find the previous non-comment line, but there isn't
<JordanBrown>
There still might be something to be done. I don't know whether a yacc parser can do it, but if you detect a problem parsing a statement, you can know that it's a problem since the last statement.
<InPhase>
But I'm willing to make a solid bet that if I worked at it I could come up with a pathological case to thwart any solution you can come up with to automatically detect where the error is. :)
<InPhase>
I believe firmly in my practiced ability to break stuff.
<JordanBrown>
But it doesn't have to be perfect.
<JordanBrown>
If it can give a hint that is right 60% of the time, that's probably a win.
<InPhase>
D- solution is a pass!
<JordanBrown>
InPhase: your messages from 16m ago are finally making it to Matrix...
<InPhase>
Matrix delays are growing exponentially.
<JordanBrown>
Equating percentage-correct to a grade is a fallacy, a convention for test design.
<JordanBrown>
I can write a test with ten questions, where if you answer any one of the questions correctly you get a Nobel Prize.
<JordanBrown>
But now, as happens all too often, I must do an unspeakable thing. It's a four letter word, so I won't just say it, but it's an anagram of "row K".
Guest59 has quit [Quit: Client closed]
lastrodamo_ has joined #openscad
lastrodamo has quit [Ping timeout: 272 seconds]
<J1A84420>
JordanBrown there are cases where i want random and seeded mixed, e.g. i select a seed that gives a pleasant form but still want the position to be randomized
qeed_ has quit [Quit: qeed_]
qeed has joined #openscad
<linext_>
ok, i added a loop that checks syntax every 1 second
TheAssassin has quit [Remote host closed the connection]
<peepsalot>
i was trying to download the exact revision that the CI was using and browse it on my linux desktop, but can't find it
TheAssassin has joined #openscad
<peepsalot>
the log shows at one point: mingw-w64-x86_64-headers-git-10.0.0.r72.g1dd2a4993-1 i thought that the part after "r72." would be the commit hash, but didn't work
<peepsalot>
er, i guess I should have realized that g isn't a valid hex numeral. 1dd2a4993 is a valid commit
<peepsalot>
well, i'm not sure i'm up to filing a gcc bug. it was a pretty involved process last time
<peepsalot>
its not the type of warning I'd like to ignore though
<peepsalot>
that class of warnings should be build errors IMO
<InPhase>
Well only if they get them right! :)
lostapathy has joined #openscad
TheAssassin has quit [Remote host closed the connection]