[ruby-core:20190] Behavior: autoload calls rb_require() directly

[ruby-core:20190] Behavior: autoload calls rb_require() directly

[Evan Phoenix]

Hi everyone,

While working on some specs, we found out that autoload  
(Kernel#autoload and Module#autoload) internally call rb_require()  
directly to pull the file in. This of course means that if  
Kernel#require has been changed (for instance by rubygems) that the  
changed logic won't be run.

My question is if it's intentional that autoload bypasses  
Kernel#require. If not, autoload should probably use rb_funcall() to  
keep everything consistent.

This obviously also effects Rubinius, as our autoload just calls  
Kernel#require directly.

Thanks!

  - Evan Phoenix

[ruby-core:20200] Re: Behavior: autoload calls rb_require() directly

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20190] Behavior: autoload calls rb_require() directly"
    on Tue, 2 Dec 2008 02:54:36 +0900, Evan Phoenix <evan@fallingsnow.net> writes:

|While working on some specs, we found out that autoload  
|(Kernel#autoload and Module#autoload) internally call rb_require()  
|directly to pull the file in. This of course means that if  
|Kernel#require has been changed (for instance by rubygems) that the  
|changed logic won't be run.
|
|My question is if it's intentional that autoload bypasses  
|Kernel#require. If not, autoload should probably use rb_funcall() to  
|keep everything consistent.
|
|This obviously also effects Rubinius, as our autoload just calls  
|Kernel#require directly.

This leads another question: should any implementation be affected by
basic method replacement, which may make implementation fragile, but
more extensible.  For MRI, this is basically protected by calling C
functions directly (no dynamic dispatch unless explicitly stated).
But for Rubinius, it always use dynamic method calls by definition.
The (official) spec will make this "implementation dependent".

							matz.

[ruby-core:20215] Re: Behavior: autoload calls rb_require() directly

[Evan Phoenix]

On Dec 1, 2008, at 10:36 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: [ruby-core:20190] Behavior: autoload calls  
> rb_require() directly"
>    on Tue, 2 Dec 2008 02:54:36 +0900, Evan Phoenix <evan@fallingsnow.net 
> > writes:
>
> |While working on some specs, we found out that autoload
> |(Kernel#autoload and Module#autoload) internally call rb_require()
> |directly to pull the file in. This of course means that if
> |Kernel#require has been changed (for instance by rubygems) that the
> |changed logic won't be run.
> |
> |My question is if it's intentional that autoload bypasses
> |Kernel#require. If not, autoload should probably use rb_funcall() to
> |keep everything consistent.
> |
> |This obviously also effects Rubinius, as our autoload just calls
> |Kernel#require directly.
>
> This leads another question: should any implementation be affected by
> basic method replacement, which may make implementation fragile, but
> more extensible.  For MRI, this is basically protected by calling C
> functions directly (no dynamic dispatch unless explicitly stated).
> But for Rubinius, it always use dynamic method calls by definition.
> The (official) spec will make this "implementation dependent".

It's a case by case basis. There are certainly places where you want  
to allow the user to change a method and have it be called. I'm  
wondering if this is one of those times.

I don't necessarily see it as making the implementation fragile, since  
those dynamically invoked methods can do nothing more than a  
statically invoked method could.

For now, in Rubinius, we'll go ahead and have Autoload call an  
internal method that require also calls, to retain compatibility.

Thanks!

  - Evan Phoenix

>
>
> 							matz.
>

[ruby-core:20217] Re: Behavior: autoload calls rb_require() directly

[Dave Thomas]

>> This leads another question: should any implementation be affected by
>> basic method replacement, which may make implementation fragile, but
>> more extensible.  For MRI, this is basically protected by calling C
>> functions directly (no dynamic dispatch unless explicitly stated).
>> But for Rubinius, it always use dynamic method calls by definition.
>> The (official) spec will make this "implementation dependent".

If you're worried about fragility, then isn't the ability to redefine  
Fixnum#+ more of an issue?

I thought the underlying reason for directly calling the methods from  
C was one of performance. For some stuff, like string comparisons in a  
sort, I can see than. But for require, which is called infrequently,  
I'd personally opt for extensibility. Being able to intercept require  
could be useful if it could be relied upon.


Dave

[ruby-core:20222] Re: Behavior: autoload calls rb_require() directly

[Yehuda Katz]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

However, that is *not* currently the implementation, and it could introduce
bugs to change the behavior now.
Merb, for instance, uses rubygems (which overrides require) as well as
autoload. Modifying the behavior to use the overridden require now would
probably produce some changes in behavior, especially since rubygems is in
common use and overrides require. Rails also overrides require.

-- Yehuda

On Tue, Dec 2, 2008 at 9:57 AM, Dave Thomas <dave@pragprog.com> wrote:

>
>  This leads another question: should any implementation be affected by
>>> basic method replacement, which may make implementation fragile, but
>>> more extensible.  For MRI, this is basically protected by calling C
>>> functions directly (no dynamic dispatch unless explicitly stated).
>>> But for Rubinius, it always use dynamic method calls by definition.
>>> The (official) spec will make this "implementation dependent".
>>>
>>
> If you're worried about fragility, then isn't the ability to redefine
> Fixnum#+ more of an issue?
>
> I thought the underlying reason for directly calling the methods from C was
> one of performance. For some stuff, like string comparisons in a sort, I can
> see than. But for require, which is called infrequently, I'd personally opt
> for extensibility. Being able to intercept require could be useful if it
> could be relied upon.
>
>
> Dave
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

[-- Attachment #2: Type: text/html, Size: 2058 bytes --]

[ruby-core:20224] Re: Behavior: autoload calls rb_require() directly

[Dave Thomas]

On Dec 2, 2008, at 1:08 PM, Yehuda Katz wrote:

> However, that is *not* currently the implementation, and it could  
> introduce bugs to change the behavior now.
>
> Merb, for instance, uses rubygems (which overrides require) as well  
> as autoload. Modifying the behavior to use the overridden require  
> now would probably produce some changes in behavior, especially  
> since rubygems is in common use and overrides require. Rails also  
> overrides require.
>

And Matz is saying the, if nothing else is agreed, that behavior will  
be an implementation-detail, and not part of the standard. Wouldn't it  
be better to swallow a smaller pill now and standardize on _something_?


Dave

[ruby-core:20225] Re: Behavior: autoload calls rb_require() directly

[Trans]

On Dec 2, 2:08 pm, "Yehuda Katz" <wyc...@gmail.com> wrote:
> However, that is *not* currently the implementation, and it could introduce
> bugs to change the behavior now.
> Merb, for instance, uses rubygems (which overrides require) as well as
> autoload. Modifying the behavior to use the overridden require now would
> probably produce some changes in behavior, especially since rubygems is in
> common use and overrides require. Rails also overrides require.

Gee. This was only reported over a year ago.

  ruby-core#13143

It's a bug and should be fixed. If other things break b/c of it then
they need to be fixed too. There isn't going to be a better time to
fix it then 1.9, so get it over with.

T.

[ruby-core:20239] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Evan Phoenix wrote:
> 
> On Dec 1, 2008, at 10:36 PM, Yukihiro Matsumoto wrote:
>> This leads another question: should any implementation be affected by
>> basic method replacement, which may make implementation fragile, but
>> more extensible.  For MRI, this is basically protected by calling C
>> functions directly (no dynamic dispatch unless explicitly stated).
>> But for Rubinius, it always use dynamic method calls by definition.
>> The (official) spec will make this "implementation dependent".
> 
> It's a case by case basis. There are certainly places where you want to 
> allow the user to change a method and have it be called. I'm wondering 
> if this is one of those times.
> 
> I don't necessarily see it as making the implementation fragile, since 
> those dynamically invoked methods can do nothing more than a statically 
> invoked method could.
> 
> For now, in Rubinius, we'll go ahead and have Autoload call an internal 
> method that require also calls, to retain compatibility.

Rather than having autoload actually invoke the global require, whatever 
it may be defined as, I think the better change would be the 
long-postponed "require plugin" logic that's been discussed previously. 
Rather than anyone ever needing to redefine require, there should be a 
simple way to add to the require lookup chain with normal Ruby code. 
require overrides have a nasty tendency to break each other, and 
obviously won't fit well into e.g. autoload that wants to make sure it's 
always calling into the "require" that eventually requires files. So 
don't override require, don't make autoload call overridden versions, 
and build in a way to add require plugins without redefining require 
yourself.

It's the right way!

- Charlie

[ruby-core:20257] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Wed, Dec 03, 2008 at 01:50:42PM +0900, Charles Oliver Nutter wrote:
> Rather than having autoload actually invoke the global require, whatever  
> it may be defined as, I think the better change would be the  
> long-postponed "require plugin" logic that's been discussed previously.  
> Rather than anyone ever needing to redefine require, there should be a  
> simple way to add to the require lookup chain with normal Ruby code.  
> require overrides have a nasty tendency to break each other, and  

How would a require plugin avoid this?  It seems to me they would still
be order-dependant.

> obviously won't fit well into e.g. autoload that wants to make sure it's  
> always calling into the "require" that eventually requires files. So  
> don't override require, don't make autoload call overridden versions,  
> and build in a way to add require plugins without redefining require  
> yourself.
>
> It's the right way!
>
> - Charlie

[ruby-core:20258] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Paul Brannan wrote:
> On Wed, Dec 03, 2008 at 01:50:42PM +0900, Charles Oliver Nutter wrote:
>> Rather than having autoload actually invoke the global require, whatever  
>> it may be defined as, I think the better change would be the  
>> long-postponed "require plugin" logic that's been discussed previously.  
>> Rather than anyone ever needing to redefine require, there should be a  
>> simple way to add to the require lookup chain with normal Ruby code.  
>> require overrides have a nasty tendency to break each other, and  
> 
> How would a require plugin avoid this?  It seems to me they would still
> be order-dependant.

require plugins would only advise the require process of additional 
paths, extensions, what have you. They would not perform the actual 
load. Yes, it would still be order dependent, but any plugin in the 
chain could opt out of finding a library and allow the other mechanisms 
to fire.

- Charlie

[ruby-core:20260] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Wed, Dec 03, 2008 at 11:49:49PM +0900, Charles Oliver Nutter wrote:
> require plugins would only advise the require process of additional  
> paths, extensions, what have you. They would not perform the actual  
> load. Yes, it would still be order dependent, but any plugin in the  
> chain could opt out of finding a library and allow the other mechanisms  
> to fire.

How is that different from overriding require, which also allows
opt-out?

Also, I thought on 1.9 rubygems was no longer using the require hook,
but instead modifying $:?  (at least, that's what I remembered coming
out of the discussion at 2007 rubyconf)

Paul

[ruby-core:20264] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Paul Brannan wrote:
> On Wed, Dec 03, 2008 at 11:49:49PM +0900, Charles Oliver Nutter wrote:
>> require plugins would only advise the require process of additional  
>> paths, extensions, what have you. They would not perform the actual  
>> load. Yes, it would still be order dependent, but any plugin in the  
>> chain could opt out of finding a library and allow the other mechanisms  
>> to fire.
> 
> How is that different from overriding require, which also allows
> opt-out?

If someone installs a new require that doesn't call the old one, the 
entire chain breaks. With a plugin, the require process would be pulling 
from the plugins, and a nil result means the next in the chain is tried. 
The only way to stop the sequence would be to successfully return a result.

> Also, I thought on 1.9 rubygems was no longer using the require hook,
> but instead modifying $:?  (at least, that's what I remembered coming
> out of the discussion at 2007 rubyconf)

I don't know.

- Charlie

[ruby-core:20265] Re: Behavior: autoload calls rb_require() directly

[Thomas Enebo]

Dave Thomas wrote:
>
> On Dec 2, 2008, at 1:08 PM, Yehuda Katz wrote:
>
>> However, that is *not* currently the implementation, and it could 
>> introduce bugs to change the behavior now.
>>
>> Merb, for instance, uses rubygems (which overrides require) as well 
>> as autoload. Modifying the behavior to use the overridden require now 
>> would probably produce some changes in behavior, especially since 
>> rubygems is in common use and overrides require. Rails also overrides 
>> require.
>>
>
> And Matz is saying the, if nothing else is agreed, that behavior will 
> be an implementation-detail, and not part of the standard. Wouldn't it 
> be better to swallow a smaller pill now and standardize on _something_?

Absolutely!  Matz pick what you want on this...please :)

One way or the other is reasonable, but changing the behavior from MRI's 
current implementation will break something. Also, the docs say that 
autoloads will be loaded via Kernel#require.   So either the 
documentation is bugged or the implementation is.  A patch should be the 
result of this thread one way or another.

Rubinius could work around this and have an internal_require which would 
not be a method any framework would routinely redefine.    Someone could 
go crazy and override that, but then that would be their funeral.  I 
think Evan is just asking for an answer on this...right Evan?  This is 
not really a limitation of Rubinius.

-Tom

[ruby-core:20267] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Thu, Dec 04, 2008 at 03:01:33AM +0900, Charles Oliver Nutter wrote:
> If someone installs a new require that doesn't call the old one, the  
> entire chain breaks. With a plugin, the require process would be pulling  
> from the plugins, and a nil result means the next in the chain is tried.  
> The only way to stop the sequence would be to successfully return a 
> result.

I'm having trouble imagining code that doesn't call the old require.  I
guess it could use eval() and fix up $" itself, or it could call the C
rb_require().

I've never seen code that does either, though.

Paul

[ruby-core:20301] Re: Behavior: autoload calls rb_require() directly

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20217] Re: Behavior: autoload calls rb_require() directly"
    on Wed, 3 Dec 2008 02:57:13 +0900, Dave Thomas <dave@pragprog.com> writes:

|If you're worried about fragility, then isn't the ability to redefine  
|Fixnum#+ more of an issue?

I mentioned about fragility just because that will be an issue for
Ruby 2.0.  For MRI replacing core methods affect less, just because
core functionality is done by C functions.  But implantation like
Rubinius suffers more.  I think we will soon need to start discussing
separating/protecting core implementation from user code by some kind
of namespaces or packages.

							matz.

[ruby-core:20316] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Yukihiro Matsumoto wrote:
> I mentioned about fragility just because that will be an issue for
> Ruby 2.0.  For MRI replacing core methods affect less, just because
> core functionality is done by C functions.  But implantation like
> Rubinius suffers more.  I think we will soon need to start discussing
> separating/protecting core implementation from user code by some kind
> of namespaces or packages.

I agree. There's no practical reason anyone should be able to override 
Fixnum#+, after all, and protecting the core simplifies implementation 
and optimization too.

- Charlie

[ruby-core:20317] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Fri, Dec 05, 2008 at 03:25:42AM +0900, Charles Oliver Nutter wrote:
> I agree. There's no practical reason anyone should be able to override  
> Fixnum#+, after all, and protecting the core simplifies implementation  
> and optimization too.

I agree.  Not having to check to see if Fixnum#+ is redefined each time
we want to add two integers would be a noticeable performance
improvement.

Paul

[ruby-core:20319] Re: Behavior: autoload calls rb_require() directly

[Trans]

On Dec 4, 1:25 pm, Charles Oliver Nutter <charles.nut...@sun.com>
wrote:
> Yukihiro Matsumoto wrote:
> > I mentioned about fragility just because that will be an issue for
> > Ruby 2.0.  For MRI replacing core methods affect less, just because
> > core functionality is done by C functions.  But implantation like
> > Rubinius suffers more.  I think we will soon need to start discussing
> > separating/protecting core implementation from user code by some kind
> > of namespaces or packages.
>
> I agree. There's no practical reason anyone should be able to override
> Fixnum#+, after all, and protecting the core simplifies implementation
> and optimization too.

Hey, leave my foot alone! I'll shoot it if I dang well want to!

[ruby-core:20321] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Trans wrote:
> Hey, leave my foot alone! I'll shoot it if I dang well want to!

Just for you, I think we should provide a command-line option 
--run-slower-for-Trans.

- Charlie

[ruby-core:20323] Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Dave Thomas]

