Bernd Raichle wrote:
> : (defmacro simple-condition-format-string (&rest)
> : `(simple-condition-format-control ,@rest))
> :
> : is my current solution. It seems that CLISP doesn't understand this.
> : Maybe I should ask on the mailing-list, why not.
>
> CLISP doesn't have implemented the last X3J13 changes?
Not all of them as you can see. I think it would be a good idea to
make Allegro the Lisp version of my choice from now on :)
> : > - "idxstyle.lsp"
> : > (open ... :direction :input-immutable ...)
> : > is non-standard, only :input, :output, :io, and :probe are allowed.
> : > Fix: changed :input-immutable to :input.
> : Ok. This is new to me. Wonder why I didn't find it?
>
> Can you explain what the differences beetwen ``:input'' and
> ``:input-immutable'' are?
I borrowed this from the implementation of function `load' int the
CLISP-source :) I never asked if it is standard.
> [...]
> : > Additionally I have rewritten the shell script "xindy" to call Allegro
> : > CL instead of CLISP. "xindy -v" works, and the first test with
> : > "attr1.xdy/.raw" gives the following result:
> [...]
> : > Mmmh, if I trace
> : >
> : > USER(3): (trace idxstyle::find-file idxstyle::append-pathnames probe-file)
> : > (PROBE-FILE IDXSTYLE::APPEND-PATHNAMES IDXSTYLE::FIND-FILE)
> : > USER(4): (searchpath ".:/home/raichle/xindy/lib/modules")
> : > (#p"/" #p"/home/raichle/xindy/lib/modules/")
> : ^^^
> : This should be #"./". At least this is not as expected.
>
> I have found this "bug" ... it was the new (searchpath ...) call in
> file "testbed.xdy". To make the test I have copied this file without
> changing it appropriately :-(
Ok. That helps a lot.
> I have got Xindy 1.2.1 and now these are the "bugs" and necessary
> changes I have found so far:
>
>
> - ".../binaries/.../defaults.xdy", "idxstyle.lsp", "markup.lsp"
>
> *load-paths* is not external
> (and not imported to the USER package).
>
> Fix: in "idxstyle.lsp"
> (export 'idxstyle:*load-paths*)
> and either change ".../binaries/.../Makefile" to access
> idxstyle:*load-paths* instead of *load-paths* or import this symbols
> to the USER package.
>
> (I have missed to report this bug last time.)
Ok.
> - "markup.lsp"
>
> When opening the `logfile' in function `do-startup' add the
> keyword/value
> :if-exists :overwrite
> to the `open' function call. The default for :if-exists is :error,
> i.e. signal an error if file to be written exists.
>
> Same change needed when opening the `output' file in this function.
CLISP did never report an error :)
> With these changes, I was able to startup Allegro CL, load all
> necessary files (without warnings), and start a first test (after
> adding ":last" to the search path in my copy of "testbed.xdy") with
>
> (xindy:startup :idxstyle "attr1.xdy"
> :rawindex "attr1.raw"
> :output "attr1.ind"
> :logfile "attr1.xlg" :trace-level 1)
>
> which returns with the following error:
>
>
> [...]
> Loading module "testbed.xdy"...
> Finished loading module "testbed.xdy".
> Loading module "class/pagenums.xdy"...
>
> Error in line 6:
> ;; $Id: msg00027.html,v 1.1 2004/01/08 19:29:17 jschrod Exp $
> ;;
> ;; This module defines the location-class "page-numbers"
>
> (define-location-class "page-numbers" ("arabic-numbers"))
>
>
> Error in line 11:
>
> ;;;;;;;;;;;;
> ;;
> ;; The rest
>
> (require "class/pagenums.xdy")
>
> Error: No methods applicable for generic function
> #<STANDARD-GENERIC-FUNCTION SIMPLE-CONDITION-FORMAT-CONTROL> with args
> (#<PROGRAM-ERROR @ #x90335a>) of classes (PROGRAM-ERROR)
> [condition type: PROGRAM-ERROR]
>
>
> There seems to be a bug w.r.t. Allegro CL in
> (define-location-class ...)
> which I'm unable to find :-((((
>
> For more, see below.
>
>
> %%%%%%%%%%%%%%%%%%%% Compiling the source files:
>
> I get warnings for all top level forms (use-package, export, ...):
> ; While compiling (:TOP-LEVEL-FORM "base.lsp" 124):
> Warning: compile-file found "USE-PACKAGE" at the top-level -- see the
> documentation for comp:*cltl1-compile-file-toplevel-compatibility-p*
When I played aroung with Allegro I did a
(setq comp:*cltl1-compile-file-toplevel-compatibility-p* t)
to overcome these messages.
> base.lsp:
> =========
>
> USER(12): (compile-file "xindy:src;base.lsp")
> ;;; Compiling file xindy:src;base.lsp
> [...]
> ; Compiling SPLIT-LIST
> Error: Attempt to take the cdr of "split-list" which is not listp.
> [condition type: SIMPLE-ERROR]
>
> [...]
> [changing package from "COMMON-LISP-USER" to "BASE"]
> [1] BASE(13): :zo
> Evaluation stack:
>
> (ERROR SIMPLE-ERROR :FORMAT-CONTROL ...)
> ->(ASSERT (ASSERT # "split-list") (:COMPILATION-ENVIRONMENT NIL))
> (COMP::TRANS (ASSERT # "split-list"))
> (COMP::PA-COMPILE (ASSERT # "split-list") NIL)
> (COMP::PA-PROGN (# #))
> (COMP::PA-BLOCK (# #))
> (COMP::PA-COMPILE (BLOCK SPLIT-LIST # ...) COMP::TAIL)
> (COMP::PA-COMPILE (PROGN #) COMP::TAIL)
> (COMP::PA-COMPILE-LAMBDA (LAMBDA # #) SPLIT-LIST)
>
> ... more older frames ...
> [1] BASE(14): :cur
> (ASSERT (ASSERT (NOT (AND SORTFUNC HEADFUNC)) "split-list")
> (:COMPILATION-ENVIRONMENT NIL))
>
>
> Seems to be a bug, CLtL2 has (assert <test-fun> [ ( <place>* )
> <string> <arg>* ]), i.e. if more than one argument is given, the
> second is a list of places and the third is a string.
>
> Fix: added a second argument () before the former second argument
> "split-list".
I see. CLISP didn't complain.
> Compiling again:
>
> [...]
> ; Note: Closure (:INTERNAL SPLIT-LIST 1) will be stack allocated.
> ; Note: Closure (:INTERNAL SPLIT-LIST 0) will be stack allocated.
> [...]
Are these messages something important or can they be ignored?
> Ok, here is a bug:
>
> ;;; Fasl write complete
> Warning: While compiling these undefined functions were referenced:
> SYSTEM::PRINT-CONDITION.
>
> Ahhh, you are using atleast this system-dependent function which isn't
> available in Allegro Common-Lisp! (If `system::print-condition' is
> used to get the printed representation of a condition, why not using a
> `print-object' method for instances of the class `condition'?)
Hm. Good question.
What about the (system::getenv "XINDY_SEARCHPATH") call in
set-searchpath-by-environment? Does it work on Allegro?
> %%%%%%%%%%%%%%%%%%%%
>
> After compiling all files and fixed these two remaining bugs, I tried
> the test again:
>
> [...]
> USER(3): (xindy:startup :idxstyle "attr1.xdy"
> :rawindex "attr1.raw"
> :output "attr1.ind"
> :logfile "attr1.xlg" :trace-level 1)
>
> This is `xindy' version 1.2 (Running on "Allegro CL").
>
> Opening logfile "attr1.xlg" (done)
> Reading indexstyle...
> Loading module "attr1.xdy"...
> Loading module "testbed.xdy"...
> Finished loading module "testbed.xdy".
> Loading module "class/pagenums.xdy"...
> Finished loading module "class/pagenums.xdy".
>
> Error in line 29:
>
> (markup-range :class "follows" :open "\folone{" :close "}f."
> :length 1 :ignore-end)
>
> ERROR:
> Syntax Error in
> (MARKUP-RANGE :CLASS "follows" :OPEN "\\folone{" :CLOSE "}f." :LENGTH 1
> :IGNORE-END).; killing "Editor Server"
> ; Exiting Lisp
>
>
> Any hints? Any hints how to trace/debug Xindy to find this bug?
Hm. Best would be to directly trace the (markup-trace)-macro.
This error message is generated by the
(desctructuring-swith-bind)-macro in idxstyle.lsp (intface.nw). It
preprocesses a macro-call and removes any switches (&switch) form the
lambda-list. The remaining-list is simply passed to a
(destructuring-bind) that for some reason has failed.
Try the following:
(LET
((<DESTRUCTURING-SWITCH-FORM>
'(:CLASS "follows" :OPEN "folone{" :CLOSE "}f." :LENGTH 1
:IGNORE-END
)) )
(LET ((IGNORE-END (FIND :IGNORE-END <DESTRUCTURING-SWITCH-FORM>)))
(DESTRUCTURING-BIND (&KEY OPEN CLOSE SEP CLASS LENGTH)
(SET-DIFFERENCE <DESTRUCTURING-SWITCH-FORM> '(:IGNORE-END))
(LIST OPEN CLOSE SEP CLASS LENGTH
IGNORE-END))))
if it returns
-> ("folone{" "}f." NIL "follows" 1 :IGNORE-END)
Then you can try interactively
(macroexpand
'(intface:destructuring-switch-bind (&key
open close sep class length
&switch ignore-end)
'(:class "follows" :open "\folone{" :close "}f."
:length 1 :ignore-end)
(list open close sep class length ignore-end)))
if it returns the above expansion.
If so, the macro-expansion mechanism seems to work. If not, contact
me. The best will be that I install Allegro for Linux here in the
university to find this error. But I'll not be able to do this before
wednesday ;-(
Thanx for your help.
--
======================================================================
Roger Kehr kehr@iti.informatik.th-darmstadt.de
Computer Science Department Technical University of Darmstadt