DOMINIQUE THILLAUD wrote:
- PATH problems
1a) I'm unable to execute the a.out (nor the hello if using -o) directly but must use the stupid ./a.out (or ./hello). Even if I redefine the variable PATH in ~/.tcshrc (adding to it the current directory .). Where lies the file who defines PATH ?
See other's replies. However, I suggest not to do it. Even if you're on a single-user system now, you might be using a multi-user system sometimes, and it's good not to get used to having . in the PATH which would then be a real security hole.
1b) I construct some modules for toolboxes (like timer.p) or for abstract types (like lists.p) and I would like to put them in a genuine directory such that the compiler could find them from any other directory : how do it ?
--unit-path
- export problem
If I construct a module to implement an abstract type such that rational numbers, how export operators ? Writing : export rationals = (rational, +, -, *, /) ; give me a parse error before '+' (trying to enclose + between ' ' or " " is useless)
Gale Paeper wrote:
Internally, GPC creates mangled function names for user defined/overloaded operators. The mangling scheme is based, I think, on a textual spelling of the operator symbol (e.g., PLUS for +) and the operand parameter type identifier(s). If one absolutely needs more control over what's included in an exported interface than what export all provides, determining what an operator's mangled function name is and then using the mangled name in the export-list might work. (I haven't tried this.) I wouldn't try to make use of this, though, unless you deparately must have something more selective than export all since it ties your code to changeable internal compiler details, is error prone, and has a lot of negative code maintenance implications.
It won't work anyway (intentionally, since these internal identifiers are designed not to conflict with the internal representation of regular identifiers).
So `export = all' (or, using a unit which is the same in this regard) is the only way.
Frank