<waddlesplash>
Skipp_OSX: the node monitoring does work here
<waddlesplash>
but I got one case in which the comparisons in there to delete didn't work
<waddlesplash>
it was even in the debugger, it looked like they should have compared equal but they didn't
<waddlesplash>
but I haven't had that happen again yet, every time since it's worked
<waddlesplash>
oh, now it happened again
<Skipp_OSX>
yeah I don't get it either
<waddlesplash>
ok I got another one in the debugger
<waddlesplash>
the device and node are identical but the comparison didn't work out
<Skipp_OSX>
I should replace "device" and "node" with actual node_refs now that we support them...
<waddlesplash>
isn't it one already?
<Skipp_OSX>
We didn't have a AddNodeRef type in BMessage so it passes the node and device separately and puts them back together again on the other side. If there is a conversion that happens it could screw up the comparison.
<waddlesplash>
it shouldn't
<waddlesplash>
I'm looking at the structures now...
<Skipp_OSX>
no it shouldn't, should work fine, yeah, the structure is literally device and node that's it.
<Skipp_OSX>
but comparison could could fail in Tracker because of conversion in message passing putting apart putting together again slightly differently.
<waddlesplash>
... the data should be identical
<Skipp_OSX>
should be yes
<Skipp_OSX>
but how else could the comparison fail then?
flag has joined #haiku
<waddlesplash>
no idea
<waddlesplash>
oh, maybe it's just the message is the wrong kind, it's not a node monitor message
<waddlesplash>
but the query changed message
<waddlesplash>
yeah, that's whats happening I think, we never get the node monitor message. So why don't we?
<Skipp_OSX>
but the comment above explains that it should be only for B_NODE_MONITOR because those are the ones for deleted files
<waddlesplash>
right
<waddlesplash>
but sometimes, we don't get it, apparently
<waddlesplash>
1 in 10 or so, maybe a bit more, in my testing
<waddlesplash>
why not?
flag_ has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
I do not know the answer, it's either the message is not sent at all or it's going in the else branch
<waddlesplash>
I added some asserts, it looks like it's not sent at all in that caes
<Begasus>
If someone could fix that cpu issue with qtwebengine I'm a happy man :D
nephele_xmpp has left #haiku [Error from remote client]
BrunoSpr has joined #haiku
BrunoSpr has quit []
talos8 has joined #haiku
talos86 has joined #haiku
talos has quit [Ping timeout: 480 seconds]
talos86 is now known as talos
nephele_xmpp has joined #haiku
BrunoSpr has joined #haiku
<BrunoSpr>
Hello
talos8 has quit [Ping timeout: 480 seconds]
<gordonjcp>
BrunoSpr: hi
jmairboeck has joined #haiku
<BrunoSpr>
Trying to upgrade to Beta 5, but get error: name in use or: https://0x0.st/Xxmb.png
<BrunoSpr>
Any Idea what to do?
<BrunoSpr>
I changed the repositories to beta5 as michael said in his HAIKU Tutorial...
nephele_xmpp has left #haiku [Error from remote client]
<Begasus>
BrunoSpr, hard error message, try to see in the list to be updated if you got items in there with the same version/revision number and uninstall/backup them
<nekobot>
[haiku/haiku] b8a2c9099141 - EntryCache: Use memcpy to copy the strings.
<nekobot>
[haiku/haiku] 1af0198a7d86 - EntryCache: Unify hash computation logic and use uint32 for it.
<nekobot>
[haiku/haiku] ab4fc43458c2 - EntryCache: Cache the entry's hash value.
gouchi has quit [Remote host closed the connection]
nephele_xmpp has left #haiku [Error from remote client]
sonikatomar[m] has joined #haiku
linuxmaster has quit [Ping timeout: 480 seconds]
erysdren has quit [Quit: Konversation terminated!]
MisthaLu has quit [Quit: Leaving]
linuxmaster has joined #haiku
nephele_xmpp has joined #haiku
Babaj has joined #haiku
<AlienSoldier>
Is there a reson why terminal is not instant on when launched? It was always like that. when launching, if i start to type i can even type before the prompt appear.
<AlienSoldier>
does the terminal itself is made of script or is it all compiled c++?
gouchi has joined #haiku
<dovsienko>
how much delay are you observing?
<waddlesplash>
definitely don't see that here, Terminal starts basically instantly
<AlienSoldier>
must depend on diskdrive, cache available and cpu, but a goos 2 sec.
<waddlesplash>
what version of Haiku?
<AlienSoldier>
*good
<AlienSoldier>
every version i ever used
<waddlesplash>
ok
bbjimmy has quit [Ping timeout: 480 seconds]
<AlienSoldier>
between welcome to haiku shell, and the prompt i can feel 1.5ish delay
<nekobot>
[haiku/haiku] edb17c548f72 - Revert "arm64: Use DEVICE_GRE memory when mapping MTR_WC."
nephele_xmpp has left #haiku [Error from remote client]
<dovsienko>
there is a possibility the delay belongs to what is in /etc/profile (hence in /etc/profile.d/) rather than the shell or the terminal
<AlienSoldier>
waddlesplash for exemple if i hold "a" while selecting new tab or new terminal, some "a" have time to get typed before the terminal own text. I would expect it to fast enough to happen faster than a key press bemessage processing.
<dovsienko>
because "Welcome to the Haiku shell." is the first thing /etc/profile prints
<AlienSoldier>
dovsienko yes but i can type tings "before" this display.
<dovsienko>
so if I was to debug this problem, I would begin by adding a few echo debug lines to /etc/profile to see which step is slower than it should be
<dovsienko>
AlienSoldier: that is irrelevant, as far as I understand. when the shell goes interactive, it consumes the buffered input, but before that the user is free to generate it
<AlienSoldier>
this is one of the thing that make ahiku feel less snappy, the other thing is things like the tracker list of application in the deskbar, it feel slower the fist time it is summoned, after if feel instant as it seem cached.
<dovsienko>
also, if this is in fact the root cause, you likely will see the same delay when logging in over SSH
<dovsienko>
which would mean the problem is not specific to the GUI terminal, and perhaps not to the shell itself
<dovsienko>
AlienSoldier: one problem at a time would be the most productive approach
nephele_xmpp has joined #haiku
<AlienSoldier>
it is not bad ad it is, just not great.
<dovsienko>
if you feel adventurous, you can add "set -x" right at the top of /etc/profile and watch the output of the next terminal you open
<dovsienko>
please do not paste the complete output here
nephele_xmpp has left #haiku [Error from remote client]
mmu_man has quit [Ping timeout: 480 seconds]
<dovsienko>
waddlesplash: the EndpointManager::Unbind() KDL has just reproduced on the latest master
<dovsienko>
there were a few SSH sessions opened, I orderly logged out in all but one, then ran "shutdown" in the last remaining session. the session is still "open", i.e. the Linux client has not received a FIN or an RST
mmu_man has joined #haiku
<mbrumbelow>
waddlesplash: I am hunting down a bug with FAT32. After moving 1TB of data to a SSD and renaming the folder I get a crash. Will be filing a bug report.
<waddlesplash>
dovsienko: ok, interesting
<waddlesplash>
probably some deinitialization order
* dovsienko
. o O (everybody's complaining about something)
<waddlesplash>
not sure how much I tested with rebooting with open sockets
<waddlesplash>
so, will have to do that
<waddlesplash>
(please add a comment to the ticket anyway)
<dovsienko>
alright
<waddlesplash>
mbrumbelow: ok. meaning a FAT partition of size 1TB? or a smaller FAT partiton with 1TB cumulative data transfer
<waddlesplash>
what's the KDL exactly, because if it's an assert failure I'm not going to worry too much
<Begasus>
closing down here
<Begasus>
cu peeps!
Begasus has quit [Quit: Vision[]: i've been blurred!]
<mbrumbelow>
waddlesplash: Not an assert.
_-Caleb-_ has left #haiku [#haiku]
<mbrumbelow>
FAT partition of 1.5 TBs with 1TB cumulative data transfer.
_-Caleb-_ has joined #haiku
<waddlesplash>
ok
zardshard has left #haiku [Error from remote client]
<nekobot>
[haiku/haiku] 65f942aadacc - WebPositive: Add missed conversion from BString to HashString.
nephele_xmpp has left #haiku [Error from remote client]
<dovsienko>
waddlesplash: if you want to extract any debugging information from the KDL anytime soon, let me know. I can keep it in this state for a while
<waddlesplash>
is it just the same as before?
<dovsienko>
from the looks of the backtrace, yes
<waddlesplash>
check tcp_endpoint <pointer> # from the message "bound endpoint <ptr> not in hash"
<waddlesplash>
then socket 0x... # from the tcp_endpoint
<waddlesplash>
and copy those to the ticket, but they'll probably just be the same as before...
Atomozero has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
dovsienko: looks a bit different than last time
<waddlesplash>
socket state is "closed"... but that might be bogus