Re: [Python-Dev] Fun with ancient unsupported platforms

[Victor Stinner]

We slowly remove old platforms, but only if the code specific to these
old platforms is annoying to maintain. For example, I wrote the
change:

https://hg.python.org/cpython/rev/a1605d2508af
"""
Issue #22591: Drop support of MS-DOS

Drop support of MS-DOS, especially of the DJGPP compiler (MS-DOS port of GCC).

Today is a sad day. Good bye MS-DOS, good bye my friend :'-(
"""
=> http://bugs.python.org/issue22591

Victor

2016-01-28 15:57 GMT+01:00 Larry Hastings :
>
>
> Check out and cd into Python trunk.
>
> % grep -Ri win16 * | wc
>  10  66 625
>
> % grep -Ri nextstep | wc
>  23 1191328
>
> % grep -Ri rhapsody * | wc
>  47 2693390
>
> % grep -Ri msdos * | wc
>  56 3813895
>  % grep -Ri ms-dos * | wc
>  20 1801425
>
>
> win16!  *laughs* *wipes tear from eye*
>
> It's currently 2016.  Perhaps it's time to remove all vestiges of these
> unsupported operating systems nobody's cared about since a year that started
> with a '1'?
>
>
> /arry
>
> p.s. I suspect some of the uses of "rhapsody" are actually live code used
> for OS X.  So this isn't necessarily dead code, some of it is merely
> long-out-of-date comments.
>
> p.p.s. At least there were no references to "taligent", "copland", or
> "gershwin"...!
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] BAD Benchmark Results for Python Default 2016-01-26

[Stefan Krah]

IMO the timings of the benchmark suite are a bit unstable -- this is not the
fault of Intel's setup, I noticed it also when running the suite myself.


