April 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Regarding Raven: DOCap System

by henry

Bleek, here are some more docs regarding the ParrotTalk specifications [1] and 'Internet Draft' [2] and the three-way Granovetter promise pipelining GalaxyObject scenario for third party introductions in Raven [3] [1] - http://jmp.sh/OqlYpyg [2] - http://jmp.sh/VRejS2g [3] - http://jmp.sh/CKsvXXz - HH âââââââ Original Message âââââââ On April 1, 2018 11:21 AM, henry <henry(a)callistohouse.club> wrote: > Sorry for the false traffic, here is a current stack. > > - HH > > âââââââ Original Message âââââââ > On April 1, 2018 11:14 AM, henry <henry(a)callistohouse.club> wrote: > >> FWIW, Here is an image showing the full stack up to Raven, though the BufferListLayer (stack item 2) is no longer present. >> >> - HH >> >> âââââââ Original Message âââââââ >> On April 1, 2018 11:06 AM, henry <henry(a)callistohouse.club> wrote: >> >>> Thank you for your observations, Andrew. Allow me to take a moment to describe how differences appear in Smalltalk and Java, you have hit the nail squarely. I wish to mention two differences, one on the send side and the other on the resolve side. I also need to mention that it has been a number of years since I have had the Java version functioning, as I delved into making ParrotTalk work binary compatible between Smalltalk and Java. So I am rusty on how the Java side actually works. I just tested and the Reactor interface is not yet functional, so more work needed there. >>> >>> On the send side, Java does not have a doesNotUnderstand: mechanism, while Smalltalk does. I do not use special syntax for local async sends, like NewSpeak does, I just have a doesNotUnderstand: implementation in the ERef hierarchy, so when you write: 42 eventual * 10, it sends the * message as an eventual send rather than an immediate call. In Java you have to explicitly call redirectMessage... Here is code (not yet functional in Raven for Java) that demonstrates both an explicit redirectMessage, as well as whenResolved with a ReactorInterface anonymous class implementation. >>> >>> Ref ref = RefUtil.wrap("a pauwau is the best", Vat.getLocalVat()); >>> Ref newRef = ref.redirectMessage("indexOf", "best"); >>> newRef.whenResolved(new ReactorInterface<Integer>() { >>> @Override >>> public void value(Integer obj) throws NotResolvedException { >>> isResolved = true; >>> assertEquals(16, obj.intValue()); >>> } >>> @Override >>> public void reactToLostClient(Exception e) throws NotResolvedException { >>> assertTrue(false); >>> } >>> }); >>> >>> To your point on whenResolved differences between Smalltalk and Java, exactly. In Smalltalk all you need to do is pass a one-arg block closure with #whenResolved: to an eventual ERef: promise, remotePromise, nearRef or farRef. FarRef and RemotePromise will forward this to the remote vat. >>> >>> In Java, I am trying to use anonymous subclasses with a Templated Class for the expected return. >>> >>> More difficulty arises if there is more that one expected return type. In Smalltalk just query the class of the returned type within the block closure. It is also possible to have two or more whenResolved: reactor blocks, each with a test for a specific type or failure, and the failure of the resolved reactor should not break the eventual reference, just fail quietly until a successful reactor is encountered. >>> >>> In Java, you can have more than one reactor, with two different templated classes. The wrong cast should fail until the correct cast is found. Another thought is how scala works. I do not recall the name of the pattern matching by type, but in scala one can add more tha n one type to the pattern matching (I think it is pattern matching) and the correct code will be called. Perhaps Java's implementation of Raven needs scala code. >>> >>> I hope this helps understanding and answers your concerns regarding differences in return types from eventual sends, between a dynamic type system such as Smalltalk and static return types in Java. Please note there is also a Swift implementation of ParrotTalk. >>> >>> - HH >>> >>> âââââââ Original Message âââââââ >>> On April 1, 2018 8:57 AM, <aglynn42(a)gmail.com> wrote: >>> >>>> One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces. Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing. >>>> >>>> If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses. A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier. i.e. in RMI you need pools of constant TCP connections, while in SST the transport needenât be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between âspacesâ or ânodesâ is required. >>>> >>>> If you avoid the nasties in Java and only support interop for self-describing types, you shouldnât need to write so much custom but rote code. If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers. Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation. >>>> >>>> If you keep in mind that although itâs a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself. >>>> >>>> Andrew >>>> >>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of henry >>>> Sent: Saturday, March 31, 2018 3:46 PM >>>> To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>; Pharo-users list <pharo-users(a)lists.pharo.org> >>>> Subject: Re: [Pharo-users] Regarding Raven: DOCap System >>>> >>>> Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6 >>>> >>>> Sent from ProtonMail Mobile >>>> >>>> On Sat, Mar 31, 2018 at 15:43, henry <henry(a)callistohouse.club> wrote: >>>> >>>>> @m_m#3045 for concurrency without shared state, running on a single green thread (smalltalkâs Process) with support for remote async sends to other images, there is my Raven [1], using Cryptography [2], ParrotTalk [3] and STON. This is an implementation of erightâs [4] ELib. I am working on implementing STON for Java, inside the ASN1 project [5] as I already have ParrotTalk in Java [6], binary interoperate with Squeak/Pharo, and my Raven work in progress in Java [7]. This model allows message send redirection to a promise or farRef (or nearRef) as an asynchronous send returning a promise, which supports whenResolved/whenBroken handlers to be registered per PromiseERef. Iâll be happy to answer any questions you may be having about Raven. Raven is an implementation of an Actor model called Communicating Event Loops, in some literature [8] [9]. >>>>> >>>>> I hope this helps! >>>>> >>>>> [1] http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz >>>>> >>>>> [2] http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz >>>>> >>>>> [3] http://www.squeaksource.com/Cryptography/ParrotTalk-rww.19.mcz >>>>> >>>>> [4] http://erights.org/elib/index.html >>>>> >>>>> [5] https://github.com/CallistoHouseLtd/ASN1 >>>>> >>>>> [6] https://github.com/CallistoHouseLtd/ParrotTalk >>>>> >>>>> [7] https://github.com/CallistoHouseLtd/Raven >>>>> >>>>> [8] https://eighty-twenty.org/2016/10/18/actors-hopl >>>>> >>>>> [9] http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf >>>>> >>>>> Sent from ProtonMail Mobile

