<enebo[m]>
trigger_delay.from == state is fine so long as state is not false/il
<enebo[m]>
ah but that should never return true
<enebo[m]>
state && trigger_delay.from == state
<boc_tothefuture[>
ok, I can see that. thanks!
<enebo[m]>
boc_tothefuture: no problem. I pretty rarely need to use nil?. falsey values tend to work but perhaps I just write things that way and I am unaware I am writing that way?
<enebo[m]>
hmm I have not really thought about the notion false is logic and nil is lack of objects. The notion the two overlap is probably not so common.
subbu is now known as subbu|afk
<headius[m]>
state&.== trigger_delay.from
<headius[m]>
so pretty
<headius[m]>
jk
subbu|afk is now known as sbbu
sbbu is now known as subbu
<boc_tothefuture[>
@headius except that would return falsey for nil, and want truthy.
<headius[m]>
it will return truthy if state is nil and from is also nil
<headius[m]>
oh actually no you're right
<headius[m]>
it won't call == at all if state is nil
<headius[m]>
but if state is nil the other form won't call == either
<headius[m]>
trigger_delay.from&.== state != false
<headius[m]>
if it is nil it won't be false, so true
<headius[m]>
if it is not nil it will only be true if == state
<boc_tothefuture[>
wow
<boc_tothefuture[>
those are some options.. not sure if they are super readable. But theya re neat
<headius[m]>
readable schmeadable
<headius[m]>
well this is a good milestone... the FFI io/console passes all tests on CRuby
<headius[m]>
seems to be some issues in our PTY module preventing it from passing on JRuby but it is close
* Freaky
whistles innocently
<Freaky>
I made that for FreshBSD when I was going to pipe stuff to git name-rev, but never ended up using it
<headius[m]>
omg
<headius[m]>
well the problem seems to be that it doesn't actually get its own tty because we can't setsid or ioctl in the child process before execing the next command
<headius[m]>
so mostly a problem in PTY.spawn because we have to use posix_spawn for process launching
<headius[m]>
that causes a few io/console tests to fail because they use PTY.spawn to launch a subprocess and drive it, but tty stuff seems to go to parent tty
<headius[m]>
Freaky: I had not looked at who wrote this until now, what a surprise
<headius[m]>
had forgotten this came from your PR
<Freaky>
yeah, used to use forkpty, which just segfaulted for me
<Freaky>
the current impl worked well enough to be able to talk to a program over a pipe without it buffering excessively
<headius[m]>
it is not on my critical path so I will just open a bug about this and move on for now... my goal was getting io/console green and that seems to have been achieved
<headius[m]>
for now it will be a known bug that PTR.spawn does not properly get its own controlling terminal