Re: [Boa Constr] Segfault bugfix and "hello!"

[Riaan B. <riaan@e.co.za>]

Hi Shane,

Shane Hathaway wrote:

> > I don't exactly understand how the ZEO fits in with this.
> > Would the debugger be some sort of ZEO shared object?
> > Are we debugging Product code or Zope code?
> 
> This would be primarily for product code.  There is a big need for a GUI
> debugger that works with Zope.
> 

I've not developed a Zope Product yet so I know neither the procedure
nor the pitfalls. 

> > I'm very interested in extending Boa's Zope support as far as possible.
> > Zope debugging sounds very cool.
> 
> I've thought about it a little more, and I think ZEO isn't a necessary
> detail.  What we really want is to have the ability to start a Zope
> instance (ZEOfied or not) which is running under the control of Boa.

The most ironic thing for me is that it would probably be easier to 
debug Zope than to debug a simple 'Hello world' wxPython app because 
I've got big problems switching between the mainloop of the GUI 
application and Boa's mainloop. In Zope there is no mixing between 
mainloops so it should be simpler.

Another big problem is that once the program being debugged is running
Boa is unavailable until a breakpoint or an error is encountered.
So you have to set these before hand.

I really hope someone with a little more debugger experience than me
would look into this.

> 
> Switching topics, I have made some changes that cause Boa to parse modules
> "late", i.e. only when the user clicks the "Explore" tab or something else
> that needs the info.  This makes loading files into the source editor
> quite a bit snappier.  Interested?

Great stuff, definitely interested, quite a few features like code
browsing
and code completion use the parsed data. I postponed just-in-time 
parsing because I accessed the model.module attribute all over the 
code and thought it would be a lot of work fixing it everywhere.

> 
> Also, we need to find out why the editor is a bit sluggish.  I have
> identified and fixed a bug in Scintilla that makes it so Windows keyboard
> events are skipped, 

Which keys?
I had trouble binding ctrl with certain other keys e.g. '<', '>' 

> but then I discovered that wxStyledTextCtrl needs some
> significant updates if it is to be compatible with the latest Scintilla
> (it's using 1.25, Scintilla is up to 1.32.)

Robin Dunn recently announced a newly wrapped wxStyledTextCtrl. This
one seems much faster (on windows have not yet seen wxGTK version) 
and goes up to 1.32. We should see it in 2.2.2. Or grab it from CVS.
There are interface changes which I have already corrected for in Boa, 
but not booked into CVS yet.

> 
> And I can't figure out why the editor is faster in the wxPython demo.
> For some reason the paint operation takes much longer in Boa.  

One of the reasons seemed to be that each wxStyledTextCtrl ate a few
idle CPU cycles, with a few modules open everything got slower.
This is addressed by the new wxSTC.

> Does Boa
> hook any events that might occur during a paint operation?

No, but I do have some code that has to run on every key press. Things
like the bracket matching, smart indent / delete, tab etc.

> 
> Keep up the good work!

I will, thanks for climbing in and helping out.

-- 
Riaan Booysen
___________________________________________________
Boa Constructor - RAD GUI building IDE for wxPython
     http://boa-constructor.sourceforge.net