April 1, 2018

Re: [Pharo-users] Regarding Raven: DOCap System

by henry

Sorry for the false traffic, here is a current stack. [ravenStack.jpeg] - HH âââââââ Original Message âââââââ On April 1, 2018 11:14 AM, henry <henry(a)callistohouse.club> wrote: > FWIW, Here is an image showing the full stack up to Raven, though the BufferListLayer (stack item 2) is no longer present. > > [a Transceiver.jpeg] > > - HH > > âââââââ Original Message âââââââ > On April 1, 2018 11:06 AM, henry <henry(a)callistohouse.club> wrote: > >> Thank you for your observations, Andrew. Allow me to take a moment to describe how differences appear in Smalltalk and Java, you have hit the nail squarely. I wish to mention two differences, one on the send side and the other on the resolve side. I also need to mention that it has been a number of years since I have had the Java version functioning, as I delved into making ParrotTalk work binary compatible between Smalltalk and Java. So I am rusty on how the Java side actually works. I just tested and the Reactor interface is not yet functional, so more work needed there. >> >> On the send side, Java does not have a doesNotUnderstand: mechanism, while Smalltalk does. I do not use special syntax for local async sends, like NewSpeak does, I just have a doesNotUnderstand: implementation in the ERef hierarchy, so when you write: 42 eventual * 10, it sends the * message as an eventual send rather than an immediate call. In Java you have to explicitly call redirectMessage... Here is code (not yet functional in Raven for Java) that demonstrates both an explicit redirectMessage, as well as whenResolved with a ReactorInterface anonymous class implementation. >> >> Ref ref = RefUtil.wrap("a pauwau is the best", Vat.getLocalVat()); >> Ref newRef = ref.redirectMessage("indexOf", "best"); >> newRef.whenResolved(new ReactorInterface<Integer>() { >> @Override >> public void value(Integer obj) throws NotResolvedException { >> isResolved = true; >> assertEquals(16, obj.intValue()); >> } >> @Override >> public void reactToLostClient(Exception e) throws NotResolvedException { >> assertTrue(false); >> } >> }); >> >> To your point on whenResolved differences between Smalltalk and Java, exactly. In Smalltalk all you need to do is pass a one-arg block closure with #whenResolved: to an eventual ERef: promise, remotePromise, nearRef or farRef. FarRef and RemotePromise will forward this to the remote vat. >> >> In Java, I am trying to use anonymous subclasses with a Templated Class for the expected return. >> >> More difficulty arises if there is more that one expected return type. In Smalltalk just query the class of the returned type within the block closure. It is also possible to have two or more whenResolved: reactor blocks, each with a test for a specific type or failure, and the failure of the resolved reactor should not break the eventual reference, just fail quietly until a successful reactor is encountered. >> >> In Java, you can have more than one reactor, with two different templated classes. The wrong cast should fail until the correct cast is found. Another thought is how scala works. I do not recall the name of the pattern matching by type, but in scala one can add more tha n one type to the pattern matching (I think it is pattern matching) and the correct code will be called. Perhaps Java's implementation of Raven needs scala code. >> >> I hope this helps understanding and answers your concerns regarding differences in return types from eventual sends, between a dynamic type system such as Smalltalk and static return types in Java. Please note there is also a Swift implementation of ParrotTalk. >> >> - HH >> >> âââââââ Original Message âââââââ >> On April 1, 2018 8:57 AM, <aglynn42(a)gmail.com> wrote: >> >>> One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces. Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing. >>> >>> If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses. A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier. i.e. in RMI you need pools of constant TCP connections, while in SST the transport needenât be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between âspacesâ or ânodesâ is required. >>> >>> If you avoid the nasties in Java and only support interop for self-describing types, you shouldnât need to write so much custom but rote code. If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers. Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation. >>> >>> If you keep in mind that although itâs a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself. >>> >>> Andrew >>> >>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of henry >>> Sent: Saturday, March 31, 2018 3:46 PM >>> To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>; Pharo-users list <pharo-users(a)lists.pharo.org> >>> Subject: Re: [Pharo-users] Regarding Raven: DOCap System >>> >>> Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6 >>> >>> Sent from ProtonMail Mobile >>> >>> On Sat, Mar 31, 2018 at 15:43, henry <henry(a)callistohouse.club> wrote: >>> >>>> @m_m#3045 for concurrency without shared state, running on a single green thread (smalltalkâs Process) with support for remote async sends to other images, there is my Raven [1], using Cryptography [2], ParrotTalk [3] and STON. This is an implementation of erightâs [4] ELib. I am working on implementing STON for Java, inside the ASN1 project [5] as I already have ParrotTalk in Java [6], binary interoperate with Squeak/Pharo, and my Raven work in progress in Java [7]. This model allows message send redirection to a promise or farRef (or nearRef) as an asynchronous send returning a promise, which supports whenResolved/whenBroken handlers to be registered per PromiseERef. Iâll be happy to answer any questions you may be having about Raven. Raven is an implementation of an Actor model called Communicating Event Loops, in some literature [8] [9]. >>>> >>>> I hope this helps! >>>> >>>> [1] http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz >>>> >>>> [2] http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz >>>> >>>> [3] http://www.squeaksource.com/Cryptography/ParrotTalk-rww.19.mcz >>>> >>>> [4] http://erights.org/elib/index.html >>>> >>>> [5] https://github.com/CallistoHouseLtd/ASN1 >>>> >>>> [6] https://github.com/CallistoHouseLtd/ParrotTalk >>>> >>>> [7] https://github.com/CallistoHouseLtd/Raven >>>> >>>> [8] https://eighty-twenty.org/2016/10/18/actors-hopl >>>> >>>> [9] http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf >>>> >>>> Sent from ProtonMail Mobile

