Discussion:
[9fans] current python & hg support
(too old to reply)
Jeff Sickel
2012-02-10 02:06:13 UTC
Permalink
A quick question for everyone, is there interest in getting a more current version of hg working for Plan 9 & NIX? If so, given I've spent way too much time in the past getting both working for other platforms, I could devote a little time to get both prepped for future work.

Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer to the 2.7.1 release.
Hg has made significant strides since 1.0.2.

Neither of these updates might help the oddities people are finding while using Hg, but if we're looking forward then keeping current should be addressed.

-jas
Anthony Sorace
2012-02-10 03:33:15 UTC
Permalink
I'd like the newer hg, at a minimum. Our current version
has limited my use at times, working with repositories
generated by newer versions.
John Floren
2012-02-10 05:03:59 UTC
Permalink
A quick question for everyone, is there interest in getting a more current version of hg working for Plan 9 & NIX?  If so, given I've spent way too much time in the past getting both working for other platforms, I could devote a little time to get both prepped for future work.
Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer to the 2.7.1 release.
Hg has made significant strides since 1.0.2.
Neither of these updates might help the oddities people are finding while using Hg, but if we're looking forward then keeping current should be addressed.
-jas
That would be really great... Ideally, if you update Python, you could
get patches put in to officially support Plan 9. If I remember
correctly, there was at least one Python developer who was interested
in helping with that.

John
Jens Staal
2012-02-10 05:55:25 UTC
Permalink
Post by John Floren
A quick question for everyone, is there interest in getting a more current version of hg working for Plan 9 & NIX?  If so, given I've spent way too much time in the past getting both working for other platforms, I could devote a little time to get both prepped for future work.
Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer to the 2.7.1 release.
Hg has made significant strides since 1.0.2.
Neither of these updates might help the oddities people are finding while using Hg, but if we're looking forward then keeping current should be addressed.
-jas
That would be really great... Ideally, if you update Python, you could
get patches put in to officially support Plan 9. If I remember
correctly, there was at least one Python developer who was interested
in helping with that.
John
The same is actually also true for the Perl guys. I asked around a bit
there just recently when I noticed that the Plan9 install instructions
do not work for recent versions (the official Perl sources ship with a
script to prep the Perl sources and an mkfile under the plan9/
directory). They seem interested in getting it up to date if anyone is
interested.

I tried looking at it but did not really figure it out...

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-02/msg00069.html
erik quanstrom
2012-02-10 06:43:47 UTC
Permalink
Post by Jeff Sickel
A quick question for everyone, is there interest in getting a more
current version of hg working for Plan 9 & NIX? If so, given I've
spent way too much time in the past getting both working for other
platforms, I could devote a little time to get both prepped for future
work.
Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer
to the 2.7.1 release. Hg has made significant strides since 1.0.2.
stallion/hg is what we're using. it's version 1.7.5. we're using it with
bichued/python.

as i see it, the slight staleness of the port is tertiary. the primary
problem is that python modules tend to assume they're on linux,
and the secondary problem is that the python port is not as complete
as it could be.

it would also be nice for a python port to not depend on
openssl, bz2 or z.

- erik
Jeff Sickel
2012-02-10 16:29:40 UTC
Permalink
Post by erik quanstrom
Post by Jeff Sickel
A quick question for everyone, is there interest in getting a more
current version of hg working for Plan 9 & NIX? If so, given I've
spent way too much time in the past getting both working for other
platforms, I could devote a little time to get both prepped for future
work.
Python 2.5.1 is stable, but it wouldn't hurt us to be a little closer
to the 2.7.1 release. Hg has made significant strides since 1.0.2.
stallion/hg is what we're using. it's version 1.7.5. we're using it with
bichued/python.
as i see it, the slight staleness of the port is tertiary. the primary
problem is that python modules tend to assume they're on linux,
and the secondary problem is that the python port is not as complete
as it could be.
it would also be nice for a python port to not depend on
openssl, bz2 or z.
You've got a few dependencies for mercurial:

bz2, zlib, & ssl

So w/o those included in the Python build, no mercurial.

Getting current will help making the transition to modules that support
the Plan 9 file systems and architecture a little more robust.

Mercurial's a good example as it's got a lot of logic in place to
deal with all sorts of odd filesystems already.


-jas
erik quanstrom
2012-02-10 16:44:42 UTC
Permalink
Post by Jeff Sickel
Mercurial's a good example as it's got a lot of logic in place to
deal with all sorts of odd filesystems already.
well if that the case, then its support isn't worth much.
nix has been dealing with problems due to osx : mangling.

- erik
John Floren
2012-02-10 17:03:42 UTC
Permalink
On Fri, Feb 10, 2012 at 8:44 AM, erik quanstrom
Post by erik quanstrom
Post by Jeff Sickel
Mercurial's a good example as it's got a lot of logic in place to
deal with all sorts of odd filesystems already.
well if that the case, then its support isn't worth much.
nix has been dealing with problems due to osx : mangling.
- erik
I think we decided that the : mangling came from a careless copy from
an iso9660 image... but OS X may be responsible for the case-mangling
of Kill and kill.

Too many emails, not enough time

John
Jeff Sickel
2012-02-10 17:50:39 UTC
Permalink
Post by John Floren
On Fri, Feb 10, 2012 at 8:44 AM, erik quanstrom
Post by erik quanstrom
Post by Jeff Sickel
Mercurial's a good example as it's got a lot of logic in place to
deal with all sorts of odd filesystems already.
well if that the case, then its support isn't worth much.
nix has been dealing with problems due to osx : mangling.
- erik
I think we decided that the : mangling came from a careless copy from
an iso9660 image... but OS X may be responsible for the case-mangling
of Kill and kill.
That's a good example. If you create the repo on a case-sensitive
filesystem and add 'Kill' and 'kill' then you'll find that the repo
always has that file in it. If you clone the repo to a case insensitive
filesystem, you end up with which ever file comes out of the repo last
when you do an 'hg up'. Mercurial preserves both, but you may be in
trouble is someone on a case insensitive file system makes a commit
to 'Kill'. Luckily the history will be there and it's easy to recover.

For those using 9vx on OSX: it's really easy to set up your local
drive to support a case sensitive file system. Just don't make it
the root partition or where /Users resides in case you run any
applications out of ~/Applications that come from certain large
corporations (aka any that really pushed the Carbon APIs, or applications
that originated in Carbon but were only slowly migrated to Cocoa). You can
create a case-sensitive disk image, though that has some drawbacks.
Partition your drive and then add an entry into /etc/fstab so that it
always mounts at a logical place, and not some /Volumes with a potentially
variable name.

-jas
Aram Hăvărneanu
2012-02-11 11:43:58 UTC
Permalink
Post by Jeff Sickel
For those using 9vx on OSX: it's really easy to set up your local
drive to support a case sensitive file system.
I've used a case sensitive root file system on my mac many years. The
only problem I had was Photoshop refusing to install, everything else
worked without any issues. Of course, Photoshop itself worked after I
copied it from another machine.
--
Aram Hăvărneanu
Loading...