[Cuis-dev] Methods that return multiple values

Juan Vuletich juan at cuis.st
Sat Jun 24 18:15:08 PDT 2023 

On 6/24/2023 10:05 PM, rabbit via Cuis-dev wrote:
> Oh! That’s exactly the semantics I’m expecting! When the method 
> resumes I’m absolutely expecting self to be the new guy.

And the new guy doesn't include the method you are resuming! Please 
check references to MethodInCallStackToBecomeInvalid . If the new guy 
includes the same exact method, then it makes sense to resume its 
execution. Maybe you can include that method.

> If a subsequent message call is not understood, a DNU would be raised. 
> Can we get a parallel method to give me those semantics, please? 
> Portability is #becomeForward: but not that breaks your existing 
> contract. Could we test #isEventual in #becomeForward:, perhaps?

Not in Cuis base image. That programming pattern is completely wrong in 
my view. But I won't police your code, I'll just be very careful with 
the Cuis base image.

>
> ❤️‍🔥🐰
>
>
>
>
> On Sat, Jun 24, 2023 at 20:38, Juan Vuletich <juan at cuis.st 
> <mailto:On%20Sat,%20Jun%2024,%202023%20at%2020:38,%20Juan%20Vuletich%20%3C%3Ca%20href=>> 
> wrote:
>> I'm not familiar with your code.
>>
>> But that error message you get is real. It is not a problem in Cuis. 
>> It is a problem in your code. You are doing #becomeForward: of an 
>> object that is in the midst of running a method. If the become is 
>> done, that method will later resume running, but self will be a 
>> different object, maybe an object of another class, where this method 
>> is not defined, and can not be run.
>>
>> I suggest understanding this problem. It is safer to only do become 
>> on objects that are NOT running any methods at that moment.
>>
>> Squeak doesn't give you this error simply because Squeak doesn't 
>> check for this problem. A VM crash is likely in this situation. I 
>> actually added this check to Cuis after someone (it was a long time 
>> ago, I don't remember who it was) was experiencing VM crashes because 
>> a method was resumed on a becomed object, and was writing instance 
>> variables that didn't exist in the becomed object.
>>
>> HTH,
>>
>> On 6/24/2023 10:57 AM, rabbit via Cuis-dev wrote:
>>>
>>> Hi Juan, I'm attaching 2 squeak source files, one with 2 methods in 
>>> compatibility and the other the source.st out of my latest 
>>> PromisesLocal-rabbt.66,mcz.
>>>
>>> I got the Vat's eventual process working (issues with terminate),
>>>
>>> but I'm blowing up on a call to #becomeForward:, from 
>>> ENearPromise>>#becomeContext:, when resolving a promise. Here is an 
>>> image of the resulting debugger. Is there more information I could 
>>> provide or is someone willing to attempt to reproduce? Many thanks! 
>>> ❤️‍🔥🐰
>>>
>>> On 6/23/23 20:50, rabbit via Cuis-dev wrote:
>>>> Ahh! Thanks for the reminder. That’s how I started loading code a 
>>>> month ago or whenever I was loading mczs. I’ll look into it tomorrow.
>>>>
>>>> Is it possible to get Monticello pkg loading working again? That’d 
>>>> be very good.
>>>>
>>>> What’s my go to solution for code packaging in Cuis? I’d like to 
>>>> establish Crypto in Cuis.
>>>>
>>>> ❤️‍🔥🐰
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 23, 2023 at 19:21, Juan Vuletich via Cuis-dev 
>>>> <cuis-dev at lists.cuis.st 
>>>> <mailto:On%20Fri,%20Jun%2023,%202023%20at%2019:21,%20Juan%0A%20%20%20%20%20%20%20%20Vuletich%20via%20Cuis-dev%20%3C%3Ca%20href=>> 
>>>> wrote:
>>>>> Hi rabbit,
>>>>>
>>>>> I suggest unzipping the Monticello files to extract the code in 
>>>>> plain text (yes, Monticello files are just zip files). When you 
>>>>> are there, you can also fix the line ending convention of the 
>>>>> files. And of course, you'd neet to check the code, because Cuis 
>>>>> is not 100% compatible with Squeak.
>>>>>
>>>>> We don't use Monticello in Cuis. At some point in the past it was 
>>>>> possible to open MC files in Cuis, but nobody used that feature in 
>>>>> ages and it got bitrotten.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On 6/23/2023 4:00 PM, rabbit via Cuis-dev wrote:
>>>>>>
>>>>>> I just realized I have been working in squeak. I updated 
>>>>>> PromisesLocal-rabbt.66.mcz and am attaching it. I am getting the 
>>>>>> error below when I 'browse code' or 'install Mionticello 
>>>>>> package'. I do not know. How can I load Monticello packages? Any 
>>>>>> way to get the Installer available in cuis? Install Monticello 
>>>>>> config maps?
>>>>>>
>>>>>> I appreciate you,
>>>>>> rabbit
>>>>>>
>>>>>>
>>>>>> On 6/22/23 16:21, rabbit via Cuis-dev wrote:
>>>>>>>
>>>>>>> Hey! I got inspired by your proposal, Luciano, and here's my 
>>>>>>> solution in eventual promises. Code can be loaded as:
>>>>>>>
>>>>>>>     Installer ss project: 'Cryptography'; install:
>>>>>>>     'ProCrypto.release.3'.
>>>>>>>
>>>>>>> I added a test method
>>>>>>>
>>>>>>>     RefsTest>>#testMultiReturns
>>>>>>>
>>>>>>>     | selectCount unionFlag pair |
>>>>>>>     unionFlag := false.
>>>>>>>     selectCount := 0.
>>>>>>>     ((pair := self promiseResolverPair) key xgcd: 9)
>>>>>>>     <<* [:each | selectCount := selectCount + 1. Transcript cr;
>>>>>>>     show: 'each = ', each];
>>>>>>>     <<* [:g :s :t | unionFlag := true. Transcript cr; show: 'g =
>>>>>>>     ', g, '; s = ', s, '; t = ', t. g + s + t].
>>>>>>>     pair value resolve: 21.
>>>>>>>     (Delay forMilliseconds: 333) wait.
>>>>>>>     self assert: (selectCount == 3).
>>>>>>>     self assert: (unionFlag).
>>>>>>>
>>>>>>> This calls new multireturn #xgcd: method
>>>>>>>
>>>>>>>     xgcd: anInteger
>>>>>>>     " 21 xgcd: 9"
>>>>>>>     | g s t |
>>>>>>>     g := self gcd: anInteger.
>>>>>>>     s := self / g.
>>>>>>>     t := anInteger / g.
>>>>>>>     ^ { g. s. t}
>>>>>>>
>>>>>>> And in the test method there are eventual sends (#<<*) to the 
>>>>>>> promise of the #xgcd: send once the reciever promise is resolved 
>>>>>>> to 21. This implementation detects cardinality of the 
>>>>>>> continuation block and sends #whenResolved: appropriately, for 
>>>>>>> future evaluation.
>>>>>>>
>>>>>>>     Object>>#<<* continuation
>>>>>>>
>>>>>>>     (continuation numArgs == 1)
>>>>>>>     ifTrue: [^ self whenResolved: [:result | result do: [:each |
>>>>>>>     continuation value: each]]].
>>>>>>>     ^ self whenResolved: [:result | continuation
>>>>>>>     valueWithArguments: result].
>>>>>>>
>>>>>>> One can see a 1 cardinality schedules the continuation to 
>>>>>>> evaluate with each result, while a continuation with cardinality 
>>>>>>> 2 or more will be scheduled to receive all results. 
>>>>>>> #valueWithArguments:
>>>>>>>
>>>>>>> Here are 2 return handlers,
>>>>>>>
>>>>>>>     promise := ((pair := self promiseResolverPair) key xgcd: 9).
>>>>>>>
>>>>>>> the first for each argument
>>>>>>>
>>>>>>>     promise <<* [:each | selectCount := selectCount + 1.
>>>>>>>     Transcript cr; show: 'each = ', each];
>>>>>>>
>>>>>>> and the second for all three arguments.
>>>>>>>
>>>>>>>     promise <<* [:g :s :t | unionFlag := true. Transcript cr;
>>>>>>>     show: 'g = ', g, '; s = ', s, '; t = ', t. g + s + t].
>>>>>>>
>>>>>>> --
>>>>>>> ❤️‍🔥🐰
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/21/23 09:44, Luciano Notarfrancesco via Cuis-dev wrote:
>>>>>>>> Interesting, thanks for sharing!
>>>>>>>> Actually I think it’s the same thing I did, my implementation 
>>>>>>>> calls BlockClosure>>#valueWithPossibleArgs: and takes only as 
>>>>>>>> many arguments as needed by the block but the array can be 
>>>>>>>> bigger than that (it should be named 
>>>>>>>> #valueWithPossibleArguments: tho, abbreviations are ugly).
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 21 Jun 2023 at 15:37 Christian Haider via Cuis-dev 
>>>>>>>> <cuis-dev at lists.cuis.st> wrote:
>>>>>>>>
>>>>>>>>     I added something similar to my Values package (VW and ports).
>>>>>>>>
>>>>>>>>     The source is
>>>>>>>>
>>>>>>>>     SequenceableCollection>>asArgumentsIn: aBlock
>>>>>>>>
>>>>>>>>     "Evaluate aBlock with the receiver's elements as parameters.
>>>>>>>>
>>>>>>>>     aBlock takes its arguments from the receiver.
>>>>>>>>
>>>>>>>>     'ok'
>>>>>>>>
>>>>>>>>     #(1 2 3) asArgumentsIn: [:a :b :c | a + b + c]
>>>>>>>>
>>>>>>>>     #(1 2 3) asArgumentsIn: [:a :b | a + b]
>>>>>>>>
>>>>>>>>     #(1 2 3) asArgumentsIn: [:a | a]
>>>>>>>>
>>>>>>>>     #(1 2 3) asArgumentsIn: [42]
>>>>>>>>
>>>>>>>>     'not ok'
>>>>>>>>
>>>>>>>>     #(1 2 3) asArgumentsIn: [:a :b :c :d | a + b + c + d]
>>>>>>>>
>>>>>>>>     "
>>>>>>>>
>>>>>>>>     ^aBlock cullWithArguments: self asArray
>>>>>>>>
>>>>>>>>     The difference is that it takes a list of any size and
>>>>>>>>     picks out the first items and binds them to the variables.
>>>>>>>>
>>>>>>>>     I use it often for CSV processing like
>>>>>>>>
>>>>>>>>     (line tokensBasedOn: $;) asArgumentsIn: [:first :second :y
>>>>>>>>     | … ].
>>>>>>>>
>>>>>>>>     I am just a bit unhappy with the name – it is too long. It
>>>>>>>>     reads ok though.
>>>>>>>>
>>>>>>>>     The pipe character is an interesting idea. I have to think
>>>>>>>>     about it.
>>>>>>>>
>>>>>>>>     I am use it for a while now and I am very happy with it.
>>>>>>>>
>>>>>>>>     Happy hacking,
>>>>>>>>
>>>>>>>>     Christian
>>>>>>>>
>>>>>>>>     *Von:* Cuis-dev <cuis-dev-bounces at lists.cuis.st> *Im
>>>>>>>>     Auftrag von *Luciano Notarfrancesco via Cuis-dev
>>>>>>>>     *Gesendet:* Mittwoch, 21. Juni 2023 15:13
>>>>>>>>     *An:* Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
>>>>>>>>     *Cc:* Luciano Notarfrancesco <luchiano at gmail.com>
>>>>>>>>     *Betreff:* [Cuis-dev] Methods that return multiple values
>>>>>>>>
>>>>>>>>     Smalltalk doesn’t have a convention for methods returning
>>>>>>>>     multiple values, and I’m not aware of any implementation.
>>>>>>>>
>>>>>>>>     An example of such thing is the extended gcd: ‘a xgcd: b’
>>>>>>>>     returns g, s, t where g is the gcd, and as + bt = g.
>>>>>>>>     Writing methods that return multiple values is easy with
>>>>>>>>     the curly brackets syntax, Integer>>#xgcd: ends with
>>>>>>>>     something like
>>>>>>>>
>>>>>>>>     ^ {g. s. t}
>>>>>>>>
>>>>>>>>     But using sending messages that return multiple values is
>>>>>>>>     kind of annoying, I end up doing something like:
>>>>>>>>
>>>>>>>>     xgcd := a xgcd: b.
>>>>>>>>
>>>>>>>>     g := xgcd at: 1.
>>>>>>>>
>>>>>>>>     s := xgcd at: 2.
>>>>>>>>
>>>>>>>>     t := xgcd at: 3
>>>>>>>>
>>>>>>>>     Some years ago I thought about using blocks for this, but I
>>>>>>>>     never tried it. Today I just did a little experiment
>>>>>>>>     implementing anArray | aBlock as ‘^ aBlock
>>>>>>>>     valueWithPossibleArgs: self’ and I can do:
>>>>>>>>
>>>>>>>>     (a xgcd: b) | [:g :s :t| … ]
>>>>>>>>
>>>>>>>>     This is seems quite nice already, I guess I’ll start using
>>>>>>>>     it and see how it feels. But the point of this mail is not
>>>>>>>>     to show a solution, but to ask if anyone have thought about
>>>>>>>>     this or if they know any nicer solutions. Any ideas?
>>>>>>>>
>>>>>>>>     -- 
>>>>>>>>     Cuis-dev mailing list
>>>>>>>>     Cuis-dev at lists.cuis.st
>>>>>>>>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>>>>
>>>>>> --
>>>>>> ❤️‍🔥🐰
>>>>>
>>>>>
>>>>> --
>>>>> Juan Vuletich
>>>>> cuis.st
>>>>> github.com/jvuletich
>>>>> researchgate.net/profile/Juan-Vuletich
>>>>> independent.academia.edu/JuanVuletich
>>>>> patents.justia.com/inventor/juan-manuel-vuletich
>>>>> linkedin.com/in/juan-vuletich-75611b3
>>>>> twitter.com/JuanVuletich
>>> --
>>> ❤️‍🔥🐰
>>
>>
>> --
>> Juan Vuletich
>> cuis.st
>> github.com/jvuletich
>> researchgate.net/profile/Juan-Vuletich
>> independent.academia.edu/JuanVuletich
>> patents.justia.com/inventor/juan-manuel-vuletich
>> linkedin.com/in/juan-vuletich-75611b3
>> twitter.com/JuanVuletich


-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230624/fa5bce98/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 246040 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230624/fa5bce98/attachment-0001.jpe>

More information about the Cuis-dev mailing list