[#7043] RUBYOPT versioning? — Caleb Tennis <caleb@...>
Matz, others:
[#7050] RDoc patches for BigDecimal in Ruby CVS — mathew <meta@...>
Now that 1.8.4 is out and the initial flurry of problem reports has died
[#7055] More on VC++ 2005 — Austin Ziegler <halostatue@...>
Okay. I've got Ruby compiling. I'm attempting to get everything in
Hi,
On 05/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
On 06/01/06, Austin Ziegler <halostatue@gmail.com> wrote:
Hi,
On 09/01/06, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:
[#7057] 64-bit Solaris READ_DATA_PENDING Revisited — Steven Lumos <steven@...>
[#7078] CRC - a proof-of-concept Ruby compiler — Anders Hkersten <chucky@...>
Hello everyone,
[#7084] mathn: ugly warnings — hadmut@... (Hadmut Danisch)
Hi,
Hadmut Danisch wrote:
Daniel Berger wrote:
*Dean Wampler *<deanwampler gmail.com> writes:
On Fri, 13 Jan 2006, mathew wrote:
On Fri, 13 Jan 2006, Mathieu Bouchard wrote:
ara.t.howard@noaa.gov wrote:
On Fri, 13 Jan 2006, James Britt wrote:
Dean Wampler <deanwampler gmail.com> writes:
On Sat, 14 Jan 2006, mathew wrote:
[#7100] core dump with ruby 1.9.0 (2006-01-10) and bdb-0.5.8 — Tanaka Akira <akr@...17n.org>
I found following test script dumps core.
>>>>> "T" == Tanaka Akira <akr@m17n.org> writes:
In article <200601110905.k0B950Op001713@moulon.inra.fr>,
[#7109] Calling flock with block? — Bertram Scharpf <lists@...>
Hi,
On Thu, 12 Jan 2006, Bertram Scharpf wrote:
[#7129] YAML.load({[]=>""}.to_yaml) — Tanaka Akira <akr@...17n.org>
I found that current YAML doesn't round trip {[]=>""}.
Hi.
Hi.
In article <20060115202203.D3624CA0.ocean@m2.ccsnet.ne.jp>,
[#7162] FileUtils.mv does not unlink source file when moving over filesystem boundary — Pav Lucistnik <pav@...>
Hi,
On Mon, 16 Jan 2006, Pav Lucistnik wrote:
[#7178] Add XHTML 1.0 Output Support to Ruby CGI — Paul Duncan <pabs@...>
The attached patch against Ruby 1.8.4 adds XHTML 1.0 output support to
[#7186] Ruby 1.9 and FHS — "Kirill A. Shutemov" <k.shutemov@...>
Build and install system changes:
[#7195] trouble due ruby redefining posix function eaccess — noreply@...
Bugs item #3317, was opened at 2006-01-24 15:33
[#7197] SSL-enabled DRb fds on SSLError? — ctm@... (Clifford T. Matthews)
Howdy,
On Jan 24, 2006, at 12:46 PM, Clifford T. Matthews wrote:
Patch worked fine against HEAD.
[#7203] bcc32's memory manager bug — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Hi.
[#7211] Some troubles with an embedded ruby interpreter — Matt Mower <matt.mower@...>
Hi folks,
[#7216] String#scan loops forefever if scanned string is modified inside block. — noreply@...
Bugs item #3329, was opened at 2006-01-26 10:55
[#7226] Fwd: Re: Question about massive API changes — "Sean E. Russell" <ser@...>
Hello,
Sean E. Russell wrote:
>
On 1/28/06, Caleb Tennis <caleb@aei-tech.com> wrote:
On Saturday 28 January 2006 17:13, Wilson Bilkovich wrote:
Sean E. Russell wrote:
[#7249] PATCH: append option to sysread — Yohanes Santoso <ysantoso-rubycore@...>
[#7259] TCP/UDP server weird lags on 1.8.4 linux — "Bill Kelly" <billk@...>
Hi !
[PATCH] Clarify String#scan Documentation (was Re: [ ruby-Bugs-3329 ] String#scan loops forefever if scanned string is modified inside block.)
* noreply@rubyforge.org (noreply@rubyforge.org) wrote:
> Summary: String#scan loops forefever if scanned string is modified inside block.
The subject doesn't really reflect what's actually happening.
> Initial Comment:
> ruby 1.8.4 (2005-12-24)
>
> Following code loops infinitely:
>
> a = " 12345678 "; a.scan(/\d/) {|s| a[3,2]='test'; s}
I'm not convinced this is a bug per-se. At least not any more than
"loop { }" is. What's actually happening is easier to demonstrate than
explain, so here goes (I'm using the caret as the position indicator).
" 12345678"
^ #=> no match
" 12345678"
^ #=> match, a = " 01test45678 "
" 12test45678 "
^ #=> match, a = " 12testst5678 "
" 12testst5678 "
^ #=> no match
... (snipped several irrelevant steps)
" 12testst5678 "
^ #=> no match
" 12testst5678 "
^ #=> match, a = " 12teststst5678 " <-- eek!
" 12teststst5678 "
^ #=> no match
" 12teststst5678 "
^ #=> match, a = " 12testststst5678 "
" 12testststst5678 "
^ #=> no match
" 12testststst5678 "
^ #=> match, a = " 12teststststst5678 "
(and so on, ad infinitum)
What honestly bothers me about this behavior is the converse: making the
receiver _smaller_ can cause the scanner to actually _miss_ matches,
like so:
a, strs = ' abcdef', []
a.scan(/[\w]/) { |s| a[0, 1] = ''; strs << s }
strs #=> ['a', 'c', 'e']
Most people would expect ['a', 'b', 'c, 'e', 'f'] there. This could be
"fixed" in a a couple of ways:
* Raise an exception if the receiver is modified during a scan (I don't
really like this option).
* Attempt to hack in offset adjustment into string modification. The
functions in question are rb_str_splice() and rb_str_aref(), although
I haven't investigated fully, so there may be other methods as well.
This is really my least-favorite option, because it doesn't handle the
case where someone modifies the receiver while keeping the length the
same.
* Leave things as they are and add a big warning to the String#scan
documentation. Personally, I prefer this option.
Anyway, attached is a patch that adds a brief note to String#scan. The
patch is against 1.8.4, but it applies clean to HEAD as well.
--
Paul Duncan <pabs@pablotron.org> OpenPGP Key ID: 0x82C29562
http://www.pablotron.org/ http://www.paulduncan.org/
Attachments (2)
diff -ur ruby-1.8.4/string.c ruby-1.8.4-string_doc/string.c --- ruby-1.8.4/string.c 2005-10-27 04:19:20.000000000 -0400 +++ ruby-1.8.4-string_doc/string.c 2006-01-26 11:52:03.000000000 -0500 @@ -4240,6 +4240,11 @@ * * <<cruel>> <<world>> * rceu lowlr + * + * <em>Note:</em> You probably don't want to modify the receiver string + * inside the block. Ruby will let you do it, but the result probably + * won't be what you expect or what you want. + * */ static VALUE