<headius[m]> G. Gibson: ok well let us know
<GGibson[m]> will do
lopex has quit [Quit: Connection closed for inactivity]
slyphon has quit [Read error: Connection reset by peer]
slyphon has joined #jruby
slyphon has quit [Ping timeout: 264 seconds]
slyphon has joined #jruby
lopex has joined #jruby
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
headius[m] has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
GGibson[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
kai[m] has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
rdubya[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
dentarg[m] has quit [Quit: Bridge terminating on SIGTERM]
jbeyer_wgt[m] has quit [Quit: Bridge terminating on SIGTERM]
daveg_lookout[m] has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
chrisseaton[m] has quit [Quit: Bridge terminating on SIGTERM]
kovyrin[m] has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
boc_tothefuture[ has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
truths33ker[m] has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
truths33ker[m] has joined #jruby
kai[m] has joined #jruby
enebo[m] has joined #jruby
lopex[m] has joined #jruby
rdubya[m] has joined #jruby
TimGitter[m] has joined #jruby
kovyrin[m] has joined #jruby
boc_tothefuture[ has joined #jruby
JesseChavezGitte has joined #jruby
OlleJonssonGitte has joined #jruby
UweKuboschGitter has joined #jruby
byteit101[m] has joined #jruby
MattPattersonGit has joined #jruby
ahorek[m] has joined #jruby
RomainManni-Buca has joined #jruby
MarcinMielyskiGi has joined #jruby
jbeyer_wgt[m] has joined #jruby
kares[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
FlorianDoubletGi has joined #jruby
daveg_lookout[m] has joined #jruby
JulesIvanicGitte has joined #jruby
XavierNoriaGitte has joined #jruby
CharlesOliverNut has joined #jruby
BlaneDabneyGitte has joined #jruby
headius[m] has joined #jruby
TimGitter[m]1 has joined #jruby
GGibson[m] has joined #jruby
chrisseaton[m] has joined #jruby
KarolBucekGitter has joined #jruby
dentarg[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
<boc_tothefuture[> The way the system works (this part is out of my control) is that there will be multiple files that get executed, parsed, etc. Multiple threads will be executing within those files.
<boc_tothefuture[> Morning everyone. Have a JSR223 question.. I have been playing around with the various options here: https://github.com/jruby/jruby/wiki/RedBridge and can't quite get to the behavior that I think my users will expect..
<boc_tothefuture[> What I am trying to work through is instance variables. The users of this system will expect instance variables to be scoped to the file they are in. However, because when coming into a file it is just 'Object' the instance variables seem to get shared between files. Is there anyway for me to fix that and scope the instance variables to just the current file?
slonopotamus[m] has joined #jruby
<slonopotamus[m]> I observe that on JRuby+Windows, Timeout.timeout fails to interrupt IO.read (I'm reading stderr from a spawned process). Interrupting does work on JRuby+Linux though. Is it a known bug?
<headius[m]> slonopotamus: unfortunately that is the case, on Windows we still use the jvm classes for IO and in some cases they are difficult to interrupt
<headius[m]> Process control is one of those cases
<slonopotamus[m]> <headius[m] "slonopotamus: unfortunately that"> What are the cases that can be interrupted? I possibly could reorganize my code to avoid hitting unsupported cases.
<headius[m]> slonopotamus: I think most non-process IO should be ok
<headius[m]> perhaps this is one last project I should try to finish for 9.3
<boc_tothefuture[> Hey headius did you see my question above?
<headius[m]> oh 223 question
<headius[m]> instance variables can't be scoped like that unfortunately
<headius[m]> they are stored on the object and there is no internal indirection to do them per file... you would need to use separate containers with separate objects to keep the instance state for different users or files separate
<boc_tothefuture[> Ok, bummer... is there anyway for me to figure out I am in different files?
<headius[m]> well FILE will always be whatever file was parsed to get the code
<headius[m]> ugh `__FILE__`
<boc_tothefuture[> except.. FILE in this case will just says <script>
<boc_tothefuture[> because its just getting a stream...
<headius[m]> ahh hmm... through our JRuby-specific embedding API there are ways to give it a filename
<boc_tothefuture[> I guess, I was looking for a way in JRuby to get some sort of unique ID of that stream.
<headius[m]> I am not sure if that is possible through 223 API
<boc_tothefuture[> yeah, the javax.script.filename property. I have a PR in place to get that added to the base project.
<headius[m]> I am not familiar with that one, looking
<boc_tothefuture[> Hmm.. I think you told me about it? but it was a while ago.
<boc_tothefuture[> Details with link here: https://github.com/openhab/openhab-core/pull/1885
<boc_tothefuture[> But, no worries.. when that is merged, I could then use that filename.
<boc_tothefuture[> I guess I was hoping there was a way to get a hash of the stream or something.
<headius[m]> aha
<headius[m]> certainly possible I forgot about this but it doesn't seem familiar
<headius[m]> that looks like it will work but I think it will have threading issues
<headius[m]> it is just a single value for the whole container it seems
<boc_tothefuture[> It is synchronized when it loads them and changes the value before each manager.loadScript
<boc_tothefuture[> So I think it shouldn't have thread safety problems in this use?
<headius[m]> ah yeah might be ok
<headius[m]> unfortunate that the 223 API doesn't provide a way to give a filename with the stream
<boc_tothefuture[> Although.. this does create a set of resources that can be run at anytime.. so those would hit the issue.
<headius[m]> directly I mean
<boc_tothefuture[> Ok, thanks.. I will have to ponder how to handle this.
<headius[m]> yeah I know you are leaning on this framework so that limits your options but feel free to brainstorm in here
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
_whitelogger has joined #jruby