<boc_tothefuture[>
Trying to understand something here about ruby ranges.. When I have a custom range object, it will call spaceship between the beginning and end.. Which makes sense. Then it calls spaceship on the beginning and object being checked with cover?.. However, next it appears to call the spaceship on the object being checked and the end? Rather than calling spaceship on the end and passing it the object being checked..
<boc_tothefuture[>
Is that right? Because that means the object being checked needs to understand the range objects as well?
<boc_tothefuture[>
I don't understand why it doesn't just call the spaceship on end, passing it the object.
<boc_tothefuture[>
Or does ruby not support a range of one type of object checking if the other type of object is in that range?
<boc_tothefuture[>
But in some cases it does call it on the end object instead?.. hmm.
<boc_tothefuture[>
Looking at the java code.. I do wee where it calls rangeLt or rangeLe.. but why do I see in some cases it being called on my object instead. Like when its a String.
<boc_tothefuture[>
oh, because it calls invcmp
<boc_tothefuture[>
Got it.. just needed to rubber duck in here apparently.
<headius[m]>
good afternoon!
<headius[m]>
boc_tothefuture: finally back in the office, having a look at your issue now
<headius[m]>
there is a possibility here maybe you can clarify
<headius[m]>
instance_exec would be a reasonable way to isolate variables
<headius[m]>
there is no way currently for you to have the same object exhibit different instance variables per file, so let's get past that model right now
<headius[m]>
or at least no way to do it without actually having different objects or different engines/containers
<headius[m]>
with instance exec you can run a piece of code that uses instance variables against separate objects... that is the closest you might be able to get
<headius[m]>
I see in your DSL example you show rule_set containing 1..n rule, which have 'run' block that eventually contains the instance variable (for this example)
<headius[m]>
the blocks there passed to run would be the things you want to instance_exec against separate objects per file
<headius[m]>
this is similar to how rspec handles instance variables... it creates an object for the spec run and instance_exec the block within that object, so it isn't just in the top-level global object
<headius[m]>
I reviewed and it seems fine... only distant concern would be the impact on code that's doing both shift/unshift operations and push/pop operations against the same Array, which seems pretty unlikely
<headius[m]>
if you do one unshift it seems logical that you will do others, but probably not likely you will suddenly start pushing on the other end
ur5us has joined #jruby
ur5us_ has quit [Ping timeout: 264 seconds]
<headius[m]>
the original Crystal issue ahorek linked above argues that this makes it more efficient to use an Array as a queue but I am not sure I agree...
<headius[m]>
it makes it a more efficient stack on both ends but a queue will still lead to a lot of copying
<enebo[m]>
lol...I just merged it
<enebo[m]>
I did not see this commentary before your ping
<headius[m]>
that's fine with me but the question stands
<enebo[m]>
I don't think that would be very common but I guess that is absent any hot code which does this to begin with
<enebo[m]>
feels like unshift is typical in situations where you just remove first arg like we do in sprintf
<enebo[m]>
doing continue unshifts in a loop would be a very odd pattern (I think)
<enebo[m]>
So a hot loop I think would normally be unshifting once and then walking the rest
<enebo[m]>
It is conceivable someone would push perhaps later but ???
<headius[m]>
well unshift inserts at the beginning, so the idea is that if you are inserting at the beginning your subsequent inserts will also probably be at the beginning
<enebo[m]>
oh sorry hahah I was thinking of shift
<enebo[m]>
yeah in this case I am less clear on idiomatic pattern other than wanting to work on front of array
<headius[m]>
and shift is used to yank off elements in the order they are in the array, that is fairly common
<enebo[m]>
but if you are diong that a lot then perhaps you are doing it wrong and should be using push and a reversed array
<headius[m]>
or if you really want to unshift+push or shift+pop you should use an actual queue
<enebo[m]>
but this is pretty clear on why it is there and maintenance is minimal
<headius[m]>
er I mean unshift+pop and shift+push
<enebo[m]>
ahorek: so they double space so they can memcopy/memmove without having to alloc
<enebo[m]>
in some situations
<headius[m]>
ahorek: the additional magic from CRuby might be worth exploring but I think spending a lot of time optimizing queue-like usage of Array is misguided
<enebo[m]>
I would be surprised if a lot of people continually shift onto the same array just due to it being much slower than doing it pretty much any other way
<enebo[m]>
A newer programmer may do it because it is more straight-forward but I think most people will dismiss this once they understand how arrays tend to perform
<enebo[m]>
other than stuff like processing a command-line or something like that but then that will never probably be measurable and thus not be noticed
<enebo[m]>
faster without any big maintenance burden is simple though
<ahorek[m]>
I agree, but the optimization is simple enough
<enebo[m]>
and single shift probably definitely happens in hot places from time to time
<enebo[m]>
just not commonly
<enebo[m]>
ahorek: just talking through any extra effort. This is a pretty simple win
<headius[m]>
ahorek: thanks for the patch
<ahorek[m]>
np
<ahorek[m]>
I also tried []= optimization (described in the crystal's PR), but it wasn't significantly faster and unlikely to happen in a real code
<headius[m]>
I don't see that description in the crystal PR
<ahorek[m]>
arr = [1,2,3,4,5]
<ahorek[m]>
arr[0..3] = 5
<ahorek[m]>
=> [5, 5]
<headius[m]>
ahh I see
<ahorek[m]>
just shift the index instead of memcpy