I'm personally quite interested in seeing what the profile of Ruby code is
that can run extremely fast, because it's certainly possible to restrict
core class implementations to that. And if that's possible, it might be
possible to have fast core classes in Ruby (at least experimentally), which
cou
Good idea. This would make define_method free in a lot of common cases. It
would also give rise to optimizations in Ruby code that are kinda unpleasant
(to make blocks faster, don't use local variables), but hey...
-- Yehuda
On Tue, Jul 28, 2009 at 9:37 PM, Thomas E Enebo wrote:
> On Wed, Jul 29
On Wed, Jul 29, 2009 at 9:06 AM, Subramanya Sastry wrote:
>
>> > It is good to hear from everyone about common code patterns and what the
>> > common scenarios are, and what needs to be targeted. But, the problem
>> > often
>> > is that ensuring correctness for the 1% (or even 0.1%) uncommon case
On Wed, Jul 29, 2009 at 7:55 AM, Charles Oliver
Nutter wrote:
> On Sat, Jul 25, 2009 at 10:37 PM, Thomas E Enebo wrote:
>> Hotspot will synthesize types based on runtime profiling for things
>> like interfaces so that it can internally perform static dispatch (or
>> so I have been told). They also
On Wed, Jul 29, 2009 at 12:21 AM, Ola Bini wrote:
> Charles Oliver Nutter wrote:
>>
>> 2009/7/28 Marcin Mielżyński :
>>
>>>
>>> There's very few places where new 1.8.7 features differ from 1.9 ones
>>> (notably individual String/Enumerable methods, or slight difference for
>>> deep
>>> hashing like
On Tue, Jul 28, 2009 at 7:06 PM, Subramanya Sastry wrote:
> I probably lean towards the latter. But, insofaras all implementations have
> bugs and specs are incomplete, you have some leeway probably. In addition,
> I am not sure if there is a solid language spec for Ruby which also leaves
> the p
On Fri, Jul 24, 2009 at 9:34 AM, Ola Bini wrote:
> Subramanya Sastry wrote:
>>
>>
>> So, the real question here boils down to the previous one: can we safely
>> determine what local variables are captured by closures? In that sense,
>> this is not a new special case that we need
>
> No, that's not
On Wed, Jul 22, 2009 at 12:11 AM, Subramanya Sastry wrote:
>> So for example, if we know we're doing a call that is likely to access
>> the caller's frame, like "public" or "private", the IR could also
>> include information about preparing a frame or ensuring a frame has
>> already been prepared.
> > It is good to hear from everyone about common code patterns and what the
> > common scenarios are, and what needs to be targeted. But, the problem
> often
> > is that ensuring correctness for the 1% (or even 0.1%) uncommon case
> might
> > effectively block good performance for the 99% common
On Sun, Jul 26, 2009 at 12:01 AM, Subramanya Sastry wrote:
>> However--as I have pointed out to Charlie a number of times--in practice,
>> classes are basically frozen after *some* time. In Rails, pretty much all
>> classes reach their final stage at the end of the bootup phase. However,
>> since J
On Sat, Jul 25, 2009 at 10:37 PM, Thomas E Enebo wrote:
> Hotspot will synthesize types based on runtime profiling for things
> like interfaces so that it can internally perform static dispatch (or
> so I have been told). They also have guards to deopt if their type
> assumptions are wrong. We co
Exceptions coming out of eval no longer have line numbers
-
Key: JRUBY-3838
URL: http://jira.codehaus.org/browse/JRUBY-3838
Project: JRuby
Issue Type: Bug
Components: Ruby 1.8
Charles Oliver Nutter wrote:
2009/7/28 Marcin Mielżyński :
There's very few places where new 1.8.7 features differ from 1.9 ones
(notably individual String/Enumerable methods, or slight difference for deep
hashing like Hash#hash which shouldn't be detectable in 1.8.7/1.9). We have
almost ever
2009/7/28 Marcin Mielżyński :
> There's very few places where new 1.8.7 features differ from 1.9 ones
> (notably individual String/Enumerable methods, or slight difference for deep
> hashing like Hash#hash which shouldn't be detectable in 1.8.7/1.9). We have
> almost everything (if not all) in plac
Ola Bini wrote:
Hi,
Not sure if we ever reached a consensus on 1.8.7.
A typical problem point is that the new Hpricot is using some 1.8.7
features (such as String#lines).
Should we start making things 1.8.7 compatible or not? If not, how
should we handle libraries like these?
Cheers
Ther
On Tue, Jul 28, 2009 at 8:09 AM, Ola Bini wrote:
> Hi,
>
> Not sure if we ever reached a consensus on 1.8.7.
>
> A typical problem point is that the new Hpricot is using some 1.8.7 features
> (such as String#lines).
> Should we start making things 1.8.7 compatible or not? If not, how should we
> ha
Hi,
Not sure if we ever reached a consensus on 1.8.7.
A typical problem point is that the new Hpricot is using some 1.8.7
features (such as String#lines).
Should we start making things 1.8.7 compatible or not? If not, how
should we handle libraries like these?
Cheers
--
Ola Bini (http://ola
17 matches
Mail list logo
