[#30995] [Bug #3523] win32 exception c0000029 on exit using fibers — B Kelly <redmine@...>

Bug #3523: win32 exception c0000029 on exit using fibers

19 messages 2010/07/02

[#31100] [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...>

Hello,

26 messages 2010/07/07
[#31148] Re: [rubysoc] Queue C-extension patch to come — Roger Pack <rogerdpack2@...> 2010/07/09

> As this it my first patch to Ruby, I don't know where to begin with.

[#31320] Re: [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...> 2010/07/16

Sorry for leaving this thread for so long. I've tried to finish the

[#31322] Re: [rubysoc] Queue C-extension patch to come — Aaron Patterson <aaron@...> 2010/07/16

On Sat, Jul 17, 2010 at 06:55:35AM +0900, Ricardo Panaggio wrote:

[#31324] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

NB: I am Ricardo's mentor for this project.

[#31331] Re: [rubysoc] Queue C-extension patch to come — Benoit Daloze <eregontp@...> 2010/07/17

On 17 July 2010 06:00, Caleb Clausen <vikkous@gmail.com> wrote:

[#31332] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

On 7/17/10, Benoit Daloze <eregontp@gmail.com> wrote:

[#31138] Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...>

Hi!

14 messages 2010/07/08
[#31146] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 7:04), Nikolai Weibull wrote:

[#31149] Re: Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...> 2010/07/09

On Fri, Jul 9, 2010 at 06:20, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#31150] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 18:28), Nikolai Weibull wrote:

[#31217] [Bug #3562] regression in respond_to? — Aaron Patterson <redmine@...>

Bug #3562: regression in respond_to?

14 messages 2010/07/12

[#31269] [Bug #3566] memory leak when spawning+joining Threads in a loop — Eric Wong <redmine@...>

Bug #3566: memory leak when spawning+joining Threads in a loop

14 messages 2010/07/13

[#31399] [Backport #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string — Dreamcat Four <redmine@...>

Backport #3595: Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

17 messages 2010/07/21

[#31459] [Bug #3607] [trunk/r28731] Gem.path has disappeared? — Ollivier Robert <redmine@...>

Bug #3607: [trunk/r28731] Gem.path has disappeared?

22 messages 2010/07/23

[#31519] [Bug #3622] Net::HTTP does not wait to send request body with Expect: 100-continue — Eric Hodel <redmine@...>

Bug #3622: Net::HTTP does not wait to send request body with Expect: 100-continue

9 messages 2010/07/28

[ruby-core:31439] Re: [Feature #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

From: Joshua Ballanco <jballanc@...>
Date: 2010-07-22 08:38:17 UTC
List: ruby-core #31439
On Jul 21, 2010, at 11:26 PM, Dreamcat Four wrote:

> Issue #3595 has been updated by Dreamcat Four.
> 
> 
> Hi,
> Well I was unaware of this. In that case the argument Bill has can be seen as an issue. Reading a file with the IO object would read the ASCII tags, and you wouldn't know what to do. The tags map to both Ascii 7-bit and ascii 8-bit anyway.

Keep in mind, there isn't really any such thing as 8-bit ASCII. The ASCII standard only defines 128 characters. This is why ASCII-8BIT == BINARY. The "ASCII" part implies that there are no multibyte characters, the "8BIT" implies that there are no invalid character bytes (even though there are only, strictly speaking, 7 bits worth of meaningful characters).

> What prompted me to report this:
> 
> Translating data from a Ruby hash object and simple Ruby types into a Plist representation. To give users a standard and appropriate way to differentiate between their Ruby strings which are either textual (ascii or unicode), and their persistent binary data.

I'm assuming that you're referring to OS X's plists? And I'm also assuming that you want to differentiate between dumping <string> nodes versus <data> nodes, yes? If so, the I'm afraid that encoding is not your issue. The issue is that Ruby (ab)uses String for "Strings" in the traditional sense and "Just someplace to put an arbitrary array of bytes".

This is something that I've been dealing with a lot, lately, and I'd been meaning to put forward a more thought out proposal. In Cocoa, there is NSString and friends for traditional strings, and NSData for arbitrary length data. I think a divide like this could be useful for Ruby in the future. In particular, as I said before the issue is not specific encodings, it's that encodings don't mean anything for binary data.

Think of it this way: What are the contents of a "String" object? Characters, right? The fact that these characters are stored as bytes is an implementation detail, and one that, if we could all just move toward a common encoding like Unicode, most programmers could forget about. Even today, the only reason you would need to know anything about encodings is if you were consuming characters from a source outside your control. More importantly, though, is that if you change the bytes as a consequence of a change to the encoding, the content of the String (i.e. the array of characters it represents) does not change. On the other hand, if you're overloading a String to store bytes, then a change in encoding is catastrophic. That's because what you were really storing wasn't a "String".

To get to the root of your problem: If you are using RubyCocoa or MacRuby, NSData is there for you (and you'll probably get improved performance to boot). If you want to do something in pure ruby to generate plists with <data> nodes, I would suggest creating a custom "Data" class for this purpose, and leave alone the topic of encodings.

Cheers,

Josh

In This Thread