Is anybody here building 2.5 from source besides Kevin O.? Anyway, I've just checked a load of stuff into CVS. Here's some random notes about it.
1. Kevin's demo patch has been checked in (Thanks!) Please contiune to test the demo as I've done very little with the new versions so far.
2. If you're using SWIG you'll need to update from SWIG's CVS and apply a new patch in wxPython/SWIG/swig.xmlout.patch. This fixes a couple things in how the XML is formatted and also adds command line options to allow writing the XML *after* a normal language module has been run, rather than *instead of* a normal language module. This is needed in order to facilitate the docstring and refdocs extraction and conversion to a simplified XML format but it also allows the code for building the renamers to be a little more sane.
3. The generation of the xml is now in setup.py instead of in build_renamers. This is to ensure that the same command line options are used. The XML file is no longer removed but is left around for when the doc extraction tools are ready to be run. They won't be checked in to CVS though since each of the raw XML files is several megabytes in size.
4. Since we're not running the SWIG XML as a regular language module I changed the #ifndef for excluding stuff when the renamer is running to BUILDING_RENAMERS instead of SWIGXML. This means that you'll probably have to ensure that build_renamers is run twice after you update, first to write the new #ifndef and then the second time to properly generate the renamers with the old %rename's excluded.
5. build_renamers.py will now use libxml2 by default if it is installed. If it isn't then the old insane way using xml.sax will still be used, but parts of the output are generated in a little different order then and so there will be uneedded CVS diffs...
I think that's it for now, please excuse me whle I allow my head to explode...
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks for the update! I think I got it all... <G>
I think that's it for now, please excuse me whle I allow my head to explode...
Errr... I take it now's a bad time to ask if you had any suggestions as to why even frame.Connect(-1, -1, wxMOZILLA_URL_CHANGED, self.UpdateURL) would not work with the CVS build? I've tried passing in the wxMozilla ID as well with no luck. The events are firing in the C++ demo and all is working as it should be (as well as wxPy 2.4 of course), so I'm not sure exactly where the problem could be (no name errors or the like), but it does seem to be something in the transition to the new SWIG. Any tips on exactly how I could debug this further?
Sorry, but this problem is nagging at me now that I'm so close. <G>
Thanks for the update! I think I got it all... <G>
I think that's it for now, please excuse me whle I allow my head to explode...
Errr... I take it now's a bad time to ask
Nah, I just worked on non-XML and non-build stuff for a while and allowed the brain-bomb to defuse a bit.
if you had any suggestions as to why even frame.Connect(-1, -1, wxMOZILLA_URL_CHANGED, self.UpdateURL) would not work with the CVS build? I've tried passing in the wxMozilla ID as well with no luck. The events are firing in the C++ demo and all is working as it should be (as well as wxPy 2.4 of course), so I'm not sure exactly where the problem could be (no name errors or the like), but it does seem to be something in the transition to the new SWIG.
A couple "are you sure your TV is plugged in?" type of questions:
1. Are you sure that wxMOZILLA_URL_CHANGED has the same value in Python as it does in C++?
2. Does it work if you use mozillaWindow.Connect(..) instead of frame?
Any tips on exactly how I could debug this further?
Set a breakpoint where you generate the event and trace it though ProcessEvent in the debugger. It should end up in wxPyCallback::EventThunker (helpers.cpp) if it's going to a Python handler.
Actually the more I think about it, the more I would bet that it's #1 above. I ran into something similar on OS X a few weeks ago that was due to the @#@*!@#! dynamic linker. Not all the static values are initialized in the wx dynlib by the time that they are first used in another static initializer in the wxPython extension modules, (the wxEVT_* are initialized by a call to wxNewEvenType, but dynld doesn't call it until after it has loaded _core.so) so I had to find a way to either delay their first use, or to reinit the Python objects for the event types. There is a typemap that will take care of it, but you have to define your event types like this in the .i files to activate it:
%constant wxEvenType wxMOZILLA_URL_CHANGED;
···
On Dec 11, 2003, at 1:13 PM, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Also, I'm seeing an error after doing a CVS update and patching and re-building SWIG.
I'm getting undeclared symbols for "Get/SetTopLeft" and "Get/SetBottomRight" at src/mac/core_wrap.cpp:3030~. I've touched the *.i sources and run with USE_SWIG=1 and SWIG pointing to my CVS SWIG build, so I don't think it's an out of date SWIGged file. Anyone else seeing this?
Thanks,
Kevin
···
On Dec 11, 2003, at 1:13 PM, Robin Dunn wrote:
Is anybody here building 2.5 from source besides Kevin O.? Anyway, I've just checked a load of stuff into CVS. Here's some random notes about it.
1. Kevin's demo patch has been checked in (Thanks!) Please contiune to test the demo as I've done very little with the new versions so far.
2. If you're using SWIG you'll need to update from SWIG's CVS and apply a new patch in wxPython/SWIG/swig.xmlout.patch. This fixes a couple things in how the XML is formatted and also adds command line options to allow writing the XML *after* a normal language module has been run, rather than *instead of* a normal language module. This is needed in order to facilitate the docstring and refdocs extraction and conversion to a simplified XML format but it also allows the code for building the renamers to be a little more sane.
3. The generation of the xml is now in setup.py instead of in build_renamers. This is to ensure that the same command line options are used. The XML file is no longer removed but is left around for when the doc extraction tools are ready to be run. They won't be checked in to CVS though since each of the raw XML files is several megabytes in size.
4. Since we're not running the SWIG XML as a regular language module I changed the #ifndef for excluding stuff when the renamer is running to BUILDING_RENAMERS instead of SWIGXML. This means that you'll probably have to ensure that build_renamers is run twice after you update, first to write the new #ifndef and then the second time to properly generate the renamers with the old %rename's excluded.
5. build_renamers.py will now use libxml2 by default if it is installed. If it isn't then the old insane way using xml.sax will still be used, but parts of the output are generated in a little different order then and so there will be uneedded CVS diffs...
I think that's it for now, please excuse me whle I allow my head to explode...
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org
Also, I'm seeing an error after doing a CVS update and patching and re-building SWIG.
I'm getting undeclared symbols for "Get/SetTopLeft" and "Get/SetBottomRight" at src/mac/core_wrap.cpp:3030~. I've touched the *.i sources and run with USE_SWIG=1 and SWIG pointing to my CVS SWIG build, so I don't think it's an out of date SWIGged file. Anyone else seeing this?
Did you also update, build and install wxWindows? Those methods were added to wxRect (see gdicmn.h) early this morning.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Hi Robin,
Also, I'm seeing an error after doing a CVS update and patching and re-building SWIG.
I'm getting undeclared symbols for "Get/SetTopLeft" and "Get/SetBottomRight" at src/mac/core_wrap.cpp:3030~. I've touched the *.i sources and run with USE_SWIG=1 and SWIG pointing to my CVS SWIG build, so I don't think it's an out of date SWIGged file. Anyone else seeing this?
Did you also update, build and install wxWindows? Those methods were added to wxRect (see gdicmn.h) early this morning.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org
Hi Robin,
<<snip>>
Thanks for the update! I think I got it all... <G>
I think that's it for now, please excuse me whle I allow my head to explode...
Errr... I take it now's a bad time to ask
Nah, I just worked on non-XML and non-build stuff for a while and allowed the brain-bomb to defuse a bit.
if you had any suggestions as to why even frame.Connect(-1, -1, wxMOZILLA_URL_CHANGED, self.UpdateURL) would not work with the CVS build? I've tried passing in the wxMozilla ID as well with no luck. The events are firing in the C++ demo and all is working as it should be (as well as wxPy 2.4 of course), so I'm not sure exactly where the problem could be (no name errors or the like), but it does seem to be something in the transition to the new SWIG.
A couple "are you sure your TV is plugged in?" type of questions:
1. Are you sure that wxMOZILLA_URL_CHANGED has the same value in Python as it does in C++?
Checking up on it, wxEVT_MOZILLA_URL_CHANGED and the rest of the events all seem to be defined as 0 in Python. I define them in an enum inside the .i file. Hmm, I actually vaguely recall reporting a similar problem with the demo splash screen a few weeks back. =)
2. Does it work if you use mozillaWindow.Connect(..) instead of frame?
Any tips on exactly how I could debug this further?
Set a breakpoint where you generate the event and trace it though ProcessEvent in the debugger. It should end up in wxPyCallback::EventThunker (helpers.cpp) if it's going to a Python handler.
Actually the more I think about it, the more I would bet that it's #1 above. I ran into something similar on OS X a few weeks ago that was due to the @#@*!@#! dynamic linker. Not all the static values are initialized in the wx dynlib by the time that they are first used in another static initializer in the wxPython extension modules, (the wxEVT_* are initialized by a call to wxNewEvenType, but dynld doesn't call it until after it has loaded _core.so) so I had to find a way to either delay their first use, or to reinit the Python objects for the event types. There is a typemap that will take care of it, but you have to define your event types like this in the .i files to activate it:
%constant wxEvenType wxMOZILLA_URL_CHANGED;
Yes, I think this is where the problem lies as well. However, when I try to use "%constant wxEventType wxEVT_MOZILLA_URL_CHANGED;" in my .i file (listed right above the wx.PyEventBinder calls), I get compile time errors that wxEVT_MOZILLA_URL_CHANGED (and the others) are not declared in this scope. I get this error with or without the enum being in the .i file. (BTW, I am also including the wxMozilla.h header where the DECLARE_LOCAL_EVENT_TYPE macros reside.) I'm sure I'm missing something simple here, but I'm stuck as to what it might be. I get the feeling, though, that if I can get the constant declarations to compile, things will get much better. =)
1. Are you sure that wxMOZILLA_URL_CHANGED has the same value in Python as it does in C++?
Checking up on it, wxEVT_MOZILLA_URL_CHANGED and the rest of the events all seem to be defined as 0 in Python. I define them in an enum inside the .i file. Hmm, I actually vaguely recall reporting a similar problem with the demo splash screen a few weeks back. =)
Yeah, that sheds a little more light on that dark and dusty memory cell...
%constant wxEvenType wxMOZILLA_URL_CHANGED;
Yes, I think this is where the problem lies as well. However, when I try to use "%constant wxEventType wxEVT_MOZILLA_URL_CHANGED;" in my .i file (listed right above the wx.PyEventBinder calls), I get compile time errors that wxEVT_MOZILLA_URL_CHANGED (and the others) are not declared in this scope. I get this error with or without the enum being in the .i file. (BTW, I am also including the wxMozilla.h header where the DECLARE_LOCAL_EVENT_TYPE macros reside.) I'm sure I'm missing something simple here, but I'm stuck as to what it might be.
Look at the c++ source spit out by SWIG. Without the typemap (either as an enum or as the %constant) you end up with code like this that makes an entry in a static array of swig_const_info structures:
So nothing special is done in either case, both cases need to ensure that the definition of your wxEVT_ values are visible to the compiler. If it is compiling okay in the enum case there shouldn't be any problem in the %constant case, unless there is something really wonky going on with the compiler.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Well, in this case, I had the TV off. ^_^; (You probably already knew this...) Sorry, I was staring at the code so long that I missed some rather obvious typos, and when I corrected those typos, using the %constant wxEventType syntax indeed resolved the problem. wxPyZilla is now happily responding to events like on other platforms.
Thanks for your explanations though, they helped me understand the situation better, at which point I realized that there had to be something simple I was overlooking.
Kevin
···
On Dec 12, 2003, at 2:31 PM, Robin Dunn wrote:
Kevin Ollivier wrote:
1. Are you sure that wxMOZILLA_URL_CHANGED has the same value in Python as it does in C++?
Checking up on it, wxEVT_MOZILLA_URL_CHANGED and the rest of the events all seem to be defined as 0 in Python. I define them in an enum inside the .i file. Hmm, I actually vaguely recall reporting a similar problem with the demo splash screen a few weeks back. =)
Yeah, that sheds a little more light on that dark and dusty memory cell...
%constant wxEvenType wxMOZILLA_URL_CHANGED;
Yes, I think this is where the problem lies as well. However, when I try to use "%constant wxEventType wxEVT_MOZILLA_URL_CHANGED;" in my .i file (listed right above the wx.PyEventBinder calls), I get compile time errors that wxEVT_MOZILLA_URL_CHANGED (and the others) are not declared in this scope. I get this error with or without the enum being in the .i file. (BTW, I am also including the wxMozilla.h header where the DECLARE_LOCAL_EVENT_TYPE macros reside.) I'm sure I'm missing something simple here, but I'm stuck as to what it might be.
Look at the c++ source spit out by SWIG. Without the typemap (either as an enum or as the %constant) you end up with code like this that makes an entry in a static array of swig_const_info structures:
So nothing special is done in either case, both cases need to ensure that the definition of your wxEVT_ values are visible to the compiler. If it is compiling okay in the enum case there shouldn't be any problem in the %constant case, unless there is something really wonky going on with the compiler.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org
I've tried passing in the wxMozilla ID as well with no luck. The events are firing in the C++ demo and all is working as it should be (as well as wxPy 2.4 of course), so I'm not sure exactly where the problem could be (no name errors or the like), but it does seem to be something in the transition to the new SWIG. Any tips on exactly how I could debug this further?