On Dec 4, 2008, at 1:38 PM, Paul Brannan wrote:

> On Fri, Dec 05, 2008 at 03:25:42AM +0900, Charles Oliver Nutter wrote:
>> I agree. There's no practical reason anyone should be able to  
>> override
>> Fixnum#+, after all, and protecting the core simplifies  
>> implementation
>> and optimization too.
>
> I agree.  Not having to check to see if Fixnum#+ is redefined each  
> time
> we want to add two integers would be a noticeable performance
> improvement.

Please, no.

Every time we do something like this, we add more special cases to the  
language. Right now, classes are open. We allow people to modify their  
behavior. That's just Ruby. Take away plus, and you limit my freedom.  
What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then  
maybe all internal classes get closed, and no one would be able to  
create things such as Symbol.to_proc.

I'd much rather see change going the other way. I'd like to see a =  
"cat" calling String.new. I'd like to see fewer special cases.

If require is broken, then fix it. But don't stop me replacing it if I  
want. And if I replace it incorrectly (making it not thread safe, for  
instance) that then becomes my fault.

Ruby is about choice. If I wanted a language implementor to tell me  
what I can change and what I can't change, I'd use Python or Java.



Dave

[ruby-core:20325] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

Dave Thomas wrote:
> Please, no.
> 
> Every time we do something like this, we add more special cases to the 
> language. Right now, classes are open. We allow people to modify their 
> behavior. That's just Ruby. Take away plus, and you limit my freedom. 
> What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then 
> maybe all internal classes get closed, and no one would be able to 
> create things such as Symbol.to_proc.
> 
> I'd much rather see change going the other way. I'd like to see a = 
> "cat" calling String.new. I'd like to see fewer special cases.
> 
> If require is broken, then fix it. But don't stop me replacing it if I 
> want. And if I replace it incorrectly (making it not thread safe, for 
> instance) that then becomes my fault.
> 
> Ruby is about choice. If I wanted a language implementor to tell me what 
> I can change and what I can't change, I'd use Python or Java.

I can appreciate the "choice is good" argument, but I think the Ruby 
world needs a little less dogmatism about "choice" and "freedom" and 
"beauty". There's practical concerns here, concerns about API stability, 
thread-safety, performance, memory efficiency. Too many of those 
concerns are sacrificed on the altar of "choice" or "freedom".

In the case of core classes, we're not talking about closing them down 
completely; we're talking about guaranteeing to all developers and users 
that some minimum set of methods will do what you expect them to do, now 
and forever. We're guaranteeing that 1 + 1 will continue to == 2. And 
it's not the case where *you* want to override a core method that's the 
problem...it's the case where someone else overrides it--potentially by 
mistake--and you don't find out about it until later.

Ruby needs to grow up as a language by allowing people who want 
guarantees to get guarantees. And there's a lot of people who want some 
minimal, basic guarantees about core classes.

- Charlie

[ruby-core:20326] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Michael Letterle]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

Being able to redefine something as basic as FixNum#+ is something that I
think makes Ruby... well Ruby.  If someone needs to lock it down, can't they
just do something like "require 'strict-fixnum'"?

Sometimes we really want 11 + 3 to = 2... sometimes we want it to = 14.

On Thu, Dec 4, 2008 at 4:41 PM, Charles Oliver Nutter <
charles.nutter@sun.com> wrote:

> Dave Thomas wrote:
>
>> Please, no.
>>
>> Every time we do something like this, we add more special cases to the
>> language. Right now, classes are open. We allow people to modify their
>> behavior. That's just Ruby. Take away plus, and you limit my freedom. What's
>> next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then maybe all
>> internal classes get closed, and no one would be able to create things such
>> as Symbol.to_proc.
>>
>> I'd much rather see change going the other way. I'd like to see a = "cat"
>> calling String.new. I'd like to see fewer special cases.
>>
>> If require is broken, then fix it. But don't stop me replacing it if I
>> want. And if I replace it incorrectly (making it not thread safe, for
>> instance) that then becomes my fault.
>>
>> Ruby is about choice. If I wanted a language implementor to tell me what I
>> can change and what I can't change, I'd use Python or Java.
>>
>
> I can appreciate the "choice is good" argument, but I think the Ruby world
> needs a little less dogmatism about "choice" and "freedom" and "beauty".
> There's practical concerns here, concerns about API stability,
> thread-safety, performance, memory efficiency. Too many of those concerns
> are sacrificed on the altar of "choice" or "freedom".
>
> In the case of core classes, we're not talking about closing them down
> completely; we're talking about guaranteeing to all developers and users
> that some minimum set of methods will do what you expect them to do, now and
> forever. We're guaranteeing that 1 + 1 will continue to == 2. And it's not
> the case where *you* want to override a core method that's the
> problem...it's the case where someone else overrides it--potentially by
> mistake--and you don't find out about it until later.
>
> Ruby needs to grow up as a language by allowing people who want guarantees
> to get guarantees. And there's a lot of people who want some minimal, basic
> guarantees about core classes.
>
> - Charlie
>
>


-- 
Michael Letterle
[Polymath Prokrammer]
http://blog.prokrams.com

[-- Attachment #2: Type: text/html, Size: 3084 bytes --]

[ruby-core:20327] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Pit Capitain]

2008/12/4 Charles Oliver Nutter <charles.nutter@sun.com>:
> I can appreciate the "choice is good" argument, but I think the Ruby world
> needs a little less dogmatism about "choice" and "freedom" and "beauty".
> There's practical concerns here, concerns about API stability,
> thread-safety, performance, memory efficiency. Too many of those concerns
> are sacrificed on the altar of "choice" or "freedom".

And who decides which things are more important than the others? Based
on which criteria? I'd say the Ruby language doesn't need more
dogmatism about things like performance and memory efficiency.

> In the case of core classes, we're not talking about closing them down
> completely; we're talking about guaranteeing to all developers and users
> that some minimum set of methods will do what you expect them to do, now and
> forever. We're guaranteeing that 1 + 1 will continue to == 2.

So I couldn't add some logging or tracing to Fixnum#+? This looks
pretty closed to me.

> And it's not
> the case where *you* want to override a core method that's the
> problem...it's the case where someone else overrides it--potentially by
> mistake--and you don't find out about it until later.

If you want to prevent this, you have to close almost all core
methods. Is this what you are proposing? Why is the current
Fixnum.freeze not enough?

> Ruby needs to grow up as a language by allowing people who want guarantees
> to get guarantees.

Says who? If you want to change Ruby in such a fundamental way, why
should it still be called Ruby?

> And there's a lot of people who want some minimal, basic
> guarantees about core classes.

Do you have any references for this claim? I'm definitely not in this group.

Regards,
Pit

[ruby-core:20328] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20323] Leave my open classes alone (was Behavior: autoload calls rb_require()  directly)"
    on Fri, 5 Dec 2008 06:25:08 +0900, Dave Thomas <dave@pragprog.com> writes:

|Every time we do something like this, we add more special cases to the  
|language. Right now, classes are open. We allow people to modify their  
|behavior. That's just Ruby. Take away plus, and you limit my freedom.  
|What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then  
|maybe all internal classes get closed, and no one would be able to  
|create things such as Symbol.to_proc.

Don't get me wrong.  No matter how Charles agreed, I said I wanted to
separate the namespace, and protect core from "casual" user
modification, but did not intended to freeze anything.  Actually quite
opposite.

Another example is mathn library, which replaces core math operation
in a somewhat useful manner, but introduces serious incompatibility at
the same time.  If we can separate effect of mathn in a region or
namespace, we can live happier with controlled monkey patching.

|I'd much rather see change going the other way. I'd like to see a =  
|"cat" calling String.new. I'd like to see fewer special cases.

