Is there a (no matter if non-portable) way of getting the name of the
currently executing function at execution time?
I'd want to further enhance my debugging/logging tools ...
Thx!!!
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Steven M. Haflich
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <46DCD6D5.7070205@alum.mit.edu>
Frank Goenninger DG1SBG wrote:
> Is there a (no matter if non-portable) way of getting the name of the
> currently executing function at execution time?
>
> I'd want to further enhance my debugging/logging tools ...
There is no standard way defined by the ANS. In ANSI CL names map onto
functions but the mapping is one way. There is no portable way to map
a function back to a name. Of course, there is no portable way even
to get the currently-executing function, although nearly every
implementation has a debugger that supports this (assuming you are
really asking how to do all this in the context of a debugger).
In ACL the debugger can do it with the :function command.
user(19): (funcall #'+ 41 'one)
Error: `one' is not of the expected type `number'
[condition type: type-error]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] user(20): :function
#<Function +>
[1] user(21): :current
(+ 41 one)
In ACL there is an unexported accessor that will return the name of a
function object. (mop:generic-function-name will fo this for generic
functions, of course.)
[1] user(22): (excl::func_name *)
+
From: Ken Tilton
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <46DD5138.8080802@optonline.net>
Steven M. Haflich wrote:
> Frank Goenninger DG1SBG wrote:
>
>> Is there a (no matter if non-portable) way of getting the name of the
>> currently executing function at execution time?
>>
>> I'd want to further enhance my debugging/logging tools ...
>
>
> There is no standard way defined by the ANS. In ANSI CL names map onto
> functions but the mapping is one way. There is no portable way to map
> a function back to a name. Of course, there is no portable way even
> to get the currently-executing function, although nearly every
> implementation has a debugger that supports this (assuming you are
> really asking how to do all this in the context of a debugger).
The OP has already indicated portable is not necessary, and no, he does
not want to do this from within the debugger, he is trying to embed more
powerful debugging code in his source. I think he is looking for the
implementation of :function so he can call it himself from app source.
If that is not possible...
I would macroexpand defun, carefully add `(let ((*func-name*
',funcname)) to the expansion, then either call it defun* and use it
where you care or call it defun and shadow cl:defun.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
From: Duane Rettig
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <o0fy1upglj.fsf@gemini.franz.com>
Ken Tilton <···········@optonline.net> writes:
> Steven M. Haflich wrote:
>> Frank Goenninger DG1SBG wrote:
>>
>>> Is there a (no matter if non-portable) way of getting the name of the
>>> currently executing function at execution time?
>>>
>>> I'd want to further enhance my debugging/logging tools ...
>> There is no standard way defined by the ANS. In ANSI CL names map
>> onto
>> functions but the mapping is one way. There is no portable way to map
>> a function back to a name. Of course, there is no portable way even
>> to get the currently-executing function, although nearly every
>> implementation has a debugger that supports this (assuming you are
>> really asking how to do all this in the context of a debugger).
>
> The OP has already indicated portable is not necessary, and no, he
> does not want to do this from within the debugger, he is trying to
> embed more powerful debugging code in his source. I think he is
> looking for the implementation of :function so he can call it himself
> from app source. If that is not possible...
>
> I would macroexpand defun, carefully add `(let ((*func-name*
> ',funcname)) to the expansion, then either call it defun* and use it
> where you care or call it defun and shadow cl:defun.
See my response to Frank (hopefully one of the attempts succeeded).
Your method is more portable, but what would you do for the following
situation:
(defun* foo ()
(flet ((bar ()
;how do I find #'bar here?
))
(bar)))
Using the excl::ll technique the value returned is (FLET FOO BAR),
which is the name of the currently executing function.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Ken Tilton
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <PcjDi.77$KS3.76@newsfe12.lga>
Duane Rettig wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Steven M. Haflich wrote:
>>
>>>Frank Goenninger DG1SBG wrote:
>>>
>>>
>>>>Is there a (no matter if non-portable) way of getting the name of the
>>>>currently executing function at execution time?
>>>>
>>>>I'd want to further enhance my debugging/logging tools ...
>>>
>>>There is no standard way defined by the ANS. In ANSI CL names map
>>>onto
>>>functions but the mapping is one way. There is no portable way to map
>>>a function back to a name. Of course, there is no portable way even
>>>to get the currently-executing function, although nearly every
>>>implementation has a debugger that supports this (assuming you are
>>>really asking how to do all this in the context of a debugger).
>>
>>The OP has already indicated portable is not necessary, and no, he
>>does not want to do this from within the debugger, he is trying to
>>embed more powerful debugging code in his source. I think he is
>>looking for the implementation of :function so he can call it himself
>>from app source. If that is not possible...
>>
>>I would macroexpand defun, carefully add `(let ((*func-name*
>>',funcname)) to the expansion, then either call it defun* and use it
>>where you care or call it defun and shadow cl:defun.
>
>
> See my response to Frank (hopefully one of the attempts succeeded).
> Your method is more portable, but what would you do for the following
> situation:
>
> (defun* foo ()
> (flet ((bar ()
> ;how do I find #'bar here?
> ))
> (bar)))
>
It's no good, Duane, it's turtles all the way down: flet*
> Using the excl::ll technique the value returned is (FLET FOO BAR),
> which is the name of the currently executing function.
>
btw, I am greatly enjoying many small improvements in the debugger, find
definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
Slime yobbo trying to keep up. :)
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Tue, 04 Sep 2007 16:25:22 -0400, <···········@optonline.net> wrote:
>
> btw, I am greatly enjoying many small improvements in the debugger, find
> definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
> Slime yobbo trying to keep up. :)
Ah, competition is awesome isn't it?
--
Lisp: Powering `Impossible Thoughts since 1958
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> On Tue, 04 Sep 2007 16:25:22 -0400, <···········@optonline.net> wrote:
>
>>btw, I am greatly enjoying many small improvements in the debugger, find
>>definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
>>Slime yobbo trying to keep up. :)
>
>
> Ah, competition is awesome isn't it?
>
Hmmm, do we use the word "competition" for lions vs. Christians?
kenny
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Wed, 05 Sep 2007 11:57:38 -0400, <···········@optonline.net> wrote:
>
>
> GP lisper wrote:
>> On Tue, 04 Sep 2007 16:25:22 -0400, <···········@optonline.net> wrote:
>>
>>>btw, I am greatly enjoying many small improvements in the debugger, find
>>>definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
>>>Slime yobbo trying to keep up. :)
>>
>> Ah, competition is awesome isn't it?
>
> Hmmm, do we use the word "competition" for lions vs. Christians?
So those "improvements" you are enjoying, were they very difficult to
impletment? No, gee they could have been done long ago? I wonder
what spurred Franz then....
--
Lisp: Powering `Impossible Thoughts since 1958
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> On Wed, 05 Sep 2007 11:57:38 -0400, <···········@optonline.net> wrote:
>
>>
>>GP lisper wrote:
>>
>>>On Tue, 04 Sep 2007 16:25:22 -0400, <···········@optonline.net> wrote:
>>>
>>>
>>>>btw, I am greatly enjoying many small improvements in the debugger, find
>>>>definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
>>>>Slime yobbo trying to keep up. :)
>>>
>>>Ah, competition is awesome isn't it?
>>
>>Hmmm, do we use the word "competition" for lions vs. Christians?
>
>
> So those "improvements" you are enjoying, were they very difficult to
> impletment? No, gee they could have been done long ago? I wonder
> what spurred Franz then....
>
>
Sorry, I was not trying to make a valid point, I just wanted to mock
free software.
You are absolutely right, but I think your point explains ACache and
Agraph more than the insanely subtle refinements I see to the IDE. I
really shake my head at those. The only thing I can come up with--and I
say this only because of exchanges with tech support over suggested
subtle refinements in which they manifested this--is that Franz
engineers have not lost their enthusiasm for quality and good work* even
though they are evil developers of despicable proprietary software. For
which /money/ is charged!
kt
* Of course if they were all that good by now they would have
implemented "search in next file" during multi-file finds. k
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Thu, 06 Sep 2007 08:56:09 -0400, <···········@optonline.net> wrote:
>
> Sorry, I was not trying to make a valid point, I just wanted to mock
> free software.
Haven't you beaten it to death yet?
> You are absolutely right, but I think your point explains ACache and
> Agraph more than the insanely subtle refinements I see to the IDE. I
> really shake my head at those. The only thing I can come up with--and I
> say this only because of exchanges with tech support over suggested
> subtle refinements in which they manifested this--is that Franz
Not using contending tools, due to lack of need, I wouldn't know that.
I did wonder why cache and graph ended up in free Franz code.
> engineers have not lost their enthusiasm for quality and good work* even
> though they are evil developers of despicable proprietary software. For
> which /money/ is charged!
Money is something that local slumlords and cheap food providers seem
to need. With this itty bitty of argument, I was thinking that Franz
charging was keeping me from buying. If I have some code that I KNOW
will turn out profitable, then paying is fine. If I have an idea that
needs to be expressed first, then I am faced with the dilemma on
betting on whether the cash flow will support future license renewals
versus whether while on that 'expression' journey I might learn that
gaining market share is likely to be impossible. Tis the sad fate of
those without venture capitalists in our pockets and the belief that a
venture should pay for itself, lest it become a hobby.
--
Lisp: Powering `Impossible Thoughts since 1958
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> On Thu, 06 Sep 2007 08:56:09 -0400, <···········@optonline.net> wrote:
>
>>Sorry, I was not trying to make a valid point, I just wanted to mock
>>free software.
>
>
> Haven't you beaten it to death yet?
You may be right. We gave not had anyone come in here looking for a free
Lisp in about five minutes.
Meanwhile, resistance is futile:
http://peak.telecommunity.com/DevCenter/Trellis#the-trellis-name
Cells begat PyCells begat Trellis and Cellulose, while prior and
parallel art abound -- oh, wait, you are in the Cells Early Adopter Hall
of Fame, I'm preachin' to the choir.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On Thu, 06 Sep 2007 08:56:09 -0400, <···········@optonline.net> wrote:
> GP lisper wrote:
>> On Wed, 05 Sep 2007 11:57:38 -0400, <···········@optonline.net> wrote:
>>>GP lisper wrote:
>>>>On Tue, 04 Sep 2007 16:25:22 -0400, <···········@optonline.net> wrote:
>>>>
>>>>>btw, I am greatly enjoying many small improvements in the debugger, find
>>>>>definitions, etc I am seeing in AllegroCL8.x. I wouldn't want to be a
>>>>>Slime yobbo trying to keep up. :)
>>>>
>>>>Ah, competition is awesome isn't it?
>>>
>>>Hmmm, do we use the word "competition" for lions vs. Christians?
>>
>> So those "improvements" you are enjoying, were they very difficult to
>> impletment? No, gee they could have been done long ago? I wonder
>> what spurred Franz then....
>
> Sorry, I was not trying to make a valid point, I just wanted to mock
> free software.
>
> You are absolutely right, but I think your point explains ACache and
> Agraph more than the insanely subtle refinements I see to the IDE.
Actually the presence of concern over a competitor is more likely seen
in the small details than the large. It means that attention is being
paid to all aspects of 'being better'. I'm sure you have done that or
will. It is hard to discern from people enjoying their work and
seeking to improve at every step, but I'm happy to benefit from either
cause.
--
Lisp: Powering `Impossible Thoughts since 1958
--
Posted via a free Usenet account from http://www.teranews.com
On Wed, 05 Sep 2007 11:57:38 -0400, Ken Tilton wrote:
> Hmmm, do we use the word "competition" for lions vs. Christians?
I hadn't noticed the Christians being protected in parks, yet. Or maybe
that's what you meant. Sarcasm is so difficult to detect in Usenet text...
--
Andrew
Andrew Reilly wrote:
> On Wed, 05 Sep 2007 11:57:38 -0400, Ken Tilton wrote:
>
>
>>Hmmm, do we use the word "competition" for lions vs. Christians?
>
>
> I hadn't noticed the Christians being protected in parks, yet.
<sigh> neither do we use the word "competition" for high-powered hunting
rifles with telescopic scopes vs. claws and teeth, howver many or long.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
"Steven M. Haflich" <···@alum.mit.edu> writes:
> Frank Goenninger DG1SBG wrote:
>> Is there a (no matter if non-portable) way of getting the name of the
>> currently executing function at execution time?
>
> There is no standard way defined by the ANS. In ANSI CL names map onto
> functions but the mapping is one way. There is no portable way to map
> a function back to a name. Of course, there is no portable way even
> to get the currently-executing function, although nearly every
> implementation has a debugger that supports this (assuming you are
> really asking how to do all this in the context of a debugger).
And that is what I'm after! I'd like to do
(defun test ()
(format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
(excl::func_name *)))
This yields now:
CL-USER > (test)
Hi there! My name is NIL. Pleased to meet you!
I would like to get:
CL-USER > (test)
Hi there! My name is CL-USER::TEST. Pleased to meet you!
>
> In ACL the debugger can do it with the :function command.
>
> user(19): (funcall #'+ 41 'one)
> Error: `one' is not of the expected type `number'
> [condition type: type-error]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart).
> 1: Abort entirely from this (lisp) process.
> [1] user(20): :function
> #<Function +>
> [1] user(21): :current
> (+ 41 one)
>
> In ACL there is an unexported accessor that will return the name of a
> function object. (mop:generic-function-name will fo this for generic
> functions, of course.)
>
> [1] user(22): (excl::func_name *)
> +
Yep. Thanks for pointing out!
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Duane Rettig
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <o0odgiphbf.fsf@gemini.franz.com>
Frank Goenninger DG1SBG <·············@nomail.org> writes:
> "Steven M. Haflich" <···@alum.mit.edu> writes:
>
>> Frank Goenninger DG1SBG wrote:
>>> Is there a (no matter if non-portable) way of getting the name of the
>>> currently executing function at execution time?
>>
>> There is no standard way defined by the ANS. In ANSI CL names map onto
>> functions but the mapping is one way. There is no portable way to map
>> a function back to a name. Of course, there is no portable way even
>> to get the currently-executing function, although nearly every
>> implementation has a debugger that supports this (assuming you are
>> really asking how to do all this in the context of a debugger).
>
> And that is what I'm after! I'd like to do
>
> (defun test ()
> (format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
> (excl::func_name *)))
>
> This yields now:
>
> CL-USER > (test)
> Hi there! My name is NIL. Pleased to meet you!
This is slightly different (or, perhaps, more specific) than your
original request. If you are willing to have the function look at
itself, it need not go through the debugger; it can use the "ll"
facility I described in my ILC07 tutorial:
CL-USER(1): (defun test ()
(format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
(excl::func_name (excl::ll :register :function))))
TEST
CL-USER(2): (compile *)
TEST
NIL
NIL
CL-USER(3): (test)
Hi there! My name is TEST. Pleased to meet you!
NIL
CL-USER(4):
Note that "ll" functions are compile-only, so it would not work
interpreted.
Duane Rettig <·····@franz.com> writes:
> Frank Goenninger DG1SBG <·············@nomail.org> writes:
>
>> "Steven M. Haflich" <···@alum.mit.edu> writes:
>>
>>> Frank Goenninger DG1SBG wrote:
>>>> Is there a (no matter if non-portable) way of getting the name of the
>>>> currently executing function at execution time?
>>>
>>> There is no standard way defined by the ANS. In ANSI CL names map onto
>>> functions but the mapping is one way. There is no portable way to map
>>> a function back to a name. Of course, there is no portable way even
>>> to get the currently-executing function, although nearly every
>>> implementation has a debugger that supports this (assuming you are
>>> really asking how to do all this in the context of a debugger).
>>
>> And that is what I'm after! I'd like to do
>>
>> (defun test ()
>> (format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
>> (excl::func_name *)))
>>
>> This yields now:
>>
>> CL-USER > (test)
>> Hi there! My name is NIL. Pleased to meet you!
>
> This is slightly different (or, perhaps, more specific) than your
> original request. If you are willing to have the function look at
> itself, it need not go through the debugger; it can use the "ll"
> facility I described in my ILC07 tutorial:
I unfortunately had been unable to attend ILC07 - but I will try to
locate the tutorial!
>
> CL-USER(1): (defun test ()
> (format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
> (excl::func_name (excl::ll :register :function))))
Great!!!
> TEST
> CL-USER(2): (compile *)
> TEST
> NIL
> NIL
> CL-USER(3): (test)
>
> Hi there! My name is TEST. Pleased to meet you!
> NIL
> CL-USER(4):
>
> Note that "ll" functions are compile-only, so it would not work
> interpreted.
... Which is absolutely ok. I look forward to explore those "ll"
functions.
Hmm - those would be good for a next version of the ANSI CL standard
;-) (10 .. 9 .. 8 .. 7 ... let the bomb go off :-)
Frank
--
Frank Goenninger
frgo(at)mac(dot)com
"Don't ask me! I haven't been reading comp.lang.lisp long enough to
really know ..."
From: Duane Rettig
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <o0bqcip71g.fsf@gemini.franz.com>
Frank Goenninger DG1SBG <·············@nomail.org> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> This is slightly different (or, perhaps, more specific) than your
>> original request. If you are willing to have the function look at
>> itself, it need not go through the debugger; it can use the "ll"
>> facility I described in my ILC07 tutorial:
>
> I unfortunately had been unable to attend ILC07 - but I will try to
> locate the tutorial!
The files for my tutorial are at ftp://ftp.franz.com/pub/duane/ilc07/
You'll probably want especially to look at ll-doc.html. Unfortunately
register names are not listed - they tend to be architecture
dependent. However, :function is one register name that is valid on
all architectures.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Duane Rettig
Subject: Re: AllegroCL 8.1: Function name of currently executing function?
Date:
Message-ID: <o0k5r6ph07.fsf@gemini.franz.com>
[sorry if this is a repeat; I may have messed up the sending of the
original reply]
Frank Goenninger DG1SBG <·············@nomail.org> writes:
> "Steven M. Haflich" <···@alum.mit.edu> writes:
>
>> Frank Goenninger DG1SBG wrote:
>>> Is there a (no matter if non-portable) way of getting the name of the
>>> currently executing function at execution time?
>>
>> There is no standard way defined by the ANS. In ANSI CL names map onto
>> functions but the mapping is one way. There is no portable way to map
>> a function back to a name. Of course, there is no portable way even
>> to get the currently-executing function, although nearly every
>> implementation has a debugger that supports this (assuming you are
>> really asking how to do all this in the context of a debugger).
>
> And that is what I'm after! I'd like to do
>
> (defun test ()
> (format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
> (excl::func_name *)))
>
> This yields now:
>
> CL-USER > (test)
> Hi there! My name is NIL. Pleased to meet you!
>
> I would like to get:
>
> CL-USER > (test)
> Hi there! My name is CL-USER::TEST. Pleased to meet you!
This request seems slightly different than the original; I, like
Steve, took you to mean that you wanted external operators to be able
to work on a running fuction (which necessarily requires debugger
support). If you are looking for a "self"-like operation, you can use
the "ll" functionality I described in my ILC07 tutorial:
CL-USER(1): (defun test ()
(format t "~%Hi there! My name is ~A. Pleased to meet you!~%"
(excl::func_name (excl::ll :register :function))))
TEST
CL-USER(2): (compile *)
TEST
NIL
NIL
CL-USER(3): (test)
Hi there! My name is TEST. Pleased to meet you!
NIL
CL-USER(4):
Note that excl::ll is a compile-time-only function, so it would not
work interpreted.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182