[#21039] Happy new year and... moving Ruby development to Git? — Michael Klishin <michael.s.klishin@...>
Happy new year everyone.
On Jan 1, 2009, at 6:42 AM, Michael Klishin wrote:
On Thu, Jan 1, 2009 at 11:22 AM, James Gray <james@grayproductions.net> wrote:
brabuhr@gmail.com writes:
Quoting Michael Klishin <michael.s.klishin@gmail.com>:
Hi,
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, Jan 2, 2009 at 12:18 PM, Florian Gilcher <flo@andersground.net> wrote:
My opinion:
My two cents:
Eust痃uio Rangel wrote:
On Sat, Jan 3, 2009 at 21:40, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Nikolai Weibull wrote:
On Sat, Jan 3, 2009 at 10:39 PM, M. Edward (Ed) Borasky
Giuseppe Bilotta wrote:
On Sun, Jan 4, 2009 at 12:14, Joel VanderWerf <vjoel@path.berkeley.edu>wrote:
Michael Klishin wrote:
On Mon, Jan 5, 2009 at 12:29 PM, Michael Klishin
On 05.01.2009, at 16:10, RadosナＢw BuナＢt wrote:
On Mon, Jan 05, 2009 at 10:22:49PM +0900, Michael Klishin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, Jan 5, 2009 at 10:06 AM, Florian Gilcher <flo@andersground.net>wrote:
On Jan 1, 2009, at 04:42 AM, Michael Klishin wrote:
On Sat, Jan 3, 2009 at 00:34, Eric Hodel <drbrain@segment7.net> wrote:
On Jan 2, 2009, at 17:25 PM, Nikolai Weibull wrote:
> I think I'm entitled to an opinion on the subject because I am a
On Jan 6, 2009, at 12:16 PM, Brent Roman wrote:
On Wed, Jan 07, 2009 at 04:03:12AM +0900, James Gray wrote:
Hi,
On Sat, Jan 3, 2009 at 4:48 AM, Michael Klishin
On Sat, Jan 03, 2009 at 12:48:09PM +0900, Michael Klishin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, Jan 5, 2009 at 4:59 PM, Florian Gilcher <flo@andersground.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, Jan 5, 2009 at 6:45 PM, Florian Gilcher <flo@andersground.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
[#21094] [Bug #975] ruby curses extension does not support multibyte characters — Michal Suchanek <redmine@...>
Bug #975: ruby curses extension does not support multibyte characters
[#21097] [Bug #977] caller for all threads patch — Roger Pack <redmine@...>
Bug #977: caller for all threads patch
I made a patch to Thread#caller(lev=1). It may be more flexible than
One thing I think might be cool is rather than raising an error for a
On Mon, Jun 8, 2009 at 5:06 PM, SASADA Koichi<ko1@atdot.net> wrote:
[#21180] how to use git to work with MBARI patches — Stephen Bannasch <stephen.bannasch@...>
At 3:16 AM +0900 1/7/09, Brent Roman asked in a previous thread about git:
[#21181] ruby_version changes in 1.9.1-rc1 — "Luis Lavena" <luislavena@...>
Hello All,
[#21238] [Bug #996] IRB doesn't work anymore with ruby-1.9.1-rc1 on MinGW — Chauk-Mean PROUM <redmine@...>
Bug #996: IRB doesn't work anymore with ruby-1.9.1-rc1 on MinGW
[#21244] [Bug #999] SSL & ZIP missing from ruby-1.9.1-preview1-i386-mswin32 — William Mason <redmine@...>
Bug #999: SSL & ZIP missing from ruby-1.9.1-preview1-i386-mswin32
Issue #999 has been updated by Luis Lavena.
[#21259] Do I need a special build arg to get irb to accept utf characters on OSX — Dave Thomas <dave@...>
I'm seeing very strange behavior at the irb prompt with ruby 1.9.1
On 1/11/09 1:06 PM, Dave Thomas wrote:
[#21269] [Bug #1005] Strange behaviour of File.directory? under Windows — Alex Fortuna <redmine@...>
Bug #1005: Strange behaviour of File.directory? under Windows
[#21289] MRI 1.8.6 bug - exit is ignored if ensure clause throws exception which is caught by outer rescue — Shri Borde <Shri.Borde@...>
The following code snippet does print "after foo" when using MRI 1.8.6 on Windows Vista, showing that exit is ignored. Any thoughts on whether this is by design, a known bug, or a new issue? If it's the latter, should I open a bug for it?
[#21302] [PATCH] drastically improve rb_waitpid for short-lived children — Evan Phoenix <evan@...>
This evening I wrote this patch while helping a friend diagnose why,
[#21309] Current status of 1.9.1 RC2 — "Yugui (Yuki Sonoda)" <yugui@...>
-----BEGIN PGP SIGNED MESSAGE-----
[#21315] Proc-as-Binding is out again? — Charles Oliver Nutter <charles.nutter@...>
1.8 can use a proc as a binding:
It seems to be more interface based rather than disallowing the access
[#21339] [Bug #1010] Ruby-1.9's rake sh doesn't work on Windows (but fix provided) — Chauk-Mean Proum <redmine@...>
Bug #1010: Ruby-1.9's rake sh doesn't work on Windows (but fix provided)
Issue #1010 has been updated by Chauk-Mean Proum.
[#21345] [Bug #1011] Chinese GB18030 transcoding is breaking build at r21509 — Luis Lavena <redmine@...>
Bug #1011: Chinese GB18030 transcoding is breaking build at r21509
[#21383] [Bug #1019] irb/xmp fails because StringInputMethod doesn't support #encoding — Dave Thomas <redmine@...>
Bug #1019: irb/xmp fails because StringInputMethod doesn't support #encoding
[#21399] Proposal: Module#copy_method — Yehuda Katz <wycats@...>
I'd like it to be possible to copy methods from one module to another. The
2009/1/18 Yehuda Katz <wycats@gmail.com>:
Excerpts from Pit Capitain's message of Sun Jan 18 11:23:48 +0200 2009:
Yehuda Katz wrote:
AOP requires being able to hook into method dispatch, which either requires
Yehuda Katz wrote:
So I guess the question is... what's wrong with the implementation ;)
Yehuda Katz wrote:
Just FYI, the define_method version fails if your method requires the use of
I believe that methods (and blocks defined as methods via method_defined) are somehow closed over the module that declares them so that "super" can find the right module/class whose parent's method to call. At least they are in IronRuby :)
Hi,
Hi,
Yukihiro Matsumoto wrote:
Hi,
For my use-case, it would be ok to support copying methods to ANY module,
On Tue, Jan 20, 2009 at 10:15, Yehuda Katz <wycats@gmail.com> wrote:
[#21444] ruby 1.9 hashes, etc. — "Roger Pack" <rogerdpack@...>
I noticed in the NEWS file that 1.9 has more compacted hashes--does it then
[#21448] [PATCH] Allow building ruby with mingw — Alexey Borzenkov <snaury@...>
---
[#21454] [Feature #1027] Dir.home — Kazuhiro NISHIYAMA <redmine@...>
Feature #1027: Dir.home
Hi,
Excerpts from Nobuyoshi Nakada's message of Wed Jan 21 05:19:23 +0200 2009:
[#21458] Repost: Evaluation order of block pass versus arguments — Charles Oliver Nutter <charles.nutter@...>
I posted this nearly a year ago and never got any replies. I'm reposting
[#21460] Array concat loops sometimes taking large amounts of "system" time. — Ron Mayer <rm_rails@...>
On both ruby1.8 and ruby1.9, about half the time when I run loops like this:
[#21473] Time.gm give me ArgumentError out of range (ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]) — Claudio Fiorini <claudio@...>
Hi all,
[#21492] 2 small warning fixes for 1.9.1 — Marcus Rueckert <darix@...>
hi,
[#21495] [Bug #1033] wrong documentation for Kernel#catch — Patrik Wenger <redmine@...>
Bug #1033: wrong documentation for Kernel#catch
[#21550] [Feature #1046] request: ability to run without specifying .rb — Roger Pack <redmine@...>
Feature #1046: request: ability to run without specifying .rb
Issue #1046 has been updated by Roger Pack.
Hi,
>
Hi,
> |Oh sorry--I meant that you would probably find my answer [that I am lazy and
[#21552] [Feature #1047] request: getters, setters for the GC — Roger Pack <redmine@...>
Feature #1047: request: getters, setters for the GC
I agree that something in this direction should be done.
Issue #1047 has been updated by Yusuke Endoh.
[#21570] [Bug #1057] ripper does not compile with mingw — Charlie Savage <redmine@...>
Bug #1057: ripper does not compile with mingw
[#21598] [Bug #1060] mkmf refuses to find 3rd party extensions - ruby 1.9.1 trunk — Charlie Savage <redmine@...>
Bug #1060: mkmf refuses to find 3rd party extensions - ruby 1.9.1 trunk
[#21613] [Bug #1063] in `write': Not enough space - <STDOUT> (Errno::ENOMEM) on Windows XP — Nick Gorbikoff <redmine@...>
Bug #1063: in `write': Not enough space - <STDOUT> (Errno::ENOMEM) on Windows XP
Issue #1063 has been updated by Tinco Andringa.
[#21618] UID Too Big, A Bug? — James Gray <james@...>
Is this a bug in Ruby?
[#21640] [Bug #1068] Ruby Cannot Handle Some UIDs — James Gray <redmine@...>
Bug #1068: Ruby Cannot Handle Some UIDs
On Wed, Jan 28, 2009 at 05:00:05PM +0100, James Gray wrote:
Hi,
On Thu, Jan 29, 2009 at 08:53:38AM +0100, Nobuyoshi Nakada wrote:
Ondrej Bilka wrote:
On Jan 29, 2009, at 3:43 AM, Urabe Shyouhei wrote:
On Thu, Jan 29, 2009 at 8:33 AM, James Gray <james@grayproductions.net>wrote:
On Jan 29, 2009, at 7:57 AM, Rocky Bernstein wrote:
On Thu, Jan 29, 2009 at 9:04 AM, James Gray <james@grayproductions.net>wrote:
One small edit I'm sorry I can resist since after all this *is* a
[#21701] [Feature #1081] add File::write() convenience method — Suraj Kurapati <redmine@...>
Feature #1081: add File::write() convenience method
Issue #1081 has been updated by Yusuke Endoh.
Hi,
Hi,
Is it intended that the length of the leading nulls are not included
Hi,
>> Is it intended that the length of the leading nulls are not included
Hi,
Teamwork. :-)
2010/3/6 Run Paint Run Run <runrun@runpaint.org>:
[#21702] [Feature #1082] add Object#singleton_class method — Suraj Kurapati <redmine@...>
Feature #1082: add Object#singleton_class method
Issue #1082 has been updated by Suraj Kurapati.
Hi,
> We haven't met any consensus of a name for the method.
+1 for Eigenclass
+1 for metaclass, as is it compatible with ActiveSupport, Rubinius and _why. Also, it confuses people with a Python background.
Hi,
Hi,
Hi,
On Mon, Jan 4, 2010 at 9:41 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
On 23.02.10 08:14, Shugo Maeda wrote:
Hi,
Issue #1082 has been updated by Yusuke Endoh.
Hi,
[ruby-core:21353] Re: Supporting Thread.critical=with native threads
Is opening a bug the recommended way to get the spec changed for 1.9*? IMO, nobody *should* depend on descheduling of other threads even on MRI. Given that you do not know where the other threads may be when they were descheduled, I think it is close to impossible to access a piece of data with Thread.critical==true sometimes, and sometimes without setting Thread.critical=true. I have written up the details of the proposed behavior here so that we can think of all the interactions with other APIs etc: http://blogs.msdn.com/shrib/archive/2009/01/07/proposed-spec-for-ruby-s-thread-critical.aspx Thanks, Shri -----Original Message----- From: Charles.O.Nutter@sun.com [mailto:Charles.O.Nutter@sun.com] On Behalf Of Charles Oliver Nutter Sent: Saturday, January 10, 2009 7:21 AM To: ruby-core@ruby-lang.org Subject: [ruby-core:21245] Re: Supporting Thread.critical=with native threads I'm starting come around to Shri's idea of critical= being represented as simply a global lock. Shri makes a very strong case that the descheduling behavior of critical is a side effect that almost nobody depends on. I'd go further and say that nobody *should* depend on it, since on e.g JRuby there's no guarantee when or if the other threads will completely deschedule. Representing critical= as a global reentrant mutex would also reduce the overhead parallel-threaded impls deal with to constantly checkpoint, and would codify a very clear and specific meaning for critical sections. It would not be a recommended way to criticalize a block of code, since it could bottleneck if several threads try to criticalize. But it would at least be more reasonable to support on parallel-threaded impls than what we have today. Interestingly enough, a global critical lock also is compatible with what 1.8 does right now, since 1.8's total descheduling of other threads is a superset of global lock behavior. The only bits that are fuzzy would be threads explicitly scheduled or spun up during a critical section, and we'd need to discuss those. Thoughts? I almost want to just make this change in JRuby right now, since it's so much cleaner. - Charlie