[squeak-dev] Error in Promises/A+ reject implementation?
robert.withers at pm.me
Fri Jun 5 14:43:35 UTC 2020
I reworked the packaging and the code split. Please load the following to see local promises:
> Installer ss project: 'Cryptography'; install: 'PromisesLocal'.
and then run the PromisesLocal tests, all #green.
And to see the remote promises, load the following:
> Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'.
> Installer ss project: 'Cryptography'; install: 'PromisesLoader'.
Run all tests, EXCEPT PromisesRemote tests. 414 tests, all #green. Now run the following #green PromisesRemote tests:
> - Base64EncodingTestCase
> - RememberTableTestCase
> - SealerUnsealerTestCase
> - SerializationTestCase
> - SubstitutionSerializationTestCase
As I am porting PromisesRemote onto the latest iteration of the ParrotTalk interface, the remote tests (LookupTestCase & OperationalTestCase) are not green. They're #Red. I wanted to give you a heads up on the package renames for local promises, such that you could not waste your time exploring this implementation. I'll email once I get those remote tests working again.
On 6/4/20 5:25 PM, Robert Withers wrote:
> Hi Tony,
> Well, this Promise implementation made it into the Kernel and schedules
> into the future (this seems to be the only use). So it certainly strikes
> me as official.
> Have you ever had a chance to look at the 'CapabilitiesLocal'
> implementation I modeled after ERights, many many years ago? It has
> tests. I would welcome comment & feedback.
> Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal'.
> On 6/4/20 10:16 AM, Tony Garnock-Jones wrote:
>> Hi Jakob,
>> On 4/5/20 12:00 AM, Jakob Reschke wrote:
>>> I think our Promise behaves wrong, but I would like a second opinion.
>> I think you're right. And I think we should fix it. I'll draft a repair.
>> I don't think there are many users of Promise out there -- if there are,
>> and any are reading this, please speak up if fixing the bug Jakob
>> reported would be a problem.
>>> I think the behavior in our Promise is also in violation with the
>>> Promises/A+ specification it claims to implement
>>> 2.2.7 then must return a promise.
>>> promise2 = promise1.then(onFulfilled, onRejected);
>>> 22.214.171.124 If either onFulfilled or onRejected returns a value x, run the
>>> Promise Resolution Procedure [[Resolve]](promise2, x).
>>> 126.96.36.199 If either onFulfilled or onRejected throws an exception e,
>>> promise2 must be rejected with e as the reason.
>> Thanks for digging into the spec here. That'll be helpful for getting
>> the tests right.
>>> On an only slightly related note, I am unhappy that I cannot debug
>>> errors in promise handler blocks [...] Opinions?
>> I don't know what to think about this, I'm afraid! I'd be keen to hear
>> more from others about what a good alternative to the current behaviour
>> might be.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev