Bill Janssen <[EMAIL PROTECTED]> writes:
> In that case, I think your idea of just hard-coding a path is probably
> the right thing to do. I'll add a note that this is how you need to do
> it if you are going to try "python setup.py build". Presumably the
> binary then built with "python setup.p
> What do you think?
I think what you are describing is the situation of today,
except in a less-performant way. The kernel *already*
implements such a "synchronization server", except that
all CPUs can act as such. You write
"Since we are guaranteeing that synchronized code is running on a singl
I was reading GvR's post on this and came up with a theory on how to
tackle the problem.
I ended up putting it in a blog post.
http://www.brainwavelive.com/blog/index.php?/archives/12-Suggestion-
for-removing-the-Python-Global-Interpreter-Lock.html
What do you think?
Prateek
On Sep 12, 200
On Wed, Sep 12, 2007, Bill Janssen wrote:
>
>>> By the way, I think the hostname matching provisions of 2818 (which
>>> is, after all, only an informational RFC, not a standard) are poorly
>>> thought out. Many machines have more hostnames than you can shake a
>>> stick at, and often provide certs
"Mark Hammond" <[EMAIL PROTECTED]> writes:
> It might be possible to try and use build_ssl.py to locate the openssl
> directory, but this will still require that someone building it has Python
> built from source - I'm fairly sure that someone installing a Python binary
> will not have build_ssl.p
> > Can't we look in the registry for this? We have a working Python;
> > perhaps we can just use a Windows-specific registry lookup to find
> > OpenSSL? (I'm just blue-skying here; I have no clue how things work
> > on Windows.)
>
> Not really. Python itself, when building _ssl, doesn't look f
> > * find_ssl() is along way from working on Windows. Python itself
> uses magic
> > to locate an SSL directory in the main Python directory's parent. On
> my
> > system, this is c:\src\openssl-0.9.7e, but obviously that could be
> almost
> > anywhere, and with almost any name. See PCBuild\buil
> * find_ssl() is along way from working on Windows. Python itself uses magic
> to locate an SSL directory in the main Python directory's parent. On my
> system, this is c:\src\openssl-0.9.7e, but obviously that could be almost
> anywhere, and with almost any name. See PCBuild\build_ssl.py and
>
Thanks, Mark (and David, who replied to me personally). I'll update
the setup.py files with your suggestions and do a 1.2 (with more
metadata in it, too). Looks like the functionality is working for
people, even if the build is still a bit flakey.
Bill
___
> I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
> and probably don't have the tools to do it anyway. I presume that
> both a Windows machine and Visual Studio (because there's a C
> extension) is required?
>
> Anyone out there who's interested in the challenge?
>
> It's a
On 9/12/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I could use a refresher on how PJE's patch solves Andy's problem.
>
> I'm not sure if you're asking about how you would execute a zip file
> after the patch has been applied, or about the mechanics of how the
> patch
Yes, port 443 on svn.python.org seems to work for this purpose.
Everyone OK with that? If so, I'll change the SSL test code.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 12, 2007, at 2:05 PM, Bill Janssen wrote:
> The SSL tests currently use SSL-protected ports on gmail.com and
> Verisign for testing. That's not what they are for; I think we should
> shift to using SSL-protected ports on python.org somewhere.
> > By the way, I think the hostname matching provisions of 2818 (which
> > is, after all, only an informational RFC, not a standard) are poorly
> > thought out. Many machines have more hostnames than you can shake a
> > stick at, and often provide certs with the wrong hostname in them
> > (usuall
The SSL tests currently use SSL-protected ports on gmail.com and
Verisign for testing. That's not what they are for; I think we should
shift to using SSL-protected ports on python.org somewhere. Are there
any HTTPS servers, or SSL-protected POP or IMAP servers, currently
running on python.org alr
I can't figure out how to build a Windows package for ssl-1.1.tar.gz,
and probably don't have the tools to do it anyway. I presume that
both a Windows machine and Visual Studio (because there's a C
extension) is required?
Anyone out there who's interested in the challenge?
It's at http://www.par
Martin> Now we are getting into details: you do NOT have to lock an
Martin> object to modify its reference count. An atomic
Martin> increment/decrement operation is enough.
Implemented in asm I suspect? For common CPUs this could just be part of
the normal Python distribution. For u
Brett> We should probably document where all of these globals lists are
Brett> instead of relying on looking for all file level static
Brett> declarations or something.
I smell a wiki page.
Skip
Brett> Or would there be benefit to moving things like this to the
Brett> interp
On 9/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Now we are getting into details: you do NOT have to lock
> an object to modify its reference count. An atomic
> increment/decrement operation is enough.
One could measure the performance hit incurred by using atomic
operations for refcount
Guido van Rossum wrote:
> I could use a refresher on how PJE's patch solves Andy's problem.
I'm not sure if you're asking about how you would execute a zip file
after the patch has been applied, or about the mechanics of how the
patch works. PJE's last post covered the former question, so I'll c
> I believe this is only in 2.5.1 and later -- can
> anyone confirm that?
That's correct.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/py
>> Sure - but those things don't get modified that often, except for their
>> reference count.
>
> The reference count is the killer, though -- you have
> to lock the object even to do that. And it happens
> a LOT, to all objects, including immutable ones.
Now we are getting into details: you do
> But this has been raised before, and was rejected as not worth the
> amount of work that would be required to achieve it.
In my understanding, there is an important difference between
"it was rejected", and "it was not done".
Regards,
Martin
___
Pyt
23 matches
Mail list logo
