<tpw_rules>
(imgui package which is already compiled for the web)
<whitequark[cis]>
I don't think I really want to use C++ either?
rpavlik[m] has joined #glasgow
<rpavlik[m]>
yeah egui is pretty decent, I use it for one thing. Accessibility is allegedly there but I haven't gotten windows screenreader to work on it...
<tpw_rules>
whitequark[cis]: there are python bindings; i don't know if they work with emscripten
<tpw_rules>
that might also start to get outside the bounds of reasonable performance
<whitequark[cis]>
:/
<whitequark[cis]>
python+(presumably wasm)+emscripten+some c++ library is a jenga tower i'm not willing to maintain
<whitequark[cis]>
considering there's also the existing python+(presumably wasm)+usb jenga tower
<whitequark[cis]>
tbh i got fed up with "just use imgui" a few years back when i maintained solvespace, where people loved to propose that as a solution because they got infatuated with imgui or something and for no particularly well motivated reason
<galibert[m]>
imgui design looks nice, at least when immediate is appropriate
<whitequark[cis]>
i think it's a nice useful library
<galibert[m]>
imgui visuals are nothing to write home about though
<whitequark[cis]>
the problem i have is people getting weirdly fanatical about it
<whitequark[cis]>
like, i get it if you get that fanatical about using imgui in your code. but if you get like that about some other project, which you don't maintain, using imgui? no.
<galibert[m]>
yeah, if at least it looked spectacularly good :-)
<tpw_rules>
i'm not particularly fanatical about it, just sharing that i'd seen it
<whitequark[cis]>
I feel like a declarative UI abstraction (not just GUI, but CLI too) plus an escape hatch for "just grab the underlying UI object" is a good direction
<tpw_rules>
is that how egui works?
<whitequark[cis]>
so the base functionality works across (hypothetically; doesn't have to be specifically these) CLI, Qt, and web, and then people who build one-off application specific tools can grab e.g. the Qt handle from underneath
<whitequark[cis]>
CLI, Qt, and web are all well covered via ... idk, click or something, PyQt/PySide, and Pyodide
<whitequark[cis]>
PyQt is kind of a pain but so many people use it that it's at least well understood pain, relatively speaking
<whitequark[cis]>
we do need some declarative UI abstraction to have the CLI/GUI unification, anyway; might as well slap some HTML on top if we have it, it's not that much effort to style half a dozen basic widgets
<whitequark[cis]>
(famous last words)
<whitequark[cis]>
we could also use PyQt+Wasm, but I think that experience is kind of miserable, so probably not
<whitequark[cis]>
not sure what egui uses
<galibert[m]>
egui seems to be doing its own thing
<rpavlik[m]>
yeah egui is one of those "i shall ignore the OS and render everything in OpenGL"
<tpw_rules>
which, kinda bleh
<rpavlik[m]>
yeah
<esden[m]>
It is consistently not OS widgets. Instead of desperately trying and failing to look native ...
<tpw_rules>
yeah there are worse ways to do it but i find imgui bleh for the same reason
<tpw_rules>
for some apps it's good but i wouldn't say opengl is the right choice for glasgow
<galibert[m]>
What's "native" is windows is an open question
<esden[m]>
I would actually argue that GL aka "fast renderer" is actually a good idea for glasgow. How I see the gui is as a realtime visualizer. Graphs, data streams. This is where I would need a GUI, otherwise I can just munge text files on the command line too.
<esden[m]>
but I don't think the purpose and goal of the GUI was discussed yet.
<tpw_rules>
i personally see it more as control
<esden[m]>
sure, but that is just the beginning In my opinion. But it is up to WQ to decide the direction.
<esden[m]>
Logic analyzer software has control too, but it is only a part of what it does.
<esden[m]>
the data visualization is a big part of it and a very important one. Is that not necessary / desired for Glasgow? Is the data going into some black hole after you configure it?
<tpw_rules>
that's like 1% of the applets though. to perhaps needlessly exaggerate, should we bring in audio libraries for the OPL applet? dosbox for the floppy applet?
<esden[m]>
We don't have currently applets that consider the existence of a UI.
<esden[m]>
thus the percentage of those that would benefit of a UI is minimal.
<whitequark[cis]>
I don't think Python is very well set up to do data processing and GL pipelines
<whitequark[cis]>
you'd have to heavily use numpy and possibly numba, both of which I would strongly prefer to avoid
<whitequark[cis]>
well, mainly numba
<galibert[m]>
Numpy, that’s the thing used for gpio, right ?
<whitequark[cis]>
huh?
<galibert[m]>
Some days ago in amaranth :-)
<whitequark[cis]>
gpio? I have no idea what are you talking about
<esden[m]>
Ok fair enough.
<tpw_rules>
i've just written gl shaders for that...
<whitequark[cis]>
mm, I guess
<whitequark[cis]>
that's a really narrow skill set though and I can see it being difficult to maintain
<tpw_rules>
that's fair
<tpw_rules>
i <3 numpy tho
<whitequark[cis]>
so it's hard to justify it being a core part of Glasgow
<whitequark[cis]>
numpy is alright
<whitequark[cis]>
numba (the LLVM compiler) is kind of an abomination
<whitequark[cis]>
* (the LLVM based JIT compiler) is
<tpw_rules>
yeah that scares me. i keep thinking about it
<tpw_rules>
but a runtime dependency on llvm at best is uh
<galibert[m]>
Oh, it was mmio, not gpio
<whitequark[cis]>
I have spent many unhappy evenings digging through their buggy LLVM codegen
<Wanda[cis]>
whitequark[cis]: there was something absolutely cursed about someone using numpy uint32 type to poke mmio and getting surpirsed it's not a proper volatile access
<tpw_rules>
oh yes that was me
<tpw_rules>
:3
<whitequark[cis]>
galibert: numpy is not actually suitable for gpio stuff
<whitequark[cis]>
tpw_rules is just doing crimes. don't listen to them
<galibert[m]>
huhuhu
<tpw_rules>
sadly ctypes doesn't have a volatile option
<galibert[m]>
(dayjob is AI systems evaluation, I actually know about numpy :-) )
<whitequark[cis]>
tpw_rules: I think you don't actually need volatile with ctypes
<whitequark[cis]>
volatile works on the C memory model, but ctypes does not really use the C memory model
<tpw_rules>
and numpy does?
<whitequark[cis]>
numpy has volatile?
<tpw_rules>
uses the c memory model
<whitequark[cis]>
no
<galibert[m]>
you don't really care about the C memory model when you're initiating from python, only the cpu matters
<tpw_rules>
exactly
<galibert[m]>
as long as your mmio range is uncached you're good
<whitequark[cis]>
galibert: I don't think numpy guarantees access widths
<galibert[m]>
you just want the access to respect the access width
<whitequark[cis]>
which is the other thing you care about
<galibert[m]>
yeah we agree
<tpw_rules>
and ctypes does?
<tpw_rules>
i guess it would sort of have to
<tpw_rules>
for writes at lest
<whitequark[cis]>
I would be very surprised if reading a c_ulong resulted in a torn access
<whitequark[cis]>
if ctypes somehow does a torn access, I could at least convincingly motivate that this is a bug
<whitequark[cis]>
if numpy does a torn access, you get to keep both pieces
<whitequark[cis]>
the way I would probably actually do it is just load some shellcode
<tpw_rules>
i feel like that's less supported
<tpw_rules>
i guess you could write out a .so and then import it
<tpw_rules>
or use ctypes
<whitequark[cis]>
... with ctypes, yes. a one line c function with the volatile read
<tpw_rules>
why would you do that as shellcode and not something like cython
<whitequark[cis]>
oh, right, cython exists
<galibert[m]>
otherwise, mmap seems to work too
<whitequark[cis]>
I know I can mmap and then shove a mov into the region
<whitequark[cis]>
and it doesn't depend on anything besides being able to mmap and call functions
<Wanda[cis]>
Catherine: so, by Glasgow documentation rules, do I need to stuff a copy of prjcombine docs into the archive repo and give it an accession number?
<whitequark[cis]>
hm
<whitequark[cis]>
I... um...
<whitequark[cis]>
yeah
<Wanda[cis]>
... well, I suppose that can be done
<_whitenotifier-3>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-502-d2ec0c55f82a9c74a31879b2be0a20068ecb6191 - https://github.com/GlasgowEmbedded/glasgow