[#4076] Ruby/DL — Jamis Buck <jamis_buck@...>

I recently used Ruby/DL to create bindings to the SQLite3 embedded

40 messages 2005/01/03
[#4096] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/04

On Tue, Jan 04, 2005 at 02:53:49AM +0900, Jamis Buck wrote:

[#4099] Re: Ruby/DL — ts <decoux@...> 2005/01/04

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4119] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Wed, Jan 05, 2005 at 03:05:48AM +0900, ts wrote:

[#4120] Re: Ruby/DL — ts <decoux@...> 2005/01/05

>>>>> "P" == Paul Brannan <pbrannan@atdesk.com> writes:

[#4125] Re: Ruby/DL — Paul Brannan <pbrannan@...> 2005/01/05

On Thu, Jan 06, 2005 at 01:10:34AM +0900, ts wrote:

[#4116] Test::Unit::Collector::Dir won't work with code that modifies $LOAD_PATH — Eric Hodel <drbrain@...7.net>

Any test code that depends upon modifications of $: fails when used

10 messages 2005/01/05

[#4146] The face of Unicode support in the future — Charles O Nutter <headius@...>

Hello Rubyists!

47 messages 2005/01/06
[#4152] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/07

Hi,

[#4167] Re: The face of Unicode support in the future — Christian Neukirchen <chneukirchen@...> 2005/01/09

Yukihiro Matsumoto <matz@ruby-lang.org> writes:

[#4175] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/10

Hi,

[#4186] Re: The face of Unicode support in the future — Paul Brannan <pbrannan@...> 2005/01/11

On Mon, Jan 10, 2005 at 11:53:48PM +0900, Yukihiro Matsumoto wrote:

[#4192] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/12

Hi,

[#4269] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...>

19 messages 2005/01/18
[#4270] Re: The face of Unicode support in the future — Yukihiro Matsumoto <matz@...> 2005/01/18

Hi,

[#4275] Re: The face of Unicode support in the future — Wes Nakamura <wknaka@...> 2005/01/19

[#4323] test/unit doesn't rescue a Exception — Tanaka Akira <akr@...17n.org>

test/unit doesn't rescue a Exception in a test method, as follows.

14 messages 2005/01/27
[#8773] Re: test/unit doesn't rescue a Exception — Tanaka Akira <akr@...> 2006/09/02

In article <87is5jb46q.fsf@serein.a02.aist.go.jp>,

[#8776] Re: test/unit doesn't rescue a Exception — "Nathaniel Talbott" <ntalbott@...> 2006/09/03

On 9/1/06, Tanaka Akira <akr@fsij.org> wrote:

[#8777] Re: test/unit doesn't rescue a Exception — Eric Hodel <drbrain@...7.net> 2006/09/03

On Sep 2, 2006, at 6:34 PM, Nathaniel Talbott wrote:

Re: Allowing custom number literal suffixes?

From: Florian Gro<florgro@...>
Date: 2005-01-05 06:26:04 UTC
List: ruby-core #4113
Brent Roman wrote:

>> But if it's already so hard to find support for the relatively simple 
>> and straight-forward patch from earlier, how are you going to get 
>> support for this? Note that I'm not entirely against this, but I think 
>> \3/2\r is a bit too complex for the simple number literal cases.
>>
>> Somehow I have the feeling that what you want to do could be 
>> accomplished with String suffixes. (Though I do not need this.)
>>
> By "String suffixes" I assume you mean numeric literal suffixes 
> implemented in Peter's patch.  Correct?

Incorrect, I was referring to something like "foobar"Q which could work 
similar to Peter's Patch. But as noted above: I'm happy with Number 
suffixes and would like to see those implemented; I'm neutral about 
this, however.

> I'd prefer to see a general mechanism incorporated rather than a patch
> for constrained cases.  My clunky \3/2\r could be streamlined by making
> this simple numeric case a special shortcut that does not require the
> delimiters.  [Much as simple arguments to outer method calls can omit
> parentheses.]  Seeing a token that begins with a digit, the lexer would
> continue until the next character that is not a \.|digit|alpha.  So,
> 
>   3/2r+2  would be syntactically equivalent to  3/\2\r+2
> 
> both evaluate as:
> 
>     3 / Kernel::Literal::Suffix.r('2') + 2

This seems to be compatible with the patch from Peter. While I dislike 
the \...\ syntax I would not need to use this. So if matz and the 
community are okay with this I'm not going to complain.

> I'm not concerned about the details of how a user defined literal 
> facility is implemented.  Just so long as it does not increase the size 
> of the core significantly and it allows arbitrary strings to function as 
> Object literals.  The above was just an example to show what I was after.
> 
> Am I the only one interested in such a facility?

I don't need the arbitrary character part, but I guess my goals are 
mostly a subset of yours.

It seems I have a hard time finding support for Numeric literals because 
most people are not using the Number classes of the standard library. 
But having a simpler way of using them would lead to them being used 
more frequently, I think. It seems to be sort of a circular problem...


In This Thread