
Actalk info file:

	INFO


Version & Date:
---------------

Actalk version 3.06 (version 3 release 06)
Jean-Pierre Briot
8 February 1996


Purpose:
--------

This file provides minimal info on installation and use of Actalk testbed.

There are also various papers decribing Actalk project.
Please refer to info file README (section 'Access:')
for information about how to access them.

Within these papers,
the most up to date is file 'synchro-todai-report-97-07.ps.gz'
It provides a general introduction to Actalk architecture
and developed examples of modeling various synchronization schemes.

It is up to date with version 06.

The following alternative files are up to date with version 05, but NOT with
version 06.

File 'actalk-slides94.ps.Z' is a set of slides summarizing
the architecture design, parameterization, hierarchies, and possibilities.

If you read french, you may rather/also look at file/paper
'actalk-lmo94.fr.ps.Z'
as it provides a similar summary within a real text/paper.


Note that this INFO file won't duplicate the description provided by papers
mentioned above.
INFO file will rather focus onto some practical aspects of using the Actalk
platform.


Installation:
-------------

After untaring the distribution (tar) file, you should have the following files
in your current directory:

	README			entry point info file,
	VERSION_3.*		info file about versions,
	INFO			info file about actual installation and use,
	Actalk-FileIn.st	the loading file,
	src/			directory containing source files.

First you have to edit the loading file named Actalk-FileIn.st.

It looks like (<...> indicates missing lines):

-------------- begin
"
Actalk loading file:

	Actalk-FileIn.st

<...>

| path |
	"Mac Finder:"
path := 'Macintosh HD:Programmation:Smalltalk-80:Actalk:3:06:src:'.
	"Unix:"
path := '/home/camille1/briot/smalltalk/actalk/3/06/src/'.

<...>
-------------- end

You have to rewrite the path name string according to current directory.
Notice that two examples of paths are proposed depending on whether you load
Actalk on a Macintosh or Unix workstation.
Put under comments (some "") or remove the path that which you possibly don't use.

Then you may launch VisualWorks Release 2.0 (or more recent, but not tested).

Through a FileList tool, you may load file Actalk-FileIn.st.

This will load the entire Actalk system.

If everything works fine (it should!),
by opening a new browser or updating one,
you will find listed numerous new categories, all starting with 'Actalk'.

You may then save an Actalk image
to avoid having to reload the source files next time.


Comments:
---------

Following information provides minimal insights into the objectives and
architecture of the Actalk testbed, as well as main advices for using it.
Most of information is currently located within the documentation of
the program itself.
Every class is commented, as well as every non trivial method.
So look for comments!
Also look for examples!


Libraries:
----------

The Actalk libraries are organized as Smalltalk-80 categories
(modules of classes).
Actalk libraries may be decomposed into:

	Actalk-Kernel-*		the kernel categories,
	Actalk-Examples		examples,
	Actalk-Ext-*		extensions to describe and implement
				various OOCP languages models and constructs,
	Actalk-Ext-*-Ex*	associated examples,
	Actalk-Synchro-*	extensions specific to describe
				various policies for synchronizing requests,
	Actalk-Synchro-*-Ex*	associated examples,

	*			remaining files are library facilities for
				kernel usage, support for examples,
				and environment facilities
				(e.g., time-slicing facility).


Decomposition of an Actalk active object:
-----------------------------------------

In Actalk, an active object is composed of the following three components
(seen from outside and along the message flow):

	an address	where messages will arrive and be buffered,

	an activity	which will fetch incoming messages and
			pass them to the behavior,

	a behavior	the actual object which will ultimately
			compute the messages.

Note that the activity owns an autonomous process in order to provide autonomy
to the active object.

The user defines a class of behaviors of active objects (as a subclass of
class ActiveObject).
The two other components will be created transparently when actually creating
the active object.


Kernel Classes:
---------------

Accordingly to this decomposition, the Actalk kernel is decomposed into three classes:

	ActiveObject	the behavior of the active object.
			Subclasses define user programs.
			Some abstract subclasses may also define
			specific programming constructs.

	Activity	the activity of the active object.
			It provides its autonomous process.
			It controls acceptance of messages/requests
			by the active object.
			Abstract subclasses may define various models of
			message acceptance and synchronization.
			Subclasses may also define synchronization
			of user programs. (This enforces separation
			between the behavior/code of an active object
			and the specification of its inner synchronization).

	Address		the address of the active object.
			Abstract subclasses may define various models of
			communication.