April 1, 2018

Re: [Pharo-users] Regarding Raven: DOCap System

by henry

FWIW, Here is an image showing the full stack up to Raven, though the BufferListLayer (stack item 2) is no longer present. [a Transceiver.jpeg] - HH âââââââ Original Message âââââââ On April 1, 2018 11:06 AM, henry <henry(a)callistohouse.club> wrote: > Thank you for your observations, Andrew. Allow me to take a moment to describe how differences appear in Smalltalk and Java, you have hit the nail squarely. I wish to mention two differences, one on the send side and the other on the resolve side. I also need to mention that it has been a number of years since I have had the Java version functioning, as I delved into making ParrotTalk work binary compatible between Smalltalk and Java. So I am rusty on how the Java side actually works. I just tested and the Reactor interface is not yet functional, so more work needed there. > > On the send side, Java does not have a doesNotUnderstand: mechanism, while Smalltalk does. I do not use special syntax for local async sends, like NewSpeak does, I just have a doesNotUnderstand: implementation in the ERef hierarchy, so when you write: 42 eventual * 10, it sends the * message as an eventual send rather than an immediate call. In Java you have to explicitly call redirectMessage... Here is code (not yet functional in Raven for Java) that demonstrates both an explicit redirectMessage, as well as whenResolved with a ReactorInterface anonymous class implementation. > > Ref ref = RefUtil.wrap("a pauwau is the best", Vat.getLocalVat()); > Ref newRef = ref.redirectMessage("indexOf", "best"); > newRef.whenResolved(new ReactorInterface<Integer>() { > @Override > public void value(Integer obj) throws NotResolvedException { > isResolved = true; > assertEquals(16, obj.intValue()); > } > @Override > public void reactToLostClient(Exception e) throws NotResolvedException { > assertTrue(false); > } > }); > > To your point on whenResolved differences between Smalltalk and Java, exactly. In Smalltalk all you need to do is pass a one-arg block closure with #whenResolved: to an eventual ERef: promise, remotePromise, nearRef or farRef. FarRef and RemotePromise will forward this to the remote vat. > > In Java, I am trying to use anonymous subclasses with a Templated Class for the expected return. > > More difficulty arises if there is more that one expected return type. In Smalltalk just query the class of the returned type within the block closure. It is also possible to have two or more whenResolved: reactor blocks, each with a test for a specific type or failure, and the failure of the resolved reactor should not break the eventual reference, just fail quietly until a successful reactor is encountered. > > In Java, you can have more than one reactor, with two different templated classes. The wrong cast should fail until the correct cast is found. Another thought is how scala works. I do not recall the name of the pattern matching by type, but in scala one can add more tha n one type to the pattern matching (I think it is pattern matching) and the correct code will be called. Perhaps Java's implementation of Raven needs scala code. > > I hope this helps understanding and answers your concerns regarding differences in return types from eventual sends, between a dynamic type system such as Smalltalk and static return types in Java. Please note there is also a Swift implementation of ParrotTalk. > > - HH > > âââââââ Original Message âââââââ > On April 1, 2018 8:57 AM, <aglynn42(a)gmail.com> wrote: > >> One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces. Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing. >> >> If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses. A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier. i.e. in RMI you need pools of constant TCP connections, while in SST the transport needenât be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between âspacesâ or ânodesâ is required. >> >> If you avoid the nasties in Java and only support interop for self-describing types, you shouldnât need to write so much custom but rote code. If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers. Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation. >> >> If you keep in mind that although itâs a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself. >> >> Andrew >> >> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of henry >> Sent: Saturday, March 31, 2018 3:46 PM >> To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>; Pharo-users list <pharo-users(a)lists.pharo.org> >> Subject: Re: [Pharo-users] Regarding Raven: DOCap System >> >> Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6 >> >> Sent from ProtonMail Mobile >> >> On Sat, Mar 31, 2018 at 15:43, henry <henry(a)callistohouse.club> wrote: >> >>> @m_m#3045 for concurrency without shared state, running on a single green thread (smalltalkâs Process) with support for remote async sends to other images, there is my Raven [1], using Cryptography [2], ParrotTalk [3] and STON. This is an implementation of erightâs [4] ELib. I am working on implementing STON for Java, inside the ASN1 project [5] as I already have ParrotTalk in Java [6], binary interoperate with Squeak/Pharo, and my Raven work in progress in Java [7]. This model allows message send redirection to a promise or farRef (or nearRef) as an asynchronous send returning a promise, which supports whenResolved/whenBroken handlers to be registered per PromiseERef. Iâll be happy to answer any questions you may be having about Raven. Raven is an implementation of an Actor model called Communicating Event Loops, in some literature [8] [9]. >>> >>> I hope this helps! >>> >>> [1] http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz >>> >>> [2] http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz >>> >>> [3] http://www.squeaksource.com/Cryptography/ParrotTalk-rww.19.mcz >>> >>> [4] http://erights.org/elib/index.html >>> >>> [5] https://github.com/CallistoHouseLtd/ASN1 >>> >>> [6] https://github.com/CallistoHouseLtd/ParrotTalk >>> >>> [7] https://github.com/CallistoHouseLtd/Raven >>> >>> [8] https://eighty-twenty.org/2016/10/18/actors-hopl >>> >>> [9] http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf >>> >>> Sent from ProtonMail Mobile

