1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
_B_u_g_ _R_e_p_o_r_t_s
Bug reports should be sent to mira-bugs at the domain
miranda.org.uk
First check below, however, in case it is already known. Also check the
downloads section at miranda.org.uk in case there is a new version of
Miranda in which your bug may be fixed. When sending a bug report,
please state the version number of your Miranda system and the platform
that it is running on.
The error messages from the Miranda system are mostly self explanatory.
Note, however, that messages of the form "impossible event ..." or
similar indicate that the internal state of the system has become
corrupted. This should be reported as a bug. Segmentation faults also
falls into this category.
First check if the problem only occurs following a garbage collection.
Garbage collector reports can be turned on by `mira -gc' from the
command line or by /gc within a miranda session. If your error does
appear to be associated with garbage collection you can try running with
a bigger heap and/or getting mira recompiled at a lower level of
optimisation (eg -O instead of -O2, or without -O). Miranda uses a
"conservative collector" which scans the C stack to follow things that
are, or appear to be, pointers into the heap. Unfortunately this is
vulnerable to compiler optimisations affecting the state of the stack.
Even if the problem does appear to be gc-related it is still worth
reporting.
The source code, orginally written for 32 bit platforms, has been
extensively revised and tested for 64 bit compatibility. It is quite
possible that some hidden "integer width" problems remain in the code
and will be discovered in use.
_L_i_s_t_ _o_f_ _k_n_o_w_n_ _b_u_g_s_,_ _d_e_f_i_c_i_e_n_c_i_e_s_,_ _a_n_d_ _u_n_i_m_p_l_e_m_e_n_t_e_d_ _f_e_a_t_u_r_e_s
If there is not enough heap to compile the current script, mira exits
after reporting this fact. The fix is to increase the heap size:
mira -heap N [filename]
where N is a bigger number than you had before.
It is not currently permitted to give a type specification for an
identifier defined locally, as part of a _w_h_e_r_e clause. That is (see
formal syntax) `spec' is not allowed after _w_h_e_r_e.
When abstract objects are tested for equality or order (under <, <= etc)
the result is that obtained by applying the operation to the underlying
representation type. In some cases this will be what you want, but in
others it will be wrong - there ought to be a way of controlling this.
The standard input cannot be accessed both as a list of characters (with
$-) and as a list of values (with $+) at the same time. If $+ is in
use, an occurrence of $- will evaluate to [], and vice versa. This is
not referentially transparent - uses of $+ and $- ought to share data.
Scripts with multiple occurrences of $+ also behave opaquely - each
occurrence of $+ reads from the terminal independently, and they do not
share data with each other. (Multiple occurrences of $+ in a single
command-level expression behave transparently, however.)
There is a subtle issue concerning `show' and %export. If you define a
function which, internally, uses `show' on an object of algebraic type,
and then %export that function to another scope, the format used by the
`show' depends on the status of the algebraic type in the NEW scope.
Thus if the type has been aliased the new constructor names will be
used, and if the algebraic type is no longer in scope, it will show as
"<unprintable>" (this latter case can arise if an abstract type based on
the algebraic type is exported, and one of the signature identifiers
invokes `show' on the base type). Although this behaviour is
defensible, it might be better for each use of `show' at algebraic type
to be frozen to use the constructor names in the scope where it occurs.
[An analogous issue arises with `readvals'.]
Implementation restrictions not mentioned elsewhere in the manual:-
A shell command called from mira using `!' is limited to 1024 characters
in length after any implied expansions (eg of `%') have been performed.
The same restriction applies to the result of expanding out a `/e'
command. The pathnames of Miranda scripts are limited to 1024
characters in length, including the `.m' extension. The name of the
editor supplied for the `/e' command, and the absolute pathnames of the
miralib directory, and of the user's home directory, are also each
limited to 1024 characters in length.
The name of a Miranda script may not contain spaces (but directory names
with spaces are allowed in pathnames).
|
