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 build
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 a
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
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 d
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
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 th
> "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 real
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 ar
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
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 t
> 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 touch
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
> 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/p
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 relea
[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 m
[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 quickl
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 in
[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 th
Hear, hear. Er
On 1/3/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [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]
> ...
>
> [Tim]
> ...
> I figure that if we keep this con
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 k
[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 o
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 some
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 p
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 peopl
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
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 hav
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 Ti
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 availa
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'
> "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
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 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:
http:
38 matches
Mail list logo
