Neal Norwitz wrote:
If adding a slave for the trunk:
[...]
If adding a slave for the 2.4 branch:
Currently, branches are not supported, because buildbot is
somewhat limited. When I get a solution for this problem,
I plan to have all buildbots build both the trunk and the
2.4 branch; such builds
Jeremy Hylton wrote:
I think this solution is better. It's relatively rare for people to
change the ast definition, so for most purposes these should be static
files.
Interestingly enough, I found yesterday that Python-ast.c did change for
me, even though I had not touched the AST grammar at
On Mon, 2006-01-02 at 15:16 -0800, Neal Norwitz wrote:
On 1/2/06, Barry Warsaw [EMAIL PROTECTED] wrote:
I think we have a fundamental problem with Python-ast.c and
Python-ast.h. These files should not be both auto-generated and checked
into Subversion.
I agree with the problem
On 3 Jan 2006, at 08:58, Neal Norwitz wrote:
I had a friend run regrtest -L on Mac OSX a while ago. There are
several memory leaks which still appear to be an issue. There are a
bunch of leaks reported from putenv which I'm not sure how to fix
The attached patch should correct one of the
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib is the only path to whatever it is that it achieves? If
security holes in zlib turn up (they have in the past), new Python releases
will have to be released quickly.
Skip
Bob The easy fix is to upgrade your OS. I don't think anyone is going
Bob to bother with the preprocessor hackery necessary to make that
Bob (harmless) warning go away on older versions of the OS.
Excuse me, but this really pisses me off. I delayed upgrading from 10.2 for
awhile
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString and
PyRun_InteractiveLoop, I have not checked if there are more or not.
This breaks apps which dynamically link at runtime to the Python dll
(the latest py2exe
On 3-jan-2006, at 16:46, [EMAIL PROTECTED] wrote:
Bob The easy fix is to upgrade your OS. I don't think anyone
is going
Bob to bother with the preprocessor hackery necessary to make
that
Bob (harmless) warning go away on older versions of the OS.
Excuse me, but this
The intent was to provide binary compatibility, but redirect all newly
linked code to the newer variants. We did this correctly for
PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do
it for the rest of the changed functions. Can you file a bug report?
(Or just fix the ones
skip == skip [EMAIL PROTECTED] writes:
Bob The easy fix is to upgrade your OS. I don't think anyone is going
Bob to bother with the preprocessor hackery necessary to make that
Bob (harmless) warning go away on older versions of the OS.
skip Excuse me, but this really pisses me
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString and
PyRun_InteractiveLoop, I have not checked if there are more or
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString and
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out
Author: martin.v.loewis
Date: Tue Jan 3 14:16:53 2006
New Revision: 41906
Modified:
python/branches/ssize_t/Objects/obmalloc.c
Log:
Disable 32-bit size limitation for 64-bit mode.
Modified: python/branches/ssize_t/Objects/obmalloc.c
[Jeremy Hylton]
I think this solution is better. It's relatively rare for people to
change the ast definition, so for most purposes these should be static
files.
[Martin v. Löwis]
Interestingly enough, I found yesterday that Python-ast.c did change for
me, even though I had not touched the
On Jan 3, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote:
Bob The easy fix is to upgrade your OS. I don't think anyone
is going
Bob to bother with the preprocessor hackery necessary to make
that
Bob (harmless) warning go away on older versions of the OS.
Excuse me, but this
class _Quitter(str):
def __call__(self): raise SystemExit
quit = _Quitter('The quit command. Type quit() to exit')
exit = _Quitter('The exit command. Type exit() to exit')
I think you meant
class _Quitter(str):
def __call__(self): raise SystemExit
[Martin v. Loewis wrote]
Trent Mick wrote:
Is this intentional? If not, could someone point me to where the svn
trigger scripts are maintained so I could poke around for a fix? (Or
just fix it themselves. :)
It was not my intention. They are in
dinsdale.python.org:/data/repos/projects
Hear, hear.
On 1/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib is the only path to whatever it is that it achieves? If
security holes in zlib turn up (they have in the past), new Python releases
[EMAIL PROTECTED] writes:
I delayed upgrading from 10.2 for awhile and was given the same
advice. I was further told (check the mac sig archives) that you'd
be able to stick with 10.3 for much longer because new apps wouldn't
need to require 10.4. So I upgraded. Now you're telling me that
[Guido]
Hear, hear.
[Skip]
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib is the only path to whatever it is that it achieves? If
security holes in zlib turn up (they have in the past), new Python releases
will have to be released quickly.
OK. As long a typical Unix build still links with whatever shared zlib
is present on the box I'm fine with this.
--Guido
On 1/3/06, Tim Peters [EMAIL PROTECTED] wrote:
[Guido]
Hear, hear.
[Skip]
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib
[Guido]
OK. As long a typical Unix build still links with whatever shared zlib
is present on the box I'm fine with this.
[Guido]
Hear, hear.
[Skip]
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib is the only path to whatever it is that it
Tim Peters wrote:
Modified: python/branches/ssize_t/Objects/obmalloc.c
[...]
This checkin should be reverted for now.
Not sure whether you've noticed this is just on the ssize_t branch.
Without this patch, it is not possible to allocate 4GiB or more for
a string object in debug mode, which kind
[Tim]
Modified: python/branches/ssize_t/Objects/obmalloc.c
[...]
This checkin should be reverted for now.
[Martin]
Not sure whether you've noticed this is just on the ssize_t branch.
Right, I noticed.
Without this patch, it is not possible to allocate 4GiB or more for
a string object in
Trent Mick wrote:
I don't have access to that box. Is this a machine used for maintaining
the pydotorg stuff?
Yes, it's also www.python.org (but not mail.python.org)
Or would it be easier
for you the fix this little inconsistency... or have me make a bug on SF
and assign to you (or someone
On 1/3/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I tried to, but couldn't. I'll be sending the mailer.py and mailer.conf
files in a private mail. I can't see anything wrong in that code.
Perhaps mailman is adding the spaces?
I looked into this briefly. I saw something like:
if prefix:
Tim Peters wrote:
If it's expedient, that's fine for now. I'd like to help fix it for
real, but time is a problem for now. In a week or two I may have
more to give to this. Would probably also like to change the dict
object's ma_{fill,used,mask} members to Py_ssize_t (while other people
Neal Norwitz wrote:
I looked into this briefly. I saw something like:
if prefix:
subject = prefix + ' ' + self.subject
else:
subject = self.subject
Hmm - this shouldn't matter: There is only a single prefix defined,
in [defaults]:
commit_subject_prefix = [Python-checkins] commit of
Stephen J. Turnbull wrote:
Sure, Python can be expected to do much better than random port
maintainers, but Discussions with the port maintainers makes it
hard to blame them.
Well, it's the same attitude that Fredrik Lundh just critized. It's
ok for a port maintainer to say I don't have
Bob Ippolito wrote:
Who's going to bother?
It violates PEP 7, unless you argue that OS X/gcc is not
a major compiler.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[EMAIL PROTECTED] wrote:
Martin checked in zlib to the Python svn repository. Are we really sure
that including zlib is the only path to whatever it is that it achieves? If
security holes in zlib turn up (they have in the past), new Python releases
will have to be released quickly.
As Tim
On Jan 3, 2006, at 3:12 PM, Martin v. Löwis wrote:
Bob Ippolito wrote:
Who's going to bother?
It violates PEP 7, unless you argue that OS X/gcc is not
a major compiler.
Clearly, but that still doesn't answer the question of who's going to
do it. Writing two code paths with availability
Bob Ippolito wrote:
Clearly, but that still doesn't answer the question of who's going to
do it. Writing two code paths with availability macros and all the
testing involved is a whole lot of work to fix a harmless warning on
older versions of the OS. If it actually caused a problem I'm
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Stephen J. Turnbull wrote:
Sure, Python can be expected to do much better than random port
maintainers, but Discussions with the port maintainers makes it
hard to blame them.
Martin Well, it's the same
Martin v. Löwis wrote:
[...]
commit_subject_prefix = [Python-checkins] commit of
[...]
Anyway, I just killed the [Python-checkins] part from the prefix
(expecting that mailman would add it, anyway), and regenerated
the r41848 commit message, and it seem that worked this time.
And
And while we're at it, could you remove the commit of too? IMHO it
just obscures the real content of the subject.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
37 matches
Mail list logo
