Lard Version 7 Release Notes

Upgrading from version 6

• If your environment variables were set up as described in the v6 release notes all you need to change is LARDHOME:

  	LARDHOME=/home/amulinks/lard/v7
  

• Recompile all existing programs.

Changes since version 6

• Improved compilation/installation

  I have improved the Makefile arangement and other installation procedures to make things easier for those who have to do this for themseleves. Please see README in the source distribution for installation instructions. If you need to do anything other than what's described in that file please let me know so that I can fix it.

• tk file dialogs

  li now uses standard tk file dialogs.

• li reads from user X resource files.

  If you set XAPPLRESDIR to $HOME/app-defaults and create a file Li in that directory, you can use it to specify colours, fonts and other properties for the application. For example, this will give all the windows a hideous orange background:

  	*Background:	orange
  

  li parses XAPPLRESDIR, XUSERFILESEARCHPATH and XFILESEARCHPATH, but it doesn't do % expansion on those variables yet.

• Emacs mode for LARD code

  There is a very primitive Emacs mode for editting LARD code in the misc directory. I appologise for the lack of functionality - if anyone would like to improve on it please go ahead.

• makedepends utility.

  Andrew Bardsley has contributed a Makefile creation utility which can be found in the misc directory.

• -notk flag.

  Passing the command-line argument -notk to li disables li's tk front-end. Use this flag if you want to run li in batch mode when no X display is available, for example in a nohup script.

• bci_responsiveness variable.

  The number of bcode instructions that are interpretted between screen updates can now be adjusted by setting the variable bci_responsiveness. A good place to do this is your $HOME/.lirc file. This could be useful if you are running li remotely with a slow X connection, for example. The default value is 1000.

• Various 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.