[#12073] Re: Ruby is much slower on linux when compiled with --enable-pthread? — "M. Edward (Ed) Borasky" <znmeb@...>

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

9 messages 2007/09/04

[#12085] New array methods cycle, choice, shuffle (plus bug in cycle) — David Flanagan <david@...>

Four new methods have been added to Array the Ruby 1.9 trunk. I've got

81 messages 2007/09/06
[#18036] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Charles Oliver Nutter <charles.nutter@...> 2008/07/31

Restarting this thread because I missed it the first time around and

[#18037] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Yukihiro Matsumoto <matz@...> 2008/07/31

Hi,

[#18038] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — "Gregory Brown" <gregory.t.brown@...> 2008/08/01

On Thu, Jul 31, 2008 at 7:50 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#18046] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Michael Neumann <mneumann@...> 2008/08/01

Gregory Brown wrote:

[#18048] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Charles Oliver Nutter <charles.nutter@...> 2008/08/01

Michael Neumann wrote:

[#18051] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — "David A. Black" <dblack@...> 2008/08/01

Hi --

[#18053] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — "Wilson Bilkovich" <wilsonb@...> 2008/08/01

On 8/1/08, David A. Black <dblack@rubypal.com> wrote:

[#18074] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — David Flanagan <david@...> 2008/08/01

Wilson Bilkovich wrote:

[#18080] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Yukihiro Matsumoto <matz@...> 2008/08/02

Hi,

[#18097] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — "Pit Capitain" <pit.capitain@...> 2008/08/03

2008/8/2 Yukihiro Matsumoto <matz@ruby-lang.org>:

[#18040] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Jim Weirich <jim.weirich@...> 2008/08/01

On Jul 31, 2008, at 7:33 PM, Charles Oliver Nutter wrote:

[#18056] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Thomas Enebo <Thomas.Enebo@...> 2008/08/01

Jim Weirich wrote:

[#18059] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Jim Weirich <jim.weirich@...> 2008/08/01

On Aug 1, 2008, at 1:53 PM, Thomas Enebo wrote:

[#12096] Next 1.8.6 on Sept. 22 — Urabe Shyouhei <shyouhei@...>

Hi all.

28 messages 2007/09/09

[#12201] how about actors implemented in ruby-core itself — hemant <gethemant@...>

Hi,

12 messages 2007/09/20

[#12248] arbitrary Unicode characters in identifiers? — David Flanagan <david@...>

12 messages 2007/09/26

[#12284] gc.c -- possible logic error? — Hugh Sasse <hgs@...>

I've been looking at Tom Copeland's memory allocation problem:

36 messages 2007/09/28
[#12329] Re: gc.c -- possible logic error? — Tanaka Akira <akr@...> 2007/10/01

In article <Pine.GSO.4.64.0709281302390.26570@brains.eng.cse.dmu.ac.uk>,

[#12305] Will 1.8.6 remain compiled with VC6? — "Luis Lavena" <luislavena@...>

Hello Core developers.

29 messages 2007/09/30
[#12306] Re: Will 1.8.6 remain compiled with VC6? — "Austin Ziegler" <halostatue@...> 2007/09/30

On 9/30/07, Luis Lavena <luislavena@gmail.com> wrote:

Re: String.force_encoding

From: Martin Duerst <duerst@...>
Date: 2007-09-29 07:07:44 UTC
List: ruby-core #12298
Hello David,

Sorry for doing half of the work in Japanese.

At 13:39 07/09/29, David Flanagan wrote:
>Hi,
>
>Nobu has just checked in a String.force_encoding method, which alters the encoding of a string (without, apparently modifying the underlying bytes at all: that is, it does not transcode from Unicode to SJIS or anything; it just changes the interpretation of the underlying bytes.)
>
>In the changelog, Martin Duerst is credited with suggesting the name force_encoding.  Could Martin or Nobu or Matz explain to non-Japanese speakers the thinking behind this name.  The last I heard it was going to be called "encode".  I can see that the name "encode" has hints of transcoding, and a user might think that it did more than it actually does.

Yes, this is exactly why I strongly advised against it.

>I don't want to re-open a discussion if this decision has already been firmly made.

It's not completely firm yet, it's just that Nobu had some code to check
in, and needed a name, and it's better to start with a long and strange
name and make it shorter if that's necessary than the other way round.

>I can live with force_encoding; it is not likely to be used often.  But I do want to suggest that it is awkward in English and I think we can do better.  My primary complaint is that "force" has connotations of "something you shouldn't do".  Putting "force" in a method name seems to me to be an inelegant substitute for ending the name with !
>
>The only parts of the ruby-dev thread I can understand were some of the other names considered.  One I liked was short and sweet: "as".

Yes, I think something like that is still under consideration for
the easy/frequent cases (in particular, 'changing' the encoding from
binary to something else). For that case, we definitely want something
shorter and more convenient. That will further reduce the number of
cases where you have to use force_encoding. Having something in
Shift_JIS, for example, and having to say "no, that was actually
EUC-JP" should really be pretty rare, I think.

>But for longer names, I think that either "set_encoding" or "alter_encoding" sound better than "force_encoding" and don't imply transcoding in the way that "encode" does.
>
>Also, one more request: can we make force_encoding accept nil as a way to specify ASCII (aka binary) encoding?

If we have an shorter method for moving from binary to something real,
we might also have a shorter method for the reverse. In the Japanese
thead, there was a suggestions of the names encode/decode, but I don't
like these, as explained above.

Also, for most practical purposes, US-ASCII and binary will probably
stay pretty close together, but at a recent meeting, we discussed
making clearer distinctions between US-ASCII (7-bit clean) and
binary, to reduce the number of cases where an exception is produced
because of encoding conflicts.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     


In This Thread