<Begasus>
still keeping track on Haiku's progress? :)
<Begasus>
k, bulk build for KF6 now :D
Nephele has joined #haiku
<Begasus>
Hi nephele! :)
<Nephele>
Hello Begasus
<Nephele>
how are you?
<Begasus>
fine here nephele, not needing to kill the deamon now :)
<Kokito>
Begasus, testing Beta 5 on my old laptop
<Begasus>
+1 Kokito, things going good so far?
<Kokito>
Yep Begasus. So far, so good.
<Begasus>
don't think there is some major issue with Haiku itself (give or take a few exeptions)
<Nephele>
Begasus: my computer can't boot with beta5
<Begasus>
probably some more problems regarding ported software
<Begasus>
ouch nephele :/
Kokito has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
HW issues?
<Nephele>
I doubt it, beta4 worked fine
<Begasus>
bughunting then
<Begasus>
think I'm due to new reading glases :)
<Begasus>
that or increase font size in Haiku :D
<Begasus>
can't check cairo atm x512[m] :) (KF6 suite building)
<Begasus>
OscarL! still sleeping?
<Begasus>
getting a crash on python with some recipes (doesn't brake builds ... but still), with this cmd: /bin/python3.10 -c "import lxml; from lxml import etree; print(lxml.get_include())" 2>&1
Begas has joined #haiku
Begas has quit []
<Begasus>
k, crashing on clean image also
<Nephele>
hmm, my issue dissapeared
<Nephele>
damn magicians
debaser has quit [Ping timeout: 480 seconds]
diver has quit [Read error: Connection reset by peer]
Coldfirex has joined #haiku
<Begasus>
:)
<Begasus>
30 recipes to go ....
tuaris has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
* OscarL
wakes up after dreaming of Begasus yelling about some bug related to Python.
<OscarL>
Oh.
<Begasus>
g'morning OscarL!
<OscarL>
Hola Begasus :-)
<OscarL>
`python3 -c "import lxml.etree"` is enough to trigger the crash.
<Begasus>
not sure it's a bug, but still, seen it a few times
<OscarL>
I don't have the skills to deal with pthreads/mutex issues, Begasus. You should open a ticket, attach the crash .report, and "@" Adrian, Augustin, or Jérôme.
<Begasus>
at haikuports OscarL?
<OscarL>
yes, was about to type that, darn gloves.
<Begasus>
didn't see it with beta4
<Begasus>
will do later, when KF6 is done
<OscarL>
I guess we could try just rebuilding lxml
<Begasus>
could check that too here
<Begasus>
still 20 to go
<Begasus>
it's easy to reproduce, so you could have a go at it also OscarL :)
<OscarL>
that's what is masking the issue you're having, and allows you to boot without having to manually kill package_daemon
<Begasus>
oh, that seems to be fixed OscarL
<OscarL>
(that's my understanding, of course)
<Begasus>
didn't have to kill the deamon this morning after full-sync
<OscarL>
that's why I asked if you were on hrev58000 :-)
<OscarL>
k, let's try rebuilding lxml.
<OscarL>
on the Python patchsets, there are a couple of those "try... catch all... return like if nothing happened" that, while "work", tend to be a nasty footgun when you're trying to debug things.
<OscarL>
I'm going to remove them from subsequent .patchsets (assuming my proposed changes get accepted, of course :-D)
<OscarL>
HaikuPorter still had a few last time I've checked. :-/
<OscarL>
lxml compilation is slooow (2x, because I forgot to disable the 3.9 package for this test build :-D).
<Begasus>
3 to go ... catching up on the forum in the meantime :)
<OscarL>
waddlesplash: thanks for the info. Can't find neither PTHREAD_MUTEX_INITIALIZER or pthread_mutex_init in lxml sources (will look on libxml2)
<waddlesplash>
well, check how the thread mutex objects are initialized then
<OscarL>
(libxml2 does seems to use PTHREAD_MUTEX_INITIALIZER at least)
<waddlesplash>
it's also possible the initialization was done correctly and then the memory was overwritten
<waddlesplash>
seeing what the value is may help here
<jmairboeck>
perl at least has some compatibility code (not used on Haiku) where mutexes are explicitly zeroed on initialization on some systems, maybe something similar is going on here?
<Begasus>
re
<waddlesplash>
oanderso[m]: hmm I see PulkoMandy's comment on your timers change. it is possible that XHCI is the first driver to initialize which depends on timer interrupts actually working. Everything before that which sets the timer may be fine if the timers never go off
<waddlesplash>
like the thread scheduler, which just won't interrupt threads when their quantum ends
<waddlesplash>
if it never gets the timer interrupts it sets
<OscarL>
I can't find anything *directly* using pthreads mutex on lxml side of things. So I assume the issue is between some of the PyThread_*_lock() functions and libxml2. But this is all waaay over my head.
<OscarL>
I think I'll have to throw in the towel on this one, Begasus. Sorry.
<waddlesplash>
oh
<waddlesplash>
how does PyThread_lock initialize mutexes?
* OscarL
has negative amounts of clues here :-)
<OscarL>
the amount of "#ifdef"s around threading/GIL/mutex on all of this makes my weak brain hurt.
<Begasus>
waddlesplash first off, thanks for the "fix" , didn't have to kill the deamon this morning after a full-sync :)
<waddlesplash>
Begasus: yeah I wondered if the changes yesterday would solve the problem outright
<waddlesplash>
either that or they would at least get us a full crash report
<waddlesplash>
good to know :)
<Begasus>
still have that "KDL" message on launch though :)
<Begasus>
that/an*
<OscarL>
from etree.pyx: "# global per-thread setup" "tree.xmlThrDefIndentTreeOutput(1)", that funtion from libxml2 calls "xmlMutexLock(&xmlThrDefMutex)". The latter is a global mutex.
<waddlesplash>
Begasus: you do? does it show up in the syslog?
<waddlesplash>
OscarL: does anything initialize that mutex?
<waddlesplash>
if not, there's the problem
<OscarL>
seems that's initialized on xmlInitGlobalsInternal.
<OscarL>
and that is called from xmlInitParser().
<OscarL>
etree.pyx has "# initialize parser (and threading)" calling that :-/
<phschafft>
donky time.
<OscarL>
heh, but only AFTER it calls tree.xmlThrDefIndentTreeOutput(1)
HaikuUser has joined #haiku
* OscarL
tries moving things around a bit.
<Begasus>
waddlesplash, will try to grab some more infromation in the morning, other stuff atm here, and dogschool later :)
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
<waddlesplash>
OscarL: if it's used before first init this sounds like a bug that should be reported upstream
<OscarL>
I'll let you know if things change after the build ends (darn etree.c file of > 10 MB! :-D ).
<OscarL>
in the meantime... I'll check if newer lxml versions still use the same code.
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
heh, fixed in neweest version.
bjorkintosh has joined #haiku
<Begasus>
me wonders if this wont bite us, lib:libopenal$secondaryArchSuffix (uses Qt5 in use by Qt6Multimedia ...)
<OscarL>
lxml >= 5.0 calls xmlparser.xmlInitParser() before xmlThrDefIndentTreeOutput(1), so we should probably just update our lxml Begasus.
<OscarL>
wrong order used up to 4.9.4
<Begasus>
go for it :)
<Begasus>
not getting anything upstream thing done today :)
<OscarL>
mmm, we build lxml without cython so it used the big etree.c without my changes on etree.pyx :-/
<Begasus[m]>
whohoo! :D NeoChat 24.07.90 still running :D
<OscarL>
good thing Pe handles that 10+MB .c file just fine :-)
<Begasus>
jikes, no fun in hunting down something there
<OscarL>
one cpu core is begging for mercy while compiling it.
<OscarL>
confirmed, moving that xmlInitParser() earlier fix the issue with our current lxml.etree.
<OscarL>
waddlesplash: ^^^. Thanks!
<OscarL>
Begasus: now... what uses lxml? (don't want to break things further if > 5.0 is not all that compatible with what we have using it).
<OscarL>
calibre, sigil... yikes.
<OscarL>
breeze_icons ?!?!
walkingdisaster has quit [Ping timeout: 480 seconds]
<OscarL>
and toot, indirectly via beautifulsoup4.
<OscarL>
doesn't sounds *too* bad. /me will attempt moving to latest lxml (5.3.0)
<Begasus>
there is a "lot" here using libxml2 :)
<OscarL>
yeah, but issue is on lxml side.
<Begasus>
ah, you are on the python one :)
<Begasus>
plasmatube crashing :(
<OscarL>
stop breaking things Begasus!!!
<Begasus>
not me!
<Begasus>
it worked fine before on beta4
<Begasus>
latest kate et all still good
<Begasus>
tokodon KF5 also broken
<Begasus>
anyway, heading out
<Begasus>
cu peeps!
Begasus has quit [Quit: Vision[]: i've been blurred!]
akashkumar has joined #haiku
<akashkumar>
Hey, I wanted to know what part of haiku code is responsible for moving the seek slider thumb from one position to another as video progresses in mediaplayer. How to find the code which does this ?
<OscarL>
akashkumar: haiku/src/apps/mediaplayer/interface/SeekSlider.{h,cpp} << that subclasses BSlider
dalme has joined #haiku
<OscarL>
so if you don't find what you're looking for in those SeekSlider files... try searching BSlider on the API docs.
<OscarL>
(or just haiku/src/kits/interface/Slider.cpp)
<OscarL>
ah, I think I missundertood you.
<akashkumar>
also suppose I did a cout statement in some place in interface files of mediaplayer, where to find that printed statement from cout in mediaplayer ?
<OscarL>
on the Terminal you started your modified MediaPlayer?
<Habbie>
perhaps the answer is 'start it from a Terminal' :)
dby has joined #haiku
<akashkumar>
if i make a change in slider.cpp, will doing "jam -q MediaPlayer` compile those changes ? or I need to do something else ?
<OscarL>
code from Slider.cpp lives in "libbe.so", so you will need to place that library next to your modified MediaPlayer ("lib/libbe.so")
<OscarL>
either copy it, or just symlinking it from your newly created "generated/objects[...]/libbe.so" to the dir where "generated/objects[...]/MediaPlayer" is (create a "lib" folder there, and place the symlink there).
<akashkumar>
i am unable to find the libbe.so file
<akashkumar>
does it generate automatically whenver i make a change in slider.cpp ?
<OscarL>
it should.
<OscarL>
use "query -a libbe.so", you should see one under /system/lib/ and some other under your Haiku clone.
<OscarL>
Regarding what code makes the slider move...
<botifico>
[haikuports/haikuports] pulkomandy e878937 - Fix and add some missing version specifiers for clarity
<botifico>
[haikuports/haikuports] pulkomandy ae7a506 - Update some packages to openssl3
HaikuUser has joined #haiku
sponge has quit [Remote host closed the connection]
HaikuUser has quit []
<OscarL>
Welp, Sigil managed to (slowly) open the largest .epub file I had around (almost 20 MB) while using the newer lxml_python39 5.3.0. Good enough testing for me :-P
<Habbie>
nice
<Habbie>
want a 157MB epub? :)
<Habbie>
apparently around 50 of my 29k epubs are > 20 MB
<OscarL>
Seems Calibre has a TON of dependencies more than Sigil... I'm not going to install all that :-D
* OscarL
takes notes to use an .epub *editor* instead of Calibre to read .epubs in Haiku :-)
<Habbie>
haha
<Habbie>
the only epub reader i've ever ran on a laptop was koreader
<Habbie>
which really is made for actual ereaders
<Habbie>
but it worked
<OscarL>
Habbie: thanks for the offer on the big epub, but my beard will be like the one from ZZ Top by the time it finishes loading :-D
<nosycat>
I tried it on Android. It's... not my favorite.
<Habbie>
OscarL, haha
<Habbie>
OscarL, i also have smaller ones, but i bet you do too
<Skipp_OSX>
we're down to 8 open bugs with one already in progress
<OscarL>
yeah, tested it with some reasonably sized novellas, worked great.
* OscarL
clarifies: he tried Sigil with smaller .epubs
<Skipp_OSX>
9 bugs excuse me forgot #7930
<nosycat>
KOReader, Habbie.
<Habbie>
nosycat, ah!
<Habbie>
nosycat, i only used it to download books, not for actual reading
Nephele has quit [Quit: Vision[]: i've been blurred!]
<nosycat>
Oh, okay.
akashkumar has quit [Quit: Leaving]
<Habbie>
the whole 'touch area map' thing was an interesting design though
<nosycat>
It has a bunch of neat ideas.
<nosycat>
Anyway, see you!
nosycat has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
it would be really nice if pkgman informed about total download sizes of requested package + dependencies before asking "Continue?"
mmu_man has joined #haiku
<OscarL>
instead of lots of "install package XXX from repository YYY", it could say "install the following package(s) from repository YYY", and then list each XXX packages (with their sizes), one per line.
<OscarL>
From my boot volume: "last_modified" index (int-64) is ~20 MB, "size" (int-64) one ~13 MB... while "name" (text) is ~30 MB. Mmm.
<OscarL>
not sure if efficient text index, or inefficient int-64 one :-)
bbjimmy has joined #haiku
<PulkoMandy>
If tour filenames are less than 8 characters, they are smaller than 64bit integers :)
<phschafft>
yes?
<phschafft>
plus an index might also compress the input data into a fixed size.
Anarchos has joined #haiku
<OscarL>
I should keep track of those indexes sizes to see if they affect my "time to delete folder with 6K symlinks" "benchmark" :-)
<phschafft>
how long does it take to delete that?
<phschafft>
and is it different with another type of files?
<OscarL>
it varied... originally 90s on a VM, switched to same install but bare metal... times got down to < 20s...
<OscarL>
went back to VM... times were around 40s.
<OscarL>
right now... ~6ms per file deletion (on a folder with 3457 regular files) (VBox)
<OscarL>
I just used symlinks because somehow I had 10/12 folders with 6k symlinks that I really don't know where they came from :-D
<OscarL>
so I was doing some clean up, and timing them.
<OscarL>
the impression was that time-to-delete was getting shorter with less files on disk. But not sure.
<phschafft>
ok, mostly wanted to know if we're in the s or the ms range.
<OscarL>
welp... for long number of files... I got plenty of "mini-stalls" (noticeable, but sub 0.5s).
<OscarL>
better than on beta4, where the stalls were multi-second.
* phschafft
wonders if a delete is triggers a sync update for each relevant index.
<OscarL>
phschafft: this is on spinning rust, btw.
<OscarL>
biggest issue I have with the stalls is that they prevented opening, or even closing apps.
<phschafft>
which hints to some more global lock
<OscarL>
hit "close" on Pe.... wait for the folder deletion to end so it actually closes << that type of thing.
<OscarL>
Pe likes to write attributes to files on "close()", so even for unmodified files I got that behavior :-)
* phschafft
nods.
gouchi has joined #haiku
<OscarL>
mmm, BeAM gives a lot of errors around liblayout related code :-/
<Coldfirex>
Try having 68,000+ files on your desktop. Lots of stalls :)
<OscarL>
cleaning Python builds (12K files each) is where I get usually hit :-)
<OscarL>
and I get to do those cleaups quite a bit while updating those recipes (I suck :-D)
<waddlesplash>
so after making the commit, you can "git reset HEAD~1" to get rid of the commit itself but keep the reverting changes in your working tree