Hi, I have looked at Scale b/c of different question, and I see it uses futures. I'd like to ask if those futures are one-off, or is there any consensus on how futures should look like in Pharo. The reason I ask is b/c Amber already has something like that - Promises, which do not use the native JS API directly (though it is inspired), but do have an API of their own; and since those concepts seems to be similar (or maybe are the same, just called differently), if the API used shouldn't be sort-of standardized / used the same way in all occasions. Herby P.S.: Including state-of-the-art Promises.st from Amber master branch to get a picture: Smalltalk createPackage: 'Kernel-Promises'! Object subclass: #Promise instanceVariableNames: '' package: 'Kernel-Promises'! !Promise class methodsFor: 'composites'! all: aCollection "Returns a Promise resolved with results of sub-promises." <inlineJS: 'return Promise.all($recv(aCollection)._asArray())'> ! any: aCollection "Returns a Promise resolved with first result of sub-promises." <inlineJS: 'return Promise.race($recv(aCollection)._asArray())'> ! ! !Promise class methodsFor: 'instance creation'! forBlock: aBlock "Returns a Promise that is resolved with the value of aBlock, and rejected if error happens while evaluating aBlock." ^ self new then: aBlock ! new "Returns a dumb Promise resolved with nil." <inlineJS: 'return Promise.resolve()'> ! new: aBlock "Returns a Promise that is eventually resolved or rejected. Pass a block that is called with one argument, model. You should call model value: ... to resolve the promise and model signal: ... to reject the promise. If error happens during run of the block, promise is rejected with that error as well." <inlineJS: 'return new Promise(function (resolve, reject) { var model = {value: resolve, signal: reject}; aBlock._value_(model); })'> ! signal: anObject "Returns a Promise rejected with anObject." <inlineJS: 'return $recv(anObject)._in_(function (x) {return Promise.reject(x)})'> ! value: anObject "Returns a Promise resolved with anObject." <inlineJS: 'return $recv(anObject)._in_(function (x) {return Promise.resolve(x)})'> ! ! Trait named: #TThenable package: 'Kernel-Promises'! !TThenable methodsFor: 'promises'! catch: aBlock <inlineJS: 'return self.then(null, function (err) {return $core.seamless(function () { return aBlock._value_(err); })})'> ! on: aClass do: aBlock <inlineJS: 'return self.then(null, function (err) {return $core.seamless(function () { if (err._isKindOf_(aClass)) return aBlock._value_(err); else throw err; })})'> ! on: aClass do: aBlock catch: anotherBlock ^ (self on: aClass do: aBlock) catch: anotherBlock ! then: aBlockOrArray "Accepts a block or array of blocks. Each of blocks in the array or the singleton one is used in .then call to a promise, to accept a result and transform it to the result for the next one. In case a block has more than one argument and result is an array, first n-1 elements of the array are put into additional arguments beyond the first. The first argument always contains the result as-is." <inlineJS: ' var array = Array.isArray(aBlockOrArray) ? aBlockOrArray : [aBlockOrArray]; return array.reduce(function (soFar, aBlock) { return soFar.then(typeof aBlock === "function" && aBlock.length > 1 ? function (result) {return $core.seamless(function () { if (Array.isArray(result)) { return aBlock._valueWithPossibleArguments_([result].concat(result.slice(0, aBlock.length-1))); } else { return aBlock._value_(result); } })} : function (result) {return $core.seamless(function () { return aBlock._value_(result); })} ); }, self)'> ! then: aBlockOrArray catch: anotherBlock ^ (self then: aBlockOrArray) catch: anotherBlock ! then: aBlockOrArray on: aClass do: aBlock ^ (self then: aBlockOrArray) on: aClass do: aBlock ! then: aBlockOrArray on: aClass do: aBlock catch: anotherBlock ^ ((self then: aBlockOrArray) on: aClass do: aBlock) catch: anotherBlock ! ! Promise setTraitComposition: {TThenable} asTraitComposition! ! ! phil@highoctane.be wrote:
https://github.com/guillep/Scale <https://github.com/guillep/Scale> is quite cool for quick scripts on *nix.
Now for embeddable, yes it would help. Bootstrapping will be helpful but the current main issue is the VM interpret loop that is in the current VMs.
It is not an intrinsic problem. Telepharo is also a great step to enable that to exist.
Phil
On Oct 7, 2017 13:05, "Herby VojÄÃk" <herby@mailbox.sk <mailto:herby@mailbox.sk>> wrote:
Ben Coman wrote:
Nice article. I like the way you've structured it and pushed the "updated" angle.
I feel a bit too strong a claim is laid on Pharo producing the CogVM. Much of the Cog + Spur + 64bit VM work was originally done for Squeak with Pharo riding the coat-tails of that work. Lately Pharo community has been involved in improving VM with hotspot optimisation with Sista and moving towards making Pharo embeddable.. (@Clement, is "hotspot
Hi, this made me curious. I always had the problem with Amber (and, all the rest of Smalltalks in similar vein) that it is hard to use to one-off scripting, as it presumes existence of the not really small class library (objects, classes, collections, etc.). This disadvantaged it IMO in the field of "can I just embed it here and script it with a few lines?" scenarios.
Did you (the Pharo community that is "moving towards making Pharo embeddable") find some way to work this around?
cheers -ben
Herby