Interesting.  if a = "cat" calls String.new, it should take an
(string) argument to initialize the content "cat", then how should the
original content sting be initialized?

							matz.

[ruby-core:20329] Re: Behavior: autoload calls rb_require() directly

[daz]

Charles Oliver Nutter wrote:
 >
 > I agree. There's no practical reason anyone should be able to 
override Fixnum#+, after all, and protecting the core simplifies 
implementation and optimization too.
 >
 > - Charlie
 >
 >

Sorry, that's wrong.

Like Pit just suggested elsewhere in this thread, we can't override to
log (a, :plus, b) then a._oldplus_(b).

The design is short-circuited ... *not* optimized.

A language designer shouldn't test her abilities to second guess what
the user is likely to want or need to do. It's a lost cause. :)


daz

[ruby-core:20330] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

Pit Capitain wrote:
> 2008/12/4 Charles Oliver Nutter <charles.nutter@sun.com>:
>> I can appreciate the "choice is good" argument, but I think the Ruby world
>> needs a little less dogmatism about "choice" and "freedom" and "beauty".
>> There's practical concerns here, concerns about API stability,
>> thread-safety, performance, memory efficiency. Too many of those concerns
>> are sacrificed on the altar of "choice" or "freedom".
> 
> And who decides which things are more important than the others? Based
> on which criteria? I'd say the Ruby language doesn't need more
> dogmatism about things like performance and memory efficiency.

You are entitled to your opinion. :)

>> In the case of core classes, we're not talking about closing them down
>> completely; we're talking about guaranteeing to all developers and users
>> that some minimum set of methods will do what you expect them to do, now and
>> forever. We're guaranteeing that 1 + 1 will continue to == 2.
> 
> So I couldn't add some logging or tracing to Fixnum#+? This looks
> pretty closed to me.

Perhaps you would be able to in a less restrictive mode. Perhaps as 
Michael proposed there could be a library to load for either case, or 
there could be a CLI flag. There's plenty of options to accommodate both 
people who want to monkey-patch core classes and people want to avoid 
the overhead that comes from allowing that monkey-patching.

>> And it's not
>> the case where *you* want to override a core method that's the
>> problem...it's the case where someone else overrides it--potentially by
>> mistake--and you don't find out about it until later.
> 
> If you want to prevent this, you have to close almost all core
> methods. Is this what you are proposing? Why is the current
> Fixnum.freeze not enough?

You would not have to close almost all core methods. And Fixnum.freeze 
closes the whole class, so you're going too far in this comparison.

>> Ruby needs to grow up as a language by allowing people who want guarantees
>> to get guarantees.
> 
> Says who? If you want to change Ruby in such a fundamental way, why
> should it still be called Ruby?

Matz proposed introducing some sort of protection for core code. Whether 
that comes in the form of locking down Fixnum#+ or adding some new 
Fixnum#__ADD__ or namespacing is a detail.

>> And there's a lot of people who want some minimal, basic
>> guarantees about core classes.
> 
> Do you have any references for this claim? I'm definitely not in this group.

If nobody were interested in it, it wouldn't keep coming up. There's 
certainly plenty of references in the ML logs.

FWIW, I don't expect this sort of thing to ever get into core, so the 
JRuby and Ruby 1.9 strategy of watching for changes to core classes is 
probably as close as we will get. And that's ok...in both cases we can 
get very good performance without locking down e.g Fixnum#+. But it 
makes pushing Ruby performance farther than what we have today a lot 
more complicated.

- Charlie

[ruby-core:20333] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[David A. Black]

Hi --

On Fri, 5 Dec 2008, Charles Oliver Nutter wrote:

> Dave Thomas wrote:
>> Please, no.
>> 
>> Every time we do something like this, we add more special cases to the 
>> language. Right now, classes are open. We allow people to modify their 
>> behavior. That's just Ruby. Take away plus, and you limit my freedom. 
>> What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then maybe 
>> all internal classes get closed, and no one would be able to create things 
>> such as Symbol.to_proc.
>> 
>> I'd much rather see change going the other way. I'd like to see a = "cat" 
>> calling String.new. I'd like to see fewer special cases.
>> 
>> If require is broken, then fix it. But don't stop me replacing it if I 
>> want. And if I replace it incorrectly (making it not thread safe, for 
>> instance) that then becomes my fault.
>> 
>> Ruby is about choice. If I wanted a language implementor to tell me what I 
>> can change and what I can't change, I'd use Python or Java.
>
> I can appreciate the "choice is good" argument, but I think the Ruby world 
> needs a little less dogmatism about "choice" and "freedom" and "beauty". 
> There's practical concerns here, concerns about API stability, thread-safety, 
> performance, memory efficiency. Too many of those concerns are sacrificed on 
> the altar of "choice" or "freedom".
>
> In the case of core classes, we're not talking about closing them down 
> completely; we're talking about guaranteeing to all developers and users that 
> some minimum set of methods will do what you expect them to do, now and 
> forever. We're guaranteeing that 1 + 1 will continue to == 2. And it's not 
> the case where *you* want to override a core method that's the problem...it's 
> the case where someone else overrides it--potentially by mistake--and you 
> don't find out about it until later.
>
> Ruby needs to grow up as a language by allowing people who want guarantees to 
> get guarantees. And there's a lot of people who want some minimal, basic 
> guarantees about core classes.

It's not a growing-up thing, though. The freedom of Ruby isn't the
freedom of an undisciplined or pre-socialized child; it's an informed,
elective, adult state.

For me, this particular issue comes down to a simple point of logic --
namely, that exactly one of the following statements must be true:

   1. There should never be a computer language that has fully open,
      changeable built-in classes; or,
   2. There should be one or more such languages, but Ruby should not
      be one of them.
   3. There should be one or more such languages, and Ruby should be
      one of them.

If #3 is not true, then either #1 or #2 is true, and I don't believe
either of them is. If Ruby does away with its openness, then another
language will come along that implements that openness. So why not
just break the cycle, and decide that Ruby *is* the language that has
come along?


David

-- 
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS (Jan 12-15), Fort Lauderdale, FL
See http://www.rubypal.com for details
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

[ruby-core:20334] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

Yukihiro Matsumoto wrote:
> Don't get me wrong.  No matter how Charles agreed, I said I wanted to
> separate the namespace, and protect core from "casual" user
> modification, but did not intended to freeze anything.  Actually quite
> opposite.
> 
> Another example is mathn library, which replaces core math operation
> in a somewhat useful manner, but introduces serious incompatibility at
> the same time.  If we can separate effect of mathn in a region or
> namespace, we can live happier with controlled monkey patching.

I in no way meant to characterize what you suggested as being 
core-freezing; that was just another aspect of API protection worth 
discussing. The concerns of e.g. mathn and rational and others are well 
known, especially to those working on Rubinius who saw the kernel blow 
up when libraries redefined numeric methods.

I'll go on the record here and say that as much as it would help 
implementers if there were a minimal subset of core methods that never 
changed, I'd never reasonably expect Ruby to do that. We've gone out of 
our way working on JRuby to support as much of Ruby as possible, even to 
the point of crippling performance in many cases. The tricks 1.9 and 
JRuby use currently to check if core methods have changed is sufficient 
for "very good" performance, and in JRuby those checks will often be 
optimized away by the JVM. So it's not that big a deal if we never lock 
down any core methods.

But it would help make performance even better :)

- Charlie

[ruby-core:20335] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

daz wrote:
> Sorry, that's wrong.
> 
> Like Pit just suggested elsewhere in this thread, we can't override to
> log (a, :plus, b) then a._oldplus_(b).
> 
> The design is short-circuited ... *not* optimized.
> 
> A language designer shouldn't test her abilities to second guess what
> the user is likely to want or need to do. It's a lost cause. :)

I wasn't speaking as a language designer or an implementer; I was 
speaking as someone who'd like to be able to get C-like performance out 
of numeric operations in Ruby some day. Yes, it's still possible. But so 
is draining the ocean with an eyedropper.

- Charlie

[ruby-core:20336] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

David A. Black wrote:
> It's not a growing-up thing, though. The freedom of Ruby isn't the
> freedom of an undisciplined or pre-socialized child; it's an informed,
> elective, adult state.
> 
> For me, this particular issue comes down to a simple point of logic --
> namely, that exactly one of the following statements must be true:
> 
>   1. There should never be a computer language that has fully open,
>      changeable built-in classes; or,
>   2. There should be one or more such languages, but Ruby should not
>      be one of them.
>   3. There should be one or more such languages, and Ruby should be
>      one of them.
> 
> If #3 is not true, then either #1 or #2 is true, and I don't believe
> either of them is. If Ruby does away with its openness, then another
> language will come along that implements that openness. So why not
> just break the cycle, and decide that Ruby *is* the language that has
> come along?

Because it isn't today. It might be more open tomorrow, or it might be 
more closed tomorrow. But this isn't a black-and-white issue, and saying 
that core class methods provide certain guarantees about behavior does 
not mean making things any more closed.

Here's an example...JRuby doesn't have ObjectSpace enabled by default. 
You can turn it on, and it works fine, but you pay a performance penalty 
to allow all objects in the system to be walkable. When we mentioned we 
were going to have ObjectSpace off by default, a bunch of people raised 
a fit. And since we started releasing versions of JRuby with ObjectSpace 
disabled, we've received basically zero bug reports or complaints about it.

You *can* make changes that at first glance seem fundamentally 
"anti-Ruby" without hurting anyone's real-world use of Ruby. So we 
shouldn't have a knee-jerk policy against such changes...they should be 
carefully considered rather than rejected out of hand.

- Charlie

[ruby-core:20337] Re: Behavior: autoload calls rb_require() directly

[Neil Stevens]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Charles Oliver Nutter wrote:
> daz wrote:
>> Sorry, that's wrong.
>>
>> Like Pit just suggested elsewhere in this thread, we can't override to
>> log (a, :plus, b) then a._oldplus_(b).
>>
>> The design is short-circuited ... *not* optimized.
>>
>> A language designer shouldn't test her abilities to second guess what
>> the user is likely to want or need to do. It's a lost cause. :)
> 
> I wasn't speaking as a language designer or an implementer; I was
> speaking as someone who'd like to be able to get C-like performance out
> of numeric operations in Ruby some day. Yes, it's still possible. But so
> is draining the ocean with an eyedropper.

Yup.  Using the wrong tool for a job is usually inefficient.

There are already languages out there that sacrifice flexibility in
order to give efficiency for niche tasks.  I don't understand why Ruby
should start to become one of them.
-- 
Neil Stevens - neil@hakubi.us

If you're seeing shades of gray, it's because you're not
looking close enough to see the black and white dots.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

[ruby-core:20338] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Neil Stevens wrote:
>> I wasn't speaking as a language designer or an implementer; I was
>> speaking as someone who'd like to be able to get C-like performance out
>> of numeric operations in Ruby some day. Yes, it's still possible. But so
>> is draining the ocean with an eyedropper.
> 
> Yup.  Using the wrong tool for a job is usually inefficient.
> 
> There are already languages out there that sacrifice flexibility in
> order to give efficiency for niche tasks.  I don't understand why Ruby
> should start to become one of them.

I don't see why Ruby couldn't someday be the right tool for the job.

- Charlie

[ruby-core:20341] Re: Behavior: autoload calls rb_require() directly

[Michael Selig]

On Fri, 05 Dec 2008 09:58:02 +1100, Charles Oliver Nutter  
<charles.nutter@sun.com> wrote:

> I wasn't speaking as a language designer or an implementer; I was  
> speaking as someone who'd like to be able to get C-like performance out  
> of numeric operations in Ruby some day. Yes, it's still possible. But so  
> is draining the ocean with an eyedropper.

Not being a "compiled to machine code" language, it seems impossible to me  
that operations like Fixnum#+ will ever have "C-like performance". But is  
is a nice goal I guess :)

