/PC/os2emx/README.os2emx

http://unladen-swallow.googlecode.com/ · Unknown · 701 lines · 535 code · 166 blank · 0 comment · 0 complexity · 7004a862f10f0905c123ebc609cf6071 MD5 · raw file

  1. This is a port of Python 2.6 to OS/2 using the EMX development tools
  2. =========================================================================
  3. What's new since the previous release
  4. -------------------------------------
  5. Another day, another version...
  6. Licenses and info about Python and EMX
  7. --------------------------------------
  8. Please read the file README.Python-2.6 included in this package for
  9. information about Python 2.6. This file is the README file from the
  10. Python 2.6 source distribution available via http://www.python.org/
  11. and its mirrors. The file LICENCE.Python-2.6 is the text of the Licence
  12. from the Python 2.6 source distribution.
  13. Note that the EMX package that this package depends on is released under
  14. the GNU General Public Licence. Please refer to the documentation
  15. accompanying the EMX Runtime libraries for more information about the
  16. implications of this. A copy of version 2 of the GPL is included as the
  17. file COPYING.gpl2.
  18. Readline and GDBM are covered by the GNU General Public Licence. I think
  19. Eberhard Mattes' porting changes to BSD DB v1.85 are also GPL'ed (BSD DB
  20. itself is BSD Licenced). ncurses and expat appear to be covered by MIT
  21. style licences - please refer to the source distributions for more detail.
  22. zlib is distributable under a very free license. GNU UFC is under the
  23. GNU LGPL (see file COPYING.lib).
  24. My patches to the Python-2.x source distributions, and any other packages
  25. used in this port, are placed in the public domain.
  26. This software is provided 'as-is', without any express or implied warranty.
  27. In no event will the author be held liable for any damages arising from the
  28. use of the software.
  29. I do hope however that it proves useful to someone.
  30. Other ports
  31. -----------
  32. There have been ports of previous versions of Python to OS/2.
  33. The best known would be that by Jeff Rush, most recently of version
  34. 1.5.2. Jeff used IBM's Visual Age C++ (v3) for his ports, and his
  35. patches have been included in the Python 2.6 source distribution.
  36. Andy Zabolotny implemented a port of Python v1.5.2 using the EMX
  37. development tools. His patches against the Python v1.5.2 source
  38. distribution have become the core of this port, and without his efforts
  39. this port wouldn't exist. Andy's port also appears to have been
  40. compiled with his port of gcc 2.95.2 to EMX, which I have but have
  41. chosen not to use for the binary distribution of this port (see item 16
  42. of the "YOU HAVE BEEN WARNED" section below).
  43. It is possible to have these earlier ports still usable after installing
  44. this port - see the README.os2emx.multiple_versions file, contributed by
  45. Dr David Mertz, for a suggested approach to achieving this.
  46. Software requirements
  47. ---------------------
  48. This package requires the EMX Runtime package, available from the
  49. Hobbes (http://hobbes.nmsu.edu/) and LEO (http://archiv.leo.org/)
  50. archives of OS/2 software. I have used EMX version 0.9d fix04 in
  51. developing this port.
  52. My development system is running OS/2 v4 with fixpack 12.
  53. 3rd party software which has been linked into dynamically loaded modules:
  54. - ncurses (see http://dickey.his.com/ for more info, v5.2)
  55. - GNU Readline (Kai Uwe Rommel's port available from Hobbes or LEO, v2.1)
  56. - GNU GDBM (Kai Uwe Rommel's port available from Hobbes or LEO, v1.7.3)
  57. - zlib (derived from Hung-Chi Chu's port of v1.1.3, v1.1.4)
  58. - expat (distributed with Python, v1.95.6)
  59. - GNU UFC (Kai Uwe Rommel's port available from LEO, v2.0.4)
  60. About this port
  61. ---------------
  62. I have attempted to make this port as complete and functional as I can,
  63. notwithstanding the issues in the "YOU HAVE BEEN WARNED" section below.
  64. Core components:
  65. Python.exe is linked as an a.out executable, ie using EMX method E1
  66. to compile & link the executable. This is so that fork() works (see
  67. "YOU HAVE BEEN WARNED" item 1).
  68. Python26.dll is created as a normal OMF DLL, with an OMF import
  69. library and module definition file. There is also an a.out (.a) import
  70. library to support linking the DLL to a.out executables. The DLL
  71. requires the EMX runtime DLLs.
  72. This port has been built with complete support for multithreading.
  73. Modules:
  74. With the exception of modules that have a significant code size, or are
  75. not recommended or desired for normal use, the standard modules are now
  76. built into the core DLL rather than configured as dynamically loadable
  77. modules. This is for both reasons of performance (startup time) and
  78. memory use (lots of small DLLs fragment the address space).
  79. I haven't yet changed the building of Python's dynamically loadable
  80. modules over to using the DistUtils.
  81. See "YOU HAVE BEEN WARNED" item 3 for notes about the fcntl module, and
  82. "YOU HAVE BEEN WARNED" item 10 for notes about the pwd and grp modules.
  83. This port supports case sensitive module import semantics, matching
  84. the Windows release. This can be deactivated by setting the PYTHONCASEOK
  85. environment variable (the value doesn't matter) - see "YOU HAVE BEEN WARNED"
  86. item 12.
  87. Optional modules:
  88. Where I've been able to locate the required 3rd party packages already
  89. ported to OS/2, I've built and included them.
  90. These include ncurses (_curses, _curses_panel), BSD DB (bsddb185),
  91. GNU GDBM (gdbm, dbm), zlib (zlib), GNU Readline (readline), and GNU UFC
  92. (crypt).
  93. Expat is now included in the Python release sourceball, and the pyexpat
  94. module is always built.
  95. I have built these modules statically linked against the 3rd party
  96. libraries. Unfortunately my attempts to use the dll version of GNU
  97. readline have been a dismal failure, in that when the dynamically
  98. linked readline module is active other modules immediately provoke a
  99. core dump when imported.
  100. Only the BSD DB package (part of the BSD package distributed with EMX)
  101. needs source modifications to be used for this port, pertaining to use
  102. of errno with multithreading.
  103. The other packages, except for ncurses and zlib, needed Makefile changes
  104. for multithreading support but no source changes.
  105. The _curses_panel module is a potential problem - see "YOU HAVE BEEN
  106. WARNED" item 13.
  107. Upstream source patches:
  108. No updates to the Python 2.6 release have become available.
  109. Eberhard Mattes' EMXFIX04 update to his EMX 0.9d tools suite includes
  110. bug fixes for the BSD DB library. The bsddb module included in this
  111. port incorporates these fixes.
  112. Library and other distributed Python code:
  113. The Python standard library lives in the Lib directory. All the standard
  114. library code included with the Python 2.6 source distribution is included
  115. in the binary archive, with the exception of the dos-8x3 and tkinter
  116. subdirectories which have been omitted to reduce the size of the binary
  117. archive - the dos-8x3 components are unnecessary duplicates and Tkinter
  118. is not supported by this port (yet). All the plat-* subdirectories in the
  119. source distribution have also been omitted, except for the plat-os2emx
  120. subdirectory.
  121. The Tools and Demo directories contain a collection of Python scripts.
  122. To reduce the size of the binary archive, the Demo/sgi, Demo/Tix,
  123. Demo/tkinter, Tools/audiopy and Tools/IDLE subdirectories have been
  124. omitted as not being supported by this port. The Misc directory has
  125. also been omitted.
  126. All subdirectories omitted from the binary archive can be reconstituted
  127. from the Python 2.6 source distribution, if desired.
  128. Support for building Python extensions:
  129. The Config subdirectory contains the files describing the configuration
  130. of the interpreter and the Makefile, import libraries for the Python DLL,
  131. and the module definition file used to create the Python DLL. The
  132. Include subdirectory contains all the standard Python header files
  133. needed for building extensions.
  134. As I don't have the Visual Age C++ compiler, I've made no attempt to
  135. have this port support extensions built with that compiler.
  136. Packaging
  137. ---------
  138. This port is packaged as follows:
  139. - python-2.6-os2emx-bin-03????.zip (binaries, library modules)
  140. - python-2.6-os2emx-src-03???? (patches+makefiles for non-Python code)
  141. As all the Python specific patches for the port are now part of the
  142. Python release tarball, only the patches and makefiles involved in
  143. building external libraries for optional extensions are included in
  144. the source archive.
  145. Documentation for the Python language, as well as the Python 2.6
  146. source distibution, can be obtained from the Python website
  147. (http://www.python.org/) or the Python project pages at Sourceforge
  148. (http://sf.net/projects/python/).
  149. Installation
  150. ------------
  151. Obtain and install, as per the included instructions, the EMX runtime
  152. package.
  153. Unpack this archive, preserving the subdirectories, in the root directory
  154. of the drive where you want Python to live.
  155. Add the Python directory (eg C:\Python26) to the PATH and LIBPATH
  156. variables in CONFIG.SYS.
  157. You should then set the PYTHONHOME and PYTHONPATH environment variables
  158. in CONFIG.SYS.
  159. PYTHONHOME should be set to Python's top level directory. PYTHONPATH
  160. should be set to the semicolon separated list of principal Python library
  161. directories.
  162. I use:
  163. SET PYTHONHOME=F:/Python26
  164. SET PYTHONPATH=F:/Python26/Lib;F:/Python26/Lib/plat-os2emx;
  165. F:/Python26/Lib/lib-dynload;F:/Python26/Lib/site-packages
  166. NOTE!: the PYTHONPATH setting above is linewrapped for this document - it
  167. should all be on one line in CONFIG.SYS!
  168. If you wish to use the curses module, you should set the TERM and TERMINFO
  169. environment variables appropriately.
  170. If you don't already have ncurses installed, I have included a copy of the
  171. EMX subset of the Terminfo database included with the ncurses-5.2 source
  172. distribution. This can be used by setting the TERMINFO environment variable
  173. to the path of the Terminfo subdirectory below the Python home directory.
  174. On my system this looks like:
  175. SET TERMINFO=F:/Python26/Terminfo
  176. For the TERM environment variable, I would try one of the following:
  177. SET TERM=ansi
  178. SET TERM=os2
  179. SET TERM=window
  180. You will have to reboot your system for these changes to CONFIG.SYS to take
  181. effect.
  182. If you wish to compile all the included Python library modules to bytecode,
  183. you can change into the Python home directory and run the COMPILEALL.CMD
  184. batch file.
  185. You can execute the regression tests included with the Python 2.6 source
  186. distribution by changing to the Python 2.6 home directory and executing the
  187. REGRTEST.CMD batch file. The following tests are known to fail at this
  188. time:
  189. - test_mhlib (I don't know of any port of MH to OS/2);
  190. - test_strptime (see "YOU HAVE BEEN WARNED" item 22);
  191. - test_time (see "YOU HAVE BEEN WARNED" item 22);
  192. - test_posixpath (see "YOU HAVE BEEN WARNED" item 23).
  193. Note that some of the network related tests expect the loopback interface
  194. (interface "lo", with IP address 127.0.0.1) to be enabled, which from my
  195. experience is not the default configuration. Additionally, test_popen2
  196. expects the "cat" utility (such as found in ports of the GNU tools) to
  197. be installed.
  198. Building from source
  199. --------------------
  200. With the EMX port now checked into Python's CVS repository, the build
  201. infrastructure is part of the Python release sourceball.
  202. Prerequisites
  203. First and foremost, you need an operational EMX development installation -
  204. EMX v0.9d with fix04 (the latest at time of writing) & the gcc 2.8.1
  205. compiler released by Eberhard Mattes is the recommended setup.
  206. If you have a different version of gcc installed, see "YOU HAVE BEEN
  207. WARNED" item 16.
  208. Other items of software required:-
  209. - GNU make (I'm using v3.76.1)
  210. - rm, cp, mkdir from the GNU file utilities package
  211. - GNU find
  212. - GNU sed
  213. Procedure
  214. 0. all changes mentioned apply to files in the PC/os2emx subdirectory
  215. of the Python release source tree. make is also executed from this
  216. directory, so change into this directory before proceeding.
  217. 1. decide if you need to change the location of the Python installation.
  218. If you wish to do this, set the value of the Makefile variable LIB_DIR
  219. to the directory you wish to use for PYTHONHOME
  220. (eg /usr/local/lib/python2.6).
  221. If you want Python to find its library without the PYTHONHOME
  222. environment variable set, set the value of the Makefile variable
  223. FIXED_PYHOME to "yes" (uncomment the appropriate line).
  224. 2. If you wish the Python executables (python.exe, pythonpm.exe & pgen.exe)
  225. to be installed in a directory other than the PYTHONHOME directory, set
  226. the value of the Makefile variable EXE_DIR to the appropriate directory.
  227. 3. If you wish the Python core DLL (python26.dll) to be installed in a
  228. directory other than the directory in which the Python executables are
  229. installed (by default, the PYTHONHOME directory), set the value of the
  230. Makefile variable DLL_DIR to the appropriate directory. This DLL must
  231. be placed in a directory on the system's LIBPATH, or that gets set
  232. with BEGINLIBPATH or ENDLIBPATH.
  233. 4. If you have installed any of the libraries that can be used to build
  234. optional Python modules, set the value of the relevant HAVE_<package>
  235. Makefile variable to "yes". The Makefile currently supports:
  236. library Makefile variable
  237. ........................................
  238. zlib (1.1.4) HAVE_ZLIB
  239. GNU UltraFast Crypt HAVE_UFC
  240. Tcl/Tk HAVE_TCLTK (not known to work)
  241. GNU Readline HAVE_GREADLINE
  242. BSD DB (v1.85) HAVE_BSDDB
  243. ncurses HAVE_NCURSES
  244. GNU gdbm HAVE_GDBM
  245. libbz2 HAVE_BZ2
  246. OpenSSL HAVE_OPENSSL
  247. Please note that you need to check that what you have installed
  248. is compatible with Python's build options. In particular, the
  249. BSD DB v1.85 library needs to be rebuilt with a source patch for
  250. multithread support (doesn't change the library's reentrant status
  251. but allows it to be linked to Python which is multithreaded).
  252. Widely available binary packages of other librarys & DLLs are
  253. not built/linked with multithread support. Beware!
  254. Also note that the Makefile currently expects any libraries to be
  255. found with the default library search path. You may need to add
  256. -L switches to the LDFLAGS Makefile variable if you have installed
  257. libraries in directories not in the default search path (which can
  258. be controlled by the LIBRARY_PATH environment variable used by EMX).
  259. 5. make
  260. It is usually a good idea to redirect the stdout and stderr streams
  261. of the make process to log files, so that you can review any messages.
  262. 6. make test
  263. This runs the Python regression tests, and completion is a sign of
  264. a usable build. You should check the list of skipped modules to
  265. ensure that any optional modules you selected have been built;
  266. checking the list of failures against the list of known failures
  267. elsewhere in this document is also prudent.
  268. 7. make install
  269. >>>>>> NOT YET COMPLETE <<<<<<
  270. 8. change to a directory outside the Python source tree and start Python.
  271. Check the version and build date to confirm satisfactory installation.
  272. YOU HAVE BEEN WARNED!!
  273. ----------------------
  274. I know about a number of nasties in this port.
  275. 1. Eberhard Mattes, author of EMX, writes in his documentation that fork()
  276. is very inefficient in the OS/2 environment. It also requires that the
  277. executable be linked in a.out format rather than OMF. Use the os.exec
  278. and/or the os.spawn family of functions where possible.
  279. 2. In the absence of GNU Readline, terminating the interpreter requires a
  280. control-Z (^Z) followed by a carriage return. Jeff Rush documented this
  281. problem in his Python 1.5.2 port. With Readline, a control-D (^D) works
  282. as per the standard Unix environment.
  283. 3. EMX only has a partial implementation of fcntl(). The fcntl module
  284. in this port supports what EMX supports. If fcntl is important to you,
  285. please review the EMX C Library Reference (included in .INF format in the
  286. EMXVIEW.ZIP archive as part of the complete EMX development tools suite).
  287. Because of other side-effects I have modified the test_fcntl.py test
  288. script to deactivate the exercising of the missing functionality.
  289. 4. the PyBSDDB3 module has been imported into the Python standard
  290. library, with the intent of superceding the BSDDB 1.85 module (bsddb).
  291. As I don't yet have a satisfactory port of Sleepcat's more recent DB
  292. library (3.3.x/4.0.x/4.1.x), I haven't included a binary of this
  293. module. I have left the Python part of the PyBSDDB package in this
  294. distribution for completeness.
  295. 5. As a consequence of the PyBSDDB3 module being imported, the former
  296. BSD DB (bsddb) module, linked against the DB v1.85 library from EMX,
  297. has been renamed bsddb185. The bsddb185 module will not be built by
  298. default on most platforms, but in the absence of a PyBSDDB3 module I
  299. have retained it in the EMX port.
  300. Version 1.85 of the DB library is widely known to have bugs, although
  301. some patches have become available (and are incorporated into the
  302. included bsddb185 module). Unless you have problems with software
  303. licenses which would rule out GDBM (and the dbm module because it is
  304. linked against the GDBM library) or need it for file format compatibility,
  305. you may be better off deleting it and relying on GDBM.
  306. Any code you have which uses the v1.85 bsddb module can be modified to
  307. use the renamed module by changing
  308. import bsddb
  309. to
  310. import bsddb185 as bsddb
  311. 6. The readline module has been linked against ncurses rather than the
  312. termcap library supplied with EMX.
  313. 7. I have configured this port to use "/" as the preferred path separator
  314. character, rather than "\" ('\\'), in line with the convention supported
  315. by EMX. Backslashes are still supported of course, and still appear in
  316. unexpected places due to outside sources that don't get normalised.
  317. 8. While the DistUtils components are now functional, other
  318. packaging/binary handling tools and utilities such as those included in
  319. the Demo and Tools directories - freeze in particular - are unlikely to
  320. work. If you do get them going, I'd like to know about your success.
  321. 9. I haven't set out to support the [BEGIN|END]LIBPATH functionality
  322. supported by one of the earlier ports (Rush's??). If it works let me know.
  323. 10. As a result of the limitations imposed by EMX's library routines, the
  324. standard extension module pwd only synthesises a simple passwd database,
  325. and the grp module cannot be supported at all.
  326. I have written pure Python substitutes for pwd and grp, which can process
  327. real passwd and group files for those applications (such as MailMan) that
  328. require more than EMX emulates. I have placed pwd.py and grp.py in
  329. Lib/plat-os2emx, which is usually before Lib/lib-dynload (which contains
  330. pwd.pyd) in the PYTHONPATH. If you have become attached to what pwd.pyd
  331. supports, you can put Lib/lib-dynload before Lib/plat-os2emx in PYTHONPATH
  332. or delete/rename pwd.py & grp.py.
  333. pwd.py & grp.py support locating their data files by looking in the
  334. environment for them in the following sequence:
  335. pwd.py: $ETC_PASSWD (%ETC_PASSWD%)
  336. $ETC/passwd (%ETC%/passwd)
  337. $PYTHONHOME/Etc/passwd (%PYTHONHOME%/Etc/passwd)
  338. grp.py: $ETC_GROUP (%ETC_GROUP%)
  339. $ETC/group (%ETC%/group)
  340. $PYTHONHOME/Etc/group (%PYTHONHOME%/Etc/group)
  341. The ETC_PASSWD and ETC_GROUP environment variables are intended to allow
  342. support for multiple passwd/grp files, where other applications may not
  343. support as wide a variety of input variations (drive remappings,
  344. separators etc).
  345. Both modules support using either the ":" character (Unix standard) or
  346. ";" (OS/2, DOS, Windows standard) field separator character, and pwd.py
  347. implements the following drive letter conversions for the home_directory and
  348. shell fields (for the ":" separator only):
  349. $x -> x:
  350. x; -> x:
  351. Example versions of passwd and group are in the Etc subdirectory. The
  352. regression tests (test_pwd and test_grp) will fail if valid password and
  353. group files cannot be found, but should pass otherwise.
  354. Be aware that Python's pwd & group modules are for reading password and
  355. group information only.
  356. 11. EMX's termios routines don't support all of the functionality now
  357. exposed by the termios module - refer to the EMX documentation to find
  358. out what is supported.
  359. 12. The case sensitive import semantics introduced in Python 2.1 for other
  360. case insensitive but case preserving file/operating systems (Windows etc),
  361. have been incorporated into this port, and are active by default. Setting
  362. the PYTHONCASEOK environment variable (to any value) reverts to the
  363. previous (case insensitive) semantics. This can be an issue with some
  364. file management utilities that do not preserve the case of file and
  365. directory names.
  366. 13. Because I am statically linking ncurses, the _curses_panel
  367. module has potential problems arising from separate library data areas.
  368. To avoid this, I have configured the _curses_.pyd (imported as
  369. "_curses_panel") to import the ncurses symbols it needs from _curses.dll
  370. (which is the curses module, but with a .dll extension rather than .pyd
  371. so that the dynamic loader can actually import the symbols from it as a
  372. DLL).
  373. The site module (Lib/site.py) has code added to tweak BEGINLIBPATH so
  374. that _curses.dll is found when _curses_panel is imported. If you have
  375. problems attempting to use the _curses_panel support please let me know,
  376. and I'll have another look at this.
  377. 14. sys.platform reports "os2emx" instead of "os2". os.name still
  378. reports "os2". This change was to make it easier to distinguish between
  379. the VAC++ build (formerly maintained by Michael Muller) and the EMX build
  380. (this port), principally for DistUtils.
  381. 15. it appears that the %W substitution in the EMX strftime() routine has
  382. an off-by-one bug. strftime was listed as passing the regression tests
  383. in previous releases, but this fact appears to have been an oversight in
  384. the regression test suite. To fix this really requires a portable
  385. strftime routine - I'm looking into using one from FreeBSD, but its not
  386. ready yet.
  387. 16. I have successfully built this port with Andy Zabolotny's ports of
  388. pgcc 2.95 and gcc 3.2.1, in addition to EM's gcc 2.8.1. To use the
  389. bsddb185 module with the gcc 3.2.1 build, I had to recompile the DB library
  390. with gcc 3.2.1 - I don't know why, but trying to import the module built
  391. against a DB library compiled with gcc 2.8.1 would result in a SYS3175
  392. error.
  393. I have not attempted to compile Python with any version of gcc prior to
  394. v2.8.1.
  395. This release sees the default optimisation change to
  396. "-O3 -fomit-frame-pointer -mprobe". This works fine too for pgcc 2.95
  397. but not for gcc 3.2.1.
  398. With gcc 3.2.1, -O3 causes 2 unexpected test failures: test_format and
  399. test_unicode. Both these tests pass if -O2 is instead of -O3 with this
  400. compiler, and the performance difference is negligible (in contrast to
  401. gcc 2.8.1 and pgcc 2.95, where the performance difference between the
  402. 2 optimisation settings approaches 10%).
  403. 17. os.spawnv() and os.spawnve() expose EMX's library routines rather
  404. than use the emulation in os.py.
  405. In order to make use of some of the features this makes available in
  406. the OS/2 environment, you should peruse the relevant EMX documentation
  407. (EMXLIB.INF in the EMXVIEW.ZIP archive accompanying the EMX archives
  408. on Hobbes or LEO). Be aware that I have exposed all the "mode" options
  409. supported by EMX, but there are combinations that either cannot be
  410. practically used by/in Python or have the potential to compromise your
  411. system's stability.
  412. 18. pythonpm.exe used to be just python.exe with the WINDOWAPI linker
  413. option set in the pythonpm.def file. In practice, this turns out to do
  414. nothing useful.
  415. I have written a replacement which wraps the Python DLL in a genuine
  416. Presentation Manager application. This version actually runs the
  417. Python interpreter in a separate thread from the PM shell, in order
  418. that PythonPM has a functioning message queue as good PM apps should.
  419. In its current state, PythonPM's window is hidden. It can be displayed,
  420. although it will have no content as nothing is ever written to the
  421. window. Only the "hide" button is available. Although the code
  422. has support for shutting PythonPM down when the Python interpreter is
  423. still busy (via the "control" menu), this is not well tested and given
  424. comments I've come across in EMX documentation suggesting that the
  425. thread killing operation has problems I would suggest caution in
  426. relying on this capability.
  427. PythonPM processes commandline parameters normally. The standard input,
  428. output and error streams are only useful if redirected, as PythonPM's
  429. window is not a console in any form and so cannot accept or display
  430. anything. This means that the -i option is ineffective.
  431. Because the Python thread doesn't create its own message queue, creating
  432. PM Windows and performing most PM operations is not possible from within
  433. this thread. How this will affect supporting PM extensions (such as
  434. Tkinter using a PM port of Tcl/Tk, or wxPython using the PM port of
  435. WxWindows) is still being researched.
  436. Note that os.fork() _DOES_NOT_WORK_ in PythonPM - SYS3175s are the result
  437. of trying. os.spawnv() _does_ work. PythonPM passes all regression tests
  438. that the standard Python interpreter (python.exe) passes, with the exception
  439. of test_fork1 and test_socket which both attempt to use os.fork().
  440. I very much want feedback on the performance, behaviour and utility of
  441. PythonPM. I would like to add a PM console capability to it, but that
  442. will be a non-trivial effort. I may be able to leverage the code in
  443. Illya Vaes' Tcl/Tk port, which would make it easier.
  444. 19. os.chdir() uses EMX's _chdir2(), which supports changing both drive
  445. and directory at once. Similarly, os.getcwd() uses EMX's _getcwd()
  446. which returns drive as well as path.
  447. 20. pyconfig.h is installed in the Include subdirectory with all
  448. other include files.
  449. 21. the default build explicitly sets the number of file handles
  450. available to a Python process to 250. EMX default is 40, which is
  451. insufficient for the tempfile regression test (test_tempfile) which
  452. tries to create 100 temporary files.
  453. This setting can be overridden via the EMXOPT environment variable:
  454. set EMXOPT=-h250
  455. is equivalent to the setting currently used. The emxbind utility (if you
  456. have it installed) can also be used to permanently change the setting in
  457. python.exe - please refer to the EMX documentation for more information.
  458. 22. a pure python strptime module is now part of the Python standard
  459. library, superceding a platform specific extension module. This module
  460. leverages the strftime module, and as a result test_strptime fails
  461. due to the EMX strftime bug in item 20 above.
  462. 23. test_posixpath attempts to exercise various Posix path related
  463. functionality. Most of the sub-tests pass, but the "ismount" and
  464. "samestat" subtests fail:
  465. - EMX provides not satisfactory mount point emulation, so "ismount"
  466. cannot succeed;
  467. - EMX documents that successive stat() calls will produce different
  468. results, so "samestat" cannot succeed.
  469. test_posixpath should skip these tests on EMX.
  470. 24. I have reports of BitTorrent not working. It appears that the
  471. EMX select() emulation, possibly in concert with bugs in the TCP/IP
  472. stack, runs into problems under the stress imposed by this application.
  473. I think it suffices to say that BitTorrent is a fair stress test of a
  474. system's networking capability.
  475. 25. In the absence of an EMX implementation of the link() function, I've
  476. implemented a crude Python emulation, in the file
  477. Lib/plat-os2emx/_emx_link.py. This is imported into the os module, and
  478. becomes available as os.link() in the normal way.
  479. The emulation copies the source file in binary mode, and will fail if
  480. disk space is exhausted. The call fails if the target already exists.
  481. There are no guarantees to thread safety with this emulation - beware!
  482. The emulation was written to support a link() based file locking system
  483. used in GNU Mailman.
  484. 26. AF_UNIX sockets, otherwise known as Unix domain sockets, are now
  485. supported. Unfortunately, there are some traps arising from the
  486. implementation in IBM's TCP/IP stack:-
  487. - the path name must start with '\\socket\\' ('/socket/' won't work!),
  488. with the length of the full path name less than 108 characters;
  489. - unlike Unix, the socket endpoints don't exist in the filesystem;
  490. - by default, sockets are in binary mode.
  491. 27. As of Python 2.4, the mpz, rotor and xreadlines modules have been
  492. dropped from the Python source tree.
  493. 28. The subprocess module was added to the standard library relatively
  494. late in the 2.4 development cycle. Unfortunately I haven't had the
  495. round tuits to adapt the module to the EMX environment yet, and
  496. test_subprocess has a number of failures as a result.
  497. 29. The default stack size for threads has been 64k. This is proving
  498. insufficient for some codebases, such as Zope. The thread stack size
  499. still defaults to 64k, but this can now be increased via the stack_size()
  500. function exposed by the threading & thread modules as well as by defining
  501. THREAD_STACK_SIZE to an appropriate value in the Makefile (which contains
  502. a commented out definition for 128kB thread stacks). I have seen
  503. references to heavy Zope/Plone usage requiring 1MB thread stacks on
  504. FreeBSD and Linux, but doubt that for most likely usage on OS/2 that
  505. more than 256kB is necessary. The size of the required stacks (main
  506. and thread) can vary significantly depending on which version of gcc
  507. is used along with the compiler optimisations selected. Note that the
  508. main thread stack size is set during linking and is currently 2MB.
  509. ... probably other issues that I've not encountered, or don't remember :-(
  510. If you encounter other difficulties with this port, which can be
  511. characterised as peculiar to this port rather than to the Python release,
  512. I would like to hear about them. However I cannot promise to be able to do
  513. anything to resolve such problems. See the Contact section below...
  514. To do...
  515. --------
  516. In no particular order of apparent importance or likelihood...
  517. - support Tkinter and/or alternative GUI (wxWindows??)
  518. Credits
  519. -------
  520. In addition to people identified above, I'd like to thank:
  521. - the BDFL, Guido van Rossum, and crew for Python;
  522. - Dr David Mertz, for trying out a pre-release of this port;
  523. - the Python-list/comp.lang.python community;
  524. - John Poltorak, for input about pwd/grp.
  525. Contact
  526. -------
  527. Constructive feedback, negative or positive, about this port is welcome
  528. and should be addressed to me at the e-mail addresses below.
  529. I have a private mailing list for announcements of fixes & updates to
  530. this port. If you wish to receive such e-mail announcments, please send
  531. me an e-mail requesting that you be added to this list.
  532. Andrew MacIntyre
  533. E-mail: andymac@bullseye.apana.org.au, or andymac@pcug.org.au
  534. Web: http://www.andymac.org/
  535. 28 January, 2008.