Hi all,
About a year ago I accidentally a small Erlang-style Actors implementation for Squeak, based on subclassing Process, using Message for, er, messages, and using Promise for RPC.
It draws on my experience of Erlang programming in a few ways: it has links and monitors for between-actor failure signalling; it has library actors representing sockets; it has a simple tracing facility. There's crude and no doubt heavily problematic support for basic Morphic interaction.
Over the past couple of weeks I've been dusting it off, fleshing it out, and documenting it. (Hence some of the stuff I've been trying out wrt Promises.)
It's available at http://squeaksource.com/Actors.html.
Installation instructions, documentation and tutorials can be found at
https://tonyg.github.io/squeak-actors/
(I spent rather too much time writing documentation.)
It's by no means as ambitious as Squeak-E or Henry's Raven - it only deals with single-image in-image messaging between actors, and doesn't have the E-style ability to refer to objects within a vat. Instead it follows Erlang in having references denote actors (i.e. vats, roughly), rather than anything more fine-grained.
Next steps could be:
- a Workspace that was actor aware, i.e. each Workspace an actor. - better Supervisors. - tools for visualizing the current constellation of actors, perhaps based on Ned Konz's Connectors? - an ActorEventTrace subclass that is able to draw message interaction diagrams as a Morph. - a screencast of building an IRC client maybe?
Cheers, Tony
PS. I did try to port it to Pharo. The first obstacle was lack of class Promise - fairly easily overcome. The second, worse obstacle was weird failures and incompatibilities in Socket support. I gave up at that point.
PPS. I'd love to see it running on Cuis.
On 19 February 2018 at 16:23, Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
Hi all,
About a year ago I accidentally a small Erlang-style Actors implementation for Squeak, based on subclassing Process, using Message for, er, messages, and using Promise for RPC.
It draws on my experience of Erlang programming in a few ways: it has links and monitors for between-actor failure signalling; it has library actors representing sockets; it has a simple tracing facility. There's crude and no doubt heavily problematic support for basic Morphic interaction.
Over the past couple of weeks I've been dusting it off, fleshing it out, and documenting it. (Hence some of the stuff I've been trying out wrt Promises.)
It's available at http://squeaksource.com/Actors.html.
Installation instructions, documentation and tutorials can be found at
https://tonyg.github.io/squeak-actors/(I spent rather too much time writing documentation.)
It's by no means as ambitious as Squeak-E or Henry's Raven - it only deals with single-image in-image messaging between actors, and doesn't have the E-style ability to refer to objects within a vat. Instead it follows Erlang in having references denote actors (i.e. vats, roughly), rather than anything more fine-grained.
Next steps could be:
- a Workspace that was actor aware, i.e. each Workspace an actor.
- better Supervisors.
- tools for visualizing the current constellation of actors, perhaps based on Ned Konz's Connectors?
- an ActorEventTrace subclass that is able to draw message interaction diagrams as a Morph.
- a screencast of building an IRC client maybe?
Cheers, Tony
PS. I did try to port it to Pharo. The first obstacle was lack of class Promise - fairly easily overcome. The second, worse obstacle was weird failures and incompatibilities in Socket support. I gave up at that point.
PPS. I'd love to see it running on Cuis.
Nice!
- Bert -
I am not familiar with Erlang. Does it make sense to extend your Actors to multi-image with Raven. Please load Raven and consider the tests in OperationalTestCase.
Sent from ProtonMail Mobile
On Mon, Feb 19, 2018 at 10:23, Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
Hi all, About a year ago I accidentally a small Erlang-style Actors implementation for Squeak, based on subclassing Process, using Message for, er, messages, and using Promise for RPC. It draws on my experience of Erlang programming in a few ways: it has links and monitors for between-actor failure signalling; it has library actors representing sockets; it has a simple tracing facility. There's crude and no doubt heavily problematic support for basic Morphic interaction. Over the past couple of weeks I've been dusting it off, fleshing it out, and documenting it. (Hence some of the stuff I've been trying out wrt Promises.) It's available at http://squeaksource.com/Actors.html. Installation instructions, documentation and tutorials can be found at https://tonyg.github.io/squeak-actors/ (I spent rather too much time writing documentation.) It's by no means as ambitious as Squeak-E or Henry's Raven - it only deals with single-image in-image messaging between actors, and doesn't have the E-style ability to refer to objects within a vat. Instead it follows Erlang in having references denote actors (i.e. vats, roughly), rather than anything more fine-grained. Next steps could be: - a Workspace that was actor aware, i.e. each Workspace an actor. - better Supervisors. - tools for visualizing the current constellation of actors, perhaps based on Ned Konz's Connectors? - an ActorEventTrace subclass that is able to draw message interaction diagrams as a Morph. - a screencast of building an IRC client maybe? Cheers, Tony PS. I did try to port it to Pharo. The first obstacle was lack of class Promise - fairly easily overcome. The second, worse obstacle was weird failures and incompatibilities in Socket support. I gave up at that point. PPS. I'd love to see it running on Cuis.
On 19-02-2018, at 7:23 AM, Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
(I spent rather too much time writing documentation.)
I'm pretty sure that is impossible except in the very special sense of spending time getting it wrong and having to redo it. Which probably in't even a mistake in truth.
I really wish the software world in general would live by the aphorism "don't document the program, program the document" rather than "comments? why do you think we call it code?"
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Diarrhea of the mouth; constipation of the ideas.
Donald E. Knuth’s work on Literate Programming may be of interest:
<https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming> <http://www.literateprogramming.com/knuthweb.pdf http://www.literateprogramming.com/knuthweb.pdf> <https://cs.stanford.edu/~knuth/lp.html https://cs.stanford.edu/~knuth/lp.html>
Ken G. Brown
On Feb 19, 2018, at 11:18, tim Rowledge tim@rowledge.org wrote:
On 19-02-2018, at 7:23 AM, Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
(I spent rather too much time writing documentation.)
I'm pretty sure that is impossible except in the very special sense of spending time getting it wrong and having to redo it. Which probably in't even a mistake in truth.
I really wish the software world in general would live by the aphorism "don't document the program, program the document" rather than "comments? why do you think we call it code?"
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Diarrhea of the mouth; constipation of the ideas.
On 19-02-2018, at 11:08 AM, Ken G. Brown kbrown@mac.com wrote:
Donald E. Knuth’s work on Literate Programming may be of interest:
Yah, I've seen Don's stuff and even chatted with him about it on occasion. It's just that nobody much seems to care...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IA: Illogical And
timrowledge wrote
Yah, I've seen Don's stuff and even chatted with him about it on occasion. It's just that nobody much seems to care...
While it does seem correct that 99.9% don't seem to care, I feel like we are the perfect community to fully flesh out his ideas. IMO GT tools and Grafoscopio are serious explorations in this direction.
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
so i am not a developer i guess so i guess that means i can be ignored if i understand the way this works correctly but this is an announcement so i take a chance at annoying devs respectfully i may be clueless about these things totally to boot royally so i have to assk maybe to find out more about these rules of morality if anyone happens to step into this pile of plurality by accidental duality hopefully it’s not too smelly nor needs no scraping off of the foot ok enough
So how do i connect from MoosePharo to Squeak to make use of this Actors for Squeak? I have an Actors for Pharo Package loaded into Moose. Any overlap?
I am interested in connecting different languages or images together anything spring to mind? it seems like there are a lot of ways to do this Are there any Packages that spring to mind? Oh i guess Actors for Squeak doesn’t do multi images. But maybe Raven can help. The idea seems to be to show Actors interacting graphically. Could this be used to show ErLang Actors interacting graphically? Is this something ErLangers would want? or do they already have something And if so then how to connect ErLang to Squeak if there was is or i made a patchwork of interlingua connectors then having a graphical way of looking at it seems like a good thing
( i am using Moose because when i try to load Roassal into Pharo it fails ( i think i tried twice once recently ) also i like the Moose thing although i don’t seem to be able to really make it work for me and i guess it’s big )
On Mon, Feb 19, 2018 at 07:23 Tony Garnock-Jones tonyg@leastfixedpoint.com wrote:
Hi all,
About a year ago I accidentally a small Erlang-style Actors implementation for Squeak, based on subclassing Process, using Message for, er, messages, and using Promise for RPC.
It draws on my experience of Erlang programming in a few ways: it has links and monitors for between-actor failure signalling; it has library actors representing sockets; it has a simple tracing facility. There's crude and no doubt heavily problematic support for basic Morphic interaction.
Over the past couple of weeks I've been dusting it off, fleshing it out, and documenting it. (Hence some of the stuff I've been trying out wrt Promises.)
It's available at http://squeaksource.com/Actors.html.
Installation instructions, documentation and tutorials can be found at
https://tonyg.github.io/squeak-actors/(I spent rather too much time writing documentation.)
It's by no means as ambitious as Squeak-E or Henry's Raven - it only deals with single-image in-image messaging between actors, and doesn't have the E-style ability to refer to objects within a vat. Instead it follows Erlang in having references denote actors (i.e. vats, roughly), rather than anything more fine-grained.
Next steps could be:
- a Workspace that was actor aware, i.e. each Workspace an actor.
- better Supervisors.
- tools for visualizing the current constellation of actors, perhaps based on Ned Konz's Connectors?
- an ActorEventTrace subclass that is able to draw message interaction diagrams as a Morph.
- a screencast of building an IRC client maybe?
Cheers, Tony
PS. I did try to port it to Pharo. The first obstacle was lack of class Promise - fairly easily overcome. The second, worse obstacle was weird failures and incompatibilities in Socket support. I gave up at that point.
PPS. I'd love to see it running on Cuis.
On 02/20/2018 01:45 PM, Kjell Godo wrote:
So how do i connect from MoosePharo to Squeak to make use of this Actors for Squeak?
It's probably not directly possible.
I have an Actors for Pharo Package loaded into Moose. Any overlap?
I'd love to see that! Can you point me to the one you mean?
I am interested in connecting different languages or images together anything spring to mind? it seems like there are a lot of ways to do this Are there any Packages that spring to mind? Oh i guess Actors for Squeak doesn’t do multi images. But maybe Raven can help.
Yes, Raven is a good starting point for learning about the Squeak-E line of work on this kind of thing. There's a lot of great ideas in there.
You might be interested in the content at http://www.erights.org/, an archive of the (now broad and deep) object-capabilities literature stretching back several decades. It's not always organised super well, but there is some awesome stuff to be found in there.
If you want to learn more about actors more generally, perhaps this might be helpful: https://eighty-twenty.org/2016/10/18/actors-hopl
The idea seems to be to show Actors interacting graphically.
I don't have any kind of graphical representation of actors yet. But it would be fun to experiment with.
Could this be used to show ErLang Actors interacting graphically?
Unlikely, not without a lot of work. There are already some tools for this kind of thing in Erlang.
Tony
On 02/20/2018 01:55 PM, Tony Garnock-Jones wrote:
If you want to learn more about actors more generally, perhaps this might be helpful: https://eighty-twenty.org/2016/10/18/actors-hopl
Actually that's a bit self-serving. Sorry.
A great survey of different kinds of actor systems can be found in
“43 Years of Actors: a Taxonomy of Actor Models and Their Key Properties”, Joeri De Koster, Tom Van Cutsem, and Wolfgang De Meuter, Proc. AGERE Workshop, 2016.
ACM metadata: https://dl.acm.org/citation.cfm?id=3001890 Tech Report version (PDF): http://soft.vub.ac.be/Publications/2016/vub-soft-tr-16-11.pdf
Tony
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
henry -
Ken G. Brown -
Kjell Godo -
Sean P. DeNigris -
tim Rowledge -
Tony Garnock-Jones