parc-leopard-1 (and most of the other builders) are failing the svn
checkout with the following error:
svn: PROPFIND of '/projects/python/trunk': Could not resolve hostname `svn.python.org': Temporary failure in name resolution (http://svn.python.org)
When I log into that machine as "buildbot" and do the svn checkout
manually using the following command
/usr/bin/svn checkout --non-interactive --no-auth-cache --revision HEAD http://svn.python.org/projects/python/trunk build
it works fine.
Bill
>
> > So I'm thinking either we make an
> > immutable/hashable dict while we're at it, or store the keyword
> > arguments as a tuple (which guarantees immutability), and only
> > convert them back to a dict when you want to call the partial object
> > (simpler, slower).
>
> I'd support an immutable dict. [...]
I've set out to implement a frozendict (like frozenset) for use to store
functools.keywords' attribute, and quickly realized I didn't think of an
obvious flaw in that idea. A frozenset will only accept hashable members,
but a frozendict can't afford this luxury for its values.
I'm not sure how should I go about handling that, if at all. Should I
implement a frozendict which will remain unhashable but support equality
testing like a regular dict? A frozendict that is only hashable if all its
values are hashable, like a tuple? Is the whole notion of a frozendict
worthy, given this limitation?
I'd be happy to hear python-dev's guidance on this.
Cheers,
- Yaniv
Hello,
The buildbots are sometimes subject to a flood of "svn exception"
errors. It has been conjectured that these errors are caused by Web
crawlers pressing "force build" buttons without filling any of the
fields (of course, the fact that we get such ugly errors in the
buildbot results, rather than a clean error message when pressing
the button, is a buildbot bug in itself). Couldn't we simply exclude all
crawlers from the buildbot Web pages?
Regards
Antoine.
Hello All,
Meebo is looking for a bright, fun, dedicated software engineer who's
interested in supporting a growing revenue team, loves a good challenge, and
wants to learn about how advertising operations works from the inside out.
In this role, you will be responsible for implementing and maintaining
critical tools that support the ongoing adops infrastructure, ranging from
content acquisition to ad inventory management. As a developer on the ads
team, you'll be exposed to many business functions and you'll support and
develop tools and systems to streamline the entire process. Our team is fun,
friendly, and willing to work really hard to meet our goals. We love a great
user experience, internal and external.
*Responsibilities:*
- Work with ads team to create and maintain mission critical support
tools
- Work closely with Sales and Marketing teams to elicit feedback from
partners
- Design and implement partner facing tools
- Participate in product meetings to determine necessary systems
- Scale and optimize with a growing revenue stream
- Interface with both server and client side teams to leverage existing
tools
*What you will need:*
- 3-5+ years of software engineering experience in Linux/Unix
- BS, MS in Computer Science (or equivalent)
- Strong expertise in Python, Perl, php, or other scripting languages
- Knowledge of Django, PIG a plus
- Database experience a plus
- Ability to work with technical and non-technical teams, in an extremely
fast-paced environment
- Strong UI design sense with the ability to adapt, take critical
feedback, and execute quickly on tasks
*Big pluses:*
- Experience working with large scale systems
- Experience working with ad ops industry tools such as: Doubleclick,
Atlas, 24/7, Salesforce, Dart Sales Manager, Solbright, Operative
If at all interested OR know someone who might be interested please reply
here Kiko(a)meebo-inc.com.
Thanks,
Kiko Griffin
kiko(a)meebo-inc.com
I've got parc-tiger-1 up and running again. It's failing on test_tk,
which makes sense, because it's running as a background twisted process,
and thus can't access the window server. I should configure that out.
I'm looking for documentation on how to configure the build slave so
that it skips this test.
Bill
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[Zlib-devel] HEADS UP: Apparent bad compilation under (just released)
GCC 4.5.0
<http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002267.html>
GCC Bugzilla Bug 40838
gcc shouldn't assume that the stack is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
Short history: new GCC 4.5.0 (released a month ago), when compiling with
- -O3, is adding MMX/SSE instructions that requires stack aligned to 16
byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes.
If you compile EVERYTHING with GCC 4.5.0, you are safe (I guess!), but
if your environment has mixed compiled code (for instance, the OS
libraries), you can possibly "core dump". If you have an old compiled
Python and you update libs compiled with GCC 4.5.0, you can crash in the
process.
Psyco is showing the issue, but it is not the culprit. It only leaves
- -correctly- the stack in not 16-byte alignment. But there are plenty of
examples of crashes not related to python+psyco.
Proposal: add "-fno-tree-vectorize" to compilation options for 2.7/3.2.
Warm 2.3/2.4/2.5/2.6/3.0/3.1 users. Or warm users compiling with GCC 4.5.0.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS+qpcZlgi5GaxT1NAQLAjgP/anZ5C2lED190++ffcluApF3ASF20iSnH
t21ynHxrz2fgkPeOxeGRAqGEGCc3jZ0UuXchECcLLzFhI8WQS8K766EOgOKdwZLV
WCt0ohWZ0FfsJZX4J5Y73x39uhjShbnl6SSek2uEvPi/tua/R4W/kVXrAZ0ZZR6/
vRqSUXpdolM=
=5K+S
-----END PGP SIGNATURE-----
Hello,
The untabification of C files didn't produce any noticeable problem on
the buildbots. I've updated PEP 7 with the mention that all C files
should be 4-space indented, and removed the obsolete wording about
some files being indented with tabs.
Regards
Antoine.
Howdy folks,
Quick e-mail at 34,000ft (aren't wifi-enabled flights great?) to mention
a new initiative that's been started by Microsoft called CoApp (Common
Opensource Application Publishing Platform). The aim is simple: make
open source software rock on Windows ;-)
It's probably easiest to think of it as a
Microsoft-endorsed-but-community-run open source distribution for
Windows, akin to all the various package managers for Linux
distributions and ports/packages for the *BSDs. There are specific user
and developer experiences we'll be addressing -- like making it easy to
install and use open source software, or use it within your own project
(open source or not).
CoApp will affect Python in one of two ways. Once there's a clear-cut
specification for open source projects to follow, Python can either
decide to follow it, or not. The same applies to all open source
packages, actually. For those that follow it, great! If not, no
problem -- the plan is to shallow-fork such projects via launchpad and
the CoApp community will take responsibility for getting releases of
open source projects into CoApp shape.
It's in its infancy at the moment -- it took the chap (Garrett Serack)
who's spearheading it at Microsoft about six months to get it all signed
off by the lawyers and platform/server VPs.
So, for those of you out there who are Windows-inclined, now's a perfect
time to get involved to help shape the direction of CoApp going forward.
The website/wiki is http://coapp.org/ and the launchpad project site is
http://launchpad.net/coapp (which is where the mailing list is hosted).
We're actually having a 'CoApp Development Summit' tomorrow and Friday
in Seattle (that Microsoft's graciously sponsored). The event will be
accessible via Live Meeting for those that are interested:
http://coapp.org/Project_Planning/CoApp_Design_and_Development_Summit
Regards,
Trent.
