[#46049] [ruby-trunk - Feature #6590] Dealing with bigdecimal, etc gems in JRuby — "mrkn (Kenta Murata)" <muraken@...>
[#46078] [ruby-trunk - Feature #2565] adding hooks for better tracing — "mame (Yusuke Endoh)" <mame@...>
On Mon, Jul 02, 2012 at 03:06:59AM +0900, mame (Yusuke Endoh) wrote:
[#46127] [ruby-trunk - Feature #2565] adding hooks for better tracing — "vo.x (Vit Ondruch)" <v.ondruch@...>
[#46160] [ruby-trunk - Feature #6693][Open] Don't warn for unused variables starting with _ — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>
[#46163] [ruby-trunk - Feature #6695][Open] Configuration for Thread/Fiber creation — "ko1 (Koichi Sasada)" <redmine@...>
[#46172] [ruby-trunk - Feature #6697][Open] [PATCH] Add Kernel#Symbol conversion method like String(), Array() etc. — "madeofcode (Mark Dodwell)" <mark@...>
[#46236] [ruby-trunk - Bug #6704][Open] Random core dump — "trans (Thomas Sawyer)" <transfire@...>
[#46248] building ruby-1.9.3-p194 on AIX 6.1 TL05 SP06 — Perry Smith <pedzsan@...>
I am just now starting to debug this but hoped someone has already =
Hi Perry
Hi Perry,
[#46262] [ruby-trunk - Feature #6710][Open] new special binding specifier :isolated — "ko1 (Koichi Sasada)" <redmine@...>
[#46276] Lambdaification of Method Calls — Robert Klemme <shortcutter@...>
Hi,
[#46320] [ruby-trunk - Feature #6721][Open] Object#yield_self — "alexeymuranov (Alexey Muranov)" <redmine@...>
[#46339] [ruby-trunk - Bug #6724][Open] waaaaaaant! ( — "zenspider (Ryan Davis)" <redmine@...>
On Thu, Jul 12, 2012 at 08:58:36AM +0900, zenspider (Ryan Davis) wrote:
On Tue, Jul 17, 2012 at 6:27 PM, Aaron Patterson
[#46377] [ruby-trunk - Feature #6727][Open] Add Array#rest (with implementation) — "duckinator (Nick Markwell)" <nick@...>
[#46420] [ruby-trunk - Feature #6731][Open] add new method "Object.present?" as a counter to #empty? — "rogerdpack (Roger Pack)" <rogerpack2005@...>
[#46500] [ruby-trunk - Feature #6739][Open] One-line rescue statement should support specifying an exception class — Quintus (Marvin Gülker) <sutniuq@...>
[#46535] [ruby-trunk - Bug #6749][Open] rdoc of Time class (incorrect explanation of leap seconds) — "stomar (Marcus Stollsteimer)" <redmine@...>
Hi Eric,
On Jul 23, 2012, at 11:52 PM, [email protected] wrote:
Am 24.07.2012 19:44, schrieb Eric Hodel:
[#46546] Fwd: [ruby-cvs:43609] ko1:r36433 (trunk): * thread.c (rb_thread_call_without_gvl2): added. — SASADA Koichi <ko1@...>
Hi,
SASADA Koichi <[email protected]> wrote:
[#46553] [ruby-trunk - Feature #2565] adding hooks for better tracing — "tenderlovemaking (Aaron Patterson)" <aaron@...>
[#46564] Ruby under CI - Windows — Luis Lavena <luislavena@...>
Hello,
[#46574] [ruby-trunk - Feature #6762][Open] Control interrupt timing — "ko1 (Koichi Sasada)" <redmine@...>
I was suggesting "interruptible" as a better alternative for
[#46577] [ruby-trunk - Feature #6763][Open] Introduce Flonum technique to speedup floating computation on th 64bit environment — "ko1 (Koichi Sasada)" <redmine@...>
[#46586] [ruby-trunk - Bug #6764][Open] IO#read(size, buf) causes can't set length of shared string in trunk (2.0.0dev) — "nahi (Hiroshi Nakamura)" <nakahiro@...>
[#46641] [ruby-trunk - Bug #6780][Open] cannot compile zlib module, when cross-compiling. — "jinleileiking (lei king)" <jinleileiking@...>
[#46686] [ruby-trunk - Bug #6784][Open] Test failures related to numeric with x64 mingw — "h.shirosaki (Hiroshi Shirosaki)" <h.shirosaki@...>
[#46741] [ruby-trunk - Bug #6789][Open] parse.y compilation error due not updated id.h — "luislavena (Luis Lavena)" <luislavena@...>
[#46744] [ruby-trunk - Bug #6791][Open] ext/js on/generator/generator.c fails to compile on nightly build (AIX 6.1) — "pedz (Perry Smith)" <pedz@...>
Hi Perry,
[#46772] Ruby 1.9.3 release? — Charles Oliver Nutter <headius@...>
JRuby will soon release 1.7.0pre2, the second preview of 1.7. Perhaps
(2012/07/26 7:07), Charles Oliver Nutter wrote:
On Sat, Jul 28, 2012 at 10:59 PM, NARUSE, Yui <[email protected]> wrote:
[#46792] [ruby-trunk - Bug #6799][Open] Digest::*.hexdigest returns an ASCII-8BIT String — "Eregon (Benoit Daloze)" <redmine@...>
[#46832] [ruby-trunk - Bug #6807][Open] Can't compile ruby without ruby — "devcurmudgeon (Paul Sherwood)" <storitel@...>
[#46834] [ruby-trunk - Feature #6808][Open] Implicit index for enumerations — "trans (Thomas Sawyer)" <transfire@...>
[#46838] [ruby-trunk - Bug #6810][Open] `module A::B; end` is not equivalent to `module A; module B; end; end` with respect to constant lookup (scope) — "alexeymuranov (Alexey Muranov)" <redmine@...>
[#46854] [ruby-trunk - Feature #6811][Open] File, Dir and FileUtils should have bang-versions of singleton methods that fails silently — "prijutme4ty (Ilya Vorontsov)" <prijutme4ty@...>
[#46896] (Half-baked DRAFT) new `require' framework — SASADA Koichi <ko1@...>
Hi,
2012/7/31 SASADA Koichi <[email protected]>
On 31/07/12 13:29, SASADA Koichi wrote:
On Tue, Jul 31, 2012 at 12:07 PM, Alex Young <[email protected]> wrote:
On 01/08/2012, at 5:59 AM, Trans wrote:
(2012/07/31 21:29), SASADA Koichi wrote:
If one is considering importing archive files like zip, tar, jar, or gem, I
On Tue, Aug 7, 2012 at 8:48 AM, Rocky Bernstein <[email protected]> wrote:
[ruby-core:46573] Re: [ruby-trunk - Feature #6695] Configuration for Thread/Fiber creation
(2012/07/21 1:23), brixen (Brian Ford) wrote:
> I object to this API for setting stack size from Ruby for at least the two following reasons:
>
> 1. Stack size is an implementation detail and coupling Ruby code to details of a particular implementation is undesirable. Applications may be developed on one implementation and deployed on another. Or details affecting stack size may change between versions of a single implementation.
> 2. Stack size may depend on code not in the application or library (eg a library using Thread.new that calls application code or application code that different versions or implementations of a library).
>
> This setting should be a VM configuration option, not a Ruby method API.
Thank you for your comment.
This issue was started from Feature #3187 "Allow dynamic Fiber stack
size" by mperham (sorry, I had needed to show it).
mperham wants to specify fiber size per fiber because current fiber's
default size is too small to do complicated procedures and no way to
change this size.
Current default fiber's machine stack is small because of two reasons.
1. On the 32bit CPU, there are address space restriction and
Only a few thousand of fibers (and threads) can be made
if we allocate 1MB per fibers.
On the Fiber's usage, it is too small in some cases.
2. 1MB memory allocation hit performance in little.
(It is very weak reason for Rubyist)
To specify stack size, there are several way.
(1) VM configuration option (as Brian say)
(2) Global config by method (Thread.stack_size=) (as mperham proposed)
(3) Per-thread configuration (as I proposed)
I don't make any objection. It is acceptable.
However, we can't mix "small" and "large" size stack size in same
program. (2) is not perfect because it is not thread-safe.
BTW, the following API is thread-safe. Is it acceptable?
Thread.stack_size(size){
# only in this block, the stack size will be `size'
Thread.new(...){
...
}
}
On the #3187 thread, nagachika proposed more high level specifier
"factor" >https://bugs.ruby-lang.org/issues/3187#note-6>
> Fiber.stacksize = 2.0 # => twice the size of default stack size
I think using factor is also acceptable (the method name should be
changed, I guess). But we need to specify.
I also think more rough specifiers such as :small, :medium, :large are
also acceptable.
Fiber.new(size: :small){...}
(for example, at VM configuration with each sizes,
ruby -Xsmall_ss=4KB -Xmedium_ss=128KB -Xlarge_ss=1MB script
)
I don't care low-level or high-level specifier. But I think we need per
thread/fiber specifier.
----
From developer's perspective: We will increase default stack size for
Fiber (maybe same as Thread) after we introduce this feature. Most
case, larger stack size doesn't make problem (small stack size makes
problems such as mperham's situation).
If application or library needs huge number of Fibers, then this will
feature help.
----
> Thread#name doesn't need a new Thread.new API.
Yes. Thread#name and Thread#name= is enough if specify a name after
creation like:
Thread.new{
Thread.current.name = 'foo' # Thread.name may be also okay
...
}
But I want to specify a name at or before thread creation.
Is it only for me?
--
// SASADA Koichi at atdot dot net