- Pharo-users - lists.pharo.org

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

by Andrei Stebakov

Thank you! On Sun, Apr 1, 2018, 14:00 Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Andrei > > if you need help we can help you. > > Stef > > On Sun, Apr 1, 2018 at 7:59 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > use metacello and iceberg or gitfiletree > > > > Stef > > > > On Sun, Apr 1, 2018 at 4:32 PM, Andrei Stebakov <lispercat(a)gmail.com> > wrote: > >> 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] [Seaside-dev] [Seaside] [ANN] MaterialDesignLite for Seaside v1.2.0

by Cyril Ferlicot D.

On 01/04/2018 03:53, Esteban A. Maringolo wrote: > Wow. Impressive work. > Thank you for sharing this. > Thank you! > I have my feets too deep into Bootstrap these days, do you have any > compelling reason that might tempt me to move to MDL? > I don't think there is really a better solution between MDL for Seaside and Bootstrap. Both have their advantages and for me the first reason to chose one or the other is what you're comfortable with. Bootstrap has a lost of plugins we can bind to Seaside. MDL for Seaside now has widgets and extensions directly available with features such as list dynamically loading with ajax and I would like to add more with time. Personally I prefer MDL for two reasons. - I prefer the design of Material Design to the one of Bootstrap - More importantly, I hate the columns system of Bootstrap Columns were a good JS feature because more flexible than tables and helped to create responsive applications. Now CSS comes with the native flex display and I find it much more flexible than columns. (https://css-tricks.com/snippets/css/a-guide-to-flexbox/) And now it's supported by all the major browsers since some versions (except IE8 and previous...). So to answer your question I think it all depends on you and your project. (I know I'm not really selling well what I'm working on but my main goal is to help web developers here, not to convert them :) ) > Regards, > > Esteban A. Maringolo > > -- Cyril Ferlicot https://ferlicot.fr

April 1, 2018

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

by Stephane Ducasse

Andrei if you need help we can help you. Stef On Sun, Apr 1, 2018 at 7:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > use metacello and iceberg or gitfiletree > > Stef > > On Sun, Apr 1, 2018 at 4:32 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: >> 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] Keeping packages up to date

by Stephane Ducasse

use metacello and iceberg or gitfiletree Stef On Sun, Apr 1, 2018 at 4:32 PM, Andrei Stebakov <lispercat(a)gmail.com> wrote: > 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 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] 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