Re: [9fans] Mercurial and Plan 9

Re: [9fans] Mercurial and Plan 9

[erik quanstrom]

> I believe the biggest sore spot is the lack of a modern Python port.

+1.

particularly one that compiles on every architechture.  the current code
has a few mistakes like defining FPINVAL (depending on the architecture)
instead of including float.h.

> Ideally we could have a more complete port that wouldn't require APE,

targeted strikes, like (as an unresearched example) using the native
ssl instead of openssl might give more bang/buck.

- erik

[9fans] Mercurial and Plan 9

[Steven Stallion]

All,

I have to admit I've been a bit late posting to the list regarding
updates to Mercurial. As Erik has mentioned a couple of times, a 1.7.5
port was made last year (a factotum extension for http/https
authentication was also written; see
/n/sources/contrib/stallion/src/mercurial). This port has seen heavy
use over the last year with a fair degree of success - I am finally
comfortable making this a bit more public. stallion/mercurial is
available via fgb's contrib. You will want to check
/n/sources/contrib/stallion/src/mercurial/README before installing.

As for the current status, I'm working on a port for the latest stable
(2.1.1 at the time of this writing). This should be complete soon -
there are a few rough edges I want to polish first, particularly with
documentation. This port should be a bit more complete than the last;
I am aiming to have this become part of the official Mercurial
distribution going forward.

Jeff,

I believe the biggest sore spot is the lack of a modern Python port.
Ideally we could have a more complete port that wouldn't require APE,
but that may be approaching the point of diminishing returns.

Cheers,

Steve

Re: [9fans] Mercurial and Plan 9

[Jeff Sickel]

On Mar 14, 2012, at 1:15 AM, Steven Stallion <sstallion@gmail.com> wrote:
>
> As for the current status, I'm working on a port for the latest stable
> (2.1.1 at the time of this writing). This should be complete soon -
> there are a few rough edges I want to polish first, particularly with
> documentation. This port should be a bit more complete than the last;
> I am aiming to have this become part of the official Mercurial
> distribution going forward.

That's great news.


> Jeff,
>
> I believe the biggest sore spot is the lack of a modern Python port.
> Ideally we could have a more complete port that wouldn't require APE,
> but that may be approaching the point of diminishing returns.

Do you see this as a potential GSoC effort?  The sans-ape version,
build based off CPython 2.7 or 3.x?  There are more dependencies
than just Python, but if we did have this updated then there would be
more opportunity for people to experiment with a Plan 9 system.

-jas

Re: [9fans] Mercurial and Plan 9

[Steven Stallion]

On Tue, Mar 13, 2012 at 11:28 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:
> Do you see this as a potential GSoC effort?  The sans-ape version,
> build based off CPython 2.7 or 3.x?  There are more dependencies
> than just Python, but if we did have this updated then there would be
> more opportunity for people to experiment with a Plan 9 system.

I think a new port regardless of flavor would be much welcomed.
Something based on 2.7 would be great for Mercurial, but I know there
is a need elsewhere for a 3.x port. I have not looked into how much
would work it would take to mitigate the apishness of a new port but
it looks like others have (bummer). I suspect dropping openssl will be
tricky but it would be quite worthwhile especially given Mercurial's
penchant for https.

Cheers,

Steve

Re: [9fans] Mercurial and Plan 9

[Yaroslav]

Speaking of which... what would be the trick to make libsec visible
for an APE source?
--
- Yaroslav

Re: [9fans] Mercurial and Plan 9

[Federico Benavento]

check, /sys/src/ape/lib/draw/ for some insight

On Mar 14, 2012, at 12:22 PM, Yaroslav wrote:

> Speaking of which... what would be the trick to make libsec visible
> for an APE source?
> --
> - Yaroslav
>

Re: [9fans] Mercurial and Plan 9

[Jeff Sickel]

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.

-jas

On Mar 20, 2012, at 5:11 PM, Federico Benavento <benavento@gmail.com> wrote:

> check, /sys/src/ape/lib/draw/ for some insight
>
> On Mar 14, 2012, at 12:22 PM, Yaroslav wrote:
>
>> Speaking of which... what would be the trick to make libsec visible
>> for an APE source?
>> --
>> - Yaroslav

Re: [9fans] Mercurial and Plan 9

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1645 bytes --]

Re: [9fans] Mercurial and Plan 9

[Charles Forsyth]

The first Python port aimed at a so-called "native" port but as I
worked on it to import a newer version of Python, it became clear that
Python's standard libraries, certainly as used by most Python
applications, are so closely bound up with POSIX interfaces (eg, the
exact components of the stat structure) that large chunks of APE were
simply being replicated in Python, which seemed a bit pointless (and
actually quite hard, as when emulating select).

On 4 January 2013 23:10, Steven Stallion <sstallion@gmail.com> wrote:
> The existing Python port is sufficient for Mercurial, though having a native
> Python port would be great.

Re: [9fans] Mercurial and Plan 9

[Federico G. Benavento]

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 <sstallion@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 <jas@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
benavento@gmail.com

Re: [9fans] Mercurial and Plan 9

[Yaroslav]

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 <benavento@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 <sstallion@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 <jas@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
> benavento@gmail.com
>
>
>
>



-- 
- Yaroslav

Re: [9fans] Mercurial and Plan 9

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

The Python libraries expect an APE environment, and that assumption is
deeply built in to it.
The previous attempt to do a so-called "native" port ended up writing large
chunks of APE in Python,
which was a bit of a waste of time, or it couldn't run all the existing
things, such as Mercurial.
Using APE means that you don't need to re-write it in Python, and
incorporating a new Python
release can be made relatively straightforward (except for bugs in Python).

On 14 March 2012 06:15, Steven Stallion <sstallion@gmail.com> wrote:

> Ideally we could have a more complete port that wouldn't require APE,
> but that may be approaching the point of diminishing returns.
>

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]