[#11890] Ruby and Solaris door library — "Hiro Asari" <asari.ruby@...>

Hi, there. This is my first patch against ruby. I think I followed

19 messages 2007/08/13
[#11892] Re: Ruby and Solaris door library — Daniel Berger <djberg96@...> 2007/08/14

Hiro Asari wrote:

[#11899] pack/unpack 64bit Integers — Hadmut Danisch <hadmut@...>

Hi,

13 messages 2007/08/14
[#11903] Re: pack/unpack 64bit Integers — Brian Candler <B.Candler@...> 2007/08/15

On Wed, Aug 15, 2007 at 06:50:01AM +0900, Hadmut Danisch wrote:

[#11948] Fibers in Ruby 1.9? — David Flanagan <david@...>

I just noticed that my ruby1.9 build of August 17th includes a Fiber

22 messages 2007/08/22
[#11949] Re: Fibers in Ruby 1.9? — Daniel Berger <djberg96@...> 2007/08/22

David Flanagan wrote:

[#11950] Re: Fibers in Ruby 1.9? — "Francis Cianfrocca" <garbagecat10@...> 2007/08/22

On 8/22/07, Daniel Berger <djberg96@gmail.com> wrote:

[#11952] Re: Fibers in Ruby 1.9? — MenTaLguY <mental@...> 2007/08/22

On Wed, 22 Aug 2007 20:50:12 +0900, "Francis Cianfrocca" <garbagecat10@gmail.com> wrote:

[#11988] String#length not working properly in Ruby 1.9 — "Vincent Isambart" <vincent.isambart@...>

I saw that Matz just merged his M17N implementation in the trunk.

17 messages 2007/08/25
[#11991] Re: String#length not working properly in Ruby 1.9 — "Michael Neumann" <mneumann@...> 2007/08/25

On Sat, 25 Aug 2007 10:54:20 +0200, Yukihiro Matsumoto

[#11992] Re: String#length not working properly in Ruby 1.9 — Yukihiro Matsumoto <matz@...> 2007/08/25

Hi,

[#12042] Encodings of string literals; explicit codepoint escapes? — David Flanagan <david@...>

This message contains queries that probably only Matz can answer:

16 messages 2007/08/31
[#12043] Re: Encodings of string literals; explicit codepoint escapes? — Yukihiro Matsumoto <matz@...> 2007/08/31

Hi,

Pragmas in Ruby 1.9

From: David Flanagan <david@...>
Date: 2007-08-31 06:35:09 UTC
List: ruby-core #12040
Hi,

In a previous thread about String.encoding and related changes to 
String, Matz revealed that Ruby 1.9 will parse comments on the first 
line (or second line if there is a shebang on the first line) in order 
to determine the encoding of the source file.

Matz acknowledges that these are pragmas, and promises at least three 
legal syntaxes for specifying an encoding:

> I will
> relax this as Python coding pragma (as in PEP-263).  
> 
>   # -*- coding: <encoding name> -*-
> 
> or
> 
>   # coding=<encoding name>
> 
> or, even
> 
>   # vim: set fileencoding=<encoding name> :
> 

I appreciate the compatibility with Python, emacs and vi.  And I 
understand that the determination of encoding may well be a special case 
in which the parser *must* be able to find an encoding on the first or 
second line.

However, if we're going to call these magic comments pragmas, then 
people will want to be able to define other pragmas in comments. (And 
indeed, a framework for accepting pragmas with names other than "coding" 
is already in place in parse.y.)  This is what has me concerned.  If 
we're going to have a general pragma facility in the language, I suggest 
that it ought to be *part of the language* and not a magic 
comment-processing hack.

So, I have two suggestions:

1) Let's not ever refer to these comment-based encoding directives as 
pragmas.  Note that Python's PEP 263 cited by Matz does not call them 
pragmas either.

2) If we need to introduce more general pragmas, I suggest overloading 
Kernel.require.  It should behave as usual if passed a string.  But it 
can handle pragmas if passed a hash.  Some possible examples (using Ruby 
1.9 hash syntax):

   require encoding: "utf-8"
   require unsafe: "fibers"
   require thread-model: "concurrent"
   require version: 1.9
   require decimal: true
   require strict: true

David

In This Thread

Prev Next