<divad27182>
Can anyone tell me what package to find the Haiku libc documentation in?
<waddlesplash>
divad27182: I don't know if it's packaged. What little there is is on the API docs. mostly the libc should conform to POSIX and other standards so the documentation is minimal and mostly about differences
<divad27182>
man errno
<divad27182>
I admit Error.h might conform in its definitions of the error constants, but it is weird.
<divad27182>
s/Error/Errors
<waddlesplash>
what's weird about it?
<waddlesplash>
there is one technically nonconforming thing there, all the error codes are negative
<waddlesplash>
when Haiku got started that wasn't contrary to POSIX I think, but in later versions of the spec they added a line saying they must be positive
<waddlesplash>
but we're locked in to that now
<waddlesplash>
there is a mode that will make them positive for individual applications for compatibility purposes but it's somewhat fragile and not recommended
<waddlesplash>
some of that is documented
<divad27182>
usually, EINTR is 4. In Haiku it is 0x8000000A
<divad27182>
personally, I consider POSIX to be a bug documenting project.
<divad27182>
to be ignored.
<divad27182>
I will admit, I really like the VMS status codes.
<divad27182>
and they are the only OS I have seen where "status code" as opposed to "error code" is correct.
<divad27182>
and even not knowing the specific status, you can know something about it...
<divad27182>
like if it is something you should fail on
<divad27182>
Are they negative so libc can check the sign of the return code to detect errors?
<divad27182>
(libc, or whatever makes the call...)
<divad27182>
Unix, on a 32 bit machine, actually uses a 33 bit return value. :-)
zard has joined #haiku-3rdparty
<divad27182>
(and, of course, C can't distinguish that extra bit!)
<waddlesplash>
divad27182: POSIX does not require EINTR to be 4 or any other value so the mere fact it's different doesn't violate any standard
<waddlesplash>
and yes, on Haiku doing (-errno) is unnecessary
<waddlesplash>
because the error codes are already negative
<divad27182>
on Unix, and probably any POSIX, -1 is a perfectly valid return code from a system call. sign does not make an error.
<waddlesplash>
in POSIX -1 almost always means error
<waddlesplash>
anyway in Haiku the calls like ioctl() will return -1 as required and put the error in errno
<divad27182>
I think the only call that routinely does it is lseek()
<divad27182>
I have a number of reference to old mounts on my desktop. How do I delete them?
<divad27182>
Ah: crash Tracker, and they disappear.
zard has quit [Ping timeout: 480 seconds]
jmairboeck has joined #haiku-3rdparty
<divad27182>
Is it possible to convince the GUI debugger to show source lines?
<waddlesplash>
if you built with debug info it should do that already
<waddlesplash>
there may be a "Click to locate source file" indicator above the disassembly
<divad27182>
yeah, but it doesn't seem to be able to access the whole filesystem
<waddlesplash>
what do you mean?
<divad27182>
I made my nfs mountpoint at /name/something and it won't go above /boot (under a different name)
<divad27182>
symlinks provide a workaround...
<divad27182>
it is annoying, but the .o file has 1 copy of the path, and two of the filename without the directory.
<waddlesplash>
yes, there's some bug there
<waddlesplash>
it behaves differently at different times
<waddlesplash>
I think DWARF5 changed something and Debugger didn't quite adapt properly to it yet
<waddlesplash>
divad27182: anyway I just checked, all mounted volumes appear on Desktop
<divad27182>
possible. there are the same pattern there on Linux, though the order is different.
<waddlesplash>
you can access them in the Open panel this way
<divad27182>
yes and no.... They are all on the "desktop", but not in the "Debugger Open" file chooser
<waddlesplash>
you can't get to the desktop from the debugger open file chooser?
<divad27182>
actually, there are 8 of them on the full desktop....
<divad27182>
one white, seven browned/colored
<divad27182>
only the white one has usage levels.
<divad27182>
apparently it doesn't go in for some of the needed details either. I'm using generated code from a header file, and it doesn't seem to recognize it.
<waddlesplash>
stepping through inlined functions doesn't work too well at the moment
<waddlesplash>
(no automated commit notifications here, but they're posted in #haiku)
<divad27182>
good to hear. I suspected that was probably something simple and silly, like something not being passed through...
<divad27182>
though I will admit the other two are more important to me.
<waddlesplash>
I don't really know much about NFS4 and will let others solve those
<waddlesplash>
not handling the RO flag was an easy fix
<divad27182>
I reconfigured to try to get errors right: wrote -O -g0 instead of -O0 -g drat...
<divad27182>
personally, I think not handling the RO flag is an architecture error. It should be handled at the all filesystems level before the individual filesystem gets to have any say.
<waddlesplash>
there are a number of reasons why this isn't done
<waddlesplash>
I looked into implementing it at the VFS level before I did it this way but decided against that
<waddlesplash>
A key reason is that a filesystem may get re-mounted read-only, or some error may happen and it degrades to readonly
<waddlesplash>
And the filesystem itself needs to be able to handle that, not the VFS
<waddlesplash>
the VFS does at least enforce open modes. If you try to call write() on an FD that was opened RDONLY, the VFS will error out before ever getting to the filesystem
<waddlesplash>
So a filesystem mounted readonly only needs checks in the open() calls and things like that, not in read() and write()
<divad27182>
the filesystem needs to be able to trigger it, but the VFS needs to say "you may not open a file read-write on a filesystem that is read-only".
<waddlesplash>
implementing that may be architecturally tricky
<divad27182>
so the VFS should set it up readonly and then let the specific filesystem do its mount things.
<waddlesplash>
it's possible, but it would be a big of a refactor
<divad27182>
possible....
<waddlesplash>
divad27182: except the thing is, many filesystems may decide to mount readonly *without* the user asking for it
<waddlesplash>
e.g. if there's features we don't fully support
<waddlesplash>
so we need to pass more information around to make that work
<divad27182>
yes, well, the FS should be able to tell the VFS: I am now read-only
<divad27182>
the VFS should be able to tell the FS: You are requested to go read-write
<waddlesplash>
and what happens to all the FDs that are open to it that are read-write?
<waddlesplash>
should the VFS iterate through all of them and force-close them?
<waddlesplash>
if not, then the VFS would need to perform special checks every read and write call, not just open call
<waddlesplash>
and checking flags in the critical I/O path would degrade performance
<waddlesplash>
so, you see, there are multiple levels of complexity here
<divad27182>
well... there are already checks on the file when you try to write().
<waddlesplash>
there's only a check for the open mode
<waddlesplash>
that's it
<divad27182>
It just need to check two things instead of one...
<waddlesplash>
all other validation happens when opening the file
<divad27182>
or maybe the open mode should be cached into a "can be written" bit that combines the two.
<waddlesplash>
there are other flags in the open mode besides RDWR
<waddlesplash>
that definitely must stay per-FD
<divad27182>
"open mode", a wonderful screw-up in Unix....
<waddlesplash>
nah, it's fine
<waddlesplash>
and everything uses that, not just Unux
<divad27182>
0=read 1=write 2=RW? no...
<waddlesplash>
oh, that
<divad27182>
should have been 1, 2, 3
<waddlesplash>
well it doesn't matter
<waddlesplash>
it's a bitfield anyway
<waddlesplash>
O_RDWR | O_CREAT | O_EXCL
<waddlesplash>
etc.
<divad27182>
right, but O_RDWR is normally 2...
<divad27182>
it should have been a "can read" and a "can write" bits.
<waddlesplash>
eh
<divad27182>
screwup in very early Unix.
<waddlesplash>
sure, fine. but oh well, not really a big deal
<waddlesplash>
anyway I am not saying what you are suggesting is impossible, I am just saying that making it work that way would've required architectural changes and refactoring all in-tree filesystems and rather than just fixing only NFS4 lol
<waddlesplash>
so I decided to just fix NFS4
<divad27182>
yeah, might well be a big refactor...
<divad27182>
I suspect bug #19656 might be too....
<waddlesplash>
nah
<waddlesplash>
that one is just failing to invalidate stuff at the NFS4 level
<waddlesplash>
like I said before, all caching decisions get made by the filesystems *not* the VFS
<divad27182>
So when do I expect build 58944 ?
<waddlesplash>
builds happen once every 24h
<divad27182>
but no new number in the last 24h ...
<waddlesplash>
I can't recall when, I think around 6am GMT
<divad27182>
or is that the repositories being on the fritz
<waddlesplash>
the last commit before today was hrev58937
<waddlesplash>
that's currently available
<waddlesplash>
hrev58938 was only committed this morning
<divad27182>
ah so those are commit numbers
<waddlesplash>
yes
<waddlesplash>
well
<waddlesplash>
actually no, they're *push* numbers
<waddlesplash>
one hrev may have multiple commits as a result
<waddlesplash>
it's the system they came up with when switching off of SVN like a dozen+ years ago
<waddlesplash>
... actually more than that probably, because I've been around over a dozen years, and Haiku was already on git when I joined
<divad27182>
I will admit to having looked at git a couple times, and used subversion for a bit.
<divad27182>
I found subversion to be ridiculously slow compared to CVS.
<divad27182>
I suspect git may have the same issue.
<divad27182>
and both suffered from a feature lack that I find good: recoverability.
<divad27182>
a feature neither bother to list...
<divad27182>
Looking at the code you had to changed, and the fact that it will have to be in every writable filesystem implementation, I would say it is a prime candidate for refactoring into the VFS.
<waddlesplash>
probably, but there are more important things to work on
jmairboeck has quit [Quit: Konversation terminated!]
<divad27182>
probably...
<divad27182>
How about making things work without a mouse?
<waddlesplash>
there's open tickets for a lot of that
<divad27182>
those dialog boxes when a program crashed insistend on being clicked. really annoying.
<waddlesplash>
every now and again someone fixes something
<waddlesplash>
they do?
<divad27182>
I think so...
<waddlesplash>
nope, keyboard works OK Here
<waddlesplash>
by default no control is focused
<waddlesplash>
Enter key presses "Oh no!" button
<waddlesplash>
otherwise, use Tab and Space as normal
<divad27182>
I will retry...
<divad27182>
when I can...
<divad27182>
In addition to the bugs reported, every so often things just freeze up for ~30 seconds... or longer....
<divad27182>
so how do I change focus in the keyboard?
<divad27182>
ok, Entry pressed "Ok no!", but Tab and space didn't seem to do anything, and I had to click-to-focus the dialog.
<divad27182>
OK. Tab and Space do seem to cycle, but I don't get any feedback on the tab. It just changes what happens when I press space.
<waddlesplash>
it has a blue outline ring for me...
<divad27182>
on the inside edge of the white area. Tiny. I can barely see it. Normally, one leaves a bit of a gap...