However there are other ways to achieve this sort of thing, by providing  
higher-level specialized classes (like Matrix) which are (or could be)  
coded in C. Such libraries can be used by, for example, numerical analysis  
applications to (hopefully) provide the speed required.

IMHO for most Ruby applications, not doing things like numerical analysis,  
it doesn't matter all that much if Fixnum#+ et al. don't have "C-like  
performance".

Cheers
Mike

[ruby-core:20343] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Paul Brannan]

On Fri, Dec 05, 2008 at 06:25:08AM +0900, Dave Thomas wrote:
> Please, no.
>
> Every time we do something like this, we add more special cases to the  
> language. Right now, classes are open. We allow people to modify their  
> behavior. That's just Ruby. Take away plus, and you limit my freedom.  
> What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then  
> maybe all internal classes get closed, and no one would be able to  
> create things such as Symbol.to_proc.

Is there a use case where redefining Fixnum#+ actually solves a
real-world problem?

There are other operations in Ruby that we can't override (logical and
and logical or, for example).  While this means Ruby is less flexible
than it could be, the missing flexibility does not mean missing
usability or expressiveness.

> I'd much rather see change going the other way. I'd like to see a =  
> "cat" calling String.new. I'd like to see fewer special cases.

Something like this was tried with arrays in the 1.7 series, but
performance was significantly degraded relative to 1.6.  Maybe now that
we have a faster VM we could do this (and avoid the method dispatch
using the same trick as for Fixnum#+).  IIRC though it also caused other
problems (it was difficult to override Array.allocate correctly, without
causing an infinite loop, because it could easily be called implicitly).

> If require is broken, then fix it. But don't stop me replacing it if I  
> want. And if I replace it incorrectly (making it not thread safe, for  
> instance) that then becomes my fault.

Did someone suggest this?  If so I missed it.

> Ruby is about choice. If I wanted a language implementor to tell me what 
> I can change and what I can't change, I'd use Python or Java.

Ruby is also about expressiveness and readability.  Often having too
many choices affects culture in undesirable ways.  Perl's motto of
"there's more than one way to do it" actually decreases readability
rather than improving it.

I'm all for choice, but not without weighing the consequences.  In the
particular case of Fixnum#+, I feel the cost outweighs the benefit.

Paul

[ruby-core:20344] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Michael Selig wrote:
> Not being a "compiled to machine code" language, it seems impossible to 
> me that operations like Fixnum#+ will ever have "C-like performance". 
> But is is a nice goal I guess :)

JRuby, via the JVM, already does compile Ruby to machine code. The JVM 
takes the bytecode we generate and JIT compiles it into real machine 
code, inlining a significant amount of logic and optimizing everything 
together. I can certainly show you what the assembly looks like, if 
you're interested. Currently there's a few things we *don't* do that 
will make this JITing even more effective in the future:

* We don't have any special logic to optionally treat Fixnums as normal 
primitive ints under controlled conditions. Doing so would allow the JVM 
to JIT it straight down to optimized machine-level math operations.
* We don't make it possible to inline across dynamic calls. Doing so 
would allow many levels of calls in Ruby to be inlined together and 
optimized as a whole.

The optimizations that result from inlining include array boundscheck 
eliminations, escape analysis to eliminate object allocation cost, loop 
unrolling and elimination, and a lot more.

All these optimizations are predicated on arriving at a static view of 
the world at some point during execution. The ability to redefine 
Fixnum#+, for example, means that we'll always need (at minimum) a guard 
against + being overridden. If it's possible to eliminate the need for 
those guards, our the potential for a static worldview expands, the 
generated code gets smaller, and performance increases.

We plan to add both of the above changes in upcoming versions of JRuby, 
with all the appropriate guards in place to allow Ruby to remain Ruby. 
But I think it's useful to know what you sacrifice by having an 
infinitely mutable set of core classes.

> However there are other ways to achieve this sort of thing, by providing 
> higher-level specialized classes (like Matrix) which are (or could be) 
> coded in C. Such libraries can be used by, for example, numerical 
> analysis applications to (hopefully) provide the speed required.
> 
> IMHO for most Ruby applications, not doing things like numerical 
> analysis, it doesn't matter all that much if Fixnum#+ et al. don't have 
> "C-like performance".

Certainly true. But it would be nice if you could get that performance 
when you need it.

- Charlie

[ruby-core:20346] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Trans]

On Dec 4, 6:56 pm, Paul Brannan <pbran...@atdesk.com> wrote:

> Ruby is also about expressiveness and readability.  Often having too
> many choices affects culture in undesirable ways.  Perl's motto of
> "there's more than one way to do it" actually decreases readability
> rather than improving it.
>
> I'm all for choice, but not without weighing the consequences.  In the
> particular case of Fixnum#+, I feel the cost outweighs the benefit.

Think out loud a bit here... Needless to say I'm in the camp of
maximum openness. I believe it is *the* feature that distinguishes
Ruby, and I think David Black's comment was very elegantly put.

But as Charles has suggested, maybe we can have our cake and eat it
too?

What if every class had a "Kernel" parent, in the same way that Object
has Kernel (though these "Kernels" might instead be super classes
instead of modules, I'm not sure which is best).  While the class
itself can be overridden, the "Kernels" cannot. If the class is
overridden, a flag is set so one can easily check. Likewise Kernel
itself would be locked down, but Object still open.

Would something like that do the trick?

T.

[ruby-core:20348] Re: Behavior: autoload calls rb_require() directly

[daz]

Charles Oliver Nutter wrote:
> 
   <snip>

> But it would be nice if you could get that performance when you need it.
> 
> - Charlie
> 
> 

So ...

Critical Error at line 42 - Attempt to redefine xxxxx while
  JRpragma "no-slow-core" (or JRopt "O3") is in effect.

and/or ...

Helpful message #28: This program could run 3.5 times faster
  by using the JRpragma "fast-core" (or JRopt "O3") option.


?


Daz

[ruby-core:20349] Re: Behavior: autoload calls rb_require() directly

[Michael Selig]

On Fri, 05 Dec 2008 11:56:19 +1100, Charles Oliver Nutter  
<charles.nutter@sun.com> wrote:

> All these optimizations are predicated on arriving at a static view of  
> the world at some point during execution. The ability to redefine  
> Fixnum#+, for example, means that we'll always need (at minimum) a guard  
> against + being overridden.

I know nothing about JRuby, so pardon my ignorance if I have got it all  
wrong, but I figure that in order to optimize an expression like "a + b"  
in a loop to an integer addition, at some point before the loop you need  
to establish that both "a" & "b" are Fixnums, and are going to stay  
Fixnums for the duration of the loop. Only then you know that the "+" is  
actually Fixnum#+, and that the method can be optimized to an integer  
addition (unless "+" has been overridden). Assuming that is possible, then  
at that time can't you also establish that Fixnum#+ isn't overridden, and  
won't be during the loop?

Cheers
Mike

[ruby-core:20350] Re: Behavior: autoload calls rb_require() directly

[Thomas Enebo]

Michael Selig wrote:
> On Fri, 05 Dec 2008 11:56:19 +1100, Charles Oliver Nutter 
> <charles.nutter@sun.com> wrote:
>
>> All these optimizations are predicated on arriving at a static view 
>> of the world at some point during execution. The ability to redefine 
>> Fixnum#+, for example, means that we'll always need (at minimum) a 
>> guard against + being overridden.
>
> I know nothing about JRuby, so pardon my ignorance if I have got it 
> all wrong, but I figure that in order to optimize an expression like 
> "a + b" in a loop to an integer addition, at some point before the 
> loop you need to establish that both "a" & "b" are Fixnums, and are 
> going to stay Fixnums for the duration of the loop. Only then you know 
> that the "+" is actually Fixnum#+, and that the method can be 
> optimized to an integer addition (unless "+" has been overridden). 
> Assuming that is possible, then at that time can't you also establish 
> that Fixnum#+ isn't overridden, and won't be during the loop?
With everything you assumed you also have to consider that Ruby/JRuby 
has multiple executing threads.

-Tom

[ruby-core:20351] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

daz wrote:
> So ...
> 
> Critical Error at line 42 - Attempt to redefine xxxxx while
>  JRpragma "no-slow-core" (or JRopt "O3") is in effect.
> 
> and/or ...
> 
> Helpful message #28: This program could run 3.5 times faster
>  by using the JRpragma "fast-core" (or JRopt "O3") option.

Yes, some of these kinds of things are already in JRuby, such as a 
"fastops" flag to turn on fast math operations or a "threadless" mode 
that doesn't do checks for critical/raise/kill. I'm building in all 
these options as we go so people have the option of turning certain 
performance-killing features off. And so far, people are often glad to 
have them.

- Charlie

[ruby-core:20352] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Michael Selig wrote:
> On Fri, 05 Dec 2008 11:56:19 +1100, Charles Oliver Nutter 
> <charles.nutter@sun.com> wrote:
> 
>> All these optimizations are predicated on arriving at a static view of 
>> the world at some point during execution. The ability to redefine 
>> Fixnum#+, for example, means that we'll always need (at minimum) a 
>> guard against + being overridden.
> 
> I know nothing about JRuby, so pardon my ignorance if I have got it all 
> wrong, but I figure that in order to optimize an expression like "a + b" 
> in a loop to an integer addition, at some point before the loop you need 
> to establish that both "a" & "b" are Fixnums, and are going to stay 
> Fixnums for the duration of the loop. Only then you know that the "+" is 
> actually Fixnum#+, and that the method can be optimized to an integer 
> addition (unless "+" has been overridden). Assuming that is possible, 
> then at that time can't you also establish that Fixnum#+ isn't 
> overridden, and won't be during the loop?

In simple cases, you can. However a general solution doesn't necessarily 
work, since the purpose of that loop could be to define new methods. Of 
course if you can analyze everything infinitely deep, you can learn all 
you need to know.

In JRuby currently we only do simple inline caching, like 1.9 does. 
However we compile code lazily, so it is possible for us to know at 
compile time that a given method has only ever been called on Fixnum, 
and add a guarded *static* call along with the dynamic path. I've 
prototyped this and it helps performance quite a bit; the JVM is able to 
optimize those calls directly.

We can look at this in terms of two extremes. On the one hand, 
everything is static and can be optimized completely via static 
analysis. On the other hand, everything is dynamic and static analysis 
gets you get little. In that case, we need dynamic optimization to get 
the best performance. So we watch, we profile, we record everything 
happening at runtime and as things settle down we can make static 
analysis against that new information. The cost of having the core 
classes totally mutable is that in addition to generating optimized 
logic, we have to also generate bail-out logic.

We're still experimenting with the next steps to take for JRuby, but I 
think we can get dynamic calls inlining very soon.

- Charlie

[ruby-core:20353] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Dave Thomas]

On Dec 4, 2008, at 4:40 PM, Yukihiro Matsumoto wrote:

> Interesting.  if a = "cat" calls String.new, it should take an
> (string) argument to initialize the content "cat", then how should the
> original content sting be initialized?

Ah, got me :)...

Except....

It seems to me that there is a set of basic types which sit below  
types such as fixnum and string. They're the raw data that the lexer  
and parser deal with. What makes them _Ruby_ numbers and strings is  
when that raw data gets wrapped up snugly inside a Ruby class.

So, I think there's some merit in having the turn "cat" into some kind  
of basic character sequence, and passing that to String.new.

Maybe...


Dave

[ruby-core:20354] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Fri, Dec 05, 2008 at 09:56:19AM +0900, Charles Oliver Nutter wrote:
> All these optimizations are predicated on arriving at a static view of  
> the world at some point during execution. The ability to redefine  
> Fixnum#+, for example, means that we'll always need (at minimum) a guard  
> against + being overridden. If it's possible to eliminate the need for  
> those guards, our the potential for a static worldview expands, the  
> generated code gets smaller, and performance increases.

