> Well, on my win2k machine getfqdn('127.0.0.1') returns the actual name
> of the machine. This is the name that was stored in server.address.
> Hence my patch that simply remove the call to getfqdn.
+1 to ditching getfqdn, following patch fixes the issue on my buildbot server:
Index: connection.
> I just found the cause of the problem ten minutes ago:
> It seems that when a socket listens on the address "127.0.0.1" or
> "localhost", another process cannot connect to it using the machine's
> name (even from the same machine).
> The best seems to listen with the empty address "".
That doesn
On Wed, Jun 18, 2008 at 9:58 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
> Very very, interesting. Thanks. :)
>
> Somebody thinks that Python is unsuitable to implement a DSL: IMO your
> example prove the contrary. :D
As long as you're willing to do the "DSL" within the strictures of
Python sy
> The server component *is* listening to localhost by default. The
> client in the code I pasted has the server's .address attribute passed
> into it to tell the client where to connect to.
Interestingly enough, I can't coerce test_multiprocessing.test_listener_client
to wedge on my XP laptop. W
Very very, interesting. Thanks. :)
Somebody thinks that Python is unsuitable to implement a DSL: IMO your example
prove the contrary. :D
Cesare
In data 16 giugno 2008 alle ore 01:12:46, Alex Martelli <[EMAIL PROTECTED]> ha
scritto:
> +1 on updating the FAQ. Maybe we could even have it notice
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team and the Python community, I
am happy to announce the first beta releases of Python 2.6 and Python
3.0.
Please note that these are beta releases, and as such are not suitable
for production environments.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 18, 2008, at 7:54 AM, Jesse Noller wrote:
Please let me know about 3088 - I've disabled the more unreliable
tests until I can give the entire suite some TLC. I'm still trying to
work around/identify the "Function not Implemented" error in iss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are enough green buildbots and I think all the showstoppers are
resolvable, so I'm going ahead and releasing beta 1 tonight. Please
refrain from any commits unless I ask you to check something in.
We've got a major thunderstorm blowing th
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
This particular one m
Amaury Forgeot d'Arc wrote:
2008/6/18 Jesse Noller <[EMAIL PROTECTED]>:
On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Jesse Noller gmail.com> writes:
The server component *is* listening to localhost by default. The
client in the code I pasted has the server's .add
2008/6/18 Jesse Noller <[EMAIL PROTECTED]>:
> On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>> Jesse Noller gmail.com> writes:
>>>
>>> The server component *is* listening to localhost by default. The
>>> client in the code I pasted has the server's .address attribute p
Georg Brandl wrote:
> Antoine Pitrou schrieb:
>>> Maciej Fijalkowski did an opcode analysis for PyPy,
>>> it also shows the relative frequency of opcodes following a
>>> specifc one:
>>>
>>> http://codespeak.net/svn/user/fijal/opcodes.txt
>>
>> Nice, but we have to be careful here: what is the test
Georg Brandl gmx.net> writes:
> Agreed; is there a way for a JUMP to end up without popping the top
> after jumping? It would have to do a DUP first then.
For example:
>>> def f(x, y):
... return x and y
...
>>> import dis
>>> dis.dis(f)
2 0 LOAD_FAST0 (x)
Antoine Pitrou schrieb:
Hi,
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Nice, but we have to be careful here: what is the tested workload?
For example, I find it h
On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Jesse Noller gmail.com> writes:
>>
>> The server component *is* listening to localhost by default. The
>> client in the code I pasted has the server's .address attribute passed
>> into it to tell the client where to conne
Jesse Noller gmail.com> writes:
>
> The server component *is* listening to localhost by default. The
> client in the code I pasted has the server's .address attribute passed
> into it to tell the client where to connect to.
So I take it that the .address attribute is different from "localhost",
Hi,
> Maciej Fijalkowski did an opcode analysis for PyPy,
> it also shows the relative frequency of opcodes following a
> specifc one:
>
> http://codespeak.net/svn/user/fijal/opcodes.txt
Nice, but we have to be careful here: what is the tested workload?
For example, I find it hard to believe th
On Wed, Jun 18, 2008 at 12:20 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> I gave my Windows buildbots a little bit of TLC last night. This little
> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
> to wedge more often than not:
>
>def test_listener_client(self)
On Wed, Jun 18, 2008 at 1:51 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Amaury Forgeot d'Arc gmail.com> writes:
>>
>> OK, I am not a tcp expert.
>> How about the following patch?
>> It seems to me that it is wrong for the server to lie about the
>> address it listens to.
>
> Maybe I'm missing
Amaury Forgeot d'Arc gmail.com> writes:
>
> OK, I am not a tcp expert.
> How about the following patch?
> It seems to me that it is wrong for the server to lie about the
> address it listens to.
Maybe I'm missing something but... if the client part defaults to connecting
to "localhost" in TCP mo
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Leap seconds? Leap seconds aren't supposed to exist when looking
> at POSIX timestamps. They don't exist when I look at my watch
> either, and that's what I expect from any time-keeping device
> except those for use by astronomers.
That's pre
Hi,
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
Georg
__
Hello,
2008/6/18 Jean-Paul Calderone <[EMAIL PROTECTED]>:
> On Wed, 18 Jun 2008 18:35:26 +0200, Amaury Forgeot d'Arc
> <[EMAIL PROTECTED]> wrote:
>>
>> [snip]
>>
>> I just found the cause of the problem ten minutes ago:
>> It seems that when a socket listens on the address "127.0.0.1" or
>> "local
On Wed, 18 Jun 2008 18:35:26 +0200, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>
wrote:
[snip]
I just found the cause of the problem ten minutes ago:
It seems that when a socket listens on the address "127.0.0.1" or
"localhost", another process cannot connect to it using the machine's
name (even fr
Amaury Forgeot d'Arc gmail.com> writes:
> if family == 'AF_INET':
> -return ('localhost', 0)
> +return ('', 0)
> elif family == 'AF_UNIX':
> return tempfile.mktemp(prefix='listener-', dir=get_temp_dir())
> elif family == 'AF_PIPE':
Doesn't it have important
On Wed, Jun 18, 2008 at 12:35 PM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> 2008/6/18 Trent Nelson <[EMAIL PROTECTED]>:
>> I gave my Windows buildbots a little bit of TLC last night. This little
>> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
>>
Hello,
2008/6/18 Trent Nelson <[EMAIL PROTECTED]>:
> I gave my Windows buildbots a little bit of TLC last night. This little
> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
> to wedge more often than not:
>
>def test_listener_client(self):
>for family
I gave my Windows buildbots a little bit of TLC last night. This little
chestnut in test_multiprocessing.py around line 1346 is causing my buildbots to
wedge more often than not:
def test_listener_client(self):
for family in self.connection.families:
l = self.connection.
Leap seconds? Leap seconds aren't supposed to exist when looking at
POSIX timestamps. They don't exist when I look at my watch either, and
that's what I expect from any time-keeping device except those for use
by astronomers.
On Wed, Jun 18, 2008 at 2:50 AM, Pete Forman
<[EMAIL PROTECTED]> wrote:
On Wed, Jun 18, 2008 at 7:54 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Well, I'm going to try again tonight to release beta one for Python 2.6 and
>> 3.0. I'm plan
On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Well, I'm going to try again tonight to release beta one for Python 2.6 and
> 3.0. I'm planning on starting the release at 6pm US/Eastern or 2200 UTC.
>
> Right now the Py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, I'm going to try again tonight to release beta one for Python
2.6 and 3.0. I'm planning on starting the release at 6pm US/Eastern
or 2200 UTC.
Right now the Python 2.6 buildbots look pretty good. We have /one/
green buildbot for Python
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> On Tue, Jun 17, 2008 at 11:09 AM, Curt Hagenlocher
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum
>> <[EMAIL PROTECTED]> wrote:
>>> On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher
>>> <[EMAIL PROTECTED]> wrote
>> Please never commit to python/trunk/Lib/lib2to3.
>> Instead, commit to sandbox/trunk/2to3, and merge
>> that using svnmerge.
>
> Could you explain that policy? Why isn't 2to3 maintained in the
> trunk but in the sandbox? Or maybe more general: Where can I find
> more information on the svn dire
34 matches
Mail list logo