April 1, 2018

Re: [Pharo-users] Regarding Raven: DOCap System

by henry

Thank you for your observations, Andrew. Allow me to take a moment to describe how differences appear in Smalltalk and Java, you have hit the nail squarely. I wish to mention two differences, one on the send side and the other on the resolve side. I also need to mention that it has been a number of years since I have had the Java version functioning, as I delved into making ParrotTalk work binary compatible between Smalltalk and Java. So I am rusty on how the Java side actually works. I just tested and the Reactor interface is not yet functional, so more work needed there. On the send side, Java does not have a doesNotUnderstand: mechanism, while Smalltalk does. I do not use special syntax for local async sends, like NewSpeak does, I just have a doesNotUnderstand: implementation in the ERef hierarchy, so when you write: 42 eventual * 10, it sends the * message as an eventual send rather than an immediate call. In Java you have to explicitly call redirectMessage... Here is code (not yet functional in Raven for Java) that demonstrates both an explicit redirectMessage, as well as whenResolved with a ReactorInterface anonymous class implementation. Ref ref = RefUtil.wrap("a pauwau is the best", Vat.getLocalVat()); Ref newRef = ref.redirectMessage("indexOf", "best"); newRef.whenResolved(new ReactorInterface<Integer>() { @Override public void value(Integer obj) throws NotResolvedException { isResolved = true; assertEquals(16, obj.intValue()); } @Override public void reactToLostClient(Exception e) throws NotResolvedException { assertTrue(false); } }); To your point on whenResolved differences between Smalltalk and Java, exactly. In Smalltalk all you need to do is pass a one-arg block closure with #whenResolved: to an eventual ERef: promise, remotePromise, nearRef or farRef. FarRef and RemotePromise will forward this to the remote vat. In Java, I am trying to use anonymous subclasses with a Templated Class for the expected return. More difficulty arises if there is more that one expected return type. In Smalltalk just query the class of the returned type within the block closure. It is also possible to have two or more whenResolved: reactor blocks, each with a test for a specific type or failure, and the failure of the resolved reactor should not break the eventual reference, just fail quietly until a successful reactor is encountered. In Java, you can have more than one reactor, with two different templated classes. The wrong cast should fail until the correct cast is found. Another thought is how scala works. I do not recall the name of the pattern matching by type, but in scala one can add more tha n one type to the pattern matching (I think it is pattern matching) and the correct code will be called. Perhaps Java's implementation of Raven needs scala code. I hope this helps understanding and answers your concerns regarding differences in return types from eventual sends, between a dynamic type system such as Smalltalk and static return types in Java. Please note there is also a Swift implementation of ParrotTalk. - HH âââââââ Original Message âââââââ On April 1, 2018 8:57 AM, <aglynn42(a)gmail.com> wrote: > One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces. Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing. > > If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses. A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier. i.e. in RMI you need pools of constant TCP connections, while in SST the transport needenât be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between âspacesâ or ânodesâ is required. > > If you avoid the nasties in Java and only support interop for self-describing types, you shouldnât need to write so much custom but rote code. If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers. Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation. > > If you keep in mind that although itâs a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself. > > Andrew > > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of henry > Sent: Saturday, March 31, 2018 3:46 PM > To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>; Pharo-users list <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Regarding Raven: DOCap System > > Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6 > > Sent from ProtonMail Mobile > > On Sat, Mar 31, 2018 at 15:43, henry <henry(a)callistohouse.club> wrote: > >> @m_m#3045 for concurrency without shared state, running on a single green thread (smalltalkâs Process) with support for remote async sends to other images, there is my Raven [1], using Cryptography [2], ParrotTalk [3] and STON. This is an implementation of erightâs [4] ELib. I am working on implementing STON for Java, inside the ASN1 project [5] as I already have ParrotTalk in Java [6], binary interoperate with Squeak/Pharo, and my Raven work in progress in Java [7]. This model allows message send redirection to a promise or farRef (or nearRef) as an asynchronous send returning a promise, which supports whenResolved/whenBroken handlers to be registered per PromiseERef. Iâll be happy to answer any questions you may be having about Raven. Raven is an implementation of an Actor model called Communicating Event Loops, in some literature [8] [9]. >> >> I hope this helps! >> >> [1] http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz >> >> [2] http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz >> >> [3] http://www.squeaksource.com/Cryptography/ParrotTalk-rww.19.mcz >> >> [4] http://erights.org/elib/index.html >> >> [5] https://github.com/CallistoHouseLtd/ASN1 >> >> [6] https://github.com/CallistoHouseLtd/ParrotTalk >> >> [7] https://github.com/CallistoHouseLtd/Raven >> >> [8] https://eighty-twenty.org/2016/10/18/actors-hopl >> >> [9] http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf >> >> Sent from ProtonMail Mobile