These kernel classes define the default and standard semantics
of active objects, that is,

their activity is:

	serialized	serially compute one message at a time,
	reactive	are activated only by message passing,

their communication is:

	asynchronous	when sending a message, the sender does not
			wait for acceptance nor completion of the message,
	unidirectional	no value is returned to the sender.


Differences with standard Smalltalk programs:
---------------------------------------------

To define and use an Actalk active object,
there are four main differences compared with standard Smalltalk programming:

1)
The class defining the behavior of an active object should be defined
as a subclass of class ActiveObject (or one of its subclasses)
and not as a subclass of class Object.

(If we take the seminal example of a counter, see category Actalk-Examples)

	ActiveObject subclass: #Counter
		instanceVariableNames: 'contents '
		classVariableNames: ''
		poolDictionaries: ''
		category: 'Actalk-Examples'

2)
When creating an instance of the active object behavior class,
message 'active' should be sent to the new instance in order to construct
and activate the active object (and actually return its address):

	Counter new active.
	"or"
	(Counter new contents: 100) active

3)
For standard Actalk objects (as defined by the kernel),
message passing is undidirectional, that is no implicit reply is returned
as a value of the message transmission.
If a reply is needed, one should explicitly program the reply message,
as well as conveying the reply destination as a parameter of the initial message.

	consultAndReplyTo: replyDestination
		"Consult the contents and reply it to the reply destination."

		replyDestination reply: contents

Note that default reply selector is by convention the selector 'reply:'.

See categories Actalk-Examples and Actalk-Kernel-ReplyDest
for predefined reply destination active objects.
(Note also that classes ImplicitReplyActivity/Address within category
Actalk-Ext-ImplicitReply provide implicit reply as in standard Smalltalk-80,
and classes such as AbclAddress provide various communication types).

4)
The self reference of an active object is pseudo variable 'aself' (and not 'self').
'aself' represents the address of the active object (external reference).
'self' represents the behavior of the active object itself
(as for a standard Smalltalk-80 object).


More on the self/aself distinction:
-----------------------------------

Note that by sending a message to 'aself', the active object behavior sends
a message to its own address
(default interpretation is as an asynchronous message send).
By sending a message to 'self', the active object behavior sends
(as in standard Smalltalk) a message directly to itself (behavior).

In order to clearly distinguish within a behavior between:
standard Smalltalk-80 methods (for instance to initialize instance variables),
and "active object" methods intended to be sent to the address,
we propose the following convention.

We group "active object methods" within the category protocol named 'script'.
They are to be sent to the address (reference) of the active object.
That is they are public and may be used by other (active) objects
as well as by the active object itself.

Alternatively, when modeling medium grained or large grained active objects,
inner computation may be described as standard Smalltalk message passing
between the sub components of the behavior, being standard objects.
By convention such private inner computation methods are grouped within
the category protocol named 'private routines'.
(We actually follow ABCL/1 terminology and convention.)
Such standard Smalltalk-80 methods should only be requested
by the behavior itself (by sending a message to 'self').

Last note: when passing its reference to other objects, the active object
should use 'aself' as this is its external reference.

In summary:

	one should use always use 'aself' in place of 'self'
	except when calling a private routine computed internally.

This is dangerous for an active object to pass the reference to its behavior
('self') to other objects.
This is because synchronization encapsulation is broken and inconsistencies
may appear in case of concurrent activations.


About super:
------------

Note that 'super' may be used as usual for private routines
in order to call methods which have been redefined.
Meanwhile there is no 'asuper' but it is not very useful.
The only difference with using 'super' would be by calling the inherited
method through a message sent to the address rather than by calling it
internally.


Starting up:
------------

To start up, first look at category Actalk-Examples.
More generally speaking, look for comments (of the classes and the methods).
Also look for example methods
(class method protocol 'example' in example categories,
that is categories ending with 'Ex' or 'Examples').

You may then start to explore other extension categories and related examples.

Note that class ActiveObject (category Actalk-Kernel)
is the entry point class of Actalk.
Class ActiveObject provides some useful class methods to trace events
(receiving, accepting and completing a message),
and also to terminate/clean up active objects.
(This latter facility happens to be necessary to help the garbage collector
recovering active objects. See section 'Warnings:'.)


