The first daily build has been uploaded to http://starship.python.net/crew/robind/wxPython/daily/. It's still not quite fully automated but it is close. This version has several bugs fixes and other updates from wxWidgets since the 2.5.2.1 build, as well as binary RPMs (still built on RH9.)
Contributors: Please test your code with this build and send me updates as soon as possible.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
The first daily build has been uploaded to http://starship.python.net/crew/robind/wxPython/daily/. It's still not quite fully automated but it is close. This version has several bugs fixes and other updates from wxWidgets since the 2.5.2.1 build, as well as binary RPMs (still built on RH9.)
Oh, yeah. I also fixed the million pixel high rows in TreeListCtrl on OSX (it was an due to an uninitialized variable because of different event order,) the problem of wx.Image.SaveFile losing the transparency for PNG images, and a bunch of little bugs.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
The first daily build has been uploaded to http://starship.python.net/crew/robind/wxPython/daily/. It's still not quite fully automated but it is close. This version has several bugs fixes and other updates from wxWidgets since the 2.5.2.1 build, as well as binary RPMs (still built on RH9.)
Contributors: Please test your code with this build and send me updates as soon as possible.
Just curious, is there a difference between the -1 builds and the 20040615-1 builds?
BTW on Fedora Core 2, the i386 rpm gave me the Xinerama problem but simply rebuilding from the source rpm worked fine.
Should I contribute the built rpm?
David
David Fraser wrote:
Robin Dunn wrote:
Just curious, is there a difference between the -1 builds and the 20040615-1 builds?
From this point forward test builds will be done with my auto build tool and will have the date in the version number (and currently the 'p' [for 'pre'] as well but I may phase that out.) The release candidates and releases will have a version number without the date. The '-1' is because RPM requires a release tag. Now that I am taking more control of my builds I can probably start using that in some way, but since the other platforms don't have something like it maybe it doesn't make sense, and I can leave it for the RPM repackagers to use, like -3mdk, -fc2 or whatever.
BTW on Fedora Core 2, the i386 rpm gave me the Xinerama problem
Yes, I expected that since I'm still building on the bare RH9 machine. Since I'm having trouble getting FC2 to work reliably in a VMWare session I'm shuffling some hardware around here so I can set up a machine with multiple distros on it to use just for builds. If I can figure out how to get my auto builder to reboot from one distro to another so it can do a build on each of them then I'll be all set.
but simply rebuilding from the source rpm worked fine.
This is good news though!
Should I contribute the built rpm?
Not yet. When I start making release candidates it will probably make sense. Does anybody know off the top of your head if it is possible to change the %release tag from the rpmbuild command line? That would let David (or my auto builder) add a 'fc2' to the FedoraCore 2 builds without needing to do surgery on the .spec file in the source RPM.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Hi Robin,
[snip]
BTW on Fedora Core 2, the i386 rpm gave me the Xinerama problem
Yes, I expected that since I'm still building on the bare RH9 machine. Since I'm having trouble getting FC2 to work reliably in a VMWare session I'm shuffling some hardware around here so I can set up a machine with multiple distros on it to use just for builds. If I can figure out how to get my auto builder to reboot from one distro to another so it can do a build on each of them then I'll be all set.
This may be more of a long-term solution, but have you checked out coLinux rather than using VMWare? coLinux (www.colinux.org) is command-line based (although I've started a wx GUI for it ;-), so it may be more open to scripting. It's also not emulated, it's rather like "User Mode Linux", except I believe it's faster, and it runs on Windows. 
They have Linux support too, I think, though I've never tried it. They've got downloadable images on their download site for Fedora Core 1, Debian and Gentoo.
I don't know how your build system is setup, so I'm not sure this would be of much help, but just a suggestion you may want to try at some point, particularly since coLinux is free.
Thanks,
Kevin
On Jun 16, 2004, at 2:19 PM, Robin Dunn wrote:
Kevin Ollivier wrote:
This may be more of a long-term solution, but have you checked out coLinux rather than using VMWare? coLinux (www.colinux.org) is command-line based (although I've started a wx GUI for it ;-), so it may be more open to scripting. It's also not emulated, it's rather like "User Mode Linux", except I believe it's faster, and it runs on Windows.
I'll look into it. I wonder how hard it is to bootstrap other distros into it...
I don't know how your build system is setup,
Basically the master runs on my main worstation and either mounts shared folders from the other machines or uses scp to copy the source tarball or SRPM to them and then uses ssh to run the build script for that platform, and then moves the results back to a staging area on the main machine when the remote build is done. As long as the remote machines are able to expose an ssh server and has the right tools and libs installed then it doesn't matter if it is a physical machine or a virtual one.
so I'm not sure this would be of much help, but just a suggestion you may want to try at some point, particularly since coLinux is free.
Thanks,
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Hi Robin,
Kevin Ollivier wrote:
This may be more of a long-term solution, but have you checked out coLinux rather than using VMWare? coLinux (www.colinux.org) is command-line based (although I've started a wx GUI for it ;-), so it may be more open to scripting. It's also not emulated, it's rather like "User Mode Linux", except I believe it's faster, and it runs on Windows.
I'll look into it. I wonder how hard it is to bootstrap other distros into it...
The easiest way I've found is to install the OS as a partition (as if you planned on dual-booting) and then make a few mods to support coLinux (see http://www.colinux.org/wiki/index.php/ConvertingDistributions). It took a little while to learn, but I'm no Linux geek by any stretch of the word and I was able to figure it out. Once I can figure out how to properly copy that partition to an image file that I can use with coLinux, I plan on making some more distros with it.
If you're a command line guru (unlike me!), and the distro supports a command line install process, it probably wouldn't be too hard to bootstrap a new distro off of a "base" image file. The coLinux Wiki has a lot of tips and tricks on how to do things.
I don't know how your build system is setup,
Basically the master runs on my main worstation and either mounts shared folders from the other machines or uses scp to copy the source tarball or SRPM to them and then uses ssh to run the build script for that platform, and then moves the results back to a staging area on the main machine when the remote build is done. As long as the remote machines are able to expose an ssh server and has the right tools and libs installed then it doesn't matter if it is a physical machine or a virtual one.
coLinux should be able to work for this then. You can setup networking to share the network connection with the "host PC" or bridge the connection and give the coLinux instance it's own IP address. It may actually be noticeably faster, considering it isn't emulated.
Thanks,
Kevin
On Jun 16, 2004, at 4:14 PM, Robin Dunn wrote:
Robin Dunn wrote:
David Fraser wrote:
Just curious, is there a difference between the -1 builds and the 20040615-1 builds?
From this point forward test builds will be done with my auto build tool and will have the date in the version number (and currently the 'p' [for 'pre'] as well but I may phase that out.) The release candidates and releases will have a version number without the date. The '-1' is because RPM requires a release tag. Now that I am taking more control of my builds I can probably start using that in some way, but since the other platforms don't have something like it maybe it doesn't make sense, and I can leave it for the RPM repackagers to use, like -3mdk, -fc2 or whatever.
BTW on Fedora Core 2, the i386 rpm gave me the Xinerama problem
Yes, I expected that since I'm still building on the bare RH9 machine. Since I'm having trouble getting FC2 to work reliably in a VMWare session I'm shuffling some hardware around here so I can set up a machine with multiple distros on it to use just for builds. If I can figure out how to get my auto builder to reboot from one distro to another so it can do a build on each of them then I'll be all set.
but simply rebuilding from the source rpm worked fine.
This is good news though!
Should I contribute the built rpm?
Not yet. When I start making release candidates it will probably make sense. Does anybody know off the top of your head if it is possible to change the %release tag from the rpmbuild command line? That would let David (or my auto builder) add a 'fc2' to the FedoraCore 2 builds without needing to do surgery on the .spec file in the source RPM.
Haven't tried this, but Google gave the following, which seems like what you want:
http://www3.sympatico.ca/sarrazip/dev/rpm-building-crash-course.html
Tricks for .spec file writers
If you write an RPM .spec.in file, you may want to specify this at the top:
# Release number can be specified with rpmbuild --define 'rel SOMETHING' ...
# If no such --define is used, the release number is 1.
#
# Source archive's extension can be specified with --define 'srcext .foo'
# where .foo is the source archive's actual extension.
# To compile an RPM from a .bz2 source archive, give the command
# rpmbuild -tb --define 'srcext .bz2' @PACKAGE@-@VERSION@.tar.bz2
#
%if %{?rel:0}%{!?rel:1}
%define rel 1
%endif
%if %{?srcext:0}%{!?srcext:1}
%define srcext .gz
%endifThe |Release| field should be |%{rel}| and the |Source| field should be |%{name}-%{version}.tar%{srcext}|.
This way, the user can easily give a release number like "1_rh6" for a Red Hat 6 version of a package. Also, the user can produce an RPM from a .bz2 source tarball without having to edit the .spec file that it contains.
Hope that helps
David
Robin Dunn wrote:
The first daily build has been uploaded to http://starship.python.net/crew/robind/wxPython/daily/. It's still not quite fully automated but it is close. This version has several bugs fixes and other updates from wxWidgets since the 2.5.2.1 build, as well as binary RPMs (still built on RH9.)
Contributors: Please test your code with this build and send me updates as soon as possible.
Hi Robin
I have a wierd problem with the wx.ColourDialog in the daily build.
If I try and run the demo, and choose the ColourDialog demo, then clicking OK on the ColourDialog closes it, but clicking Cancel does not (the colour dialog stays open).
I was trying to test this, so I took the code for demo/ColourDialog.py and adapted it to run outside the demo (with a parent frame). Amazingly, clicking OK and Cancel both worked here.
So I played around with the ColourDialog code within the demo.
The difference seems to be that the if OK section writes out a message to the log.
If I add code to write out a message to the log if the dialog is cancelled, it closes fine. Or if I comment out the code that writes the message from the if OK section, it doesn't close when OK is clicked.
This seems really wierd to me. I would think its something strange with the demo but I have a similar problem in my own program.
It seems like the call to colourdialog.Destroy is reached, but the dialog still doesn't disappear.
Any ideas on how to debug this?
Incidentally, I have been using wxselect to have multiple versions installed - its *very* useful for this kind of testing as I have wxPythonGTK-2.5.1.5, wxPythonGTK2-2.5.1.5, and wxPythonGTK2-2.5.2.2 all installed, and can run the test easily on each version using a environment variable.
David
latest daily build, python 2.3.4, winxp:
daily build gives plenty of error at grid's autosizecolumns
and cangetvalueas (my grid has a checkbox type field):
5:47:45 PM.: (lambda event:self.AutoSizeColumns(),'Optimi&ze Columns'),
5:47:45 PM.: File "C:\PYTHON23\Lib\site-packages\wx\grid.py", line 1742, in AutoSizeColumns
5:47:45 PM.: return _grid.Grid_AutoSizeColumns(*args, **kwargs)
5:47:45 PM.: wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ..\..\src\generic\grid.cpp(9363): Unknown data type name
5:48:35 PM.: Traceback (most recent call last):
5:48:35 PM.: File "_\_tableadv.py", line 143, in CanGetValueAs
5:48:35 PM.: if typeName == colType:
5:48:35 PM.: wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ..\..\src\generic\grid.cpp(9349): Unknown data type name
also apparently, the grid row's default vertical height now
is increased? it's ok, but the checkbox render seems
becoming too large.
David Fraser wrote:
This way, the user can easily give a release number like "1_rh6" for a Red Hat 6 version of a package. Also, the user can produce an RPM from a .bz2 source tarball without having to edit the .spec file that it contains.
Hope that helps
Thanks. I figured it would be something like that.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
David Fraser wrote:
I have a wierd problem with the wx.ColourDialog in the daily build.
If I try and run the demo, and choose the ColourDialog demo, then clicking OK on the ColourDialog closes it, but clicking Cancel does not (the colour dialog stays open).
wxGTK2 is now using the native gtk dialog similar to how wxMSW does it. Apparently the native dialog doesn't hide itself when the cancel button is pressed, and since it is a top-level window it is not destroyed immediately when Destroy() is called, but when the next idle event happens. Since the dialog is not active any longer the next idle event doesn't happen in the case of the demo until you move the pointer outside the dialog window...
I've added an explicit gtk_widget_hide after the dialog is completed and that seems to take care of it for me.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
latest daily build, python 2.3.4, winxp:
daily build gives plenty of error at grid's autosizecolumns
and cangetvalueas (my grid has a checkbox type field):5:47:45 PM.: (lambda event:self.AutoSizeColumns(),'Optimi&ze Columns'),
5:47:45 PM.: File "C:\PYTHON23\Lib\site-packages\wx\grid.py", line 1742, in AutoSizeColumns
5:47:45 PM.: return _grid.Grid_AutoSizeColumns(*args, **kwargs)
5:47:45 PM.: wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ..\..\src\generic\grid.cpp(9363): Unknown data type name
5:48:35 PM.: Traceback (most recent call last):
5:48:35 PM.: File "_\_tableadv.py", line 143, in CanGetValueAs
5:48:35 PM.: if typeName == colType:
5:48:35 PM.: wx._core.PyAssertionError: C++ assertion "wxAssertFailure" failed in ..\..\src\generic\grid.cpp(9349): Unknown data type name
I'll check into this.
also apparently, the grid row's default vertical height now
is increased?
I don't recall any specific changes dealing with this, but it looks like the height has been restored to what it used to be a few releases ago. Perhaps something that the grid is using to determine the height has changed or been reverted to old functionality.
dody.wijaya2@asp.co.id wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
David Fraser wrote:
I have a wierd problem with the wx.ColourDialog in the daily build.
If I try and run the demo, and choose the ColourDialog demo, then clicking OK on the ColourDialog closes it, but clicking Cancel does not (the colour dialog stays open).wxGTK2 is now using the native gtk dialog similar to how wxMSW does it. Apparently the native dialog doesn't hide itself when the cancel button is pressed, and since it is a top-level window it is not destroyed immediately when Destroy() is called, but when the next idle event happens. Since the dialog is not active any longer the next idle event doesn't happen in the case of the demo until you move the pointer outside the dialog window...
That makes sense - I hadn't noticed that moving the mouse pointer off it made it disappear...
I've added an explicit gtk_widget_hide after the dialog is completed and that seems to take care of it for me.
Brilliant, thanks
David
Testing CVS version from a couple day ago, rather thanthedaily build, but this probably applies:
SetSizeHints() seems to take one aragument now, rather than two in 2.5.1. I imagine this is the same old:
(x,y) vs ( (x,y) )
Issue.
However, it seems to be the opposite of what was done for DCs, as it chooses the tuple version over the x,y version. Was this intentional? If so, there should be a note in the Changes doc.
I just did more testing, and SetSizeHints(x,y) seems to work on both 2.5.1 and the cvs version....
-Chris
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris Barker wrote:
Testing CVS version from a couple day ago, rather thanthedaily build, but this probably applies:
SetSizeHints() seems to take one aragument now, rather than two in 2.5.1. I imagine this is the same old:
(x,y) vs ( (x,y) )
Issue.
It should be taking both forms.
>>> f = wx.Frame(None)
>>> f.SetSizeHints(1, 2, 3, 4)
>>> f.SetSizeHints((1, 2), (3, 4))
This is an example where I turned on overloading as I didn't think there was much need for using keyword args in this case.
$ pydoc wx.Window.SetSizeHints
Help on method SetSizeHints in wx.Window:
wx.Window.SetSizeHints = SetSizeHints(*args) unbound wx._core.Window method
SetSizeHints(self, Size minSize, Size maxSize=DefaultSize, Size incSize=DefaultSize)
SetSizeHints(self, int minW, int minH, int maxW=-1, int maxH=-1, int incW=-1,
int incH=-1)
Allows specification of minimum and maximum window sizes, and window
size increments. If a pair of values is not set (or set to -1), the
default values will be used. If this function is called, the user
will not be able to size the window outside the given bounds (if it is
a top-level window.) Sizers will also inspect the minimum window size
and will use that value if set when calculating layout.
The resizing increments are only significant under Motif or Xt.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
>>> f = wx.Frame(None)
>>> f.SetSizeHints(1, 2, 3, 4)
>>> f.SetSizeHints((1, 2), (3, 4))
and the first form is compatible with 2.5.1, so I'm happy.
$ pydoc wx.Window.SetSizeHints
Help on method SetSizeHints in wx.Window:
I've GOT to start using pydoc! The docs for wxPython are looking really good!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov