[#59445] [ruby-trunk - Bug #9335][Open] dynamic rescue regression in Ruby 2.1 — "fdr (Daniel Farina)" <daniel@...>
[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>
[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>
Issue #9343 has been updated by Eric Wong.
[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>
[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>
Issue #9356 has been updated by Shugo Maeda.
[#59517] [ruby-trunk - Bug #9357][Open] TracePoint's c_return traces return from call to 'trace' — "andhapp (Anuj Dutta)" <anuj@...>
[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>
Intersting challenge.
On 01/06/2014 04:52 PM, SASADA Koichi wrote:
On 01/06/2014 06:11 PM, Urabe Shyouhei wrote:
(2014/01/06 23:10), Urabe Shyouhei wrote:
On 01/07/2014 07:36 AM, SASADA Koichi wrote:
Hi, I noticed a trivial typo in array.c, and it fails building struct.c
Eric Wong <normalperson@yhbt.net> wrote:
Btw, I just pushed a few trivial fixes up (a few more failures below):
OK, last update of the night :o I think everything is good on 32-bit...
Eric Wong <normalperson@yhbt.net> wrote:
Btw, I started working on cachelined-time branch on git://80x24.org/ruby
Eric Wong <normalperson@yhbt.net> wrote:
On 01/06/2014 12:02 PM, Eric Wong wrote:
Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#59564] [ruby-trunk - Bug #9365][Open] Sporadic TypeError (wrong argument type Thread (expected VM/thread)) from IO#close (via Net:HTTP) — "ggiesemann (Geoffrey Giesemann)" <geoffwa@...>
Issue #9365 has been updated by Geoffrey Giesemann.
[#59728] Ruby 2.1.0 in Production: known bugs and patches — Aman Gupta <ruby@...1.net>
Last week, we upgraded the github.com rails app to ruby 2.1.0 in production.
Hello Aman,
[#59770] bug report did not propagate to ruby-core — Mean Login <meanlogin@...>
https://bugs.ruby-lang.org/issues/9416
[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>
A while ago I created a proof-of-concept that I intended to use in my
On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
Em 15-01-2014 19:42, Eric Hodel escreveu:
On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
Em 16-01-2014 19:43, Eric Hodel escreveu:
On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
Em 17-01-2014 19:53, Eric Hodel escreveu:
On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
Em 20-01-2014 21:51, Eric Hodel escreveu:
On 21 Jan 2014, at 02:01, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:
Em 21-01-2014 19:36, Eric Hodel escreveu:
[#59807] [ruby-trunk - misc #9421] [Open] [PATCH] doc/contributing.rdoc: allow/encourage other git hosts — normalperson@...
Issue #9421 has been reported by Eric Wong.
[#59882] [ruby-trunk - Feature #9428] [Rejected] Inline argument expressions and re-assignment — matz@...
Issue #9428 has been updated by Yukihiro Matsumoto.
On 2014/01/20 11:32, matz@ruby-lang.org wrote:
[#59909] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — shyouhei@...
Issue #9425 has been updated by Shyouhei Urabe.
shyouhei@ruby-lang.org wrote:
[#60229] [ruby-trunk - Feature #9427] [Feedback] [PATCH] io.c: remove socket check for sendfile — akr@...
Issue #9427 has been updated by Akira Tanaka.
[#60377] Re: [ruby-cvs:51920] nobu:r44775 (trunk): socket.c: suppress warnings — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
[ruby-core:59929] Re: About unmarshallable DRb objects life-time
Em 20-01-2014 21:51, Eric Hodel escreveu: > On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote: >> Em 17-01-2014 19:53, Eric Hodel escreveu: >>> On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote: >>>> I guess the problem is that I didn't quite understand what you meant by this id_conv thing even after looking at the examples you pointed me to. Are there any comprehensive documentation about this feature? >>> There痴 no comprehensive documentation, but it痴 not a particularly complex feature. You implement to_id to convert an object to a reference and to_obj to convert a reference to an object. How you do this depends on the needs of your application. >> I still don't understand what you mean. Should I override Object#to_id and #to_obj in the DRb server-side to get this transparent proxy to work somehow? > Have you read the id_conv samples that ship with ruby? > > $ ag -l id_conv sample/drb/ > sample/drb/gw_s.rb > sample/drb/holders.rb > sample/drb/name.rb The problem is that as far as I understand this id conversion will only take place for objects tranferred between the drb server and client, right? My concern is that with a generic drb server that will evaluate arbitrary code in the server-side there are good chances more objects will be created in the server-side that are not referenced by any of the objects transferred over DRb, don't you agree? >> The approach described in that article is that Ruby code is "eval"ued in the DRb server side (running JRuby). I can't easily track what intermediate objects have been created by the eval code on arbitrary code sent by the client-side. > The id conversion feature allows you to track such intermediate objects. All of them, even if they are not transferred back to the DRb client? How would DRb know about them? >>> One option is to use an LRU-backed id converter with a smart client that can recreate objects for lost references. >> I would have no idea on how to recreate a lost object I don't even know about (it was generated by a generic "eval" call anyway). > This is what id conversion tracks (as mentioned above). > >> And I don't really think this would be possible as those objects were generated as part of an algorithm and I'd need to re-run the algorithm to recreate the object most likely. > Fair. > >>> Another option is to have the client create a context object on the server that the client allocates and communicates through. The context object will hold temporary objects and can be cleaned up automatically through a keep-alive mechanism after the client disconnects. >> This would be so complex that it wouldn't worth to implement a client that could easily run arbitrary code in the DRb server with access to the JVM> It could just be a proxy object that wraps all calls to the underlying API and ensures that only tracked references are returned to the clients. It痴 basically the same as performing id conversion, but you値l know when the client disconnects so you can drop all references. You should be able to wrap any protocol generically with such a context object regardless of the communication mechanism. This has the same concern as the id conversion approach. I'm not sure if keeping a reference only to the returned objects would be enough or if there could be any cases where the returned objects don't hold any references to other possible required intermediate objects created in the process... I can't think of an example right now, so maybe this can't help, I'm just not confident enough about that... But in the case where the returned DRb objects will always hold a reference to all required objects created in the server-side, there remains another problem. How do I detect that the objects have been collected in the client-side so that I could free them in the server-side as well? This has always been my main concern with regards to manually keeping a reference by artificial means in the server-side. Anyway, thank you for pointing me more details about what to look at in those samples. That certainly helped me to understand what you meant by id conversion. Cheers, Rodrigo.