On Sat, Oct 02, 2010 at 10:37:40PM +0200, "Martin v. Löwis" wrote:
> > I'm already running a Jython buildslave on an Intel Mac Pro which is
> > pretty underused - I'd be happy to run a CPython one there too, if
> > it'd be worthwhile.
>
> I think Bill was specifically after Snow Leopard - what sys
On Sun, Oct 3, 2010 at 9:00 AM, R. David Murray wrote:
> I do not propose that this is a *good* API, since it has the classic
> problem that if there are coding bugs in the email module strings may
> "escape" that have surrogates in them and we end up with programs that
> work most of the time
On Sat, 02 Oct 2010 19:15:57 -0500, Benjamin Peterson
wrote:
> 2010/10/2 R. David Murray :
> > Regardless of whether or not this patch or a descendant thereof is
> > accepted I still intend to continue working on email6. =C2=A0There are ma=
> ny
> > other bugs in the current email package that re
On Oct 2, 2010, at 11:50 AM, Bill Janssen wrote:
Perhaps we could get Apple to contribute some "seconds"?
If you don't get a good solution soon, let me know off-list and I'll
see if Apple can help.
Cheers,
--
Ivan Krstić | http://radian.org
___
On Sat, Sep 25, 2010 at 1:36 AM, James Y Knight wrote:
>
> An OSX code sketch is available here (summary: call FSPathMakeRef to get an
> FSRef from a path string, then FSRefMakePath to make it back into a path,
> which will then have the correct case). And note that it only works if the
> file act
2010/10/2 R. David Murray :
> Regardless of whether or not this patch or a descendant thereof is
> accepted I still intend to continue working on email6. There are many
> other bugs in the current email package that require a rewrite of parts
> of its infrastructure, and the email-sig is agreed th
A while back on some issue or another I remember telling someone that
if there was any sort of clever hack that would allow the current email
package (email5) to work with bytes we would have implemented it.
Well, I've come up with a clever hack.
The idea came out of a conversation with Antoine.
On Sat, Oct 02, 2010 at 10:08:09PM +0200, "Martin v. Löwis" wrote:
> > Surely someone could volunteer an old Intel Mac to run some tests?
> > (Actually, two someones -- we'd need separate machines for Leopard and
> > Snow Leopard.) I'd be happy to stick it in a server room at PARC and
> > keep an
> 1) who is the notification e-mail sent to when a review is published?
I haven't figured that out yet. I'm not even sure whether email gets
sent at all. I'll look into this a week from now, unless someone
resolves that earlier. But...
> I
> just tried on one of my patches and the e-mail came wit
Le samedi 02 octobre 2010 à 22:55 +0200, "Martin v. Löwis" a écrit :
>
> > 2) if I look at http://bugs.python.org/issue9962, only the second patch
> > of all three has been enabled for review. Yet they were all created
> > through "svn diff" against a recent py3k checkout.
>
> They had both the s
Am 02.10.2010 22:42, schrieb Jesus Cea:
> On 30/09/10 22:41, Brett Cannon wrote:
>> Don't see why not, but those of us who use OpenID would need to start
>> caring about a password which would be unfortunate.
>
> +1. OpenID or OAuth is a must.
>
> Moreover, I am a bit worried of needing a google
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/09/10 22:41, Brett Cannon wrote:
> Don't see why not, but those of us who use OpenID would need to start
> caring about a password which would be unfortunate.
+1. OpenID or OAuth is a must.
Moreover, I am a bit worried of needing a google accou
> I'm already running a Jython buildslave on an Intel Mac Pro which is
> pretty underused - I'd be happy to run a CPython one there too, if
> it'd be worthwhile.
I think Bill was specifically after Snow Leopard - what system are you
using?
Regards,
Martin
Hello,
On Sat, 02 Oct 2010 22:03:57 +0200
"Martin v. Löwis" wrote:
> Following up to the recent thread, I have now integrated Rietveld
> into Roundup. This is a rough draft still, and highly experimental.
> Please try it out, but expect that it may be necessary to discard
> all data (including c
On Sat, 02 Oct 2010 22:14:28 +0200
Jesus Cea wrote:
>
> My idea is to convert the CObject exception in bsddb to print a warning
> like "CObject creation failed. The bsddb.cAPI will be not available.
> Reason is: ".
>
> Is there a "canonical way" of doing this?. Sorry if the answer is trivial
Thanks for this. It looks very nice.
2010/10/2 "Martin v. Löwis" :
> Following up to the recent thread, I have now integrated Rietveld
> into Roundup. This is a rough draft still, and highly experimental.
> Please try it out, but expect that it may be necessary to discard
> all data (including co
On Sat, Oct 2, 2010 at 1:16 PM, Alan McIntyre wrote:
> I have an Intel Core 2 Duo Mac that I was going to convert into a home
> file server in the next couple of weeks, and I'd be glad to set it up
> as a build slave as well. I don't remember what version of OS X it
> has on it (it's still packed
I have an Intel Core 2 Duo Mac that I was going to convert into a home
file server in the next couple of weeks, and I'd be glad to set it up
as a build slave as well. I don't remember what version of OS X it
has on it (it's still packed up in the box), but it certainly won't be
the latest one.
On
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/09/10 18:00, Antoine Pitrou wrote:
> By "fails" you mean "crashes the interpreter".
> While the deprecation warning can be discussed, bsddb shouldn't crash
> when PyCObject_FromVoidPtr() returns NULL, but instead bail out
> cleanly (or perhaps ev
> Surely someone could volunteer an old Intel Mac to run some tests?
> (Actually, two someones -- we'd need separate machines for Leopard and
> Snow Leopard.) I'd be happy to stick it in a server room at PARC and
> keep an eye on it. (Right now I've got a rack full of old eMacs and a
> G5 running
Following up to the recent thread, I have now integrated Rietveld
into Roundup. This is a rough draft still, and highly experimental.
Please try it out, but expect that it may be necessary to discard
all data (including comments) to start over (of course, I'll try
to avoid having to do so).
The Ri
Folks, I was looking at the buildbots again. Do you realize that we
have no OS X Snow Leopard buildbot? No Intel Leopard buildbot? Well
over half of Mac users are using Snow Leopard, and we're not testing on
that platform. In fact, the only Intel OS X machine we're testing on
is a Core Duo, not
I've finished upgrading the PPC Leopard builder to a dual 2 GHz G5
machine. Tests should run a bit faster now that the eMac is out of the
loop :-). I'm looking for a faster machine for the PPC Tiger buildbot.
Bill
___
Python-Dev mailing list
Python-Dev
On Sat, 02 Oct 2010 09:44:16 +0200
"Martin v. Löwis" wrote:
>
> I could accept that a suffix is parameter to configure (or some such),
> and then gets used throughout. By default, Python will not add a suffix.
> However, I still wonder why people couldn't just install Python in a
> different pref
Am 02.10.2010 00:06, schrieb Barry Warsaw:
> Let's say I build the foo module, which has an _foo extension for both the
> 3.2m and 3.2dmu builds. Everything gets installed correctly, and you'll see:
>
> lib/python3.2/site-packages/foo-...egg/_foo.cpython-32m.so
> lib/python3.2/site-packa
>>> With my branch, you'll end up with this in /tmp/python:
>>>
>>> bin/python3.2m - the normal build binary
>>> bin/python3.2dmu - the wide+pydebug build binary
>>> bin/python3.2m-config
>>> bin/python3.2dmu-config
>>
>> Do users really want to see such idiosyncratic suffixes?
>
26 matches
Mail list logo