On Tue, Jan 26, 2016 at 06:48:54PM +, Stewart, David C wrote:
> Wow, what happened to Python default to cause such a regression?
> 
> 
> 
> 
> On 1/26/16, 7:31 AM, "lp_benchmark_robot"  
> wrote:
> 
> >Results for project Python default, build date 2016-01-26 03:07:40 +
> >commit:  cbd4a6a2657e
> >previous commit: f700bc0412bc
> >revision date:   2016-01-26 02:54:37 +
> >environment: Haswell-EP
> > cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
> > stepping 2, LLC 45 MB
> > mem:128 GB
> > os: CentOS 7.1
> > kernel: Linux 3.10.0-229.4.2.el7.x86_64
> >
> >Baseline results were generated using release v3.4.3, with hash b4cbecbc0781
> >from 2015-02-25 12:15:33+00:00
> >
> >--
> >  benchmark   relative   change since   change since   current 
> > rev run
> >  std_dev*   last run   baseline  
> > with PGO
> >--
> >:-)   django_v2  0.21% -2.93%  8.95%
> >16.19%
> >:-| pybench  0.10%  0.05% -1.87% 
> >5.40%
> >:-(regex_v8  2.72% -0.02% -4.67% 
> >4.57%
> >:-|   nbody  0.13% -0.92% -1.33% 
> >7.40%
> >:-|json_dump_v2  0.20%  0.87% -1.59%
> >11.48%
> >:-|  normal_startup  0.90% -0.57%  0.10% 
> >5.35%
> >--
> >* Relative Standard Deviation (Standard Deviation/Average)
> >
> >If this is not displayed properly please visit our results page here: 
> >http://languagesperformance.intel.com/bad-benchmark-results-for-python-default-2016-01-26/
> >
> >Note: Benchmark results are measured in seconds.
> >
> >Subject Label Legend:
> >Attributes are determined based on the performance evolution of the workloads
> >compared to the previous measurement iteration.
> >NEUTRAL: performance did not change by more than 1% for any workload
> >GOOD: performance improved by more than 1% for at least one workload and 
> >there
> >is no regression greater than 1%
> >BAD: performance dropped by more than 1% for at least one workload and there 
> >is
> >no improvement greater than 1%
> >UGLY: performance improved by more than 1% for at least one workload and also
> >dropped by more than 1% for at least one workload
> >
> >
> >Our lab does a nightly source pull and build of the Python project and 
> >measures
> >performance changes against the previous stable version and the previous 
> >nightly
> >measurement. This is provided as a service to the community so that quality
> >issues with current hardware can be identified quickly.
> >
> >Intel technologies' features and benefits depend on system configuration and 
> >may
> >require enabled hardware, software or service activation. Performance varies
> >depending on system configuration.
> ___
> Python-checkins mailing list
> python-check...@python.org
> https://mail.python.org/mailman/listinfo/python-checkins

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?

[Chris Angelico]

On Thu, Jan 28, 2016 at 9:41 PM, Chris Angelico  wrote:
> However, as I was doing so (and I just discarded a draft message where
> I'd been typing up notes), my entire system went kerblooie, and I've
> spent the last day rebuilding stuff from scratch. When I get around to
> it, I'll rebuild the buildbot VM - and it'll be Debian Jessie (current
> stable), because there's no particular reason to use Wheezy
> (oldstable). So the problem will almost certainly disappear.

Sure enough, the problem is no longer reproducible. Sorry folks.
Hopefully it wasn't actually a bug anywhere, but was some bizarre
piece of VM setup weirdness.

The "AMD64 Debian root" buildbot (angelico-debian-amd64) is now
running Debian Jessie, rather than the Wheezy it was before.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fun with ancient unsupported platforms

[Barry Warsaw]

Just as long as you can still build and run Python on Guido's ancient SGI
machine .

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fun with ancient unsupported platforms

[Christian Heimes]

On 2016-01-28 15:57, Larry Hastings wrote:
> 
> 
> Check out and cd into Python trunk.
> 
> % grep -Ri win16 * | wc
>  10  66 625
> 
> % grep -Ri nextstep | wc
>  23 1191328
> 
> % grep -Ri rhapsody * | wc
>  47 2693390
> 
> % grep -Ri msdos * | wc
>  56 3813895
>  % grep -Ri ms-dos * | wc
>  20 1801425
> 
> 
> win16!  *laughs* *wipes tear from eye*
> 
> It's currently 2016.  Perhaps it's time to remove all vestiges of these
> unsupported operating systems nobody's cared about since a year that
> started with a '1'?

The platform module has more hilarious comments:

Still needed:
* more support for WinCE
* support for MS-DOS (PythonDX ?)
* support for Amiga and other still unsupported platforms running Python

Christian

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fun with ancient unsupported platforms

[Paul Sokolovsky]

Hello,

On Thu, 28 Jan 2016 17:29:41 +0100
Victor Stinner  wrote:

> We slowly remove old platforms, but only if the code specific to these
> old platforms is annoying to maintain. For example, I wrote the
> change:
> 
> https://hg.python.org/cpython/rev/a1605d2508af
> """
> Issue #22591: Drop support of MS-DOS
> 
> Drop support of MS-DOS, especially of the DJGPP compiler (MS-DOS port
> of GCC).
> 
> Today is a sad day. Good bye MS-DOS, good bye my friend :'-(
> """
> => http://bugs.python.org/issue22591

Well, MicroPython is ready to take the baton - FreeDOS (that's how they
call MS-DOS now) support was added recently:
https://github.com/micropython/micropython/commit/64a909ef5113925adef19f275f62473de8ee68c5

> 
> Victor
> 

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FAT Python (lack of) performance

[INADA Naoki]

Please stop.

I'm sorry about messing up this thread.
I just wanted to represent why I'm very interested in Victor's efforts.

Regards.

On Thu, Jan 28, 2016 at 4:58 PM, Nick Coghlan  wrote:

> On 28 January 2016 at 04:40, Sven R. Kunze  wrote:
> > On 27.01.2016 12:16, Nick Coghlan wrote:
> >> Umm, no, that's not how this works
> > That's exactly how it works, Nick.
> >
> > INADA uses Python as I use crossroads each day. Daily human business.
> >
> > If you read his post carefully, you can discover that he just presented
> to
> > you his perspective of the world. Moreover, I can assure you that he's
> not
> > alone. As usual with humans it's not about facts or mathematically proven
> > theorems but perception. It's more about marketing, little important
> details
> > (or unimportant ones depending on whom you ask) and so on. Stating that
> he
> > has a wrong perspective will not change anything.
>
> The only part I disagree with is requesting that *other people* care
> about marketing numbers if that's not something they're already
> inclined to care about. I'm not in any way disputing that folks make
> decisions based on inappropriate metrics, nor that it bothers some
> folks that there are dozens of perfectly viable programming languages
> people may choose to use instead of Python.
>
> The fact remains that contributors to open source projects work on
> what they want to work on or on what their employers pay them to work
> on (for a lucky few, those are the same thing), so telling other
> contributors that they're working on the "wrong thing" because their
> priorities differ from our priorities is almost always going to be
> irritating rather than helpful.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] FAT Python (lack of) performance

[Nick Coghlan]

On 28 January 2016 at 18:30, INADA Naoki  wrote:
> Please stop.
>
> I'm sorry about messing up this thread.

Not your fault at all! This is just a particular bugbear of mine,
since software architecture design (including appropriate programming
language selection) is an even more poorly understood discipline than
software development in general :)

