<headius>
olle: historical lines that used to do something but were later not needed...but that whole thing is hacks upon hacks to make Java processes work right
<headius>
I actually pivoted after that commit to try to just get native processes working on Windows
<headius>
the equivalent code from MRI isn't too bad...just need to get a good binding for CreateProcess + structs on Windows
<headius>
if we get native processes working we might be able to flip the bit on native IO in general, which will greatly improve compat
<olle>
headius: Color me interested! Thanks for the precise update.
<headius>
I should push the partial port I have but it doesn't compile
<headius>
have to switch to presentation mode for a few days
<lopex>
headius: also managed to remove like 15 cases from that big switch
<headius>
oh that's great
<lopex>
wonder if it still matters
<headius>
I know of no work to improve switches, though something was planned
<lopex>
havent got a time to do any benchmarks though
<lopex>
but there's lots of code reduction and hiosting
<headius>
if I remember right they didn't profile switches and so didn't hoist the frequent branches up
<lopex>
they could be a subject of the same opts as pics right ?
<headius>
yeah certainly
<headius>
kares: that sounds like a good idea
<headius>
I like that we were able to do so much in Ruby but we're still competing with hand-written C
<enebo>
kares: yeah we should but I guess your merge broke a bunch of tests for at least postgresql in Rails tests
<lopex>
headius: I've seen mri commits that remove a lot of funcalls from complex/rational
<lopex>
or was it a pl
<headius>
lopex: not surprising...we have blunted much of that cost by introducing call site caching for calls from Java
<enebo>
kares: I am still working on bytelist work for 9.2 but I would like to somehow get our CI for arjdbc working with minitests-excludes. I tried a couple of days to include the proper magic and failed
<headius>
if I ever had time I'd write my magic indyfier that rewrites all those calls into invokedynamic
<headius>
should just be a one-pass ASM rewriter
<enebo>
kares: so perhaps that should happen first is we get travis green with both local and AR tests
<enebo>
kares: but someone did ask about a 51.x release for postgresql as well
olle has quit [Quit: olle]
tomlukeywood has joined #jruby
<headius>
grr lambdaform error
<headius>
lopex: looks much better
<headius>
one failure that looks related and another that might not be
<lopex>
headius: yes, noticed that one failier
<lopex>
*failure
<headius>
I'm going to look at the ungetc one in case it's an unreliable test
<headius>
same two on the jit run
<headius>
ok that's weird...I don't know why that would start failing
<headius>
RangeError: 4294967295 out of char range
<headius>
ungetc at org/jruby/ext/stringio/StringIO.java:1077
<headius>
you may be right there's some match failing
<enebo>
Did travis start showing provisioning cmds at start of jobs recently?
<enebo>
It is weird to see riak/mongo/14 other things start up in our jobs in the logs
<headius>
not recently but there's been a lot more noise over the past several months
<headius>
maybe they decided it's better to show the provisioning so people can tell what goes on
<enebo>
oh actually I bet this does always happen but it collapses it and I never look while it is running
<enebo>
and for raw logs I immediately jump to bottom
tomlukeywood has left #jruby [#jruby]
<enebo>
It spends quite a while just getting the image up to the point where our stuff starts
<headius>
yeah it collapses
<nirvdrum>
enebo, lopex: I finally was able to add in checking the encoding to Rope#equals (very similar to ByteList#equals), which cleaned up some other code. I don't know if that's of interest or not, but the PR was https://github.com/graalvm/truffleruby/pull/944/files.
<nirvdrum>
This was like 2.5 years in the making.
<headius>
nirvdrum: nice
<headius>
I don't get why it would help remove a lot of code though
<headius>
well, maybe not a lot of code
<nirvdrum>
Not a ton. It was just weird having two notions of equality and constantly having to think about which to use.
<headius>
enebo: have you run into any issues because ByteList.equals still doesn't consider encoding?
<enebo>
nirvdrum: thanks for sharing
<nirvdrum>
For us in particular, it complicated the SymbolTable.
<headius>
I still think we need to do that
aemadrid has quit [*.net *.split]
subbu has quit [*.net *.split]
kares has quit [*.net *.split]
adam12 is now known as adam
subbu has joined #jruby
<enebo>
nirvdrum: I just saw two FIXMEs yesterday reminding me to calc CR inline on lexer string construction
<nirvdrum>
If you look at the diff there, I had to implement an artificial key class so the encoding could be taken into account for key lookups.
<enebo>
nirvdrum: you do that now right?
<headius>
we don't use ByteList as a key hardly at all except on your branch
adam is now known as Guest26989
<headius>
nirvdrum: ahh I see
aemadrid has joined #jruby
kares has joined #jruby
<headius>
yeah we aren't using ByteList as a key anywhere yet
<enebo>
headius: yeah and now I am considering full flip to bytelist for tables since I don't like working around weird error reporting
<lopex>
nirvdrum: I guess similar thing is for caching regexps right ?
lroca has joined #jruby
<nirvdrum>
headius: It came up in other places where we used it as a cache key for Truffle's PIC.
<enebo>
searchMethod on raw string bytes works fine for all encodings but the error can look wrong. I have been avoiding this but I think it just needs to be bytelist
<nirvdrum>
enebo: We eagerly calculate CR upon rope construction. So we have it at all times in the lexer.
<enebo>
I had all thuis changed on symbol_love but of course it was symbols
<nirvdrum>
I need to revisit that, because it's not cheap.
<enebo>
symbols is so much nicer for that
<nirvdrum>
Well, the problem is the lexer takes substrings all over the place.
<nirvdrum>
lopex: I'd have to look again. We still do what JRuby does, but less efficiently. Our regexp code is really bad.
<nirvdrum>
Well, Duncan fixed up a fair bit of it. So maybe that's no longer accurate.
<enebo>
nirvdrum: but since strings are made sequentially we can just have some state as we go and it only toggles that state as something changes
<lopex>
nirvdrum: that cache is mostly for throw away regexps which mri does a lot (still ?)
<enebo>
nirvdrum: it is not quite that simple but I think in most cases we should not have to rescan any strings
<lopex>
nirvdrum: btw, in case you were interested in casemapping, unicode casemapping is in jcodings now
<enebo>
nirvdrum: so cost of eager may not really be a cost if it is accounted for during initial byte walking
<headius>
nirvdrum: actually that's a fallback case; there's another piece of logic that tries to just do a string comparison directly and fail over if nothing matches
<headius>
that got broken by some Ripper fixes
<headius>
it mimicks the MRI way but I don't know if both are necessary
<nirvdrum>
Ahh, right. The j.l.String comparisons.
<nirvdrum>
All of this is way too complex and too costly for a situation that just never really arises.
<headius>
no argument there
<GitHub129>
[jruby] ivoanjo opened issue #4970: String from literal sometimes not reused with frozen_string_literal enabled https://git.io/vNGxr
lroca has quit [Quit: lroca]
<nirvdrum>
We feel the parsing pain a bit more since we implement a bunch in Ruby. And each of those source files has a 30+ line license comment at the top.
<nirvdrum>
And the license has a ':' in it, which is is enough to start searching for magic comments.
claudiuinberlin has joined #jruby
rrutkowski has joined #jruby
rrutkowski has quit [Client Quit]
rrutkowski has joined #jruby
rrutkowski has quit [Client Quit]
rrutkowski has joined #jruby
rrutkowski has quit [Client Quit]
rrutkowski has joined #jruby
<headius>
nirvdrum: ugh, fun
<headius>
enebo, kares, whoever: I need a review
<enebo>
headius: I looked at that popen3 thing and as far as I can tell it looks ok to me but kares should weigh in too.
<enebo>
headius: I do have one comment which is commented out code
<headius>
not that one
<headius>
that's a WIP and all I did was move some stuff around
<enebo>
oh well that was my review of that :)
<headius>
commented out code just came along for the ride
<headius>
I also realized we're not vacating dead references other than this new code, so that's probably something we should address
<headius>
it's not a huge thing to fix...if we find a dead reference run a cleaner that does computeIfPresent and nukes empty entries
<enebo>
yeah I suppose random string generation in an eval is uncommon
<headius>
right
rrutkowski_ has joined #jruby
rrutkowski has quit [Ping timeout: 265 seconds]
<enebo>
headius: my only question on this is the encoding bit
<enebo>
headius: this is because we find the same string but with different encodings so it will not transmute into something else like have wrong encoding or replace original
<headius>
yeah I'm not sure if it can happen because I thought String hash calculation considered encoding
<headius>
but the point is that if it does happen don't wipe out the other frozen string since it would then be inconsistent for sites that already cached it
<enebo>
headius: yeah if two instances cannot be Map equivalent that should not happen
<headius>
thats not new but yeah I'm unsure if it happens
<enebo>
headius: ok well maybe FIXME that else as part of the work to allow someone to figure that out
<headius>
sure
<enebo>
I feel like I was able to trace through that logic ok and did not see a problem
<headius>
ok
<headius>
I'll push it and have ivoanjo test it out on his env
<enebo>
I have not use the compute methods or if I did it was a couple of years ago when I closureized some small game
<enebo>
I am still not comfortable with closure syntax yet but mostly because I have not used it more than to play with it (as in that game largely)
<headius>
yeah I've been using it more and more
<headius>
I need to revert this to anon classes for 9.1 though
<enebo>
to bad there is no compareAndSet in maps so this is not evenr needed
<headius>
it's absolutely beautiful for things you want to do lazily, since if the lambda isn't called there's nearly zero cost
<headius>
yeah that's what I wanted
<headius>
computeIfPresent is pretty close since it's atomic
<headius>
you get what's there and can do your calculation if you intend to replace it
<enebo>
Seems complicated enough if some kind soul added it we would get a lot less production concurrency errors in Java land :)
<headius>
right
<headius>
it would also be nice to have a proper concurrent weak hash