<GitHub105>
[jruby] chrisseaton pushed 1 new commit to truffle-execjs-list-languages: https://git.io/vz1xu
<GitHub105>
jruby/truffle-execjs-list-languages c465d06 Chris Seaton: [Truffle] getSupportedMimeTypes -> isMimeTypeSupported
vtunka has joined #jruby
<kares>
headius: enebo: we're mvn deploy-ing for jossl as well ... will setup a wiki to document.
<enebo>
kares: so you mean we missed that yesterday?
<kares>
its not one command mvn deploy and then gem push since if we usually mvn deploy - test it out and than push staging to central + gem push
<headius>
kares: can we just put a BUILDING file or similar in jruby-openssl?
<kares>
enebo: yes but no biggie
<kares>
headius: will do - thanks for reminding us
<headius>
I tried to do a deploy and that didn't work, so I guess it's not set up for snapshots?
<enebo>
kares: I do nearly same for jruby releases but I merely close but not release before gem push
<kares>
headius: should be
<enebo>
kares: I do that in case gem push messes up
<enebo>
after gem push I go from close -> release on sonatype
<kares>
enebo: I do the oposite :)
<kares>
close -> release than gem push
<enebo>
kares: but I do not think it is possible for a release to not work after a successful close
<enebo>
kares: it may just take time but a gem push could fail outright
<enebo>
kares: or at least that is my logic :)
<kares>
well it if fails I do not want it to mvn :)
<kares>
* on
<headius>
kares: what about the issue we found? thoughts?
<kares>
reading - not sure
<enebo>
kares: but I can drop a cloed repo on mvn without releasing
<kares>
thoughts are SSL::Session was added cause ppl were complaining every now and than
<enebo>
kares: so if gem push gets bungled I can still change things. I guess this extra level of deploy on sonatype would be really nice for rubygems as well
<kares>
so I just added it - as much as we can emulate it
<enebo>
we need 2phase commit :)
<kares>
but I can confirm SSLSession wasn't critical
<kares>
do you guys still want to remove it?
<headius>
kares: no, I think we need to have it
<enebo>
kares: is some of that code in JRuby proper?
<headius>
but it's unclear how complete it is or whether its incompleteness will bite us after release
<enebo>
kares: we tried to back off to 0.9.11 and things still did not work
<headius>
I think we've already committed to using 0.9.15 though
<kares>
enebo: jruby had http.rb or similar patched to work without ssl.session
<enebo>
aha
<enebo>
headius: so 0.9.11 is possible if we undo net/http.r
<kares>
enebo: maybe I reverted those - now I'm not sure ... think not
<kares>
I mean the http.rb patches
<kares>
what JRuby are you now worried ... 9K only?
<enebo>
kares: headius: so I am not as sure we have to move forward now that we know why it was failing … I was confused why master dies but 1.7.24 works when it is using 0.9.11
<enebo>
kares: headius: so it was due to us having modified net/http.rb to not use session
<kares>
came surprising to me as well that you suddenly hit issues
<kares>
as I usually do a full jruby test suite run before releasing jossl (and upgrading the one in jruby)
<enebo>
kares: to be fair we only hit on obvious issue with timeout but then headius noticed that a lot of methods assume a ssl struct will always be available
<enebo>
kares: but our full test runs were/are green so it is something missing coverage
<kares>
enebo: aha - so likely there were less of those in 1.7.x
<kares>
in stdlib
<enebo>
kares: it appears when it hits some keep alive sort of boundary it hits this logic
<kares>
najs
<enebo>
kares: so you need to install several gems at once to hit this code
<kares>
worth an IT test :)
<kares>
I mean jossl is so under tested ... with real world usage
<enebo>
kares: well very tough to make one since it depends on your bandwidth I suspect
<kares>
;(
<enebo>
kares: for me it happened after like the 12th gem but I think that just happened to be after a particular amount of time
<enebo>
kares: I think this is about a persistent connection?
<enebo>
kares: but 1.9 net/http.rb does not have this logic in it at all
<enebo>
kares: at least not the timeout method
<kares>
enebo: good to know! ... might be I did not notice those stdlib changed in 2.2
<enebo>
git show 30768a67c5c8e991171c59d14a8b397f8be3eba3
<kares>
should I release 0.9.15 to maven than?
<enebo>
so this is supposedly the only change to make us not use session logic?
<headius>
damn
<enebo>
kares: you might as well since we released it as a gem
<enebo>
kares: this is independent of whether we put it in 9.0.5.0 though
<kares>
kares: yep that's the patch I had in mind
<enebo>
fwiw I was able to install gems fine with 0.9.15 and run some other tests like webrick…but I have not tried puma or something which could exercise session on the server side of things
<headius>
enebo: the failures are all just verification of versions and sizes btw
<headius>
nothing that holds up release
<enebo>
headius: sorry I am not following
<headius>
travis failures
<headius>
checking BC version, jar sizes
<enebo>
headius: ah yeah ok
<kares>
yes - I have those somewhere as I tested out 0.9.14
<kares>
new BC grew too much
<headius>
ok
<enebo>
inflated too much :)
<headius>
I need to figure out which size verification to fix
<enebo>
It is a bouncy castle
<kares>
500-700k ... we were a few releases behind :()
<enebo>
headius: kares: so we feel good enough for 0.9.15 now that we know 0.9.11 was only not working from a one-line patch?
<kares>
not sure what kind of viruses are they putting in :)
<enebo>
I am somewhat wondering about how important proper session support is for this modern age :) Will some people be broken if we shiip with 0.9.11?
<kares>
enebo: for me its fine
<kares>
enebo: there were some regressions along the line - let me check release notes
<enebo>
kares: ok. You mean 0.9.11 has had regressions fixed since then?
<enebo>
kares: we do not appear to have used any releease since 0.9.11 in a JRuby release yet
thedarkone2 has joined #jruby
lanceball is now known as lance|afk
<kares>
enebo: right - mkristian did some stuff he really wanted I'm not sure about how important are those to other users (he can obviously upgrade to newer)
<enebo>
kares: ok well that is good to know
<kares>
there are some stdlib compatibility issues fixed since 0.9.11 ... e.g. around exception: false
<enebo>
kares: and you feel it is not so risky
<kares>
recall celluloid-io had issues with those
<enebo>
kares: so known fixes and not so risky…but we did find an unforeseen problem
<kares>
enebo: yep
<enebo>
kares: but now that we addressed that we know of nothing wrong
<GitHub161>
jruby/master 16b13e1 Charles Oliver Nutter: Fixes to Time and BigDecimal for #3616....
benlovell has joined #jruby
djellemah has joined #jruby
subbu has quit [Ping timeout: 260 seconds]
subbu has joined #jruby
shellac has quit [Quit: Ex-Chat]
<headius>
chrisseaton: hey, what were the reasons you wanted to introduce your own parser/interpreter for e.g. pack?
<chrisseaton>
headius: we're compiling the expressions to Truffle nodes so that they're compiled, inlined etc
<headius>
ok, that's what I figured
<chrisseaton>
headius: there seems to be a pattern where it's used mostly as a kind of cast that when you compile and inline it it almost becomes a noop
<chrisseaton>
Fixnum to a byte for example
<headius>
one of these days I might leverage your parser to do the same for us
<chrisseaton>
I'm also planning to write a new Ruby parser and wanted to try Antlr
<chrisseaton>
Yeah the Antlr interface is pretty clean
<chrisseaton>
There's no logic in the parser - there's a listener
<headius>
especially since there's a tiny number of really common pack forms
<chrisseaton>
yeah the parser tidies up the cruft and tells you type, size, endianness etc
<headius>
could generate fast bytecode versions of those three
<headius>
nice
<headius>
what was the other one you did?
<chrisseaton>
printf
<headius>
ok, pack/unpack and printf
<headius>
do glob plz
<chrisseaton>
good idea
<chrisseaton>
the reason we want our own Ruby parser is we need better source information and we want to embed JS
<headius>
marshal is another one that would be worthy of a formal parser but I don't know if text parsers would handle binary well
rsim has quit [Quit: Leaving.]
<headius>
what do people use for fast binary parsing these days eh?
<chrisseaton>
One problem with antlr is it wants char[], so I'm having to just stuff each byte into a char
<chrisseaton>
But hopefully parsing should be a slow-path operation if we're inlining
<chrisseaton>
If you just used Antlr to parse pack etc it may be slower, so I'd plan to combine it with the byte code generation at least
<headius>
ahh char[] pain does suck
bbrowning_away is now known as bbrowning
<headius>
yeah I probably wouldn't use it to parse every time...it would go hand in hand with a "PackInstr" that could cache the bytecoded pack logic
<headius>
or a simple LRU
<chrisseaton>
I also combined it with a crude form of pack 'vectorisation' to turn something like UxUxUx..... repeated a thousand times into (Ux)*
<headius>
ahh nice
<headius>
I wonder if we could just use your AST for anything we come up with
<headius>
I guess that would necessitate pulling in your jar though