[#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: Brent Roman <brent@...>
Date: 2005-01-05 07:42:16 UTC
List: ruby-core #4115
> Florian Gross wrote:
> 
> 
> 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.

> 
> 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 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...
> 

I would have to assume that 'foobar'Q would also work.
As would %q|foobar!Q  Can you confirm this?

My backslashes were just an alternative way of quoting a string.
They allow for the embedded tics and double-quotes that are so common 
with real-world measures -- especially where inches and feet are still
the norm!  They also disambiguate the Prefix notation:

	Time"12AM"   #method call?
	Time\12AM\   #calls Kernel::Literal::Prefix.Time

But, if we drop support for the prefix notation, we don't really need 
backslash quotes. This is OK by me.  Ruby already has enough string
quoting mechanisms.

String suffixes then does go a long way towards making the literal 
definition mechanism more generic.  I still don't understand why:

	'12:30'am  or '9:15'GMT or even 9.15utc

should be problematic.  They would call:

	String::Literal.am, String::Literal.GMT and String::Literal.utc

respectively.  Where Literal is a module in the built-in String class.

So, why insist that suffixes be single letters?

Is there a parsing ambiguity that would result from allowing a suffix
to be any legal method identifier?  This certainly would result in more
readable code and far less chance that different libraries would attempt 
to define literals with the same suffix.

- brent


In This Thread