From: Daniel Nugent Date: 2006-02-24T13:30:25+09:00 Subject: Re: lazy.rb 0.9.5 -- transparent futures! Mental, could I perchance persuade you to add an optional parameter to the Future initializer that accepts a block to be run inside the rescue clause of the Future's thread? The situation I am specifically thinking of is this: I have a number of objects that will want the value resulting from the Future. I know all of these objects WILL need to access that value. Because the computation in the Future is very expensive, I would like to raise exceptions on those objects as soon as the thread is caught so that they can begin handling the error as soon as possible. So, at the time of the exception, I can lock down the current subscribers list and then fire off the exception to each of them. Something like this: future(lambda{|exception| lock.synchronize{subscribers.each{|s| s.raise(exception)}}}){holy_crap_long_execution} On 2/23/06, Jim Weirich wrote: > Jim Weirich wrote: > > MenTaLguY wrote: > >> On Wed, 2006-02-22 at 15:27 +0900, Jim Weirich wrote: > >> > >>> Ok, I think I fixed it. Give it another try. > >> > >> ERROR: While executing gem ... (YAML::Error) > >> Invalid object explicitly tagged !ruby/Object: "requir" > > > > Ahhh ... Interesting. > > > > I've tracked this down to a corrupt compressed gem index on my beta > > server. My home box wasn't getting it because it uses a unreleased > > version of RubyGems that does incremental downloads of the individual > > gem specs rather than grabbing the massive gem index all the time. > > > > This might also explain an unrelated issue I was having with testing > > RubyGems. I think this bug has made my day. > > > > Now all I have to do is fix it. > > Yep, it was a bug in the new RubyGems server-side indexing software. > Should be fixed now. Give it another try... > > gem install blankslate -s http://onestepback.org/betagems > > -- > -- Jim Weirich > > > > -- > Posted via http://www.ruby-forum.com/. > > -- -Dan Nugent