Lard Version 2.0.13 Release Notes

LARD is now being maintained by the team of:

• Peter Riocreux - Thread state display, new configuration mechanism, command line arguments to the lard code
• W. John Bainbridge - Channel display and debugging improvements
• Andrew Bardsley - Arbitrary precision integer support, new value display format format

Upgrading from version 2.0.12

No change in environment variables is required from version 2.0.12. If you are upgrading from older versions of LARD (or using LARD for the first time) do this:

• Change your .profile. All you need to change this time is the version number in LARDHOME. You should end up with something like this:

  	LARDHOME=/home/amulinks/lard/2.0.13
  	BINFMT=`${LARDHOME}/bin/common/lard_bin_fmt`
  	export LCD_OPTS="-lio -lchannels -ltime"
  	export PATH=${LARDHOME}/bin/${BINFMT}:${LARDHOME}/bin/common:${PATH}
  

• Existing programs only need to be recompiled if they are older than version 2.0.12

Changes since version 2.0.12

• Removed ill thought out change to forseq_in_do_

  forseq_in_do_ now works the same way it did in all versions from 1 to 11. Also added forseq_in_step_do to allow reverse and variable increment counting.

• Added fsetunbuffered

  Added the function fsetunbuffered (which does a setbuf (..., 0) on a binary file descriptor) and changed bopenout to allow connection of binary streams to pipes.

• Added lardpos and warning functions

  lardpos returns a string representing the position in the LARD code (with debugging on) when it was called. warning can be used to issue non fatal runtime warnings (which may in later versions be logged and presented in interesting ways).

• Added non-blocking input

  The file type nbfile and the functions nbopenin and nbfread allow input from files (pipes really) which doesn't block the LARD scheduler.

• Reduced number of windows

  `Notebook' widgets are used to reduce the clutter of separate windows. The time view and channel selector are now in one window, as are the source view and threads windows. LARD now requires the BWidgets widget set in order to be built.

• Added variable perpetual

  Setting the variable perpetual (e.g. perpetual := true) prevents the scheduler from reporting Program Terminated when no channel/thread activity is scheduled. This is useful for preventing a program using non-blocking I/O from terminating while the input loop is the only thread runnable.

• Allow `C style' radix prefices in format

  The parsedata string parser now allows C style number prefices to be used (0x for hex, 0b for binary). The leading-zero octal prefix is only recognised when the input radix is set to 0 or the %i format is used.

Changes since version 11

• GNU automake/autoconf configuration

  LARD should be more portable and easier to install. Unfortunately LARD still only works correctly on machines with 32 bit architectures. (sizeof (int) == 4 && sizeof (void *) == 4)

• Improved tviewps module

  I have improved the functionality of the tviewps (plot) module. You can now specify a scale factor, and if you have more traces than will fit on the page the plot will be broken into multiple slices.

• Command line arguments to the lard code

  You can now pass arguments to the lard code itself from the li command line. Simply append the arguments to the command line, separated from arguments to the li binary by the argument --end.

• Assorted bug fixes

Known Bugs

• There can be class checking problems when using an expression in the class of a declaration, for example v:var(int^(a+1)). The problem hasn't been thoroughly investigated, but is seems that it can be made to go away using an explicit eval, for example v:var(int^(eval(a+1))).

• If a recursive function's return type depends on its parameters (explicit or implicit), things will go wrong. For example, compiling the following program fails to terminate:

  (foo(T:type):expr(T)=foo(T)).null

• Multi-dimensional array declarations work "backwards", for example if I declare V:var(int^100^200) then the highest numbered element of V is V[199][99], not V[99][199] as you would have expected.

• If a channel's receiver has no delay in its ?() expression then other processes that are watching the channel using wait_until(chan_ready()) may "miss" any activity on the channel. This needs a mechanism like VHDL's delta timing model in order to get the correct behaviour.

• Bad things sometimes happen when a parameterised type declaration contains a record declaration with a field type using the parameter. This can sometimes generate bad code; under some conditions it will pick up the wrong actual value of the parameter and give a run-time error.