Differences

This shows you the differences between the selected revision and the current version of the page.

at:tutorial:appendix 2008/07/10 17:41 at:tutorial:appendix 2020/04/28 19:47 current
Line 1: Line 1:
====== Appendix: Libraries ====== ====== Appendix: Libraries ======
-In the appendix, we explain useful libraries available to the AmbientTalk/2 programmer. These libraries provide abstractions ranging from traditional, established "collections" up to newly researched language constructs, such as "ambient references".+In the appendix, we explain useful libraries available to the AmbientTalk/2 programmer as part of the AmbientTalk standard library, also known as ''atlib''. These libraries provide abstractions ranging from traditional, established "collections" up to newly researched language constructs, such as "ambient references". 
 + 
 +The Ambientalk standard library (''atlib'') is part of the AmbientTalk/2 distribution. Note that the Intellij plugin already contains ''atlib''. If you would like to access the atlib source files, please visit the dedicated gitlab project [[ https://gitlab.soft.vub.ac.be/ambienttalk/atlib |here.]]
===== Unit Testing Framework ===== ===== Unit Testing Framework =====
Line 27: Line 29:
This will execute all ''test*'' methods in the given unit test (in an **undefined** order!), and print out which of the tests succeeded or failed. The ''runTest'' method can optionally take a "reporter" object as an argument, which can be used to implement a custom strategy for reporting success or failure of a unit test. The default reporter object is a text-based UI. This will execute all ''test*'' methods in the given unit test (in an **undefined** order!), and print out which of the tests succeeded or failed. The ''runTest'' method can optionally take a "reporter" object as an argument, which can be used to implement a custom strategy for reporting success or failure of a unit test. The default reporter object is a text-based UI.
-Like in JUnit and SUnit, it is possible to define two methods named ''setUp()'' and ''tearDown()'' that are invoked in between //each// individual ''test*'' method. Never rely on the lexical order of your unit test methods for the purposes of initialization, etc.! Unit test methods may be exacuted in an arbitrary order.+Like in JUnit and SUnit, it is possible to define two methods named ''setUp()'' and ''tearDown()'' that are invoked in between //each// individual ''test*'' method. Never rely on the lexical order of your unit test methods for the purposes of initialization, etc.! Unit test methods may be executed in an arbitrary order.
==== Assertions ==== ==== Assertions ====
Line 82: Line 84:
It is also possible to use ''makeFuture()'' to create a fresh future explicitly within the unit test method, and to use the returned resolver to resolve the future at the appropriate time. It is also possible to use ''makeFuture()'' to create a fresh future explicitly within the unit test method, and to use the returned resolver to resolve the future at the appropriate time.
 +
 +<note tip>
 +See the [[distribution#take_offline_remote_objects|distributed programming]] chapter for details about how to simulate network disconnections in distributed unit tests.
 +</note>
==== Test Suites ==== ==== Test Suites ====
Line 388: Line 394:
The files in the ''at/lang'' directory define custom language features which mostly use AmbientTalk/2's reflective facilities to extend the language. The files in the ''at/lang'' directory define custom language features which mostly use AmbientTalk/2's reflective facilities to extend the language.
-==== Futures and Multifutures ==== 
-=== Futures ===+ 
 + 
 +==== Futures ====
The module ''/.at.lang.futures'' provides support for futures. Futures have already been described as part of the [[:at:tutorial:actors#futures|concurrency]] section in the tutorial. The module ''/.at.lang.futures'' provides support for futures. Futures have already been described as part of the [[:at:tutorial:actors#futures|concurrency]] section in the tutorial.
Line 413: Line 420:
</code> </code>
-Finally, the futures module also provides some auxiliary functions, of which ''group:'' is often a very useful one. The ''group:'' construct groups a table of futures into a single future which is resolved with a table of values or ruined with an exception:+The ''makeFuture'' function can also take a timeout. If a timeout is given it returns a returns a pair [lease, resolver]  where the lease timer gets immediately activated. If the future is not resolved within the given timeout, the lease expires and ruins the future with a ''TimeoutException''. Note that this means a lease will get parameter-passed rather than the future if given to other actors. 
 + 
 +=== Auxilary functions in the futures module ==== 
 + 
 +The futures module also provides some auxiliary functions, of which ''group:'' is often a very useful one. The ''group:'' construct groups a table of futures into a single future which is resolved with a table of values or ruined with an exception:
<code> <code>
-when: (group: [ a<-m(), b<-n() ]) becomes: { |values|+when: (group: [ a<-m()@FutureMessage, b<-n()@FutureMessage ]) becomes: { |values|
  def [aResult, bResult] := values;   def [aResult, bResult] := values;
  ...   ...
Line 422: Line 433:
</code> </code>
-=== Multifutures ===+Another useful auxilary function is ''future:'' construct which returns a future which is resolved with the value passed to the 'reply' closure: 
 + 
 +<code> 
 +future: { |return| 
 +  // some computation 
 +  return(val) 
 +
 +</code> 
 + 
 +This is actually equivalent to the slightly more verbose code: 
 + 
 +<code> 
 +def [fut,res] := makeFuture(); 
 +try: { // some computation 
 +  res.resolve(val); 
 +} catch: Exception using: { |e| res.ruin(e) } 
 +fut; 
 +</code> 
 + 
 +==== Multifutures ====
The module ''/.at.lang.multifutures'' provides support for multifutures. A multifuture is a future that can be resolved multiple times. We distinguish between 'bounded multifutures', which can be resolved up to a maximum number and 'unbounded multifutures' which have no upper bound. The module ''/.at.lang.multifutures'' provides support for multifutures. A multifuture is a future that can be resolved multiple times. We distinguish between 'bounded multifutures', which can be resolved up to a maximum number and 'unbounded multifutures' which have no upper bound.
Line 462: Line 492:
When the message sent to a multireference is annotated with @Due(t), the timeout is applied to the implicit multifuture, causing whenAll observers to trigger automatically. Note that the implicit multifuture of a multireference is bounded, so whenAll observers trigger automatically when all replies have been received. When the message sent to a multireference is annotated with @Due(t), the timeout is applied to the implicit multifuture, causing whenAll observers to trigger automatically. Note that the implicit multifuture of a multireference is bounded, so whenAll observers trigger automatically when all replies have been received.
 +
 +
 +==== Leased Object References ====
 +
 +The module ''/.at.lang.leasedrefs'' provides support for leased object references. Leased object references have already been described as part of the [[:at:tutorial:distribution#dealing_with_permanent_failures|distributed programing]] section in the tutorial.
 +
 +<note>
 +The implementation of leased object references actually consists of two files: ''/.at.lang.leasedrefs'' and ''/at.lang.leasedrefstrait''. ''leasedrefstrait'' module implements the behaviour common to the different types of leased references. This module is imported in the ''leasedrefs'' module which provides the public API for creating and managing leased object references.
 +</note>
 +
 +The ''leasedrefs'' module exports language constructs to create three different types of leased object references:
 +  * ''lease:for:''returns a leased reference that remains valid for the indicated time interval.
 +  * ''renewOnCallLease:for:'' returns a leased reference that is automatically renewed (with the specified time interval) each time the remote object receives a message.
 +  * ''singleCallLease:for:'' returns a leased reference that remains valid for only a single method call on the remote object.
 +
 +Variations of these constructs are also provided to allow developers to specify the renewal time interval in renew-on-call leased references and the name(s) of the method(s) which trigger expiration of a single-call leased reference.
 +
 +The ''leasedrefs'' module also provides the following constructs to explicitly manage the lifetime of leased references:
 +
 +<code>
 +renew: leasedRef for: interval; // renews a lease
 +revoke: leasedRef; // revokes a lease
 +leaseTimeLeft: leasedRef; // return time left until lease expires
 +when: lease expired: {...}; // trigger a closure when the lease expires
 +</code>
 +
 +The ''when:expired:'' construct is provided to schedule clean-up actions with a leased reference upon its expiration.
 +
 +Finally, the ''leasedrefs'' module exports support primitives to manipulate time intervals (i.e. ''minutes'', ''seconds'', ''millisecs'') so that developers do not need to explicitly import the timer module to use leased references.
 +
 +
 +
 +==== TOTAM ====
 +
 +The module ''/.at.lang.totam'' provides an implementation for TOTAM, a tuple space model geared towards mobile ad hoc networks which combines a replication-based tuple space model with a dynamic scoping mechanism that limits the transportation of tuples.
 +
 +Please have a look to [[:uf:totam]] for further details on the model and its API.
==== Dynamic Variables ==== ==== Dynamic Variables ====
Line 574: Line 641:
The files in the ''at/support'' subdirectory of the standard library implement various utilities of use to the AmbientTalk programmer. We discuss the most useful modules below. The files in the ''at/support'' subdirectory of the standard library implement various utilities of use to the AmbientTalk programmer. We discuss the most useful modules below.
 +
==== Timing Utilities ==== ==== Timing Utilities ====
Line 597: Line 665:
The timer module also defines a function ''whenever:elapsed:'' which repetitively invokes the given block closure every time the timeout period has elapsed. The returned subscription object can be used to eventually stop the repetitive invocation of the closure. The timer module also defines a function ''whenever:elapsed:'' which repetitively invokes the given block closure every time the timeout period has elapsed. The returned subscription object can be used to eventually stop the repetitive invocation of the closure.
-The timer module defines a small number of additional utility functions which can be found in the file ''at/support/timer.at''.+Finally, there is a variant of ''when:elapsed:'' called ''when:elapsedWithFuture:'' which returns a future that will be resolved or ruined by executing the given closure after the given timeout. This variant is very useful in unit tests, e.g: 
 + 
 +<code> 
 +def testAsyncNearbyPlayerReply(){ 
 +  def nearbyPlayers := // search 2 nearby player orjbects; 
 +  // wait a bit so that there are the 2 members. 
 +  when: 2.seconds elapsedWithFuture:{ 
 + self.assertEquals(2, nearbyPlayers.getReceivedAnswers); 
 +  } 
 +}; 
 +</code> 
==== Logging Framework ==== ==== Logging Framework ====
Line 618: Line 697:
==== Object Inspector ==== ==== Object Inspector ====
-The module ''/.at.support.inspector'' implements a graphical object inspector. The module requires ''java.awt'' and ''javax.swing'' support from the underlying JVM running AmbientTalk. To inspect an object ''o'', execute:+The module ''/.demo.inspector'' implements a graphical object inspector. The module requires ''java.awt'' and ''javax.swing'' support from the underlying JVM running AmbientTalk. To inspect an object ''o'', execute:
<code> <code>
-import /.at.support.inspector;+import /.demo.inspector;
inspect(o); inspect(o);
</code> </code>
 
 
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki