anaeem1 has quit [Remote host closed the connection]
Integral1st has quit [Ping timeout: 252 seconds]
diegoviola has joined #jruby
Who has quit [Quit: Who]
Who has joined #jruby
Who has quit [Client Quit]
17WAAWJ1I has joined #jruby
robbyoconnor has quit [Ping timeout: 264 seconds]
shellac has joined #jruby
kares has joined #jruby
yfeldblum has joined #jruby
lance|afk is now known as lanceball
<nirvdrum>
It's that same time spec.
<lopex>
nirvdrum: hiya
yfeldblum has quit [Ping timeout: 252 seconds]
<nirvdrum>
lopex: Hey. I was wondering why RubyString#subpatSet19 uses RubyString#replaceInternal rather than RubyString#replaceInternal19.
<lopex>
nirvdrum: I'd have to check
<nirvdrum>
lopex: No rush, but if you could, that'd be helpful.
<lopex>
nirvdrum: I thought non 19 stuff is already gone
<nirvdrum>
lopex: Thus my confusion :-)
<lopex>
nirvdrum: feel my pain when tr19 against tr was done
<lopex>
nirvdrum: at least ruby doesnt suffer like python does wrt python3 adoption
<nirvdrum>
I wish it had, initially.
<nirvdrum>
1.9.2 wasn't all that great.
<bbrowning>
is there any jruby project that uses fibers heavily?
<nirvdrum>
I appreciate the Python community standing up and saying "this is working an stable, don't needlessly break things."
<nirvdrum>
bbrowning: Sidekiq/Celluloid.
<bbrowning>
hrm
viking has joined #jruby
viking has quit [Changing host]
viking has joined #jruby
paulswil_ has joined #jruby
<kares>
bbrowning: on top of that Adhearsion
<kares>
performing terribly at time as far as I've seen so far ;(
<bbrowning>
I'm still seeing whackiness with Rails 4's usage of fibers on JRuby when the Rails app uses "render :stream => true". On JRuby 1.7 and a special branch headius made with JRuby master's fiber impl backported to 1.7
<bbrowning>
Guess I need to dig into it more, but seems like there's either a bug in Rails assumptions about fiber usage or in JRuby's impl resulting in intermittent race conditions and failure of web requests
<kares>
bbrowning: I was checking that out while you were talking about it last week ... have not seen anything similar with Celluloid
<bbrowning>
I'm still trying to get to the bottom of what's going on so I can make something easy to reproduce. It's a bit of a PITA because I can only reproduce it on a virtual machine running Ubuntu 12, so far :/
<bbrowning>
Ubuntu 12 being what Travis also runs, since our Travis builds also hit the issue
<kares>
feel your pain ... I'm not sure what to do to reproduce a heavy Celluloid usage "warmup" issue ;(
iamjarvo has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
mrmargolis has joined #jruby
enebo has joined #jruby
iamjarvo has joined #jruby
iamjarvo has quit [Client Quit]
e_dub has quit [Quit: e_dub]
paulswil_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Who has joined #jruby
<nirvdrum>
lopex: Anyway, I'm looking to move replace19 to StringSupport. I can keep replace easily enough. But I'm wondering if we really need both.
anaeem1 has joined #jruby
mitchellhenke has joined #jruby
<bbrowning>
hmm in rails there's code like "fiber.resume while fiber.alive?"
<bbrowning>
I wonder if alive? is returning true but then the fiber dies before fiber.resume is called
<bbrowning>
ie that line of code isn't atomic
<bbrowning>
guess I need to read up on how fibers actually work
subbu has joined #jruby
viking has quit [Remote host closed the connection]
viking has joined #jruby
viking has joined #jruby
kl__ has quit [Ping timeout: 240 seconds]
kl__ has joined #jruby
rcvalle has joined #jruby
e_dub has joined #jruby
cremes has quit [Ping timeout: 264 seconds]
elia has quit [Read error: Connection reset by peer]
elia has joined #jruby
kl__ has quit [Ping timeout: 252 seconds]
skade has quit [Quit: Computer has gone to sleep.]
kl__ has joined #jruby
skade has joined #jruby
pchalupa has quit [Quit: Computer has gone to sleep.]
iamjarvo has joined #jruby
noop has quit [Ping timeout: 255 seconds]
e_dub has quit [Quit: e_dub]
e_dub has joined #jruby
cremes has joined #jruby
<dfr|work>
morning folks
camlow325 has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 244 seconds]
bbrowning is now known as bbrowning_away
DrShoggoth has joined #jruby
mister_solo has quit [Ping timeout: 244 seconds]
<Who>
hey, how can I printout something in IRB in native JRuby code?
subbu is now known as subbu|breakfast
<nirvdrum>
lopex: I think I'm going to break out a CodeRangeSupport class to get some of this stuff out of StringSupport. Does that sound reasonable?
<lopex>
nirvdrum: subpat_set in mri uses rb_str_splice_0 which is exactly what replaceInternal does
<lopex>
nirvdrum: so to have it compatible it should stay the same
<nirvdrum>
lopex: Okay. I just thought the bare named ones were 1.8 stuff.
anaeem1 has quit [Remote host closed the connection]
<lopex>
nirvdrum: it's one of those cases it got reused from 18
<lopex>
headius: can't recall any other reason than that it would make bytelist heavier
<lopex>
headius: but it would be more covenient given lots of logic might be made bytelist-wise
<nirvdrum>
I'm hoping when I'm done making a mess we can figure out what might make better sense within jcodings.
<headius>
well this is a damn hard thing to sort out...none of the time calculation tools online allow year 0
Specialist has quit [Ping timeout: 265 seconds]
<lopex>
nirvdrum: I'll jump at some point in feb or march
<lopex>
nirvdrum: I see some of stuff is updated in mri
<nirvdrum>
Sounds good. At least by having two implementations, we have a better idea of usage patterns now.
<lopex>
nirvdrum: two ?
<nirvdrum>
Truffle has its own.
skade has quit [Quit: Computer has gone to sleep.]
<nirvdrum>
I'm working to unify them basically.
<lopex>
yeaj, I gather
<nirvdrum>
IMHO, both RubyString implementations should be little more than a ByteList wrapper with the Ruby endpoints.
<nirvdrum>
org.jruby.RubyString is pretty complicated at the moment.
<lopex>
yep
<lopex>
I rewrote it two times
<nirvdrum>
Don't get me wrong. I'm not passing judgment or anything.
<nirvdrum>
We just have an opportunity to maybe clean some stuff up.
<lopex>
I know
<nirvdrum>
Particularly with 9k.
<lopex>
I was aware of the issues you're raising
<headius>
my dream was always to have all encoding and CR-aware code live inside ByteList itself
<lopex>
but it was just a String at that time that was hot at dev
<lopex>
headius: ideally
<headius>
so that ByteList was both a byte[] manager and aware of characters
<headius>
then the jcodings/bytelist/joni library trio would be complete
<nirvdrum>
It's already aware of the Encoding, so that doesn't seem like a far stretch.
olleolleolle has joined #jruby
<headius>
lopex: we could do everything CR does with a character length field, right?
<nirvdrum>
I think an Encoding aware ByteList could maybe take over the responsibility of byte replacement, indexing, length calculations, and so on.
<lopex>
but I'm still happy joni doesnt depend on bytelist
<headius>
I mean, MRI used CR because they didn't have any room in the String header for char length, I believe
<lopex>
headius: why char ?
<headius>
nirvdrum: for sure
<headius>
lopex: because we already have byte length
<lopex>
headius: ah, both would be aligned
<lopex>
er, packed
<headius>
if char length == byte length that's basically isAscii
<olleolleolle>
Hi all, and @headius, I'm investigating the 20 hours old issue with openssl complaining when using bundler install.
<headius>
well, pretty much
<lopex>
headius: I wonder how would jvm pack those fields
<headius>
lopex: well it would either add 64 bits or 32 bits
<lopex>
headius: unless it's broken :)
<olleolleolle>
(The output would be "Gem::LoadError: can't activate jruby-openssl-0.9.5-java, already activated jruby-openssl-0.9.6-java)" Issue was https://github.com/jruby/jruby/issues/2444
<headius>
right now bytelist has three ints and three references
<headius>
lopex: indeed
<lopex>
headius: where is hash stored now ?
<headius>
bytelist caches one
<headius>
but it's not the one we use for most things because of hashdos
<lopex>
headius: I wonder if at any point mri devs pondered code range scan and hash calc in one pass
<lopex>
oh, hmm
<headius>
probably not since that would also have required some place to keep it
<lopex>
the could be a flag
<lopex>
*there
<lopex>
headius: did you see my stream fusion question above ?
<headius>
in any case, if ByteList did all character-wrangling too, it could use CR or length or something else, we wouldn't care
yfeldblum has joined #jruby
<lopex>
well, lots could go into jcodings then
<headius>
indeed
<headius>
that's the direction I think all this code should be going
<headius>
out of JRuby
<lopex>
headius: the only thing I'm affraid is the mri intertwined mess, like we'd have to add userData somewhere at some point
<headius>
to what?
<lopex>
any structure there
<lopex>
like userdata in joni
pchalupa has joined #jruby
<headius>
ah well
<lopex>
headius: or callbacks
<lopex>
not sure if I'm making this clear
<nirvdrum>
I'm not sure what you're alluding to, but I'm pretty okay retaining some data in the RubyString implementation and making it implement an interface (pass this) or pass whatever argument to methods in ByteList.
<lopex>
headius: like if mri decides at some point to use it's internals on unrelated code
<headius>
I think we only put in there what makes sense as an isolated library, and if things are more intertwined in MRI we work around that
<headius>
sure, that could happen
<headius>
but we also own our library
kl__ has quit [Ping timeout: 244 seconds]
claudiuinberlin has quit [Quit: Leaving.]
yfeldblum has quit [Ping timeout: 244 seconds]
<headius>
nirvdrum: I tried a couple times to move all CR logic into ByteList, but it always became a big bang sort of move and I never could finish
<lopex>
headius: brave you, I'd definitely require some psychic preparations
<nirvdrum>
Hopefully it'll be easier now. I'm making things static methods on StringSupport with some crazy argument lists. Not pretty, but easily refactorable.
<nirvdrum>
And the key thing is to make everything basically work around ByteList and Encoding.
<nirvdrum>
Code range is the weird one because it's tied to the RubyString itself. I introduced a kludgy CodeRangeable interface for that for now.
<lopex>
nirvdrum: also, in general, joni should be responsible for string validation, now it's a separate pass, but I guess that will never happen
<nirvdrum>
And I'm retaining all the public methods in RubyString, although I think some of those could really be removed.
<headius>
nirvdrum: yeah that structure can transplant pretty easily
<headius>
separate logic for encodings/chars/CR from RubyString, and then evaluate where it should actually live
<nirvdrum>
The elephant in the room is what this does for performance. I don't think it's something we really need to be concerned with. But some of this may need to be unwound.
<nirvdrum>
I'm of the mindset that when the code is easier to read and simpler in structure, both we and the JVM can take a pretty good crack at it.
<headius>
static methods should inline trivially, and are otherwise a direct hop to call rather than a vtable
<headius>
ignoring changes to logic, they should not generally hurt perf, even if diced up pretty small
<nirvdrum>
There are some extra calls in between though. But assuming they inline it shouldn't matter.
<headius>
right
<headius>
as long as there's no vtable indirection you're just spreading out one method into several that inline
<nirvdrum>
The CodeRangeable calls are via interface, so there could be a hit there. But we don't look up code range in extremely hot paths.
<lopex>
nirvdrum: the smaller methods the better
bbrowning has quit [Ping timeout: 252 seconds]
kl__ has joined #jruby
mrmargolis has quit [Remote host closed the connection]
benlovell has joined #jruby
diegoviola has quit [Ping timeout: 245 seconds]
<nirvdrum>
HotSpot has also gotten a lot better since some of this was written.
diegovio1 has joined #jruby
<lopex>
nirvdrum: but afaik there's still mismatch in bytecode being taken as a code measure by heuristics
<lopex>
headius: is that right ?
<headius>
lopex: not as much
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/ZJquiQ
<JRubyGithub>
jruby/master cd5683a Charles Oliver Nutter: Update old test for currently-accepted ancient TZ behavior....
JRubyGithub has left #jruby [#jruby]
<headius>
I believe it was in 7u20 they added incremental inlining, which will keep inlining code based on what the resulting machine code size will be
diegovio1 is now known as diegoviola
x1337807x has joined #jruby
<headius>
rather than based on pre-inlined, pre-optimized metrics like bytecode size
<lopex>
ah
<headius>
I'm not sure of the details
skade has joined #jruby
<lopex>
I wonder if they could some asessment from ssa
<headius>
could be
<headius>
enebo: looking at this lambda arity-checking issue
<headius>
the problem is that Arity is just not up to the task of calculating both min and max args
<headius>
the best it can do is ensure minimum args
<headius>
we can't represent different min and max in the single int Arity aggregates
e_dub has quit [Quit: e_dub]
<headius>
so I'm looking at adding a new structure to start replacing it, just used for this arity check right now
<headius>
chrisseaton: what do you have to represent arity of a method?
<headius>
this could (and maybe should) go all the way to describing keyword arg layout
x1337807x has quit [Ping timeout: 265 seconds]
bbrowning has joined #jruby
<chrisseaton>
headius: there's an Arity object, with minimum, required and whether it's a rest, and then separately (but maybe should be part of it) a list of accepted keywords and whether it accepts keyword rest
<headius>
ok
<headius>
my current debate is how far this should go
<chrisseaton>
org.jruby.truffle.runtime.methods.Arity - I found I couldn't munge it all into one integer - now idea how you've managed
<headius>
I have pre/post/opt/rest for example...so it's representing the layout as much as the count
<headius>
a good solid representation of argument list layout would be helpful in many places
x1337807x has joined #jruby
anaeem1_ has joined #jruby
<chrisseaton>
yeah - it's the hardest thing I've had to tackel
<chrisseaton>
a lot of times I almost write random code until it manages to get the right arguments - it's really slow and painful
<headius>
I know...Ruby is full of richness in this area
<headius>
to put it politely
<chrisseaton>
in fact almost all the remaining language specs we have tagged are destructuring of some kind
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
iamjarvo has joined #jruby
<enebo>
headius: ah yeah this was what I was talking about a while ago…completely changing arity would be nice
<enebo>
headius: and not so fixated in using MRI internal number (although we obviously still need to calc it)
mister_solo has quit [Ping timeout: 245 seconds]
<headius>
yeah my Signature class will aggregate Arity for backward compat
<headius>
or for transition
Integralist has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
metadave_ has joined #jruby
x1337807x has joined #jruby
metadave has quit [Read error: Connection reset by peer]
<Who>
but failing two rubyspecs, ruby/language/block_spec.rb A block taking |a, b| arguments destructures a splatted Array and A block taking |a, *b| arguments destructures a splatted Array
subbu|lunch is now known as subbu
<enebo>
Who: yeah I guess I am not surprised something failed
<enebo>
Who: I suspect this might have more to do with behavior of Generator than proc processing
<enebo>
Who: My familiarity of what << is in this context is lacking
<Who>
It’s proc.call19
<enebo>
Who: it seems like maybe we are destructuring that array at that point and then first is thinking the first element is
<Who>
in RubyYielder
<enebo>
Who: ok then that anonymous class might be the place to fix this or we need different code path. I am unsure without studying MRI
<headius>
enebo: the args to << go straight into RubyProc.call19
nanoyak has quit [Quit: Computer has gone to sleep.]
<enebo>
headius: yeah so there are two possibliities
<headius>
yeah that's possible, the behavior of this yielder may differ from a normal proc perhaps?
<enebo>
headius: which you see the two I can see from that
<headius>
yeah
<enebo>
headius: That goofy logic for call19 is pretty time-tested in spite of being really icky
<headius>
Who: localizing it even more would be to move some of this into RubyYielder before calling the proc
<enebo>
headius: I remember it being a great simplification over what we had
<headius>
but that's just a thought...it's hard to sort out where in MRI they do all the various forms of arg destructuring
<headius>
AHHH I got the missing ENV['HOME'] failures again
<headius>
they haunt us like a poltergeist
<chrisseaton>
headius: interesting thing: in Truffle we're actually compiling different versions of methods/blocks for different destructure semantics
<headius>
chrisseaton: it ends up that way once it gets to JIT in the JVM runtime
<enebo>
Who: headius: yeah I would not be entirely surprised if something changes in proc.call semantics in Ruby 2 or something but I would be more inclined to think yielder/generator logic does something to not destructure that array
cremes has quit [Ping timeout: 245 seconds]
<headius>
hmm, my signature change passes rubyspec and mri
<enebo>
chrisseaton: we should probably have created specialized proc impls based on block type
<headius>
so yay
<enebo>
chrisseaton: Our massive amount of conditional logic sort of gives that smell
camlow325 has quit [Remote host closed the connection]
<enebo>
headius: cool
dabradley has quit [Quit: WeeChat 0.3.8]
<enebo>
headius: I have been bothered about Arity for a while
<chrisseaton>
enebo: I think for blocks we have block-style, proc-style, method-style, and it looks like we also need lambda-style all as separate call targets
<headius>
enebo: it's terrible
<enebo>
headius: and incomplete with kwargs
<chrisseaton>
enebo: we tried creating them on demand but it had pathological characteristics for some cases
<Who>
I’ll try to port the logic to RubyYielder then
<enebo>
chrisseaton: the binding between site and actual used block really makes it tough to follow
<headius>
for the moment I'm just doing normal args, propagating pre/opt/rest/post into closure forms in IR
<headius>
encoded in JIT as a long
<headius>
(64k pre/opt/post should be enough for anyone)
<enebo>
chrisseaton: You can see in Java code we have optimizations which checks block arity at Java callsite to pass things through without stuffing it into a RubyArray instance
<headius>
we wouldn't be able to represent passing or processing more than 64k of any argument anyway
<headius>
in JIT
<enebo>
headius: for kwargs you sometimes need to subtract one
<headius>
hmm
<headius>
I might need a bit for that then
<headius>
at the moment Arity doesn't aggregate that info, though, so same calculations apply wrt kwargs
<enebo>
headius: This is one reason I would like to make at least some portion of kwargs processing out or band (meaning a separate arg and not part of args[])
<headius>
Signature aggregates the old Arity we used
metadave_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<chrisseaton>
are you guys trying to pack something? for the sanity of your future selves, can't you just use a class with fields?
<headius>
so we still have both
<headius>
chrisseaton: just in JIT
yfeldblu_ has joined #jruby
<headius>
Signature has normal fields for pre/post/opt/rest
<headius>
long encode() and decode(long)
<enebo>
headius: stuff it all as one short!!!!
<enebo>
headius: and be sure to use the sign bit
<headius>
16 args should be enough for anyone
<enebo>
have as many arg types as you want so long as it is only required
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/D_PaUA
<JRubyGithub>
jruby/master b6d996d Charles Oliver Nutter: Introduce new Signature class to represent argument layout.
JRubyGithub has left #jruby [#jruby]
<enebo>
So the hash as last arg makes kwarg processing difficult to detect since you do not know which is which until you know what it is calling
<headius>
^ so there's the start on it, anyway
<headius>
enebo: right
<enebo>
but for actual arity itself I guess we do know for the method def
<enebo>
headius: so I am conflating the two sides sort of
<enebo>
headius: but if you get n args it might match n-1 req arity if it is a kwargs method
vifino has joined #jruby
<enebo>
headius: ick
<headius>
heh, ick what
yfeldblum has quit [Ping timeout: 244 seconds]
<enebo>
headius: just that there is an extra layer of calc needed for detecting args.length against a signature which may or may not have kwargs
<headius>
ahh yeah
<headius>
I had started to put kwargs in here but that gets big fast
<headius>
this is just a smarter Arity at the moment
<enebo>
yeah I am still riffing on your next part
<headius>
kwargs logic throughout goes through signature.arity() still
<headius>
that arity should still be the same as before
<headius>
we can expand from here
<enebo>
yeah
<headius>
heh, sometimes I love that we can access JRuby internals from Ruby
<headius>
$ jruby -e "puts JRuby.reference(lambda {|a,b=1| p a}).block.body.signature"
<headius>
enebo: the args for that are parsing as having a rest arg
paulswil_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<enebo>
headius: good lord add some kwargs-style output to that toString :)
<headius>
nah
<enebo>
headius: I did this in the last few months for check_arity instr because it is impossible to remember everything
<headius>
just remember popr
<headius>
:-D
<headius>
yeah I will...had not added toString until debugging this
<enebo>
pre post, opt?, rest?
<enebo>
AHAHA
<headius>
answer my question about parsing!
<enebo>
I cannot even guess…I am still laughing
tcrawley is now known as tcrawley-away
<headius>
the a, form is only allowed in literal block args
<enebo>
headius: oh yeah that is a good question
<headius>
for a lambda it needs to be required = 1
<headius>
and proc doesn't enforce arity anyway
<enebo>
headius: but seems like it could have been a “DIRTY LAMBDA”
<headius>
and you can't use it in the literal lambda syntax
<headius>
->(a,){} doesn't parse
<headius>
nor does def foo(a,)
<enebo>
ah good
<enebo>
headius: have you ever used a, in a script?
<headius>
other than writing tests for it?
<headius>
I have used starnode on occasion
<headius>
but not this
<enebo>
headius: for some reason it seems unappealing and maybe because it looks like a syntax error in my mind
<headius>
yeah it does
tcrawley-away is now known as tcrawley
<enebo>
I have wondered how many of these features have any significant adoption
<enebo>
I can see why someone might have thought it was a good idea but if no one uses it ?
towski has joined #jruby
<Who>
headius: enebo one thing I can think of is to identify this case in Yielder and pass a flag or something, since RubyProc is actually changing the args and then passing it to doYield
<headius>
enebo: I'm not sure where to fix this
<headius>
it's allowed to parse but seems like the comma basically ends up ignored
<enebo>
Who: possibly you need to just wrap the arg in an array too
<headius>
unless there's something after it
<enebo>
headius: yeah this should be a special arity
<enebo>
Who: I think you might need to make a matrix of values and then try each
nanoyak has joined #jruby
<headius>
oh you are creating a special node for it
<headius>
so I think I can work with that in builder
paulswil_ has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
shellac has quit [Ping timeout: 264 seconds]
slyphon has joined #jruby
<Who>
enebo: followed your approach, it seems to be working (RubySpec also passes). I just had wrap with one more layer of RubyArray based on few coditions.
<Who>
let me send the PR, do comment on it if there is anything a miss
<enebo>
Who: ok I might try and find the logic in MRI to see if they actually do this or not
<Who>
I am going to bed for now, it’s pretty late over here
<enebo>
Who: ok thanks for looking into it
nanoyak has left #jruby ["Lates."]
treehau55 has joined #jruby
<headius>
Who: nice exploration
rsim has joined #jruby
<headius>
we're slowly improving and simplifying this nasty logic
<headius>
hmmm
<headius>
ignoring the comma doesn't work
<headius>
it *does* have some behavior
Integral2st has joined #jruby
kl__ has quit [Ping timeout: 264 seconds]
<enebo>
headius: it is >1 arity so it will destructure in a proc I think
<enebo>
headius: but only bind first value
<headius>
yeah it basically destructures as a single argument but acts like arity = 1
<enebo>
yeah
<headius>
I think it needs another flag :-\
elia has joined #jruby
<headius>
enebo: why do you use UnnamedRestArgNode for a,* in blocks instead of StarNode
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] Who828 opened pull request #2458: Fixed yielded arrays of 1 element bug when using Enumerator#first (master...2376_bugfix) http://git.io/SmT9uw
JRubyGithub has left #jruby [#jruby]
<headius>
basically for lambdas, |a,| only accepts one argument, but will destructure incoming array when used as a proc
<headius>
my arity checking is right but I lost destructuring
<enebo>
headius: hmmm
Integral2st has quit [Ping timeout: 245 seconds]
<headius>
destructuring lost because I modified IRBuilder to ignore the rest arg in the comma form
<headius>
I can't have it both ways, so I need more bits
<enebo>
headius: yeah I am trying to remember
<headius>
three-state rest?
<enebo>
headius: ah zsuper
<enebo>
headius: I think noarg would not retain values but star does
<headius>
ugh
<enebo>
headius: maybe?
<enebo>
perhaps even switched :)
<headius>
right, something like that
<headius>
but wait
<headius>
oh
<headius>
define_method
<headius>
nevermind
<headius>
but zsuper doesn't work in define_method anymore, right?
<headius>
in MRI 2.2
slyphon has quit [Quit: I REGRET NOTHiiiiiiiiiinnnngggg….]
<enebo>
headius: actually I am not sure it ever worked
<enebo>
headius: but we always have
<headius>
what I'm saying is that |a,*| parses the * as UnnamedRestArgNode with a name of ""
havenwood has quit []
<headius>
and def foo(a, *) parses it as StarNode
<headius>
I can switch it but trying to understand why
<headius>
and I'm not sure why UnnamedRestArgNode takes a name :-D
<enebo>
yeah and it is ‘*'
<enebo>
:)
Who has quit [Quit: Who]
<enebo>
headius: Another aspect was retaining syntax when we cared about IDEs
<headius>
yeah true
<headius>
I'll fiddle with this
paulswil_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<enebo>
fun bit is MRI has no nodes for either
rsim has quit [Quit: Leaving.]
<enebo>
but they stuff some state in masgn and for new_args about it
<headius>
yeah lovely
<enebo>
headius: I also think we alloc’d so that AST interp would work with zsuper
<enebo>
headius: so we will an innaccessible rest with vlaues in case zsuper was used
<enebo>
headius: and tieing your other observation is we still allow zsuper/super in defnie_method
<enebo>
headius: so there are two dead reasons why we don’t need to care any more
<headius>
ok
<headius>
I'm trying to get * in block args to use StarNode too
<enebo>
headius: although I think not being able to call super in define_method is odd on MRI’s part.
<headius>
starting to go a little quagmire on me
<headius>
well you can call super, just not zsuper
<enebo>
headius: It definitely is possible (we do it) and it does not violate principle of least surprise
<headius>
yeah
<enebo>
I had no parens but yeah I meant zsuper
cremes has joined #jruby
mister_solo has quit [Ping timeout: 244 seconds]
kares has quit [Quit: Ex-Chat]
mrmargolis has quit [*.net *.split]
e_dub has quit [*.net *.split]
subbu has quit [*.net *.split]
SynrG has quit [*.net *.split]
tenderlove has quit [*.net *.split]
dling has quit [*.net *.split]
Sinjo has quit [*.net *.split]
qmx has quit [*.net *.split]
guilleiguaran_ has quit [*.net *.split]
krainboltgreene has quit [*.net *.split]
pietr0 has quit [*.net *.split]
yopp has quit [*.net *.split]
tbuehlmann has quit [*.net *.split]
joevandyk has quit [Max SendQ exceeded]
_whitelogger has joined #jruby
pietr0 has joined #jruby
yopp has joined #jruby
tbuehlmann has joined #jruby
amdprophet has joined #jruby
elia has quit [*.net *.split]
viking has quit [*.net *.split]
jimbaker has quit [*.net *.split]
cultureulterior1 has quit [*.net *.split]
mccraig has quit [*.net *.split]
DomKM has quit [*.net *.split]
mcclurmc_ has quit [*.net *.split]
jgdavey has quit [*.net *.split]
rhinon has quit [*.net *.split]
chrisseaton has quit [*.net *.split]
brycek_ has quit [*.net *.split]
cprice404 has quit [*.net *.split]
dyer has quit [*.net *.split]
Scient has quit [*.net *.split]
haze has quit [*.net *.split]
quadz has quit [*.net *.split]
rtyler has quit [*.net *.split]
Integral2st has joined #jruby
<headius>
enebo: I am representing rest arg as four values in Signature now
<headius>
none, normal, anonymous, and star
<headius>
!= none all destructure and represent Arity the same, as -(required + 1)
<headius>
but for arity checking, anonymous is treated like none
Specialist has joined #jruby
elia has joined #jruby
viking has joined #jruby
DomKM has joined #jruby
cultureulterior1 has joined #jruby
mccraig has joined #jruby
haze has joined #jruby
Scient has joined #jruby
rtyler has joined #jruby
chrisseaton has joined #jruby
jgdavey has joined #jruby
rhinon has joined #jruby
brycek_ has joined #jruby
dyer has joined #jruby
cprice404 has joined #jruby
jimbaker has joined #jruby
mcclurmc_ has joined #jruby
quadz has joined #jruby
<headius>
appears to be working
<nirvdrum>
Control flow in RubyString is the other hard thing to reason about. Lots of nested calls and some may throw exceptions. Unwinding this is a bit tricky.
rcvalle has quit [*.net *.split]
balo has quit [*.net *.split]
kwando has quit [*.net *.split]
Antiarc has quit [*.net *.split]
neoice has quit [*.net *.split]
bruceadams has quit [*.net *.split]
rcvalle has joined #jruby
Antiarc has joined #jruby
kwando has joined #jruby
bruceadams has joined #jruby
neoice has joined #jruby
balo has joined #jruby
vifino has quit [*.net *.split]
vifino has joined #jruby
Integral2st has quit [*.net *.split]
marr has quit [*.net *.split]
pgokeeffe has quit [*.net *.split]
jeremyevans has quit [*.net *.split]
cpuguy83 has quit [*.net *.split]
tcrawley has quit [*.net *.split]
het has quit [*.net *.split]
brixen has quit [*.net *.split]
kotk has quit [*.net *.split]
sluukkonen has quit [*.net *.split]
yarker has quit [*.net *.split]
londo_ has quit [*.net *.split]
projectodd-ci has quit [*.net *.split]
mberg has quit [*.net *.split]
jamo_ has quit [*.net *.split]
klap has quit [*.net *.split]
vifino has quit [*.net *.split]
rcvalle has quit [*.net *.split]
balo has quit [*.net *.split]
kwando has quit [*.net *.split]
Antiarc has quit [*.net *.split]
neoice has quit [*.net *.split]
bruceadams has quit [*.net *.split]
elia has quit [*.net *.split]
viking has quit [*.net *.split]
jimbaker has quit [*.net *.split]
cultureulterior1 has quit [*.net *.split]
mccraig has quit [*.net *.split]
DomKM has quit [*.net *.split]
mcclurmc_ has quit [*.net *.split]
jgdavey has quit [*.net *.split]
rhinon has quit [*.net *.split]
chrisseaton has quit [*.net *.split]
brycek_ has quit [*.net *.split]
cprice404 has quit [*.net *.split]
dyer has quit [*.net *.split]
Scient has quit [*.net *.split]
haze has quit [*.net *.split]
quadz has quit [*.net *.split]
rtyler has quit [*.net *.split]
pietr0 has quit [*.net *.split]
yopp has quit [*.net *.split]
tbuehlmann has quit [*.net *.split]
mrmargolis has quit [*.net *.split]
e_dub has quit [*.net *.split]
subbu has quit [*.net *.split]
SynrG has quit [*.net *.split]
tenderlove has quit [*.net *.split]
dling has quit [*.net *.split]
Sinjo has quit [*.net *.split]
qmx has quit [*.net *.split]
guilleiguaran_ has quit [*.net *.split]
krainboltgreene has quit [*.net *.split]
kith has quit [*.net *.split]
lanceball has quit [*.net *.split]
metadave has quit [*.net *.split]
cremes has quit [*.net *.split]
towski has quit [*.net *.split]
ivan\ has quit [*.net *.split]
electrical has quit [*.net *.split]
Xzyx987X has quit [*.net *.split]
DrShoggoth has quit [*.net *.split]
enebo has quit [*.net *.split]
lopex has quit [*.net *.split]
locks has quit [*.net *.split]
LTe has quit [*.net *.split]
englishm has quit [*.net *.split]
kylo has quit [*.net *.split]
logs has quit [*.net *.split]
skade has quit [*.net *.split]
joevandyk has quit [*.net *.split]
diegoviola has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
jc00ke has quit [*.net *.split]
spectre256 has quit [*.net *.split]
yfeldblu_ has quit [*.net *.split]
x1337807x has quit [*.net *.split]
benlovell has quit [*.net *.split]
olleolleolle has quit [*.net *.split]
mje113__ has quit [*.net *.split]
baroquebobcat has quit [*.net *.split]
bryancp has quit [*.net *.split]
flavorjones has quit [*.net *.split]
AckZ has quit [*.net *.split]
fidothe has quit [*.net *.split]
graphex has quit [*.net *.split]
eregon has quit [*.net *.split]
asarih has quit [*.net *.split]
mpapis has quit [*.net *.split]
beawesomeinstead has quit [*.net *.split]
portertech has quit [*.net *.split]
jgraichen has quit [*.net *.split]
universa1 has quit [*.net *.split]
finch has quit [*.net *.split]
Guest85414______ has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
justinmcp_ has quit [*.net *.split]
dcolebatch has quit [*.net *.split]
asuka has quit [*.net *.split]
lupine has quit [*.net *.split]
eonwe has quit [*.net *.split]
Freaky has quit [*.net *.split]
mtfk_ has quit [*.net *.split]
teamon_ has quit [*.net *.split]
ale_ has quit [*.net *.split]
Athenelle has quit [*.net *.split]
nateberkopec has quit [*.net *.split]
multibot_ has quit [*.net *.split]
mswart has quit [*.net *.split]
atambo has quit [*.net *.split]
zph has quit [*.net *.split]
headius has quit [*.net *.split]
dvorak has quit [*.net *.split]
dcheung has quit [*.net *.split]
errstr has quit [*.net *.split]
koichiro_zzz0 has quit [*.net *.split]
lumeet has quit [*.net *.split]
Haifeng has quit [*.net *.split]
Liothen has quit [*.net *.split]
Jamo has quit [*.net *.split]
_ko10 has quit [*.net *.split]
tarcieri has quit [*.net *.split]
treehau55 has quit [*.net *.split]
bbrowning has quit [Remote host closed the connection]
dbussink has quit [Excess Flood]
dbussink has joined #jruby
metadave has joined #jruby
bruceadams has joined #jruby
brycek_ has joined #jruby
x1337807x has joined #jruby
e_dub has joined #jruby
Xzyx987X has joined #jruby
lanceball has joined #jruby
brixen has joined #jruby
tenderlove has joined #jruby
mrmargolis has joined #jruby
yosafbridge has joined #jruby
teamon_ has joined #jruby
ale_ has joined #jruby
graphex has joined #jruby
eonwe has joined #jruby
kotk has joined #jruby
<headius>
because there were no timezones but they need the tables to work for all times ever, they use solar time
<eregon>
wow, timezones before timezones, definitely bad stuff
<headius>
yeah
jeregrine has quit [Max SendQ exceeded]
<headius>
I decided that we'll just let Joda do its thing and fixed the test to use an explicit offset
<headius>
it should be ok now
<eregon>
yeah
<eregon>
since the test is about precision of Time#+ and TIme#- mostly
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<headius>
things look ok locally now
<eregon>
headius: about RubySpec, I guess contributing to it in the Rbx repo is far from ideal. Contributing to nurse's fork or an independent fork would likely be far easier
<headius>
right
<headius>
until it is updated, though, we can't really switch
<headius>
so that would be a good priority for someone
<eregon>
plus, this merging of files in bigger repo would be much simpler if it was oinly going from specs-only repo to big repos most of the time :)
<eregon>
only*
kl__ has joined #jruby
<headius>
eregon: indeed
<headius>
might be worth exploring git modules AGAIN to see if they'd work
<eregon>
yeah, but it might work decently for such stuff
<headius>
ArgumentError: wrong number of arguments (3 for 11)
<headius>
something's not quite right there.
<eregon>
ahah
<headius>
oops, I see it
<headius>
javac is compiling "str" + required() + opt + "str" as 11 instead of 2
<eregon>
(MRI just "git clone", so essentially implementing submodules by themselves so that might work, except you can't change them direclty there)
<headius>
right
<headius>
that would probably be the best option, to be honest
<headius>
wanna run specs, need to clone them first
<headius>
clone as you if you want to edit in place
<headius>
ideally we'd be able to do that for MRI's tests too, but I need to get my few modifications back in
<nirvdrum>
Everyone potentially running a different version of the specs sounds like a recipe for disaster.
<eregon>
the issue of one "bad" change breaking all others impls is real, we need some way to avoid it as much as possible
<headius>
nirvdrum: well, MRI and JRuby would be using the same set
<headius>
do you mean wrt scm?
<eregon>
nirvdrum: it's already the case
<nirvdrum>
Maybe I misunderstood then. I thought you were saying people would be responsible for cloning the spec directory themselves in lieu of submodules.
<eregon>
ah, but it would still be from a fork or so to keep the latest revision a "good latest stable"
<nirvdrum>
eregon: Well currently they're versioned in the source tree. So when I do a "git pull" I get any spec changes.
<headius>
nirvdrum: well, I figured our build would do that
<headius>
but if you want to clone a writable copy you could
<headius>
we used to do it this way...the build knew what rev of specs we were on
<eregon>
yeah, auto-pulling is really too annoying in practice, doing it manually regularly is much better
<headius>
yeah, can't just pull master because new specs may not pass
<headius>
has to be locked to a version
<eregon>
anyway, first issue would be to elect the new canonical RubySpec, and merge efforts ot bring most the clones in that one
<nirvdrum>
We could tag them.
<headius>
I dunno, we have a lot of tools and no combination of them feels best to me
<nirvdrum>
But I guess I don't feel too strongly. That's just the potential downside I see.
<headius>
nirvdrum: not on CI we can't :-D
<headius>
I'm talking about a build that always just clones HEAD would not work because of that
<headius>
it would have to clone a specific revision at least
<nirvdrum>
I'm okay letting a build fail and have someone investigate to tag *shrug*
<eregon>
yeah, of course
<headius>
at which point, versioning in our repo is not much different
<headius>
<headius>
nirvdrum: except a build that didn't fail the first time might fail the second if a spec were added between the two
<headius>
too variable
<nirvdrum>
Fair enough.
<eregon>
mmh, having a submodule force to contribute to canonical repo, dunno if it is good (avoid merging different repos) or not (force to merge on canonical repo)
<enebo>
yeah I like fixing something and not needing to worry whether some new spec arrived
<eregon>
nirvdrum: the situation where specs are updated independently of impl commits is basically what made MRI fork RubySpec if I recall well
jeremyevans has joined #jruby
<eregon>
we already break each the build enough like that :D
<eregon>
-each
<headius>
submodules are almost right but they kept showing up as dirty for me in git status
kaawee has joined #jruby
<headius>
for unknown reasons...like I'd do nothing to touch them and they'd show as dirty suddenly
<eregon>
I'll try to write a few thoughts on the ruby-core thread about what we discussed
<headius>
ok
<headius>
I need to get back to that thread
<nirvdrum>
eregon: That's fine. I was just trying to avoid the problem we have no where a spec update is made but we don't pick it up for weeks.
<eregon>
yeah, I would be in favor to try submodules again
<nirvdrum>
I was expecting the auto-pull to be a commit itself, so when the build fails it'd be easy to track it down.
<nirvdrum>
But, again, I don't care a whole lot.
<nirvdrum>
So I'll just stop talking :-)
<eregon>
I see your point :) I think nothing can beat human granularity to update specs so no one feels forced to fix or tag (but a reminder to not forget doing it might help)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/I1Zjbw
<JRubyGithub>
jruby/master 7cc1afc Charles Oliver Nutter: Fix error message for arity fail with opt args.
<JRubyGithub>
jruby/master 6218a4d Charles Oliver Nutter: Remove some now-passing excludes for block behaviors.
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius closed issue #2441: Lambda with arity -2 can be called with three arguments in 9K http://git.io/WSXeKQ
<slyphon>
hey, i have what may be a common question about jnr-posix, it seems from reading through the code that there's no way to exec except on windows?
<slyphon>
i read headius' blog post from 2013 about the problems with process management on the JVM, I was wondering if you guys had figured out a decent solution
<headius>
slyphon: well exec is in there for all platforms, isn't it?
<headius>
JRuby master is now using posix_spawn to do process launching
<headius>
from jnr-posix
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/1nKoWw
<JRubyGithub>
jruby/master 99a2573 Chris Seaton: [Truffle] Remove DSL from dispatch nodes.
JRubyGithub has left #jruby [#jruby]
<headius>
I have meant to wrap it with a nice ProcessBuilder-like API but have not had time
<slyphon>
handler.unimplementedError("No exec in Java (yet)");
<headius>
slyphon: JavaPOSIX is the version we use when we can't use the native logic
<slyphon>
ahhhhhhhh
<slyphon>
ok, i thought that might be the case
<headius>
it has substantially reduced functionality as you'd expect
* slyphon
nods
<slyphon>
this is great, btw
<slyphon>
we have a lot of problems automating git operations because some java jockey is using the native java process stuff and it has all sorts of stupid issues
<slyphon>
well, process management stuff in general
<slyphon>
and i didn't want to repeat his mistakes
<slyphon>
:)
<headius>
oh yeah
<headius>
slyphon: if you want to pair on building a process wrapper, I'm all over that
<slyphon>
oooh
<headius>
jnr-process or something
<slyphon>
that would be awesome
<slyphon>
lemme do some reading
<headius>
yah read up on posix_spawn
<slyphon>
so i don't sound like a tool
<slyphon>
excellent
<headius>
it's bound and working in jnr-posix and it has allowed us to really support POSIX process semantics in 9k
<slyphon>
I had the idea to write a scala wrapper around this stuff
<headius>
oh yeah, that would be slick
<headius>
I'd really like to see jnr-ffi support for all key jvm languges too
<slyphon>
yeah, eventually work it so i can represent it using futures
<slyphon>
i'm pretty sure some of the finagle nerds would be interested