bugKawa - Bugs: bug #27555, compile-file doesn't show errors


bug #27555: compile-file doesn't show errors

Submitted by:  Helmut Eller <ellerh>
Submitted on:  Mon 28 Sep 2009 06:12:31 PM UTC  
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  Per Bothner <bothner>
Open/Closed:  Open

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Tue 06 Oct 2009 03:54:01 PM UTC, comment #5:

> How/why do you use compile-file instead of the command-shell?

The compile-file/load functionality is important to me also,
so I wanted to weigh in here with another use case. I rely on
this for updating running applications which operate uninterrupted
for months at a time. The updates are non-interactive, and the
way the application is sandboxed, firing off a shell to run a
compilation is undesirable at best (at worst, impossible).

I appreciate the arguments for the batch compilation approach,
but doing this to the exclusion of compile-file/load would be
a serious loss.


tk <huh>
Thu 01 Oct 2009 05:22:42 PM UTC, comment #4:

I'm using Kawa from within Emacs which some glue
code for smoother interaction between Emacs and

I typically compile files (buffers) with a key
combination C-c C-k which compiles the file and
loads the jar file into the running JVM process.
It doesn't create a new JVM instance just to
compile a file.

Warnings/Errors are annotated in the source
buffer. To do that my glue code can't use
compile-file directly; it uses the lower level
functions instead but it's conceptually the same
as compile-file.

If the second argument of compile-file is a jar
filename it seems to generate a jar file. I'm
not sure though, might just be a zip file with a
different extension. But the -C command line
switch compiles to a ton of class files instead
of a single jar which is another reason why I
rather use
kawa -e '(compile-file \"x.scm\" \"x.jar\")'.

As far as interaction goes, I'd like to associate
an Emacs buffer/file with a (runtime) module. It
would be nice if there were a way to evaluate
expressions in the "toplevel environment" of such
modules. In that environment the toplevel macros
and toplevel functions of the module should be
callable even if not exported (in addition to
imported bindings). It would also be nice to be
able to reload/relink/hotswap those modules with
newer versions of the module.

So Emacs could have a command like C-x C-e which
evaluates the expression before point in the
environment associated with the current
file/module. Of course, it should also be
possible to compile modules without loading them
just to see compiler warnings.

Except for the relinking part, I think that such
a model isn't unreasonably inefficient. And
relinking will probably be easy with

In terms of a REPL, there could be something
analogous to the "cd" command but instead of
changing the directory it would switch the
current module. Something like Scheme48's ",in"

Helmut Eller <ellerh>
Thu 01 Oct 2009 04:04:34 PM UTC, comment #3:

Yes, for now it is better to use Kawa as batch compiler from the system shell. But it might make sense to have a new "compile" procedure that takes various (keyword?) parameters specifying what files to compile, where to put them, where to report errors and warnings, and which options to apply. I haven't felt much need for that myself, but I'm on Unix/Gnu/Linux, where I have reasonable shells and 'make'; some people might prefer scripting in Scheme. That's a topic I'm interested in exploring (see the old http://per.bothner.com/software/Q/Qshell.html), but the general topic will have to wait.

How/why do you use compile-file instead of the command-shell?

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Thu 01 Oct 2009 03:36:01 PM UTC, comment #2:

So what do you recommend instead of compile-file and load?
Using Kawa purely as batch compiler from the system shell?

Helmut Eller <ellerh>
Thu 01 Oct 2009 03:39:18 AM UTC, comment #1:

I believe compile-file does show errors - just not warnings.
However, it shows errors by throwing an exception, rather than by printing to a port. Printing the exception reports the errors.

I feel uncomfortable with having a "tool" like compile-file write to the current output (or error) port. That makes it harder to invoke the tool programmatically. Yes, it is possible to change the current output port, but it seems ugly.

I'm also concerned about duplicate error message. Your patch prints the errors and warnings, then if there is an error, we throw an exception, which gets reported - by printing the exception.

Finally, compile-file is not really recommended these days. It creates a zip file, which you then need to load. Load interacts badly with lexical scoping, compile-time analysis, and hence performance and error checking. I strong discourage use of load, and hence also of compile-file.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Mon 28 Sep 2009 06:12:31 PM UTC, original submission:

Attached is a patch to make
compile-file print error messages.

Helmut Eller <ellerh>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #18790:  compile-file.diff added by ellerh (998B - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by huh (Posted a comment)
  • -email is unavailable- added by bothner (Posted a comment)
  • -email is unavailable- added by ellerh (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-01 bothner Assigned toNone => bothner
    2009-09-28 ellerh Attached File- => Added compile-file.diff, #18790

    Back to the top

    Powered by Savane 3.3