pappo has quit [Remote host closed the connection]
myriad has quit [Quit: Connection closed for inactivity]
<Skipp_OSX>
unfortunately my patch does indeed not fix the problem, sigh
Nasina has quit [Read error: Connection reset by peer]
<AlienSoldier>
Skipp_OSX doing a mouse selection is snappy, only with the keys it seem to mess. Could it be a message passing overload or locking problem?
<Skipp_OSX>
it is a locking problem or something in the interaction between BMenu and BWindow and I'm interjecting in MenusBeginning() that I can't do.
<Skipp_OSX>
I'm convinced the bug is in BMenu but I can't fix it there so I'm gonna have to do a workaround.
<AlienSoldier>
i don't know when this started, just stumbled on this because i have an insane amound of files name to edit.
<AlienSoldier>
*amount
<Skipp_OSX>
I do, when I re-enabled menu bar add-ons
Nasina has joined #haiku
Nasina has quit [Remote host closed the connection]
bjorkintosh has quit [Remote host closed the connection]
<OscarL>
Was thinking in opening a ticket for this, but would be nice to rule out some stupid mistake on my part.
<OscarL>
Gist of the issue is... if in Haiku you set a language locale and a different one for formating, you end up with git's output text in the "formatting language", not the one you use for UI.
<OscarL>
my test output seems to shows that unless your program calls setlocale(LC_ALL, ""), any call to setlocale() for other categories changes ALL of them.
Nasina has quit [Read error: Connection reset by peer]
nephele_xmpp has left #haiku [Error from remote client]
SLema has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
bjorkintosh has joined #haiku
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
Nasina has joined #haiku
<OscarL>
This is odd... in Locale preflet... Formatting for "Spanish (Argentina)" is different on 32 bits than on 64 bits.
<OscarL>
on 32 bits, time properly defaults to 24-hours, with leading 0s on it (eg: 01:11), while on 64 bits it defaults to 12-hour format, and even when switched to 24-hours, it lacks the leading 0s (1:11).
nik_ has joined #haiku
OscarL has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
bbjimmy has quit [Read error: No route to host]
Chai-T-Rex has quit [Remote host closed the connection]
ChaiTRex has joined #haiku
yote has quit [Ping timeout: 480 seconds]
<Begasus[m]>
morning peeps
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
aloha Begasus[m].
<Begasus[m]>
Hola OscarL :)
<Skipp_OSX>
I mean, we use ICU to get 12/24 hour time format, I don't see how there could be a 32/64 bit problem in ICU
<Skipp_OSX>
so maybe a bad conversion somewhere idk that's strange.
<Begasus[m]>
well seeing buildmaster is off to on the beta hrev maybe I "could" switch to nighly, but ... nah :P
<OscarL>
Skipp_OSX: yeah, that 32 vs 64 difference is odd. (just rebooted onto 64 bits, and confirmed that the data for Spanish (Argentina) is off (also misses leading 0s in dates).
<OscarL>
Begasus[m]: that out of focus Be logo plays badly with my worsening sight :-D
<Begasus[m]>
classic one OscarL :)
<OscarL>
for a moment... I wasn't sure if I was wearing the wrong glasses, or if they were really dirty :-P
<Begasus[m]>
too bad most of those wallpapers were made for 1024*768, so yeah don't always scale well
* OscarL
is a "plain BeOS blue" background color type of guy. (Win98 blue while on the "dark side")
<Begasus[m]>
just installed thememanager so I can easely switch day/night colors
<OscarL>
Skipp_OSX: oddly enough, on 64 bits, after setting "Spanish (Argentina)" formatting to 24 hours, the clock on Deskbar correctly uses leading 0s (02:57), while on 32 bits it does not... beside Locale preflet showing it should.
<Skipp_OSX>
maybe an issue in Deskbar?
<Skipp_OSX>
Deskbar should be using BLocale so I don't see why it would be any different.
<Skipp_OSX>
maybe a bad conversion in Deskbar
<OscarL>
that part at least maybe. Locale stll showing "2:57" even on 24-hour mode still makes no sense :-D
<nekobot>
• OscarL (e355c349): tig: update to version 2.5.12. (#11835)
<OscarL>
welp... that's one way to find out if my patch for git was nonsense :-P
<Begasus[m]>
never used tig, so I trust you in this :P
<Begasus[m]>
and ffmpeg7 has been running good for what I've checked
<OscarL>
just started to use tig more regularly... still need to learn more about it.
<OscarL>
I have seen Python tests fail on strftime/strptime regularly, but can't pin-point where the issue lies. might be this cursed setlocale() after all.
<Begasus[m]>
wished 3dEyes could have a look into fixing the error on haikuplugins for Qt 6.8.2, at one point KF6 will start requiring the new version (Tokodon master already does)
Nasina has quit [Remote host closed the connection]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
Nasina has quit [Remote host closed the connection]
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
Nasina has quit [Ping timeout: 480 seconds]
nephele_xmpp has joined #haiku
<nephele_xmpp>
OscarL: LANG was set in previous releases i think. with it git behaves like before
OscarL has quit [Ping timeout: 480 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
OscarL has joined #haiku
<OscarL>
nephele_xmpp: I don't recall LANG being there before (will try using "git log -S")... but in any case, according to humdinger, older git on newer beta5 didn't showed the issue.
<nekobot>
[haiku/haiku] e38d10fd9f5f - Update translations from Pootle
<nephele_xmpp>
git should use LC_MESSAGES in any case though
<OscarL>
as far as I can tell, from "command_main.c"'s main(), it calls git_init_getttext(), and that calls setlocale(LC_MESSAGES, "") and setlocale(LC_TIME, "").
<OscarL>
but then I'm seeing that each of those just sets the language for the rest of the categories (LC_*), unless you call setlocale(LC_ALL, "") after.
<OscarL>
something on Haiku's side is using it, is what I mean. and it clearly has to do with what setlocale() does. from where that would get the proper formatting data otherwise?
<nephele_xmpp>
Anyway, irrespective of whatever else the LC messages do... if git does *NOT* use LC_MESSAGES for it's string outputs there is something wrong with git
<nephele_xmpp>
so unless you can demonstrate that the LC_TIME call also changes LC_MESSAGES there is also a bug in git
dodo75 has quit [Quit: Vision[]: i've been blurred!]
dodo75 has joined #haiku
akashkumar has joined #haiku
ChaiTRex has quit [Remote host closed the connection]
ChaiTRex has joined #haiku
gouchi has quit [Quit: Quitte]
HaikuUser has joined #haiku
dpirate_ has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
arjen_ has joined #haiku
HaikuUser has joined #haiku
diver has joined #haiku
HaikuUser has quit []
MisthaLu has quit [Quit: Leaving]
akashkumar has quit [Quit: Connection closed for inactivity]
x10z has joined #haiku
maylay_ has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
nik_ has quit [Remote host closed the connection]
mmu_man has joined #haiku
vdamewood has joined #haiku
bjorkintosh has joined #haiku
bbjimmy has joined #haiku
<B2IA>
(Unknown) coup
qwebirc68001 has joined #haiku
qwebirc68001 has quit []
erysdren has joined #haiku
B2IAb has joined #haiku
B2IA is now known as Guest10424
B2IAb is now known as B2IA
B2IA has quit []
B2IA has joined #haiku
<waddlesplash>
nephele_xmpp: Haiku does have a C locale, it's just the same as POSIX and it always reports its name as POSIX. but if you set a C locale this works fine
<nephele_xmpp>
We only have POSIX as the named locale, which is what posix species... it also specifies this to be equivalent to the C locale
<nephele_xmpp>
I think only mpv had a problem with this up to now, but since we follow posix here I don't see that as a big issue...
Guest10424 has quit [Ping timeout: 480 seconds]
<waddlesplash>
mpv should just be patched to understand that POSIX is the same as the C locale
SLema has joined #haiku
<nephele_xmpp>
Yes, probably. I think that was done in haikuports
<Begasus[m]>
Subject: disable setlocale for haiku * first part in that patchset
arjen_ has quit [Ping timeout: 480 seconds]
arjen_ has joined #haiku
gouchi has joined #haiku
gouchi has quit []
SLema has quit [Quit: Vision[]: i've been blurred!]
SLema has joined #haiku
yote has joined #haiku
yote is now known as Yoke
mmu_man is now known as Guest10427
mmu_man has joined #haiku
Guest10427 has quit [Ping timeout: 480 seconds]
<nipos>
nephele_xmpp: I just tried to look into the issue with the gradients on the Haiku website that you told me a few days ago.I couldn't reproduce it,however.Tried in WebPositive,GNOME Web,Otter Browser,LibreWolf and NetSurf.All worked perfectly fine,except NetSurf which doesn't seem to support gradients at all.Even good old Otter Browser displayed the gradient correctly.
n_crm has joined #haiku
<nephele_xmpp>
nipos: I can only reproduce it on safari iOS
<nipos>
Which is weird,since WebPositive,GNOME Web and Otter Browser all also use WebKit.And Otter Browser uses a very outdated version of it,ruling out the possibility that old WebKit versions had problems with it
<nephele_xmpp>
Yes but, I *can't* reproduce it on safari macos
<nipos>
With this being a minor bug in one single browser,I think it's probably not worth investigating a specific workaround
<nephele_xmpp>
That's fine for me :)
<nipos>
Another thing: I didn't forget adding HaikuWebKit2 to Grok,but it's a *really* big codebase and my server is taking ages (now over a week at 100% CPU load) to index it.You can already browse the source at https://grok.nikisoft.one/opengrok/xref/haikuwebkit2/ but searching doesn't work until it's fully indexed.
zdykstra has joined #haiku
KapiX has joined #haiku
zdykstra has quit [Remote host closed the connection]
zdykstra has joined #haiku
arjen_ has quit [Ping timeout: 480 seconds]
x10z has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<trannus_aran>
ah, yeah I thought it was some kinda rtl88xx
<waddlesplash>
0xc820
<waddlesplash>
hm
<trannus_aran>
yeah
<trannus_aran>
like ideally I'd get my iprowifi4965 for the built in wlan card fixed, but I figure the dongle (being cheap and pretty ubiquitout on amazon/already supported by openBSD) would be a better target for a fix
FreeFull has joined #haiku
<waddlesplash>
does 4965 not work?
<waddlesplash>
that driver is usually very reliable
<trannus_aran>
yeah, no go with my centrino n205 or some such (lemme get the exact one in case I'm misremembering the model)
<waddlesplash>
what does "no go" mean specifically: does it not show up in Network preferences? does it not show networks? not connect? etc.
<waddlesplash>
you should check /var/log/syslog there, it may have interesting errors
<trannus_aran>
waddlesplash: oo, lemme see! I was wondering where the logs/dmesg equivalent was
<trannus_aran>
I'm still fairly new to haiku :sweat smile:
<waddlesplash>
trannus_aran: OK I found the realtek hardware in Linux. This is indeed an 8821CU
<waddlesplash>
the FreeBSD driver supports 8821*A*U, but not *C*U
<waddlesplash>
and yes, the one letter does make a big difference lol (sadly)
<trannus_aran>
danke!
<trannus_aran>
hmmmmmm
<waddlesplash>
adrian_ will know what needs to be done to add support for it (he's one of the key FreeBSD WiFi people)
<waddlesplash>
but they're busy/backlogged/ENOTIME, so I wouldn't hold your breath
<trannus_aran>
nothing in the syslog about the iprowifi4965, but it shows up in the network app
<trannus_aran>
just reads as no link on device 0
<waddlesplash>
no networks?
<waddlesplash>
i.e. the wireless network dropdown is empty?
<trannus_aran>
status disconnected!
<trannus_aran>
yeah, the network dropdown is empty
<trannus_aran>
something's not talking to something internally
<waddlesplash>
ok. is there anything in "syslog.old"? if your syslog got too big it will have gotten rotated
<waddlesplash>
so the errors might be in there
<trannus_aran>
ah, lemme check
<waddlesplash>
you can also try "ifconfig /dev/net/iprowifi.... scan" and see what happens
<waddlesplash>
i.e. if it returns a more specific error code
<trannus_aran>
weird, ifconfig /dev/net/iprowifi4965/0 scan just returns an empty table with the headers for "name" "address" "signal" and "auth"
<trannus_aran>
lemme check the syslog real quick
<waddlesplash>
OK so it's just "dead" somehow
<waddlesplash>
probably there will be an init error *somewhere*
<trannus_aran>
weird, nothing in syslog.old either! just the ipro1000/0 I'm using now for the ethernet
<waddlesplash>
nothing for either "iprowifi4965" or "iwn"?
<waddlesplash>
there should at least be the init messages
<trannus_aran>
I *did* just install the wifi firmwares package , but last time that didn't fix it, so I didn't have high hopes (I am on the latest nightly though)
<waddlesplash>
the wifi firmwares packages does nothing for this hardware
<waddlesplash>
the firmwares are bundled with the default install in the intel_wifi_firmware package
<waddlesplash>
the install script is only needed for really old Intel and then Broadcom hardware with strange license requirements
<trannus_aran>
yeah, figured as much ;/
<trannus_aran>
weird, yeah, there's no init stuff in the syslog either? Almost every line (including the first full page of them) just reads:
<trannus_aran>
DAEMON 'DHCP': /dev/net/ipro1000/0: Send DHCP_DISCOVER to 255.255.255.255:67
<waddlesplash>
oh, is DHCP just flooding your syslog?
<trannus_aran>
looks like it!
<waddlesplash>
well then that's why there's nothing here, it's gotten overwritten by now lol
<trannus_aran>
I could reboot, maybe that would at least show what's happening
<waddlesplash>
are you actually using ipro1000 right now?
<trannus_aran>
yep
<waddlesplash>
did you give it a static address?
<waddlesplash>
or did DHCP work but thinks it failed
<trannus_aran>
no static addr (or at least I didn't assign it one)
<trannus_aran>
so no, barring something weird lol
<waddlesplash>
so it's yet another bug in our DHCP then lol
<waddlesplash>
yeah, just reboot, and then immediately copy syslog
<trannus_aran>
aight sounds good. I'll keep the ethernet unplugged while I copy so we don't get a bunch of noise, hopefully
<trannus_aran>
one sec (also thx so much!)
<waddlesplash>
np
Nasina has quit [Read error: Connection reset by peer]
trannus_aran has quit [Ping timeout: 480 seconds]
trannus_aran has joined #haiku
<trannus_aran>
alright, here we are
<trannus_aran>
the paste of the syslog at boot, grepping for iprowifi
<trannus_aran>
oh nice! wondered if there were some c/c+-isms that lived in the haiku shell
<waddlesplash>
just looks like it didn't get an interrupt
<trannus_aran>
*c++-isms
<trannus_aran>
looks like it's trying to start an ssh server and failing with that?
<waddlesplash>
nah, that's harmless
<waddlesplash>
it's happening in parallel
<trannus_aran>
hmmm
<waddlesplash>
the errors are only for V6 anyway
<trannus_aran>
yeah
<waddlesplash>
we don't support some V6 feature sshd wants
<waddlesplash>
our V6 support is kind of incomplete in general
<waddlesplash>
anyway this just looks like firmware load failed due to no interrupts
<trannus_aran>
I mean v6 support is kind of incomplete in general for software as a whole :P
<waddlesplash>
you can check this hypothesis by dropping to the kernel debugger and running "ints" command
<trannus_aran>
let's see, how can I drop into the db?
<waddlesplash>
and then exiting via "co" (the kernel debug session will be written to syslog after a succcessful exit)
<waddlesplash>
ideally via keyboard, Alt+SysRq+D
<waddlesplash>
(if you do this from a USB keyboard then it will set up USB routing for the kernel debugger)
<trannus_aran>
hmm, does SysRq have another name on US keyboards?
<waddlesplash>
Print Screen
<trannus_aran>
ahhhh, right
<waddlesplash>
if you are using a PS/2 keyboard then the shortcut doesn't matter as much, you can use the "kernel_debugger" command in shell
<waddlesplash>
your syslog looks like it has a PS/2 keyboard init
<trannus_aran>
okay got it, lemme grab that from the syslog (also that's a very cool feature, wonder if linux or bsd have anything like that that can run in userspace like that)
<waddlesplash>
oh, this isn't userspace
<waddlesplash>
our kernel debugger is just pretty sophisticated lol
<trannus_aran>
oh, it's like directly in the kernel?
<trannus_aran>
damn
<waddlesplash>
yes
xet7 has joined #haiku
<trannus_aran>
anyway, lemme get the paste here
<waddlesplash>
Linux and the BSDs have "debugnet", a way for network packets to be sent while the kernel debugger is running
<waddlesplash>
that's generally how they do "advanced kernel debugging" stuff, just run commands on another machine
<waddlesplash>
we could implement this, but obviously there are many times that won't or can't work
<waddlesplash>
meanwhile our input stack looks totally different than the BSDs, and we have HID report parsing support in the USB HID driver
<waddlesplash>
so, we instead have a "debug USB packet send/receive" facility
<waddlesplash>
KERN: int 26, enabled 1, handled 0, unhandled 0
<waddlesplash>
KERN: iprowifi4965:_ZL12intr_wrapperPv (0xffffffff8275c650), data 0xffffffff98ca1340, handled 0
<waddlesplash>
so, indeed, we got 0 interrupts
<trannus_aran>
very very cool
<trannus_aran>
hmm, wonder what part of the source tree this would live in to try out a patch (I have a dev enviro for haiku nightly on another machine)
<trannus_aran>
though I suppose I could set it up on this one, hmm
<waddlesplash>
this bug is probably not in this driver
<waddlesplash>
it's likely in interrupt routing/handling
<trannus_aran>
yeah, somewhere else
<waddlesplash>
the idualwifi7265 (next Intel WiFi generation up) hits similar problems with firmware failing to load and no interrupts received, much more commonly
<waddlesplash>
but unfortunately not on my hardware nor on any other devs' hardware
<waddlesplash>
so nobody has really dug into this
<trannus_aran>
wonder what's unique about this hardware case compared to ones that work with this same driver
<waddlesplash>
it's probably not the PCI device itself
<waddlesplash>
I have some 7265 devices that the exact same PCI ID fails on other people's hardware
<waddlesplash>
it's something in the mainboard or MSI or something
<trannus_aran>
just how it expects to handle it on the host machine's side?
<waddlesplash>
basically, something is wrong with how we are setting up interrupt routing, I'd guess
<trannus_aran>
(ie not the driver, but the OS)
<waddlesplash>
yes
<trannus_aran>
hmmm
<waddlesplash>
basically all cases where these symptoms happen and I ask people to try FreeBSD, it works
<waddlesplash>
it's just Haiku that does not
<waddlesplash>
the first thing I would try here, if you want to dig into it, is to see if legacy interrupt mode works
<waddlesplash>
basically, edit the driver to not allocate a MSI
<trannus_aran>
good opportunity to open up a bug report I suppose. yeah, I was considering dual booting this with freebsd to eliminate any OS-specific variables
<waddlesplash>
this assumes however that your hardware has a legacy IRQ assigned in the first place
<waddlesplash>
you can check the giant PCI information dump in the syslog to see if there is an interrupt line set for this device
<trannus_aran>
it might, this thing's from 2013
<waddlesplash>
if there is, then avoiding MSIs may be interesting
<trannus_aran>
though even that's a bit late IIRC
<waddlesplash>
well a number of things in the ints command are using legacy IRQs
<trannus_aran>
ahh
<waddlesplash>
all the IRQs <= 16 (I think?) are legacy
<waddlesplash>
you can clearly see int 16 is shared between 2 devices
<waddlesplash>
that never happens with MSIs
<trannus_aran>
between sdhci and ehci?
<waddlesplash>
yeah
<trannus_aran>
just making sure I'm reading it right
<waddlesplash>
one of those devices or both or our driver may not support MSIs
<waddlesplash>
our EHCI driver definitely does, not sure if it was implemented for SDHCI
<trannus_aran>
I mostly work with lisp and assembly, so this is firmly in the hinterlands between that I wanna get to know better
<waddlesplash>
but the EHCI device may not support MSIs
<waddlesplash>
it looks like you have 2 EHCI controllers and XHCI controller
<waddlesplash>
which is kind of interesting
<waddlesplash>
more interesting is that the XHCI controller hasn't taken over from the EHCI controllers
<trannus_aran>
msi's being machine specific interrupts or some such?