[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
nari@ruby-lang.org wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <ko1@atdot.net> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <ko1@atdot.net> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <ko1@atdot.net> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62533] [ruby-trunk - Bug #9829] [Assigned] Contradictions in docs for FileUtils::ln (and related functions)
From:
e@...
Date:
2014-05-11 19:52:43 UTC
List:
ruby-core #62533
Issue #9829 has been updated by Zachary Scott. Status changed from Open to Assigned ---------------------------------------- Bug #9829: Contradictions in docs for FileUtils::ln (and related functions) https://bugs.ruby-lang.org/issues/9829#change-46688 * Author: Mike Vastola * Status: Assigned * Priority: Normal * Assignee: Zachary Scott * Category: doc * Target version: * ruby -v: HEAD (r45880 at present) * Backport: ---------------------------------------- In the FileUtils module, to add simplicity and avoid duplication of code, a sort of coding paradigm exists for actions that read a filesystem object at one path and write a filesystem object at another. These are the functions mv, cp and ln, along with similarly named functions that perform the same actions with slightly different options. What they all have in common is that they take two primary arguments -- first a "source" path and then a "destination" -- and also that they share the same code structure along with a couple of private helper methods to accomplish their work. While this src/dest dynamic might be sufficient for creating hard/soft links given the level of abstraction Ruby is operating at with regard to the filesystem, it has resulted in the function parameters (to ln/ln_s/ln_sf/etc) themselves being named 'src' and 'dest' (presumably for consistency). Since RDoc takes the function declaration (with parameter names) and makes it large and bold atop the function description, 'symlink(src, dest)', for example, is the first thing you see if you're trying to understand how to use this function. But in terms of symlinks in particular, 'source' and 'destination' each have double meanings. I.e. Is destination the target of the newly-created symlink? Or is it the path of the symlink? Someone has clearly noticed this and tried to write in an alternate/duplicate function declaration somewhat below the real one with the arguments "old" and "new" this time rather than "src" and "dst", but this alternate declaration is still a lot lest prevalent than the official one, and new/old aren't the best terms to use anyway. I would propose that the documentation and functions be updated to take the parameter pairs (target, link/alias) in the case of a single link and (targets, directory) in the case of multiple. These are the terms that `man ln` uses. -- https://bugs.ruby-lang.org/