<enebo>
I believe that particular beer only comes in bottle
<enebo>
you see the abv?
<headius>
"Notes of caramel, slight bitterness, slight rust after taste (probably from cap)" - 4.25
<enebo>
It tasted like pure malt
<enebo>
either the camp slowly leeched or it was on side no doubt
<headius>
pure rust
<enebo>
the 2017 had no rust flavor
<enebo>
but you could probably just go to homebrew store and drink some liquid malt extract to get what the 2017 tastes like
<enebo>
maybe in 2028 it gets good
<GitHub6>
[jruby-openssl] headius opened issue #159: gen_random_openssl missing https://git.io/vp8Rl
<headius>
hah
<headius>
yeah you're supposed to cellar it bro
<enebo>
headius: yeah I knew that but with that said this is the only good cellar beer I have tasted that was fucking awful out of the gate
<headius>
a fine addition to your collection
<GitHub161>
[jruby] headius pushed 10 new commits to master: https://git.io/vp8uO
<GitHub161>
jruby/master 3599ab0 Charles Oliver Nutter: Pass symbol through for error here (2.5).
<GitHub161>
jruby/master 97291a8 Charles Oliver Nutter: Tag two inspect-related tests.
<GitHub161>
jruby/master 1402250 Charles Oliver Nutter: Bump to Psych 3.0.3.pre1 to deal with issues.
<headius>
ok that's my last pass over MRI tests...the rest are parser-related or getting punted
<headius>
so it's all up to enebo now
<enebo>
I am confused about that spec:ruby:fast 3 errors
<enebo>
actually I should have read my commit message better
<enebo>
I made it fail
<enebo>
which I figured but I thought it was from an exclude only commit...it was not
<headius>
test:jruby regressed too
<headius>
looks like a bad test
<headius>
enebo: still have that NPE during JRuby tests too
<headius>
from bytelist love
<enebo>
ah yeah the null symbol
<enebo>
not worried about that but I will get to it
<headius>
I see the three spec failures you mentioned
<headius>
definitely some parse error
<headius>
I guess that intends to be guard(->{blah}) do ...
xardion has quit [Remote host closed the connection]
<headius>
two regressions in spec:compiler that also appear to be bad tests
xardion has joined #jruby
<GitHub189>
[jruby] headius pushed 2 new commits to master: https://git.io/vp8zi
<GitHub189>
jruby/master ae0495f Charles Oliver Nutter: Use anon name for file when it is null.
<GitHub189>
jruby/master f2dab99 Charles Oliver Nutter: Change this test for the changing times.
<headius>
enebo: that second one fixes the NPE but you might have something better in mind
<headius>
lunchbreak for me
<enebo>
headius: thanks at this point just having any fix is ok
<headius>
I don't see how it wasn't broken before too though
<headius>
before your change it blindly called getBytes, which would still NPE
<headius>
spec run looks like it just has the parser thing you're looking at, the new Psych failures we need to figure out, and some regression in delete_prefix I just introduced
shellac has quit [Quit: Computer has gone to sleep.]
<GitHub157>
[jruby] headius pushed 3 new commits to master: https://git.io/vp82w
<GitHub157>
jruby/master f848082 Charles Oliver Nutter: Tag remaining Psych failures, since we have other issues (#5142)
<GitHub157>
jruby/master 85babc7 Charles Oliver Nutter: We'll address this separately....
<GitHub157>
jruby/master 3ae5c32 Charles Oliver Nutter: Fix my regressions in String#delete_prefix.
<headius>
ok breaktime...if all goes well there should just be parser failures in MRI and that's it
<GitHub17>
[jruby] headius pushed 1 new commit to psych_3_update: https://git.io/vp825
<GitHub17>
jruby/psych_3_update f02bf17 Charles Oliver Nutter: Merge branch 'master' into psych_3_update
<headius>
enebo: I have a conundrum
<headius>
because you are raising syntax error for some things at build time, that error happens with jit threshold=0 and gets reraised as a compilation error
<headius>
The JIT triggers the build which raises the syntax error
<headius>
I'm going to delete the troublesome test, since it shouldn't even parse
<headius>
but not sure how to handle the syntax error bubbling out during jit
bbrowning is now known as bbrowning_away
<GitHub175>
[jruby] headius pushed 3 new commits to master: https://git.io/vp865
<GitHub175>
jruby/master ad6e096 Charles Oliver Nutter: Tag off a few final MRI 2.5 failures for later.
<GitHub175>
jruby/master 258b2bd Charles Oliver Nutter: Final tweaks for String#delete_prefix!.
<GitHub175>
jruby/master 6ffce7a Charles Oliver Nutter: Just delete this test, since it shouldn't even parse.
<headius>
enebo: that batch addresses or tags everything not related to parser
<enebo>
lopex: this was somewhat why I think it is an obvious reason we already have destructuring
<enebo>
lopex: if signature resolution was name + something about signature it would be more or less an extension
<lopex>
enebo: and what about user modifiable like scala's unapply ?
<enebo>
I admit my scala is weak
<enebo>
(basically martin O. class on edx + about half a book) :)
<lopex>
enebo: if you have case class Foo(a: Int)
<lopex>
you can "intercept" case Foo(a) =>
<lopex>
via unapply method for that class
<enebo>
sounds horrific
<enebo>
I guess it depends on how obvious that behavior is
<lopex>
yeah
<enebo>
and by obvious I mean explicit
<lopex>
but then we go algebra
<lopex>
constructors are bad idea
<enebo>
if you are doing that in a second file or drastically different part of the file then what you read is not what you get
<lopex>
(custom ones)
<enebo>
of course I dislike some aspects of Ruby's typesystem for the same reason. I can look at a def and not realize someone replaced it via an eval somewhere else
<enebo>
with debugging I can source_location or something but that magic gets confusing quick
<lopex>
yep
<enebo>
having n def signatures where a stack trace goes to an ordinary file location is not that confusing to me
<enebo>
having four def address() with different destructurings of different countries address structures probably would not be too confusing but super elegant compared to these manual destruturing we do today
<GitHub163>
jruby/master cf5065a Marcin Mielzynski: add case map tests
<lopex>
headius: at least those
<headius>
but we ran into this because we shaded jline and that started breaking
<headius>
I never dug out the code involved
<nirvdrum>
I can appreciate needing to patch in the gem because there were JRuby versions in the wild. But not getting the change back upstream seems odd.
<headius>
I'd still like to get us using rb_readline in 9.2
<headius>
nirvdrum: this happens all the time
<nirvdrum>
MRI was talking about using rb_readline, too, weren't they?
<headius>
maybe?
<headius>
I had not heard that but it would be nice
<headius>
the less we have to maintain on our own the better...95% of this past year has been support :-\
<nirvdrum>
We're looking at upgrading to Ruby 2.4 now.
<nirvdrum>
That's going to be a bit of work.
<lopex>
nirvdrum: on readline ?
<nirvdrum>
lopex: I mean in general. We need to add implementations for all the new 2.4 methods.
<nirvdrum>
lopex: Our readline implementation is nearly identical to JRuby's.