<kares>
already went ahead and updated jossl and readline to use load_ext (JRuby::Util internal API)
<kares>
than there's jar-dependencies + one what is commonly booted by RGs that could use a new release for 9.2.1 is psych
claudiuinberlin has quit [Ping timeout: 240 seconds]
stoffie has quit [Remote host closed the connection]
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
deobalds has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
drbobbeaty has joined #jruby
deobalds has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
stoffie has joined #jruby
rdubya has quit [Ping timeout: 276 seconds]
rawra has quit [Remote host closed the connection]
rawra has joined #jruby
rawra has quit [Ping timeout: 245 seconds]
rawra has joined #jruby
rdubya has joined #jruby
<stoffie>
headius, sorry if I bother you again, I was thinking, where should I start if I want to fix the problem by myself? What do you think could be causing that? I managed to run jruby in a docker ubuntu container so the problem is definitively fedora
rawra has quit [Remote host closed the connection]
rawra has joined #jruby
rawra has quit [Remote host closed the connection]
rawra has joined #jruby
rawra has quit [Remote host closed the connection]
rawra has joined #jruby
rawra has quit [Ping timeout: 268 seconds]
xardion has quit [Remote host closed the connection]
jrafanie has joined #jruby
xardion has joined #jruby
jrafanie has quit [Client Quit]
claudiuinberlin has joined #jruby
<headius>
stoffie: hmm maybe I can take a look at it on fedora too
rawra has joined #jruby
<headius>
kares: ok everything you want me to look at is in pulls then?
<enebo>
eregon: so can I use that code and have it work with our tri-licensed code?
<headius>
patent free? :-D
<eregon>
The license header says Version: EPL 1.0/GPL 2.0/LGPL 2.1
<eregon>
But yeah I'm no lawyer :(
<headius>
should be fine
<enebo>
eregon: ok. sounds ok then
<headius>
patents we won't know about but EPL has protections
<eregon>
I don't think there is any patent in my bug fixes or refactoring in RubyLexer :)
<enebo>
eregon: mostly that code you changed was a direct port of MRI code
<headius>
👍
<eregon>
enebo: Yeah, I saw, I also took at the MRI code :)
<enebo>
eregon: so most of your busting things out of the for loops and stuff was cleaning. I am interested in the feature concept part of this if that is what you mean
<headius>
enebo: if we'd had more time we should have dropped GPL
<eregon>
The check for Emacs -*- in the magic comment is so crazy hand-optimized, it's unbelievable :D
<enebo>
eregon: ah so diverging with that weird double check
<eregon>
In terms of bug fixes only:
<eregon>
* magicCommentMarker() should not scan more than magicLineLength bytes.
<eregon>
offset from the start of the Rope and length the remaining length.
<eregon>
* Fix bug using "str < length" which is meaningless as str is an arbitrary
<headius>
but in this case it looks like it failed to build the native jruby executable, I don't think that matches your issue
<enebo>
eregon: I will look at the emacs weirdness removal though as it has bugged me
<enebo>
eregon: I partially look at this as some weird little organ which is working and isolated so unless we can squeeze some perf on the comment handling or something I may just fix the issues
<eregon>
Yeah I didn't touch the emacs thing beyond simple code style and adding a comment about what it does
<enebo>
eregon: thanks for the commits though. Especially since you found some more corners around whitespace
<enebo>
comments are good too :)
<headius>
stoffie: it does seem to fetch the tarball just fine though
<headius>
I think I'm getting past where you did
<enebo>
eregon: I used to just use a regexp there
<headius>
install --verbose seems to print out some good info
<eregon>
Switching to offset + end position instead of manually updating length sounds like a good way to be less error-prone in parser_magic_comment
<eregon>
enebo: tricky regexp, as it needs to work on raw bytes, since the encoding is defined by the magic comment itself :)
<enebo>
yeah that maybe was the reason why it changed. I don't recall
<headius>
hmm for some reason it's not saving my log from the failed install
<headius>
stoffie: try a --verbose run and see if that has any more info
<enebo>
definitely the fact that it was originally only for encoding and ended up being for pragmas could have been it as well though
<stoffie>
nope
<headius>
ah mine failed because it needs g++ to compile
<headius>
enebo: what's the g++ package on fedora
<headius>
it's not called g++
claudiuinberlin has joined #jruby
<enebo>
maybe a gcc package
<enebo>
headius: I will see
<eregon>
enebo: another cool/fun thing in that set of changes is in TruffleRuby we can reuse String's ropes used for eval(), e.g. in ERB def_method, when lexing/parsing the code for eval().
<headius>
oh gcc-c++
<headius>
I have it
<enebo>
eregon: this is unrelated as we don't use ropes but I wondered about using CoW semantics to just use original source as backing array for strings
<eregon>
enebo: I also added a fair bit of specs for magic comments, so hopefully that should catch bugs if a fix is missing :)
<enebo>
eregon: main issue being it might appear to be a memory leak....OTOH source is not massive generally
<enebo>
eregon: yeah great
<headius>
enebo: mmap
<eregon>
ah, do you mean string literals could just use the source byte[] with an offset?
<enebo>
eregon: yeah
<enebo>
how much source is actually loaded memory wise in even a huge rails app
<eregon>
Yeah sonds tricky as the source be quite a bit larger than the string literals
<eregon>
can be*
<enebo>
as strings mutate less it becomes more appealing
<headius>
string literals + identifiers would be larger percentage but still not large
<enebo>
identifiers I used to think would be good but we make symtable entries now
<headius>
yeah and most are referenced many places for one object
<enebo>
we could have each identifier still pin source but it seems less useful
<headius>
so you save nothing for call side or common var names
<enebo>
My grand thought is if Ruby ever requires source for things like evals so people can .source or something like that then we would be saving that source anyways
<headius>
stoffie: success :-(
<headius>
stoffie: gist me your install --verbose output
<headius>
this os F28 btw
<enebo>
headius: stoffie: I tried this morning and could install on fedora locally
<enebo>
I did a git pull on build-plugin or whereever rbenv source is
<headius>
yeah we've had no other reports and you use fedora so JRuby's well tested there
<stoffie>
headius I already used the -v flag
<eregon>
enebo: yeah if it's like JavaScript which requires to keep the source around then it's an easy clear win :)
<enebo>
eregon: I feel like some day eval will have a source method
<enebo>
eregon: it is one consistent complaint that people cannot figure out what an eval'd method is doing
<enebo>
things like source_location has helped in debugging but it is a half measure if you ask me
<eregon>
Right, I think Truffle keeps the source around, so we could actuall debug eval'd code, as long as the method is reachable
rawra has joined #jruby
<eregon>
Need to try that, would make for a nice demo :)
<enebo>
eregon: yeah I am all for pushing on that front of Ruby
<enebo>
eregon: and thanks for the update on the lexer
<eregon>
I need to go back home, see you guys around
<enebo>
headius: yeah it explains why I do not remember it being possible then :)
<headius>
or at least for T/F values it doesn't consider blank to be true
<headius>
it will appear set to an empty string
<stoffie>
OK guys you did it!
<stoffie>
it works :)
<enebo>
this is a weird one resolution wise
<enebo>
it is an environment issue but I am not sure we can help future problems like this other than a troubleshooting wiki/document on rbenv maybe or us?
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo>
stuffing lots of opinions via -D is likely to add even more weird reports although perhaps preferIPV4Stack is not too dangerous...but some person will complain that we added that some day
<stoffie>
why do you think I encountered this problem and you did not enebo?
rawra has joined #jruby
<stoffie>
Only thing I did on this machine was play around with docker/kubernetes do you think could be it?
Puffball has quit [Quit: Puffball]
<enebo>
stoffie: I don't actually know how the JVM picks myself. It could be an env is pushing it to try via ipv6
<enebo>
stoffie: a weirder question and I think more important one is if you can do ipv6 why did it fail
<enebo>
if we could answer that question we would probably never have a future problem but we still don't know why it decided to prefer v6
<enebo>
It is possible openjdk prefers v6 now
<enebo>
I stopped using fedora packaging for jvms because alternatives does not work well for me and I made my own jvm switcher (I need to test against multiple versions of java)
<enebo>
so I download java as .tar and install locally
rawra has quit [Ping timeout: 264 seconds]
<stoffie>
If I were to reproduce this bug inside a docker container do you think it could be useful for the rbenv folks?
<enebo>
stoffie: possibly also us depending on why ipv6 is not working
<enebo>
stoffie: if it is some env thing in general they would but if C Ruby can run in same env and it is not some specific confuse Java env setting then maybe we have some issue
<enebo>
If I could figure out which ip version I am using locally that would be interesting
<enebo>
since it works for me
<headius>
stoffie: what java version?
<headius>
it is interesting that it says invalid URL though
<headius>
if it's just using ipv6 it should see it's an ipv4 only address and encode that as ip6
<headius>
it's like it's not resolving correctly under ip6
<headius>
or it's trying to feed an ip4 address string to the JDK API and that's trying to use it as an ip6 string?
<stoffie>
openjdk version "1.8.0_171"
<headius>
stoffie: there's some socket logging options, let me dig those up
<headius>
I'd like to know the root problem
<stoffie>
Sure thing! Just tell me what to do
<stoffie>
In the meantime I will be watching some dr house
<stoffie>
damn
<headius>
hmm ok it looks like the ones I was thinking of are only for ssl
<headius>
can you try the raw tarball + PATH and see if it reproduces there?
<stoffie>
that's a lot of vicodin
<headius>
download, unpack, prepend bin to PATH, try to gem install something
<headius>
so it's definitely falling down the ip6 path
<headius>
in Ruby code
<headius>
stoffie: ok I think you should open a jruby bug at this point
<headius>
include that output...there seems to be some issue with how it chooses ip4 vs ip6 in resolv under JRuby
<headius>
when ip6 is present and the JDK tries to use it things go pear-shaped
<headius>
stoffie: how was this instance provisioned? EC2 or something?
<stoffie>
sorry you mean where I got the binaries?
<headius>
is it just a local machine?
<stoffie>
it's my desktop
<headius>
ok, default install of fedora or did you do something special to enable ip6?
<headius>
maybe it just worked because you have ip6 on your network router?
<stoffie>
fresh install of fedora
<headius>
I'm trying to understand why our fedoras are different from your fedora basically
<headius>
I do not have IP6 on any networks I regularly use
<stoffie>
well I have a home router
<stoffie>
it says ipv6 is enabled in the access control of the router panel
<lopex>
calling somewhat in the blind but you might change the precendence in gai.conf ?
<lopex>
*precedence
<headius>
stoffie: ok I'm sure I have not enabled it in mine
<headius>
enebo: maybe you can try throwing ip6 on your network
<lopex>
is it now ipv6 by default on fedora ?
<headius>
stoffie: so just throw what we know into a bug and we can take it from here...but you may need that env until we figure out why it's going wrong
<headius>
lopex: maybe if dhcp provides it?
<headius>
my mac does not have ip6 because none of the dhcp I connect to have ip6
<lopex>
headius: but still can you force it in gai.conf ?