mexen has quit [Quit: Connection closed for inactivity]
peder has quit [Ping timeout: 240 seconds]
orific1 has joined #ruby
sickdyd has quit [Ping timeout: 268 seconds]
peder has joined #ruby
sickdyd has joined #ruby
sickdyd has quit [Ping timeout: 268 seconds]
Guest26nakilon has joined #ruby
<Guest26nakilon>
while refactoring that socket part of the irc bot again I now face the weird thing -- it does not flush the command sent socket unless I do "p 1" to STDOUT
tomtmym has joined #ruby
tomtmym has quit [Changing host]
tomtmym has joined #ruby
<Guest26nakilon>
even socket.sync = true and socket.flush does not help
sickdyd has joined #ruby
<dminuoso>
Guest26nakilon: What does "it does not flush the command" mean to you exactly?
<Guest26nakilon>
dminuoso when I issue a chat command I see in logs that I've called the socket#send ...+"\n", but there is nothing in chat; until I send another message in my irc client; so every response is one message late; but it does not get late if I just add "p 1" in one specific place
<Guest26nakilon>
clarification: in my first message by "the command" I meant bot's PRIVMSG, in the previous one by it I mean the chat command an irc channel user issues
<Guest26nakilon>
it will take a while to minimize my code for the reproduction I decided to ask first, maybe anyone already knows thing weird behaviour
sickdyd has quit [Ping timeout: 248 seconds]
<dminuoso>
Guest26nakilon: Okay, your assumption is way too broad. You cannot directly infer whether or not the "sending side has flushed" based on some high level visible behavior on the client side.
<dminuoso>
Guest26nakilon: strace or wireshark on the sending side to see.
<dminuoso>
(Preferrably strace, though)
orific1 has quit [Ping timeout: 268 seconds]
<Guest26nakilon>
I've restarted it few times with and without the p to see the effect, here is without it: https://i.imgur.com/nu3Q9O2.png
<dminuoso>
Like I said, you're jumping huge distances to conclusions
<dminuoso>
Check `strace` on the sending side.
hightower4 has quit [Ping timeout: 240 seconds]
<Guest26nakilon>
there is no other possible reason why twitch chat won't show the message until the next one
<Guest26nakilon>
the chat server web interface in this way indicates that it does not get the command in time
<dminuoso>
If all your assumptions were right, you wouldn't have ab ug.
<dminuoso>
What is more likely: That there's a deeply flawed basic bug in the socket API, or that you're somehow inferring wrong conclusions?
<dminuoso>
And I can tell you right away: You cannot make that inference.
<Guest26nakilon>
1
<dminuoso>
Guest26nakilon: Then use strace to prove me wrong.
<dminuoso>
strace will give you a *fact* what the syscalls actually receive.
<Guest26nakilon>
you probably don't know what the "irc server web interface" means
<Guest26nakilon>
or just want to talk random "you do too distant assumptions" just because you feel iike that
<Guest26nakilon>
you are reducing my willing to create a bug report
<leftylink>
as count dooku said. twice the price, double the fall.
<leftylink>
oops
<leftylink>
as count dooku said. twice the pride, double the fall.
kaivai has joined #ruby
swaggboi has joined #ruby
<Guest26nakilon>
so the assumption that "twitch decided to lag (the first time ever in two years I use it), delay the responses exactly when I was testing the commands 30 times in a row" isn't distant, right?
<Guest26nakilon>
even "lag 5 times, then 5 times not, then lag again, then not again"
<dminuoso>
Guest26nakilon: Look in order to file a bug report, you will need the strace anyway.
<Guest26nakilon>
in order to bug report I need only a reproducible example
<dminuoso>
I'm kind of confused why you refuse so intensively to use the authoritative debugging tool to give you an actual answer.
<Guest26nakilon>
that I would be already ~30% done
<dminuoso>
But I don't really care.
<Guest26nakilon>
I'm confused why you can't derive the obvious web interface picture as a confirmation
<leftylink>
you don't need to worry about them. they've always been like that, which is why I've never liked them (and that's okay, not everyone needs to like each other in an irc channel)
<Guest26nakilon>
and you really care, otherwise you won't insist
<dminuoso>
Guest26nakilon: Because that involves a huge stack of software.
<dminuoso>
That requires all of twitch and all of an irc client for some behavior
<dminuoso>
where you draw some conclusion how ruby interacts with sockets
<dminuoso>
the truth is: you dont know
<dminuoso>
maybe its the actual newline of `p` that causes the behavior on twitch to "flush"?
<dminuoso>
(perhaps the twitch protocol requires a newline?)
<Guest26nakilon>
the truth is you jumped to assumptions without even knowing how I tested it
<Guest26nakilon>
just to flame
<dminuoso>
Guest26nakilon: I asked you from the beginning how you drew that conclusion.
<dminuoso>
15:48:02 Guest26nakilon | dminuoso when I issue a chat command I see in logs that I've called the socket#send ...+"\n", but there is nothing in chat; until I send another message in my irc client; so every response is one message late; but it does not get late if I just add "p 1" in one specific place
<dminuoso>
You told me that you used the visible behavior on the client on the other side to draw a conclusion how ruby interacts with the socket API.
<dminuoso>
I told you that this is an extremely far fetched conclusion.
<Guest26nakilon>
I call the "p" globally, i.e. on the Kernel, I'm not calling it on Socket instance and I'm not inheriting the class
<dminuoso>
Guest26nakilon: All the more reason to use strace to figure out whats going on.
<Guest26nakilon>
I've just added the troll to ignorelist
<Guest26nakilon>
just wasted time and irc log
<Guest26nakilon>
instead of letting someone who faced the same issue, have a clear view on my initial message
<dminuoso>
It was fairly obvious where this was going to end. *sigh*
<Guest26nakilon>
Guest26nakilon: while refactoring that socket part of the irc bot again I now face the weird thing -- it does not flush the command sent socket unless I do "p 1" to STDOUT
<Guest26nakilon>
line 46 is where you can insert more debug print and so _.flush, but it won't help
donofrio has joined #ruby
sickdyd has joined #ruby
donofrio has quit [Ping timeout: 240 seconds]
sickdyd has quit [Ping timeout: 265 seconds]
_ht has joined #ruby
hightower2 has joined #ruby
<Guest26nakilon>
removed "logger" dependency; also just experienced the weird delay on Queue#push, that you can see in the example log, where 22 was queued only after 33 was already received
<Guest26nakilon>
rbenv ruby 2.7.2, mac os
hightower2 has quit [Remote host closed the connection]
<Guest26nakilon>
hmmmm maybe the line 67 is stuck on mutex
hightower2 has joined #ruby
<Guest26nakilon>
but it still does not explain why "p 1" fixes all this
hightower3 has joined #ruby
hightower3 has quit [Remote host closed the connection]
hightower2 has quit [Ping timeout: 268 seconds]
hightower3 has joined #ruby
<Guest26nakilon>
aha, looks like queue_thread can't catch the mutex, and 'p 1' gives it a time
<Guest26nakilon>
that's it -- issue localization and no flame to delay it was needed
<Guest26nakilon>
learn to use time effectively
<Guest26nakilon>
i.e. spend more on rereading the code
<Guest26nakilon>
instead of wasting time on needless additional activities, like doing dumps and such
<Guest26nakilon>
now the question is how to make the 'until' loop on line#49 give another thread time to catch it
<Guest26nakilon>
probably it would be no issue if ruby could respect the order in which threads are waiting for the semaphore
johnjaye has quit [Ping timeout: 240 seconds]
johnjaye has joined #ruby
Prodigy has joined #ruby
sickdyd has joined #ruby
TomyWork has quit [Remote host closed the connection]
Prodigy has quit [Quit: WeeChat 3.8]
Guest26nakilon has quit [Quit: Client closed]
sickdyd has quit [Ping timeout: 265 seconds]
Guest26nakilon has joined #ruby
Guest26nakilon has quit [Client Quit]
desnudopenguino has quit [Quit: desnudopenguino]
desnudopenguino has joined #ruby
Sankalp has quit [Ping timeout: 264 seconds]
Sankalp has joined #ruby
sickdyd has joined #ruby
howdoi has joined #ruby
desnudopenguino1 has joined #ruby
sickdyd has quit [Ping timeout: 268 seconds]
desnudopenguino has quit [Ping timeout: 240 seconds]
<isene>
I need to split a string but retain consequtive spaces ( "I am a nerd" => ["I", " ", "am", " ", "a", " ", "nerd"]. This `str.split(/(\W)/)` is slow, and this `str.scan(/\s+|\S+/)` is faster - but still rather slow. Is there a much faster way?
anther has quit [Ping timeout: 240 seconds]
roadie has quit [Ping timeout: 248 seconds]
ur5us has joined #ruby
ur5us has quit [Remote host closed the connection]
ur5us has joined #ruby
sickdyd has joined #ruby
swaggboi has quit [Ping timeout: 240 seconds]
infinityfye has quit [Quit: Leaving]
John_Ivan has joined #ruby
swaggboi has joined #ruby
roadie has joined #ruby
roadie has quit [Ping timeout: 248 seconds]
ruby[bot] has quit [Remote host closed the connection]
ruby[bot] has joined #ruby
shokohsc0 has joined #ruby
shokohsc has quit [Ping timeout: 250 seconds]
shokohsc0 is now known as shokohsc
roadie has joined #ruby
roadie has quit [Ping timeout: 248 seconds]
<leftylink>
I will suggest a use of Enumerator#slice_when, but that implies you have to do String#each_char or String#chars before and an Array#join after, so I'm not sure if that will make it faster or slower.
<leftylink>
not just an Array#join, multiple Array#join
<havenwood>
My first thought is: split(/\b/)
<havenwood>
Though seems not so zippy.
<leftylink>
great news. I just found that my suggestion slows it down by over an order of magnitude
<havenwood>
leftylink: Then my suggestion only slowing it down by double seems better. :P
<leftylink>
truly it is a pleasure when that happens
<havenwood>
JRuby speed up `split(/(\W)/)` to nearly double the i/s over CRuby. TruffleRuby takes the cake on this one with `scan(/\s+|\S+/)` at over 5x CRuby's best with YJIT or MJIT.
<havenwood>
isene: If CRuby split/scan is too slow, I'd consider JRuby or TruffleRuby or trying a Rust or C Ruby extension with CRuby.
roadie has joined #ruby
roadie has quit [Ping timeout: 248 seconds]
ap4y has joined #ruby
John_Ivan has quit [Quit: Disrupting the dragon's slumber one time too often shall eventually bestow upon all an empirical and indiscriminate conflagration that will last for all goddamn eternity.]
roadie has joined #ruby
<leah2>
also use scan with a block
roadie has quit [Ping timeout: 248 seconds]
Dooky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]