Re: [Python-Dev] Developing/patching ctypes
Trent Mick wrote: > I do this for ActivePython builds... by setting up the Platform SDK > compiler I want in the environment and then using: > > devenv.com .../pcbuild.sln /useenv /build Release Right - that might be the easiest thing to do. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
> The Coverty marketing droids need to be a bit less anal about getting > people to register at the website. IMHO, the technology should be Honestly, I laughed out loud when I read this. ;) So thanks for that. > > I'd also encourage Coventry to explain their business model a bit more > clearly. Coventry seems to be supportive of open source projects. > Coverty also seems to be targeting big companies as customers. It's not > clear how arbitrary open source projects (and small companies and > individuals) will be able to take advantage of Coventry's products and > services. > Here's my take on this -- in the last couple of years, I've personally been to hundreds of companies (some big, some small) in an effort to get our technology out there. Of course it's no surprise that I see open source projects everywhere -- as part of infrastructure or part of code bases that people are developing. So from a Coverity perspective, clearly we want to provide source code analysis for the projects that our customers care about (their own as well as open source). Putting on my idealistic hat and remembering back my grad school days, I think we're on to something very new in the world of source code analysis. I really just want every developer to use source code analysis while they write code (remember, idealistic :)). We got a lot of the good publicity in the research lab because there existed this big open source OS that we could test our theories on. So from that angle, I think it makes sense for Coverity to have a strong relationship with the open source community since that community has been helping us pretty much since day 1. This project is just the next step in that...it's certainly not the last. There's plenty more to do to target every developer. -ben ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Martin v. Löwis wrote: > Josiah Carlson told me had has given up getting a Windows > buildbot running, because every time he installed VS.NET > on his machine, the installation would immediately crash. > > So if anybody wants to contribute both a machine and time > to operate it (including the likely very tedious phase to > get any results out of this at all), please contact me. > Are there any estimates how much network traffic a buildbot would generate? And how must it be connected to the internet - I assume it must be reachable from the outside. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Thomas Heller] > Are there any estimates how much network traffic a buildbot would generate? It should be trivial except for the initial checkout of the Python code base. > And how must it be connected to the internet - I assume it must be reachable > from the outside. The slave opens a socket connection to the master, so you must be able to reach the python.org box _from_ the slave. I don't expect you'll have serious problems if you can do that much. For example, my home box has a dynamic IP (assigned by my ISP to my router), my router gives a different dynamic IP to my box (NAT'ed), and I'm running behind both software and hardware (SPI) firewalls. Because my box initiated the connection, nothing in the chain objects. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Open Source Defect Scan of Python
On 3/7/06, Ben Chelf <[EMAIL PROTECTED]> wrote: Putting on my idealistic hat and remembering back my grad school days, Ithink we're on to something very new in the world of source codeanalysis. I really just want every developer to use source code analysiswhile they write code (remember, idealistic :)). We got a lot of the good publicity in the research lab because there existed this big opensource OS that we could test our theories on. So from that angle, Ithink it makes sense for Coverity to have a strong relationship with the open source community since that community has been helping us prettymuch since day 1. This project is just the next step in that...it'scertainly not the last.There's plenty more to do to target every developer. Well, as long as we're talking idealistically, I wonder how easy it would be to add reference-counting tracking to Coverity Prevent. Python, Perl and (I believe) PHP all have their own kind of refcounting, but the base semantics are pretty much the same: a function can return a new or a borrowed reference, and it can borrow or steal references passed to it. Without having seen how Prevent works, it feels to me like it would be a small addition to keep track of these application-specific details. Or, perhaps more generic, add a few markers to keep track of them; in Python, you'd only have to mark Py_INCREF and Py_DECREF, and possibly manual fidgeting with an objects' refcount (which is hopefully extremely rare.) I say 'idealistically', though, because I don't know how much business sense it makes to cater to refcounting mechanisms.-- Thomas Wouters < [EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Google ads on python.org?
Okay, if they were sensible, but: http://www.ph.tum.de/~gbrandl/python-vb.png Not that we want them to use Python... Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
On 3/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Heller wrote:> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:>> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 >> Is there a way to get the actual failures somehow?They are now inhttp://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. Maybe re-running the test could be done in a freshly spawned Python? -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google ads on python.org?
Georg Brandl wrote: >Okay, if they were sensible, but: > >http://www.ph.tum.de/~gbrandl/python-vb.png > >Not that we want them to use Python... > >Georg > > > > It's a beta that Google have asked Python to roadtest. I'm hoping that the relevance level will increase soon though ... Tim Parkin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: > I suspect that some of those failures probably aren't ctypes failures, > but re-running-ctype-tests-in-the-same-process failures (like the very > first one) -- I get more errors when running -R:: than I do when running > the test verbosely directly. Maybe re-running the test could be done in > a freshly spawned Python? Feel free to implement that; buildbot will immediately pick it up. Getting the command line right might be a challenge though (plus finding the right Python interpreter, etc.) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Thomas Heller wrote: > Are there any estimates how much network traffic a buildbot would generate? It will need to download the entire source code twice (once for the trunk, and once for 2.4). After that, it currently does only svn up, on each commit. > And how must it be connected to the internet - I assume it must be reachable > from the outside. No: it opens a connection itself, and then keeps that connection permanently open. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] libbzip2 version?
The current PCBuild/readme.txt directs people to http://sources.redhat.com/bzip2 to get the 1.0.2 version of libbz2. The RedHat link redirects to http://www.bzip.org, which shows that 1.0.3 was released in February 2005. I suggest that Python 2.5 should move up to 1.0.3, and that readme.txt should point to bzip.org instead of redhat.com. I'll make & submit a patch if that would help. Here's the changelog entry for 1.0.3: 1.0.3 (15 Feb 05) ~ Fixes some minor bugs since the last version, 1.0.2. * Further robustification against corrupted compressed data. There are currently no known bitstreams which can cause the decompressor to crash, loop or access memory which does not belong to it. If you are using bzip2 or the library to decompress bitstreams from untrusted sources, an upgrade to 1.0.3 is recommended. * The documentation has been converted to XML, from which html and pdf can be derived. * Various minor bugs in the documentation have been fixed. * Fixes for various compilation warnings with newer versions of gcc, and on 64-bit platforms. * The BZ_NO_STDIO cpp symbol was not properly observed in 1.0.2. This has been fixed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libbzip2 version?
Alan McIntyre wrote: > The current PCBuild/readme.txt directs people to > http://sources.redhat.com/bzip2 to get the 1.0.2 version of libbz2. The > RedHat link redirects to http://www.bzip.org, which shows that 1.0.3 was > released in February 2005. I suggest that Python 2.5 should move up to > 1.0.3, and that readme.txt should point to bzip.org instead of > redhat.com. I'll make & submit a patch if that would help. There is no need to submit a patch. I had planned to update it myself for some time now. I also want to update versions of various other libraries (Tcl and bsddb in particular). On bzip2, I wonder whether 2.4 should also update to the newer library; on bsddb, I wonder what version to update to. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libbzip2 version?
Martin v. Löwis <[EMAIL PROTECTED]> wrote: > On bzip2, I wonder whether > 2.4 should also update to the newer library; +1, I seem to remember of exploits with corrupted data fed to the bz2 decompressor. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Trent Mick]
> I'm keen. However, it looks like Tim is most of the way there already:
The first 100% clean (ignoring _ctypes warnings) Windows builbot test
run just finished. Yippee! Setup is hellish, although you've already
done the worst of it if you regularly build+test full Python on
Windows from a checkout ("full" == everything we ship on Windows,
including bsddb, ssl, Tcl/Tk and bz2).
The second-worst part was figuring out which parts of various software
docs could be ignored. I recorded all that remained here:
http://wiki.python.org/moin/BuilbotOnWindows
Reading that should save you several months ;-)
> "x86 XP-2 trunk". I'd still like to give it a go. The machine I'd use
> (initially at least) would be Win2k -- so not just a dupe of Tim's WinXP
> box.
That would be great. A dupe of WinXP would also be great: I'm not
going to keep my buildbot slave up all the time, or anywhere near all
the time.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jeremy Hylton wrote: >> Perhaps the solution >> is to require parens around all expressions, a simple consistent rule. > > I actually designed a language with that feature once. > It was an exercise in minimality, with hardly anything > built-in -- all the arithmetic operators, etc. were > defined in the language. > > A result was that there was no built-in notion of > precedence, and my solution was to require parentheses > around every infix operation. So instead of > > dsq = b * b - 4 * a * c > > you would have had to write > > dsq = ((b * b) - ((4 * a) * c)) > > I never got an implementation working well enough > to find out how much of a disaster this would > have been to use, though. :-) Well the original was almost certainly a tongue-in-cheek reference to LISP. LISP was a disaster to use, so I doubt your language would have been any worse. The way one identifies a lisp programmer is to find the person whose paren keys have worn competely off their keyboard. :D ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
On Fri, 2006-03-10 at 12:46 +1300, Greg Ewing wrote:
> Steven Elliott wrote:
> > One way of handling it is to
> > alter STORE_ATTR (op code for assigning to mod.str) to always check to
> > see if the key being assigned is one of the default builtins. If it is,
> > then the module's indexed array of builtins is assigned to.
>
> As long as you're going to all that trouble, it
> doesn't seem like it would be much harder to treat
> all global names that way, instead of just a predefined
> set. The compiler already knows all of the names that
> are used as globals in the module's code.
The important difference between builtins and globals is that with
builtins both the compiler and the runtime can enumerate all references
to builtins in a single consistent way. That is "True" can always be
builtin #3 and "len" can always be builtin #17, or whatever. This isn't
true of globals in that a pyc file referencing a global in a module may
have been compiled with a different version of that module (that is
"some_module.some_global" can't compiled to single fixed index since
stuff may shift around in "some_module"). With globals you have the
same kind of problem that you have with operating systems that use
ordinals to refer to symbols in shared libraries.
So in the case of a static reference to a builtin ("while True", or
whatever) the compiler would generate something that refers to it with
that builtin's index (such as a new "BUILTIN_OP" opcode, as Philip
suggested). Ordinary globals (non-builtins) would continue to be
generated as the same code (the "LOAD_GLOBAL" opcode (I'll only refer to
the loading opcodes in this email)).
In the case of a dynamic reference to a builtin ("eval('True = 7')" or
"from foo import *" or whatever) would generate the opcode that
indicates that the runtime needs to figure out what do to (the same
"LOAD_NAME" opcode). The second part of the the "LOAD_NAME" opcode is
similar to the current "LOAD_GLOBAL" opcode - it first checks the hash
tables of globals and then checks the hash table of builtins. However,
the second part of the "LOAD_NAME" opcode could be implemented such that
it first checks against a list of default builtins (which could be a
hash table that returns the index of that builtin) and then indexes into
the array of builtins if it is found, or retrieves it from the single
hash table of globals otherwise. So the "LOAD_NAME" opcode (or similar
attempts to dynamically get a name) would almost be as efficient as it
currently it.
> > That's great, but I'm curious if additional gains can be
> > made be focusing just on builtins.
>
> As long as builtins can be shadowed, I can't see how
> to make any extra use of the fact that it's a builtin.
> A semantic change would be needed, such as forbidding
> shadowing of builtins, or at least forbidding this
> from outside the module.
One way of looking at is rather than having a clear distinction between
builtins and globals (as there currently is) there would be a single
global name space that internally in Python is implemented in two data
structures. An array for frequently used names and a hash table for
infrequently used names. And the division between the two wouldn't even
have two be between globals and builtins like we've been talking about
so far.
What distinguishes the builtins is you get them for free (initialized on
startup). So, it would be possible to insert infrequently used builtins
into the hash table of infrequently used names only when the module
refers to it. Conversely, names that aren't builtins, but that are used
frequently in many different modules, such as "sys" or "os", could have
indexes set aside for for them in the array of frequently used names.
Later, when when it gets a value (because "sys" is imported, or
whatever) it just gets stuck into the predetermined slot in the array of
frequently used names.
Since builtins can be shadowed, as you point out, there would have to be
one array of frequently used names per module. But often it would be
the same as other modules. So internally, as a matter of efficiency,
the interpreter could use a copy on write strategy where a global array
of frequently used names is used by the module until it assigns to
"True", or something like that, at which point it gets its own copy.
--
---
| Steven Elliott | [EMAIL PROTECTED] |
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libbzip2 version?
Martin v. Löwis wrote: > Alan McIntyre wrote: >> The current PCBuild/readme.txt directs people to >> http://sources.redhat.com/bzip2 to get the 1.0.2 version of libbz2. The >> RedHat link redirects to http://www.bzip.org, which shows that 1.0.3 was >> released in February 2005. I suggest that Python 2.5 should move up to >> 1.0.3, and that readme.txt should point to bzip.org instead of >> redhat.com. I'll make & submit a patch if that would help. > > There is no need to submit a patch. I had planned to update it myself > for some time now. I also want to update versions of various other > libraries (Tcl and bsddb in particular). There seems to be a new version of expat too: http://python.org/sf/1433435 The namespace problem with pyexpat persists: http://python.org/sf/1295808 Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
