Re: [Python-Dev] cpython (2.7): Closes #16461: Wave library should be able to deal with 4GB wav files, and
On Sat, 17 Nov 2012 03:43:31 +0100 (CET) jesus.cea wrote: > http://hg.python.org/cpython/rev/b8ece33ce27d > changeset: 80455:b8ece33ce27d > branch: 2.7 > parent: 80439:457c0c9c7893 > user:Jesus Cea > date:Sat Nov 17 03:38:17 2012 +0100 > summary: > Closes #16461: Wave library should be able to deal with 4GB wav files, and > sample rate of 44100 Hz. Any reason you didn't add any tests? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Register-based VM for CPython
Hi Victor, On Sat, Nov 17, 2012 at 2:13 AM, Victor Stinner wrote: > The major drawback of the register approach (at least of my implementation) > is that it changes the lifetime of objects. Newly created objects are only > "destroyed" at the exit of the function, whereas the stack-based VM destroys > "immediatly" objects (thanks to the reference counter). PyPy has similar > issues with its different garbage collector. That is not strictly correct. PyPy, Jython and IronPython have non-immediate destructors, but as far as I can tell they all avoid to keep objects alive for an unbounded amount of time. This important difference is visible if the function calls other code that takes a long while to run: in your approach, the objects created by the function itself will stay alive for the whole duration, while the other interpreters will all release them soon after they are not referenced any more --- not instantly like CPython but still soon. A bientôt, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
[Apologies for resurrecting a few-weeks old thread.] On Thu, Oct 4, 2012 at 2:46 PM, wrote: > > Zitat von Victor Stinner : > >> I only see one argument against such refactoring: it will be harder to >> backport/forwardport bugfixes. > > I'm opposed for a different reason: I think it will be *harder* to maintain. > The amount of code will not be reduced, but now you also need to guess what > file some piece of functionality may be in. Instead of having my text editor > (Emacs) search in one file, it will have to search across multiple files - > but not across all open buffers, but only some of them (since I will have > many other source files open as well). > > I really fail to see what problem people have with large source files. > What is it that you want to do that can be done easier if it's multiple > files? One thing is browse or link to such code files on the web (e.g. from within a tracker comment or from within our online documentation). For example, today I was unable to open the following page from within a browser to link to one of its lines on a tracker comment: http://hg.python.org/cpython/file/27c20650aeab/Objects/unicodeobject.c My laptop's fan simply turns on and the page hangs indefinitely while loading. I don't think this point was ever mentioned. --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
On Sun, Nov 18, 2012 at 5:47 AM, Chris Jerdonek wrote: > On Thu, Oct 4, 2012 at 2:46 PM, wrote: >> I really fail to see what problem people have with large source files. >> What is it that you want to do that can be done easier if it's multiple >> files? > > One thing is browse or link to such code files on the web (e.g. from > within a tracker comment or from within our online documentation). > For example, today I was unable to open the following page from within > a browser to link to one of its lines on a tracker comment: > > http://hg.python.org/cpython/file/27c20650aeab/Objects/unicodeobject.c > > My laptop's fan simply turns on and the page hangs indefinitely while loading. Curious. This sounds like a web browser issue - I can pull it up in either Chrome or Firefox on Windows on my 2GHz/2GB RAM laptop with a visible pause, but not more than half a second. However, this page is rather more significant, and is affected equally by the file size: http://hg.python.org/cpython/annotate/27c20650aeab/Objects/unicodeobject.c ChrisA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split unicodeobject.c into subfiles?
On Sat, Nov 17, 2012 at 10:55 AM, Chris Angelico wrote: > On Sun, Nov 18, 2012 at 5:47 AM, Chris Jerdonek > wrote: >> On Thu, Oct 4, 2012 at 2:46 PM, wrote: >>> I really fail to see what problem people have with large source files. >>> What is it that you want to do that can be done easier if it's multiple >>> files? >> >> One thing is browse or link to such code files on the web (e.g. from >> within a tracker comment or from within our online documentation). >> For example, today I was unable to open the following page from within >> a browser to link to one of its lines on a tracker comment: >> >> http://hg.python.org/cpython/file/27c20650aeab/Objects/unicodeobject.c >> >> My laptop's fan simply turns on and the page hangs indefinitely while >> loading. > > Curious. This sounds like a web browser issue - I can pull it up in > either Chrome or Firefox on Windows on my 2GHz/2GB RAM laptop with a > visible pause, but not more than half a second. I'm also using Chrome and on a fairly new Mac. Perhaps. I tried again and it froze up several open *.python.org tabs (mail.python.org, bugs.python.org, etc). However, later it worked as you describe. The problem seems sporadic. --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] externals?
Thanks for your pro-tip. Might I suggest that it ought to go into the dev FAQ? Along with an explanation that a windows dev has to have SVN installed too, just for the laughs? I think there might be a benefit to moving at least the current externals to a separate HG repository. We could easily have multiple branches in that repo reflecting the required externals for each version under active HG development). There is an inherent drawback in having to rely on two different RCS to fetch the necessary stuff, imho. K -Original Message- From: Trent Nelson [mailto:[email protected]] Sent: 16. nóvember 2012 12:13 To: Kristján Valur Jónsson Cc: Benjamin Peterson; Python-Dev ([email protected]) Subject: Re: [Python-Dev] externals? On Thu, Nov 15, 2012 at 01:20:09AM -0800, Kristj?n Valur J?nsson wrote: > Perhaps the unix makefiles get the proper version, but a windows developer > has to fetch those externals manually. Pro-tip: if you're developing on Windows, you're mad if you don't prime your dev env with Tools\buildbot\externals.bat. It takes care of *everything*. I wish every proprietary UNIX system we support had something similar. > Also, is there any reason to keep this in svn? I think it's more a case of there being no tangible benefit (and numerous drawbacks) to switching it to hg. I personally have no need for a local hg repo with 30 different Tcl/Tk histories in it. Subversion's good for this sort of use case. The externals repo gets committed to maybe, what, 3-4 times a year? > Why not check this in to HG, we need not worry about history, etc. Who are these mystical people worried about history? ;-) Trent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] need reviewers for #16475 and #16487
Hello there. I'd like to have some pair of eyes on a couple of patches i´ve submitted. http://bugs.python.org/issue16475 This fixes a regression in marshal between 2.x and 3.x, reinstating string reuse and internment support. In addition, it generalizes string reuse to all objects, allowing for data optimizations to be made on code objects before marshaling. This straighforward extension considerably enhances the utility of the marshal module as a low-cost data serialization tool. http://bugs.python.org/issue16487 This allows ssl contexts to be initialized with certificates from memory, rather than having to rely on the openssl performing its own file IO to read them. This allows clients and servers that have their certificates deployed e.g. from a db or verbatim in a module, to use ssl without having to resort to temporary disk files and physical IO. Both of these patches are bourne out of work performed at CCP. The former comes from work on marshal in order to support our own code object optimizer, which helps save memory on the PS3. The second comes from us supporting isolated embedded python servers and clients and not wanting to complicate things with unnecessary temporary files for storing credidentials that are obtained from elsewhere. Both were, of course, 2.7 modifications, that I have now ported to 3.4 for the benefit of the python community. K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] externals?
Zitat von Kristján Valur Jónsson : Thanks for your pro-tip. Might I suggest that it ought to go into the dev FAQ? Along with an explanation that a windows dev has to have SVN installed too, just for the laughs? I think there might be a benefit to moving at least the current externals to a separate HG repository. We could easily have multiple branches in that repo reflecting the required externals for each version under active HG development). Feel free to work on this. Consider that using hg may significantly increase the amount of network traffic, since the repo(s) will contain multiple versions, when only one specific version is needed. When working on this, try to come up with other automated download procedures, e.g. ones that do not involve revision control and have support built into Windows. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
On Fri, 16 Nov 2012 22:35:38 -0800 Chris Jerdonek wrote: > > > > I'm pretty sure it's because python-dev is the 'from' address > > used when the messages are sent...and the configuration of > > that user is what allows them to be accepted. > > > > I suggest changing the from address and the account configuration > > to [email protected] instead. > > Above and on the meta tracker issue I filed, it sounds like Martin is > saying that the e-mails should never be going to python-dev (or > tracker-discuss) in the first place -- due to a roundup bug and > because the e-mail is already being sent to the submitter and the > roundup admins. Thus, changing the from address would only mitigate > the problem and not be fixing the root cause. So, for the record, the "From" address has been changed to [email protected], so python-dev shouldn't be spammed anymore. Cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need reviewers for #16475 and #16487
On Sat, Nov 17, 2012 at 1:48 PM, Kristján Valur Jónsson wrote: > Hello there. > > I‘d like to have some pair of eyes on a couple of patches i´ve submitted. Sorry, can't help you with these, but I've got a language nit... > http://bugs.python.org/issue16475 > > This fixes a regression in marshal between 2.x and 3.x, reinstating string > reuse and internment support. In addition, it generalizes string reuse to It's not internment -- that means imprisonment. The term we use is interning. (The dictionary will tell you that means imprisonment too -- but it's long been used as the name for this particular technique. Internment has not.) > all objects, allowing for data optimizations to be made on code objects > before marshaling. This straighforward extension considerably enhances the > utility of the marshal module as a low-cost data serialization tool. > > > > http://bugs.python.org/issue16487 > > This allows ssl contexts to be initialized with certificates from memory, > rather than having to rely on the openssl performing its own file IO to read > them. This allows clients and servers that have their certificates > deployed e.g. from a db or verbatim in a module, to use ssl without having > to resort to temporary disk files and physical IO. > > > > Both of these patches are bourne out of work performed at CCP. The former > comes from work on marshal in order to support our own code object > optimizer, which helps save memory on the PS3. The second comes from us > supporting isolated embedded python servers and clients and not wanting to > complicate things with unnecessary temporary files for storing credidentials > that are obtained from elsewhere. > > > > Both were, of course, 2.7 modifications, that I have now ported to 3.4 for > the benefit of the python community. > > > > K > > > > > > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] externals?
Am 17.11.2012 23:47, schrieb [email protected]: > > Zitat von Kristján Valur Jónsson : > >> Thanks for your pro-tip. Might I suggest that it ought to go into >> the dev FAQ? Along with an explanation that a windows dev has to >> have SVN installed too, just for the laughs? >> I think there might be a benefit to moving at least the current >> externals to a separate HG repository. We could easily have >> multiple branches in that repo reflecting the required externals for >> each version under active HG development). > > Feel free to work on this. Consider that using hg may significantly > increase the amount of network traffic, since the repo(s) will contain > multiple versions, when only one specific version is needed. > > When working on this, try to come up with other automated download > procedures, e.g. ones that do not involve revision control and have > support built into Windows. One way would be to use one hg repo per version, and (maybe, if needed) a master repo that has them as subrepos. Whoever needs externals can download the repo as a zipfile and unpack it (both of which is possible with batteries only). Note that in this scenario, hg is used mostly in order to avoid another service (such as rsync), and for developer convenience. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
