19582-21708

19385-19707 subjects 19748-21854

I still can't write code that demonstrates weakref--does it actually work?
19582 [dave@pr gp o] This was a thread that started back in April, but which never really
19584 [mame@ts .n .] Though I don't know the previous thread, how about this?

[Bug #694] eof? call on a pty IO object causes application to exit
19583 [redmine@ru y] Bug #694: eof? call on a pty IO object causes application to exit
19652 [matz@ru y- a] pty uses exceptions to notify the process exit.  In my case, it
19653 [dave@pr gp o] That's what 1.8 seems to do.
19687 [dave@pr gp o] I wonder if the problem is that pty.c doesn't release the global lock,
19724 [matz@ru y- a] Actually, 1.9 releases the global lock, so there was a chance for

[Bug #692](Closed) non-ascii comment with Encoding.default_internal set raises Encoding::InvalidByteSequenceError
19585 [redmine@ru y] Issue #692 has been updated by Nobuyoshi Nakada.

[Bug #690](Closed) Ruby 1.9.1 preview1 build error
19589 [redmine@ru y] Issue #690 has been updated by Nobuyoshi Nakada.

[Feature #695] More flexibility when combining ASCII-8BIT strings with other encodings
19590 [redmine@ru y] Feature #695: More flexibility when combining ASCII-8BIT strings with other encodings
19646 [michael.seli] Feature #695 was closed & marked done, but unfortunately it does not seem
+ 19648 [duerst@it ao] I think it should have been marked part done, part rejected,
| 19650 [michael.seli] Some sort of explanation would also have been nice.
| 19658 [duerst@it ao] Sometimes things just happen. Often, that's enough, and
| 19662 [michael.seli] I am hoping that there is a way of achieving the simplicity without
+ 19649 [nobu@ru y- a] Martin kindly replied already, so I don't have to add his post
  + 19651 [michael.seli] There seems little point in making the effort to produce a patch if it is
  | 19654 [duerst@it ao] This has been discussed quite extensively, but rejected.
  + 19701 [michael.seli] ...

Re: 1.8.6, make test-all errors on MinGW
19591 [roger.pack@l] You may be able to use wireshark to see if the connection is indeed being reset.

[Bug #634] Time parsing works in 1.8 but not 1.9
19592 [redmine@ru y] Issue #634 has been updated by Roger Pack.

[Feature #695] More flexibility when combining ASCII-8BIT strings with other encodings
19593 [redmine@ru y] Issue #695 has been updated by Michael Selig.

[Bug #633] dl segfaults on x86_64-linux systems
19594 [redmine@ru y] Issue #633 has been updated by Roger Pack.

[Feature #695](Closed) More flexibility when combining ASCII-8BIT strings with other encodings
19595 [redmine@ru y] Issue #695 has been updated by Nobuyoshi Nakada.
19598 [michael.seli] Wow, that was quick!

Future of Continuations
19599 [ruben.schemp] In my master thesis I dealt with Continuations Based Web Servers and
+ 19607 [pbrannan@at ] They restore the state of the stack, not the state of the heap.  This is
| 19609 [ko1@at ot ne] right.
| 19645 [pandyacus@sb] This seems to assume that there is stack copying needed to make fibers work across threads, but it isn't clear that is the only way. If there is an indirect reference to thread local storage in the context of the fiber, there might be issues. Are there systems, libraries or structures where it is true?
| 19659 [ruben.schemp] Thanks for your comments and clarifications!
+ 19608 [james@gr yp ] Ruby is not a "web programming language."  It's a programming language
+ 19611 [roger.pack@l] Apparently with 1.8.x continuations lead to memory leak [or so I've
+ 19636 [mneumann@nt ] Interesting. I implemented a Seaside-like framework with a lot of help
+ 19637 [mneumann@nt ] Interesting. I implemented a Seaside-like framework with a lot of help
+ 19640 [mneumann@nt ] Interesting. I implemented a Seaside-like framework with a lot of help

[Bug #696] 1.9.0-0 is more faster in factrial test
19601 [redmine@ru y] Bug #696: 1.9.0-0 is more faster in factrial test

test failure in r20022
19604 [mike@st k. a] ...
+ 19606 [mike@st k. a] ...
+ 19612 [roger.pack@l] Fascinating.  I get this "sometimes" too-- OS X.
  19628 [roger.pack@l] Looks like the problem is that if you have two threads writing to the
  19672 [roger.pack@l] Does anybody see any drawbacks to adding a ruby mutex to every rb_io_t

[Bug 1.9] gem_prelude.rb always require rubygems
19610 [matz@ru y- a] By recent change, gem_prelude always requires rubygems/defaults.rb and
19619 [drbrain@se m] require 'rubygems/defaults/operating_system'
19623 [matz@ru y- a] Yes, please.  It will be much better.
19627 [nobu@ru y- a] It will still require "rubygems/defaults/operating_system" and
19647 [matz@ru y- a] It works anyway.  It's much better than not working.

Result of backticks
19618 [jdeville@mi ] `echo disc world` returns "disc world\n"
+ 19620 [roger.pack@l] I'd guess that it returns "exactly whatever echo returns" which
| 19621 [jdeville@mi ] Heh,
| 19622 [jdeville@mi ] Doh, scratch that. Echo (and Dir) produce \r\n, and Ruby strips it.
+ 19625 [usa@ga ba ec] It's spec.

[Bug #696] 1.9.0-0 is more faster in factrial test
19624 [redmine@ru y] Issue #696 has been updated by Roger Pack.

[Bug #701] Wrong behaviour of StringIO#ungetc
19632 [redmine@ru y] Bug #701: Wrong behaviour of StringIO#ungetc

The Effects of $KCODE
19633 [james@gr yp ] Can someone please confirm that $KCODE has these effects in Ruby 1.8?

performance issues with --enable-pthread on Solaris.
19634 [Paul.Vandenb] ...
19639 [roger.pack@l] so 1.8.7 with and without pthread were the same--about as fast as
19704 [Paul.Vandenb] Mmmm redid the 1.8.7 tests.  Now the results are a little different.

Odd TypeError in inject (1.9.1 preview 1)
19660 [dblack@ru yp] I think this should return 0. Anything I'm missing?
+ 19663 [lukfugl@gm i] ...
| 19664 [nobu@ru y- a] Then what do you expect to be called?
| 19665 [lukfugl@gm i] ...
| 19666 [dblack@ru yp] I thought that the idiom was (&:sym), not just (:sym). I certainly
| 19667 [lukfugl@gm i] ...
+ 19682 [matz@ru y- a] According to [ruby-core:19666], you expect [].inject(0) to work as
  19683 [dblack@ru yp] I think I was starting from the 1.8 behavior, and not grasping the
  + 19684 [B.Candler@po] [Apologies for broken threading, it shouldn't happen again]
  | 19692 [matz@ru y- a] See [ruby-core:19691].  It's an issue with #next.
  | 19694 [B.Candler@po] compared to each { ...block... }, since the block can return a value.
  | + 19695 [B.Candler@po] implemented as a layer on top of #each (by creating a fiber which in turn
  | | 19696 [B.Candler@po] I think I understand it (roughly) now, and it doesn't need anything clever
  | + 19699 [matz@ru y- a] Not really.  Both #inject and #next depends on #each.  Maybe I
  + 19691 [matz@ru y- a] Indeed 1.8.6 returns 0 for [].inject(0), but it's kinda odd corner

[Bug #703] string output duplication occurs if the same file descriptor written to in different threads
19668 [redmine@ru y] Bug #703: string output duplication occurs if the same file descriptor written to in different threads
19676 [matz@ru y- a] It's not related to ruby-dev:32566, I think.
19678 [nobu@ru y- a] It could reproduced with full ruby, but not with miniruby nor
19686 [nobu@ru y- a] It seems a mere timing and probability issue.  And seems solved

[Feature #440] Better introspection for methods (declaring class, arity)
19669 [redmine@ru y] Issue #440 has been updated by Roger Pack.

module_function
19670 [Tomas.Matous] It seems that module_function with no parameters doesn't trigger creation o=

[Bug #704] delegate.rb will only delegate to specifically-named delegate object
19671 [redmine@ru y] Bug #704: delegate.rb will only delegate to specifically-named delegate object

[Bug #703] string output duplication occurs if the same file descriptor written to in different threads
19673 [redmine@ru y] Issue #703 has been updated by hemant kumar.

[Bug #706] Segmentation fault in garbage collector ruby 1.8.7 (2008-10-31 revision 0) [x86_64-linux]
19674 [redmine@ru y] Bug #706: Segmentation fault in garbage collector ruby 1.8.7 (2008-10-31 revision 0) [x86_64-linux]
19677 [matz@ru y- a] Extension related problems cannot be identified without source code.

[Bug #696] 1.9.0-0 is more faster in factrial test
19675 [redmine@ru y] Issue #696 has been updated by Alexandre Riveira.

[Feature #707] Documentation for Enumerator chaining
19679 [redmine@ru y] Feature #707: Documentation for Enumerator chaining

[Feature #708] Lazy Enumerator#select, Enumerator#map etc.
19680 [redmine@ru y] Feature #708: Lazy Enumerator#select, Enumerator#map etc.

[Feature #709] Enumerator#+
19681 [redmine@ru y] Feature #709: Enumerator#+
19688 [roger.pack@l] So you expect this to output

[Feature #707] Documentation for Enumerator chaining
19685 [redmine@ru y] Issue #707 has been updated by Brian Candler.

[Feature #709] Enumerator#+
19689 [redmine@ru y] Issue #709 has been updated by Brian Candler.

[Feature #710] Pathname#=~
19690 [redmine@ru y] Feature #710: Pathname#=~
19693 [nobu@ru y- a] In Ruby, Regexp#=~ would be used more preferably than

Different gem flavors for 1.8 and 1.9
19697 [kbloom@gm il] I'm updating my SqlStatement gem http://sqlstatement.rubyforge.org/ to be
19698 [luislavena@g] Cool!

[Feature #710] Pathname#=~
19700 [redmine@ru y] Issue #710 has been updated by James M. Lawrence.

[Feature #711] M17N of irb
19702 [redmine@ru y] Feature #711: M17N of irb

[Feature #712] M17N of erb
19703 [redmine@ru y] Feature #712: M17N of erb

[Bug #193] Crash during build on Mac OS 10.5.3/PPC when configured with --enable-pthread
19705 [redmine@ru y] Issue #193 has been updated by Wataru Kimura.

[Bug #286] open-uri leaking file handles
19706 [redmine@ru y] Issue #286 has been updated by Elliot Temple.

updating the tracker
19708 [roger.pack@l] I am contemplating sending a message to each open ticket on the old
19709 [tom@in oe he] Works for me.  Sadly, GForge has no option to leave a tracker

build error with "nightly snapshot"
19710 [rogerpack200] With mingw and the current 1.9 "nightly snapshot"  I currently get
19717 [matz@ru y- a] I think we've fixed this issue.  Try again tomorrow.
19734 [rogerpack200] I believe that issue was fixed.
19793 [nobu@ru y- a] It is curious.  How are topdir extout defined in the Makefile?
19802 [rogerpack200] Interesting--I successfully compiled it a few days ago.  I might have
+ 19949 [nobu@ru y- a] Yes, but I don't say it must not work.  Just no one has
+ 19951 [rogerpack200] Appears that if you make, then compile the extensions "by hand" then
  + 19952 [nobu@ru y- a] Sounds strange.  Each commands are run in each processes, so
  + 19953 [luislavena@g] The trick is the usage of MinGW compiler + 'make' from MSYS (which is

[Bug #713] DST bug in Logger
19711 [redmine@ru y] Bug #713: DST bug in Logger
19712 [nakahiro@sa ] Please check upstream version of logger.rb at

[Bug #714] Socket bug in Ruby-mswin32
19713 [redmine@ru y] Bug #714: Socket bug in Ruby-mswin32

[Feature #715] Ruby interpreter should understand UTF-8 symbols with special meaning
19714 [redmine@ru y] Feature #715: Ruby interpreter should understand UTF-8 symbols with special meaning
+ 19715 [ryand-ruby@z] doesn't this sum up at least one of the problems with the proposal?
+ 19722 [ shot@ho .p ] That said, and as much as my idealism supports the above, I=E2=80=99m again=

[Bug #714] Socket bug in Ruby-mswin32
19716 [redmine@ru y] Issue #714 has been updated by Roger Pack.

[Bug #717] Unneccesary statement in lib/irb.rb
19718 [redmine@ru y] Bug #717: Unneccesary statement in lib/irb.rb

[Bug #717](Closed) Unneccesary statement in lib/irb.rb
19719 [redmine@ru y] Issue #717 has been updated by Yukihiro Matsumoto.

[Bug #718] Emacs ruby-mode does not show comment #@var correctly
19720 [redmine@ru y] Bug #718: Emacs ruby-mode does not show comment #@var correctly

[Bug #719] yaml not precise on some strings
19721 [redmine@ru y] Bug #719: yaml not precise on some strings

[Bug #714] Socket bug in Ruby-mswin32
19723 [redmine@ru y] Issue #714 has been updated by Heesob Park.

[Bug #720] [patch] autoconf changes needed for uClibc stdio
19725 [redmine@ru y] Bug #720: [patch] autoconf changes needed for uClibc stdio

[Bug #703](Closed) string output duplication occurs if the same file descriptor written to in different threads
19726 [redmine@ru y] Issue #703 has been updated by Nobuyoshi Nakada.

[Bug #714] Socket bug in Ruby-mswin32
19727 [redmine@ru y] Issue #714 has been updated by Roger Pack.

[Bug #721] select in windows accepts too many fd's
19728 [redmine@ru y] Bug #721: select in windows accepts too many fd's

default should be --enable-shared ?
19729 [rogerpack200] would it make sense for the default to be --enable-shared for a
21398 [wycats@gm il] I'd like to +1 this. I ran into some issues today with the preview that

[Bug #722] optparse needs patch in 1.9
19730 [redmine@ru y] Bug #722: optparse needs patch in 1.9

use of require thread safety
19731 [rogerpack200] I'm sure this has been discussed before, but...should there be
+ 19732 [charles.nutt] We've had some long discussions about this on the JRuby lists as well.
+ 19796 [nobu@ru y- a] While a thread is requiring a given file, another thread which
  + 19798 [rogerpack200] Currently with 1.8.7 (for me) the secondmost thread continues
  | 20732 [rogerpack200] Thanks for fixing that in 1.9 trunk.  [now if two threads request the
  | 20737 [charles.nutt] Is this behavior now specified? I don't remember this ever being resolved.
  | + 20739 [rogerpack200] Good question.
  | + 20769 [charles.nutt] first.rb
  |   + 20770 [gwtmp01@ma .] I admit to not thinking about this too much but shouldn't there be a
  |   | 20771 [charles.nutt] It certainly could, but that is a behavioral change; there's no way to
  |   | + 20776 [gwtmp01@ma .] Did you mean to say  "no way to *safely* require files in separate
  |   | | 20789 [charles.nutt] I mean that with a single require lock, there's no way to require files
  |   | + 20777 [shortcutter@] I don't think there should be locking involved for "load" as that
  |   |   20791 [charles.nutt] I tend to agree. Load explicitly bypasses things like $" population so
  |   |   20802 [shortcutter@] ...
  |   + 20795 [pbrannan@at ] What applications use circular requires?
  |     20798 [charles.nutt] It's not so much that they intend to be circular; more it's that many
  |     20832 [pbrannan@at ] I'm still having trouble imagining a case where code like the above is
  |     20833 [shortcutter@] I don't think it is a bug.
  |     20837 [pbrannan@at ] I see no deadlock here.  The lock is released as soon as each require
  |     + 20846 [charles.nutt] Perhaps it's a behavior that should be discouraged, or even qualifies as
  |     | + 20848 [charles.nutt] I think it's also worth pointing out that people probably don't
  |     | + 20857 [pbrannan@at ] Currently in a single-threaded application the above require call is a
  |     |   20864 [charles.nutt] It's not a no-op, though it may seem to be. It still needs to check if
  |     |   20896 [rogerpack200] I suppose as a bandaid to the real problem you could have each
  |     |   20897 [charles.nutt] Yeah, probably would work ok. Of course this also reminds me that
  |     + 20919 [shortcutter@] Probably.  But rather than deadlocking we could throw an exception
  + 19821 [pbrannan@at ] - Thread 1 requires a.rb
  | 19829 [charles.nutt] I've given this a lot of thought, and I'm just about positive the best
  | + 19840 [pbrannan@at ] Wouldn't this also break code?
  | | 19847 [charles.nutt] It would break code that's doing what it shouldn't, i.e. requiring the
  | | + 19852 [pbrannan@at ] I'd rather have it fail predictably than fail due to a race condition.
  | | | 19854 [charles.nutt] A hard failure (when a new thread tries to start requiring a script an
  | | + 19853 [matz@ru y- a] Isn't that unavoidable when combined with autoload?
  | |   19855 [Thomas.Enebo] Autoload, in general, is a bad idea in a multiple thread environment.
  | |   19859 [matz@ru y- a] I agree.  But sometimes it's up to library author's choice, not ours.
  | |   19860 [charles.nutt] I think in that case helping the author realize their mistake by raising
  | |   19862 [dave@pr gp o] It would seem that many of the global $ variables would need
  | |   + 19863 [charles.nutt] A single global lock would avoid deadlock...but would also prevent any
  | |   | 19865 [wycats@gm il] What about a hash of global locks keyed on file name? Or would that be
  | |   + 19864 [dooby@d1 .k ] Charlie commented on mutex at [ruby-core:19732]
  | + 19841 [rogerpack200] A safe way would probably be to raise if a file is required twice
  |   19849 [charles.nutt] Not a bad idea, but then again I'm generally in favor of smacking users
  + 21651 [charles.nutt] I never got an answer about whether this is now specified behavior. Keep
    21653 [matz@ru y- a] I propose that two or more separated threads may not load same library
    + 21654 [akr@fs j. rg] Agreed.
    | 21655 [matz@ru y- a] If some one write a patch, I am pleased to merge it.
    | 21659 [nobu@ru y- a] Currentry, it will cause a fatal error.  By checking before
    | 21664 [akr@fs j. rg] I couldn't see a fatal error.
    | 21687 [kbloom@gm il] If you can check and emit a fatal error (or warning) then couldn't you
    | 21688 [charles.nutt] Use a reentrant lock and proceed to double-require?
    | 21708 [kbloom@gm il] I may be in over my head here. I'm having a trouble imagining a situation
    + 21656 [charles.nutt] Currently JRuby will not allow the same library to load twice, but it
      21671 [matz@ru y- a] Yes.
      21675 [rogerdpack@g] Would it be possible to backport this functionality to 1.8.x, too?
      21677 [charles.nutt] JRuby will support this behavior in both 1.8 and 1.9 modes.

[Bug #722](Closed) optparse needs patch in 1.9
19733 [redmine@ru y] Issue #722 has been updated by Yukihiro Matsumoto.

[Bug #701](Closed) Wrong behaviour of StringIO#ungetc
19735 [redmine@ru y] Issue #701 has been updated by Yukihiro Matsumoto.

[Bug #704](Closed) delegate.rb will only delegate to specifically-named delegate object
19736 [redmine@ru y] Issue #704 has been updated by Yukihiro Matsumoto.

[Bug #723] Net::HTTPHeader doesn't check the type of the 'value'
19737 [redmine@ru y] Bug #723: Net::HTTPHeader doesn't check the type of the 'value'
19817 [matz@ru y- a] The report lacks the situation info where the error happened, so I

[Bug #559](Closed) WEBrick should use #bytesize instead of #size
19738 [redmine@ru y] Issue #559 has been updated by Yukihiro Matsumoto.

[Bug #724] webrick httpresponse wrong content-length
19739 [redmine@ru y] Bug #724: webrick httpresponse wrong content-length

[Bug #725] Synchronized block in finalizer-method results in deadlock/ crash of the interpreter
19740 [redmine@ru y] Bug #725: Synchronized block in finalizer-method results in deadlock/ crash of the interpreter
19742 [nobu@ru y- a] Finalizers run in sole thread, so you don't need / can't use synchronization.

[Bug #725] Synchronized block in finalizer-method results in deadlock/ crash of the interpreter
19741 [redmine@ru y] Issue #725 has been updated by Sebastian Morawietz.

[Bug #726] erb references $KCOD
19743 [redmine@ru y] Bug #726: erb references $KCOD

[Bug #727] Signal(CLD) seems not to work on OS X
19744 [redmine@ru y] Bug #727: Signal(CLD) seems not to work on OS X

A bug of the monkey patch for REXML
19745 [shugo@ru y- ] A bug of the monkey patch to fix the DoS vulenerability in REXML has

[Bug #728] Segmentation fault with Ruby 1.8.7-p22 from st_lookup
19746 [redmine@ru y] Bug #728: Segmentation fault with Ruby 1.8.7-p22 from st_lookup
19757 [matz@ru y- a] I couldn't reproduce the problem.  Do I have to use version 0.2.1 of

[Bug #724](Closed) webrick httpresponse wrong content-length
19747 [redmine@ru y] Issue #724 has been updated by Yukihiro Matsumoto.
threads.html
top