From: "deckerben" Newsgroups: comp.os.msdos.djgpp References: <3ce7fc1f$0$26970$9b622d9e AT news DOT freenet DOT de> <3CE810BA DOT FCA8CEDF AT phekda DOT freeserve DOT co DOT uk> <3ce8232a$0$26959$9b622d9e AT news DOT freenet DOT de> <3CE93EB2 DOT 2DD59789 AT phekda DOT freeserve DOT co DOT uk> Subject: Re: ANNOUNCEMENT: Python 2.2.1 for DOS test release Date: Tue, 21 May 2002 00:13:54 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 68 Message-ID: <3ce97174$0$23709$9b622d9e@news.freenet.de> NNTP-Posting-Host: 213.6.61.201 X-Trace: 1021931893 news.freenet.de 23709 213.6.61.201 X-Complaints-To: abuse AT freenet DOT de To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > Do you have diffs against the original sources? I can take a look at the > diffs, if you'd like a second opinion. > > (I added a DJGPP port of Python to my list of things to do on Friday, which is > a pretty strange coincidence!) I'm really happy for any advice that is given to me in a positive manor. I will try to make up a diff package and send it to you. By far the biggest known bug of the current test release is that running any setup.py script seems to crash - usually running out of memory when Python tries to start up GCC. I have a new version underway, one with the NUMERIC library built in (from http://www.pfdubois.com/numpy/ ), and some other small fixes. But I want to wait and see what the score is with the first release before I upload the next. So I would appreciate feedback. I want to take the package in the direction of scientific visualization, using various XML implementations as data-storage format(s). But that's all a long way down the road. Step-by-step. > > Actually, I did it because I was looking for a faster alternative to Batch > > files. > > That's a long way to go, just to get faster scripts! But I can understand > that. For 'faster scripts' I realized that I was going to implement a whole new technology into my system - one that could replace my slow-running batch files (that need to call a new executable every line) with a script-interpreter that could do the lion's share under it's own roof. I decided I wanted to make it count ... so I didn't want to play with some software toy, but it would need to be a tested, extensible and industrial-strength solution... preferably one with a lot of support and 3rd party development. I considered Perl, Python and Lisp and chose Python. > I haven't really started learning Python yet. I've done some Zope stuff and > I'm going to write some stuff at work in Python, but I'm not at all familiar > with the language. I've been so busy porting the interpreter, I haven't had time to learn it either :-) But I got some mail from other developers, a few of whom also started out the same way, by first porting it to their platform. > The problem with socket libraries is that they only work on a subset of the > platforms that DJGPP runs on. That really is pretty inconvenient for the user. > Until there's one library for all platforms, I'm not sure it's worth trying to > add Socketmodule. Then, I guess what is needed is a C library (please, NOT TSR) that can detect a Win95/NT winsock-tcpip connection _if_it_exists. Otherwise, it tries its own connection via comm port. It needs to have all the Libsocket definitions, though, so that porting UNIX stuff is made easy. Just my thinking. Ben