Mail Archives: djgpp/2002/05/20/18:19:50
> 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
- Raw text -