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

[Tunmer, Luke]

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