m4rCsi has quit [Quit: No Ping reply in 180 seconds.]
m4rCsi has joined #jruby
yosafbridge has joined #jruby
prasunanand has joined #jruby
<GitHub188>
[jruby] bjfish pushed 1 new commit to truffle-head: https://git.io/vix0a
<GitHub188>
jruby/truffle-head c0c7080 Brandon Fish: [Truffle] Binding#{local_variable_get/set} cast name param
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
<GitHub56>
[jruby] chrisseaton pushed 27 new commits to truffle-head: https://git.io/vixzp
<GitHub56>
jruby/truffle-head fffdf8f Chris Seaton: [Truffle] rb_define_alloc_func uses the singleton class.
<GitHub56>
jruby/truffle-head df5f2b2 Chris Seaton: [Truffle] Make native openssl the default and replace JRUBY_TRUFFLE_NATIVE_OPENSSL with JRUBY_TRUFFLE_SHIM_OPENSSL
<GitHub56>
jruby/truffle-head 86c730d Chris Seaton: [Truffle] Handle rb_define_method with argc of -1
deobalds has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
deobalds has quit [Quit: Computer has gone to sleep.]
deobalds has joined #jruby
cprice has quit [Ping timeout: 264 seconds]
tenderlove has quit [Read error: Connection reset by peer]
tenderlo_ has joined #jruby
deobalds has quit [Ping timeout: 240 seconds]
temporalfox has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
flavorjones_ has joined #jruby
atambo__ has joined #jruby
jsvd_ has joined #jruby
fidothe_ has joined #jruby
bruceadams_ has joined #jruby
atambo__ is now known as atambo
justinmcp_ has joined #jruby
Antiarc_ has joined #jruby
deathy_ has joined #jruby
chrisarc1nd has joined #jruby
cpuguy83_ has joined #jruby
lanceball_ has joined #jruby
headius_ has joined #jruby
clayton_ has joined #jruby
joast has quit [*.net *.split]
headius has quit [*.net *.split]
jsvd has quit [*.net *.split]
fidothe has quit [*.net *.split]
flavorjones has quit [*.net *.split]
atambo_ has quit [*.net *.split]
clayton has quit [*.net *.split]
deathy has quit [*.net *.split]
lanceball has quit [*.net *.split]
bruceadams has quit [*.net *.split]
justinmcp has quit [*.net *.split]
Hobogrammer has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
codefinger has quit [*.net *.split]
Antiarc has quit [*.net *.split]
chrisarcand has quit [*.net *.split]
cpuguy83_ is now known as cpuguy83
lanceball_ is now known as lanceball
flavorjones_ is now known as flavorjones
clayton_ is now known as clayton
jsvd_ is now known as jsvd
jensnock_ has quit [Ping timeout: 244 seconds]
fidothe_ is now known as fidothe
pawnbox has joined #jruby
bruceadams_ is now known as bruceadams
deathy_ is now known as deathy
donV has joined #jruby
codefinger has joined #jruby
Hobogrammer has joined #jruby
deobalds_ has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
prasunanand has quit [Ping timeout: 265 seconds]
pilhuhn has joined #jruby
temporalfox has joined #jruby
deobalds_ has quit [Quit: Computer has gone to sleep.]
prasunanand has joined #jruby
blaxter has joined #jruby
temporalfox has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
blaxter has quit [Quit: foo]
claudiuinberlin has joined #jruby
lobner has joined #jruby
shellac has joined #jruby
sandelius has joined #jruby
<sandelius>
good morning guys
lobner has quit [Quit: Ex-Chat]
<sandelius>
Would faye websockets on jruby be a viable option to node.js regarding performance?
<sandelius>
or is there another tool for jruby that's more suitable? I rather write ruby then javascript
shellac has quit [Quit: Computer has gone to sleep.]
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
jensnockert has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
donV has quit [Quit: donV]
Hobogrammer has quit [Ping timeout: 244 seconds]
donV has joined #jruby
Hobogrammer has joined #jruby
shellac has joined #jruby
donV has quit [Quit: donV]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 265 seconds]
donV has joined #jruby
deobalds has joined #jruby
pawnbox has joined #jruby
jensnock_ has joined #jruby
jensnockert has quit [Ping timeout: 240 seconds]
deobalds has quit [Quit: Computer has gone to sleep.]
temporalfox has joined #jruby
pilhuhn is now known as pil-afk
donV has quit [Quit: donV]
temporalfox has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
temporalfox has joined #jruby
deobalds has joined #jruby
temporalfox has quit [Client Quit]
donV has joined #jruby
drbobbeaty has quit [Remote host closed the connection]
Specialist has joined #jruby
bbrowning has joined #jruby
drbobbeaty has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
<GitHub89>
[jruby] mprins opened pull request #4180: Aimplify appveyor.yml, Maven is now a pre-installed package (master...patch-1) https://git.io/vipnb
<headius>
nice...don't have to hassle everyone to rebase now
<chrisseaton>
headius nirvdrum does it re-run the tests on the rebased commits though?
<headius>
it looks like it's merge-time
<headius>
so that would be up to you
<headius>
or rebase, merge, test locally, and then push like before
hobodave has joined #jruby
<nirvdrum>
chrisseaton: Uncertain, but I hope so. I know similar tools don't re-run the tests, which I think is a bit misguided.
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
temporal_ has quit [Read error: Connection reset by peer]
electrical_ has quit []
_whitelogger_ has joined #jruby
jensnockert has quit [Remote host closed the connection]
electrical_ has quit []
jensnockert has joined #jruby
electrical_ has joined #jruby
<eregon>
enebo: Hi!
<enebo>
eregon: a couple of questions
<enebo>
eregon: Do I understand this right that you guys are close to not using our AST any more?
<eregon>
Not so sure about that, ask chrisseaton
<chrisseaton>
I forked your parser yes, but it's not on the master branch yet
<enebo>
eregon: ok I just saw there was an issue on that…it actually makes sense you are still using the AST based on that issue question
<chrisseaton>
There's almost no modifications yet, except for the support for inline JS
<enebo>
chrisseaton: ok
<enebo>
chrisseaton: eregon: once you guys have your own copy I might play with hybridized IR/AST
<enebo>
Like making StringOperands directly
<eregon>
so StaticScope.variableNames only list the variables in that specific scope?
<eregon>
it seems wrong for the "for" statements though
<enebo>
eregon: it shows depth 0 lvars so specific to current scope
<enebo>
eregon: for shares static scope of scope it is contained in
<enebo>
eregon: unless we are missing somethign about that?
jensnockert has quit [Ping timeout: 244 seconds]
jensnockert has joined #jruby
<enebo>
eregon: out of curiousity do you need this for some sourcelocation aspect? You don’t need this for ruby semantic reasons do you?
<eregon>
I do
<eregon>
for a spec actually
<eregon>
in the case the block var is shadowing the method var with the same name
<eregon>
yes
<enebo>
I do == ruby semantics?
<enebo>
eregon: are we also broken?
<eregon>
nope
<eregon>
and I wonder why :)
<enebo>
haha…yeah me too
<enebo>
but I thought the parser handled this warning
<eregon>
so when declaring variables in a frame in jruby you just take all variableNames?
<enebo>
or is it that you are picking up wrong variable value
<eregon>
wrong variable so wrong value, in our case the block-level var is just not declared
electrical_ is now known as electrical
<enebo>
eregon: so you potentially do not reserve space for all variables in a frame and it is something to do with that?
jensnockert has quit [Read error: Connection reset by peer]
<eregon>
I think usually we jsut don't use the StaticScope
jensnockert has joined #jruby
<eregon>
I think usually we just don't use the StaticScope
jensnockert has quit [Remote host closed the connection]
<enebo>
eregon: variables are lexical and resolved when we build so we know the inner lvar in the block is depth 0 slot n
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
<enebo>
eregon: there is no way it can decide to go deeper
<enebo>
eregon: by end of parse time it considers those to be totally different variables from a runtime perspective
<headius>
yeah it basically just puts a hard stop into the scope hierarchy so it doesn't treat accesses as depth > 0
<chrisseaton>
Yes we don't use the static scope. Maybe we should?
<eregon>
right, so the DAsgnNode has depth 0, but we just happen to do a lookup, which most of the time is correct if the variables are properly declared
<headius>
might be a good idea... StaticScope is the compendium of all knowledge about the structure of vars and args
<enebo>
I sort of wish we only had variable info in IRScope or StaticScope but we have some duplication
<enebo>
but staticscope is not going away
<enebo>
chrisseaton: do you walk scopes every time you see a variable reference?
<chrisseaton>
Yes - obviously it's almost always in the two two scopes so it's not a problem
<enebo>
chrisseaton: I mean we sort of do if depth is 3 but we could in theory pre-resolve those
<chrisseaton>
We just build our own 'frame descriptors' as we go
<enebo>
chrisseaton: even if you don’t use staticscope I advocate performing the resolution when you parse
<chrisseaton>
Oh sorry, we do do it as we parse
<chrisseaton>
Or 'translate' we'd say, meaning JRuby AST to Truffle AST
<chrisseaton>
But this is why we need to fork the parser as it's crazy that we allocate your AST, and then throw that away and convert to ours
<enebo>
ah ok but your translation does not use staticscope so we lose some info for you guys
<chrisseaton>
Yes, that's it
<headius>
you should also be able to see depth = 0 versus depth > 0 in the assignment nodes
<enebo>
since we do not fully replicate static struction of source
<headius>
the depth = 0 "c" would shadow a depth = 1 "c"
<enebo>
yeah headius true
<headius>
if there's no depth = 1 "c" there's no shadowing...but it's always just offset + depth in the parse artifacts and declared or not in StaticScope
<headius>
should be everything needed there
akp has quit [Remote host closed the connection]
<enebo>
eregon: chrisseaton: so staticscope should not be needed just examining location field (getDepth() and getIndex())
<enebo>
unless you have plans to supoprt more than 16 bit worth of lvars in a scope
<chrisseaton>
I can't remember why, but I think that wasn't enough for some reason
<headius>
32767 local vars is enough for anyone
<headius>
I guess we don't need the sign bit
<headius>
I could see someone generating Ruby code with 65535 local vars in it
<enebo>
headius: this also assumes we can have 32k nested variable scopes active :)
<eregon>
the problem is this is doing seeing variables lazily when seeing the first DAsgnNode or DLocalNode
<eregon>
so it would make normal lookup of variables inheriting scopes go wrong
<headius>
enebo: that would be impressive
<headius>
eregon: yes, precisely
<headius>
the parser has already made the determination of what vars are at what levels and put it in depth and StaticScope
<enebo>
to a degree staticscope is not neccesary for us for execution until we encounter an error or use a reflective method
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
yes, it is metadata mostly unused at execution time
<headius>
I think we do use it for some of the weirder super and argument layouts
<enebo>
actually it is a regret of mine we did not swap (or eliminate) dynscope and staticscope for 9k
<eregon>
guys, this is terribly good at confusing me:
<eregon>
public class ForNode extends IterNode {
<eregon>
private Node iterNode;
<enebo>
heh
<headius>
if regrets were peaches we'd all be in the pits
<eregon>
terminology is already hard enough like this :p
<enebo>
eregon: I admit it is confusing but this is one of those things where for nodes smell a lot like blocks but have this one extra variable scoping wrinkle
<eregon>
I think I foudn a bug in for which causing spec failures:
<eregon>
def init_block(s)
<eregon>
s.dyn_ltree
<eregon>
for n in 0 ... L_CODES
<eregon>
the last "s" is considered depth 0, that's clearly wrong, isn't it?
<headius>
all vars in a for loop live in the scope above
<eregon>
or is it just the location of LocalVarNode which is not set?
<eregon>
headius: right, but then it should be 1
<headius>
well for doesn't have a scope
<headius>
so there is no 1
<eregon>
because the impl will actually have to walk one frame up
<enebo>
eregon: it does not for us
<headius>
right
<enebo>
eregon: the scope above and for work in the same frame
<headius>
the method and the for use the same "frame"
<eregon>
but how can you invoke each without adding an extra frame on stack??
<headius>
the original method's frame is used
<headius>
re-pushed
temporalfox has quit [Ping timeout: 260 seconds]
<headius>
this is one reason for loops are *slightly* lighter-weight than regular each { } loops
<headius>
I admit having ForNode extend *and* aggregate IterNode is weird, there's probably not a good reason for that
<enebo>
well not in 9k
<enebo>
in 1.7 they evalauted in the interp nearly identically
<enebo>
from a object modelling perspective it is weird but from a code duplication standpoint fixing itternode in interp would also fix for
nicksieger has joined #jruby
<headius>
well in MRI don't they still have ITER aggregate CALL in their AST?
<headius>
that probably had a hand in this structure
<enebo>
headius: yeah for sure
<eregon>
ugh, weird for semantics
<headius>
`for` is a bit of a dinosaur
<headius>
I still like the syntax but I'd rather it have a proper scope
<enebo>
It should just be a MACRO!
<headius>
lexically, it does scope
<headius>
but then it doesn't really
<eregon>
how?
<headius>
I guess while and if don't have their own scope either, and that's why for doesn't
lanceball is now known as lance|afk
<enebo>
for should be removed from the language since literally no one uses it
<headius>
it was intended to be a depth 0 language construct, but it depends on calling through another method unlike while
<enebo>
no one who writes ruby for more than a few months
<enebo>
while does not scope either
<enebo>
oh you said while already
<headius>
yeah, it's obvious for was intended to scope like while and if, but it has the weird #each snag
drbobbeaty has joined #jruby
<enebo>
we could translate this during build to a while loop that calls each
<eregon>
yeah teh stack is like: ... -> frame X within method -> frame Y in each -> frame X within for
<eregon>
the*
<enebo>
since but the arg passed in still follow block rules
<eregon>
the arg passed in is hoisted in the method though
<eregon>
the var in for var in I mean
<enebo>
heh I think of hoisted being other direction
<enebo>
eregon: you mean it is in scope of original method after for finishes
<eregon>
hoisted out of loop :)
<enebo>
eregon: ok :)
<headius>
eregon: it just parses as though for doesn't have any scope of its own
<eregon>
yeah
<chrisseaton>
We just translate it to an each and adjust the scope
<chrisseaton>
It's pretty easy
<enebo>
so parameter binding would be the only reason why keeping it as a special block makes sense for us (beyond making a construct rarely used work better)
<eregon>
which is really awkward for impl since it means reusing a frame already on the stack for invoking something else (both a method and the for "block)
<eregon>
we don't that, but therefore we have to not trust any depth information at that point ;)
<enebo>
yeah so our AST does not fit your desired needs for this case
<enebo>
which is what precipitated the original question
cprice has joined #jruby
<headius>
or at least, not the AST alone
<enebo>
eregon: I would be happy if you guys wanted you could add a flag which changes depth if truffle mode is on
<headius>
they aren't using our parse anymore anyway
<enebo>
headius: well nearlty not
<enebo>
but yeah if you plan on having your own parser copy anyways I guess they would make more sense to update to your parser sooner than later
<enebo>
headius: I guess we could add an extra scope though and it will end up eliminated anyways since nothing would be in it
<enebo>
headius: personally I am not sure we get a lot from the work at this point though
<enebo>
buildFor in IRBuilder is only 7 lines of code
<eregon>
I'm still surprised you push an already-executing frame on stack again, this sounds almost like continuations :p
<headius>
pretty sure it's no different in MRI or rbx
<enebo>
hmmm for has no list dereferencing does it
<headius>
and it is a delimited continuation, no?
<eregon>
enebo headius do you know if variables in StaticScope.variableNames are interned?
<enebo>
eregon: hehehe
<enebo>
eregon: I am laughing because someone just opened a bug that we depend on them being interned
<headius>
they are currently but we'd rather not have to guarantee that
<enebo>
eregon: but they are interned
<headius>
most of our identifier interning is a relic from days when string == string still had perf advantages over string.equals(string)
<enebo>
eregon: but we are changing code internally back to using equals() since it does not really have any perf impact to call equals vs ==
<eregon>
ok I;'ll keep my explicit intern call then :)
<headius>
enebo: no perf impact when they actually are the same string, anyway :-)
<enebo>
eregon: we might be coming to a decision point sooner or later to use bytelist over String for variables
<headius>
as in the same object
<enebo>
headius: yeah
<headius>
if they're not the same object .equals is always O(n)
<headius>
(now)
<enebo>
headius: it seems like we will always use intern internally but for external libs coming in they might end up being less performant if they do not intern
<headius>
we'll probably always intern some way, but it may not be String#intern
<enebo>
Not sure why I addressed that to you :)
<headius>
e.g. ByteList internment
<enebo>
yeah if we move to bytelist this will be a different story
<chrisseaton>
We want to do that (but to ropes)
<chrisseaton>
So all internal identifiers are the same rep as Ruby strings
cprice404 has quit [Remote host closed the connection]
<enebo>
chrisseaton: hopefully always a leafnode
nicksieger has quit [Read error: Connection reset by peer]
cprice404 has joined #jruby
<enebo>
but yeah our thoughts on this are because symbols and strings have some mismatches
<headius>
yeah I'd assume all identifiers end up as their own leaves in a rope
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton>
enebo: doesn't need to be a leaf - there's no advantage to leaves really - you can cache the byte[] at any level you want, and you can identity compare at any level as well
<chrisseaton>
(there's the wasted space of the child nodes of course)
<enebo>
chrisseaton: yeah I just meant it would be weird to see a tree internally for an ident
<enebo>
chrisseaton: not that it wouldn’t work ok
camlow321 has joined #jruby
camlow321 has quit [Client Quit]
<enebo>
chrisseaton: eregon: so if you guys have a forked parser which is landing soon should we be changing anything on our side?
nicksieger has joined #jruby
cprice has quit [Quit: Konversation terminated!]
<GitHub86>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/vipDh
<GitHub86>
jruby/truffle-head 55d74cb Benoit Daloze: [Truffle] Use the StaticScope to find the block-local variables....
<chrisseaton>
you can change what you want now - we'll look at changes and pull in things that we need for 2.4 or whatever
<chrisseaton>
we have a pretty nasty hack for inline JS which you can copy if you really want :)
camlow325 has quit [Ping timeout: 260 seconds]
<enebo>
chrisseaton: I keep thinking you guys will want a radically different parser to generate your own nodes directly
<chrisseaton>
Yeah we will, but haven't done that yet
<enebo>
chrisseaton: I guess maintenance is a concern but it iwll help with your startup time
<enebo>
chrisseaton: ok
<GitHub11>
[jruby] eregon closed issue #4181: Parser: How to know the block-local variables https://git.io/vip0k
<chrisseaton>
Hopefully the structure of the parser grammar can stay the same so we can copy you when new language features are added, and we'll just change the actions to emit our nodes instead of yours
<chrisseaton>
It's not going to be a productivity bonus we know
<enebo>
yeah having same structure would be nice if it is not too painful
<enebo>
like maybe #ifdef :)
jensnockert has joined #jruby
<chrisseaton>
I was planning to write a great new parser from scratch in Antlr, but gave up on it
<enebo>
I GOT NOTHING :)
<chrisseaton>
All parser tools are terrible
<enebo>
chrisseaton: yeah I am not surprised and Ruby LALR gives interesting error order too
<enebo>
not to mention all the lex_state magic
<headius>
chrisseaton: you'd have been the first to succeed, had you succeeded
<headius>
next closest attempt was for now-defunct xruby, and they never got anywhere near complete parsing
<enebo>
I think _de was working on unwinding the lexer at one point
<headius>
defunct may be a bit strong...I think they're still used by some of the mobile Ruby frameworks
<enebo>
not really sure how big the grammar would need to be (assuming it is not ambiguous already — past quote nesting)
<chrisseaton>
For a language like Ruby I'm sure hand-written lexer and recursive descent parser is the best way
<chrisseaton>
Otherwise half your code is fighting the tools
<enebo>
chrisseaton: RDP for Ruby would be neat
<enebo>
chrisseaton: for IDE if nothing else
<enebo>
chrisseaton: since they re-parsing from a method entry point would be trivial
<enebo>
or maybe not trivial but more obvious than trying to do it with lex/flex/bison/jay
<headius>
I hate parsers
<enebo>
or beaver(tm)
<headius>
(c) 2016 headius
<enebo>
speaking of beaver that is one project I would like to convert enough to use instead of Jay since it would be LALR in Java
<chrisseaton>
Jay - that's a disaster as well
<enebo>
GHAHAHAHA
<chrisseaton>
The only way to build our parser is with some specific version of some binary tool?
<headius>
but it's our disaster
* headius
puffs out his chest
<enebo>
chrisseaton: I invite you to read the source code of Jay…it is memory lane
<headius>
just interpret it with truffle and you won't have to build the binary
<headius>
problem solved
<enebo>
there are pdp-11 comments in it
<enebo>
fuck yes!
<headius>
I've still only heard of two projects ever using jay: us and the Mono C# compiler
<enebo>
chrisseaton: yeah you need to compile to LLVM IR and use sulong to make SVM binary
<enebo>
although it sounds like the cure might be worse than the disease
<enebo>
I think we are stuck with some LALR parser but if we have a pure-Java one we would end up eliminating this complaint
<headius>
enebo, eregon: I'm going to remove remaining blockLocalVariable stuff from ArgsNode and all consumers...which includes truffle MethodTranslator on master...cool?
drbobbeaty has joined #jruby
<headius>
in fact that seems to be the only consumer of getBlockLocalVariables
<chrisseaton>
I also had a grand scheme for unified Truffle parsers so we could have all languages inline - it would be like parser combinators in that every node would have a parse method as well as an execute method
pawnbox has joined #jruby
<headius>
definitely need top-down to make that work nicely
pilhuhn is now known as pil-afk
<headius>
what's your hack btw?
<chrisseaton>
headius: won't that break the method translator on master?
<enebo>
headius: happliy but I guess it depends on eregon
<headius>
chrisseaton: the field never has any content so it shouldn't
<headius>
nobody ever sets it, only truffle reads it currently
<GitHub126>
jruby/master 418dc70 Charles Oliver Nutter: Remove unused blockLocalVariables stuff from ArgsNode. #4181
drbobbeaty has joined #jruby
<eregon>
enebo: I merged master in truffle-head, waiting for the build to get green to do it the other way too
<bga57>
I recently installed a new certificate from Let's Encrypt on my imap server, and with both jruby 1.3 and jruby 9.1.5.0, both claim there's something wrong with the certificate, but MRI has no problem with it.
jensnockert has quit [Read error: Connection reset by peer]
<GitHub27>
jruby/master 886cbe9 Benoit Daloze: [Truffle] Keep the simple ci.hocon on master.
<headius>
bga57: that will help, thanks
cprice has joined #jruby
cprice404 has quit [Ping timeout: 265 seconds]
<bga57>
It looks like I'm using jruby-openssl 0.9.17, which appears to me to be the latest version.
akp has quit [Ping timeout: 255 seconds]
<headius>
ok
shellac has quit [Remote host closed the connection]
<GitHub107>
[jruby] eregon pushed 1 new commit to truffle-head: https://git.io/vipbZ
<GitHub107>
jruby/truffle-head d4e5f80 Benoit Daloze: Revert "[Truffle] Make native openssl the default and replace JRUBY_TRUFFLE_NATIVE_OPENSSL with JRUBY_TRUFFLE_SHIM_OPENSSL"...
<GitHub93>
[jruby-openssl] bgalbrecht opened issue #106: Net::IMAP won't connect to my IMAP server with jruby-openssl 0.9.17, MRI has no problems with it. https://git.io/vipbE
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
nicksieg_ has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
akp_ has joined #jruby
akp has quit [Read error: Connection reset by peer]
claudiuinberlin has quit [Remote host closed the connection]
akp_ has quit [Read error: Connection reset by peer]
akp has joined #jruby
akp has quit [Read error: Connection reset by peer]
akp has joined #jruby
prasunanand has quit [Ping timeout: 244 seconds]
<GitHub157>
[jruby] abelsromero opened issue #4182: Inconsistent behaviour of same code in Windows, from not finding an installed gem to missing methods https://git.io/vihUX
shellac has quit [Quit: Computer has gone to sleep.]
nicksieg_ has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
<headius>
sigh, one of those days where I do nothing but fiddle with peripheral projects
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
<GitHub98>
[jruby] headius closed issue #4182: Inconsistent behaviour of same code in Windows, from not finding an installed gem to missing methods https://git.io/vihUX
akp has quit [Remote host closed the connection]
akp has joined #jruby
akp has quit [Ping timeout: 255 seconds]
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
hobodave has quit [Quit: Computer has gone to sleep.]
dinfuehr_ has joined #jruby
dinfuehr_ has quit [Remote host closed the connection]
jensnockert has joined #jruby
jensnock_ has quit [Ping timeout: 272 seconds]
nicksieger has quit [Read error: Connection reset by peer]
<nirvdrum>
headius: So, coming back to previous discussion. 1) I think caching character length in ByteList could be very beneficial. 2) I think lazy computing code range adds a lot of complicating code with very little pay-off. I tried to do this initially with an immutable ByteList variant, but ByteList is final. I was tweaking that on the ByteList repo, bu
<nirvdrum>
t there's no easy way to support both within JRuby and I figured changes there would mark a major JRuby version bump. So I went more clean-room on that.
bbrowning is now known as bbrowning_away
nicksieger has joined #jruby
temporalfox has joined #jruby
temporalfox has quit [Read error: Connection reset by peer]
temporalfox has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
claudiuinberlin has quit []
temporal_ has joined #jruby
tcrawley-away is now known as tcrawley
nicksieg_ has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
temporalfox has quit [Read error: Connection reset by peer]
nicksieg_ has quit [Read error: Connection reset by peer]
nicksieger has joined #jruby
nicksieg_ has joined #jruby
nicksieger has quit [Read error: Connection reset by peer]
pawnbox_ has quit [Remote host closed the connection]
<enebo>
nirvdrum: do you mean major version because native exts will depend on bytelist being final?
nicksieg_ has quit [Read error: Connection reset by peer]
<nirvdrum>
enebo: Yeah. You'd need a major version bump of bytelist at the very least, since others might be using it.
<enebo>
nirvdrum: yeah I guess bytelist might be public enough where it may require a jruby major rev too
<enebo>
nirvdrum: I guess it depends on whether a final can be made non-final and still work against old compiled code
temporalfox has joined #jruby
temporal_ has quit [Read error: Connection reset by peer]
<nirvdrum>
enebo: There was an open question of how much your performance relies on those being non-virtual calls, too.
<enebo>
nirvdrum: well I guess we are trading perf for perf no? We cannot know until we try
nicksieger has joined #jruby
<nirvdrum>
enebo: Yeah. It was more that the string code seems to have some implicit optimizations in mind.
<nirvdrum>
Maybe those are obsoleted now.
<enebo>
nirvdrum: which may or may not matter since many of those were considered in a Java 1.4 world
<enebo>
nirvdrum: I think unfortunately there is no way to know without trying htough
<enebo>
nirvdrum: which I guess is an obvious answer :)
<nirvdrum>
Keeping track of code range and character length as you implement operations is doable. But it is more bookkeeping.
hobodave has joined #jruby
<nirvdrum>
*in a mutuable object
<enebo>
nirvdrum: true
<nirvdrum>
The code range one in particular I think just complicates code. And there are very few places where you can do much of anything with an unknown code range.
<enebo>
nirvdrum: we have talked about some of this like what parts are done
<enebo>
we need it in IO
<enebo>
parser does CR
<enebo>
but could do length pretty easily
<nirvdrum>
Yeah. You and I discussed in more detail at RubyKaigi. But headius wasn't there and he had some questions on what was innate to ropes and what could be done with ByteList.
<enebo>
ah yeah
<enebo>
I only saw the tail
<enebo>
IO is more complicated I guess but obviously doable
<enebo>
Java calls into Ruby would be another vector we did not talk about
<enebo>
nirvdrum: it might be we could start with length/cr being optional and then marking off areas as we go
<nirvdrum>
enebo: It'd be nice if RegexpNode had the code range, too.
<nirvdrum>
It seems that could go do a similar path as StringNode.
<enebo>
nirvdrum: which would be undesirable but would still have some improvements to perf while work is ongoing
<nirvdrum>
Err, RegexpParseNode and StrParseNode.
<enebo>
nirvdrum: totally esepecially since we use StringTerm to process the body of a regexp :)
<enebo>
nirvdrum: in fact we calculate cr I think for regexp body but just do not store it in the regexp
<enebo>
nirvdrum: tSTRING_CONTENT I think does a cr calc
<nirvdrum>
enebo: One nice part about pre-calculating the code range is I can set a breakpoint anywhere we need to calculate it and see why. The lexer really gets us a far way during bootstrap.
<enebo>
nirvdrum: which is innefficient since we walk the string a second time for that calc
<enebo>
nirvdrum: ah yeah that is a neat way of seeing it…so you can filter our the lexer call then
lanceball is now known as lance|afk
<nirvdrum>
I don't even need to filter it. When we get it from the lexer, I don't need to calculate anything. So I just trace when we hit CR_UNKNOWN basically.
<nirvdrum>
In most cases, we can build up the CR based on what we already know.
camlow325 has quit [Quit: WeeChat 1.5]
tcrawley is now known as tcrawley-away
<GitHub35>
[jruby] nirvdrum opened issue #4183: Add code range to RegexpParseNode https://git.io/vihV5
<nirvdrum>
enebo: There you go ^
<enebo>
nirvdrum: thanks buddy
<GitHub128>
[jruby] headius pushed 2 new commits to master: https://git.io/vihwU
<GitHub128>
jruby/master 21b9760 Charles Oliver Nutter: Expose dedent_string. Fixes #4176
<GitHub128>
jruby/master f8c373e Charles Oliver Nutter: Trial by fire for jnr-ffi 2.1 and jffi 1.2.13.
<GitHub51>
[jruby] headius closed issue #4176: NoMethodError: undefined method `dedent_string' when lexing squigly heredocs in Ripper https://git.io/viNQ6
<nirvdrum>
I'd offer to do the work, but I'm not all that familiar with jay.
<enebo>
nirvdrum: newRegexpNode is in ParserSupport
<enebo>
nirvdrum: no rebuilding should be neccesary
<chrisseaton>
nirvdrum: ask me if you want to do it - there's even a jt command for building the parser now!
<nirvdrum>
enebo: I think I asked in Japan, but don't really recall: how do you want to handle issues upstream? E.g., String#b really should never need to set the coderange to CR_UNKNOWN. Since the resulting encoding is ASCII-8BIT, it can only possibly be CR_7BIT or CR_VALID.
<nirvdrum>
But you currently match almost line-for-line what MRI does.
<enebo>
nirvdrum: I am not sure I mremeber what you suggest for this case? recalc or just set to valid?
dinfuehr_ has joined #jruby
<enebo>
nirvdrum: ok so regexp is a little more complicated depending on whether interpolation happens too
<nirvdrum>
enebo: Well, it's more a matter of I didn't just fix it in JRuby because I'm not sure if you value being as close to MRI as possible more.
<enebo>
nirvdrum: I guess to me it is merely a blackbox issue
dinfuehr_ has quit [Ping timeout: 265 seconds]
<enebo>
nirvdrum: if we can match semantics in string handling I think we can internally do whatever so long as we have confidence
<nirvdrum>
I could report upstream and let it trickle down.
<nirvdrum>
Okay.
<nirvdrum>
I know there was some concern about keeping things mostly the same so porting was easy.
<enebo>
nirvdrum: but for some things it is in flux enough where I would not stray too far from MRI
<enebo>
nirvdrum: like I would not try and make new productions in the parser because the likelihood of tripping over that would be a big risk
<enebo>
nirvdrum: but strings are settled more or less.
<enebo>
nirvdrum: I could see them accidentally changing a semantic in code like cat19() but with that said I think we can push back or at least realize the change makes sense
<enebo>
nirvdrum: IO was one which I do not think we want massive changes to code
<enebo>
nirvdrum: but we can calc cr and length and still mostly follow MRI there
<nirvdrum>
But we can do that because we don't have CR_UNKNOWN in live ropes.
<enebo>
nirvdrum: yeah so long as we always calc that makes sense
<nirvdrum>
You could add an extra case to handle CR_UNKNOWN easily enough here.
<headius>
asarih: should I shoot support an email about getting a debug instance, or can you just set me up?
<nirvdrum>
Right now, you and MRI just clear the code range.
<nirvdrum>
I don't know if String#b really matters. But there have been several cases like that I've come across.
<headius>
support usually directs me to use docker, but I'd like to investigate it with the same stack
<enebo>
nirvdrum: we 28 occurrences of UNKNOWN
<nirvdrum>
enebo: How many for scanForCodeRange?
<enebo>
nirvdrum: if we can guarantee always calc’d we can probably kill all the confiditionals using it
<enebo>
nirvdrum: 30 :)
<enebo>
nirvdrum: sort of thinking those get paired up a lot
<headius>
I don't know of any reason old code would fail if a final class suddenly became non-final
<enebo>
headius: yeah I cannot remember
<nirvdrum>
enebo: I think there's a lot of cases that just scanForCodeRange without the check. But I could be wrong.
<enebo>
nirvdrum: just a pretty similar number of occurrences
<nirvdrum>
Cool.
<nirvdrum>
enebo: And not that I think you need much convincing, but you also have this issue where strings that are ASCII-only UTF-8 end up going down a slower path for String#length when the CR is unknown. I think your lexer changes to pass the CR cleared up a lot of those though.
<nirvdrum>
And I was going to have an ImmutableByteList.
<headius>
right, ok
<headius>
is what you have now too far removed from ByteList for us to use it in JRuby classic?
<headius>
perhaps with some massaging of ByteList and your stuff together
<nirvdrum>
Obviously things like concatenation aren't represented by different nodes in this case, but it seemed a good start.
<nirvdrum>
headius: The core types use some Truffle annotations. We could find a way to deal with that. The real issue is the operations themselves are done as Truffle nodes.
<nirvdrum>
So, you'd need to tear through RubyString.
<headius>
well on that note I think we may want to consider what an external annotation project might look like
<headius>
it would be helpful if Graal recognized some external ValueObject annotation for that other issue I filed, for example
<headius>
something we could both use without JRuby classic having to pull in Truffle
<nirvdrum>
Yeah. chrisseaton and I talked about a truffle-annotations that would just no-op in the normal case. Sorta like @Nullable.
<headius>
tearing through RubyString sounds like a great quest...I am without fear
<headius>
yeah that's a great idea
<headius>
it would help us find more ways to reduce the gap between the impls, share more stuff we can't
<headius>
and maybe get a bit more out of Graal for classic
<chrisseaton>
I can still help someone add support for Sulong in JRuby classic - just don't have time to do it myself - we need some students or something
<headius>
hmm
<nirvdrum>
headius: I'm off to dinner for a bit. I'll be back around this evening if you want to discuss more.
<headius>
if we had a post we could tweet I bet we could dig up some students
<headius>
I'd back that for sure
<chrisseaton>
Could do it after RubyConf
<chrisseaton>
oops not supposed to be talking about that until they announce
<headius>
and it could prove out the sulong approach
<headius>
hah
<headius>
well you haven't said anything except timing :-)
<headius>
I'm on board with sulong exts + classic in any case....practical or not it would be eye-catching
<headius>
and it might be practical too :-)
<headius>
now if only we could figure out how to fork
<dfr>
Stupid nokogiri assuming there's always just a single JRuby runtime :(
nicksieger has quit [Read error: Connection reset by peer]
<headius>
dfr: that's a C API problem really
<enebo>
headius: I suspect we need to make sure it is not the default since it likely won’t be as fast as java native exts for us
<headius>
the Java nokogiri should work fine with many instances
<headius>
enebo: for sure
<headius>
I've only ever figured C ext support would be a last resort
<enebo>
I guess we have went down this path already :)
<dfr>
headius, I've traced a concurrency issue to them filling a cache of Nokogiri instances in a map that is shared between runtimes.
<headius>
like if you have some proprietary library binding you don't want to port
<headius>
dfr: well that's definitely wrong
<enebo>
yeah there is definitely a benefit
<headius>
I always wanted to add a user-facing cache in org.jruby.Ruby but could never come up with something generic enough
<headius>
chrisseaton, nirvdrum, enebo: maybe we should try using github projects to track these things
nicksieger has quit [Remote host closed the connection]
<headius>
sulong C ext for classic, shared ropes backend
<headius>
dfr: ahh ok...hopefully that's in a released version
<headius>
nokogiri is too big
<enebo>
headius: I have not looked at the new support yet
<chrisseaton>
sounds great, but we don't have much time to actually do that work
<chrisseaton>
ramping up to RubyConf and our yearly review for the next few months
<headius>
chrisseaton: but we might
<headius>
again, after rubyconf
<enebo>
heh
<headius>
I mostly just don't want to lose the project and discussion
<chrisseaton>
yeah and we can help anyone else who wants to help
<headius>
and not open a meaningless issue
<enebo>
headius: we should team on rails 5 this week
<headius>
totally
<headius>
I was going to today but I'm doing a big rev to jffi and jnr-ffi
<headius>
varargs, struct packing, aarch64, many other fixes
<enebo>
nice
<headius>
yeah, finally have some contribs
<dfr>
headius, unfortunately upgrading for me is kinda out of question. So that doens't help me much. But at least I now know what the issue is. I think I might try to undo the updaing of their cache class after I load nokogiri as a work-around >.<
<headius>
dfr: yeah that's a tough one to work around...good luck
<headius>
there is one way
* headius
signs off for the day
<headius>
j/k
<headius>
if you can get each jruby + gems instance to be loaded in their own classloaders, they'll isolate by virtue of classloading
<headius>
it would work 100% but it would be tweaky to set up
<headius>
that fix was three years ago and I commented on future peril
<headius>
the patch does use one of my suggested mechanisms (getInternalVariable) so I think it is probably just fine
<flavorjones>
hey team. how can I help with Nokogiri?
<flavorjones>
dfr: please be aware that the JRuby port of Nokogiri is largely unmaintained, and was largely written by headius ... *ducks*
<flavorjones>
I kid. What's up?
<headius>
bahaha
<headius>
if I have ten lines of code in there I'd be amazed
<headius>
that was all the servlet princess's work
<headius>
flavorjones: what does maintaining nokogiri mean at this point? I mean...it's XML, I can't imagine things are changing very rapidly
<headius>
other than the drumbeat of surly natives trying to get people to move to Oga
temporalfox has quit [Ping timeout: 255 seconds]
temporalfox has joined #jruby
<flavorjones>
maintenance is minimal at this point
<flavorjones>
other than me monitoring random IRC channels for instances of the work "nokogiri" and asking how I can help
<headius>
kudos
Specialist has quit [Remote host closed the connection]
rcvalle has quit [Quit: rcvalle]
rcvalle has joined #jruby
rcvalle has quit [Client Quit]
<flavorjones>
Seriously, open an issue if there's something I can help with wrt the node cache. Or send a PR and I'll happily merge it.
<flavorjones>
gotta go
enebo has quit [Quit: enebo]
bga57 has quit [Ping timeout: 250 seconds]
rcvalle has joined #jruby
<headius>
flavorjones: it's fixed now apparently, so it's just a problem of upgrading
<headius>
thank you for jumping in though
temporalfox has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<headius>
chrisseaton: GSoC rolls around in a few months too...getting some of these project ideas fleshed out now would help our chances of getting students to work on them