<JakeSays>
i'd investigate using tools other than flex/bison
<peeps[zen]>
what about that parsertl that was recently used for syntax highlighting?
<teepee>
why standalone? it was always a wish to have the parsing part as library for more flexibility but language server might need some more infrastructure
<JakeSays>
teepee: what kind of infrastructure?
<teepee>
syntax highlighting only uses the lexer (lexertl) but there is the parsertl library too
<teepee>
handling multiple files, includes, finding references, all the stuff that's nice in the editor
<JakeSays>
that's all done in the language server
<teepee>
sure, you can always write things again
<teepee>
considering there's already a partially working language server, I would be sad to see another new effort starting, but who knows, if it works out that's great
<teepee>
also having it integrated would mean it picks up changes automatically, no need to add that in a separate application too
<JakeSays>
i looked at the existing language server. from what i can see it 'parses' by causing a preview update to happen
<peeps[zen]>
teepee: ah, right yeah that's what I meant. was there a particular reason lexertl was chosen in that case? seems odd to end up with a mix of different parser/lexer technology for different cases in the same project
<teepee>
it's code, it can be changed
<JakeSays>
teepee: a language server has the updates pushed to it from the editor. it doesn't have to watch
<teepee>
the "it works this way" never was a good reason for forcing a new project, but it's probably the most common one :)
<JakeSays>
every time a key is pressed in the editor the language server is updated
<peeps[zen]>
i just mean if it has some desirable advantages over flex/bison (e.g. being targeted for C++ not C) then maybe it would be nice to try consolidating on that lexer/parser stack
<teepee>
peeps[zen]: flex is a) annoying b) difficult to integrate and c) has no unicode support
ickk has joined #openscad
<teepee>
yes, that would be nice, there seems to be no chance flex is ever getting utf8 handling and using one of the fors is not ideal
<teepee>
lexertl has a neat c++ interface and the nowadays even c++14
<teepee>
I guess the only concern is that it's essentially a 1 person project, that said, I have no idea how flex is maintained
<JakeSays>
does parsertl support restarting?
<teepee>
I don't know
<JakeSays>
personally i prefer using DSL based parser generators.
<teepee>
I'm hugely impressed by boost spirit :)
<JakeSays>
that thing is a beast!
<JakeSays>
but it is very cool
<teepee>
true, but auto creating datastructures is hugely impressive stuff
<JakeSays>
i've had good luck with coco/r
<teepee>
never used it but seems quite powerful with multi symbol lookup
<teepee>
that single CGAL "make install" error did cost me a huge amount of hours to patch that everywhere
<teepee>
that's the point, use what *you* like, we have the options :)
<JakeSays>
yup
<teepee>
now don't come with Haiku yet :P
<teepee>
who knows...
<JakeSays>
haiku is an interesting project
<JakeSays>
i've used components of it in other things
<teepee>
yeah, I had a BeOS version of my emulator many many moons ago :)
<teepee>
supposedly they now support OpenGL via Qt
<teepee>
so OpenSCAD actually might be possible to run
<JakeSays>
what are your thoughts on vulkan?
<teepee>
it would be great if everyone would use it (and we would have a neat simple library to access it)
<JakeSays>
iirc angle sits over both vulkan and metal (or whatever that apple thing is called)
<teepee>
also I would like to express my usual disapproval to apple for being separatists... again.
<JakeSays>
lol that they are
<teepee>
hm? wasn't angle opengl on directx?
<teepee>
the apple thing is MoltenVK
<JakeSays>
it was, now it's opengl on *
<teepee>
supposedly faster than plain apple opengl
<teepee>
ahh, ok, so it can map opengl to different things
<JakeSays>
right
<teepee>
still general vulkan support would be cool
ferdna has quit [Quit: Leaving]
J2224 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
<peeps[zen]>
teepee: circleci builds failed on my pr, but not sure why. it says it was killed, is it possible we hit credit limits?
<peeps[zen]>
I read this: "Organizations on our Free plan receive a set amount of free credits per month for Linux open source builds. Using our Free plan and keeping your repository public will enable this for you. Open-source credit availability and limits will not be visible in the UI."
<teepee>
1h timeout?
<peeps[zen]>
like, gee thanks for the unspecified number of credits i guess?
<teepee>
sometimes builds get stuck
<peeps[zen]>
no, it was only 13m
<teepee>
hmm :(
<peeps[zen]>
also i saw it tried to post a build failure to freenode, but no idea where that is configured
<Scopeuk>
I wonder with that if we might be better off switching to a list of mappings only with an add button, hit add, press button to bind, chose function
<Scopeuk>
That would work arround the whole how many buttons is enough thing, more work though
<teepee>
yeah, probably, but that's quite some work to make it dynamic
Alexer- has quit [Ping timeout: 240 seconds]
Alexer has joined #openscad
<teepee>
argh, trying to find out why marlin 2.0.9.3 did not boot, finding offending commit, then finding out the tag has be recreated without that commit :/
<peeps[zen]>
teepee: like it got force-pushed?
<teepee>
tags are separate, but I think there was also a force push
<teepee>
but their branches are confusing anyway, there's a 2.0.x and bugfix-2.0.x but both get commits
Guest3938 has joined #openscad
Guest3938 has quit [Client Quit]
<Scopeuk>
ok that does seam bonkers
<Scopeuk>
the whole point of a fixes branch is it takes a back port of bug fixes against a fixed release
<teepee>
well, there might be a totally clear reason for what they are doing, it's just not transparent to me so far :)
<teepee>
just to state that in context, I'm happy about all the effort put into Marlin, I can't even imagine the stuff going on there with all the 3d printing stuff going on in the recent years
<peeps[zen]>
teepee: i'd like to use ninja with mxe cross builds. i added ninja to mingw-x-build-dependencies.sh, but I guess the circleci builds, running from docker containers, don't use that anyways
<peeps[zen]>
are the docker containers automatically rebuilt when commits are merged to docker-openscad? or do they need to be run manually somehow?
<teepee>
not built automatically anymore, even split into 5 pieces, it's still not really safely passing the 1h limit
<teepee>
which is why the file I linked earlier was called .circleci.yaml.diabled :/
<teepee>
I think it uses the build-deps.sh, I can trigger a local build but that will take a while
<teepee>
on circleci it took 6h, not sure what my good old PC will need
<peeps[zen]>
cpack has an annoying thing where it doesn't track dependencies properly with the default "Unix Makefiles" generator, so it does a full rebuild of openscad for each packaging (ZIP and NSIS for windows mxe)
<teepee>
did you checkin the change? not getting anything with git pull
<peeps[zen]>
no i haven't made changes to docker-openscad yet, still looking at things
<teepee>
oh, right the deps script is for MSYS2 builds, not MXE
<teepee>
so ninja needs to be added to the mxe-requirements I think
<teepee>
so it would use the native version, not sure if we would need a MXE built of ninja
<teepee>
it does exist as MXE package
<peeps[zen]>
teepee: well, mxe has a package for ninja, which is native
<teepee>
then it would need to go into the mxe-deps*
<teepee>
to actually build the MXE package
<peeps[zen]>
yeah i was using that on my dev machine: https://mxe.cc/build-matrix.html you can see the native checkmark in the rightmost column for ninja
<teepee>
hmm, I guess we then can just try to work with the debian installed version
<teepee>
I suppose that makes sense if the MXE configured cmake generates all the correct references, it should not matter what ninja build executes those
<teepee>
whops: Package 'ninja' has no installation candidate
<teepee>
I guess ninja-build is the correct one
<teepee>
also lets go with buildpack-deps:bullseye, shall we? :)
<J2224>
there is no way to get the name of a children() or ? and why ?
<teepee>
no, not yet, I started before with just ninja-build added
<peeps[zen]>
just trying to simplify by using nsis from MXE in all cases (before there was some confusing mix between native nsis and mxe nsis depending on 32/64 bits build) i don't think that is needed anymore
<teepee>
right, fine by me, just curious :)
nanoflite has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
I'll let it run through first, we can re-run with your changes applied and in the meantime find out if the build works
nanoflite has joined #openscad
<teepee>
I'll also merge the 2 deps builds again, I don't think we'll get circleci back
<teepee>
I did get some feedback but I don't really have much motivation to disucss with them
<teepee>
as fun side node, they do seem to have some internal escalation mechanism
<teepee>
I flagged the closing of the ticket as "not helpful" and got an update from (probably) someone up the chain, or some sort of "communicty manager" :)
GNUmoon has quit [Ping timeout: 276 seconds]
<teepee>
uff, who broke github? ;-)
<ccox_>
JakeSays: that works. Are you just dealing with visible light, or do you need IR or UV? I use a lot of different fibers (plastic and silica) to bring light to spectrometers for various measurements/experiments.
<teepee>
ok, pushing the x86 images, there was a download issue with one of the i386 builds
<teepee>
so I guess we can restart the 64 build and I'll trigger another build for the latest docker setup
<teepee>
will take a minute to upload the gigabytes :)
<teepee>
right, make that a huge number of minutes :D
<InPhase>
peeps[zen]: It's been far more than a decade since the vast majority of computers were 64-bit. The latest Windows doesn't even come with 32-bit support anymore.
<InPhase>
If you have a 32-bit system in 2022, you'd probably have to run Linux on it just to have a chance at it being a sensibly usable system.
<teepee>
I guess we could just comment out the 32-bit version on the download page and see what happens
<teepee>
I used it for a while for testing with wine
<teepee>
but now there's also a wine64 by default, so that's good
<teepee>
and last image uploading... another 1.3gb
<teepee>
ok, looks like it finally pushed everything