isavin has quit [Remote host closed the connection]
Crocket has joined #jruby
<headius>
isavin: this is unfortunately true...the S3 bucket we kept them in was wiped out mistakenly by the company hosting us and we have only restored builds going back a certain amount of time
<headius>
do you need the full tarball or could you make do with just the "complete" jar file?
<headius>
enebo: ^^
<headius>
since JRuby 1.7.6 (I think) we started pushing the tarball to Maven Central so newer releases are all available that way
<headius>
prior to that the tarballs only existed on our bucket, which was not properly set up and then got nuked
<headius>
in other news...good morning all!
<enebo>
I do have 1.6.8 on the nas
<enebo>
so I will restore that one
<headius>
👍
<headius>
don't want to just restore everything you have on the NAS?
<headius>
at least we have a guarantee now they won't wipe it out
<enebo>
headius: yeah probably should now...having it wiped out a second time made me not want to go through it all again
rtyler has quit [Remote host closed the connection]
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
<headius>
enebo: I don't blame ya
<headius>
grrr
<headius>
I can't get this interrupt test to fail locally and don't see why it would fail on travis
Puffball has joined #jruby
<subbu>
1.6.8 seems like ... what ... a decade old?
<headius>
prehistoric
<headius>
wow, 2012
<headius>
it's over 6 years
subbu is now known as subbu|lunch
kares has quit [*.net *.split]
kares has joined #jruby
subbu|lunch is now known as subbu
Puffball_ has joined #jruby
Puffball has quit [Ping timeout: 272 seconds]
Puffball has joined #jruby
Puffball_ has quit [Ping timeout: 272 seconds]
<headius>
ok, master is green again with some timeout tweaks
<headius>
if anything goes red spuriously we'll deal with it immediately...these flaky results need to end
<xardion>
Man, I feel your pain.
<xardion>
I've been trying to run the same test quite for a couple hours now.
<xardion>
suite*
<xardion>
Our chef repo is set up to run manadatory Travis CI builds of the chef spec
<xardion>
and one of the specs keeps failing because yum repository mirrors are being flaky today
<xardion>
I got it to pass once, but somebody had merged while my specs were running so I had to re-run them *rage*
<xardion>
To be fair, this repository is too goddamn big and needs to be broken up, but nobody wants to put in the time to deal with the cross-cookbook dependency headache that breaking up this repo would require.
<headius>
xardion: yeah I just had one job completely fail to start on travis and I regularly see our maven builds stall for no obvious reason
<headius>
I mean, you get what you pay for, but these failures are confusing and infuriating
<headius>
I've been trying to break up our longer suites also
<ChrisBr>
headius: ever thought switching to CircleCi?
<ChrisBr>
we recently did and I don't look back ... altough everything needs to run in a container there!
<headius>
is there a free option?
<headius>
we are not exactly a rich project
<ChrisBr>
yup
<headius>
well that's definitely worth investigating then
<ChrisBr>
there is a free option and if you're an open source project you get some more containers even
<headius>
travis has served us well but these spurious unexplanable failures are really frustrating
<ChrisBr>
yup
<ChrisBr>
and Circle has live debugging
<ChrisBr>
so you can login via SSH to the contaienr
<ChrisBr>
I didn't use it very often but is a nice option if you dont cant reproduce it locally
<ChrisBr>
and they have uploading assets included (e.g. logs, screenshots ...)
<ChrisBr>
so you're running Travis on the free plan then?
<ChrisBr>
btw: I think e.g. rails runs Travis & Circle in parallel
<headius>
yeah we are just free plan
<headius>
Travis guys might have bumped up our job count but I dunno
<headius>
they did run a bunch of stuff on JRuby for a long time
<ChrisBr>
headius: I would think so, IIRC with the basic plan you can only run two jobs in parallel
<headius>
ah sure
<headius>
I think we have 5
<ChrisBr>
yeah, otherwise that would take forever ...
<ChrisBr>
"We offer a total of four free linux containers ($2400 annual value) for open-source projects. Simply keeping your project public will enable this for you!" https://circleci.com/pricing/
<ChrisBr>
but the pricing model is quite untransparent to be honest ...
<headius>
lopex: we could have a different ByteCodeMachine for regionless matching that's a little smaller, right?
<headius>
I'm not sure alloc is what's keeping us from matching MRI but making a smaller object would help if so
<headius>
"This application will be able to read and write all public and private repository data." 😬
<headius>
I mean I get that it needs access but I'd love to see this a bit finer-grained :-)
<lopex>
headius: you mean the "match?"
<headius>
yeah I was looking at it in passing
<lopex>
headius: there's one more alloc for repeat stack
<headius>
I suspect maybe this is back to big switches optimizing poorly
<headius>
but if it's alloc we can make some stuff smaller
<lopex>
headius: but then you'd have to account for (.)\1 and the like
<lopex>
headius: whole "region" range update is tiny little thing there
<lopex>
headius: do you profile it ?
<lopex>
*did
<headius>
I did an alloc profile
<headius>
it's nothing we don't know...all ByteCodeMachine and int[]
<lopex>
so the int come from that repeat stack alloc
<enebo>
lopex: I am partially surprised if this a if/else with that check vs something calling two methods which don't have this check (e.g. make a smaller method)
<lopex>
it forwards faster
<headius>
I have no idea what this test is supposed to do
<headius>
hmm
<lopex>
what test ?
<lopex>
ah
<headius>
autoload thing, pay no attention
<headius>
multitasking
<enebo>
doh
<lopex>
enebo: there's regexp.map and intMap
<enebo>
lopex: map and intMap is the same type right?
<lopex>
enebo: but those are tight inner loops
<lopex>
both should be int[]
<enebo>
this could be a single set of whiles if you save proper int[] to a local variable
<lopex>
enebo: no, map is byte[]
<lopex>
enebo: yeah this is very old code, I havent paid attention for a long time
<enebo>
lopex: I don't know if size matters but I was thinking about notion of two search methods where you call one depending on which one you work with
<lopex>
aaah
<enebo>
I guess this method calls no methods and even with half the whiles it maybe would not inline
<lopex>
enebo: oni has a new variation called sunday search
<headius>
screw it, I'm going to quarantine this test and open an issue
<enebo>
when we call match? which path are we going done?
<enebo>
down
<lopex>
depends on the regexp
<enebo>
lopex: ok but what feature triggers intMap vs map
<enebo>
this method is pretty damn irreducible other than the if/else making the method larger
<lopex>
enebo: fixed parts in the regexp
<lopex>
like /foo..bar/
<lopex>
foo will trugger that since thet fast skip want for find the interesting part using that
<enebo>
lopex: so it is like switch(first) case 'm': match_exact 'mon' ...
<lopex>
yes
<enebo>
lopex: but it starts on the 'o' in match_exact right?
<enebo>
since it knows from first instr that m matched?
<lopex>
what 'o' ?
<enebo>
'mon' 'm' was determined by the skip map
<enebo>
so the second character of mon
<lopex>
enebo: hmm, the order might not matter
<lopex>
since it's and alteration
<lopex>
*anm
<lopex>
enebo: oh, it's sorted
<enebo>
lopex: but regardless of order if it determines first character in skip map then second char in where it jumps next should be next thing looked at
<enebo>
lopex: I guess I am saying after skip map determines it might be 'mon' because it saw 'm' does it actually look at 'm' again in exact?
<lopex>
yes
<lopex>
ah
<lopex>
yeah
<lopex>
enebo: it always reassure in the interpreter if that what you mean
<lopex>
*reassures
<enebo>
lopex: well I am just wondering if one less compare would make a difference
<enebo>
seems like exact3:on would be better bytecode if you know m will match from skip map
<lopex>
enebo: but it need to build a backtrack first
<lopex>
cant have it both ways
<lopex>
enebo: that's why you have push first
<enebo>
lopex: well I clearly don't understand this
<enebo>
lopex: and unfortunately I need to go now :P
<lopex>
enebo: or we're missunderstanding each other
<enebo>
lopex: but I should maybe hang with you and try and learn basics of oni/joni bytecode one of these days
<enebo>
I think if I did I would not ask so many long questions
<enebo>
lopex: but I will talk to you later buddy
<lopex>
enebo: yeah, I'm off the steam now too
<lopex>
and also forgot lots of that parts of code
rtyler has joined #jruby
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]