<headius[m]>
kares: I am punting https://github.com/jruby/jruby/pull/4736 to 9.2.8 but I think we should just go big finally and make a set of invalidators for ALL the key fixnum/float methods we want to optimize. That way modifying one method won't affect any of the others, across the board.
<headius[m]>
for some upcoming release we need to do some unification of how we dispatch calls between interpreter and indy JIT, so we can take advantage of common logic. Right now we have our own CallSite impls, indy call sites, and a few non-callsite (and poorly optimized) paths for things like super. Gotta get that straightened out.
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jmalves has joined #jruby
lucasb has joined #jruby
KeyJoo has quit [Quit: KeyJoo]
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
<rdubya[m]>
Does jruby support thread level "safe levels"?
jmalves_ has joined #jruby
jmalves has quit [Ping timeout: 246 seconds]
<enebo[m]>
ok looks like this is 9.2.7.0 day!
<OlleJonssonGitte>
\o/
jmalves_ has quit [Ping timeout: 245 seconds]
jmalves has joined #jruby
mat_bug has quit []
<kares[m]>
yay! for 9.2.7
<JulesIvanicGitte>
:tada:
<kares[m]>
rdubya: it isn't supported/implemented
<kares[m]>
btw, do you find those useful?
<headius[m]>
kares yeah ditto on the fixnum thing, Rails kills it right away
<kares[m]>
yy actually some stdlib requires kill it as well as they add Integer methods
<headius[m]>
Right that too
<headius[m]>
We also need to fix the fixnum/float call sites to cache an object for when they can't call with a long or double...I think it creates new every time still
<headius[m]>
This stuff is all so much easier with Indy but Indy means no native image, so things won't be quite that simple
<rdubya[m]>
kares: I was just looking at it because we're developing a templating library based on nokogiri and I was hoping to take advantage of the sandboxing
<headius[m]>
Sandboxing using safe levels is never reliable, and almost certainly not actually safe, which is why the feature has largely been removed from CRuby as well
<rdubya[m]>
makes sense, was mostly just hoping to use it as a secondary line of defense
<headius[m]>
There are plenty of folks who use jruby and jvm isolation and jvm security to do sandboxing, though. The TryRuby site used to be a server-side JRuby app.
jmalves has quit [Remote host closed the connection]
<headius[m]>
enebo do you know how the Kinetic Data guys are doing sandboxing? Their whole app revolves around user-created scripting
jmalves has joined #jruby
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xardion has quit [Remote host closed the connection]
<lopex>
and it only occured because someone tried css in lookbehind
<lopex>
any comments on those @1 etc placeholders ?
<headius[m]>
disapprove
<enebo[m]>
@1 denied
<enebo[m]>
lopex I will not be leaving for a few more days
<lopex>
if there was a currying operator there wouldnt be a need for so much explicit lambdas
<lopex>
but then you'd go for haskells pointfree madness
<lopex>
headius[m]: enebo[m] and what about that .: operator ?
<enebo[m]>
lopex: I don't see it generally as an improvement
<enebo[m]>
[1,2,3].map(&2.:*)
<enebo[m]>
I would rather see |n| 2 * n
<enebo[m]>
hell even @1 * 2 seems better
<lopex>
enebo[m]: is it's a bogus argument on both sides imho
<lopex>
too little gain
<lopex>
it will never be map (2*) [...]
<lopex>
I mean both versions
<enebo[m]>
lopex: I don't remember that whole haskell (+1) (+) (1+) partial function thing is called but this all feels like someone is trying to hack in syntax give this level of convenience
<lopex>
sure
<lopex>
well
<lopex>
enebo[m]: in haskell () is a syntax trick to convert infix function into info prefix
<lopex>
just as `` does otherwise
<lopex>
so they have plentyful of syntax freedom there
<enebo[m]>
lopex: but it is syntax for controlling application of how the function is applied
<enebo[m]>
lopex: I feel like this is what these Ruby changes are trying to do as well
<lopex>
enebo[m]: evalwise ?
<enebo[m]>
lopex: but they look ugly
<lopex>
yeah
<enebo[m]>
lopex: no just syntactically
<lopex>
so evalwise ?
<enebo[m]>
lopex: well I don't understand what you mean by evalwise
<enebo[m]>
lopex so I may mean that :)
<lopex>
wrt evaluation order etc
<enebo[m]>
well 1 + @1 and @1 + 1 is one form
<lopex>
aah
<lopex>
then, is it syntax ?
<enebo[m]>
Unfortunately .:+ is not useful
<enebo[m]>
well maybe you can Integer.:+ and it will receive 2 params?
<lopex>
yeah, arity
<enebo[m]>
but &Integer.:+ is pretty unpalatable to just doing @1 + @2
<lopex>
that's a different issue
<enebo[m]>
well I feel they are trying to solve simiar issues though
<lopex>
^ that was a reponse to the former
<enebo[m]>
or there is some overlap at least &1.:+
<enebo[m]>
oh ok
<lopex>
enebo[m]: at least @ are positional
<enebo[m]>
&.:+ is almost looks like APL :)
<lopex>
bit what if foo {|a| a + @2 } ?
<enebo[m]>
hahaha
<lopex>
and what about splats ?
<lopex>
etc
<enebo[m]>
I don't think it will work
<enebo[m]>
I think normative definition for @n is it must map to |a,b,...n,| <- note last comma
<lopex>
hm
<enebo[m]>
so maybe your foo example is |a,b,| but I sure hope not as that is confusing
<lopex>
yeah
<enebo[m]>
benoit was annoyed at this because passing in [1,2] into something use @1 will not recieve [1,2] but 1
<enebo[m]>
and for those of us who are not implementers these semantics seem ambiguous and definitely will be unintuitive
<lopex>
right
<lopex>
in scala there;s already problems with _
<enebo[m]>
I do like the notion of controlling binding and mapping to a function as syntax or as some primal functions but of course this is not really that to me
<lopex>
but I thought I liked positional better than _ and _ etc
<lopex>
whatever you call that
<enebo[m]>
oh yeah unnamed vars
<enebo[m]>
I would like explicit binding syntax in procs/lambdas so autospreading is explicit
<enebo[m]>
passing [1, 2] into proc with |a| vs |a,b| is just weird
<lopex>
and then splats and kwargs
<enebo[m]>
I would prefer a to get [1,2] and for a and b to get 1 and 2 to be |(a, b)|
<enebo[m]>
that would be a big semantic change but it would be pretty clear how it worked
<lopex>
enebo[m]: how much logic w would go away
<enebo[m]>
the auto-splatting is magic most people don't notice until one day it throws them off the bridge in confusion
<lopex>
yeah, I'm accustomed to it in ruby though now
<enebo[m]>
who knows...block binding logic is horribly corner casey...I would be keen on removing all of it if possible
<enebo[m]>
I think I usually just avoid it or it happens to work since I mostly only hit it in bug reports
<enebo[m]>
It sometimes happens but then I realize what is going on
<lopex>
enebo[m]: but as I said you go either this route, or curry functions and overuse pointfree