Pheonix buildbot update

14 views
Skip to first unread message

Robin Dunn

unread,
Apr 19, 2012, 2:02:46 PM4/19/12
to wxpyth...@googlegroups.com
Hi all,

Just a quick note to let you know that I've been working on getting the
Phoenix buildbot doing more for us than just a simple build on a single
platform. It's now got build slaves on OSX, Windows and Ubuntu. I've
also added builders that will run once daily for making a tarball with
binaries for OSX[1] and Windows, and also a once daily builder that will
build the docs[2] and make a tarball of them.

You can view the buildbot waterfall, build logs, etc. at
http://buildbot.wxpython.org:8010. The tarballs are uploaded to
http://wxpython.org/Phoenix/snapshot-builds/ after they have been created.

[1] There are no new OSX binaries on the server yet as that build slave
had a problem which has just been resolved. I'll trigger a new dist
build once the current normal build succeeds.

[2] Just the docs for the core modules are being built so far since
wx.lib and etc. hasn't been copied into the Phoenix source tree yet.

--
Robin Dunn
Software Craftsman
http://wxPython.org

jmfauth

unread,
May 16, 2012, 3:57:24 PM5/16/12
to wxPython-dev


On 19 avr, 20:02, Robin Dunn <ro...@alldunn.com> wrote:
> Hi all,
>
> Just a quick note to let you know that I've been working on getting the
> Phoenix buildbot doing more for us than just a simple build on a single
> platform.  It's now got build slaves on OSX, Windows and Ubuntu.  I've
> also added builders that will run once daily for making a tarball with
> binaries for OSX[1] and Windows, and also a once daily builder that will
> build the docs[2] and make a tarball of them.
>
> You can view the buildbot waterfall, build logs, etc. athttp://buildbot.wxpython.org:8010.  The tarballs are uploaded tohttp://wxpython.org/Phoenix/snapshot-builds/after they have been created.
>
> [1] There are no new OSX binaries on the server yet as that build slave
> had a problem which has just been resolved.  I'll trigger a new dist
> build once the current normal build succeeds.
>
> [2] Just the docs for the core modules are being built so far since
> wx.lib and etc. hasn't been copied into the Phoenix source tree yet.
>
> --
> Robin Dunn
> Software Craftsmanhttp://wxPython.org

I am afraid, it is completely wrong by design. And it
is.

For some reasons I can not explain, there is in this "coding of
the characters" field, something you do not get correctly.

If Xe(La)TeX were working in that way, it would be impossible
to produce a piece of text -- documents -- correctly. Why XeTeX
as exemple? To take something different and interestingly XeTeX is
working exactly as Python does!

I see and foresee what you are doing and expecting. Unfortunately,
it is impossible. You do not deeply realize this.

Among other things, you have wrongly reimplemented something
that Python (2) is already able to do. And it does it correctly!

from __future__ import unicode_literals

jmf

Chris Barker

unread,
May 17, 2012, 11:58:07 AM5/17/12
to wxpyth...@googlegroups.com
On Wed, May 16, 2012 at 12:57 PM, jmfauth <wxjm...@gmail.com> wrote:
> I am afraid, it is completely wrong by design. And it
> is.
>
> For some reasons I can not explain, there is in this "coding of
> the characters" field, something you do not get correctly.

if you can't explain it -- no one can offer solutions -- so please
give an explaination a try!

> Among other things, you have wrongly reimplemented something
> that Python (2) is already able to do. And it does it correctly!
>
> from __future__ import unicode_literals

how is that relevant -- wx doesn't change python sysntax or parsing --
what that does is essentially add the "u" before the "" automatically
-- handy, and really only required for 2to3 compatibility, but I can't
see how this changes how wx handles encoding.

-Chris


--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

Kevin Ollivier

unread,
May 17, 2012, 12:04:45 PM5/17/12
to wxpyth...@googlegroups.com
So wxPython has a different idea than you of how to handle the encodings issue. Get over it. It isn't perfect but the encoding conversion works for a whole lot of code out there in order to make transitioning to unicode less painful, and that's precisely what it was designed to do. Python 3 support, high on the TODO list, will greatly improve the unicode situation and reduce conversions quite considerably.

Unless you've got some real bugs to report, rather than just repeating "I wouldn't have done it this way" in so many words, please, give the ranting a rest. All you're doing is annoying people with these vague emails that all say nothing more specific than "I know all this stuff better than you do". This is neither a bug report nor constructive criticism.. nor, I might add, helpful. It is simply a condescending rant. If you really think these condescending rants are an effective a way to get people to listen to you, I encourage you to keep trying and see how that works out for you. I know I, for one, am tired of hearing it, and about ready to start sending your emails straight to /dev/null.

There are plenty of real problems and injustices in the world far more deserving of the level of attention and frustration you show on this issue.

Regards,

Kevin

> jmf
>
> --
> To unsubscribe, send email to wxPython-dev...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-dev?hl=en

jmfauth

unread,
May 18, 2012, 5:51:46 AM5/18/12
to wxPython-dev


On 17 mai, 17:58, Chris Barker <chris.bar...@noaa.gov> wrote:

> if you can't explain it -- no one can offer solutions -- so please
> give an explaination a try!
>


It was some kind of a raw warning. I'm aware of this.

I do not wish to enter again in a discussion, which
will quickly and as usually turn into a great confusion.

jmf


Reply all
Reply to author
Forward
0 new messages