We have problems with threading support in the mentioned APE python port (e.g. hg serve): they complain about invalid file descriptors which may be due to non-reentrant implementation of APE interfaces. I didn't look any deeper though.
2013/1/5 Federico G. Benavento <benave...@gmail.com>: > Hola Steven, > > thanks for getting mercurial support for Plan 9 upstream, > I did the APE port of python (based on the native one) years ago > because nothing worked with the "native" one, I wanted to get X > running then it needed openssl or some socket api that wasn't > implemented in the Plan 9 emulation of it (written in python as > charles mentions), because native python didn't have sockets > and things like non-blocking IO provided by APE's select. > > basically you're left out with the Language but without significant > parts of the runtime when you use a native port. > > thanks again > > > On Jan 4, 2013, at 8:10 PM, Steven Stallion <sstall...@gmail.com> wrote: > >> Hi Jeff, >> >> Mercurial has been taken care of! I more or less track the latest stable >> (stallion/mercurial). The existing Python port is sufficient for Mercurial, >> though having a native Python port would be great. I've added Plan 9 support >> upstream in the Mercurial repository, so future builds are very simple. In >> fact, it's even documented: >> http://mercurial.selenic.com/wiki/Plan9FromBellLabs >> >> Cheers, >> >> Steve >> >> On Fri, Jan 4, 2013 at 1:56 PM, Jeff Sickel <j...@corpus-callosum.com> wrote: >> Has anyone completed an APE lib sec yet? >> >> I'm starting to roll an ape build of libsec in as it's needed for >> a new Python 2.7.3+ port of Python. I'd gladly take someone else's >> mkfile rework to save some time. Libsec is needed to implement a >> new _hashlib module, one that doesn't require OpenSSL among others. >> >> The new Python release&build will be pushed out once I clean up >> a few more details like getting new builds of Mercurial working. >> > > --- > Federico G. Benavento > benave...@gmail.com > > > > -- - Yaroslav