Instead of using guards you can recompile the world if someone ever
does override Fixnum#+.  I guess this means slightly higher memory
consumption, since some representation of the function needs to be kept
around just in case.

Paul

[ruby-core:20355] Re: Behavior: autoload calls rb_require() directly

[Tomas Matousek]

Except for the frames that are already on stack... that's not so easy.

Tomas

-----Original Message-----
From: Paul Brannan [mailto:pbrannan@atdesk.com]
Sent: Thursday, December 04, 2008 7:26 PM
To: ruby-core@ruby-lang.org
Subject: [ruby-core:20354] Re: Behavior: autoload calls rb_require() directly

On Fri, Dec 05, 2008 at 09:56:19AM +0900, Charles Oliver Nutter wrote:
> All these optimizations are predicated on arriving at a static view of
> the world at some point during execution. The ability to redefine
> Fixnum#+, for example, means that we'll always need (at minimum) a guard
> against + being overridden. If it's possible to eliminate the need for
> those guards, our the potential for a static worldview expands, the
> generated code gets smaller, and performance increases.

Instead of using guards you can recompile the world if someone ever
does override Fixnum#+.  I guess this means slightly higher memory
consumption, since some representation of the function needs to be kept
around just in case.

Paul

[ruby-core:20356] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Yes, deoptimization is the hard case; compiling, recompiling, even 
inlining are easy. We will certainly look at iterative compilation, but 
without deopt we can't get far.

The more logical thing for JRuby is to just line all the pieces up so 
that the JVM can optimize it. The JVM (OpenJDK's HotSpot, at least) 
*does* do deopt, profiled optimization, inlining, and iterative 
compilation. At this point we will slowly move Ruby code closer and 
closer to an ideal optimizable path for the JVM, and performance will 
continue to improve with every release.

Tomas Matousek wrote:
> Except for the frames that are already on stack... that's not so easy.
> 
> Tomas
> 
> -----Original Message-----
> From: Paul Brannan [mailto:pbrannan@atdesk.com]
> Sent: Thursday, December 04, 2008 7:26 PM
> To: ruby-core@ruby-lang.org
> Subject: [ruby-core:20354] Re: Behavior: autoload calls rb_require() directly
> 
> On Fri, Dec 05, 2008 at 09:56:19AM +0900, Charles Oliver Nutter wrote:
>> All these optimizations are predicated on arriving at a static view of
>> the world at some point during execution. The ability to redefine
>> Fixnum#+, for example, means that we'll always need (at minimum) a guard
>> against + being overridden. If it's possible to eliminate the need for
>> those guards, our the potential for a static worldview expands, the
>> generated code gets smaller, and performance increases.
> 
> Instead of using guards you can recompile the world if someone ever
> does override Fixnum#+.  I guess this means slightly higher memory
> consumption, since some representation of the function needs to be kept
> around just in case.
> 
> Paul
> 
> 
> 
> 

[ruby-core:20357] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Jeremy McAnally]

Soooo basically you're advocating a Python-like object tree, which is
the single trait about Python's language features that makes me burn
with rage.

"Hey we're totally dynamic OO broo ha ha from top-to-bottom!!
Except...er...these few things...and uh...well there are these other
things too...that...don't really...uh...go in the same box..."

--Jeremy

On Thu, Dec 4, 2008 at 7:38 PM, Trans <transfire@gmail.com> wrote:
>
>
> On Dec 4, 6:56 pm, Paul Brannan <pbran...@atdesk.com> wrote:
>
>> Ruby is also about expressiveness and readability.  Often having too
>> many choices affects culture in undesirable ways.  Perl's motto of
>> "there's more than one way to do it" actually decreases readability
>> rather than improving it.
>>
>> I'm all for choice, but not without weighing the consequences.  In the
>> particular case of Fixnum#+, I feel the cost outweighs the benefit.
>
> Think out loud a bit here... Needless to say I'm in the camp of
> maximum openness. I believe it is *the* feature that distinguishes
> Ruby, and I think David Black's comment was very elegantly put.
>
> But as Charles has suggested, maybe we can have our cake and eat it
> too?
>
> What if every class had a "Kernel" parent, in the same way that Object
> has Kernel (though these "Kernels" might instead be super classes
> instead of modules, I'm not sure which is best).  While the class
> itself can be overridden, the "Kernels" cannot. If the class is
> overridden, a flag is set so one can easily check. Likewise Kernel
> itself would be locked down, but Object still open.
>
> Would something like that do the trick?
>
> T.
>
>



-- 
http://jeremymcanally.com/
http://entp.com/
http://omgbloglol.com

My books:
http://manning.com/mcanally/
http://humblelittlerubybook.com/ (FREE!)

[ruby-core:20359] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Bill Kelly]

    
From: "Jeremy McAnally" <jeremymcanally@gmail.com>
>
> Soooo basically you're advocating a Python-like object tree, which is
> the single trait about Python's language features that makes me burn
> with rage.

I think, rather, that Trans was wanting Ruby to be just as open as it
currently is, but he was looking for a way to quickly detect whether
any crucial class methods have been overridden, that could be used
behind the scenes to make decisions about optimization.


(?)


Regards,

Bill

[ruby-core:20366] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[David A. Black]

HriI --

On Fri, 5 Dec 2008, Charles Oliver Nutter wrote:

> David A. Black wrote:
>> It's not a growing-up thing, though. The freedom of Ruby isn't the
>> freedom of an undisciplined or pre-socialized child; it's an informed,
>> elective, adult state.
>> 
>> For me, this particular issue comes down to a simple point of logic --
>> namely, that exactly one of the following statements must be true:
>>
>>   1. There should never be a computer language that has fully open,
>>      changeable built-in classes; or,
>>   2. There should be one or more such languages, but Ruby should not
>>      be one of them.
>>   3. There should be one or more such languages, and Ruby should be
>>      one of them.
>> 
>> If #3 is not true, then either #1 or #2 is true, and I don't believe
>> either of them is. If Ruby does away with its openness, then another
>> language will come along that implements that openness. So why not
>> just break the cycle, and decide that Ruby *is* the language that has
>> come along?
>
> Because it isn't today. It might be more open tomorrow, or it might be more 
> closed tomorrow. But this isn't a black-and-white issue, and saying that core 
> class methods provide certain guarantees about behavior does not mean making 
> things any more closed.
>
> Here's an example...JRuby doesn't have ObjectSpace enabled by default. You 
> can turn it on, and it works fine, but you pay a performance penalty to allow 
> all objects in the system to be walkable. When we mentioned we were going to 
> have ObjectSpace off by default, a bunch of people raised a fit. And since we 
> started releasing versions of JRuby with ObjectSpace disabled, we've received 
> basically zero bug reports or complaints about it.
>
> You *can* make changes that at first glance seem fundamentally "anti-Ruby" 
> without hurting anyone's real-world use of Ruby. So we shouldn't have a 
> knee-jerk policy against such changes...they should be carefully considered 
> rather than rejected out of hand.

The danger, though, is of enshrining what people have done so far with
Ruby as being the permanent comfort zone of the language. It reminds
me of the thing where the administration of a college wait until
enough people have walked across the grass along a certain path, so
that there's just dirt, and then, having seen where people walk, they
pave that route and put a "Keep off the grass" sign on the rest :-) I
know no one is talking about that degree of change, but I do think
there's a risk to trying to decide or delimit the real-world practices
up front.

Mind you, I am personally very conservative about making core changes.
I tend to advocate #extend as the best way to change the behavior of
an instance of a core class. My kid-in-a-candy-store days are long
behind me :-)


David

-- 
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS (Jan 12-15), Fort Lauderdale, FL
See http://www.rubypal.com for details
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

[ruby-core:20367] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Trans]

On Dec 5, 1:36 am, "Bill Kelly" <bi...@cts.com> wrote:
> From: "Jeremy McAnally" <jeremymcana...@gmail.com>
>
>
>
> > Soooo basically you're advocating a Python-like object tree, which is
> > the single trait about Python's language features that makes me burn
> > with rage.
>
> I think, rather, that Trans was wanting Ruby to be just as open as it
> currently is,

Yes. And hopefully even more open. I've written code were I wanted to
redefine ||, &&, !, etc, within special contexts.

> but he was looking for a way to quickly detect whether
> any crucial class methods have been overridden, that could be used
> behind the scenes to make decisions about optimization.

Precisely. My thinking-out-load was that the isolation of core static
code into "Kernels" made a useful delineation for easily determining
optimizations:

  optimize_methods = Fixnum::Kernel.instance_methods(false) -
Fixnum.instance_methods(false)

And overrides more elegantly written:

  class Fixnum
    def +(a,b)
      puts "adding"
      super
    end
  end

T.

[ruby-core:20373] Re: Behavior: autoload calls rb_require() directly

[Paul Brannan]

On Fri, Dec 05, 2008 at 12:31:36PM +0900, Tomas Matousek wrote:
> Except for the frames that are already on stack... that's not so easy.
> 
> Tomas

Yes, that's (very) difficult, but not impossible (method return needs to
be a little bit smarter).

Paul

[ruby-core:20377] Re: Behavior: autoload calls rb_require() directly

[Ken Bloom]

On Fri, 05 Dec 2008 03:25:42 +0900, Charles Oliver Nutter wrote:

> Yukihiro Matsumoto wrote:
>> I mentioned about fragility just because that will be an issue for Ruby
>> 2.0.  For MRI replacing core methods affect less, just because core
>> functionality is done by C functions.  But implantation like Rubinius
>> suffers more.  I think we will soon need to start discussing
>> separating/protecting core implementation from user code by some kind
>> of namespaces or packages.
> 
> I agree. There's no practical reason anyone should be able to override
> Fixnum#+, after all, and protecting the core simplifies implementation
> and optimization too.
> 
> - Charlie

There's plenty of reasons why someone might want to override Fixnum#+.

First: mathn.rb overrides Fixnum#/, and that's in the standard library