April 1, 2018

Re: [Pharo-users] Keeping packages up to date

by Andrei Stebakov

Exactly! I guess because there are so many ways to navigate around updating the package, I was lost :) Thank you guys for giving me some pointers, I'll try to learn them. I wonder, which one is the most promising and mainstream? On Sun, Apr 1, 2018, 08:58 <aglynn42(a)gmail.com> wrote: > You can open the repository in the Monticello browser if itâs a > Metacello/Monticello repo, or use Iceberg with git if itâs a git repo in > the same manner you would with any other git project. You can also open > the project in Versionner to get the latest version. > > > > As far as scripting it, thatâs reasonably obvious if you look at the > Monticello or Versionner code itself. > > > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Andrei > Stebakov > *Sent:* Saturday, March 31, 2018 7:14 PM > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* [Pharo-users] Keeping packages up to date > > > > I wonder if there is a generic solution to keeping certain Pharo project > in sync with development tree. > > For example when I want to get latest Roassal I execute > > Gofer it > > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > > package: 'Roassal2'; > > package: 'Roassal2GT'; > > package: 'Trachel'; > > load. > > > > Also I wouldn't know this unless the maintainers (thanks Alexandre!) of > the project told me what script to execute to get the latest version. > > If I went to Project Catalog I can only get the stable version and if I go > and find Roassal2 it won't give me information how to get its latest > version. > > > > How would I get info about how to update, say Roassal given the script > above from some Roassal project public page? > > Talking about Roassal, if I go to > http://smalltalkhub.com/#!/~ObjectProfile/Roassal2/ page, it offers the > following script: > > Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > configurationOf: 'Roassal2'; loadDevelopment > > > > Which is probably not exactly equal to the script above (or is it?). > > > > So, is there a generic way to get a latest version of some XYZ package? > > What do I need to learn to be able to get that information about any Pharo > project (other than asking the community)? Something similar to "git pull" > when you know the repository. >

