xardion has quit [Remote host closed the connection]
xardion has joined #jruby
lopex has quit [Ping timeout: 240 seconds]
lopex has joined #jruby
Liothen has quit [Ping timeout: 272 seconds]
Liothen has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
shellac has quit [Client Quit]
shellac has joined #jruby
shellac has quit [Client Quit]
<headius[m]>
yo
<headius[m]>
enebo: what's on your plate today
subbu is now known as subbu|lunch
<enebo[m]>
still gettign rid of SourcePosition
<enebo[m]>
It is a big task
<enebo[m]>
headius: what are you working on?
<headius[m]>
I'm looking into these two bugs reports about building jnr stuff on ppc64le quick
<enebo[m]>
right on
<enebo[m]>
I am evaluating position stuff a lot as part of changing this so I might magically fix out tracing stuff at the same time
<headius[m]>
that would be pretty slick
<enebo[m]>
MRI does this stuff weirdly in places like it will make a $$ = NODE(..., @$) which will set it to loc of the lhs terminal/production but then do a fixpos($$, $2)
<headius[m]>
I don't think that will include fixing methods and branches coverage but perhaps 😀
<enebo[m]>
So it starts with leftmost items line but then use the expr's line and replace that (but only if the expr is not something null like ()
<enebo[m]>
well this will likely just make the line numbers match more than it did in a few places
<enebo[m]>
my main motivation in auditing this is we do a lot of somewhat mixed use of $1.getPosition where we know $1 exiects but then lexer.getPosition($1) and support.getPosition($1)
<enebo[m]>
in most cases these will be the same but not always
<enebo[m]>
anyways my example above I noticed for 'case' and it definitely will do the hash-like line thing if the expr is on another line
<enebo[m]>
I also have another blue sky task...see if I can finally make bison generate a grammar for us
<enebo[m]>
bison can generate java. I tried once before and I did not get hung up so much as just marvelled at how much work it was
<headius[m]>
that would be nice, one less tool to worry about
<enebo[m]>
plus I am a bit concerned it will be slower than jay but if it did work they @$/@n sorts of stuff would just work and our keywords would not need to be boxed ints
<headius[m]>
do you see why hash would have an off line but array would not yet?
<enebo[m]>
here let me check
<enebo[m]>
weirdly I see no reason why it would not be { and not the first expr
<enebo[m]>
It seemingly sets it to that
<enebo[m]>
maybe iseq is messing with it
<headius[m]>
I can come up with reasons for either but no reason for array and hash to differ
<enebo[m]>
ok so the Node itself is set to the line of { but that is not the same as being marked as a newline
<enebo[m]>
atm I am more concerned with the node positions being correct but obviously what is marked as newline should match as well
<headius[m]>
yeah like you say hopefully some of that will fall out of this work
<enebo[m]>
nothing in cmopile seems to change line for hash either
<enebo[m]>
yeah it is something I am increasingly more curious how it happens
<enebo[m]>
I find it weird already but now that I am seeing pos being what I expect on hash node it is doubly weird
<enebo[m]>
it has to be that newline is not marked on hash but first pair of a hash
<enebo[m]>
yay looks like lex_state will help determine newline property
<enebo[m]>
I am pretty sure those are right or other things go wrong
<headius[m]>
hmmm where to get a ppc64le server
<headius[m]>
maybe there's something in ibm cloud
<enebo[m]>
heh we do not remove begin nodes during newline marking...seems very unlikely to be the problem
<enebo[m]>
ok enough of this...marching forward with what I am doing
<headius[m]>
it will all come out in the wash
shellac has joined #jruby
<headius[m]>
enebo: omg they reverted reverse backtraces
<enebo[m]>
heh
<headius[m]>
apparently the new option is --suppress-backtraces={length} to only show the top length frames
<enebo[m]>
I am surprised it is not just an option
<headius[m]>
the issue mentioned is above but all it says is we have to reopen to support supressed-backtraces
<headius[m]>
aha, from matz in that issue: "OK, let's revert it. Instead, I want to something to suppress backtrace lines (e.g. --suppress-backtrace=5 command-line option to ruby or something similar in RUBYOPT environment variable)."
<headius[m]>
there are a series of folks saying how much they hate reversed traces before that
<enebo[m]>
I am also meh on that but hey
<headius[m]>
so yay, the conservative approach worked out for us
<enebo[m]>
won't help debugging specs
<headius[m]>
yeah I don't like that feature either but at least traces go back to normal
<enebo[m]>
unless your suppress is like 30 lines long
<enebo[m]>
I really feel like this could just be | tail -20
<headius[m]>
it might make exception stack traces way cheaped for us 😛
<headius[m]>
but tail won't work because the trace isn't reversed
<enebo[m]>
yeah that is true if anyone actually uses it
<enebo[m]>
I mean you have to have a reasonable idea you can track your localized error in n stacks
<enebo[m]>
perhaps that is common?
<headius[m]>
well I think the justification is filtering to only the last like 50 or 100 frames when you have 1000 in rails
<enebo[m]>
Irony is all internal exceptions get faster :)
<headius[m]>
not filtering to the last two or three
<enebo[m]>
yeah and I get that but it is tough to know when significance ends but I suppose most people working on a particular app can dial that down
<enebo[m]>
I work on enough different Ruby stuff that I doubt I would ever set this but that is maybe really uncommon
subbu|lunch is now known as subbu
<headius[m]>
ugh dependency convergence
<headius[m]>
I forgot every time we update jcodings we need to update joni
<headius[m]>
enebo: maybe we can do this so it only runs against non-snapshot builds? Would that catch it before release?
<enebo[m]>
mvn tree dep thing can show it so we could possibly make a Ruby script which looks at that
<headius[m]>
I need to release joni now for the jcodings update to get that run passing again
<enebo[m]>
yeah we could also just make a wiki page showing what we need to update when we update
<enebo[m]>
which would be very low tech but we would be more mindful perhaps
<headius[m]>
I know if we don't have something automated it will happen again
<headius[m]>
but having something automated is super annoying
<enebo[m]>
mvn dep tree command could be a smoketester on travis/actions which just runs that maven command and ruby makes sure it is all the same
<enebo[m]>
that would not automate the release part but we would not release out of sync
<headius[m]>
is this a step you want to add to release process?
<enebo[m]>
well it would not be a step at all
<enebo[m]>
it would fail CI when not up to date
<headius[m]>
woot, I have free access to a power8 cloud
<enebo[m]>
MINECRAFT SERVER
<headius[m]>
haha
<headius[m]>
for science
<headius[m]>
huh they have just about every release of commercial linux available
<headius[m]>
neat, I have a fedora 29 ppc64le system with 3 VCPUs and 3GB memory starting up now
shellac has quit [Quit: Computer has gone to sleep.]
<headius[m]>
so I fixed this one case but it seems there may be others
<headius[m]>
jnr-ffi has a "fast numeric" mode for generating method stubs on x86 that's not used elsewhere... it's the non-fast logic that had differing boolean conversion, which I fixed in that commit
<headius[m]>
however if I add a test run with fast numerics off completely I get a bunch of other failures
<headius[m]>
enebo: FYI on a clean checkout `mvn clean package` does install the rake binscript
<headius[m]>
I think this will just be a transition period while everyone catches up to the commit that deleted bin/rake
<enebo[m]>
oh yeah and I never run package generally but I suppose I should remember that
nirvdrum has quit [Ping timeout: 265 seconds]
<headius[m]>
well package is default
<headius[m]>
so you run it all the time unless you run something else
<enebo[m]>
mvn with no args
<headius[m]>
yeah, we have it set to do package by default
<headius[m]>
otherwise mvn has no default and yells at you
<enebo[m]>
I just make new branch and rake had disappeared again
<enebo[m]>
so perhaps my issue was I did not compile it once before I started making changesw
<enebo[m]>
but then when it did compile I had to install rake to get the binstub
<enebo[m]>
so something interesting is happening in the dev env since I had a rake binstub
Antiarc_ has quit [Ping timeout: 256 seconds]
Antiarc has joined #jruby
<headius[m]>
enebo: hmmm
<headius[m]>
so you switched branch and it deleted your rake binscript?
<headius[m]>
the problem going across branches is some have bin/rake and some don't, so some will delete it; and if they delete it but the gem file is in the cache it won't reinstall
<headius[m]>
we could remove that logic but it would install every time you package then
<headius[m]>
once all branches don't have bin/rake (and ignore it) it should stay in place