[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    Re: [Sbcl-devel] package locks and tracing
From:       Faré <fahree () gmail ! com>
Date:       2009-07-20 16:59:38
Message-ID: 653bea160907200959x6f0e25bbtb23ef4db8d4198f0 () mail ! gmail ! com
[Download RAW message or body]

When a TRACEd function is invoked, isn't it meant to already:
1- checks whether the special variable *IN-TRACE* is non-nil;
 if so, proceed without tracing.
2- binds same special variable to T.
?

That way, you should still be able to usefully trace system functions
to see when they are being called directly or indirectly by user code,
without having to care or worry about TRACE itself using same function
(assuming checking and proceeding can happen w/o a function call).

Is there a reason why *in-trace* is either not working or not sufficient?

In trace-start-breakpoint-fun I see quite a few function calls before
the value of *in-trace* is tested. Probably they should be moved to
*after* it is checked - or the check itself could be moved to
trace-call.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Minimum wage laws are but making it illegal for less productive people
to get an honest job.




2009/7/20 Robert Goldman <rpgoldman@sift.info>:
> Tobias C. Rittweiler wrote:
>> [ prior reply didn't make it to the list. ]
>>
>> Richard M Kreuter writes:
>>
>>> "Tobias C. Rittweiler" writes:
>>>> Evaluating (TRACE LIST) will bring SBCL down (Maciej Katafiasz reported
>>>> that it'd even segfault for him.)
>>>>
>>>> So I started to hack in checking for package locks in TRACE.
>>> Are you sure that it's the package locks?
>>
>> What's "it" here? The cause for the segfault?
>>
>>
>>> IIRC, tracing anything that TRACE calls is problematic; maybe this is
>>> what you're seeing.
>>
>> Yes, very likely. Still it seems reasonable to me to signal an
>> (continuable) error in case you're trying to trace a symbol from a
>> locked package. Is it not?
>
> I confess to not having used the trace facility extensively on SBCL, but
> on ACL, I trace some built ins not infrequently.  A paradigm case would
> be something like
>
> (trace (find :inside <my-function-that-finds-more-than-expected>))
>
> It's almost never a good idea to unconditionally trace a built-in, but
> in specific circumstances, it can be very helpful.
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
>

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[prev in list] [next in list] [prev in thread] [next in thread]