April 1, 2018

Re: [Pharo-users] Regarding Raven: DOCap System

by aglynn42＠gmail.com

One thing that occurred to me is that the whenResolved etc. handlers only need to be customized to the degree that you want to interop with Java types that are not self-describing, such as the faked primitives and interfaces. Smalltalk types are uniformly self describing, allowing you to implement a single handler for all types, whereas only certain kinds of Java types are self-describing. If you think about it in terms of RMI, which is not really much different other than the metaphor not taking time and frequency of non-response into account, the promises and futures are much like stubs and skeletons, proxies for the remote message send and resulting method invocations/responses. A Smalltalk to Smalltalk interop such as SST, which is very similar to RMI, only needs one proxy for all objects, which makes abstracting it from the transport (and whether the transport is continuous etc.) much easier. i.e. in RMI you need pools of constant TCP connections, while in SST the transport needenât be a continuous connection, it could be entirely discrete such as http, and only one abstract connection between âspacesâ or ânodesâ is required. If you avoid the nasties in Java and only support interop for self-describing types, you shouldnât need to write so much custom but rote code. If you do need to support non self-describing types, only on those do you need the custom rote code in the handlers. Further if you use only one set of proxies, i.e. one future/promise/handler set, it will be much easier to keep Raven clean and separated from the transport implementation. If you keep in mind that although itâs a useful and powerful metaphor, the notion of futures, promises and the like is only a metaphor for invoking remote methods, which in turn is only a more mentally adhesive manner of describing remote procedure calls, with self-describing objects one handler can invoke the appropriate methods on the object by delegating the responsibility to the object itself. Andrew From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of henry Sent: Saturday, March 31, 2018 3:46 PM To: Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>; Pharo-users list <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Regarding Raven: DOCap System Raven is a remote, distributed object-capability system. I wanted to stress it runs distributedly over 2048-bit encrypted ParrotTalk 3.6 Sent from ProtonMail Mobile On Sat, Mar 31, 2018 at 15:43, henry <henry(a)callistohouse.club <mailto:henry@callistohouse.club> > wrote: @m_m#3045 for concurrency without shared state, running on a single green thread (smalltalkâs Process) with support for remote async sends to other images, there is my Raven [1], using Cryptography [2], ParrotTalk [3] and STON. This is an implementation of erightâs [4] ELib. I am working on implementing STON for Java, inside the ASN1 project [5] as I already have ParrotTalk in Java [6], binary interoperate with Squeak/Pharo, and my Raven work in progress in Java [7]. This model allows message send redirection to a promise or farRef (or nearRef) as an asynchronous send returning a promise, which supports whenResolved/whenBroken handlers to be registered per PromiseERef. Iâll be happy to answer any questions you may be having about Raven. Raven is an implementation of an Actor model called Communicating Event Loops, in some literature [8] [9]. I hope this helps! [1] http://www.squeaksource.com/Cryptography/Raven-HenryHouse.21.mcz [2] http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz [3] http://www.squeaksource.com/Cryptography/ParrotTalk-rww.19.mcz [4] http://erights.org/elib/index.html [5] https://github.com/CallistoHouseLtd/ASN1 [6] https://github.com/CallistoHouseLtd/ParrotTalk [7] https://github.com/CallistoHouseLtd/Raven [8] https://eighty-twenty.org/2016/10/18/actors-hopl [9] http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf Sent from ProtonMail Mobile

