<cahoots>
hi, is there an easy way in ruby to create an IO object where i can write to it on one thread and read to it on another, and for example if i call .gets on it, it'll block until it has enough data? basically i want StringIO, except that StringIO is non-blocking and returns nil for .gets if there's not enough data
<cahoots>
i want the blocking behavior of the stdout/stderr IO objects from popen3
<cahoots>
o0x1eef, yeah, i was looking at IO.pipe, it does fit what i asked for. the only issue is that pipes have bounds afaik, and i want this to be totally unbounded
<o0x1eef>
You mean you can only write so much before it blocks and you must read from it ?
<cahoots>
o0x1eef, yeah
<o0x1eef>
Right, yeah. You can work around that similar my example by having a separate thread / process that is always looking for content to read, and that way you never fill the buffer
<cahoots>
o0x1eef, so what i'm trying to do is provide an abstraction over popen3 that doesn't suffer from popen3's similar issue: it runs into problems when its buffers for stdout and stderr get full. i have a reader thread right now, and it could publish to a pipe that i'd expose, but the pipe would fill up. but are you saying i'd have, like, a writer thread in addition to the reader thread, and the writer thread
<cahoots>
is just always trying to write to the pipe?
<o0x1eef>
Did you look at the code I pasted because it sounds exactly like what you're trying to do ?
<cahoots>
hehe
<o0x1eef>
Look at #spawn especially
<cahoots>
you mean in cmd.rb? i see that you're writing to two different strings, and i guess there is where i'd replace it with writing chunks to a list that a writer thread is always trying to write to a pipe
<cahoots>
two different strings being @stdout and @stderr
<cahoots>
maybe use a queue
<o0x1eef>
Right, more or less that's it.
jasfloss has quit [Ping timeout: 252 seconds]
jasfloss has joined #ruby
gemmaro_ has quit [Ping timeout: 252 seconds]
gemmaro_ has joined #ruby
<cahoots>
o0x1eef, what happens if i don't call .join on threads? in my case, i have these writer threads that are instance members of the process handle, and i don't want to force the user to call a cleanup method to join them
<cahoots>
i'm curious if the threads will be garbage collected when they finish, or if they also have to have join called on them
cahoots has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
zokia has quit [Remote host closed the connection]
cahoots has quit [Ping timeout: 252 seconds]
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 276 seconds]
cahoots has joined #ruby
xokia has joined #ruby
xokia_ has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
xokia has quit [Ping timeout: 260 seconds]
xokia_ has quit [Read error: Connection reset by peer]
xokia_ has quit [Remote host closed the connection]
xokia has joined #ruby
xokia has quit [Remote host closed the connection]
xokia has joined #ruby
cahoots has joined #ruby
Furai has quit [Quit: WeeChat 4.5.1]
xokia has quit [Ping timeout: 272 seconds]
cahoots has quit [Ping timeout: 252 seconds]
Linux_Kerio has joined #ruby
wbooze has quit [Quit: Leaving]
Furai has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 265 seconds]
xokia has joined #ruby
xokia has quit [Read error: Connection reset by peer]
xokia has joined #ruby
xokia has quit [Read error: Connection reset by peer]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 272 seconds]
matoro has quit [Quit: No Ping reply in 180 seconds.]
matoro has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 268 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 252 seconds]
<henk>
I’m running rbot off this branch right now: https://github.com/henk84/rbot/tree/refactor/error_handling and I get this crash: https://bpa.st/GXPA when I let it run, connect, and then interrupt it with ctrl-c. sometimes the output varies and lines 15-21 are not there. I don’t understand what’s happening, where that call to `select` comes from, i.e. the chain what happens. I get the feeling that
<henk>
this might be threading related. any advice how to figure out what’s really going on here?
cahoots has joined #ruby
cahoots has quit [Ping timeout: 276 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 272 seconds]
cahoots has joined #ruby
TomyWork has joined #ruby
user71 has joined #ruby
cahoots has quit [Ping timeout: 244 seconds]
Linux_Kerio has quit [Quit: Konversation terminated!]
Linux_Kerio has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 268 seconds]
nil78 has quit [Read error: Connection reset by peer]
cahoots has joined #ruby
nil78 has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
wbooze has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
Linux_Kerio has quit [Ping timeout: 244 seconds]
cahoots has quit [Ping timeout: 265 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
xokia has joined #ruby
cahoots has joined #ruby
naiithink has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
naiithink has quit [Client Quit]
cahoots has joined #ruby
xokia has quit [Read error: Connection reset by peer]
cahoots has quit [Ping timeout: 244 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 272 seconds]
Inline has joined #ruby
xokia has joined #ruby
cahoots has joined #ruby
mrzasa has joined #ruby
mrzasa has quit [Client Quit]
cahoots has quit [Ping timeout: 252 seconds]
Quiet-Oil9262 has quit [Read error: Connection reset by peer]
Quiet-Oil9262 has joined #ruby
donofrio has joined #ruby
xokia has quit [Read error: Connection reset by peer]
cahoots has joined #ruby
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
cahoots has quit [Ping timeout: 268 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 246 seconds]
xokia has joined #ruby
cahoots has joined #ruby
whysthatso125070 has quit [Read error: Connection reset by peer]
whysthatso125070 has joined #ruby
whysthatso125070 has quit [Read error: Connection reset by peer]
whysthatso125070 has joined #ruby
cahoots has quit [Ping timeout: 252 seconds]
balo has quit [Quit: leaving]
balo has joined #ruby
GreenResponse has joined #ruby
cahoots has joined #ruby
<o0x1eef>
cahoots: Usually you would call join a thread to prevent the main thread exiting and taking all the other threads with it
cahoots has quit [Ping timeout: 268 seconds]
<henk>
oh, I guess my problem has to do with the traps and reentrancy … looking into that now. if anyone knows about this stuff and can check whether my hunch is correct, I’d appreciate it!
cahoots has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 244 seconds]
fantazo has joined #ruby
MsInput has joined #ruby
brokkoli_origin has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
wbooze has quit [Ping timeout: 246 seconds]
denvermullets has joined #ruby
cappy has joined #ruby
cappy has quit [Quit: Leaving]
cahoots has joined #ruby
cappy has joined #ruby
denvermullets has quit [Ping timeout: 260 seconds]
cahoots has quit [Ping timeout: 244 seconds]
FetidToot8 has joined #ruby
FetidToot has quit [Ping timeout: 246 seconds]
FetidToot8 is now known as FetidToot
cahoots has joined #ruby
wbooze has joined #ruby
sarna has quit [Ping timeout: 252 seconds]
cahoots has quit [Ping timeout: 265 seconds]
Linux_Kerio has joined #ruby
Linux_Kerio has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ruby
sarna has joined #ruby
donofrio_ has quit [Ping timeout: 248 seconds]
cahoots has joined #ruby
donofrio_ has joined #ruby
donofrio has quit [Read error: Connection reset by peer]
<CalimeroTeknik>
havenwood, how does `gem install -g --no-lock` help running the bundler project without heeding the Gemfile.lock?
hwpplayer1 has joined #ruby
cahoots has quit [Ping timeout: 246 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
cahoots has joined #ruby
Guest9260 has joined #ruby
Guest9260 has quit [Client Quit]
cahoots has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
nil78 has quit [Read error: Connection reset by peer]
cahoots has joined #ruby
nil78 has joined #ruby
wbooze has quit [Quit: Leaving]
cahoots has quit [Ping timeout: 244 seconds]
wbooze has joined #ruby
wbooze has quit [Client Quit]
wbooze has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
denvermullets has joined #ruby
cappy has quit [Quit: Leaving]
denvermullets has quit [Ping timeout: 276 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 272 seconds]
wbooze has quit [Quit: Leaving]
wbooze has joined #ruby
wbooze has quit [Remote host closed the connection]
wbooze has joined #ruby
denvermullets has joined #ruby
<havenwood>
CalimeroTeknik: So if you say `bundle init` then `bundle add async` it creates a `Gemfile` but not `Gemfile.lock` file. When you `gem install -g --no-lock` it resolves `Gemfile` dependencies and installs the gems but does *not* create a `Gemfile.lock`.
<havenwood>
CalimeroTeknik: I thought you wanted to install `Gemfile` dependencies without creating a `Gemfile.lock` but maybe I misunderstood your intention?
<havenwood>
The `-g, --file [FILE]` flag will install `Gemfile` dependencies if not provided an argument.
wbooze has quit [Quit: Leaving]
<havenwood>
The `--no-lock` flag is meant for use with the `-g, --file` flag when you wish to not create a `Gemfile.lock`, as was once recommended for gems but is now debated.
<havenwood>
CalimeroTeknik: Try deleting the `Gemfile.lock` and running `gem i -g --no-lock` in the directory with your `Gemfile`.
<havenwood>
An aside, but I'd hoped the more modern `gems.rb` and `gems.locked` convention would have taken over for `Gemfile` and `Gemfile.lock` by now. I guess RuboCop discouraging it greatly diminishes adoption. I prefer `gems.rb` to `Gemfile`. We know it's a file. Ruby files should have an `.rb` extension.
<havenwood>
(A `bundle` or `gem i -g` will detect a `gems.rb` just like a `Gemfile`, FWIW.)
cahoots has joined #ruby
wbooze has joined #ruby
<havenwood>
CalimeroTeknik: Rereading backlog, is it that you want a `bundle update` equivalent that doesn't modify the `Gemfile.lock`? You want a `Gemfile.lock`? Then to ignore it?
<havenwood>
I was assuming you'd opt to not create the Gemfile.lock in the first place. Does that work?
brokkoli_origin has joined #ruby
<havenwood>
You should be able to do either, but I'd opt to not have a Gemfile.lock if you're going to not use it at all.
denvermullets has quit [Ping timeout: 252 seconds]
TomyWork has quit [Ping timeout: 248 seconds]
denvermullets has joined #ruby
denvermullets has quit [Ping timeout: 252 seconds]
donofrio_ has quit [Ping timeout: 260 seconds]
user71 has quit [Quit: Leaving]
wbooze has quit [Ping timeout: 244 seconds]
denvermullets has joined #ruby
denvermullets has quit [Ping timeout: 244 seconds]
mange has quit [Remote host closed the connection]
nil78 has quit [Read error: Connection reset by peer]