Generic events methods:
-----------------------

Actalk includes generic event handling methods.
There are three of them, associated to:
receiving, accepting, and completing a message.

They may be used for:
	tracing methods,
	control scheduling (see Section 'Scheduling concurrency:'),
	step execution (by calling method halt),
	broadcast changes (for instance to views in a MVC dependencies framework),
	etc...

They are also actually used by the system itself for modeling extensions,
e.g., synchronization policies.

Their main use at the user level is for tracing events.
Class ActiveObject actually includes class methods ('setTrace:' and others)
to automatically generate tracing methods for a given class.
(See class ActiveObject comment.)

Note that there is actually a fourth user-level generic event method
associated to sending a message. However it is triggered when sending a message
only to some specific active objects (which capture the sender).
(We don't include that feature of capturing the sender
within the standard kernel
because this adds some extra computation cost.)
See class Basic2ActiveObject comment in category 'Actalk-Kernel-Basic'.


Scheduling concurrency:
-----------------------

Actalk provides concurrent activities, thanks to standard Smalltalk-80
multi processing facility.
Meanwhile, standard Smalltalk-80 scheduler does not provide time-slicing.
As a result, some process may keep the processor until termination
(unless there is some other higher priority process preempting it).
This is not very satisfactory to simulate fair concurrency between activities.

By evaluating the expression 'Processor yield', one may (explicitly)
force the way to other processes.
In order to avoid putting such control statements within the programs,
the programmer may use generic event methods
(see Section 'Generic event methods:' above) to include 'Processor yield'.
This solution is abstract enough, but is unfortunately not fully complete.
This is because private routines won't be affected by generic events.
Moreover scheduling as explicitly triggered by 'Processor yield' is not
necessarily very fair between activities.

In order to provide a more complete solution,
we currently include within the testbed libraries a minimal extension
to provide time-slicing (implicit fair sharing of processor between processes).
This is a small goodies written by Hubert Baumeister, at Dortmund University,
and provided through the Manchester Smalltalk Archive Library.

By default this time-slicing facility is not active.
It may be activated by evaluating expression:
'ProcessorScheduler startTimeSlicingEvery: <time slice in milliseconds>',
and terminated by evaluating:
'ProcessorScheduler stopTimeSlicing'.
If activated, it is then necessary to protect/serialize the Transcript window,
by evaluating: 'SharedTextCollector setProtectedTranscript'.

Please see class ProcessorScheduler class method protocol 'slc' for
entry points, detailed information, and implementation.

In the future we intend to port and integrate a more elaborate
and generic time-slicing scheduler
which had been developed in Actalk version 2 by Loic Lescaudron.


Environment Tools:
------------------

Customizing environment tools for active objects
(including an extended MVC-based user-interface framework) is another
dual project which has been achieved into previous version 2
(implemented by Loic Lescaudron in Smalltalk-80 release 2.5).
These tools should be eventually reintroduced within current Actalk version 3.


Warnings:
---------

Actalk has some specificities in terms of the behavior of active objects
and the way standard Smalltalk-80 programming tools may work on them.

Errors.

In case of error within an active object (e.g., does not understand a message)
its activity process is then stopped.
Then you have to proceed in the notifier or debugger window
or to reset it if you want the behavior to resume its activity.
(Note that actually we often happen to just restart the whole program
with a brand new set of objects and active objects).

An important issue is that the debugger only shows the stack of messages of
current active object. Information about the sender has been lost,
because of the asynchronous transmission.
A simple prototype debugger reconstructing such links had been designed for Actalk
version 1 (at the expense of computing and storing the sender context at message passing time).
We intend to eventually port and integrate this extended debugger
within current version.

Garbage collection of processes.

Note: that previous problem (see INFO file for version 05) has been solved.
VisualWorks garbage collector does collect processes which are waiting on a
semaphore which is no more referenced.
Thus there is no need to manually clean up from time to time
Actalk objects which are no more necessary.
(See category 'process cleanup' in class Activity for details).

Author(s):
----------

Actalk version 3 is currently being developed by Jean-Pierre Briot.
However many other people contributed (and will still contribute, we hope!)
to the history of its development. See section 'Acknowledgements:' below.


Acknowledgements:
-----------------

Actalk version 1 has been initially designed and developed by Jean-Pierre Briot.

