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

[Shane H. <sh...@di...>]

On Sat, 21 Oct 2000, Riaan Booysen wrote:

> Shane Hathaway wrote:
> > 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. 

It's not hard once you get the idea (and there's a decent tutorial
now) but one still longs for a debugger. 

> > 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 haven't looked at how Boa's debugger works, but IMHO it's always best to
run a processing being debugged in a different process, especially
considering that a lot of times what you need to debug is a segfault
(GPF).

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

I'm getting everything set up to start doing some work on Boa.  I think
the debugger will be the first thing I'll look into.

> > 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.

OO encapsulation is designed to overcome this.  I created a new method
named getModule() which creates the module if it hasn't been
created.  I'll submit patches soon. 

> > 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. '<', '>' 

If the program spends too much time processing a keystroke, Windows will
bunch the keystrokes into a single event.  Scintilla interprets the single
event as a single keystorke, ignoring the repeat count.

> > 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.

That's great news!

> > 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.

Excellent.

> > 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.

Yes, I saw that.  There must still be something that's slowing the paint
operations, though.

> > Keep up the good work!
> 
> I will, thanks for climbing in and helping out.

I can't commit myself too much, but I'm pretty excited about what you've
done so far.  I'll help as much as I can.

Shane