Recent experiences have shown that the behaviour of the LVM runtime system is not as it should be
when it comes to file I/O. We are currently aware of two mistakes.
If you know of any other bugs, either in the compilation process, the functionality of the system,
or in the documentation, we seriously want to know, and would be extremely happy if you
could contact us
We try to fix the bugs we discover, but we do not have the necessary expertise in our team to deal with
all of them, especially those that deal with the behaviour of the lvm runtime.
Bug 1: segmentation fault when attempting to write "large" files.
The LVM runtime system will terminate with a segmentation fault when you try to write files of more than
An example is
. This program should print itself,
but terminates. The source of the bug might be in the garbage collector of
which was borrowed
from the OCaml runtime system when it was built.
Known work-around: pass the parameter
. However, this might reveal
another bug, namely Bug 2 (see below).
Bug 2: no writing occurs when attempting to write "small" files.
When the initial heap of
is set 8m or higher, then
it is possible that when writing small files, nothing is ever output.
The work-around in this case is to set the heap with
, but then you might run into
Bug 1 (see above). We conjecture that this problem is caused by the omission of a flush at some point.
Bug 3: type inferencer loops or leaks
There are situations in which the type inferencer seems to loop when it uses the type graph solver.
Some experimentation has shown that it simply takes a lot of memory to solve the problem.
The program is small, but not simple. This is a problem we hope to fix in the near future.
Bug 4: type synonyms in warnings unfolded
We do our best not to unfold type synonyms in error messages, and we don't unless we have to.
However, this is, unexpectedly, not the case for warnings that involve type synonyms.
This is why the test for
fails. Although not essential,
we would like to remedy this inconsistency.
Bug 5: errors in dictionary passing/construction
The code generation for a program like the following was shown to be buggy by Erik Mulder
test :: Ord a => a -> a -> String
test x y
| x < y = "smaller"
| x == y = "equal"
| x > y = "larger"
| otherwise = "buggy"
test  
will actually return
Bug 6: UTF-8 encoding problems
Some versions of Helium have a problem reading UTF-8 encoded source files.
A typical error message you might get is
(1,1): Unexpected character 'ï'
Compilation failed with 1 error
This problem should go away by telling your editor to change the encoding to ANSI.
Thank you Marvin Hernandez
for pointing this out to us.
Bug 7: can not fixup code references beyond a 4gb memory span.
If, after invoking lvmrun or using an interpreter such as Hint or texthint, you get the message
can not fixup code references beyond a 4gb memory span.
then during compilation there is likely to have been an unobserved problem with gcc.
The problem is due to a mismatch between 32 bits and 64 bits lvmrun and helium
As far as we know this problem only shows up under MacOSX?
, and the problem has
been fixed for that platform. Please retrieve from the website a version of Helium
dated later than Sep 30, 2010, or checkout the current head.
If you have the same problem on another platform, please let us know, and we can fix that too.
- 29 Jan 2008