<waddlesplash>
in my testing, this doubles GLTeapot's FPS, among quite a lot of other latency reductions
<waddlesplash>
these changes were pretty challenging to get right, I debugged a lot of very frustrating deadlocks while writing them. the end result is obviously worth it, though
orealis has quit [Read error: Connection reset by peer]
orealis has joined #haiku
orealis has quit [Read error: Connection reset by peer]
orealis has quit [Read error: Connection reset by peer]
orealis has joined #haiku
<Begasus>
forum got an update too or related to your work nielx[m] ?
<Begasus>
nvm, saw it just now :)
OscarL has joined #haiku
Begasus_64 has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
Hi Begasus. Tried using "LD_PRELOAD=/boot/system/develop/lib/libpython3.9.so ./CudaText" yet?
<Begasus>
OscarL, did that the other day and yes it works (need to check that again on 64bit though)
<Begasus>
but why doesn't it need it for python37?
<OscarL>
no idea, really.
<OscarL>
no relevant change (on the recipe side of things at least) between those versions.
<OscarL>
but can't really tell what else might have changed from the configure/make side of things.
AmyMalik is now known as Reinhilde
<OscarL>
(or from one of the dependencies, for that matter)
<Begasus>
the 32bit version is at the depot, maybe you could debug it somewhere there? :)
<OscarL>
I saw you had to add iconv, or something like that for the 32 bits one, right? That fixed the "symbol missing" errors there?
<Begasus>
that's still using python3.9
<OscarL>
or there was some other fix?
<Begasus>
the iconv was missing from the package recipe (policy error)
<Begasus>
the actual linking error with ivonv is in fpc source (which is fixed in the one at haikuports but not upstreamed)
<OscarL>
all "a bit" over my head, really. Not really good with linking / .so issues :-/
<Begasus>
well no need to think about iconv, that's fixed :)
<OscarL>
and all relevant packages on your 64 bit install reflect that already, right? (trying to rule out things, just in case).
<OscarL>
if that LD_PRELOAD thing works on 64 bits, I would think that possibly there's a mismatch on where CudaText tries to load libpython3.9.so from, and where the C extensions (Python modules as "math" for example) do.
<OscarL>
Maybe either CudaText or the modules have a hardcoded "rpath", something like "/packages/[blablalbla]/lib/libpython3.9.so" vs /system/[..]/libpython3.9.so vs just "libpython3.9.so" and let the OS search for it.
Begas_VM has joined #haiku
<Begas_VM>
on 32bit now: ERROR: Exception in CudaText for cuda_prefs.dlg_cuda_options: ModuleNotFoundError: No module named 'cuda_prefs'
<OscarL>
(it modifies the binaries, so, make backups before trying it)
<OscarL>
btw, Begasus, you can upload binaries and use those for github Releases, no need to add them in the git repo. and you coulld use a .gitignore fie for all tose .o and .ppu files too :-D
<Begas_VM>
the hpkg for 32bit is already on that release note (only got the src.tar.gz for creating the package with the recipe :)
<Begas_VM>
but I could just as well grab it through srcGitRev (as I'm doing atm still for 64bit)
<Begas_VM>
reboot
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
damn... uninstalled Python 3.7.16... and ends up being that I also have Python 3.7.14 still installed ?!?!?
<Begas_VM>
lol
<Begas_VM>
had that a while ago after an update for imagemagick, oh and 2 different python3.9 packages installed
<OscarL>
Seems like I had an older CudaText too.
<OscarL>
no more 3.7 installed, and new CudaText still starts ok.
<OscarL>
with those "resolve symbol" messages, but it finds Python 3.9.17
<OscarL>
and it starts much faster now
<OscarL>
(fixed the chrpath recipe)
<Begas_VM>
still getting that module not found
<OscarL>
I'm tempted to use that SYS:ENV trick, to set LD_PRELOAD for CudaText binary :-D
freddietilley1 has joined #haiku
<OscarL>
can't change it with chrpath, because "/system/develop/lib/x86" does not fits on the 14 bytes is has available for that :-/
freddietilley has quit [Ping timeout: 480 seconds]
<Begas_VM>
should be there ... /boot/home/CudaText_up/src/CudaText/app/py/cuda_prefs
<OscarL>
the error is misleading.
<OscarL>
it is not that it does not finds "cuda_prefs", rather, there's an error when loading that module.
<Begas_VM>
oh ... :/
<OscarL>
the error being... some thing in there needs a symbol from libpython3xx,so... and it can even find the dam library.
<Begas_VM>
sticking to python3.7 here for the time being, no use in keep switching version untill I can load that module (did work on 64bit)
<OscarL>
I rather use LD_PRELOAD than require anything older than the default Python version on Haiku but... not my call :-)
<OscarL>
the problem is not on cuda_prefs in particular, I think. it will fail whenever you try to make it use one any functionality that relies on python extensions.
<OscarL>
"Plugings->Addon Manager -> Install..." for example.
<Begas_VM>
right, seeing that too now
<OscarL>
Something it's either not linking to libpython3.9.so as it should, or some library search path gets screwed.
<OscarL>
possibly because CudaText (or some of its components, or ones from Lazarus/fpc, I don't know) is specting some Linuxy behaviour that we don't follow.
<OscarL>
but that's the extent of what I can figure out, sadly. Maybe one of the other porters/devs with more experience can chime in?
<Begas_VM>
aha!
<OscarL>
I don't know now it starts the python interpreter, for example.
<Begas_VM>
got it to work :)
<OscarL>
s/now/how/
<Begas_VM>
seems it needs the py directory in settingsdir (read-write probably?)
<Begas_VM>
symbol not found with python3.9
<OscarL>
unrelated but... do we really need $dataDir/cudatext/lib/i386-haiku on the package?
<Begas_VM>
haven't changed that from the original work roided did
<OscarL>
those files there seems to just be intermediary/artifact files from the compilation process, not something that should be really needed after CudaText is generated (I think, at least :-D).
<Begas_VM>
aren't those plugins or so?
<OscarL>
AFAICT, no. just like .o for a .cpp.
<OscarL>
but in this case... .pas -> .ppu -> .o
<Begas_VM>
checking repology ...
<Begasus>
not much there (we're ahead on the others though) :)
<Begasus>
but looking at the source there is no lib directory, so created during build
<OscarL>
and then all that gets copied under ~/condig/settings/cudatext ?
<OscarL>
that dir being read-only shouldn't matter that much, AFAIK, from Python's side. It means it looses a bit of performance, as it can't save the compiled bytecode, but should work still.
<Begas_VM>
(going to need to clean those screenshots once I'm done) :)
<OscarL>
(Python normally creates a __pycache__ dir and puts the .pyc/.pyco there for each package/module)
<Begas_VM>
well, the "import" part seems to work now for python3.7
<OscarL>
(our _python3x packages already include the "precompiled" bytecode files, to speed up things for the matching Python version)
<Begas_VM>
still left with https://bpa.st/KMLJM when checking other python versions
<Begas_VM>
so the import seems to work there too, but fails with a missing symbol
<Begas_VM>
that FD_PRELOAD probably fixes for you
<OscarL>
yes.
<OscarL>
Again, not sure how CudaText (or that python4delphi) loads/start the Python interpreter, or what things it is doing that work on 3.7 but not on the others.
<OscarL>
could be as simple as one of those chdir() fixes, or something more complex, but I can't tell.
<Begas_VM>
np, thanks for brainstorming, at least I know how to "fix" this for now with python3.7
<Begas_VM>
still strange it worked for 64bit though (without changes) (with python3.7) :)
<OscarL>
didn't it worked for 3.7 already? what did you fix for it?
<Begas_VM>
nothing on 64bit, on 32bit reverted the look for the py directory
<Begas_VM>
and cp'd it to settings
<OscarL>
leaving it under settings should make it a bit faster (and also allow to use more than one python version, either with LD_PRELOAD, or when we find the issue and fix it)
<Begas_VM>
well, it probably solves installing plugins too for python
<ermo[m]>
Does Haiku have redshift-like functionality at this stage?
zard has joined #haiku
<zard>
Hello
<zard>
Hopefully my internet works better than it did yesterday
<Begas_VM>
hope for you too zard :)
<Begas_VM>
k, sticking with python3.7 for now OscarL, not going on a witchhunt when it's working ok
<OscarL>
ermo[m]: not built in, and I don't know of any third party tool for that either.
<ermo[m]>
thanks =)
<ermo[m]>
is the underlying display code even "ready" for that kind of thing...?
<OscarL>
Begas_VM: as you see it fit. I guess I'll just have to use a hacked up version, as I'm not going back to installing 3.7 just for CudaText (already left it due to its usage of 3.6 last year :-D)
<Begas_VM>
for now can live with that OscarL (untill a sollution pops up) :)
<OscarL>
not sure ermo[m]. Don't think there's a "compositor" yet. Better ask one of the devs :-D
<OscarL>
the solution is SYS:ENV atrribute with LD_PRELOAD, IMO, but.... time for me to go to sleep :-D