Design #989
init file obligatory?
Description
Currently the CoCoAInterpreter
requires that there be a file init.cocoa5
in the same directory as the packages.
If the file not found, the interpreter prints an error message (before the banner) and proceeds.
Is this the right behaviour?
Related issues
History
#1 Updated by John Abbott over 7 years ago
- Related to Feature #485: Initialization for CoCoA-5: file init.cocoa5 added
#2 Updated by John Abbott over 7 years ago
I found this while trying to create a "quick start" CoCoA-5 by giving it an empty directory as the place to look for packages.
CoCoAInterpreter
produced the following error message:
EmptyDir/init.cocoa5: No such file or directory
At least a "nicer" warning message should be printed. Perhaps something like this:
WARNING: missing or unreadable initialization file init.cocoa5
Not sure if the file name should be just the basename (i.e. without any directories),
the name as it appears currently (e.g.
EmptyDir/init.cocoa5
above), or the full path.Perhaps the current approach is a good compromise between readability for non-specialists
and helpfulness to hapless debuggers.
#3 Updated by John Abbott over 7 years ago
In my tree init.cocoa5
contains 9 lines, but only 2 (or perhaps 3) actually do anything useful.
I suggest keeping just the first 3 lines, and deleting the rest. Objections?
#4 Updated by John Abbott over 7 years ago
The critical section of source code appears to be around line 126 of Main.C
.
(call to perror
)
#5 Updated by Anna Maria Bigatti over 7 years ago
John Abbott wrote:
In my tree
init.cocoa5
contains 9 lines, but only 2 (or perhaps 3) actually do anything useful.I suggest keeping just the first 3 lines, and deleting the rest. Objections?
done. cvs-ed
#6 Updated by Anna Maria Bigatti over 7 years ago
- % Done changed from 0 to 10
When I added init.cocoa5
I did not consider the possibility of calling cocoa passing explicitely an empty directory instead of packages
.
Now we know it makes sense (very fast start of cocoa for calling builtin functions only).
So it should not give an error.
Should we instead (or as well) have a flag -NO_PACKAGES
?
#7 Updated by John Abbott over 7 years ago
- Status changed from New to In Progress
If it can be done quickly, I see no objection to having a --no-packages
option.
I am not entirely happy about the name of the option --packageDir
, probably it should be --package-dir
?