April 1, 2018

Re: [Pharo-users] Keeping packages up to date

by aglynn42＠gmail.com

You can open the repository in the Monticello browser if itâs a Metacello/Monticello repo, or use Iceberg with git if itâs a git repo in the same manner you would with any other git project. You can also open the project in Versionner to get the latest version. As far as scripting it, thatâs reasonably obvious if you look at the Monticello or Versionner code itself. From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Andrei Stebakov Sent: Saturday, March 31, 2018 7:14 PM To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] Keeping packages up to date I wonder if there is a generic solution to keeping certain Pharo project in sync with development tree. For example when I want to get latest Roassal I execute Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'Roassal2'; package: 'Roassal2GT'; package: 'Trachel'; load. Also I wouldn't know this unless the maintainers (thanks Alexandre!) of the project told me what script to execute to get the latest version. If I went to Project Catalog I can only get the stable version and if I go and find Roassal2 it won't give me information how to get its latest version. How would I get info about how to update, say Roassal given the script above from some Roassal project public page? Talking about Roassal, if I go to http://smalltalkhub.com/#!/~ObjectProfile/Roassal2/ page, it offers the following script: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadDevelopment Which is probably not exactly equal to the script above (or is it?). So, is there a generic way to get a latest version of some XYZ package? What do I need to learn to be able to get that information about any Pharo project (other than asking the community)? Something similar to "git pull" when you know the repository.

