Please download and test in a variety of situations. Other than the true/false thing and some other bug fixes nothing much has changed since .6 so I don't expect any new problems, but you never know...
Here's the changes:
2.4.0.7
···
-------
Gave up on generating a warning upon the use of the old true/false or
TRUE/FALSE values.
Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
that it can successfully handle lots of nodes instead of overflowing
when the virtual height of the widget overflowed a 16-bit value.
Fixed the typemap that converts strings to wxColours to also accept
unicode.
Fixed problem where the wrong class name could sometimes be used for
OOR.
Fixed an interpreter lock problem in the __eq__ and __ne__ methods in
wxSize and etc.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
So far I haven't seen any issues using Python 2.2.2 and wxPython 2.4.0.7 on
Windows 2000. I no longer have Python 2.1.x, 2.2, or 2.2.1. I'm assuming
that True/False problems would manifest themselves with 2.1.x and 2.2.
One thing I'm wondering about is whether previous versions of 2.4.0.x should
be hidden on the download page if in fact we have some API differences and
behavior changes from 2.4.0.2. The large number of downloads of
wxPythonGTK-py2.2-2.4.0.2-2.i386.rpm is most likely a SF reporting error or
some sort of bot. Most of the downloads for that RPM occurred on February
22nd
Anyway, it is important that 2.4.x be stable from now on. We've had a number
of hiccups from my removal of import string which caused breakage for
projects like Boa that assumed modules would be available because it used
"from wxPython.wx import *" to the latest True/False changes. There were
also some behavioral changes mentioned, at least on Linux, if I remember
correctly.
Comments? It would also be nice to document in one place the API and
behavioral changes from 2.3.x to 2.4.x to encourage people to upgrade. We've
taken the first steps to build trust in future releases of wxPython, so what
else do we need to do?
ka
···
-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Wednesday, March 19, 2003 11:12 PM
To: wxPython-dev@lists.wxwindows.org
Subject: [wxPython-dev] wxPython 2.4.0.7 preview
Please download and test in a variety of situations. Other than the
true/false thing and some other bug fixes nothing much has changed since
.6 so I don't expect any new problems, but you never know...
Here's the changes:
2.4.0.7
-------
Gave up on generating a warning upon the use of the old true/false or
TRUE/FALSE values.
Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
that it can successfully handle lots of nodes instead of overflowing
when the virtual height of the widget overflowed a 16-bit value.
Fixed the typemap that converts strings to wxColours to also accept
unicode.
Fixed problem where the wrong class name could sometimes be used for
OOR.
Fixed an interpreter lock problem in the __eq__ and __ne__ methods in
wxSize and etc.
--
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 tested this release against the demo and my own app, and all seems OK. I used an old version of my app from November to ensure that I hadn't changed any of the true/false values, etc. Looks good from this end!
Thanks,
Kevin
···
On Wednesday, March 19, 2003, at 11:11 PM, Robin Dunn wrote:
Please download and test in a variety of situations. Other than the true/false thing and some other bug fixes nothing much has changed since .6 so I don't expect any new problems, but you never know...
Here's the changes:
2.4.0.7
-------
Gave up on generating a warning upon the use of the old true/false or
TRUE/FALSE values.
Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
that it can successfully handle lots of nodes instead of overflowing
when the virtual height of the widget overflowed a 16-bit value.
Fixed the typemap that converts strings to wxColours to also accept
unicode.
Fixed problem where the wrong class name could sometimes be used for
OOR.
Fixed an interpreter lock problem in the __eq__ and __ne__ methods in
wxSize and etc.
--
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
2.4.0.7
-------
Gave up on generating a warning upon the use of the old true/false or
TRUE/FALSE values.
Fixed wxGenericTreeCtrl (used on wxGTK and wxMac for wxTreeCtrl) so
that it can successfully handle lots of nodes instead of overflowing
when the virtual height of the widget overflowed a 16-bit value.
I like being able to scroll through the whole wx namespace in the
PyFilling tree. Nice fix!
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
I tested this release against the demo and my own app, and all seems OK. I used an old version of my app from November to ensure that I hadn't changed any of the true/false values, etc. Looks good from this end!
Unless somebody comes up with a showstopper in the meantime I plan on starting to build final binaries tomorrow.
Are there any contribs that still need to be updated? Patrick has there been any changes to PyCrust since the version I have now (0.9b I think)?
BTW, I don't know if Roman is on this list or not, but I just got some updates for XRCed that are real awesome! Good job!
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Kevin Ollivier wrote:
> Hi Robin,
>
> I tested this release against the demo and my own app, and all
seems OK.
> I used an old version of my app from November to ensure that I hadn't
> changed any of the true/false values, etc. Looks good from this end!
>
Unless somebody comes up with a showstopper in the meantime I plan on
starting to build final binaries tomorrow.
Just as a logistical point it seems like it would be best if the installers
we test are the actual distributions that will be made public, only the name
of the actual installer file should be different and maybe not even that. If
you end up having to make yet another build after initial tests then that is
more work for you, it introduces the possibility of changes and errors and
it introduces at least another day in the release process without any real
benefits.
Once you freeze a release for testing there shouldn't be any changes to cvs
in the release tree until the public release unless a bug is identified and
fixed which would start the pre-release check process over.
It is partly the "minor tweaks" that got us into trouble earlier.
Does that make sense?
Are there any contribs that still need to be updated? Patrick has there
been any changes to PyCrust since the version I have now (0.9b I think)?
BTW, I don't know if Roman is on this list or not, but I just got some
updates for XRCed that are real awesome! Good job!
Only Patrick, Kevin, and I reported in. Are we the only ones besides Robin
doing any checks?
> From: Robin Dunn [mailto:robin@alldunn.com]
>
> Unless somebody comes up with a showstopper in the meantime I plan on
> starting to build final binaries tomorrow.
Just as a logistical point it seems like it would be best if the installers
we test are the actual distributions that will be made public, only the name
of the actual installer file should be different and maybe not even that. If
you end up having to make yet another build after initial tests then that is
more work for you, it introduces the possibility of changes and errors and
it introduces at least another day in the release process without any real
benefits.
Once you freeze a release for testing there shouldn't be any changes to cvs
in the release tree until the public release unless a bug is identified and
fixed which would start the pre-release check process over.
It is partly the "minor tweaks" that got us into trouble earlier.
Does that make sense?
Yes, and I agree. Here is what I'd like to see happen. I'd like to see
a message saying you intend to do a release and we have X amount of
time (one day?) to submit any changes. That gives me time to finalize
any PyCrust stuff and make sure it is clean and ready to ship. I also
like to tag the files in CVS with the version number. For example, I
just did this:
cvs tag PyCrust-0-9
That gives you a marker to work with and lets me know exactly what
version of the files are going into wxPython.
At the appointed hour you build the release and let us know about
it. We download and test it. After some period of time without
problems, you make a simple name change and release it to the wxPython
community at large. If there are problems, we repeat this process.
I also plan to rig CVS to send email to a PyCrust-cvs list so that you
and others have a better idea when commits take place in the PyCrust
CVS repository.
How does that sound? (Hopefully not too burdensome.)
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Are there any contribs that still need to be updated? Patrick has
there been any changes to PyCrust since the version I have now (0.9b I
think)?
Yes, including some changes to keep compatible with Python 2.1. So get
the latest from CVS. Actually, since this may be a stable release for
a while, I may drop the letter from the version and consider this 0.9
final. In fact, I just did and I also tagged the files:
cvs tag PyCrust-0-9
Thanks.
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Just as a logistical point it seems like it would be best if the installers
we test are the actual distributions that will be made public, only the name
of the actual installer file should be different and maybe not even that. If
you end up having to make yet another build after initial tests then that is
more work for you, it introduces the possibility of changes and errors and
it introduces at least another day in the release process without any real
benefits.
That thought crossed my mind too, but for the most part my build scripts get the version number for the file names from the same place that wxPython gets it from, setup.py. That can be changed for some of them, but the RPMs need to use the real version number.
So what I decided to do instead is use the p1,p2,... suffix on the preview releases and then the release cantidate (only one of them if all goes well) will use the real version number. The release cantidate will have all binaries built, but the previews will just be one or two binaries to help reduce the load.
Since the builds are almost fully automated doing a rebuild with only a version number change should result in an otherwise identical binary.
Once you freeze a release for testing there shouldn't be any changes to cvs
in the release tree until the public release unless a bug is identified and
fixed which would start the pre-release check process over.
Yep.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Please download and test in a variety of situations. Other than the
true/false thing and some other bug fixes nothing much has changed since
.6 so I don't expect any new problems, but you never know...
I've been using 2.4.0.7p1 with Boa the whole of today and everything
works great for me too so far.
I can also confirm that the typemap issues are fixed.
Kevin Altis wrote:
>
> Just as a logistical point it seems like it would be best if
the installers
> we test are the actual distributions that will be made public,
only the name
> of the actual installer file should be different and maybe not
even that. If
> you end up having to make yet another build after initial tests
then that is
> more work for you, it introduces the possibility of changes and
errors and
> it introduces at least another day in the release process
without any real
> benefits.
That thought crossed my mind too, but for the most part my build scripts
get the version number for the file names from the same place that
wxPython gets it from, setup.py. That can be changed for some of them,
but the RPMs need to use the real version number.
So what I decided to do instead is use the p1,p2,... suffix on the
preview releases and then the release cantidate (only one of them if all
goes well) will use the real version number. The release cantidate will
have all binaries built, but the previews will just be one or two
binaries to help reduce the load.
Since the builds are almost fully automated doing a rebuild with only a
version number change should result in an otherwise identical binary.
Hmm, that isn't giving me a warm fuzzy feeling. So what if you just use the
real numbers, and only make the binaries available from the alldunn.com
server? There will never be p1, p2, etc. suffixes. If we need to tell the
difference between a 2.4.0.7 made yesterday and another today (after a bug
fix), the file size as well as a MD5 or other signature would let us testing
fools know what we're dealing with.
I also plan to rig CVS to send email to a PyCrust-cvs list so that you
and others have a better idea when commits take place in the PyCrust
CVS repository.
This is done. The list info is available here:
Please subscribe if you want to be notified of PyCrust cvs commits.
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
That thought crossed my mind too, but for the most part my build scripts
get the version number for the file names from the same place that
wxPython gets it from, setup.py. That can be changed for some of them,
but the RPMs need to use the real version number.
So what I decided to do instead is use the p1,p2,... suffix on the
preview releases and then the release cantidate (only one of them if all
goes well) will use the real version number. The release cantidate will
have all binaries built, but the previews will just be one or two
binaries to help reduce the load.
Since the builds are almost fully automated doing a rebuild with only a
version number change should result in an otherwise identical binary.
Hmm, that isn't giving me a warm fuzzy feeling. So what if you just use the
real numbers, and only make the binaries available from the alldunn.com
server? There will never be p1, p2, etc. suffixes. If we need to tell the
difference between a 2.4.0.7 made yesterday and another today (after a bug
fix), the file size as well as a MD5 or other signature would let us testing
fools know what we're dealing with.
My one worry with this is that after the final release there will be no way to tell at runtime the difference between the final release and an eary preview release (other than the bugs that were fixed for the final.) I expect that it could lead to unnecessary confusion.
Perhaps another possibility is to always increment the micro-micro (or is it "nano"? number for each build, preview and final. So the build I do tomorrow will be 2.4.0.8, will get put on alldunn.com and then will go up to SF if no problems are reported.
Any other ideas?
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
> Hmm, that isn't giving me a warm fuzzy feeling. So what if you just use
the
> real numbers, and only make the binaries available from the alldunn.com
> server? There will never be p1, p2, etc. suffixes. If we need to tell
the
> difference between a 2.4.0.7 made yesterday and another today (after a
bug
> fix), the file size as well as a MD5 or other signature would let us
testing
> fools know what we're dealing with.
My one worry with this is that after the final release there will be no
way to tell at runtime the difference between the final release and an
eary preview release (other than the bugs that were fixed for the
final.) I expect that it could lead to unnecessary confusion.
Perhaps another possibility is to always increment the micro-micro (or
is it "nano"? number for each build, preview and final. So the
build I do tomorrow will be 2.4.0.8, will get put on alldunn.com and
then will go up to SF if no problems are reported.
Any other ideas?
I personally like the p1, p2 approach best, because the different naming
scheme highlights that it is a preview release. I think whatever system we
choose, there should be some easy and consistent way to differentiate
between preview and final releases. I think incrementing the microscopic
build number could confuse people not familiar with the build system, as
(for example) 2.4.0.8-10 could be previews, and 2.4.0.11 could be a final.
Just looking at the number does not give a clear indication of what type of
build it is.
I think that as long as any "final-final" release gets a quick runthrough by
testers before it is made official, there is very little chance of surprises
getting introduced into a final release. I personally have found that having
someone else look at my code before sending it to 'the presses' uncovers
most problems rather quickly (especially if you have change notes for people
to review when testing), and any bug that cannot be uncovered by these tests
probably is rare enough that it will take a very specific set of
circumstances to uncover it.
I think even our current approach of peer review makes great strides towards
ensuring that no unexpected surprises make it into the final builds. My only
concern is if we're getting a good coverage of the different platforms at
this point. Kevin A and I are both testing on Windows (2000 and XP), and I'm
not sure what platforms the other two testers have been working on.
Thanks,
Kevin
···
----- Original Message -----
From: "Robin Dunn" <robin@alldunn.com>
To: <wxPython-dev@lists.wxwindows.org>
Sent: Thursday, March 20, 2003 4:20 PM
Subject: Re: [wxPython-dev] wxPython 2.4.0.7 preview
I think even our current approach of peer review makes great strides towards
ensuring that no unexpected surprises make it into the final builds. My only
concern is if we're getting a good coverage of the different platforms at
this point. Kevin A and I are both testing on Windows (2000 and XP), and I'm
not sure what platforms the other two testers have been working on.
My daily platform is Python 2.2.2 on Mandrake 9.0. Sometimes I boot
into Win98 and test with Python 2.2.2 and 2.1.3. But I'm growing tired
of maintaining compatibility with Python 2.1.3 and look forward to the
day I can drop it.
Any idea how many Python 2.1 users we've got versus 2.2 users?
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
My daily platform is Python 2.2.2 on Mandrake 9.0. Sometimes I boot
into Win98 and test with Python 2.2.2 and 2.1.3. But I'm growing tired
of maintaining compatibility with Python 2.1.3 and look forward to the
day I can drop it.
When 2.3 is released
Any idea how many Python 2.1 users we've got versus 2.2 users?
A very quick guess based on download stats, 2.1 has roughly 10-20% the numbers of 2.2.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
From: "Robin Dunn" <robin@alldunn.com>
To: <wxPython-dev@lists.wxwindows.org>
Sent: Thursday, March 20, 2003 4:20 PM
Subject: Re: [wxPython-dev] wxPython 2.4.0.7 preview
> Kevin Altis wrote:
[snip]
> > Hmm, that isn't giving me a warm fuzzy feeling. So what if you just use
the
> > real numbers, and only make the binaries available from the alldunn.com
> > server? There will never be p1, p2, etc. suffixes. If we need to tell
the
> > difference between a 2.4.0.7 made yesterday and another today (after a
bug
> > fix), the file size as well as a MD5 or other signature would let us
testing
> > fools know what we're dealing with.
>
> My one worry with this is that after the final release there will be no
> way to tell at runtime the difference between the final release and an
> eary preview release (other than the bugs that were fixed for the
> final.) I expect that it could lead to unnecessary confusion.
>
> Perhaps another possibility is to always increment the micro-micro (or
> is it "nano"? number for each build, preview and final. So the
> build I do tomorrow will be 2.4.0.8, will get put on alldunn.com and
> then will go up to SF if no problems are reported.
>
> Any other ideas?
I personally like the p1, p2 approach best, because the different naming
scheme highlights that it is a preview release. I think whatever system we
choose, there should be some easy and consistent way to differentiate
between preview and final releases. I think incrementing the microscopic
build number could confuse people not familiar with the build system, as
(for example) 2.4.0.8-10 could be previews, and 2.4.0.11 could be a final.
Just looking at the number does not give a clear indication of what type of
build it is.
Well, the whole question is: when do you know that you have a final? And
how do you differentiate between three different "what we thought were
finals" which turned out not to be? Do you have to rebuild everything
with a different "branding"? At my work we have gone through the same
issues for our product and have decided that a build # or timestamp is
needed for differentiating between different versions and the number
(2.4.0.8) for example is kept the same throughout the release. Perhaps
that is another idea?
On Thu, 2003-03-20 at 18:23, Kevin Ollivier wrote:
----- Original Message -----
I think that as long as any "final-final" release gets a quick runthrough by
testers before it is made official, there is very little chance of surprises
getting introduced into a final release. I personally have found that having
someone else look at my code before sending it to 'the presses' uncovers
most problems rather quickly (especially if you have change notes for people
to review when testing), and any bug that cannot be uncovered by these tests
probably is rare enough that it will take a very specific set of
circumstances to uncover it.
I think even our current approach of peer review makes great strides towards
ensuring that no unexpected surprises make it into the final builds. My only
concern is if we're getting a good coverage of the different platforms at
this point. Kevin A and I are both testing on Windows (2000 and XP), and I'm
not sure what platforms the other two testers have been working on.
Thanks,
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org
--
Anthony Tuininga
anthony@computronix.com
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838
Well, the whole question is: when do you know that you have a final? And
how do you differentiate between three different "what we thought were
finals" which turned out not to be? Do you have to rebuild everything
with a different "branding"? At my work we have gone through the same
issues for our product and have decided that a build # or timestamp is
needed for differentiating between different versions and the number
(2.4.0.8) for example is kept the same throughout the release. Perhaps
that is another idea?
Well, you have a final when there is no longer a 'p1, p2' etc. tag. A p tag
should be used for any release in which a new bug fix was added. This same
strategy is used for alpha and beta release testing in many open source
projects, and it is thus easily recognizable by users. (Using a beta marker
would be fine with me as well, BTW.)
Testing on the final version should happen only as an extra precaution in
case somehow a change makes its way in between the last preview and the
final build, but that could be avoided I think. (Especially if Robin, like
Patrick, is tagging the CVS version that will be released.)
I'm just concerned about Joe Public somehow getting ahold of one of the
preview builds. Under the other approaches mentioned, there'd be no clear
way to tell for 'Joe' to tell if he's got a preview or final release, unless
he's familiar with our build system. I think he'd be likely to assume he's
got a final, since there is nothing to tell him otherwise.
However, having said all that, if others do not feel that this will be a
problem, then I could go along with any of the other suggestions heard so
far.
Thanks,
Kevin
···
----- Original Message -----
From: "Anthony Tuininga" <anthony@computronix.com>
To: <wxPython-dev@lists.wxwindows.org>
Sent: Friday, March 21, 2003 6:48 AM
Subject: Re: [wxPython-dev] wxPython 2.4.0.7 preview
On Thu, 2003-03-20 at 18:23, Kevin Ollivier wrote:
> ----- Original Message -----
Frankly that seems pretty clunky, but it should work, and it used to,
but when I upgraded to 2.4.0, I got a weird result. I got what looks
like Chinese characters to me, apparently a different font altogether.
If I only multiply the font size by 1.5, it works OK. I've enclosed a
screen shot of a test, where I create 3 StaticTexts, one normal, one
with the font 1.5 times normal, and one with it twice. You can see the
problem. In the code I printed out some font properties:
Font info: Label1
GetFaceName :
GetFamily : 74
GetNativeFontInfoDesc: 0;-*-*-*-*-*--*-*-*-*-*-*-*-*
GetPointSize : 12
GetStyle : 90
Font info: Label2
Font info
GetFaceName :
GetFamily : 74
GetNativeFontInfoDesc: 0;-*-*-*-*-*--*-180-*-*-*-*-*-*
GetPointSize : 18
GetStyle : 90
Font info: Label2
Font info
GetFaceName :
GetFamily : 74
GetNativeFontInfoDesc: 0;-*-*-*-*-*--*-240-*-*-*-*-*-*
GetPointSize : 24
GetStyle : 90
Reading X font specifications is a little beyond me, but it looks like
it should have gone from default to 180 to 240 in size, and the
GetPointsize value looks fine. I'm also not getting any value from
GetFaceName(), which is a little odd.
I've also enclosed the code, any hints would be great.
I"ve noticed that on my Linux box and Windows, I get very different
sizes of fonts, when specifying the same size. I suspect that the
problem is that GTK and Windows have different ideas as to how many
pixels-per-inch my screen is. Personally, I'd much rather specify fonts
in pixel sizes, rather than points, but so be it. My question is: can I
find out how many ppi wxWindows thinks the screen is, so I can choose
the appropriate font size to give me the pixel size I know I want?
-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