Hi all:
Using
(defparameter *this-file*
(load-time-value
(or #.*compile-file-pathname* *load-pathname*)))
I am defining *this-file* to hold the source file name of the file at
hand. Now, when formatting an error message, I am trying to keep the
filename fix during run-time.
I came up with this macro:
(defmacro logmsg (msg-class file module function/method msg-nr msg
&rest msg-args)
`(call-logmsg ,msg-class
,file
,module
,function/method
,msg-nr
,msg
,@msg-args))
(defun call-logmsg (msg-class file module function/method msg-nr msg
&rest msg-args)
(let ((*print-circle* nil))
(format *debug-io* "~&~%;;; ~a --------------------------------------------------"
(format-iso8601-time (get-universal-time) t))
(format *debug-io* "~&;;; Process PID ....: ~d" (getpid))
(format *debug-io* "~&;;; Module .........: ~A" module)
(format *debug-io* "~&;;; File ...........: ~A" (basename (namestring file)))
(format *debug-io* "~&;;; Function/Method : ~A" function/method)
(format *debug-io* "~&;;;")
(format *debug-io* "~&;;; ~A -> Msg ID ~4,'0D :~&"
msg-class msg-nr)
(format *debug-io* ";;; ")
(apply 'format *debug-io* msg msg-args)
(format *debug-io* "~%")
(force-output *debug-io*))
(values))
I actually see that, when I later on use logmsg like this
(logmsg :DEBUG *this-file* *this-module* 'paint-view-border 0
"Painting border for ~S with width ~S." self width)
and like this
(logmsg :DEBUG *this-file* *this-module* 'observer/layers/cello-view 0
"Layers for ~S changed, therefore posting redisplay request." self)
I always get the same last filename assigned to *this-file* _for_ _both_
_messages_ ...
I'd need to capture the value of *this-file* at compile-time with it not
being overwritten later on ...
Using variable capture on purpose in the macro? Would that be a good
solution?
Thanks for sharing your thoughts!
Frank
From: Kaz Kylheku
Subject: Re: name of source file at load-time and compile-time
Date:
Message-ID: <20090620083622.224@gmail.com>
On 2009-06-08, Frank GOENNINGER <······@googlemail.com> wrote:
> Hi all:
>
> Using
>
> (defparameter *this-file*
> (load-time-value
> (or #.*compile-file-pathname* *load-pathname*)))
LOAD-TIME-VALUE in DEFPARAMETER is pointless. The expression which initializes
a defparameter is a load-time value already, by definition. When the file
is loaded (source or compiled form), that expression is evaluated and the
dynamic variable takes on that value.
Also, did you read this, in the description of LOAD-TIME-VALUE:
``It is guaranteed that the evaluation of form will take place
only once when the file is loaded, but the order of evaluation
with respect to the evaluation of top level forms in the file
is implementation-dependent. ''
Oops! So not only is it pointless to use in toplevel forms, it may
actually be unreliable.
> I am defining *this-file* to hold the source file name of the file at
> hand.
Right, except if the file is loaded as source, rather than compiled, where it
makes sense to fall back on the load name.
> I actually see that, when I later on use logmsg like this
>
> (logmsg :DEBUG *this-file* *this-module* 'paint-view-border 0
> "Painting border for ~S with width ~S." self width)
>
> and like this
>
> (logmsg :DEBUG *this-file* *this-module* 'observer/layers/cello-view 0
> "Layers for ~S changed, therefore posting redisplay request." self)
>
> I always get the same last filename assigned to *this-file* _for_ _both_
> _messages_ ...
What should cause the name to differ in these two messages?
* Kaz Kylheku <··················@gmail.com> :
Wrote on Mon, 8 Jun 2009 17:53:34 +0000 (UTC):
| * Frank GOENNINGER <··············@ccde007.de.goenninger.net> :
| Wrote on Mon, 08 Jun 2009 18:45:44 +0200:
|
|> (defparameter *this-file*
|> (load-time-value
|> (or #.*compile-file-pathname* *load-pathname*)))
|
| LOAD-TIME-VALUE in DEFPARAMETER is pointless. The expression which
| initializes a defparameter is a load-time value already, by
| definition. When the file is loaded (source or compiled form), that
| expression is evaluated and the dynamic variable takes on that value.
[snip]
|> I am defining *this-file* to hold the source file name of the file at
|> hand.
|
| Right, except if the file is loaded as source, rather than compiled,
| where it makes sense to fall back on the load name.
Except that the fasl may be in a different location from the source. In
this case, if this trick is used at run time to locate support files
which are present in the same directory as the source file *THIS-FILE*,
this approach will fail. IIRC I've seen kt's CellTk and Edi Weitz's
code use this trick and fail, and remember I had to change the order to
(or *load-pathname* *compile-file-pathname*)
so the correct value gets into the fasl and things work as the author
intended.
[snip]
|> I always get the same last filename assigned to *this-file* _for_ _both_
|> _messages_ ...
|
| What should cause the name to differ in these two messages?
I am unable to follow the logic to expect different results, but to
answer the OP's question
|> I'd need to capture the value of *this-file* at compile-time with it
|> not being overwritten later on ...
See the thread `passing values from compile-time to load-time' from Feb
2008where I answered Steingold in
<·······················@robolove.meer.net>
<URL:News:m3d4qw515z.fsf @ robolove.meer.net>
http://al.howardknight.net/msgid.cgi?STYPE=msgid&MSGI=<··············@robolove.meer.net>
|> Using variable capture on purpose in the macro? Would that be a good
|> solution?
I'd suggest you not even think about doing this. Just define a logical
pathname host, put translations in a separate-file and use logical
pathnames such as "FRGO:thisfile" when referring to any files in the
code.
--
Madhu
[IMPORANT NOTICE: I expressly prohibit google.com from truncating the
URL and MSG-ID mentioned above in this message, when google.com
processes this message in any form; including the case where this
message is quoted in replies. Truncating the quoted URL and Message-ID,
constitutes wilful removal of important information intented and
essential to be passed on to the readers of this message, and truncation
renders the message useless and destroying any value of this post]