> I just wanted to represent why I'm very interested in Victor's efforts.

And thanks for posting that, as it is indeed cool that the
optimisation efforts currently being discussed may result in
performance improvements on some of the simplified micro-benchmarks
popular in programming language shootouts.

There's no way you could have anticipated the subsequent tangential
discussion on motives for contributing to open source projects, and
the impact that has on what we can reasonably expect from fellow
contributors.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?

[Martin Panter]

> After digging through test_socket.py for over an hour (the MRO for
> RecvmsgUDP6Test is enormous!!), I've boiled the issue down to this:
>
> import socket
> MSG = b'asdf qwer zxcv'
> serv = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> serv.bind(("::1", 0))
> cli = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
> cli.bind(("::1", 0))
> cli.sendto(MSG, serv.getsockname())
> print(serv.recvmsg(len(MSG) - 3, 0, socket.MSG_PEEK))
> print(serv.recvmsg(len(MSG), 0, socket.MSG_PEEK))
> print(serv.recvmsg(len(MSG)))
>
> On my main system, this produces three lines of output: the first has
> truncated text, the second has full text, and the third also has full
> text. This proves that MSG_PEEK is working correctly. On the buildbot,
> though, the first one stalls out. Commenting that line out produces
> correct results - peek the full data, then read it, and all is well.
>
> Any idea why partial read on a datagram socket would sometimes stall?

I think it would stall if there is no data to receive. Maybe check the
return value of sendto(), to ensure it is sending the whole message.

Attached is a C program which should do the equivalent of your
boiled-down Python script, in case that helps:

$ gcc -Wall peek-udp6.c -o peek-udp6
$ ./peek-udp6
Bytes sent: 14
Received [asdf qwer z]
Received [asdf qwer zxcv]
Received [asdf qwer zxcv]

Other things that come to mind are to see if there is anything odd
about the buildbot’s Linux kernel and glibc versions. Maybe run the
Python script under “strace” to see if anything strange is going on.
/*
$ gcc -Wall peek-udp6.c -o peek-udp6
$ ./peek-udp6
Bytes sent: 14
Received [asdf qwer z]
Received [asdf qwer zxcv]
Received [asdf qwer zxcv]
*/

#include 
#include 
#include 
#include 
#include 

static const char MSG[] = "asdf qwer zxcv";
static const size_t MSG_LEN = sizeof MSG - 1;

int main() {
int serv = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0);
if(serv < 0) {
perror("serv socket()");
return 1;
}

struct sockaddr_in6 bind_addr;
memset(_addr, 0, sizeof bind_addr);
bind_addr.sin6_family = AF_INET6;
bind_addr.sin6_port = htons(0);
bind_addr.sin6_addr = (struct in6_addr)IN6ADDR_LOOPBACK_INIT;
if(bind(serv, (struct sockaddr *)_addr, sizeof bind_addr) < 0) {
perror("bind(serv)");
return 1;
}

int cli = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0);
if(cli < 0) {
perror("cli socket()");
return 1;
}

if(bind(cli, (struct sockaddr *)_addr, sizeof bind_addr) < 0) {
perror("bind(cli)");
return 1;
}

