lgierth / promise.rb Goto Github PK

Hi,

I opened an Issue but I just need some help relate to promise.rb.
I know and use Promises with q.js and I was trying a ruby equivalent.

I'm not an expert with EM but I tried the first examples and I never get the output printed.

It's possible that I have to wrap the execution of nonblocking_stuff methods with an EM.run?

EM.run do
   nonblocking_stuff.then { |value| p value }
   nonblocking_stuff.then(proc { |value| p value })
end

Maybe it's just me

Thank you.

cc @stephencelis

Prototype mentioned in #23 (comment)

Hi all,

I'm the original author of promise.rb - it's great to see it's still of use to so many people. I intend to close my Github account and here's a plan how to do that without causing any trouble for promise.rb. These steps can hopefully be done in less than 10 minutes.

1. Create lgierth2 org
2. Add all current committers to that org
3. Move promise.rb to lgierth2 org
4. Rename lgierth account to something else
5. Rename lgierth2 org to lgierth
6. Done

Does this sound good? If so, I'd follow through with this on 1 July.

Thanks!

I'm running into a bug in promise.rb where the sync method breaks when mixing various Promise classes together.

Here's some sample code demonstrating the problem:

require "promise"

class MyPromise < ::Promise
  def wait
    fulfill(456)
  end
end

p1 = Promise.resolve(123)

p2a = MyPromise.new
p2a.sync

p2b = MyPromise.new

p3a = p1.then { |a| p2a.then { |b| a + b } }
p3b = p1.then { |a| p2b.then { |b| a + b } }

puts p3a.sync
puts p3b.sync

What's happening is that when then is called on p1 (which is already resolved), promise.rb internally creates a new promise of the same type as p1 and then immediately executes the then block. Even though the then block is called immediately and returns a new MyPromise instance, the internal state of the promise returned by the then block is copied into the newly created Promise instance rather than the MyPromise instance being returned directly.

If p2a is also already resolved, this is not a problem and calling p3a.sync returns the right thing.

If p2b is not already resolved when p3b.sync is called, the sync call tries to call wait on an instance of Promise, rather than an instance of MyPromise. This raises a NoMethodError.

The output I'd expect the code sample above to produce is:

579
579

The actual output is:

579
lib/promise.rb:64:in `sync': undefined local variable or method `wait' for #<Promise:0x007fb8db51e028 @state=:pending, @callbacks=[]> (NameError)
    from x.rb:20:in `<main>'

Hi.

Installing as described (in my case with bundler gem 'promise') succeeds but installs the wrong gem - i.e. it installs this older and completely different promises library: https://github.com/bhuga/promising-future

Since the install appears to succeed the mistake is not apparent until you try to use the library - at which time Promise.new fails with the runtime exception:

undefined method `arity' for nil:NilClass

The Gemfile for this repo is using devtools with an unspecified version or git reference. The Gemfile.devtools requires gem 'rspec', '~> 2.99.0' but all the released version of devtools expect 3.x

Here is the error message from bundle install:

Bundler could not find compatible versions for gem "rspec":
  In Gemfile:
    rspec (~> 2.99.0)

    devtools was resolved to 0.1.4, which depends on
      rspec (~> 3.4.0)

    fuubar was resolved to 1.2.1, which depends on
      rspec (~> 2.0)

Do you mind introducing initialize that looks similar to ES6 version?

Promise.new do |resolve, reject|
  # ...
end

When an handler raises an error, it will reject the next promise, but also let the error bubble up the call stack.

When using the example EM Promise subclass in an RSpec spec, this will generate weird behaviors:

• if only 1 test exists, it will pass with the message 'Empty test suite.'
• if other tests exist, we'll get the following trace in all tests:

RuntimeError: can't modify frozen object
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `extend_object'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `extend'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:274:in `finish'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example.rb:139:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:390:in `block in run_examples'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:386:in `map'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:386:in `run_examples'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/example_group.rb:371:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `map'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:28:in `block in run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/reporter.rb:34:in `report'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/command_line.rb:25:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/runner.rb:80:in `run'
/usr/local/var/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/rspec-core-2.13.1/lib/rspec/core/runner.rb:17:in `block in autorun'

This happens will all rspec versions I tested.

I suggest explaining that in the docs, I almost gave up on the library because I thought it was a bug in it.

Thank for it, btw, I like the API and being able to use any 'scheduler'.

I remember @arthurschreiber hunting some good performance wins on his own branch a loooong time ago, and I can't remember if the all got merged here, or if some of them are still in https://github.com/arthurschreiber/promise.rb/branches somewhere. Does anyone know?

cc @ahoglund, do you mind checking if GitHub still runs a custom sha of this library? (Or maybe it's running a Rubygems version by now, like I said, I can't remember...) Thanks!

Hey!

Your library is awesome, but the promises in my code get often rejected and I don't even know about it.. Could you provide Promise.unhandled_rejection function to handle unhandled rejections (I'd use it in development only)

That way we can use things which do not inherit from Promise but which obey the interface with helpers like all

For now the readme says:

Promise.new
  .tap(&:fulfill)
  .then { Promise.new.tap(&:fulfill) }
  .then { Promise.new.tap(&:reject) }
  .then(nil, proc { |reason| p reason })

Last two PRs I've made introduced a change so following is possible:

Promise.new.fulfill
  .then { Promise.new.fulfill }
  .then { Promise.new.reject }
  .then(nil, proc { |reason| p reason })

What about an extra Promise.reject and Promise.fulfill, so following is possible?

Promise.fulfill
  .then { Promise.fulfill }
  .then { Promise.reject }
  .then(nil, proc { |reason| p reason })

Is it ok?