<OscarL>
oof. I got my share if inflamed costal cartilages due to falls... that thing makes breathing actually hurt :-/ (as the "joke" we have here: "Hurts?" asks one, "No. Only when I breath" says the one in pain).
Maturi0n_ has joined #haiku
Maturi0n has quit [Ping timeout: 480 seconds]
DanDan has quit [Ping timeout: 480 seconds]
DanDan has joined #haiku
<zdykstra>
Exactly - it's only sore when I breath, or my dog sleeps against my side :)
HaikuUser has joined #haiku
HaikuUser has quit []
vdamewood has joined #haiku
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser has quit []
HaikuUser2 has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
GrizzlyKiwi has joined #haiku
GrizzlyKiwi has quit []
<jhj>
x512[m]: Hey any chance of getting a newer Clang into HaikuPorts?
<augiedoggie>
there is a pull request that will be merged within a few days
<jhj>
Oh, cool. Do you happen to have that handy - I know if I build it, it'll take awhile.
<augiedoggie>
i haven't tried to build it
<jhj>
The current LLVM/Clang 12 that is packaged doesn't properly include the compatability paths, and you can't easily manually detect it, so I need a gross hack.
<jhj>
I look forward to being able to take that out.
<Begasus>
still got some from OBOS around somewhere :)
<Begasus>
nothing fancy though
<OscarL>
Welp... nothing I can do about that gfortran / libbsd thing :-( (can't do much about it at my skill level). Putting scipy and co on hold until that gets sorted out.
<OscarL>
Missing symbols on libgfortran.so, resulting on runtime_loader errors for the most basic fortran programs.
* Begasus
feels an update yet again on gcc comming up :)
<Begasus>
OscarL, maybe it never worked before?
<OscarL>
No idea Begasus. First time touching fortran (despite my age :-D)
<Begasus>
you're just a kiddo, no exuces there!
<nielx[m]>
I am not familiar with how fortran is supposed to work, but I am pretty sure that C/C++ requires you to explicitly link to all shared libraries that you directly and indirectly depend on
<OscarL>
I might be reading the error wrong... and it is not libgfortran the one missing symbols... only the part complaining about it?
<nielx[m]>
well yes, the other part of that is that C/C++ linking gives an error if you have unresolved symbols at link time, which is what makes this error slightly more suspicious
<nielx[m]>
So I agree something fishy is going on :-)
<Begasus>
need to check autoconf and automake on 32bit ...
<OscarL>
So... for one part it would be reasonable to expect to get linking errors before these runtime errors, for the other... I need to learn how to tell meson to add -lbsd when compiling Fortran code :-D
<Begasus>
export LIBS ... doesn't work?
<Begasus>
there should be an option to add specific libraries with meson ...
<PulkoMandy>
C/C++ says nothing about that, and we do support transitive linking, so you don't need to explicitly link to things you indirectly depend on
<OscarL>
this one is meson_python, not sure if it makes any difference. In any case, thanks for the pointers Begasus (I've no experience with either :-D)
<Begasus>
haven't looked there for a while OscarL (think I had some issues using meson_python too)
<OscarL>
Begasus: worked well for contourpy at least :-)
<Begasus>
ah, ok, so did atleast something good :)
<nielx[m]>
you're right PulkoMandy
<nielx[m]>
anyway, the issue here is that libgfortran seems to be a static library.
<OscarL>
Thanks PulkoMandy. To me... that `dl_iterate_phdr` missing symbol seemed too low level as to be expected to require a -lbsd from the user compiling a "hello world"... but... I know nothing so...
<nielx[m]>
hmm, there does seem to be a dynamic library too
<Begasus>
it's a singleton nielx[m], shouldn't harm?
<Begasus>
at least no shared counterpart?
<nielx[m]>
ok, yeah it does not link to libbsd.so
<nielx[m]>
we'll probably need to review the gfortran build
<OscarL>
there's a libfortran.spec file that reads: "this spec file is read by gfortran when linking" / "it is used to specify the libraries we need to link in, in the right order".
<nielx[m]>
like PulkoMandy said, the issue is that libgfortran.so itself is not linked to libbsd
<nielx[m]>
so it is actually the libgfortran build that needs to be amended
<Begasus>
PulkoMandy, so far much better with WebPositive, thanks!
<jmairboeck>
Nice, Begasus! Thanks for merging autoconf and automake. I'll revert my hack, then the perl/texinfo/lilypond PR should be ready as well.
<Begasus>
thanks!
<Begasus>
Had to make sure all was still good on 32bit
<Begasus>
time stamp is still of when looking at the commit time at github though PulkoMandy .... 2 hours ago
<Begasus>
:)
<Begasus>
of/off*
<jmairboeck>
a confusion between UTC and local time?
<Begasus>
maybe ... don't know, but it's been like that for a while (never really noticed it before)
<jmairboeck>
I noticed the same in Hyper-V, there the system clock is also wrong. But I kind of expected that because my system is set to UTC (unix-compatible) in Time settings.
<Begasus>
nvm :)
<Begasus>
switched to GMT in prefs, fine now
<jmairboeck>
ah, so for WebKit you need the exact opposite
<Begasus>
had to sync also though (otherwise the clock would be 2 hours ahead)
<jmairboeck>
VirtualBox supports both modes btw.
<jmairboeck>
I don't know about other VM engines
<Begasus>
err ... something still wrong in WebPositive ...
erysdren has quit [Quit: Konversation terminated!]
floof58 has joined #haiku
Diver has quit [Quit: Leaving.]
Diver has joined #haiku
jacereda has quit [Remote host closed the connection]
<jmairboeck>
waddlesplash: regarding that GPE from the dec network driver in Hyper-V: trying to read any memory, I only ever get the same READ/WRITE FAULT and no contents, and always with the same "pc" address.
<waddlesplash>
not reading memory but try to find what area the address is in
<jmairboeck>
how do I do that?
jacereda has joined #haiku
jacereda has quit [Remote host closed the connection]
<waddlesplash>
jmairboeck: one of the area commands iirc?
<jmairboeck>
now that is weird: I used "areas" to list all of them, this worked, then with an argument, which got me the fault again, and now "out of memory for command execution"
<jmairboeck>
something is completely wrong here
<jmairboeck>
when I tried before, the VM rebooted suddenly after some commands
<jmairboeck>
now I get the "out of memory" error for every command
ScottD17 has joined #haiku
xet7 has joined #haiku
ScottD1 has quit [Ping timeout: 480 seconds]
ScottD17 is now known as ScottD1
jmairboeck has quit [Quit: Konversation terminated!]
xet7 has quit [Remote host closed the connection]
petterhj has joined #haiku
petterhj is now known as Guest9204
HaikuUser has joined #haiku
HaikuUser has quit []
gouchi has joined #haiku
gouchi has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
jacereda has joined #haiku
<waddlesplash>
that can happen, yes
<waddlesplash>
kdl memory allocation is odd
<Begasus>
going down, g'night peeps
Begasus has quit [Quit: Vision[]: i've been blurred!]
_0xdd has quit [Ping timeout: 480 seconds]
<jacereda>
Hi. I'm reading now https://www.haiku-os.org/docs/userguide/en/keyboard-shortcuts.html and have a question... wouldn't those shortcuts be less painful if they all used the OPT key? I mean, it would be simpler if OPT was reserved for the OS (workspace operation, task switching, window handling), so applications (think Emacs) can freely use all keyboard combinations that use CTRL/CMD. Is it too late to propose something like this?
<jacereda>
I was really upset when I noticed emacs didn't handle CTRL+TAB properly and wrote a patch today to forward those combos, but that's just the beginning of the story. Everything would be much simpler if OPT was used for all of those shortcuts.
HaikuUser has joined #haiku
HaikuUser has quit [Remote host closed the connection]
lubo76kubuntu has quit [Remote host closed the connection]
<PulkoMandy>
none of them use CMD alone, that is normally free for applications. Except CMD+TAB and apparently CMD+PrintScreen from this list?
<PulkoMandy>
I think most of these shortcut are inherited from BeOS and predate the existence of the OPT key :)
<PulkoMandy>
some of them can be changed if there are conflicts with existing apps, but I think we'd do it on a case by case basis rather than changing all of them
HaikuUser has joined #haiku
HaikuUser has quit []
<jacereda>
But basically anything except OPT conflicts with Emacs. Maybe it could be a setting for those who want to retain the muscle memory and aren't too keen on Emacs. What would be the appropriate channel for these kind of suggestions?
<jacereda>
Hmmm, I can't find the package containing the manpages for libc functions... where are those?
<PulkoMandy>
We don't have manpages for libc functions. There is room sor improvement in all things documentation…
_0xdd has joined #haiku
<phschafft>
I wonder if there should be a set of manpages not for a specific OS but directly based on POSIX and the C standard. I would guess that such an project would be helpful for all systems that include manpages.
<phschafft>
(both as they would provide a minimum e.g. when there is no OS specific manpage and as a reference to use when pointing out differences in the OS specific one.)
AlienSoldier has joined #haiku
extrowerk has quit [Quit: Bye!]
extrowerk has joined #haiku
<jacereda>
Sure, it would be nice if a plain POSIX manpages project existed, but... I guess something could be extracted from the susv4 docs, but I'm not sure it would be legal. Looks like Haiku's libc is based on glibc? If so I guess the Linux manpages could be added to the codebase as a starting point? There will be lots of unimplemented bits, but probably better than nothing.
<jacereda>
BTW, I'm curious, why glibc and not musl?
<x512[m]>
Because BeOS used glibc.
<phschafft>
I mean it's also a matter of why you read it. do you want to write generic (portable) software or do you want to use that one feature.