struct sockaddr_in6 addr;
socklen_t addr_len = sizeof addr;
if(getsockname(serv, (struct sockaddr *), _len) < 0) {
perror("getsockname()");
return 1;
}
ssize_t size;
size = sendto(cli, MSG, MSG_LEN, 0, (struct sockaddr *), addr_len);
if(size < 0) {
perror("sendto()");
return 1;
}
printf("Bytes sent: %zi\n", size);

char buffer[MSG_LEN];
struct msghdr message = {
.msg_name = ,
.msg_namelen = sizeof addr,
.msg_iov = (struct iovec [1]){
{.iov_base = buffer, .iov_len = MSG_LEN - 3},
},
.msg_iovlen = 1,
};
size = recvmsg(serv, , MSG_PEEK);
if(size < 0) {
perror("short recvmsg(MSG_PEEK)");
return 1;
}
printf("Received [%.*s]\n", (int)size, buffer);

message.msg_iov[0].iov_len = MSG_LEN;
size = recvmsg(serv, , MSG_PEEK);
if(size < 0) {
perror("full recvmsg(MSG_PEEK)");
return 1;
}
printf("Received [%.*s]\n", (int)size, buffer);

size = recvmsg(serv, , 0);
if(size < 0) {
perror("full recvmsg(0)");
return 1;
}
printf("Received [%.*s]\n", (int)size, buffer);

return 0;
}
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbot timing out - test suite failure - test_socket issue with UDP6?

[Chris Angelico]

On Thu, Jan 28, 2016 at 7:35 PM, Martin Panter  wrote:
> Other things that come to mind are to see if there is anything odd
> about the buildbot’s Linux kernel and glibc versions. Maybe run the
> Python script under “strace” to see if anything strange is going on.
>

I did that, and a few other things. Most notably, commenting out the
partial-read resulted in a flawless run, and strace showed it stalling
in the partial read too.

However, as I was doing so (and I just discarded a draft message where
I'd been typing up notes), my entire system went kerblooie, and I've
spent the last day rebuilding stuff from scratch. When I get around to
it, I'll rebuild the buildbot VM - and it'll be Debian Jessie (current
stable), because there's no particular reason to use Wheezy
(oldstable). So the problem will almost certainly disappear.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fun with ancient unsupported platforms

[Ryan Gonzalez]

win16 doesn't seem to have important stuff:

https://github.com/python/cpython/search?utf8=✓="win16;

On January 28, 2016 8:57:20 AM CST, Larry Hastings  wrote:
>
>
>Check out and cd into Python trunk.
>
>% grep -Ri win16 * | wc
>  10  66 625
>
>% grep -Ri nextstep | wc
>  23 1191328
>
>% grep -Ri rhapsody * | wc
>  47 2693390
>
>% grep -Ri msdos * | wc
>  56 3813895
>  % grep -Ri ms-dos * | wc
>  20 1801425
>
>
>win16!  *laughs* *wipes tear from eye*
>
>It's currently 2016.  Perhaps it's time to remove all vestiges of these
>
>unsupported operating systems nobody's cared about since a year that 
>started with a '1'?
>
>
>//arry/
>
>p.s. I suspect some of the uses of "rhapsody" are actually live code 
>used for OS X.  So this isn't necessarily dead code, some of it is 
>merely long-out-of-date comments.
>
>p.p.s. At least there were no references to "taligent", "copland", or 
>"gershwin"...!
>
>
>
>
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fun with ancient unsupported platforms

[Larry Hastings]

Check out and cd into Python trunk.

% grep -Ri win16 * | wc
 10  66 625

% grep -Ri nextstep | wc
 23 1191328

% grep -Ri rhapsody * | wc
 47 2693390

% grep -Ri msdos * | wc
 56 3813895
 % grep -Ri ms-dos * | wc
 20 1801425


win16!  *laughs* *wipes tear from eye*

It's currently 2016.  Perhaps it's time to remove all vestiges of these 
unsupported operating systems nobody's cared about since a year that 
started with a '1'?



//arry/

p.s. I suspect some of the uses of "rhapsody" are actually live code 
used for OS X.  So this isn't necessarily dead code, some of it is 
merely long-out-of-date comments.


p.p.s. At least there were no references to "taligent", "copland", or 
"gershwin"...!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com