/PC/os2emx/README.os2emx
http://unladen-swallow.googlecode.com/ · Unknown · 701 lines · 535 code · 166 blank · 0 comment · 0 complexity · 7004a862f10f0905c123ebc609cf6071 MD5 · raw file
- This is a port of Python 2.6 to OS/2 using the EMX development tools
- =========================================================================
- What's new since the previous release
- -------------------------------------
- Another day, another version...
- Licenses and info about Python and EMX
- --------------------------------------
- Please read the file README.Python-2.6 included in this package for
- information about Python 2.6. This file is the README file from the
- Python 2.6 source distribution available via http://www.python.org/
- and its mirrors. The file LICENCE.Python-2.6 is the text of the Licence
- from the Python 2.6 source distribution.
- Note that the EMX package that this package depends on is released under
- the GNU General Public Licence. Please refer to the documentation
- accompanying the EMX Runtime libraries for more information about the
- implications of this. A copy of version 2 of the GPL is included as the
- file COPYING.gpl2.
- Readline and GDBM are covered by the GNU General Public Licence. I think
- Eberhard Mattes' porting changes to BSD DB v1.85 are also GPL'ed (BSD DB
- itself is BSD Licenced). ncurses and expat appear to be covered by MIT
- style licences - please refer to the source distributions for more detail.
- zlib is distributable under a very free license. GNU UFC is under the
- GNU LGPL (see file COPYING.lib).
- My patches to the Python-2.x source distributions, and any other packages
- used in this port, are placed in the public domain.
- This software is provided 'as-is', without any express or implied warranty.
- In no event will the author be held liable for any damages arising from the
- use of the software.
- I do hope however that it proves useful to someone.
- Other ports
- -----------
- There have been ports of previous versions of Python to OS/2.
- The best known would be that by Jeff Rush, most recently of version
- 1.5.2. Jeff used IBM's Visual Age C++ (v3) for his ports, and his
- patches have been included in the Python 2.6 source distribution.
- Andy Zabolotny implemented a port of Python v1.5.2 using the EMX
- development tools. His patches against the Python v1.5.2 source
- distribution have become the core of this port, and without his efforts
- this port wouldn't exist. Andy's port also appears to have been
- compiled with his port of gcc 2.95.2 to EMX, which I have but have
- chosen not to use for the binary distribution of this port (see item 16
- of the "YOU HAVE BEEN WARNED" section below).
- It is possible to have these earlier ports still usable after installing
- this port - see the README.os2emx.multiple_versions file, contributed by
- Dr David Mertz, for a suggested approach to achieving this.
- Software requirements
- ---------------------
- This package requires the EMX Runtime package, available from the
- Hobbes (http://hobbes.nmsu.edu/) and LEO (http://archiv.leo.org/)
- archives of OS/2 software. I have used EMX version 0.9d fix04 in
- developing this port.
- My development system is running OS/2 v4 with fixpack 12.
- 3rd party software which has been linked into dynamically loaded modules:
- - ncurses (see http://dickey.his.com/ for more info, v5.2)
- - GNU Readline (Kai Uwe Rommel's port available from Hobbes or LEO, v2.1)
- - GNU GDBM (Kai Uwe Rommel's port available from Hobbes or LEO, v1.7.3)
- - zlib (derived from Hung-Chi Chu's port of v1.1.3, v1.1.4)
- - expat (distributed with Python, v1.95.6)
- - GNU UFC (Kai Uwe Rommel's port available from LEO, v2.0.4)
- About this port
- ---------------
- I have attempted to make this port as complete and functional as I can,
- notwithstanding the issues in the "YOU HAVE BEEN WARNED" section below.
- Core components:
- Python.exe is linked as an a.out executable, ie using EMX method E1
- to compile & link the executable. This is so that fork() works (see
- "YOU HAVE BEEN WARNED" item 1).
- Python26.dll is created as a normal OMF DLL, with an OMF import
- library and module definition file. There is also an a.out (.a) import
- library to support linking the DLL to a.out executables. The DLL
- requires the EMX runtime DLLs.
- This port has been built with complete support for multithreading.
- Modules:
- With the exception of modules that have a significant code size, or are
- not recommended or desired for normal use, the standard modules are now
- built into the core DLL rather than configured as dynamically loadable
- modules. This is for both reasons of performance (startup time) and
- memory use (lots of small DLLs fragment the address space).
- I haven't yet changed the building of Python's dynamically loadable
- modules over to using the DistUtils.
- See "YOU HAVE BEEN WARNED" item 3 for notes about the fcntl module, and
- "YOU HAVE BEEN WARNED" item 10 for notes about the pwd and grp modules.
- This port supports case sensitive module import semantics, matching
- the Windows release. This can be deactivated by setting the PYTHONCASEOK
- environment variable (the value doesn't matter) - see "YOU HAVE BEEN WARNED"
- item 12.
- Optional modules:
- Where I've been able to locate the required 3rd party packages already
- ported to OS/2, I've built and included them.
- These include ncurses (_curses, _curses_panel), BSD DB (bsddb185),
- GNU GDBM (gdbm, dbm), zlib (zlib), GNU Readline (readline), and GNU UFC
- (crypt).
- Expat is now included in the Python release sourceball, and the pyexpat
- module is always built.
- I have built these modules statically linked against the 3rd party
- libraries. Unfortunately my attempts to use the dll version of GNU
- readline have been a dismal failure, in that when the dynamically
- linked readline module is active other modules immediately provoke a
- core dump when imported.
- Only the BSD DB package (part of the BSD package distributed with EMX)
- needs source modifications to be used for this port, pertaining to use
- of errno with multithreading.
- The other packages, except for ncurses and zlib, needed Makefile changes
- for multithreading support but no source changes.
- The _curses_panel module is a potential problem - see "YOU HAVE BEEN
- WARNED" item 13.
- Upstream source patches:
- No updates to the Python 2.6 release have become available.
- Eberhard Mattes' EMXFIX04 update to his EMX 0.9d tools suite includes
- bug fixes for the BSD DB library. The bsddb module included in this
- port incorporates these fixes.
- Library and other distributed Python code:
- The Python standard library lives in the Lib directory. All the standard
- library code included with the Python 2.6 source distribution is included
- in the binary archive, with the exception of the dos-8x3 and tkinter
- subdirectories which have been omitted to reduce the size of the binary
- archive - the dos-8x3 components are unnecessary duplicates and Tkinter
- is not supported by this port (yet). All the plat-* subdirectories in the
- source distribution have also been omitted, except for the plat-os2emx
- subdirectory.
- The Tools and Demo directories contain a collection of Python scripts.
- To reduce the size of the binary archive, the Demo/sgi, Demo/Tix,
- Demo/tkinter, Tools/audiopy and Tools/IDLE subdirectories have been
- omitted as not being supported by this port. The Misc directory has
- also been omitted.
- All subdirectories omitted from the binary archive can be reconstituted
- from the Python 2.6 source distribution, if desired.
- Support for building Python extensions:
- The Config subdirectory contains the files describing the configuration
- of the interpreter and the Makefile, import libraries for the Python DLL,
- and the module definition file used to create the Python DLL. The
- Include subdirectory contains all the standard Python header files
- needed for building extensions.
- As I don't have the Visual Age C++ compiler, I've made no attempt to
- have this port support extensions built with that compiler.
- Packaging
- ---------
- This port is packaged as follows:
- - python-2.6-os2emx-bin-03????.zip (binaries, library modules)
- - python-2.6-os2emx-src-03???? (patches+makefiles for non-Python code)
- As all the Python specific patches for the port are now part of the
- Python release tarball, only the patches and makefiles involved in
- building external libraries for optional extensions are included in
- the source archive.
- Documentation for the Python language, as well as the Python 2.6
- source distibution, can be obtained from the Python website
- (http://www.python.org/) or the Python project pages at Sourceforge
- (http://sf.net/projects/python/).
- Installation
- ------------
- Obtain and install, as per the included instructions, the EMX runtime
- package.
- Unpack this archive, preserving the subdirectories, in the root directory
- of the drive where you want Python to live.
- Add the Python directory (eg C:\Python26) to the PATH and LIBPATH
- variables in CONFIG.SYS.
- You should then set the PYTHONHOME and PYTHONPATH environment variables
- in CONFIG.SYS.
- PYTHONHOME should be set to Python's top level directory. PYTHONPATH
- should be set to the semicolon separated list of principal Python library
- directories.
- I use:
- SET PYTHONHOME=F:/Python26
- SET PYTHONPATH=F:/Python26/Lib;F:/Python26/Lib/plat-os2emx;
- F:/Python26/Lib/lib-dynload;F:/Python26/Lib/site-packages
- NOTE!: the PYTHONPATH setting above is linewrapped for this document - it
- should all be on one line in CONFIG.SYS!
- If you wish to use the curses module, you should set the TERM and TERMINFO
- environment variables appropriately.
- If you don't already have ncurses installed, I have included a copy of the
- EMX subset of the Terminfo database included with the ncurses-5.2 source
- distribution. This can be used by setting the TERMINFO environment variable
- to the path of the Terminfo subdirectory below the Python home directory.
- On my system this looks like:
- SET TERMINFO=F:/Python26/Terminfo
- For the TERM environment variable, I would try one of the following:
- SET TERM=ansi
- SET TERM=os2
- SET TERM=window
- You will have to reboot your system for these changes to CONFIG.SYS to take
- effect.
- If you wish to compile all the included Python library modules to bytecode,
- you can change into the Python home directory and run the COMPILEALL.CMD
- batch file.
- You can execute the regression tests included with the Python 2.6 source
- distribution by changing to the Python 2.6 home directory and executing the
- REGRTEST.CMD batch file. The following tests are known to fail at this
- time:
- - test_mhlib (I don't know of any port of MH to OS/2);
- - test_strptime (see "YOU HAVE BEEN WARNED" item 22);
- - test_time (see "YOU HAVE BEEN WARNED" item 22);
- - test_posixpath (see "YOU HAVE BEEN WARNED" item 23).
- Note that some of the network related tests expect the loopback interface
- (interface "lo", with IP address 127.0.0.1) to be enabled, which from my
- experience is not the default configuration. Additionally, test_popen2
- expects the "cat" utility (such as found in ports of the GNU tools) to
- be installed.
- Building from source
- --------------------
- With the EMX port now checked into Python's CVS repository, the build
- infrastructure is part of the Python release sourceball.
- Prerequisites
- First and foremost, you need an operational EMX development installation -
- EMX v0.9d with fix04 (the latest at time of writing) & the gcc 2.8.1
- compiler released by Eberhard Mattes is the recommended setup.
- If you have a different version of gcc installed, see "YOU HAVE BEEN
- WARNED" item 16.
- Other items of software required:-
- - GNU make (I'm using v3.76.1)
- - rm, cp, mkdir from the GNU file utilities package
- - GNU find
- - GNU sed
- Procedure
- 0. all changes mentioned apply to files in the PC/os2emx subdirectory
- of the Python release source tree. make is also executed from this
- directory, so change into this directory before proceeding.
- 1. decide if you need to change the location of the Python installation.
- If you wish to do this, set the value of the Makefile variable LIB_DIR
- to the directory you wish to use for PYTHONHOME
- (eg /usr/local/lib/python2.6).
- If you want Python to find its library without the PYTHONHOME
- environment variable set, set the value of the Makefile variable
- FIXED_PYHOME to "yes" (uncomment the appropriate line).
- 2. If you wish the Python executables (python.exe, pythonpm.exe & pgen.exe)
- to be installed in a directory other than the PYTHONHOME directory, set
- the value of the Makefile variable EXE_DIR to the appropriate directory.
- 3. If you wish the Python core DLL (python26.dll) to be installed in a
- directory other than the directory in which the Python executables are
- installed (by default, the PYTHONHOME directory), set the value of the
- Makefile variable DLL_DIR to the appropriate directory. This DLL must
- be placed in a directory on the system's LIBPATH, or that gets set
- with BEGINLIBPATH or ENDLIBPATH.
- 4. If you have installed any of the libraries that can be used to build
- optional Python modules, set the value of the relevant HAVE_<package>
- Makefile variable to "yes". The Makefile currently supports:
- library Makefile variable
- ........................................
- zlib (1.1.4) HAVE_ZLIB
- GNU UltraFast Crypt HAVE_UFC
- Tcl/Tk HAVE_TCLTK (not known to work)
- GNU Readline HAVE_GREADLINE
- BSD DB (v1.85) HAVE_BSDDB
- ncurses HAVE_NCURSES
- GNU gdbm HAVE_GDBM
- libbz2 HAVE_BZ2
- OpenSSL HAVE_OPENSSL
- Please note that you need to check that what you have installed
- is compatible with Python's build options. In particular, the
- BSD DB v1.85 library needs to be rebuilt with a source patch for
- multithread support (doesn't change the library's reentrant status
- but allows it to be linked to Python which is multithreaded).
- Widely available binary packages of other librarys & DLLs are
- not built/linked with multithread support. Beware!
- Also note that the Makefile currently expects any libraries to be
- found with the default library search path. You may need to add
- -L switches to the LDFLAGS Makefile variable if you have installed
- libraries in directories not in the default search path (which can
- be controlled by the LIBRARY_PATH environment variable used by EMX).
- 5. make
- It is usually a good idea to redirect the stdout and stderr streams
- of the make process to log files, so that you can review any messages.
- 6. make test
- This runs the Python regression tests, and completion is a sign of
- a usable build. You should check the list of skipped modules to
- ensure that any optional modules you selected have been built;
- checking the list of failures against the list of known failures
- elsewhere in this document is also prudent.
- 7. make install
- >>>>>> NOT YET COMPLETE <<<<<<
- 8. change to a directory outside the Python source tree and start Python.
- Check the version and build date to confirm satisfactory installation.
- YOU HAVE BEEN WARNED!!
- ----------------------
- I know about a number of nasties in this port.
- 1. Eberhard Mattes, author of EMX, writes in his documentation that fork()
- is very inefficient in the OS/2 environment. It also requires that the
- executable be linked in a.out format rather than OMF. Use the os.exec
- and/or the os.spawn family of functions where possible.
- 2. In the absence of GNU Readline, terminating the interpreter requires a
- control-Z (^Z) followed by a carriage return. Jeff Rush documented this
- problem in his Python 1.5.2 port. With Readline, a control-D (^D) works
- as per the standard Unix environment.
- 3. EMX only has a partial implementation of fcntl(). The fcntl module
- in this port supports what EMX supports. If fcntl is important to you,
- please review the EMX C Library Reference (included in .INF format in the
- EMXVIEW.ZIP archive as part of the complete EMX development tools suite).
- Because of other side-effects I have modified the test_fcntl.py test
- script to deactivate the exercising of the missing functionality.
- 4. the PyBSDDB3 module has been imported into the Python standard
- library, with the intent of superceding the BSDDB 1.85 module (bsddb).
- As I don't yet have a satisfactory port of Sleepcat's more recent DB
- library (3.3.x/4.0.x/4.1.x), I haven't included a binary of this
- module. I have left the Python part of the PyBSDDB package in this
- distribution for completeness.
- 5. As a consequence of the PyBSDDB3 module being imported, the former
- BSD DB (bsddb) module, linked against the DB v1.85 library from EMX,
- has been renamed bsddb185. The bsddb185 module will not be built by
- default on most platforms, but in the absence of a PyBSDDB3 module I
- have retained it in the EMX port.
- Version 1.85 of the DB library is widely known to have bugs, although
- some patches have become available (and are incorporated into the
- included bsddb185 module). Unless you have problems with software
- licenses which would rule out GDBM (and the dbm module because it is
- linked against the GDBM library) or need it for file format compatibility,
- you may be better off deleting it and relying on GDBM.
- Any code you have which uses the v1.85 bsddb module can be modified to
- use the renamed module by changing
- import bsddb
- to
- import bsddb185 as bsddb
- 6. The readline module has been linked against ncurses rather than the
- termcap library supplied with EMX.
- 7. I have configured this port to use "/" as the preferred path separator
- character, rather than "\" ('\\'), in line with the convention supported
- by EMX. Backslashes are still supported of course, and still appear in
- unexpected places due to outside sources that don't get normalised.
- 8. While the DistUtils components are now functional, other
- packaging/binary handling tools and utilities such as those included in
- the Demo and Tools directories - freeze in particular - are unlikely to
- work. If you do get them going, I'd like to know about your success.
- 9. I haven't set out to support the [BEGIN|END]LIBPATH functionality
- supported by one of the earlier ports (Rush's??). If it works let me know.
- 10. As a result of the limitations imposed by EMX's library routines, the
- standard extension module pwd only synthesises a simple passwd database,
- and the grp module cannot be supported at all.
- I have written pure Python substitutes for pwd and grp, which can process
- real passwd and group files for those applications (such as MailMan) that
- require more than EMX emulates. I have placed pwd.py and grp.py in
- Lib/plat-os2emx, which is usually before Lib/lib-dynload (which contains
- pwd.pyd) in the PYTHONPATH. If you have become attached to what pwd.pyd
- supports, you can put Lib/lib-dynload before Lib/plat-os2emx in PYTHONPATH
- or delete/rename pwd.py & grp.py.
- pwd.py & grp.py support locating their data files by looking in the
- environment for them in the following sequence:
- pwd.py: $ETC_PASSWD (%ETC_PASSWD%)
- $ETC/passwd (%ETC%/passwd)
- $PYTHONHOME/Etc/passwd (%PYTHONHOME%/Etc/passwd)
- grp.py: $ETC_GROUP (%ETC_GROUP%)
- $ETC/group (%ETC%/group)
- $PYTHONHOME/Etc/group (%PYTHONHOME%/Etc/group)
- The ETC_PASSWD and ETC_GROUP environment variables are intended to allow
- support for multiple passwd/grp files, where other applications may not
- support as wide a variety of input variations (drive remappings,
- separators etc).
- Both modules support using either the ":" character (Unix standard) or
- ";" (OS/2, DOS, Windows standard) field separator character, and pwd.py
- implements the following drive letter conversions for the home_directory and
- shell fields (for the ":" separator only):
- $x -> x:
- x; -> x:
- Example versions of passwd and group are in the Etc subdirectory. The
- regression tests (test_pwd and test_grp) will fail if valid password and
- group files cannot be found, but should pass otherwise.
- Be aware that Python's pwd & group modules are for reading password and
- group information only.
- 11. EMX's termios routines don't support all of the functionality now
- exposed by the termios module - refer to the EMX documentation to find
- out what is supported.
- 12. The case sensitive import semantics introduced in Python 2.1 for other
- case insensitive but case preserving file/operating systems (Windows etc),
- have been incorporated into this port, and are active by default. Setting
- the PYTHONCASEOK environment variable (to any value) reverts to the
- previous (case insensitive) semantics. This can be an issue with some
- file management utilities that do not preserve the case of file and
- directory names.
- 13. Because I am statically linking ncurses, the _curses_panel
- module has potential problems arising from separate library data areas.
- To avoid this, I have configured the _curses_.pyd (imported as
- "_curses_panel") to import the ncurses symbols it needs from _curses.dll
- (which is the curses module, but with a .dll extension rather than .pyd
- so that the dynamic loader can actually import the symbols from it as a
- DLL).
- The site module (Lib/site.py) has code added to tweak BEGINLIBPATH so
- that _curses.dll is found when _curses_panel is imported. If you have
- problems attempting to use the _curses_panel support please let me know,
- and I'll have another look at this.
- 14. sys.platform reports "os2emx" instead of "os2". os.name still
- reports "os2". This change was to make it easier to distinguish between
- the VAC++ build (formerly maintained by Michael Muller) and the EMX build
- (this port), principally for DistUtils.
- 15. it appears that the %W substitution in the EMX strftime() routine has
- an off-by-one bug. strftime was listed as passing the regression tests
- in previous releases, but this fact appears to have been an oversight in
- the regression test suite. To fix this really requires a portable
- strftime routine - I'm looking into using one from FreeBSD, but its not
- ready yet.
- 16. I have successfully built this port with Andy Zabolotny's ports of
- pgcc 2.95 and gcc 3.2.1, in addition to EM's gcc 2.8.1. To use the
- bsddb185 module with the gcc 3.2.1 build, I had to recompile the DB library
- with gcc 3.2.1 - I don't know why, but trying to import the module built
- against a DB library compiled with gcc 2.8.1 would result in a SYS3175
- error.
- I have not attempted to compile Python with any version of gcc prior to
- v2.8.1.
- This release sees the default optimisation change to
- "-O3 -fomit-frame-pointer -mprobe". This works fine too for pgcc 2.95
- but not for gcc 3.2.1.
- With gcc 3.2.1, -O3 causes 2 unexpected test failures: test_format and
- test_unicode. Both these tests pass if -O2 is instead of -O3 with this
- compiler, and the performance difference is negligible (in contrast to
- gcc 2.8.1 and pgcc 2.95, where the performance difference between the
- 2 optimisation settings approaches 10%).
- 17. os.spawnv() and os.spawnve() expose EMX's library routines rather
- than use the emulation in os.py.
- In order to make use of some of the features this makes available in
- the OS/2 environment, you should peruse the relevant EMX documentation
- (EMXLIB.INF in the EMXVIEW.ZIP archive accompanying the EMX archives
- on Hobbes or LEO). Be aware that I have exposed all the "mode" options
- supported by EMX, but there are combinations that either cannot be
- practically used by/in Python or have the potential to compromise your
- system's stability.
- 18. pythonpm.exe used to be just python.exe with the WINDOWAPI linker
- option set in the pythonpm.def file. In practice, this turns out to do
- nothing useful.
- I have written a replacement which wraps the Python DLL in a genuine
- Presentation Manager application. This version actually runs the
- Python interpreter in a separate thread from the PM shell, in order
- that PythonPM has a functioning message queue as good PM apps should.
- In its current state, PythonPM's window is hidden. It can be displayed,
- although it will have no content as nothing is ever written to the
- window. Only the "hide" button is available. Although the code
- has support for shutting PythonPM down when the Python interpreter is
- still busy (via the "control" menu), this is not well tested and given
- comments I've come across in EMX documentation suggesting that the
- thread killing operation has problems I would suggest caution in
- relying on this capability.
- PythonPM processes commandline parameters normally. The standard input,
- output and error streams are only useful if redirected, as PythonPM's
- window is not a console in any form and so cannot accept or display
- anything. This means that the -i option is ineffective.
- Because the Python thread doesn't create its own message queue, creating
- PM Windows and performing most PM operations is not possible from within
- this thread. How this will affect supporting PM extensions (such as
- Tkinter using a PM port of Tcl/Tk, or wxPython using the PM port of
- WxWindows) is still being researched.
- Note that os.fork() _DOES_NOT_WORK_ in PythonPM - SYS3175s are the result
- of trying. os.spawnv() _does_ work. PythonPM passes all regression tests
- that the standard Python interpreter (python.exe) passes, with the exception
- of test_fork1 and test_socket which both attempt to use os.fork().
- I very much want feedback on the performance, behaviour and utility of
- PythonPM. I would like to add a PM console capability to it, but that
- will be a non-trivial effort. I may be able to leverage the code in
- Illya Vaes' Tcl/Tk port, which would make it easier.
- 19. os.chdir() uses EMX's _chdir2(), which supports changing both drive
- and directory at once. Similarly, os.getcwd() uses EMX's _getcwd()
- which returns drive as well as path.
- 20. pyconfig.h is installed in the Include subdirectory with all
- other include files.
- 21. the default build explicitly sets the number of file handles
- available to a Python process to 250. EMX default is 40, which is
- insufficient for the tempfile regression test (test_tempfile) which
- tries to create 100 temporary files.
- This setting can be overridden via the EMXOPT environment variable:
- set EMXOPT=-h250
- is equivalent to the setting currently used. The emxbind utility (if you
- have it installed) can also be used to permanently change the setting in
- python.exe - please refer to the EMX documentation for more information.
- 22. a pure python strptime module is now part of the Python standard
- library, superceding a platform specific extension module. This module
- leverages the strftime module, and as a result test_strptime fails
- due to the EMX strftime bug in item 20 above.
- 23. test_posixpath attempts to exercise various Posix path related
- functionality. Most of the sub-tests pass, but the "ismount" and
- "samestat" subtests fail:
- - EMX provides not satisfactory mount point emulation, so "ismount"
- cannot succeed;
- - EMX documents that successive stat() calls will produce different
- results, so "samestat" cannot succeed.
- test_posixpath should skip these tests on EMX.
- 24. I have reports of BitTorrent not working. It appears that the
- EMX select() emulation, possibly in concert with bugs in the TCP/IP
- stack, runs into problems under the stress imposed by this application.
- I think it suffices to say that BitTorrent is a fair stress test of a
- system's networking capability.
- 25. In the absence of an EMX implementation of the link() function, I've
- implemented a crude Python emulation, in the file
- Lib/plat-os2emx/_emx_link.py. This is imported into the os module, and
- becomes available as os.link() in the normal way.
- The emulation copies the source file in binary mode, and will fail if
- disk space is exhausted. The call fails if the target already exists.
- There are no guarantees to thread safety with this emulation - beware!
- The emulation was written to support a link() based file locking system
- used in GNU Mailman.
- 26. AF_UNIX sockets, otherwise known as Unix domain sockets, are now
- supported. Unfortunately, there are some traps arising from the
- implementation in IBM's TCP/IP stack:-
- - the path name must start with '\\socket\\' ('/socket/' won't work!),
- with the length of the full path name less than 108 characters;
- - unlike Unix, the socket endpoints don't exist in the filesystem;
- - by default, sockets are in binary mode.
- 27. As of Python 2.4, the mpz, rotor and xreadlines modules have been
- dropped from the Python source tree.
- 28. The subprocess module was added to the standard library relatively
- late in the 2.4 development cycle. Unfortunately I haven't had the
- round tuits to adapt the module to the EMX environment yet, and
- test_subprocess has a number of failures as a result.
- 29. The default stack size for threads has been 64k. This is proving
- insufficient for some codebases, such as Zope. The thread stack size
- still defaults to 64k, but this can now be increased via the stack_size()
- function exposed by the threading & thread modules as well as by defining
- THREAD_STACK_SIZE to an appropriate value in the Makefile (which contains
- a commented out definition for 128kB thread stacks). I have seen
- references to heavy Zope/Plone usage requiring 1MB thread stacks on
- FreeBSD and Linux, but doubt that for most likely usage on OS/2 that
- more than 256kB is necessary. The size of the required stacks (main
- and thread) can vary significantly depending on which version of gcc
- is used along with the compiler optimisations selected. Note that the
- main thread stack size is set during linking and is currently 2MB.
- ... probably other issues that I've not encountered, or don't remember :-(
- If you encounter other difficulties with this port, which can be
- characterised as peculiar to this port rather than to the Python release,
- I would like to hear about them. However I cannot promise to be able to do
- anything to resolve such problems. See the Contact section below...
- To do...
- --------
- In no particular order of apparent importance or likelihood...
- - support Tkinter and/or alternative GUI (wxWindows??)
- Credits
- -------
- In addition to people identified above, I'd like to thank:
- - the BDFL, Guido van Rossum, and crew for Python;
- - Dr David Mertz, for trying out a pre-release of this port;
- - the Python-list/comp.lang.python community;
- - John Poltorak, for input about pwd/grp.
- Contact
- -------
- Constructive feedback, negative or positive, about this port is welcome
- and should be addressed to me at the e-mail addresses below.
- I have a private mailing list for announcements of fixes & updates to
- this port. If you wish to receive such e-mail announcments, please send
- me an e-mail requesting that you be added to this list.
- Andrew MacIntyre
- E-mail: andymac@bullseye.apana.org.au, or andymac@pcug.org.au
- Web: http://www.andymac.org/
- 28 January, 2008.