Second: many people had the same argument that there was no practical 
reason to override the != operator separately from the == operator. It's 
something I wanted to do for DSL support (specifically, turning a block 
into an s-expression and then from there into SQL). Thankfully, this 
reasoning won out in Ruby 1.9 where I can now override != and !. (As it 
happens, my sexp19.rb does override Fixnum#/ for just this reason.)



-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[ruby-core:20378] Re: Behavior: autoload calls rb_require() directly

[Ken Bloom]

On Thu, 04 Dec 2008 16:51:10 +0900, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: [ruby-core:20217] Re: Behavior: autoload calls
> rb_require() directly"
>     on Wed, 3 Dec 2008 02:57:13 +0900, Dave Thomas <dave@pragprog.com>
>     writes:
> 
> |If you're worried about fragility, then isn't the ability to redefine
> |Fixnum#+ more of an issue?
> 
> I mentioned about fragility just because that will be an issue for Ruby
> 2.0.  For MRI replacing core methods affect less, just because core
> functionality is done by C functions.  But implantation like Rubinius
> suffers more.  I think we will soon need to start discussing
> separating/protecting core implementation from user code by some kind of
> namespaces or packages.
> 
> 							matz.

Actually, you can already see this kind of fragility in irb. There are 
lots of things that I might redefine while working in IRB, just because I 
want to see how they work. If they break something IRB depends on, then 
IRB will throw an exception and exit immediately.

The simplest case I can think of at the moment:
[bloom@cat-in-the-hat ~]$ irb
irb(main):001:0> $SAFE=4
/usr/lib/ruby/1.8/irb.rb:265:in `signal_status': Insecure: can't modify 
instance variable (SecurityError)
	from /usr/lib/ruby/1.8/irb.rb:147:in `eval_input'
	from /usr/lib/ruby/1.8/irb/ruby-lex.rb:244:in 
`each_top_level_statement'
	from /usr/lib/ruby/1.8/irb/ruby-lex.rb:230:in `loop'
	from /usr/lib/ruby/1.8/irb/ruby-lex.rb:230:in 
`each_top_level_statement'
	from /usr/lib/ruby/1.8/irb/ruby-lex.rb:229:in `catch'
	from /usr/lib/ruby/1.8/irb/ruby-lex.rb:229:in 
`each_top_level_statement'
	from /usr/lib/ruby/1.8/irb.rb:146:in `eval_input'
	from /usr/lib/ruby/1.8/irb.rb:70:in `start'
	from /usr/lib/ruby/1.8/irb.rb:69:in `catch'
	from /usr/lib/ruby/1.8/irb.rb:69:in `start'
	from /usr/bin/irb:13
[bloom@cat-in-the-hat ~]$ 



-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[ruby-core:20380] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20343] Re: Leave my open classes alone (was Behavior: autoload calls	rb_require()  directly)"
    on Fri, 5 Dec 2008 08:56:44 +0900, Paul Brannan <pbrannan@atdesk.com> writes:

|Is there a use case where redefining Fixnum#+ actually solves a
|real-world problem?

I know none for Fixnum#+ bu mathn uses Fixnum#/ replacement, and it is
useful (though incompatible and somewhat dangerous). 

							matz.
 

[ruby-core:20381] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Paul Brannan wrote:
> On Fri, Dec 05, 2008 at 12:31:36PM +0900, Tomas Matousek wrote:
>> Except for the frames that are already on stack... that's not so easy.
>>
>> Tomas
> 
> Yes, that's (very) difficult, but not impossible (method return needs to
> be a little bit smarter).

Well, it's more than that; at any point you need to be able to branch 
back into unoptimized code, since your assumptions are no longer valid. 
The JVM does this by putting guards around all inlined calls that have a 
potential to change later on.

- Charlie

[ruby-core:20382] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Evan Phoenix]

I see my simple little question has ruffled feathers in the hen house  
again!

One aspect I'd feel remiss if I didn't mention was the extend to Ruby  
is already not dynamic. Trans brings up a few below, and I guess I'm  
hearing that 1.9 allows you to change != independent of ==?

Dave brought up the idea that a string literal '"cat"' would boil down  
to an invocation of String.new. In Rubinius, '{ 1 => 2 }' is literally  
shorthand for 'Hash[1,2]'.

My point is that there is set of essentially static features already,  
and so the question is how did they become static and should they  
remain static.

I'd imagine that are static in MRI for performance and simplicity, a  
decision if not made at least approved by Matz. So now we've reached a  
crossroads in the ruby community, where Matz has begun to reevaluate  
which of those static features should be static or not.

The point of my initial question was "is autoload calling rb_require()  
a designed static feature or an accidental static feature?" Matz  
answered it, I think, in a round about way that it's an accidental  
static feature.

So, I think this is a very healthy discussion, because it emphasizes  
one of my favorite features of the ruby community, the ability to  
evolve and move forward. But I think that the final word on a lot of  
these questions lives with Matz. A programming language is all about  
managing expectations and assumptions, and to be consistent, I believe  
that Matz has to hand down decisions on things like this.

  - Evan Phoenix

On Dec 5, 2008, at 3:24 AM, Trans wrote:

>
>
> On Dec 5, 1:36 am, "Bill Kelly" <bi...@cts.com> wrote:
>> From: "Jeremy McAnally" <jeremymcana...@gmail.com>
>>
>>
>>
>>> Soooo basically you're advocating a Python-like object tree, which  
>>> is
>>> the single trait about Python's language features that makes me burn
>>> with rage.
>>
>> I think, rather, that Trans was wanting Ruby to be just as open as it
>> currently is,
>
> Yes. And hopefully even more open. I've written code were I wanted to
> redefine ||, &&, !, etc, within special contexts.
>
>> but he was looking for a way to quickly detect whether
>> any crucial class methods have been overridden, that could be used
>> behind the scenes to make decisions about optimization.
>
> Precisely. My thinking-out-load was that the isolation of core static
> code into "Kernels" made a useful delineation for easily determining
> optimizations:
>
>  optimize_methods = Fixnum::Kernel.instance_methods(false) -
> Fixnum.instance_methods(false)
>
> And overrides more elegantly written:
>
>  class Fixnum
>    def +(a,b)
>      puts "adding"
>      super
>    end
>  end
>
> T.
>

[ruby-core:20383] Re: Behavior: autoload calls rb_require() directly

[Tomas Matousek]

But this only means we are missing a sandbox feature. If there was a simple way how to create a new sandboxed environment and execute a Ruby script within it and then remotely inspect the results then irb could use that.

BTW: You can do it in IronRuby: :)

irb(main):001:0>
irb(main):002:0> load_assembly 'IronRuby'
=> true
irb(main):003:0> include IronRuby
=> Object
irb(main):004:0> engine = Ruby.create_engine
=> #<Microsoft::Scripting::Hosting::ScriptEngine:0x00001e8>
irb(main):005:0> engine.execute '
irb(main):006:0'   class Fixnum
irb(main):007:0'     def + other
irb(main):008:0'       self - other
irb(main):009:0'     end
irb(main):010:0'   end
irb(main):011:0' '
=> nil
irb(main):012:0> 1+2
=> 3
irb(main):013:0> engine.execute '1+2'
=> -1
irb(main):014:0>

Tomas

-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Ken Bloom
Sent: Friday, December 05, 2008 8:32 AM
To: ruby-core@ruby-lang.org
Subject: [ruby-core:20378] Re: Behavior: autoload calls rb_require() directly

On Thu, 04 Dec 2008 16:51:10 +0900, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: [ruby-core:20217] Re: Behavior: autoload calls
> rb_require() directly"
>     on Wed, 3 Dec 2008 02:57:13 +0900, Dave Thomas <dave@pragprog.com>
>     writes:
>
> |If you're worried about fragility, then isn't the ability to redefine
> |Fixnum#+ more of an issue?
>
> I mentioned about fragility just because that will be an issue for Ruby
> 2.0.  For MRI replacing core methods affect less, just because core
> functionality is done by C functions.  But implantation like Rubinius
> suffers more.  I think we will soon need to start discussing
> separating/protecting core implementation from user code by some kind of
> namespaces or packages.
>
>                                                       matz.

Actually, you can already see this kind of fragility in irb. There are
lots of things that I might redefine while working in IRB, just because I
want to see how they work. If they break something IRB depends on, then
IRB will throw an exception and exit immediately.

The simplest case I can think of at the moment:
[bloom@cat-in-the-hat ~]$ irb
irb(main):001:0> $SAFE=4
/usr/lib/ruby/1.8/irb.rb:265:in `signal_status': Insecure: can't modify
instance variable (SecurityError)
        from /usr/lib/ruby/1.8/irb.rb:147:in `eval_input'
        from /usr/lib/ruby/1.8/irb/ruby-lex.rb:244:in
`each_top_level_statement'
        from /usr/lib/ruby/1.8/irb/ruby-lex.rb:230:in `loop'
        from /usr/lib/ruby/1.8/irb/ruby-lex.rb:230:in
`each_top_level_statement'
        from /usr/lib/ruby/1.8/irb/ruby-lex.rb:229:in `catch'
        from /usr/lib/ruby/1.8/irb/ruby-lex.rb:229:in
`each_top_level_statement'
        from /usr/lib/ruby/1.8/irb.rb:146:in `eval_input'
        from /usr/lib/ruby/1.8/irb.rb:70:in `start'
        from /usr/lib/ruby/1.8/irb.rb:69:in `catch'
        from /usr/lib/ruby/1.8/irb.rb:69:in `start'
        from /usr/bin/irb:13
[bloom@cat-in-the-hat ~]$



--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[ruby-core:20384] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Brent Roman]

This is somewhat of a tangent, but I think it is related...

Do any of the current open source Ruby implementations 
already have, or are planning on having, Floats represented
as immediate objects?

Mag-Lev Ruby apparently does this, but it's not open source.

For 64-bit systems, this one, transparent enhancement should dramatically
reduce memory use and increase performance of numeric intensive
Ruby apps.

My general point in asking on this, rather philosophical, thread
is that I believe there are still a number of rewarding, noninvasive 
optimizations that can be implemented before we start removing
core features of Ruby in an effort to attain more speed.

- brent



Charles Oliver Nutter-2 wrote:
> 
> 
> I'll go on the record here and say that as much as it would help 
> implementers if there were a minimal subset of core methods that never 
> changed, I'd never reasonably expect Ruby to do that. We've gone out of 
> our way working on JRuby to support as much of Ruby as possible, even to 
> the point of crippling performance in many cases. The tricks 1.9 and 
> JRuby use currently to check if core methods have changed is sufficient 
> for "very good" performance, and in JRuby those checks will often be 
> optimized away by the JVM. So it's not that big a deal if we never lock 
> down any core methods.
> 
> But it would help make performance even better :)
> 
> - Charlie
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20190--Behavior%3A-autoload-calls-rb_require%28%29-directly-tp20777164p20859864.html
Sent from the ruby-core mailing list archive at Nabble.com.

[ruby-core:20385] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Paul Brannan]

Floats are 64-bits wide, and need at least 1 bit to indicate that the
object reference holds a float.  To make a float an immediate object,
one would then need at least 96 bits for each object reference (vs. 32
bits now on a 32-bit platform).

This is doable, but does the performance gain outweigh the cost of the
additional memory required for applications that don't use Floats?  Or
would a solution like an object pool produce a happier medium?

Paul

[ruby-core:20386] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Brent Roman]

Paul,

As we all know, Ruby
Integers are 32-bits or 64-bits wide, but Fixnums are somewhat smaller.
They get transparently promoted by Bignums as needed.
Similarly, a 64-bit VM could define SmallFloats.  These would be a floats
few bits
short of 64-bits that are promoted to a full Floats as needed.
This video presentation of Allan Ottis at RubyConf 2008 explains
what gemstone did in their proprietary MagLev VM:

http://rubyconf2008.confreaks.com/ruby-persistence-in-maglev.html

Listen to the topic "Special Objects" beginning 35 minutes in.

It's little more than extending object tags to include floats and
a persistent store.  Seems pretty straightforward to do just the floats
on a 64-bit machine.  Big win for a small effort as I see it.

Could you explain how an Object pool would address this issue?

- brent


Paul Brannan wrote:
> 
> Floats are 64-bits wide, and need at least 1 bit to indicate that the
> object reference holds a float.  To make a float an immediate object,
> one would then need at least 96 bits for each object reference (vs. 32
> bits now on a 32-bit platform).
> 
> This is doable, but does the performance gain outweigh the cost of the
> additional memory required for applications that don't use Floats?  Or
> would a solution like an object pool produce a happier medium?
> 
> Paul
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20190--Behavior%3A-autoload-calls-rb_require%28%29-directly-tp20777164p20861312.html
Sent from the ruby-core mailing list archive at Nabble.com.

[ruby-core:20387] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

Brent Roman wrote:
> Paul,
> 
> As we all know, Ruby
> Integers are 32-bits or 64-bits wide, but Fixnums are somewhat smaller.
> They get transparently promoted by Bignums as needed.
> Similarly, a 64-bit VM could define SmallFloats.  These would be a floats
> few bits
> short of 64-bits that are promoted to a full Floats as needed.
> This video presentation of Allan Ottis at RubyConf 2008 explains
> what gemstone did in their proprietary MagLev VM:

There's a lot of interest in adding value types and tagged numerics to 
the JVM, and I believe some work has already started on it. Currently 
JRuby doesn't even have tagged Fixnums, though the speed of allocation 
and young gen GC on the JVM makes up for it (we're still comfortably 
faster than 1.9 on numeric benchmarks). However long term we'll need 
them to really show full-speed arithmetic on the JVM, and since several 
languages have said the same thing, they're likely to be added.

Here's an article by John Rose, one of the folks responsible for 
Hotspot's optimizing JIT:

http://blogs.sun.com/jrose/entry/fixnums_in_the_vm

