[plt-scheme] Debugging Multiple Modules

From: Filled Void (filledvoid at gmail.com)
Date: Tue Aug 29 14:37:41 EDT 2006

Yeah, I think Robby hit on what I'm thinking.  One approach that I've seen  
in some debuggers (e.g. ActiveState Komodo as I recall) is that when a  
function is called that is in a different file, the debugger loads a *new*  
window with that file, even if that file is already open for editing.  In  
this case, that file could open in a new tab with the debugging state  
somehow linked to the state of the original file.  Clicking "Stop" or  
"Pause" on either tab would then have the same effect.  If the file is  
already open, you could make the tab read-only to avoid issues with  
editing the same file at once.  If the file hasn't been opened yet, you  
could probably allow editing, but you might want to still have it be  
read-only for consistency sake.

Thanks for the quick feedback!!  Hope this helps a bit...

fv

On Mon, 28 Aug 2006 23:05:51 -0500, Robby Findler <robby at cs.uchicago.edu>  
wrote:

> I think you only want one session state, but to cope with multiple  
> editors that display different parts of the program. I don't think any  
> new threads should be required (beyond what you already have for running  
> with a single window).
>
> Robby
>
> On Aug 28, 2006, at 10:26 PM, Gregory Cooper wrote:
>
>> So the error tracer always shows the most recent error.  Is that  
>> correct?
>>
>> I think with the debug button it's more complicated because I'm
>> tracking a program's execution over time.  It can be paused at a
>> breakpoint (where you can inspect its state), then resume, etc.  I
>> might be able to take a similar approach to the error tracer
>> (multiplexing events from different debugging sessions into the same
>> window), but I don't think it would be pretty if someone were to
>> actually debug the same file from two places at once.  (Which
>> session's state would I show?)  Perhaps it's mostly a matter of making
>> the debugger handle multiple threads sensibly.  I'll think about it.
>>
>> On 8/28/06, Robby Findler <robby at cs.uchicago.edu> wrote:
>>> Right now, if you open two files in drscheme, and an error is signalled
>>> from an evaluation in one file whose source location is in the other
>>> file, DrScheme goes to the second file just fine. Is that what you
>>> want? Or, do you really need the two interactions windows to be
>>> syncronized?
>>>
>>> Robby
>>>
>>> At Mon, 28 Aug 2006 23:10:39 -0400, "Gregory Cooper" wrote:
>>> > Hi,
>>> >
>>> > Unfortunately (as you've noticed), the Debug button does not support
>>> > debugging across multiple files.  This is a feature that I really  
>>> wish
>>> > could be implemented without extensive effort, but I'm not aware of
>>> > any natural way to do so.  In particular, while it would be nice to
>>> > just have a separate tab for each file and make the debugger follow
>>> > the control flow across tabs, this would conflict with the design of
>>> > DrScheme, where each tab has its own private evaluation
>>> > thread/execution session.  (E.g., what if you're debugging one file
>>> > already, then start debugging another file that requires the first
>>> > file?)  If I can't use DrScheme's built-in support for managing
>>> > multiple files, I'd have to write my own, which I suspect would
>>> > involve a fair bit of work...
>>> >
>>> > It's possible, though, that I'm just being dense about this, and
>>> > perhaps Robby can suggest a technique that would make it relatively
>>> > easy.
>>> >
>>> > Greg
>>> >
>>> > On 8/28/06, Filled Void <filledvoid at gmail.com> wrote:
>>> > > Hi,
>>> > >
>>> > > My project now consists of around 5 modules each defined in a  
>>> separate
>>> > > file and requiring other modules as necessary.  I define my  
>>> modules as:
>>> > >
>>> > > (module my_project_module mzscheme
>>> > > ...
>>> > > )
>>> > >
>>> > > and use it with:
>>> > >
>>> > > (require "my_project_module.scm")
>>> > >
>>> > > My problem is that I can't seem to debug dependency modules using
>>> > > DrScheme.  In other words, I start debugging the top-level module,  
>>> but
>>> > > then DrScheme doesn't seem to trace down through the functions  
>>> defined in
>>> > > other modules.  If they are all defined in one file, then it  
>>> works, but
>>> > > the project is large enough that that is very tedious.  I'm using  
>>> the
>>> > > Pretty Big language, although I've briefly tried a few of the  
>>> others
>>> > > (including module...).
>>> > >
>>> > > Thanks for any help!
>>> > >
>>> > > fv
>>> > > _________________________________________________
>>> > >   For list-related administrative tasks:
>>> > >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>> > >
>>> > _________________________________________________
>>> >   For list-related administrative tasks:
>>> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


Posted on the users mailing list.