<JRubyGithub>
jruby/master 52f332e Benoit Daloze: [Truffle] Implement UnboundMethod#to_s and #inspect.
JRubyGithub has left #jruby [#jruby]
mdb has quit [Quit: mdb]
<mje113__>
headius, Antiarc, thanks for the help yesterday! Issue looks to be resolved in jruby-head
kith has joined #jruby
<mje113__>
Now that I'm back to benching performance diffs between 1.7.18 and 9k, first thing I'm noticing is 2 full GCs in 1.7.18, and 5 for 9k, though they appear to happen early in the benchmark--probably during the setup phase so I don't think that's affecting the actual benchmark.
yfeldblum has joined #jruby
mister_solo has quit [Ping timeout: 276 seconds]
<headius>
mje113__: ok, that may just be due to 9k using more memory at the moment
yfeldblum has quit [Ping timeout: 276 seconds]
<headius>
it uses roughly 2x 1.7for just app/library code
mister_solo has joined #jruby
<mje113__>
ah, ok that makes sense... back to profiling
e_dub has quit [Quit: e_dub]
mitchellhenke has joined #jruby
donV has joined #jruby
mdb has joined #jruby
<nirvdrum__>
headius: Were those heap dumps useful at all?
tcrawley-away is now known as tcrawley
erikhatcher has quit [Quit: erikhatcher]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
enebo: I think I should get jrubyc working again
<headius>
only took two days for someone to notice
<enebo>
headius: so there are two routes there for the persist bit
<enebo>
headius: since you will need persistence working
<enebo>
headius: one is to minimally make it work again
<enebo>
headius: the second is to persist using CFG and not at point of IRBuild list of instrs
<enebo>
headius: the second mechanism is more complex because it involves lifecycle of IRScope
<enebo>
which we might want to change so perhaps just unbreaking the persist we have is enough
Aethenelle has quit [Ping timeout: 244 seconds]
<headius>
4%rTfgvb
<mkristian>
headius, yes, would be cleaner then creating lib/jruby.jar in truffle/ after the truffle artifact is ready
<headius>
a23e@
<headius>
oops, what?
<mkristian>
?
<headius>
kids
<mkristian>
enjoy the surprises then :)
<bbrowning>
headius: this will reproduce the issue w/ activesupport 4.1.8 installed - jruby -e "require 'active_support/time';"
<bbrowning>
it looks like it's trying to undef "==" twice, and the 2nd time blowing up
<enebo>
hmm language level changed? Did we change java lang level in maven recently?
<headius>
enebo: I guess that's worth discussing...do we want to always just persist as IR or should I actually compile what I can to bytecode?
slyphon has joined #jruby
pgokeeffe has quit [Quit: pgokeeffe]
<enebo>
headius: well good question. I thought we decided to do persistence since it would mean 100% of AOT would just work
<headius>
well yeah, it would "work" :-)
tenderlove has joined #jruby
<headius>
I could also just vomit the source into the class file and re-parse it
<enebo>
headius: well it can force a compile at threshold 0
<headius>
somehow it seems like it's less interesting then
cremes has joined #jruby
<enebo>
headius: and still fail back to interp
cajone has quit [Remote host closed the connection]
<headius>
yeah hmmm
pgokeeffe has joined #jruby
<enebo>
headius: persist has big advantages over time
<enebo>
headius: since if you do not JIT until load then any changes we made to opt passes will be applied then and not when you save it
<headius>
I was going to say before that I'd just go ahead with compiling to bytecode what I can...but then I realized we do have an interest in keeping the IR around
<enebo>
headius: downside is obviously slower load but AOT is already a slow load
<headius>
heh, it may be a faster load
<headius>
less bytecode to verify
<enebo>
headius: yeah and the ability to recompile when we have profiled opts
<headius>
I guess it seems a little weird to emit a .class file that doesn't actually contain the bytecode of that script
noop has quit [Ping timeout: 252 seconds]
<headius>
I mean, if jrubyc was emitting .jrb files, sure
<enebo>
headius: well it does have the bytecode but just not the java bytecode :)
<headius>
or precompiling IR to persisted format
<headius>
right
<enebo>
.class file which contains some compiled bits just with a longer pipeline to load but with less java bytecoed verification
<headius>
I'm just thinking...a .class with persisted IR is just a .jrb file with more ceremony
<enebo>
headius: yeah one which another lang can Class.forName
<headius>
it's a .jrb file with a java-executable wrapper
<enebo>
headius: I think also it may end up being less maintenance for us long term as well
<enebo>
I guess that assumes we use persistence for things like a .jrb
iamjarvo has joined #jruby
<enebo>
AOT then is just small shell impl to load retrieve jrb bits and feed to persistence
<headius>
I suspect persistence will evolve pretty quickly to optimize for load time and pre-optimization
<enebo>
headius: It sounds like I am hard-sellnig this idea but I am mostly just rehashing some previous conversations
<headius>
e.g jrubyc should probably run every pass that's useful for interp before persisting so we're already ready to go
<enebo>
headius: and that is in the cards for persist but the way it works now that is not possible
<headius>
it needs plain un-processed instruction sequence, yes?
<enebo>
headius: but once persist does support it then AOT would just do it as well
<enebo>
headius: well to save at a conservative opt state we need more than what we do now
<headius>
e.g. cfg
<enebo>
headius: we would need safe CFG
<enebo>
headius: and Scope flags which cannot be calculated. It is a tiny bit fuzzy since we store so much unnneeded stuff in IRScope now
marr has quit [Ping timeout: 265 seconds]
<headius>
yeah I know
cajone has joined #jruby
<enebo>
headius: I was hoping some the the memory stuff I have been looking at will make this easier
<headius>
I was just thinking how I'd approach persisting it and that was the first question...how much of this is transient?
kl has quit [Ping timeout: 252 seconds]
<enebo>
things like callArgs and kwargs in IRMethod are only for building zsuper
<enebo>
so I want to look at build data and push it into IRBuilder state
kl__ has joined #jruby
<headius>
ahh right
<enebo>
besides being a good thing for division of responsibility/ownership it also reduces the size of IRScopes and makes thinking about persistence simpler
havenwood has joined #jruby
<enebo>
headius: but I think done right we need to persist IRScope with enough full info to run passes
<enebo>
headius: I did not do it that way because I started with GSoC codebase
<headius>
right
<headius>
well perhaps .jrb will be a 9.1 feature :-)
Who has joined #jruby
<enebo>
so yesterday afternoon and this morning I have been looking at IRBuilder and reducing IRScope as a dumping ground
<headius>
heh, @_de reported that thread pooling properties warn now (because I removed thread pooling)
<Who>
hello
<enebo>
Who: howdy. I think I only have one more style comment for you (and thanks for the work btw)
<headius>
enebo: i.e. moving more build-time state out so we're not dragging it around?
<enebo>
headius: well callArgs is only used by buildZSuper but it is a nested set of scopes it examines
dinfuehr_ has joined #jruby
dinfuehr_ has quit [Remote host closed the connection]
<enebo>
headius: by the time we are done it should not exist in IRScope
<enebo>
headius: so I will move to IRBuilder but then I need to make containment field for builders to hold builders
<enebo>
headius: so zsuper can walk builders for it
<Who>
enebo: no problem, I enjoy working on JRuby. Hopefully I can work on challenging/interestings things in the future :D
<enebo>
Who: lining up = on var decls is not something we do
<headius>
enebo: stacks of some kind, sure
<headius>
I have stacks of current method body, etc, in JIT
<Who>
enebo: ah! sure will keep in mind going forward
<enebo>
headius: yeah I agree there are exceptions but subbu for example did that as a general thing and in fact I think we still have it in some ir code
<headius>
Who: I'm trying to think of where you'd want to start
<enebo>
Who: yeah that bug is a little sucky
<enebo>
I think for proc invocation only we can do a max arg calc and if the numbers exceed that we cut the number down to max num
<headius>
IRBuilder I guess?
Who has quit [Quit: Who]
Who has joined #jruby
<headius>
heh oops
<enebo>
The design of our recv instrs assumes we can calc post from walking back from end of passed in IRubyObject[] args
<enebo>
and proc is the sole exception where we can pass in as many as we want and it will still run
<headius>
oh I see
<enebo>
headius: does signature have a max arg count sort of thing
<headius>
yeah pre and post kinda demand walking both ways
<enebo>
headius: is no rest exists
<enebo>
is=if?
<headius>
it does so in arity checking but there's no method for it
<headius>
it's just pre + post + opt
<enebo>
headius: I thought about trying from end of optargs but that is horrific with current design because we bind each opt args as an instr w
<headius>
Who: d and e in that example are "post required args"
<headius>
argument processing in Ruby is complicated
<headius>
enebo: is this just fixes in the instr or are builder changes needed?
<enebo>
if (!rest) pre + post + opt + 1 if kwarg
<enebo>
headius: this is in BlockBody
<enebo>
or a BlockBody
<enebo>
we have to trim internally because we do not only pass proc invocations from IR
<headius>
hmm
<headius>
wait
<headius>
I need to understand how post and opt fit together
<headius>
like if I pass two args to the example in the bug
<enebo>
IR can only solve this if we can calculate where first post index is and we only know that based on args incoming
<headius>
post args get the args
<enebo>
post is index after args but before kwargs I believe
<headius>
so really the processing needs to be in order: pre, post, opt, rest
<enebo>
but kwargs is rip last element off if it needs to
<headius>
oh right, and kwargs would fall under rest processing somewhere
<enebo>
pre, opt, post, rest, kwargs
<enebo>
err sorry
<enebo>
pre, opt, rest, post, kwargs
<headius>
but you need to do post before opt
<headius>
post consumes passed args before opt gets them
<enebo>
but opt just need to know arity to know if it can get them
<headius>
wow, so weird
<headius>
do people use this?
<enebo>
so it can be done at ant point
<headius>
$ jruby -e "proc {|a = 1, b = 2, c, d| p [a, b, c, d]}.call(3, 4, 5)"
<headius>
[3, 2, 4, 5]
<enebo>
yeah I always wonder
<enebo>
but design is really simple right now in that post is just args.length - post_length
<nirvdrum__>
If you slightly tweak your question, the answer is "no" ;-)
<headius>
the first incoming arg offset for post is variable
<enebo>
indeed unless you count from end except for proc :)
<headius>
first opt is a fix offset
<headius>
but first post varies based on however many args there are MORE than required
pchalupa has quit [Quit: Leaving]
<enebo>
I guess another way to solve this is to mark max args in the post instr
<enebo>
then if we receive 100 and post is from 5 we go from 5
<headius>
1 pre, 2 opt, 1 post ... passed 3 args... first post arg starts at args[2]
<headius>
passed 4, first post arg starts at args[3]
<headius>
passed 5 and it's a proc/block, first post arg still starts at args[3]
<enebo>
headius: but it is a function os args being sent to it
<enebo>
yeah I guess this can be done it recv_post knows about opt airty + rest
<headius>
I'm going to write up some pseudocode
<enebo>
headius: we may have it in ArgsNode in 1.7 branch already
<enebo>
headius: we might not have counted from end
<enebo>
So this might not be something for Who to work on then?
<headius>
mkristian: I may try building lib/jruby.jar as an artifact of parent then
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
or of lib?
<mkristian>
headius, enebo switching back to 9.0.0.0-SNAPSHOT is what we want to have, i.e. which corresponds to jruby-head on RVM and maybe rbenv. no ?
<mkristian>
do it in lib/pom.rb
<headius>
mkristian: ahh yes, for rbenv at least
<headius>
rvm always pulls head and builds
nirvdrum__ has quit [Ping timeout: 245 seconds]
<enebo>
mkristian: yeah thanks for bringing that up I was not sure but that seems right
drbobbeaty has quit [Read error: Connection reset by peer]
<headius>
enebo: there's no way to assign post args statically
<headius>
but that applies to rest args too
<headius>
oh wait, maybe not
drbobbeaty has joined #jruby
<enebo>
headius: I am working through one
<headius>
rest args always start at <max args>
<headius>
but post can vary starting offset
<enebo>
headius: I think snice the instr can know how many potntial opt args there are we can do some match to calc start index for the instr
<enebo>
is recv_post gets preCount, postCount, potentialOptCount, isRest we can calc first index
<enebo>
(I am ignoring kwargs)
<headius>
right
<enebo>
so not static per se but simple math in instr impl and not in IR itself
<JRubyGithub>
jruby/master 2990190 Christian Meier: cleanup documentation [skip ci]
JRubyGithub has left #jruby [#jruby]
<enebo>
anyways I posted prematurely only to say I think there is a simple set of cases based on static ints/bools which does not require keeping state in IR
<enebo>
in IR as tempvar data like an index counter
<headius>
yeah I believe you're right
robbyoconnor has joined #jruby
<headius>
it's just not quite in our grasp at this moment :-)
<enebo>
headius: So I agree some change to resceivepostarginstr can make this work for procs
nirvdrum has joined #jruby
<enebo>
Who: if you want to try this you can
<enebo>
Who: it will end up being adding a field and doing some simple math like in the above gist (which is wrong but gives an idea)
erikhatcher has joined #jruby
mister_solo has joined #jruby
iamjarvo has joined #jruby
kl__ has quit [Ping timeout: 276 seconds]
DavidEGrayson has joined #jruby
baroquebobcat has joined #jruby
codefinger has joined #jruby
yfeldblum has joined #jruby
Hobogrammer has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tcrawley is now known as tcrawley-away
rsim has quit [Quit: Leaving.]
yfeldblum has quit [Ping timeout: 252 seconds]
colinsurprenant has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
dhinojosa has quit [Quit: leaving]
dinfuehr has joined #jruby
codefinger has quit [Remote host closed the connection]
<mpapis>
headius, mkristian is there a binary for snapshots? (if yes I thought I probably tried to make it work already) - either way it should be supported - open a ticket for rvm to make it work
johnmuhl has joined #jruby
triple_b has joined #jruby
dinfuehr has quit [Ping timeout: 245 seconds]
codefinger has joined #jruby
<mkristian>
mpapis, the build system builds jruby-dist-9.0.0.0-SNAPSHOT-bin.tar.gz BUT I do not know where and how they put for downloading
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 4 new commits to master: http://git.io/NIY6Jg
<chrisseaton>
headius: so what do we need to do to the launcher scripts and the launcher gem to get -X+T working again?
<chrisseaton>
headius: btw we should also look at moving the Truffle core code into the truffle module
claudiuinberlin has quit [Quit: Leaving.]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 4 new commits to master: http://git.io/9Dv6IQ
<JRubyGithub>
jruby/master 102fd7b Chris Seaton: [Truffle] Start to look at optimised cases for Array#pack
<JRubyGithub>
jruby/master c46ad3e Chris Seaton: [Truffle] Kernel#rand with a long.
<JRubyGithub>
jruby/master e3755c5 Chris Seaton: [Truffle] Truffle::Debug::storage_class for Array.
JRubyGithub has left #jruby [#jruby]
e_dub has quit [Quit: e_dub]
mdb has quit [Quit: mdb]
<mkristian>
chrisseaton, even headius mentioned it somewhere that the spilt off of the truffle module broke the launcher. but the lib/jruby.jar remains the same. or is the reflection code I added ?
<chrisseaton>
mkristian: I think the problem is just the launcher - but I'm not sure how to fix it
<chrisseaton>
mkristian: I guess we need to modify the .sh, .bash, .bat and the native code!
<mkristian>
ok
<mkristian>
headius, chrisseaton would it make sense instead of haveing lib/jruby.jar to have lib/jruby.jar + lib/jruby-truffle.jar and adjust the launcher respectively ? would avoid to merge those two jar and they do already exist and are needed for jruby-jars.gem
Hobogrammer has quit [Ping timeout: 244 seconds]
<chrisseaton>
mkristian: I don't even understand what lib/jruby.jar is - I know about complete and core - but not this one
<mkristian>
chrisseaton, lib/jruby.jar is jruby-core + all its dependencies shaded into one file.
<mkristian>
chrisseaton, and now it needs to add jruby-truffle.jar as well.
<mkristian>
jruby-complete just adds the jruby-stdlib.jar to the shaded jar
<chrisseaton>
and that makes sense because it's JRuby as-a-library that we don't want to put Truffle into
<chrisseaton>
got it
<mkristian>
once this current setup is settled I will add a little wiki page with what artifact depends on which and where it is build, etc
Who has quit [Quit: Who]
noop has joined #jruby
Who has joined #jruby
pietr0 has joined #jruby
Xzyx987X has quit [Read error: Connection reset by peer]
iamjarvo has joined #jruby
Xzyx987X has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
iamjarvo has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] DavidEGrayson closed issue #1328: Encoding of symbol literals does not respect the encoding of the source file http://git.io/Fb-nzA
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] DavidEGrayson reopened issue #1328: Encoding of symbol literals does not respect the encoding of the source file http://git.io/Fb-nzA
JRubyGithub has left #jruby [#jruby]
<DavidEGrayson>
Oops, I clicked the wrong button. I was just trying to make a comment, not close and reopen the issue.
<DavidEGrayson>
My latest comment in https://github.com/jruby/jruby/issues/1328 shows what I think could be a pretty serious regression in JRuby. That script used to run but now it gives an ArrayIndexOutOfBoundsException in the parser.
DavidEGrayson has quit [Read error: Connection reset by peer]
<DavidEGrayson>
headius: You can use the md5sum utility to be totally sure that nothing mangled the bytes; the result should be ea3a3e1bb80abd9095db810874e80650.
diegoviola has joined #jruby
erikhatcher has joined #jruby
<DavidEGrayson>
The script could be simplified a lot. It seems that just a single Micro Sign (\u00B5) encoded in UTF-8 seems to crash the parser.
<DavidEGrayson>
Never mind the last message, I was wrong.
johnmuhl has quit [Quit: Connection closed for inactivity]
dinfuehr has quit [Ping timeout: 264 seconds]
<Antiarc>
I know that someone added UTF-8 support for symbols recently per the 2.2 specs
<Antiarc>
I should see if I can get jruby building on Windows
kares has quit [Ping timeout: 255 seconds]
<DavidEGrayson>
Antiarc: Thanks for reproducing it
<DavidEGrayson>
After posting that gist initially, I realized it wasn't quite right. I had to wrestle with git for a little bit to make sure the exact right bytes are stored in that file and they aren't changed during checkout, but it should be good now.
<DavidEGrayson>
Ah yes, Antiarc verified the md5sum of the file, great.
Felystirra has joined #jruby
deobalds has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
Antiarc: it should build ok
<Antiarc>
It's building, but the executable is being stubborn
<headius>
I'm always surprised how many jruby users are on Windows
<Antiarc>
"Error: Could not find or load main class org.jruby.Main"
<headius>
we'll make a big push for better Windows support in pre2
<headius>
Antiarc: are you in powershell? I had some trouble with it
<Antiarc>
cmder, which I think wraps powershell
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton deleted truffle-u at 8b84e49: http://git.io/5nWSwg
<headius>
DavidEGrayson: what about you, running what shell?
<headius>
could be significant
<Antiarc>
same deal. I'll figure it out, no worries
<Antiarc>
ah, intellij isn't building lib/jruby.jar. heh
<DavidEGrayson>
headius: I was running "Git Bash" which comes with Git.
<DavidEGrayson>
headius: I just tried it in a plain old Command Prompt and got the same exception.
triple_b has quit [Ping timeout: 244 seconds]
<headius>
Antiarc: oh, I always build at command line
<headius>
intellij project is probably not recognizing the odd dependency graph we have now
<Antiarc>
Hehe, yeah, I just don't have maven set up in my path on windows yet
<Antiarc>
I should fix that
<headius>
DavidEGrayson: ok, thanks
triple_b_ has quit [Ping timeout: 244 seconds]
<Antiarc>
great success, building now. Will see what I can find.
<DavidEGrayson>
I think the parser also has an infinite loop in it. If you put an ASCII character like "a" right before the unicode Micro Sign, then JRuby seems to just run without doing anything forever.
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/bix27A
<JRubyGithub>
jruby/truffle-head 52391a5 Chris Seaton: Merge branch 'master' into truffle-head...
JRubyGithub has left #jruby [#jruby]
<headius>
Add that info to the bug please
shellac has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] keltia opened issue #2502: Using Celluloid::IO for async reading from a TLS socket does not work http://git.io/016-5A
JRubyGithub has left #jruby [#jruby]
<DavidEGrayson>
I haven't looked at the code at all, but I have a theory that the parser is doing some backtracking incorrectly. It's as if when it sees the Micro sign, it is backtracking by 2 characters instead of 1 character, and that either results in infinite loops or out-of-bounds errors depending on where the character is in relation to the start of the symbol name.
<Antiarc>
Bizarre. Running this script under intellij produces the proper output.
<headius>
DavidEGrayson: that's a good theory
skade has joined #jruby
<headius>
oh you know what changed in 9k... enebo added support for :"foo#{bar}"
<headius>
so there were definitely changes that would involve some backtracking
<headius>
(obviously other things have changed too)
<enebo>
well it is definitely possible
<enebo>
I think it would require : to precede it
anaeem1_ has joined #jruby
<enebo>
well “dooo”:somembc
<headius>
enebo: the example is p :µ.encoding with UTF-8 magic comment
<Antiarc>
Encoding.default_external is IBM437 under Windows, even when coding: UTF-8 is set. I'll betcha that's one of the fundamental diffs.
<headius>
only appears to fail on Windows run from command line
<headius>
Antiarc: ooops
anaeem1_ has quit [Remote host closed the connection]
<enebo>
I was hoping to port ripper lexer to mainline by now
<enebo>
It compleltely handles mbc but it is a very close port of MRI
<enebo>
ala MRI 2.0 timeframe
<Antiarc>
okay, so under Linux Encoding.default_external is UTF-8
<Antiarc>
And it's IBM437 under Windows
<Antiarc>
Is that the right variable to be checking?
<enebo>
IBM437?!?!!?
<enebo>
WTF IS THAT? :)
<rtyler>
0_0
<enebo>
So that is the DOS encoding which precedes CP1252
nirvdrum has joined #jruby
<Antiarc>
well __ENCODING__ is still UTF-8
<Antiarc>
So I'm not convinced that's the issue yet
<Antiarc>
But it's the only platform difference I've found so far
<enebo>
Antiarc: Is it possilbe you have some DOS compat mode from cmd?
DrShoggoth has joined #jruby
<Antiarc>
enebo: Very possible, the script works properly when run from intellij
<enebo>
Antiarc: in theory encoding of Java should not matter for our strings but we have definitely found lots of bugs where we Strnig.getbytes and it returns file.encoding of JVM and not #coding:utf-8 of source
<mjc_>
huh, mkmf still doesn't work in jruby without a c ext?
<Antiarc>
AFAIK my diff there is the canonical way to check asciionly
<headius>
mjc_: we've talked about this before, right?
<enebo>
Antiarc: interesting fix
<mjc_>
first time I ever tried to use it
<headius>
what's the example of using mkmf for a non-C ext?
<Antiarc>
enebo: -J-Dfile.encoding=UTF-8 works as well
<mjc_>
I only need the find_executable bit from mkmf in this case, is there some other way to do path hunting that doesn't require shelling out to which?
<enebo>
Antiarc: so lengthEnc == length should work since they should be same length is clean 7bit ascii
<Antiarc>
enebo: the problem is that lengthEnc throws a bounds exception
<headius>
mjc_: we could make it back into a warning but our mkmf is really hacked to pieces to support C exts
kwando_ has quit [Ping timeout: 245 seconds]
<headius>
and I really don't understand mkmf at all
<enebo>
Antiarc: ah because it is not a valid string from what enc it thinks it is
<headius>
mjc_: you could open an issue to discuss...we have had other requests to make mkmf still load, even if you can't build C exts
<enebo>
Antiarc: which is perhaps us garbling it on the way in or a bug in jcodings or the encoding we give it does not match the bytes
<Antiarc>
enebo: If you'd like I'll PR that, though I think there may still be a different issue with how files are read under windows
<enebo>
Antiarc: yeah tbh I am unsure still what the issue is. The fact that file.encoding fixes it tells me we have some mismatch in how we are handling the incoming bytes
<headius>
enebo: weird thing is that the failure happens in UTF8Encoder
<headius>
so it *is* deciding to use UTF-8 for the file
<enebo>
headius: because encoding is marked in Ruby side but on Java side the bytes are coming from IBM437
<headius>
maybe it's not using file encoding for all parts of parsing...something falling back on file.encoding
<enebo>
by changing to file.encoding to UTF-8 it gets corrected
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
enebo: that reproduces it on OS X for me too
<headius>
same stackt trace
<enebo>
headius: I am not surprised I guess
robbyoconnor has quit [Ping timeout: 276 seconds]
<enebo>
headius: this has to be that our inputstream source is feeding CP1252 and in original case IBM437 and those are injecting some values which are extension bytes in UTF-8
<enebo>
headius: at least that would be my guess
<enebo>
We are reading files as iso8864_1 or whatever but perhaps not for -e
<enebo>
Antiarc: Does that work if you save it to a file?
<Antiarc>
Save what to a file? The source script is a file already
<enebo>
oh yeah…hmm
<enebo>
Well I sort of feel like your fix may be canonical way to detect but our way should not be crashing
<Antiarc>
Right, that's my sense too
<enebo>
It can only be crashing if jcodings has a bug or we are getting a weird set of bytes
<nirvdrum>
Being in one of the European timezones sucks if working on/with JRuby. Dunno how others live with this.
<enebo>
file.encoding tells me we are doing something wrong in how we load source
<enebo>
since if we set that then everything is happy
deobalds has joined #jruby
<enebo>
fwiw regardless of this bug we should probably have launcher set file.encodnig=UTF-8
<enebo>
I think we would get way less bug reports :)