As with all features, John never makes it sound particularly difficult 
to add. By this time next year, the JVM may have fixnums, fast dynamic 
dispatch, tail calls, continuations, value types/tuples, interface 
injection, and a whole lot more.

- Charlie

[ruby-core:20388] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Tomas Matousek wrote:
> But this only means we are missing a sandbox feature. If there was a simple way how to create a new sandboxed environment and execute a Ruby script within it and then remotely inspect the results then irb could use that.
> 
> BTW: You can do it in IronRuby: :)

JRuby as well, either by instantiating a new JRuby instance directly or 
by using Evan Phoenix's MVM API (which does the same thing under the covers.

There is also work going on to add MVM support to 1.9. Check out the 
branch, I believe it's functional already (or very close). Talk to ko1 
or nobu if you have more questions about that implementation. We will 
match Ruby-level APIs as they evolve.

- Charlie

[ruby-core:20389] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yehuda Katz]

Matz,

One possibility is that packages are first-class concepts (in 2.0?)  
and new methods or changes to existing methods could be restricted to  
a package (optionally -- packages could still decide not to protect  
their changes and make them global).

If this is done, it would moot the most common need for selector  
namespaces (libraries that extend core classes for internal convenience)

If packages could be imported into other packages, or the "global"  
package, users could decide, for instance, if they wanted Merb's core  
extensions or Rails'

Does this make sense?

Sent from my iPhone

On Dec 4, 2008, at 2:40 PM, Yukihiro Matsumoto <matz@ruby-lang.org>  
wrote:

> Hi,
>
> In message "Re: [ruby-core:20323] Leave my open classes alone (was  
> Behavior: autoload calls rb_require()  directly)"
>    on Fri, 5 Dec 2008 06:25:08 +0900, Dave Thomas  
> <dave@pragprog.com> writes:
>
> |Every time we do something like this, we add more special cases to  
> the
> |language. Right now, classes are open. We allow people to modify  
> their
> |behavior. That's just Ruby. Take away plus, and you limit my freedom.
> |What's next? Maybe Fixnum.to_s. And then maybe Struct.to_s. And then
> |maybe all internal classes get closed, and no one would be able to
> |create things such as Symbol.to_proc.
>
> Don't get me wrong.  No matter how Charles agreed, I said I wanted to
> separate the namespace, and protect core from "casual" user
> modification, but did not intended to freeze anything.  Actually quite
> opposite.
>
> Another example is mathn library, which replaces core math operation
> in a somewhat useful manner, but introduces serious incompatibility at
> the same time.  If we can separate effect of mathn in a region or
> namespace, we can live happier with controlled monkey patching.
>
> |I'd much rather see change going the other way. I'd like to see a =
> |"cat" calling String.new. I'd like to see fewer special cases.
>
> Interesting.  if a = "cat" calls String.new, it should take an
> (string) argument to initialize the content "cat", then how should the
> original content sting be initialized?
>
>                            matz.
>
>

[ruby-core:20390] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yehuda Katz]

What is desirable is a user option that could turn on more static  
features for a segment of code without affecting ruby proper.

Sent from my iPhone

On Dec 4, 2008, at 2:46 PM, Charles Oliver Nutter <charles.nutter@sun.com 
 > wrote:

> Pit Capitain wrote:
>> 2008/12/4 Charles Oliver Nutter <charles.nutter@sun.com>:
>>> I can appreciate the "choice is good" argument, but I think the  
>>> Ruby world
>>> needs a little less dogmatism about "choice" and "freedom" and  
>>> "beauty".
>>> There's practical concerns here, concerns about API stability,
>>> thread-safety, performance, memory efficiency. Too many of those  
>>> concerns
>>> are sacrificed on the altar of "choice" or "freedom".
>> And who decides which things are more important than the others?  
>> Based
>> on which criteria? I'd say the Ruby language doesn't need more
>> dogmatism about things like performance and memory efficiency.
>
> You are entitled to your opinion. :)
>
>>> In the case of core classes, we're not talking about closing them  
>>> down
>>> completely; we're talking about guaranteeing to all developers and  
>>> users
>>> that some minimum set of methods will do what you expect them to  
>>> do, now and
>>> forever. We're guaranteeing that 1 + 1 will continue to == 2.
>> So I couldn't add some logging or tracing to Fixnum#+? This looks
>> pretty closed to me.
>
> Perhaps you would be able to in a less restrictive mode. Perhaps as  
> Michael proposed there could be a library to load for either case,  
> or there could be a CLI flag. There's plenty of options to  
> accommodate both people who want to monkey-patch core classes and  
> people want to avoid the overhead that comes from allowing that  
> monkey-patching.
>
>>> And it's not
>>> the case where *you* want to override a core method that's the
>>> problem...it's the case where someone else overrides it-- 
>>> potentially by
>>> mistake--and you don't find out about it until later.
>> If you want to prevent this, you have to close almost all core
>> methods. Is this what you are proposing? Why is the current
>> Fixnum.freeze not enough?
>
> You would not have to close almost all core methods. And  
> Fixnum.freeze closes the whole class, so you're going too far in  
> this comparison.
>
>>> Ruby needs to grow up as a language by allowing people who want  
>>> guarantees
>>> to get guarantees.
>> Says who? If you want to change Ruby in such a fundamental way, why
>> should it still be called Ruby?
>
> Matz proposed introducing some sort of protection for core code.  
> Whether that comes in the form of locking down Fixnum#+ or adding  
> some new Fixnum#__ADD__ or namespacing is a detail.
>
>>> And there's a lot of people who want some minimal, basic
>>> guarantees about core classes.
>> Do you have any references for this claim? I'm definitely not in  
>> this group.
>
> If nobody were interested in it, it wouldn't keep coming up. There's  
> certainly plenty of references in the ML logs.
>
> FWIW, I don't expect this sort of thing to ever get into core, so  
> the JRuby and Ruby 1.9 strategy of watching for changes to core  
> classes is probably as close as we will get. And that's ok...in both  
> cases we can get very good performance without locking down e.g  
> Fixnum#+. But it makes pushing Ruby performance farther than what we  
> have today a lot more complicated.
>
> - Charlie
>

[ruby-core:20391] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yehuda Katz]

Again, what is desired is a way to *elect* into this state of affairs  
for performance or stability for a segment of your code.

Sent from my iPhone

On Dec 4, 2008, at 2:53 PM, "David A. Black" <dblack@rubypal.com> wrote:

> Hi --
>
> On Fri, 5 Dec 2008, Charles Oliver Nutter wrote:
>
>> Dave Thomas wrote:
>>> Please, no.
>>> Every time we do something like this, we add more special cases to  
>>> the language. Right now, classes are open. We allow people to  
>>> modify their behavior. That's just Ruby. Take away plus, and you  
>>> limit my freedom. What's next? Maybe Fixnum.to_s. And then maybe  
>>> Struct.to_s. And then maybe all internal classes get closed, and  
>>> no one would be able to create things such as Symbol.to_proc.
>>> I'd much rather see change going the other way. I'd like to see a  
>>> = "cat" calling String.new. I'd like to see fewer special cases.
>>> If require is broken, then fix it. But don't stop me replacing it  
>>> if I want. And if I replace it incorrectly (making it not thread  
>>> safe, for instance) that then becomes my fault.
>>> Ruby is about choice. If I wanted a language implementor to tell  
>>> me what I can change and what I can't change, I'd use Python or  
>>> Java.
>>
>> I can appreciate the "choice is good" argument, but I think the  
>> Ruby world needs a little less dogmatism about "choice" and  
>> "freedom" and "beauty". There's practical concerns here, concerns  
>> about API stability, thread-safety, performance, memory efficiency.  
>> Too many of those concerns are sacrificed on the altar of "choice"  
>> or "freedom".
>>
>> In the case of core classes, we're not talking about closing them  
>> down completely; we're talking about guaranteeing to all developers  
>> and users that some minimum set of methods will do what you expect  
>> them to do, now and forever. We're guaranteeing that 1 + 1 will  
>> continue to == 2. And it's not the case where *you* want to  
>> override a core method that's the problem...it's the case where  
>> someone else overrides it--potentially by mistake--and you don't  
>> find out about it until later.
>>
>> Ruby needs to grow up as a language by allowing people who want  
>> guarantees to get guarantees. And there's a lot of people who want  
>> some minimal, basic guarantees about core classes.
>
> It's not a growing-up thing, though. The freedom of Ruby isn't the
> freedom of an undisciplined or pre-socialized child; it's an informed,
> elective, adult state.
>
> For me, this particular issue comes down to a simple point of logic --
> namely, that exactly one of the following statements must be true:
>
>  1. There should never be a computer language that has fully open,
>     changeable built-in classes; or,
>  2. There should be one or more such languages, but Ruby should not
>     be one of them.
>  3. There should be one or more such languages, and Ruby should be
>     one of them.
>
> If #3 is not true, then either #1 or #2 is true, and I don't believe
> either of them is. If Ruby does away with its openness, then another
> language will come along that implements that openness. So why not
> just break the cycle, and decide that Ruby *is* the language that has
> come along?
>
>
> David
>
> -- 
> Rails training from David A. Black and Ruby Power and Light:
> INTRO TO RAILS (Jan 12-15), Fort Lauderdale, FL
> See http://www.rubypal.com for details
> Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)
>

[ruby-core:20392] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Berger, Daniel]

> -----Original Message-----
> From: Dave Thomas [mailto:dave@pragprog.com] 
> Sent: Thursday, December 04, 2008 2:25 PM
> To: ruby-core@ruby-lang.org
> Subject: [ruby-core:20323] Leave my open classes alone (was 
> Behavior: autoload calls rb_require() directly)
> 
> 
> On Dec 4, 2008, at 1:38 PM, Paul Brannan wrote:
> 
> > On Fri, Dec 05, 2008 at 03:25:42AM +0900, Charles Oliver 
> Nutter wrote:
> >> I agree. There's no practical reason anyone should be able to 
> >> override Fixnum#+, after all, and protecting the core simplifies 
> >> implementation and optimization too.
> >
> > I agree.  Not having to check to see if Fixnum#+ is redefined each 
> > time we want to add two integers would be a noticeable performance 
> > improvement.
> 
> Please, no.

No need to ask. No need to check explicitly.

1) Run with -w.
2) Watch warnings emit.
3) ???
4) Profit!

You are running your code and test with warnings enabled, right? Of
course you are.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

[ruby-core:20393] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Paul Brannan]

On Sat, Dec 06, 2008 at 04:46:36AM +0900, Brent Roman wrote:
> 
> Paul,
> 
> As we all know, Ruby
> Integers are 32-bits or 64-bits wide, but Fixnums are somewhat smaller.
> They get transparently promoted by Bignums as needed.
> Similarly, a 64-bit VM could define SmallFloats.  These would be a floats
> few bits
> short of 64-bits that are promoted to a full Floats as needed.

You can't easily do these sorts of tricks with floating point numbers;
it breaks IEEE floating point compatibility.  On some platforms you
might be able to get away with breaking out the exponent and dropping a
few bits off it, but you'd want a LOT of unit tests to ensure you don't
introduce a subtle incompatibility.

Floating point code can be very fragile, and I'd feel much better about
a solution that leaves the floating point number intact.

Paul

[ruby-core:20396] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Brent Roman]

Paul,

I understand your concern, but it may not be an tricky as you believe.

I think the MagLev folks addressed this by truncating 
the binary exponent to 8 bits in their immediate object format while 
always preserving the full mantissa.  There should thus be no loss of
precision,
but there will be a loss of dynamic range.  Those few floats
whose absolute value is greater than approx. 2**127 (1.0e+38) could not be
represented as SmallFloats, so they would be automatically promoted to
non-immediate
Float objects, much like 2**30 gets silently promoted to a Bignum in 32-bit
MRI today.

- brent