Loic Lescaudron designed and implemented version 2,
including programming environment tools.
We sincerely thank him for his prime contribution to the development
of Actalk.

Other contributors are people who developed some parts, some experiments,
or some systems built upon Actalk foundation:

the GLA DESS program, University Pierre et Marie Curie, Paris,
who developed the initial extended MVC-based user-interface framework,
including Gilles Moussion, who developed the initial time-slicing scheduler,
and Pierre Abramovici, who developed a prototype multi-agent system (Agentalk);

Nicolas Graube, LITP, Paris, who designed a prototype compiler for automatically
generating continuations from a high-level functional style program description;

Robert Voyer, INT, Evry, who interfaced his OKS AI system (which compiles
production rules into daemons) with Actalk in order to gain concurrent activation
of daemons;

Malik Bouabsa, LITP, Paris, who designed an extended window mechanism
for version 2 (in Smalltalk-80 version 2.5);

Sylvie Lemarie, LITP, Paris, who transposed the Actalk kernel
into C++ and also studied its distributed implementation onto transputers;

the DESS program, Nantes University, supervised by Jean Bezivin and
Olivier Roux, who developed many Actalk extensions
(POOL, OCCAM, CSP, synchronization counters).
(Actually their implementations of POOL and synchronization counters
have been revised and integrated within current version 3);

the multi-agents research team headed by Jacques Ferber, Laforia, Paris,
and more specifically Alexis Drogoul, Thierry Bouron and Claude Delaye,
who developed various Actalk-based multi-agents platforms
with various granularities and goals (Ecotalk, Magentalk...);

Francois Goret, LITP/Laforia, Paris, who ported the Actalk kernel (version 1)
to Smalltalk-V and moreover used Actalk as an inspirational foundation
to design a novel distributed computation model;

Sylvain Giroux, University of Montreal, who developed a reflexive system
based on Actalk, named ReActalk;

Annick Fron, AFC, who recently transposed an experimental constraint solving system
into a concurrent version implemented in Actalk, and for her feedback
and encouragement;

Xavier Briffault, at Limsi, Orsay, who is currently experimenting with Actalk
to develop a natural language (multi-agent-based) processing system;

Key supporters of Actalk through their feedback and encouragements
(and not yet cited) have been:
Les Gasser, USC, L.A., and Jean-Francois Perrot, Laforia, Paris.

We also thank Akinori Yonezawa for his current support and comments,
as well as people within his lab, notably Jeff McAffer and Laurent Thomas
for several discussions about OOP, concurrency, synchronization, reflection,
and... Smalltalk of course!

Recently :
Martin Kobetic, University of Bratislava and ArtInAppleS, Bratislava, Slovakia,
designed and implemented a CORBA-like distributed extension (called the SORB),
Peter Neuhaus, University of Freibug, Germany, ported (in VisualWorks 2.0)
and updated the original version of a prototype debugger extension
(it has been included in version 06, under category 'Actalk-Debug').
and Jean-Paul Smets, ENS, Paris, ported Actalk in SmalltalkAgents, and did
various experiments with computer graphics,
We would like to thank them here !

Influences:
-----------

Key influences for Actalk are following:

ConcurrentSmalltalk (Yasuhiro Yokote and Mario Tokoro, OOPSLA'86&87)
as an OOCP language based on Smalltalk.
Of prime interest was also the simultaneous evolution of ConcurrentSmalltalk
into a more portable system (ConcurrentSmalltalk90) by Hideaki Okamura.

Simtalk (Jean Bezivin, OOPSLA'87) as a testbed using Smalltalk-80
to classify and compare various simulation models and constructs.
Simtalk includes implementation of various synchronization policies
(monitors,...) for concurrent activities.
In some way Simtalk and Actalk are complementary as Simtalk focus is more on
simulation and synchronization of processes on passive shared data,
whereas Actalk exclusive focus is on languages with the notion of
active objects.

All OOCP languages modeled within Actalk extensions (Actors, ABCL/1, POOL...)
have been, needless to say, influences to Actalk.


Last words:
-----------

Have fun!
The development of Actalk is still open.
We are welcoming any feedback (good or not) from you!
Please share your experience with the community!
(Please let us know of your possible experiments and developments
so we could possibly broadcast and include them within next release/version
of the environment).

Thank you.

Jean-Pierre Briot
