On Friday 31 March 2006 08:52 am, Thomas E Enebo wrote:
>This is prone to the same problem that took us away
> from lazy instantiation in the first place. Namely, if
> you define a method in Kernel or Object matching the camel
> case name that you are hoping will be lazily created, then
> met
I added a couple additional quick interpreter optimizations this morning. After running some numbers through, I saw that we're creating roughly 170 times as many InstructionBundle objects as there are unique AST nodes in the system. I knew this was wasteful when I wrote it, but I figured now is a g
HEH. I just noticed the marshal_load/dump is commented out in Ruby.
-Tom
On Fri, 31 Mar 2006, Ola Bini defenestrated me:
> Hi.
>
> This patch creates a _dump-method for Time that matches what Ruby 1.8
> creates. The code is created by looking at time.c in the Ruby distro.
> I have also added
This is prone to the same problem that took us away
from lazy instantiation in the first place. Namely, if
you define a method in Kernel or Object matching the camel
case name that you are hoping will be lazily created, then
method_missing will not be called.
Perhaps, this is ok for came
Hi.
This patch creates a _dump-method for Time that matches what Ruby 1.8
creates. The code is created by looking at time.c in the Ruby distro.
I have also added some methods to support marshal_dump later on. What's
missing is a correct implementation of _load in Time, but that will come
soon
On Thursday 30 March 2006 10:21 pm, Charles O Nutter wrote:
> That's a possibility.
>
> def method_missing(sym, *args)
> camel = to_camel(sym)
> super unless respond_to?(camel)
return super unless respond_to? camel
> send(camel, *args)
> end
>
I'm sure that's what you meant :)
> On
Charles O Nutter wrote:
The fix was to also set self on the adopted thread's frame and evaluator. I
would LOVE to commit this fix right now, but SF CVS is still down. So here's
the changed code. With this fix, your test case runs successfully.
I built a custom jruby.jar with your new code,