Paul Brannan wrote:
> 
> On Sat, Dec 06, 2008 at 04:46:36AM +0900, Brent Roman wrote:
> 
> You can't easily do these sorts of tricks with floating point numbers;
> it breaks IEEE floating point compatibility.  On some platforms you
> might be able to get away with breaking out the exponent and dropping a
> few bits off it, but you'd want a LOT of unit tests to ensure you don't
> introduce a subtle incompatibility.
> 
> Floating point code can be very fragile, and I'd feel much better about
> a solution that leaves the floating point number intact.
> 
> Paul
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20190--Behavior%3A-autoload-calls-rb_require%28%29-directly-tp20777164p20865593.html
Sent from the ruby-core mailing list archive at Nabble.com.

[ruby-core:20397] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Brent Roman]

Charlie,

I skimmed the article.  John's obviously a smart guy.  I hope
he gets a chance implement his headless objects.

Sun's JVM has grown into a truly impressive piece of work and
I do believe it well continue to get better.  However,
it's also grown quite large and remains tied to the Intel x86
and SPARC CPUs.

Is there anyone running a recent version of 
JRuby on an ARM or MIPS CPU with an open source JVM?

If I could find a way to run JRUBY on my targets, I'd be all
over it.

- brent


Charles Oliver Nutter-2 wrote:
> 
> 
> There's a lot of interest in adding value types and tagged numerics to 
> the JVM, and I believe some work has already started on it. Currently 
> JRuby doesn't even have tagged Fixnums, though the speed of allocation 
> and young gen GC on the JVM makes up for it (we're still comfortably 
> faster than 1.9 on numeric benchmarks). However long term we'll need 
> them to really show full-speed arithmetic on the JVM, and since several 
> languages have said the same thing, they're likely to be added.
> 
> Here's an article by John Rose, one of the folks responsible for 
> 
> Hotspot's optimizing JIT:
> 
> http://blogs.sun.com/jrose/entry/fixnums_in_the_vm
> 
> As with all features, John never makes it sound particularly difficult 
> to add. By this time next year, the JVM may have fixnums, fast dynamic 
> dispatch, tail calls, continuations, value types/tuples, interface 
> injection, and a whole lot more.
> 
> - Charlie
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20190--Behavior%3A-autoload-calls-rb_require%28%29-directly-tp20777164p20865782.html
Sent from the ruby-core mailing list archive at Nabble.com.

[ruby-core:20398] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20384] Re: Leave my open classes alone (was Behavior: autoload calls rb_require()  directly)"
    on Sat, 6 Dec 2008 03:43:23 +0900, Brent Roman <brent@mbari.org> writes:

|Do any of the current open source Ruby implementations 
|already have, or are planning on having, Floats represented
|as immediate objects?

Ko1 once experimented making float values immediate on 64bit systems.
It improved performance, but as far as I know it's not production
ready, besides that most of the systems out are still 32bit.

							matz.

[ruby-core:20399] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Yukihiro Matsumoto]

Hi,

In message "Re: [ruby-core:20389] Re: Leave my open classes alone (was Behavior: autoload calls rb_require()  directly)"
    on Sat, 6 Dec 2008 05:31:27 +0900, Yehuda Katz <wycats@gmail.com> writes:

|One possibility is that packages are first-class concepts (in 2.0?)  
|and new methods or changes to existing methods could be restricted to  
|a package (optionally -- packages could still decide not to protect  
|their changes and make them global).

|Does this make sense?

Makes sense.  Although I have no fixed idea for 2.0 namespace.  At
least I know scoping management is an important issue for the future.

							matz.

[ruby-core:20404] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Charles Oliver Nutter]

Brent Roman wrote:
> Charlie,
> 
> I skimmed the article.  John's obviously a smart guy.  I hope
> he gets a chance implement his headless objects.
> 
> Sun's JVM has grown into a truly impressive piece of work and
> I do believe it well continue to get better.  However,
> it's also grown quite large and remains tied to the Intel x86
> and SPARC CPUs.
> 
> Is there anyone running a recent version of 
> JRuby on an ARM or MIPS CPU with an open source JVM?
> 
> If I could find a way to run JRUBY on my targets, I'd be all
> over it.

I'm not sure, actually. There's a lot of people using JRuby on peculiar 
setups that we don't even know about. I know there's also work being 
done to get OpenJDK hosted on ARM and other platforms, but I'm not sure 
what the status is other than this posting:

http://gbenson.net/?p=88

Gary Benson is working on the Zero and Shark projects, which aim to 
provide Hotspot (OpenJDK's VM) with zero assembly and with an LLVM 
backend, respectively. Might be worth giving it a try, and at any rate 
it won't be long before Hotspot runs everywhere.

- Charlie

[ruby-core:20410] Re: Behavior: autoload calls rb_require() directly

[Ken Bloom]

On Sat, 06 Dec 2008 05:18:40 +0900, Charles Oliver Nutter wrote:

> Tomas Matousek wrote:
>> But this only means we are missing a sandbox feature. If there was a
>> simple way how to create a new sandboxed environment and execute a Ruby
>> script within it and then remotely inspect the results then irb could
>> use that.
>> 
>> BTW: You can do it in IronRuby: :)
> 
> JRuby as well, either by instantiating a new JRuby instance directly or
> by using Evan Phoenix's MVM API (which does the same thing under the
> covers.
> 
> There is also work going on to add MVM support to 1.9. Check out the
> branch, I believe it's functional already (or very close). Talk to ko1
> or nobu if you have more questions about that implementation. We will
> match Ruby-level APIs as they evolve.
> 
> - Charlie

Could a sandbox feature like these (or why's) be used to protect the core?

--Ken

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[ruby-core:20411] Re: Behavior: autoload calls rb_require() directly

[Charles Oliver Nutter]

Ken Bloom wrote:
> Could a sandbox feature like these (or why's) be used to protect the core?

The environments are very separate, so they really act like separate 
processes each with their own String, Fixnum, and so on. It really is a 
coarse-grained sandbox, not just a separate namespace.

- Charlie

[ruby-core:20415] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[SASADA Koichi]

Yukihiro Matsumoto wrote::
> Ko1 once experimented making float values immediate on 64bit systems.
> It improved performance, but as far as I know it's not production
> ready, besides that most of the systems out are still 32bit.

To be precise, most of Desktop OSs are 32bit.  But 64bit CPU and OSs are
common for Server, HPC and so on.

-- 
// SASADA Koichi at atdot dot net

[ruby-core:20426] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Paul Brannan]

On Sat, Dec 06, 2008 at 10:17:52AM +0900, Brent Roman wrote:
> 
> Paul,
> 
> I understand your concern, but it may not be an tricky as you believe.
> 
> I think the MagLev folks addressed this by truncating the binary
> exponent to 8 bits in their immediate object format while always
> preserving the full mantissa.  There should thus be no loss of
> precision, but there will be a loss of dynamic range.  Those few
> floats whose absolute value is greater than approx. 2**127 (1.0e+38)
> could not be represented as SmallFloats, so they would be
> automatically promoted to non-immediate Float objects, much like 2**30
> gets silently promoted to a Bignum in 32-bit MRI today.

A few comments:
- My initial concern was that arithmetic would be done on objects that
  don't have the same bit representation, but after thinking about it I
  see now that would be impossible.  As long as the immediate object is
  converted to a double with the same bit representation as the original
  before arithmetic operations are performed, there should be little
  problem.
- While this scheme would reduce the number of objects created, without
  seeing benchmarks I'm not convinced that the arithmetic necessary to
  extract the exponent and create the immediate object would be faster
  to execute than removing a pre-allocated object from a freelist of
  Floats and populate it (likely there would be an overall performance
  gain, due to Ruby's non-generational GC).  This is how Python's float
  objects are implemented (at least as of 2.4; I'm not familiar with
  newer versions).
- A 96-bit or 128-bit object reference representation would be able to
  represent all possible Floats, and would also be able to represent 3-
  and 4-tuples as immediate objects.

Paul

[ruby-core:20441] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[Ken Bloom]

On Mon, 08 Dec 2008 18:21:39 +0900, SASADA Koichi wrote:

> Yukihiro Matsumoto wrote::
>> Ko1 once experimented making float values immediate on 64bit systems.
>> It improved performance, but as far as I know it's not production
>> ready, besides that most of the systems out are still 32bit.
> 
> To be precise, most of Desktop OSs are 32bit.  But 64bit CPU and OSs are
> common for Server, HPC and so on.

Even so, where would you get space for the tag from? Ruby's documentation 
says that a "Float objects represent real numbers using the native 
architecture‘s double-precision floating point representation," and a 
double is 64 bits on most 32- and 64-bit operating systems.



-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[ruby-core:20442] Re: Leave my open classes alone (was Behavior: autoload calls rb_require() directly)

[SASADA Koichi]

Ken Bloom wrote::
> Even so, where would you get space for the tag from? Ruby's documentation 
> says that a "Float objects represent real numbers using the native 
> architecture‘s double-precision floating point representation," and a 
> double is 64 bits on most 32- and 64-bit operating systems.

Good point.

A method is written in my paper, but it is written in Japanese.

This is ruby.h for embed double.
http://www.atdot.net/sp/view/e76mbk

rb_float_new(), NUM2DOUBLE() and RFLOAT_VALUE() have a trick.  It
generates 1 bit for Float.  However Fixnum consumes 3 bit tags.

-- 
// SASADA Koichi at atdot dot net

[ruby-core:20444] Re: Leave my open classes alone (was Behavior:autoload calls rb_require() directly)

[Martin Duerst]

At 23:39 08/12/09, SASADA Koichi wrote:
>Ken Bloom wrote::
>> Even so, where would you get space for the tag from? Ruby's documentation 
>> says that a "Float objects represent real numbers using the native 
>> architecture窶\xCF\xD4 double-precision floating point representation," and a 
>> double is 64 bits on most 32- and 64-bit operating systems.
>
>Good point.
>
>A method is written in my paper, but it is written in Japanese.

Do you have a pointer?

>
>This is ruby.h for embed double.
>http://www.atdot.net/sp/view/e76mbk

I only get a page with some data and links, as follows:

Paste time: Wed Dec 10 11:00:08 +0900 2008
Paste IP addr: 218.45.21.194 
Your paste URL is http://www.atdot.net/sp/view/e76mbk 
Read only URL is http://www.atdot.net/sp/readonly/e76mbk 
Raw URL is http://www.atdot.net/sp/raw/e76mbk 
make new page
delete this page
stick this page


Regards,    Martin.

>rb_float_new(), NUM2DOUBLE() and RFLOAT_VALUE() have a trick.  It
>generates 1 bit for Float.  However Fixnum consumes 3 bit tags.
>
>-- 
>// SASADA Koichi at atdot dot net


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     

[ruby-core:20445] Re: Leave my open classes alone (was Behavior:autoload calls rb_require() directly)

[SASADA Koichi]

Martin Duerst wrote::
> At 23:39 08/12/09, SASADA Koichi wrote:
>> Ken Bloom wrote::
>>> Even so, where would you get space for the tag from? Ruby's documentation 
>>> says that a "Float objects represent real numbers using the native 
>>> architecture double-precision floating point representation," and a 
>>> double is 64 bits on most 32- and 64-bit operating systems.
>> Good point.
>>
>> A method is written in my paper, but it is written in Japanese.
> 
> Do you have a pointer?

I posted this paper to PPL2008.
paper in Japanese:
http://www.atdot.net/~ko1/activities/rubyfp.pdf
slides in Japanese:
http://www.atdot.net/~ko1/activities/PPL2008-rubyfp.pdf

My EURUKO2008 slides includes this idea in English.
http://www.atdot.net/~ko1/activities/EURUKO2008_sasada_en.pdf

>> This is ruby.h for embed double.
>> http://www.atdot.net/sp/view/e76mbk
> 
> I only get a page with some data and links, as follows:

Someone may delete it.
here is: http://www.atdot.net/sp/readonly/iponbk

-- 
// SASADA Koichi at atdot dot net