Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ANNOUNCEMENT: Python 2.2.1 for DOS test release

0 views
Skip to first unread message

deckerben

unread,
May 19, 2002, 3:40:17 PM5/19/02
to
Hello group,

A DJGPP-built Python 2.2.1 binary has been uploaded to
http://phaseit.net/Python/python-djgpp.221.tar.gz .

For those familiar with Python:
This package works much better when used with DJGPP, a full ncurses
installation, and the Python 2.2 standard libraries.
Dynamic Linking:
The Dynamic Linking package (libdl.a) from Andrew Zabolotny has been
used in this build, but has not been tested. Dlmodule is part of this port,
but has not been tested.

Libsocket:
Richard Dawe's libsocket port may enable some low-level options, but
socketmodule.c still does not compile as of now. Libsocket is not being
actively developed.

Libxsltmod:
Yes, this program should be able to do all of your XSLT 1.0
processing, as well (Actually, my goal is that Python can to the dishes,
too, by the time that I'm done with it :-)
This has been made possible by Dave Kuhlman's Python wrapper for the
Gnome LibXSLT library. See the subfolder XSLT.
See http://www.rexx.com/~dkuhlman/libxsltmod.html and
http://xmlsoft.org/XSLT.html.

Ncurses support:
It made it in(ncurses 5.2) but I haven't tested it on systems other
than my own.
Terminfo is a terminal interpretation database that must be kept in
the directory structure in which it comes. Additional terminals can be
compiled using the accompanying tic.exe.


Python is an interpreted, interactive, object-oriented programming
language. Its use varies from networking to shell scripting.

Ben


Richard Dawe

unread,
May 19, 2002, 4:53:14 PM5/19/02
to DJGPP newsgroup
Hello.

deckerben wrote:
>
> Hello group,
>
> A DJGPP-built Python 2.2.1 binary has been uploaded to
> http://phaseit.net/Python/python-djgpp.221.tar.gz .

Wow! How difficult was it to port? Were any source changes required?

[snip]

> Richard Dawe's libsocket port may enable some low-level options, but
> socketmodule.c still does not compile as of now. Libsocket is not being
> actively developed.

[snip]

Personally I would not bother trying to make Python work with libsocket, since
libsocket is unsupported. It's more trouble than it's worth. Is a socket
library currently required to build Python?

Thanks, regards,

--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

deckerben

unread,
May 19, 2002, 6:27:35 PM5/19/02
to
> Wow! How difficult was it to port? Were any source changes required?

A little. I'm not that good, and I needed some help. But it seems OK now,
all the scripts seem to work. I wrote a *small* README outlineing some of
the steps needed to set it up. If anyone has trouble, please let me know in
this group, because I have decided not to announce it *just* yet to the
python guys(and gals - sorry Eli) :-)

Actually, I did it because I was looking for a faster alternative to Batch
files.

> > Richard Dawe's libsocket port may enable some low-level options,
but
> > socketmodule.c still does not compile as of now. Libsocket is not being
> > actively developed.
> [snip]
>
> Personally I would not bother trying to make Python work with libsocket,
since
> libsocket is unsupported. It's more trouble than it's worth. Is a socket
> library currently required to build Python?

I have Watt32 downloaded, but I haven't played with it yet. You know, Python
has a socketmodule, right? well... for it to work ... it needs a socket.
Socketmodule is missing entirely this go-around. maybe someday I'll find an
answer. BTW: thanks for keeping the Libsocket page up, even if you don't
support it anymore.

Ben


Eli Zaretskii

unread,
May 20, 2002, 12:54:27 AM5/20/02
to deckerben, dj...@delorie.com

On Mon, 20 May 2002, deckerben wrote:

> because I have decided not to announce it *just* yet to the
> python guys(and gals - sorry Eli) :-)

Who, me? Why did you feel you have to apologize? ;-)

Richard Dawe

unread,
May 20, 2002, 2:21:38 PM5/20/02
to DJGPP newsgroup
Hello.

deckerben wrote:
>
> > Wow! How difficult was it to port? Were any source changes required?
>
> A little. I'm not that good, and I needed some help. But it seems OK now,
> all the scripts seem to work. I wrote a *small* README outlineing some of
> the steps needed to set it up. If anyone has trouble, please let me know in
> this group, because I have decided not to announce it *just* yet to the
> python guys(and gals - sorry Eli) :-)

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!)

> 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.



> > > Richard Dawe's libsocket port may enable some low-level options,
> but
> > > socketmodule.c still does not compile as of now. Libsocket is not being
> > > actively developed.
> > [snip]
> >
> > Personally I would not bother trying to make Python work with libsocket,
> since
> > libsocket is unsupported. It's more trouble than it's worth. Is a socket
> > library currently required to build Python?
>
> I have Watt32 downloaded, but I haven't played with it yet. You know, Python
> has a socketmodule, right? well... for it to work ... it needs a socket.
> Socketmodule is missing entirely this go-around. maybe someday I'll find an
> answer.

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.

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.

In the worst case a Python program could invoke a program to do what it wants,
e.g.: get a web page.

> BTW: thanks for keeping the Libsocket page up, even if you don't
> support it anymore.

It's no trouble. 8) Actually, I hope there are some useful bits of information
and links there.

Thanks, bye,

deckerben

unread,
May 20, 2002, 6:13:54 PM5/20/02
to
> 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


Richard Dawe

unread,
May 21, 2002, 5:53:29 PM5/21/02
to DJGPP newsgroup
Hello.

deckerben wrote:
[snip]


> 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.

I won't really be able to comment on how you've ported it, unless I can see
the diffs. I'm not sure I know enough Python, to test out the port. ;)

[snip]


> > 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.

Yes. That's the problem. Incidentally there is a driver for Windows NT (and
maybe it works with 2k, XP) that tries to emulate the Windows '95 interface
that libsocket uses. It could do with some more testing & work:

http://www.phekda.freeserve.co.uk/gabor/wsockvdd/

Unfortunately it did not work very well last time I tried it.

> 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.

When you say "tries its own connection via comm port", do you mean that the
program should make a connection via modem and run all the networking
protocols itself? That's quite a task. Also it would not work very well on a
LAN.

Bye,

deckerben

unread,
May 27, 2002, 1:04:54 PM5/27/02
to
> When you say "tries its own connection via comm port", do you mean that
the
> program should make a connection via modem and run all the networking
> protocols itself? That's quite a task. Also it would not work very well on
a
> LAN.

True, but wouldn't it be even more challenging to build a module that
supports a large array of external DOS networking drivers? I don't think
that "one-size-fits-all" there, or am I mistaken?

Ben


Richard Dawe

unread,
May 27, 2002, 5:30:12 PM5/27/02
to
Hello.

deckerben wrote:

Well, you've certainly got a large challenge there! 8)

But that's pretty much what Watt-32 does with packet drivers. You can get
packet drivers for LAN cards and modems.

Regards,

0 new messages