<peepsalot>
teepee: was that error only on the 32bit version?
<teepee>
no, it's on both builds
<peepsalot>
and this is from running a local docker setup with the same dockerfiles from circle-ci ?
<teepee>
yes, same base image, but the local setup is just a "normal" docker build, where the CircleCI build is from .circleci/config.yml
<teepee>
but as far as I can see the commands are same only some extra stuff on circleci to grab build variables and such
<peepsalot>
could it possibly depend on the host system's charset?
<Andy-pants>
or locale
<teepee>
yeah, quite possible
<Andy-pants>
I've definitely banged by head against that in the past when working with Docker.
<teepee>
local has en_US.UTF-8, let me just try with latin1
<peepsalot>
are dockerfiles not run in vms? i haven't messed with it in a while. if its in a VM, i wouldn't expect the host system setup to possibly affect docker
<teepee>
no idea how docker does that, would make sense that it's doing the build in a container too
<Andy-pants>
peepsalot: They are not. They use the same kernel as the host system for execution only. All the settings and other things are defined within the context of the container.
<Andy-pants>
Which is why they're called containers. :D
<peepsalot>
I think I meant "codepage" rather than charset, not that I really know the difference
<peepsalot>
Andy-Pants: hmm, docker on windows uses hyper-v though i think
<Andy-pants>
It's getting into the weeds, but a charset is the entire potential set of characters that can be encoded, and the code page is the actual encoding/mapping of those characters to binary values.
<Andy-pants>
peepsalot: Just to be absolutely sure. You're using the Hyper-V backend which uses windows containers, and not the Windows Subsystem for Linux 2 backend which uses linux containers?
<Andy-pants>
(NOT CONFUSING, AT ALL)
<peepsalot>
i'm not currently using docker at all, but just remembering from last time I messed with it on windows a few years ago
<peepsalot>
but iirc, installing docker required me to enable virtualization in bios
<Andy-pants>
Technically, WSL2 uses Hyper-V for it's virtualization
<Andy-pants>
Yep, exactly
<Andy-pants>
Sorry, I'm just reading through the logs catching up on the convo right now
<Andy-pants>
teepee: Are you still working through the issue?
<teepee>
waiting on the build to finish
<Andy-pants>
Because, I'm fairly confident what caused it.
<teepee>
same error
<peepsalot>
teepee: in .circleci/config.yml: export LC_ALL=C.UTF-8
<teepee>
ah, I'm all ears
<teepee>
oh, indeed, LC_ALL
<Andy-pants>
yep, that was I was just about to say :D
<teepee>
and that's inside the build
<Andy-pants>
Since the æ character is in the UTF-8 extended character set, it NEEDS all 8 bytes to be encoded. Whereas ASCII is a 7 bit encoding, and while Windows-1252 is 1 byte, it doesn't cover very much.
<Andy-pants>
Actually, it might need more than 8... I need to look into that. But, what's happening is that your windows system is trying to read a UTF-8 character, into a smaller character set, upon which it barfs, and splits it up into two characters `<C3><A6>` from the logs.
<Andy-pants>
It effectively maps it the best it can into it's system local charset
<teepee>
yep, build successfull. nice!
<teepee>
full rebuild coming up again :)
<Andy-pants>
On windows?
<teepee>
no, I'm building on an old linux server here
<Andy-pants>
ahh, ok :)
<peepsalot>
<teepee> it also packages the venv folder, but I guess we could remove that by just passing the TESTS=NO flag as we are not running them anyway
<peepsalot>
do you mean ENABLE_TESTS=OFF in the top level CMakeLists.txt ? that would strip tests entirely from the install, and hence the packaging
<teepee>
oh, hmm
<peepsalot>
well all that variable does is guard a add_subdirectory(tests) call
<teepee>
yeah, makes sense
<teepee>
I guess it's not hugely critical if there's some extra files, but having a clean package would be nice too :)
<peepsalot>
dunno what should be done about the venv stuff (assuming you want a package with tests included still)
<peepsalot>
hmm, the whole packaging of tests was before venv complications. the way it is setup I don't think the test configure step gets run on windows. there's a lot of path delicate path string replacement that has to go on to make it even work that way
<peepsalot>
so, somewhere a script may need to manually set up that python venv stuff for the windows user prior to running the test suite.
<peepsalot>
s/manually //
<peepsalot>
PATTERN "venv" EXCLUDE
<peepsalot>
and adding ^ that line ^ to that tests dir install command
<peepsalot>
or, i guess that would actually correspond with the tests-build install command below that
<peepsalot>
what command creates that venv directory? i don't see venv mentioned anywhere in the source
<peepsalot>
oops, was looking at an out of date local branch
<peepsalot>
i'd have to do some testing on my windows box to see how things go with the new python3-venv changes, and packaged tests. maybe this weekend
<teepee>
cool, it's not urgent, just found that while getting things updated for the Manifold stuff
<peepsalot>
i just checked the venv dir on my linux box, and its 99 MB. so yeah it would be good to omit that from the archive
<Andy-pants>
yeah, venv folders can get out of hand pretty quickly.
<Andy-pants>
And then you multiply that for every version of python you're testing against.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
teepee: Already? I thought that would take longer.
<InPhase>
ochafik is a machine.
<teepee>
yes, it's very amazing work. as bonus he did know exactly the structure as it's essentially a structural copy of the fast-csg work
<InPhase>
:( Build fail.
<teepee>
not that I'm trying to belittle that in any way, it's still a huge amount of work and focus on details, including getting pretty much all of the platform builds prepared
<teepee>
you need git submodules update --init --recursive
<InPhase>
Right, recursive.
<teepee>
and I'm not sure if the thrust patch is applied automatically via a normal cmake build
<InPhase>
And a new "tbb" dependency...
<teepee>
right + libtbb-dev on debian but he even added that for all the distros to uni-get-dependencies.sh
<InPhase>
*thumbs-up*
<teepee>
it would be better to have manifold as library instead of submodule, but I suppose that will take a couple of years
<InPhase>
If this works reliably I prefer the "let's not wait" option. :)
<InPhase>
Building.
<teepee>
agreed
<InPhase>
So I'm currently wanting to cross-compare preview and these manifold builds. Because fast-csg was already super close to preview on many designs.
<InPhase>
And I really favor the option of a future state where we get color into render, and end up with one true path into a rendered state.
<InPhase>
That motivation will be strong if it ends up faster. :)
<InPhase>
15-30 seconds added to my build times.
<InPhase>
I guess that's fair.
pbsds6 has joined #openscad
pbsds has quit [Ping timeout: 250 seconds]
pbsds6 is now known as pbsds
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
joe has joined #openscad
joe is now known as Guest2758
Guest2758 has quit [Client Quit]
kintel has joined #openscad
<kintel>
buZz: If you're still around. Try now. I found one bug, and it should now fail cleanly.
<kintel>
I don't have an GLES2-only device myself, except RPi 1, but cmake doesn't like the OpenGL installation there..
<buZz>
alrighty
<buZz>
kintel: you can run plain debian on the pi1 , should help
<buZz>
kintel: ah, more output now , SegFaults after 'Rendering using legacy (immediate mode) OpenGL'
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
buZz Thanks, that's another bug. It's choosing the wrong rendering path. wups
<kintel>
^ Fixed now
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
<buZz>
lets see :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
teepee: Well, something is amiss... I loaded a heavy design which previews in 12 minutes on the last release and then is fine. The latest master branch version has been at 100% cpu for 2 hours now.
<InPhase>
I will investigate more later... I didn't even get to the point of opening the settings and turning on Manifold, so I don't have an explanation yet.
<InPhase>
I was just trying to open it!
<teepee>
hmm, odd indeed
<teepee>
I only tested a couple of designs and found no strange effects
<InPhase>
teepee: I killed it, started with a blank design, turned on Manifold, and now it is working okay. In fact it has made this preview lightning fast as well, apparently because it had to do some implicit render steps in there.
<guso78>
teepee , you are omnipresent, are you ?
<teepee>
nope
<InPhase>
teepee: There must still be some sort of anomaly but I'm not sure what the reproduction process would be. I'll keep an eye out for it.
<InPhase>
I will certainly say this is fast.
<InPhase>
And... fails a bit.
<InPhase>
"ERROR: [manifold] Input mesh is not closed! ERROR: [manifold] Surface_mesh -> Manifold conversion failed: NotManifold"
<InPhase>
I figured this would be a good stress test. I'll post an issue.
<guso78>
teepee, i spent two days already on debugging one single ctest testcase in my texture branch. the actual output is much brighter than it should be. i do have an extended fragment shader. buts texture influence is *only* 0.00000001 and still the actual png is WAY off. extracting a tiny testcase of it appears literally impossible with size of
<guso78>
openscad. any hints on how to debug that ?
<guso78>
is there something like a opengl record and replay feature ?
<teepee>
yes, renderdoc
<guso78>
i will browse renderdoc, thank you !
<linext>
is it possible to put a reference image as the background in openscad?
<teepee>
no
<teepee>
there's a feature request, but I've not seen any code for that yet
<buZz>
linext: just tape it on your monitor :D
<buZz>
hehe
<buZz>
kintel: oh , forgot to tell you , it no longer SegFaults!!!
<InPhase>
Ship it!
<buZz>
kintel: now ends with 'GLSL 100 es shaders not implemented'
hisacro has quit [Ping timeout: 252 seconds]
<guso78>
literally also interesting to me ... : cmake -DCMAKE_BUILD_TYPE=Debug .
kintel has joined #openscad
hisacro has joined #openscad
<kintel>
guso78: A common issue when textures are too bright is sRGB vs. linear encoding. This can be particularly important if you write your own shaders
<kintel>
buZz: Thanks! I'll implement the GLES2-compatible shaders and ping you again :)
<buZz>
<3 coolio
<guso78>
kintel, if i add my texture color with scale 0.0 , the output is OK . (probably because its optimized away) if i add my texture color with 0.000001 the output is WAY too bright. it appears to me, that the texture color contains NaN. but stackoverflow community meant, it was nonsense ...
<kintel>
That sounds like a different issue; sRGB vs. linear results in brighter textures, but the effect is relatively subtle
<guso78>
i am temped to create an ultimate testcase on it but i am not sure, if anybody has time to look into it.
<guso78>
also it only happens only with -o (exportpng) and never with the GUI
<guso78>
.. and only when using the --enable=vertex-object-renderers
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
guso78 That can be tricky to debug. It's sometimes easier to just write a stand-alone OpenGL program to isolate the behavior..
<guso78>
kintel, the ctest which failed created a png file for some simple CSG operation. i would not be able to replicate this functionality in a simple testcase. so my plan was to printf all gl Commands onto the command line, but now i am still struggling with glBufferSubData magic which cant just use a single integer argument ...
<guso78>
openscad assembles the VBO buffer in 4, 12 or 16 byte chunks most of the time ... so it takes lot of commands until buffer is complete :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<guso78>
here is my issue on stackoverflow which explains the details of the issue.not sure if its acessible as stackoverflow has disabled my questin due to lack of a testcase
snaked has quit [Quit: Leaving]
castaway has quit [Ping timeout: 250 seconds]
<InPhase>
teepee: Yeah, something definitely amiss. The master branch is randomly just 100% cpu freezing on me.
<teepee>
that's not good :(
<InPhase>
I don't know if I should bundle this in the same issue though.
<InPhase>
I don't have clarity on if it is the same problem, because it appears even if Manifold is turned off.
<InPhase>
But... I didn't see the behavior before today.
<InPhase>
However I also haven't loaded this old design in a while.
<teepee>
hmm, I did upgrade the platform stuff so that could be the reason too