Brett Cannon schrieb:
> I just tried to update my 3.0 branch in hg from
> http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
> 404. Anyone else having trouble?
404 here too.
Since http://code.python.org/ serves the loggerhead Bazaar view, I suppose
the problem is that the logger
Georg Brandl wrote:
Brett Cannon schrieb:
I just tried to update my 3.0 branch in hg from
http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
404. Anyone else having trouble?
404 here too.
Since http://code.python.org/ serves the loggerhead Bazaar view, I suppose
the problem
On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Neil Schemenauer wrote:
>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
>>> For a student project in a course on virtual machines, we are
>>> evaluating the possibility to experiment with removing the GIL
>>> from CPy
Adam Olsen wrote:
> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Neil Schemenauer wrote:
>>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
For a student project in a course on virtual machines, we are
evaluating the possibility to experiment with remov
On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>> What about having two level of devs ?
>>
>> + core developers + standard library developers
>>
>> [cut]
>
>
> So I'd suggest thinking about developer responsibilities more in terms
> of areas of expertise rather than "le
On Fri, Oct 31, 2008 at 2:11 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>> Neil Schemenauer wrote:
Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
> For a student project in a course on vi
>> Yet another hint at the evil force-Bazaar-upon-them conspiracy .
>
> I'm not so sure Bazaar isn't it's own victim :)
I have now restored the original URL structure, and moved the loggerhead
installation to
http://code.python.org/loggerhead/
Regards,
Martin
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 08:44 AM, Georg Brandl wrote:
>Brett Cannon schrieb:
>> I just tried to update my 3.0 branch in hg from
>> http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
>> 404. Anyone else having trouble?
>
>404 here too.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 08:58 AM, Barry Warsaw wrote:
>Naw, I think I just f'd up the Apache conf. I'll try to fix that.
And by "I'll" of course I meant "Martin". :)
Thanks Martin!
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 03:50 AM, Eric Smith wrote:
>I posted this yesterday about using bzr:
>
> >I'd like to try it out, but the instructions on
> > http://www.python.org/dev/bazaar/ say to get wget
> > http://code.python.org/snapshots/python-bzr-snapsh
> Looks like it should be
>
> http://code.python.org/loggerhead/static/images/ico_folder.gif
I did a quick hack for the static files, but many of the links still
don't work. loggerhead has specific support for reverse proxies
(through loggerhead.conf), but I couldn't figure out how to activat
Has anyone made the argument for keeping the GIL to discourage
threading? I'm only throwing this out there and I'm sure we'd want to
improve things no matter what, but I would like to voice the concern
anyway. We all know there are people who think threading is the answer
to all things, and who don
> A couple nits. Leaving off the trailing / yields a 404. (No big deal
> though). More importantly, there seem to be no images, e.g.:
>
> http://code.python.org/static/images/ico_folder.gif
>
> Looks like it should be
>
> http://code.python.org/loggerhead/static/images/ico_folder.gif
Martin> I have now restored the original URL structure, and moved the
Martin> loggerhead installation to
Martin> http://code.python.org/loggerhead/
A couple nits. Leaving off the trailing / yields a 404. (No big deal
though). More importantly, there seem to be no images, e.g.:
On Fri, Oct 31, 2008 at 07:59:01AM -0400, Calvin Spealman wrote:
> Has anyone made the argument for keeping the GIL to discourage
> threading?
I haven't, but I would support such argument. In my humble opinion
multithreading is rarely a good answer, and for multicore CPUs it's a wrong
answer. F
Alexandre Vassalotti wrote:
But what if PyType_GenericAlloc is used for tp_alloc? As far as I
know, the memory block allocated with PyType_GenericAlloc is zeroed.
Oh, you are right. The generic allocator uses memset to initialize the
block with \0.
Christian
_
Nick Coghlan wrote:
If I recall correctly, the main blocker to ctypes portability is libffi
portability. So if anyone would like to see ctypes on more platforms,
then that's the limitation they really need to attack.
ctypes is also missing utilities to write code that works on 32 and
64bit pla
Calvin Spealman wrote:
Has anyone made the argument for keeping the GIL to discourage
threading? I'm only throwing this out there and I'm sure we'd want to
improve things no matter what, but I would like to voice the concern
anyway. We all know there are people who think threading is the answer
t
Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit :
> ctypes is also missing utilities to write code that works on 32 and
> 64bit platforms. Without a tool like
> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
> to avoid and fix segfaults.
I wrote some c
On Fri, Oct 31, 2008 at 9:17 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
>>
>> Has anyone made the argument for keeping the GIL to discourage
>> threading? I'm only throwing this out there and I'm sure we'd want to
>> improve things no matter what, but I would like to voic
Calvin> Has anyone made the argument for keeping the GIL to discourage
Calvin> threading? I'm only throwing this out there and I'm sure we'd
Calvin> want to improve things no matter what, but I would like to voice
Calvin> the concern anyway. We all know there are people who think
Christian Heimes schrieb:
> Nick Coghlan wrote:
>> If I recall correctly, the main blocker to ctypes portability is libffi
>> portability. So if anyone would like to see ctypes on more platforms,
>> then that's the limitation they really need to attack.
>
> ctypes is also missing utilities to writ
Victor Stinner schrieb:
> Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit :
>> ctypes is also missing utilities to write code that works on 32 and
>> 64bit platforms. Without a tool like
>> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
>> to avoid and
On Fri, Oct 31, 2008 at 4:59 AM, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Has anyone made the argument for keeping the GIL to discourage
> threading?
Oooh, you are on to my secret plan! :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
> I have a similar list that I have been thinking about proposing. I did
> a blog post about it at
> http://sayspy.blogspot.com/2008/08/what-are-typical-steps-issue-goes.html
> and received positive feedback:
>
> * triage
> * verify bug
> * test needed
> * needs patch
> * patch review
> * commit re
> But we need also some hooks to automate stage changes:
> * attach a new patch => set stage to "patch review"
>(and maybe add the keyword "review")
The latter already happens automatically.
> * remove "patch reviewed" keyword => set stage to "commit review"
> * set status to "closed" => s
ACTIVITY SUMMARY (10/24/08 - 10/31/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2153 open (+33) / 13915 closed (+19) / 16068 total (+52)
Open issues with patches: 705
Average
>> Has anyone made the argument for keeping the GIL to discourage
>> threading?
>
> Oooh, you are on to my secret plan! :-)
I completely agree that there are other approaches to parallelism and
concurrency that are much better than threading. However, I don't
think this is a good argument for hav
On Fri, Oct 31, 2008 at 11:55 AM, Brian Granger <[EMAIL PROTECTED]> wrote:
>>> Has anyone made the argument for keeping the GIL to discourage
>>> threading?
>>
>> Oooh, you are on to my secret plan! :-)
>
> I completely agree that there are other approaches to parallelism and
> concurrency that are
On Wed, Oct 29, 2008 at 9:22 PM, <[EMAIL PROTECTED]> wrote:
>
> On 29 Oct, 09:14 pm, [EMAIL PROTECTED] wrote:
>>
>> Will 3.1 and 2.7 also be parallel releases? (I ask, not having read
>> the 3xxx PEPS at all.)
>>
>> If yes, why? While I can see a case for 2.6/3.0 being in sync -- new
>> features
30 matches
Mail list logo