April 1, 2018

Re: [Pharo-users] PharoLauncher image loading error

by Hilaire

Le 31/03/2018 Ã 16:03, Stephane Ducasse a Ã©critÂ : >>> And you are on MacOSX? >> No, I am not. Just some testing on school computers. > Can you tell us then on which os? which version? Mentioned earlier on this thread > >>> Can you describe what you did? Because with the Launcher you can also >> I open the "Official distributions" subtree, select Pharo6.1 then click on >> the icon with the play symbol, on the top of the window. > Is the disc where the launcher is located in read write mode? I guess so as it was copied there on the first place, the hard disk, on the dekstop. > > > Stef > > -- Dr. Geo http://drgeo.eu

April 1, 2018

Re: [Pharo-users] Namespaces and ASN1 types in Cryptography package

by Stephane Ducasse

Hi holger we are planning to work again on Module once we release Pillar 70 and Iceberg v2.0. We did not want to let Pillar die so we had to do something to put it in the rails for the future. I hope that by mid may we will get some traction and time to work again on the class infrastructure. Stef On Sat, Mar 31, 2018 at 6:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi Holger, > > Cryptography package lacks a proper modularization, so you could load > only the groups you need, e.g. ASN1 will only be needed if you load > X509 (AFAIR). > > If Nortbert's ASN1 package is more complete than Cryptography's, then > we whould either merge it or discard what's there and load Norbert's > ASN1 package as a dependency instead. > > Regards, > > > Esteban A. Maringolo > > > 2018-03-31 12:11 GMT-03:00 Holger Freyther <holger(a)freyther.de>: >> Hi, >> >> I was debugging some test failures and it turns out that my code defines an ASN1IntegerType and the Cryptography package (a dependency of MongoTalk which is loaded into my code) has such a class as well. >> >> Thanks to Epicea I could see which package added the method but now I have no idea how to resolve the problem. Mongotalk needs PBKDF2 for modern authentication... Could Cryptography use "ASN1-Model"[1] instead? This is a rather complete[2] ASN1 implementation and used in production for some years. Could the classes be prefixed? >> >> If not how can I instruct Metacello to not load a certain package? >> >> holger >> >> >> [1] http://smalltalkhub.com/#!/~NorbertHartl/ASN1/source >> [2] Rather complete parser for ASN1 files but only encoding/decoding for DER/BER (none of the modern ones like aper/uper >

April 1, 2018

Re: [Pharo-users] Keeping packages up to date

by Stephane Ducasse

Alexandre should publish a version in the catalog browser. Projects should push their configuration once there are stable and updated. On Sun, Apr 1, 2018 at 1:14 AM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > I wonder if there is a generic solution to keeping certain Pharo project in > sync with development tree. > For example when I want to get latest Roassal I execute > Gofer it > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > package: 'Roassal2'; > package: 'Roassal2GT'; > package: 'Trachel'; > load. > > Also I wouldn't know this unless the maintainers (thanks Alexandre!) of the > project told me what script to execute to get the latest version. > If I went to Project Catalog I can only get the stable version and if I go > and find Roassal2 it won't give me information how to get its latest > version. > > How would I get info about how to update, say Roassal given the script above > from some Roassal project public page? > Talking about Roassal, if I go to > http://smalltalkhub.com/#!/~ObjectProfile/Roassal2/ page, it offers the > following script: > Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > configurationOf: 'Roassal2'; loadDevelopment > > Which is probably not exactly equal to the script above (or is it?). > > So, is there a generic way to get a latest version of some XYZ package? > What do I need to learn to be able to get that information about any Pharo > project (other than asking the community)? Something similar to "git pull" > when you know the repository.

April 1, 2018