<nekobot>
• Begasus (6195a4b1): knetwalk, bump version (#11902)
<Begasus[m]>
patch upstreamed for the last one, should be good for the next version (only need to patch for Haiku icons, can't push a change there as they are pretty much keen on keeping the breeze style) :)
dodo75 has quit [Quit: Vision[]: i've been blurred!]
tigerbrother has quit [Quit: Ping timeout (120 seconds)]
tigerbrother has joined #haiku
nephele has joined #haiku
nexus6 has quit [Quit: Vision[]: i've been blurred!]
<nephele>
waddlesplash: but but, we have so many improvements in the nightlies :D
<waddlesplash>
that's always true though, lol
<nephele>
gonna work a bit on webkit patches. those don't need the nightlies :P
* Anarchos
will try again his bios drive checksum PR with recent master hrev.
Nasina has joined #haiku
Nasina has quit [Remote host closed the connection]
Nasina has joined #haiku
* Begasus[m]
is closing down soon
<Begasus[m]>
enough flooding the channel for one day :P
jmairboeck has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
cu peeps!
erysdren has joined #haiku
<nephele>
how am i supposed to test local website changes? I don't see a hugo package
<waddlesplash>
we don't have one because hugo needs go
<nephele>
so... no way to test changes? :/
<waddlesplash>
nope, you'll have to use a Linux VM or something
<nephele>
that sounds majorly inconvenient :)
<waddlesplash>
it is what it is
<waddlesplash>
at the time we were switching off Drupal I don't think any of the major static site generators had much chance of working on Haiku
<waddlesplash>
so that wasn't a factor in the choice
<waddlesplash>
nowadays the node.js-based ones probably would, with some effort
<nephele>
node js sounds even worse than go
<nephele>
my webkit build just build the web inspector sucessfully
<nephele>
i didn't tell it to do that, so i was suprised. wondering if there is any way to invoke it
<Anarchos>
waddlesplash i could install tiddlywiki with node.js on haiku
<dovsienko>
waddlesplash: www.tcpdump.org uses two shell scripts to generate the pages, and there is no JavaScript
<dovsienko>
there's a bit of PHP and mod_rewrite on top of the man page collection, but that's a matter of style and convenience, not the contents
MisthaLu has quit [Quit: Leaving]
<nephele>
we don't need to switch the generator because of this...
<nephele>
no javascript is not a good thing in and of itself either. It's good to not use it where it is uneccesary, but it should be used when relevant
HaikuUser has joined #haiku
HaikuUser is now known as jochwehg_
Nasina has quit [Ping timeout: 480 seconds]
* jochwehg_
is idle: BRB
<dovsienko>
nephele: I agree with that, but millions of developers that produce web sites that take 5 seconds to respond to a mouse click probably have missed the point
<nephele>
sure, but that isn't our websites ;)
<dovsienko>
keep it this way then
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #haiku
Nasina has joined #haiku
orealis has quit [Quit: yap...]
tqh has joined #haiku
<waddlesplash>
the website is statically generated and served via a CDN
<waddlesplash>
the generation is also quite fast
<waddlesplash>
so yes that's not a concern
orealis has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
HaikuUser has joined #haiku
HaikuUser is now known as grexe
<grexe>
somebody can help me with a pesky bogus pointer issue? want to show this at PKM Summit 2025 but some code that was working fine before doesn't seem to like the new malloc of latest Haiku Revs...
<waddlesplash>
as always: use the guarded heap lol
tqh has quit [Quit: Leaving]
<waddlesplash>
basically any memory problem on Haiku like that, first thing to try is the guarded heap
<grexe>
oh you're there @wadllesplash, please I need an experienced memory wrangler, Clang is giving me the creeps.
<grexe>
Github link incoming
<waddlesplash>
creeps? what does that mean lol
<grexe>
it's an include detector, works fine but crashes on exit:( simply launch with
<waddlesplash>
App.cpp:19:10: fatal error: Sensei.h: No such file or directory
<waddlesplash>
running "make" in sourcecode-extractor
<grexe>
oh darn, yes these are external includes you need to get from the API repo and put it in local includes $(HOME)/config/non-packaged/include/sen
<jhj>
NOTICE: '/boot/system/lib/libhwloc.so.15' is valid 64-bit ELF.
<jhj>
Found '/boot/system/lib/libhwloc.so.15'
<jhj>
resolve symbol "hwloc__xml_import_diff" returned: -2147478780
<jhj>
ERROR: hwloc_get_type_depth failure.
grexe has joined #haiku
grexe has quit [Quit: Vision[]: i've been blurred!]
<jhj>
Trying to get just the version does work. I'm not so concerned with the "hwloc_get_type_depth failure" message, because that's just my error handling.
<jhj>
But I don't want it spamming "resolve symbol returned -2147478780" stuff to stderr.
Nasina has joined #haiku
<jhj>
Oh, weird. Haiku has a /boot/system/lib/hwloc/hwloc_xml_libxml.so file, and if I load that also, no stderr message at least.
<waddlesplash>
that probably means hwloc__xml_import_diff was not found in the library you tried to dlopen
<waddlesplash>
nor in any of its dependents
<waddlesplash>
so we just failed loading
<jhj>
But I'm not sure why I should have to do that.
<waddlesplash>
probably means libhwloc isn't linked properly or something
<jhj>
waddlesplash: I'm seeing this magical /boot/system/lib/hwloc/hwloc_xml_libxml.so only on Haiku. On every other OS I've tested (AIX, FreeBSD, Linux, macOS, Solaris, etc.) there is only libhwloc.so.
<waddlesplash>
what version do you have installed, hwloc or hwloc2?
<jhj>
hwloc2
<waddlesplash>
do the other OSes have hwloc1?
<waddlesplash>
either way this deserves a bug report at HaikuPorts
<jhj>
No, hwloc2 everywhere. hwloc1 is EOL since forever, not sure why you package it.
<waddlesplash>
anyway error -2147478780 is just "symbol not found"
<jhj>
NOTICE: '/boot/system/lib/libhwloc.so.15' is valid 64-bit ELF.
<jhj>
ERROR: hwloc_get_type_depth failure.
<jhj>
Found '/boot/system/lib/libhwloc.so.15'
<jhj>
Still doesn't work that way, but it at least doesn't spam stderr with stuff.
<jhj>
waddlesplash: Is there some Haiku-specific way I can get a count of cores (actual processors, so excluding hyperthreads)?
<waddlesplash>
I don't know that we expose the CPU topology to userland
<waddlesplash>
why would you need it?
<jhj>
waddlesplash: Well, this isn't the Haiku case (because Haiku doesn't have POSIX real-time extensions), but, for real-time simulation.
<waddlesplash>
just set REALTIME or greater priority on your threads
<waddlesplash>
the scheduler should, ideally, take care of the rest
* Anarchos
is looking for the command to list the hard drives/usb drives
<waddlesplash>
but warning that you really have to know what you are doing if you do that, because unless "realtime" threads yield one way or another, you can lock up the whole OS by having realtime threads eat all CPU!
<jhj>
waddlesplash: Well, what we do is we create a high-priority watchdog thread at the highest realtime priority, up to seven other threads with SCHED_RR, and then a lower-priorty watchdog thread. The low priority watchdog periodically talks to the high-priority watchdog, and in case it misses 5 checkins, it calls a recovery procedure that drops the real-time priority from the work threads.
<jhj>
And yes, I'm very well aware of the issues.
<jhj>
We have to check the number of CPUs available (which is easy enough) to make sure that the users who refuse to read documentation and enable RT don't get completely locked out of their systems.
<jhj>
If they have just 4 CPUs or something and configure 4 or more RT workers.
<waddlesplash>
you can easily get CPU count via system_info struct but this does not indicate HT
<jhj>
Right, and if two realtime threads get scheduled on different hyperthreads on same physical CPU, it causes jitter, and the SCHED_RR algorithm (at least everywhere I've tested) doesn't prefer any kind kind of topology by default.
<waddlesplash>
the Haiku thread scheduler is topology-aware
<jhj>
hwloc has some nice tooling to do this - hwloc-distrib and hwloc-bind.
<jhj>
But what I really want to do is to be able to provide the user a warning that they are probably not doing what they think they are doing.
<jhj>
If they configure 7 workers on a "12 CPU" system that is really "6 cores, SMT2".
<dovsienko>
my usual solution to that is disabling HT in the BIOS setup
<mmu_man>
Hmm I'm getting "Too many open files" quite often today
<jhj>
Yeah, if you know about it, that's all good. I want to be able to provide a warning to users who refuse to read the documentation and turn on RT :)
<waddlesplash>
mmu_man: there's some open tickets about this with Tracker. I fixed a bug recently where Tracker would just crash in that situation
<waddlesplash>
it seems to have a FD leak somewhere
tktech284 has joined #haiku
<mmu_man>
OK
tktech28 has quit [Ping timeout: 480 seconds]
tktech284 is now known as tktech28
<jhj>
waddlesplash: hwloc is pretty neat. Let's say you want to distribute N tasks equally, you can run hwloc-distrib N (--taskset gives you Linux taskset parameters). --single is for binding each to a single CPU.
<jhj>
`hwloc-distrib 7 --taskset | hwloc-calc -q -H package.core | uniq -c` will tell me that I've overcommitted cores.
<jhj>
(6-core SMT2)
<PulkoMandy>
get_cpu_info has all the topoloygy info for the cpu (that was added by pdziepak a long time ago)
Nasina has quit [Read error: Connection reset by peer]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Nasina has joined #haiku
<jhj>
Hrm, where is that documented, and is there a userland tool for it?
<jhj>
The hwloc port should be updated to use it, so lstopo would work, since a lot of things use libhwloc to get the topology in a cross-platform way :)
<jhj>
Intel TBB and also the base LLVM OpenMP runtime use libhwloc to know how to distribute threads.
<nekobot>
[haiku/haiku] 0d73795fc9ee - libroot/malloc: Make the guarded heap handle bogus pointers better.
<waddlesplash>
PulkoMandy: it does?
<waddlesplash>
ah, no, it doesn't, but there is another method right next to it that I missed: get_cpu_topology_info
<waddlesplash>
so, there we go
<jhj>
waddlesplash: Hrrm. ProcessController doesn't seem to understand the topology. If I start Haiku under qemu/kvm and use `-smp maxcpus=12,sockets=1,cores=6,threads=2` it shows I have 12 individual processors, and libhwloc2's lstopo utility also shows I have 12 individual processors. Let me see what get_cpu_topology_info does. :)
<waddlesplash>
those 12 processors will all have unique APIC IDs
<waddlesplash>
and will all behave as unique processors, from an OS perspective
<waddlesplash>
so to the OS it's all managed the same
<waddlesplash>
the topology info will show the real story
Nasina has quit [Read error: Connection reset by peer]
<jhj>
Well, that is somewhat of an issue because we don't, ideally, want two workers threads sharing a physical core.
<jhj>
Not the end of the world, just not ideal.
<waddlesplash>
Linux behaves the same way I am pretty sure
<waddlesplash>
i.e. in most monitors you will see "threads" as CPUs, not "cores"
<jhj>
Yes, by default, but that's where libhwloc comes in.
<waddlesplash>
okay, well ProcessController is just the same then
<jhj>
Looks like I can figure it out from get_cpu_topology_info
<jhj>
waddlesplash: I'll look into what it might take to get proper libhwloc support too upstream.