Re: Byte compilation error.

[Jeremy Hankins <nowan nowan org>]

Teika Kazura <teika lavabit com> writes:
> Hi, I've stopped the previous thread to make it clear that the
> Harald's patch is the official fix.

Ok.  Would you like me to go ahead and apply this version to git, then?
I'm sorry, I didn't mean to step on toes.

> Now, let me review the problem, one by one.
>
> 1. Sawfish-1.6.3 byte compilation fails since commit 2277ff on Mar 13,
> at the compilation of wm/util/prompt.jl. If it is compiled after other
> prompt*jl, then it succeeds. But that commit itself is faultless, it
> only revealed a new problem as we see below.
>
> The compilation order is not related to multi-threads. Lisp function
> 'compile-lib-batch' uses 'directory-files' which returns *unsorted*
> list of files. This is the cause of the randomness.  Thus, a fix is
> needed, and any which works is ok. I've chosen the first one.
>
> I don't know why in my case it was alphabetical order. I've compiled 7
> times since Mar 13, so it must be always so in my environment.

I wonder if it's the raw order of the directory.  Try an unsorted
directory listing (ls -1f) and see what you get.  If the first time you
put files in the directory you did so via a program that sorted the
listing the raw listing may be sorted (or mostly sorted, as old files
are deleted and new ones added).

> 3. Byte compilation. (This is for Lisp fans.)
> Jeremy understands lisp far better than me, but he's confused
> with byte compilation. Let me tell you what I've learned.

I wouldn't say I know lisp better than you.  My lisp knowledge is only
"adequate," and very much a work in progress.  And you definitely know
sawfish better than I do.

> 'requiring itself' does nothing. It's already opened.  But it's byte
> compiler (Herafter 'bc')! A bc is *NOT* a lisp interpreter. A silly
> but easy example of bc is something like a preprocessor, deleting
> comments, redundant whitespaces, etc. It has almost nothing to do with
> lisp. Of coures, librep bc is far more complex, but it does not evaluate
> the file.

My concern was that it must in some way be processing (though not
running, of course) the variable definitions and function definitions,
and possibly other things as well.  This information is used to help
catch errors -- hence the need for the eval-when-compile: it's catching
errors that aren't really there.  I was trying to decide if requiring
the file might, e.g., hide legitimate errors that are introduced in the
future.  But here I realized that my understanding of the byte
compilation process isn't up to answering that question.

> The bc opens other modules to check exported functions, defvars, and
> so on. So, (require 'prompt) is the first open, not the second whih
> opens itself. It's natural to assume defvar's in prompt.jl should be
> evaluated at compilation of prompt.jl, but it's not. This is the whole
> story.
>
> 4. So, what to do?
> We can sweep this issue under the carpet, but if it's to be fixed,
> Jeremy's patch is the only meaningful way. But he says it's not yet
> complete, so let me conclude that's all for today. ;) We've got other
> issues now.

The unfinished part has nothing to do with prompt.jl; I can apply that
anytime we decide it's time.  In fact, the sawfish that I run myself has
this patch applied and has for months.  The problem is that it breaks
backward-compatibility since it changes the way the prompt code is
called.

-- 
Jeremy Hankins <nowan nowan org>