[#36034] [Backport92 - Backport #4651][Open] Bus Error using continuation on x86_64-darwin11.0.0 (Lion) — Erik Michaels-Ober <sferik@...>

17 messages 2011/05/07

[#36058] draft schedule of Ruby 1.9.3 — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

18 messages 2011/05/09

[#36131] Re: [ruby-cvs:38172] Ruby:r30989 (trunk): * include/ruby/win32.h: define WIN32 if neither _WIN64 nor WIN32 defined. it forces to use push/pop for pack(4) pragma. — "Yuki Sonoda (Yugui)" <yugui@...>

Hi arton,

7 messages 2011/05/12

[#36156] [Ruby 1.9 - Bug #4683][Open] [PATCH] io.c: copy_stream execute interrupts and retry — Eric Wong <normalperson@...>

11 messages 2011/05/12

[#36316] [Ruby 1.9 - Bug #4731][Open] ruby -S irb fails with mingw/msys vanilla builds — Roger Pack <rogerpack2005@...>

12 messages 2011/05/18

[#36329] [Ruby 1.9 - Bug #4738][Open] gem install fails with "Encoding::ConverterNotFoundError" on windows 7 greek — Ilias Lazaridis <ilias@...>

11 messages 2011/05/19

[#36390] [Ruby 1.9 - Feature #4766][Open] Range#bsearch — Yusuke Endoh <mame@...>

23 messages 2011/05/22

[#36406] 1.8.7 release next month — Urabe Shyouhei <shyouhei@...>

Hello core people,

18 messages 2011/05/23
[#36414] Re: 1.8.7 release next month — Luis Lavena <luislavena@...> 2011/05/23

2011/5/23 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#36487] Re: 1.8.7 release next month — Urabe Shyouhei <shyouhei@...> 2011/05/26

Hi Luis,

[#36488] Re: 1.8.7 release next month — Hidetoshi NAGAI <nagai@...> 2011/05/26

From: Urabe Shyouhei <shyouhei@ruby-lang.org>

[#36496] Re: 1.8.7 release next month — Hidetoshi NAGAI <nagai@...> 2011/05/26

From: Hidetoshi NAGAI <nagai@ai.kyutech.ac.jp>

[#36712] Re: 1.8.7 release next month — Urabe Shyouhei <shyouhei@...> 2011/06/03

Ping Luis, how's it going?

[#36748] Re: 1.8.7 release next month — Luis Lavena <luislavena@...> 2011/06/05

On Fri, Jun 3, 2011 at 5:18 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#36434] [Ruby 1.9 - Feature #4774][Open] User Friendly Handling of "Encoding::ConverterNotFoundError" — Lazaridis Ilias <ilias@...>

11 messages 2011/05/24

[#36447] [Ruby 1.9 - Bug #4777][Open] Ruby 1.9.2-p180 ignoring INT, TERM, and QUIT until it receives CONT — Nathan Sobo <nathansobo@...>

10 messages 2011/05/25

[#36559] [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Tom Wardrop <tom@...>

48 messages 2011/05/30
[#36560] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Yukihiro Matsumoto <matz@...> 2011/05/30

Hi,

[#36571] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Anurag Priyam <anurag08priyam@...> 2011/05/30

> Iff 'key': 'value'} means {:key => 'value'} I have no objection.

[#36573] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Yukihiro Matsumoto <matz@...> 2011/05/30

Hi,

[#36578] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Cezary <cezary.baginski@...> 2011/05/30

On Mon, May 30, 2011 at 04:21:32PM +0900, Yukihiro Matsumoto wrote:

[#36580] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/05/30

Em 30-05-2011 07:58, Cezary escreveu:

[#36581] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Michael Edgar <adgar@...> 2011/05/30

Since :"#{abc}" is allowed in Ruby, I imagine that any such substitute syntax would preserve that property.

[#36587] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Cezary <cezary.baginski@...> 2011/05/30

On Mon, May 30, 2011 at 09:05:04PM +0900, Michael Edgar wrote:

[ruby-core:36015] [Ruby 1.9 - RubySpec #4649] Adding parallel constructors to Ruby 2.0

From: Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date: 2011-05-05 20:53:27 UTC
List: ruby-core #36015
Issue #4649 has been updated by Rodrigo Rosenfeld Rosas.


You're right Joel. Maybe the syntax I'm requesting to be included in standard Ruby should be something like:

concurrently do
  task {...}
  ...
end

But, although the implementation is simple, having a standard idiom for that common requirement would be great. That means I wouldn't have to redefine this idiom not to rely on external gem while doing some scripting... Other than that, making it a language feature could allow some low level improvements in performance, but it is just a guess since I don't know how this could be achieved yet.

Furthermore, depending on the specs, maybe it wouldn't be necessary to do something like "a, b = concurrently do...". Being a standard idiom, someone looking at a code like this would know for sure what is happening since it is a language feature instead of an external dependency...

Also, my initial example was too simple, but I imagine possibly several variables inside each task that should be available at the end of the parallels/concurrently block.
----------------------------------------
RubySpec #4649: Adding parallel constructors to Ruby 2.0
http://redmine.ruby-lang.org/issues/4649

Author: Rodrigo Rosenfeld Rosas
Status: Open
Priority: Normal
Assignee: Yukihiro Matsumoto
Category: 
Target version: 2.0


I was not sure if this was RubySpec or Feature type.

My request is to create some new syntax for easing the write of concurrent code with Ruby. The syntax could be something like this:

parallels do
  task "get response from service A" do # optional description
    a = IO.read("http://serviceA/request")
  end
  task { b = get_response_from_service_b }
end

# at this point both tasks have finish, it's like a join in the threads at the end of the parallel block.
call_another_service_that_depends_on(a and b)

I am not sure, though, how to deal with scopes inside the parallel block. Traditionally in Ruby, this wouldn't work because both 'a' and 'b' would be local to the 'task' block and would not be accessible from the outside of the parallel block. If we don't want instance variables, I don't know what is the best approach for avoiding some "a=nil; b=nil" before the parallel block.

Maybe this could start as a gem, but having it implemented directly in Ruby would be awesome, specially for scripts that usually don't rely in external dependencies for simplifying distribution...

Any thoughts about this propose?


-- 
http://redmine.ruby-lang.org

In This Thread