[#11569] sprintf: Format specifier tokens aren't checked well enough — Florian Gross <florgro@...>

Hi,

12 messages 2007/07/01

[#11611] Import gem to Ruby 1.9 — SASADA Koichi <ko1@...>

Hi,

130 messages 2007/07/08
[#11625] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/07/09

On Jul 8, 2007, at 00:49, SASADA Koichi wrote:

[#11727] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/17

-----BEGIN PGP SIGNED MESSAGE-----

[#11738] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/07/17

On Jul 17, 2007, at 01:26, NAKAMURA, Hiroshi wrote:

[#11752] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/18

-----BEGIN PGP SIGNED MESSAGE-----

[#11794] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/24

-----BEGIN PGP SIGNED MESSAGE-----

[#11820] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/26

-----BEGIN PGP SIGNED MESSAGE-----

[#12323] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/01

-----BEGIN PGP SIGNED MESSAGE-----

[#12330] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/10/01

On Sep 30, 2007, at 22:56 , NAKAMURA, Hiroshi wrote:

[#12637] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/10/13

On Oct 1, 2007, at 09:57 , Eric Hodel wrote:

[#12642] Re: Import gem to Ruby 1.9 — Yukihiro Matsumoto <matz@...> 2007/10/13

Hi,

[#12643] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/13

-----BEGIN PGP SIGNED MESSAGE-----

[#12645] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/10/13

On Oct 13, 2007, at 02:00 , NAKAMURA, Hiroshi wrote:

[#12652] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/13

-----BEGIN PGP SIGNED MESSAGE-----

[#12656] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/10/13

On Oct 13, 2007, at 08:00 , NAKAMURA, Hiroshi wrote:

[#12691] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/15

-----BEGIN PGP SIGNED MESSAGE-----

[#12712] Re: Import gem to Ruby 1.9 — Eric Hodel <drbrain@...7.net> 2007/10/16

On Oct 15, 2007, at 07:14 , NAKAMURA, Hiroshi wrote:

[#12717] Re: Import gem to Ruby 1.9 — "Leonard Chin" <l.g.chin@...> 2007/10/17

On 10/17/07, Eric Hodel <drbrain@segment7.net> wrote:

[#12729] Re: Import gem to Ruby 1.9 — Charles Oliver Nutter <charles.nutter@...> 2007/10/17

Leonard Chin wrote:

[#12766] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/19

In article <4710890A.3020009@sarion.co.jp>,

[#12768] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/19

-----BEGIN PGP SIGNED MESSAGE-----

[#12771] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/19

In article <4718708D.3050001@sarion.co.jp>,

[#12792] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/20

-----BEGIN PGP SIGNED MESSAGE-----

[#12798] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/21

In article <471A1720.4080606@sarion.co.jp>,

[#12827] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/22

-----BEGIN PGP SIGNED MESSAGE-----

[#12852] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/23

In article <471CAFE0.2070104@sarion.co.jp>,

[#12853] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/23

-----BEGIN PGP SIGNED MESSAGE-----

[#12854] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/23

In article <471D4D1F.5050006@sarion.co.jp>,

[#12857] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/23

-----BEGIN PGP SIGNED MESSAGE-----

[#12896] Re: Import gem to Ruby 1.9 — Tanaka Akira <akr@...> 2007/10/24

In article <471D5665.5040209@sarion.co.jp>,

[#12914] Re: Import gem to Ruby 1.9 — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/10/25

-----BEGIN PGP SIGNED MESSAGE-----

[#11642] Re: Proposal: runtime-modifying Kernel methods should be keywords — "Marcel Molina Jr." <marcel@...>

On Fri, Jul 13, 2007 at 03:02:06PM +0900, Charles Oliver Nutter wrote:

21 messages 2007/07/13
[#11671] Re: Proposal: runtime-modifying Kernel methods should be keywords — Ryan Davis <ryand-ruby@...> 2007/07/13

[#11645] Re: Proposal: runtime-modifying Kernel methods should be keywords — Charles Oliver Nutter <charles.nutter@...>

Charles Oliver Nutter wrote:

20 messages 2007/07/13
[#11646] Re: Proposal: runtime-modifying Kernel methods should be keywords — Yukihiro Matsumoto <matz@...> 2007/07/13

Hi,

[#11647] Re: Proposal: runtime-modifying Kernel methods should be keywords — Charles Oliver Nutter <charles.nutter@...> 2007/07/13

Yukihiro Matsumoto wrote:

[#11650] Re: Proposal: runtime-modifying Kernel methods should be keywords — Nobuyoshi Nakada <nobu@...> 2007/07/13

Hi,

[#11756] threads and heavy io on osx and linux — "ara.t.howard" <Ara.T.Howard@...>

15 messages 2007/07/18

[#11795] What libraries to be unbundled? — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

27 messages 2007/07/24
[#11797] Re: What libraries to be unbundled? — David Flanagan <david@...> 2007/07/24

I don't think that json should be unbundled. It is the interchange

Re: Proposal: runtime-modifying Kernel methods should be keywords

From: TRANS <transfire@...>
Date: 2007-07-13 14:10:45 UTC
List: ruby-core #11659
On 7/13/07, John Lam <jlam@iunknown.com> wrote:
> > 3. These methods are exactly the ones that complicate optimizing Ruby in
> > all implementations, including Ruby 1.9, Rubinius, JRuby, Ruby.NET, and
> > others. They confound a compiler's efforts to optimize calls by always
> > leaving open questions about the behavior of a method. Will it need
> > access to a heap-allocated scope? Will it save off a binding or the
> > current call frame? No way to know for sure, since they're methods.
>
> +1
>
> We have a design (not implemented yet) to throw on an attempt to alias
> Kernel#eval by default. We would enable aliasing eval with a command
> line switch along the lines of /MakeItRunSlower :) We have a number of
> optimizations for non-local control flow that take advantage of using
> static analysis of a block/proc body. These optimizations simply
> cannot work in cases where eval appears within the block/proc. If
> folks could alias eval then we can't do any of the optimizations at
> all, and that is clearly a bad thing.

I think 'eval' is a clear choice for keyword. But I'm curious, how
does that effect Binding#eval?

As for the others, I don't think the criteria makes sense exactly.
It's not that one would want to re-implement 'local_variables', for
example, but rather just reuse the name for something else. Is that
dangerous? Well, that's Ruby. There are lots of meta-methods that one
would like to think are always there and always operating as one would
expect, but you can't. We've had a number of discussions on ruby-talk
about externalizing such calls in order to avoid overrides. Keywords
are just another attempt at that.

Just a couple of quick points about particular methods:
  - I hope block_given? ultimately goes away!
  - I wish public/private/protected could just be a matter of
    documentation and leave us too, but I realize that's not
    likely, so personally I'd rather do like Java:
      private def x()
      public def x()
      protected def x()
  - What about module_function as keyword? (another one I don't like)
  - You mention 'binding'. However I prefer my alias 'here'.
    How would I alias a keyword?

T.

In This Thread