[Eric] RE: Debugging when running from .zip files, and various problems

[Detlev Offenbach]

Hi,

thanks for your response. I appreciate your support very much. Please let me 
know about your results.

Regards,
Detlev

On Montag, 7. Januar 2008, Tunmer, Luke wrote:
> Thanks, Detlev.
>
> Getting some example code might take a while. Given that others haven't
> seen these issues, I'll probably tackle if from the other direction -
> attempt to see what is happening in Eric to find out what's going on,
> and why our usage of Python is triggering this, in particular the
> problem with the different behavior between the Standard and
> Multithreaded clients.
>
> I'll let you know more when I do.
>
> Regards,
> Luke
>
>
> -----Original Message-----
> From: Detlev Offenbach [mailto:detlev at die-offenbachs.de]
> Sent: 06 January 2008 14:04
> To: eric at riverbankcomputing.com
> Cc: Tunmer, Luke
> Subject: Re: [Eric] RE: Debugging when running from .zip files, and
> various problems
>
> On Donnerstag, 3. Januar 2008, Tunmer, Luke wrote:
> > Hi,
> >
> > I've just started to look at Eric4, and I'm impressed. However, the
> > following things have stopped me in my tracks:
> >
> > - We build our project from a large number of components (currently >
> > 15), some developed by other teams. The way that these components get
> > built is they are compiled into pyc files and packaged into a zip file
>
> -
>
> > very much like the Java jar file concept. When our project runs, all
>
> the
>
> > zip files get added to the sys.path by a little bootstrap script. This
> > of course breaks the assumption that most debuggers use, which is that
> > the py sits next to the pyc file. Is there a way of getting the Eric4
> > DebugClient to have some knowledge of a mapping between the filename
> > found in frame.f_code.co_filename and the source file, using something
> > like a source-path setting? I don't think the remote/local mapping
>
> will
>
> > be sufficiently rich to do this.
>
> Have you tried it? I was about to suggest this function.
>
> > - I have also hit a problem with threads. If I select the Multi
>
> Threaded
>
> > Client Type, my thread's run method is never getting called. If I
>
> select
>
> > Standard, then my Python-created threads do run, however threads that
> > originate from elsewhere (i.e. ominORBpy) seem to get hung up. If the
> > Standard client is selected, then breakpoints set in wxPython dialog
> > code fail to work.
>
> Can you send some minimal example code, that shows the observed
> behaviour.
> That way I can try to debug it.
>
> > - Furthermore the Multi Threaded client seems to be excruciatingly
>
> slow:
> > our app is a large wxPython app, and the startup of it can take 2
> > minutes when run in Eric4 as opposed to 15 seconds normally. I looked
>
> at
>
> > how much gets run on the settrace hook and it seems to be quite a bit.
> > However the Standard client runs much faster.
> >
> > - I've also had lock-ups where the client is consuming 100% of the
>
> CPU.
>
> Any idea what was going on at that time?
>
> > Many thanks for any feedback you can offer.
> >
> > This is Eric4 - 4.0.3 (r1529) running on WinXP.
> >
> > Regards.
> > Luke
> >
> >
> > _______________________________________________
> > Eric mailing list
> > Eric at riverbankcomputing.com
> > http://www.riverbankcomputing.com/mailman/listinfo/eric
>
> Detlev



-- 
Detlev Offenbach
detlev at die-offenbachs.de