Re: [Pythonmac-SIG] [Python-Dev] sad state of OS X Python testing...

[Martin v. Löwis]

> Surely someone could volunteer an old Intel Mac to run some tests?
> (Actually, two someones -- we'd need separate machines for Leopard and
> Snow Leopard.)  I'd be happy to stick it in a server room at PARC and
> keep an eye on it.  (Right now I've got a rack full of old eMacs and a
> G5 running PPC buildbots.)  Perhaps we could get Apple to contribute
> some "seconds"?  I believe donations to the PSF are deductible.

The issue isn't really to get the hardware. The issue is to find
somebody to volunteer running a build slave.

Regards,
Martin
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Python-Dev] sad state of OS X Python testing...

[Martin v. Löwis]

> I'm already running a Jython buildslave on an Intel Mac Pro which is
> pretty underused - I'd be happy to run a CPython one there too, if
> it'd be worthwhile.

I think Bill was specifically after Snow Leopard - what system are you
using?

Regards,
Martin

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Python-Dev] sad state of OS X Python testing...

[Nicholas Riley]

On Sat, Oct 02, 2010 at 10:08:09PM +0200, "Martin v. Löwis" wrote:
> > Surely someone could volunteer an old Intel Mac to run some tests?
> > (Actually, two someones -- we'd need separate machines for Leopard and
> > Snow Leopard.)  I'd be happy to stick it in a server room at PARC and
> > keep an eye on it.  (Right now I've got a rack full of old eMacs and a
> > G5 running PPC buildbots.)  Perhaps we could get Apple to contribute
> > some "seconds"?  I believe donations to the PSF are deductible.
> 
> The issue isn't really to get the hardware. The issue is to find
> somebody to volunteer running a build slave.

I'm already running a Jython buildslave on an Intel Mac Pro which is
pretty underused - I'd be happy to run a CPython one there too, if
it'd be worthwhile.

-- 
Nicholas Riley 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] xattr question

[Christian Tismer]

 Hi Bob, hi mackies

while writing some tool for Time Machine, I encountered quite some
different implementations of xattr. Actually, for a tool written
in python, the internal API is sufficient, but when trying the xattr
command, I was quite confused which way to go.

At the moment, I see three different implementations of xattr.

- one implementation completely in C

- one from you (Bob)

- the built-in version from Mac Os.

The problem is that they are not compatible or subsets of each other,
but that they diverge in the one or other aspect. I think this is
not a good thing for system tools. They should have different names,
or they should be aware of their differences and clearly state this.
At the moment, I see the different versions pretty much ignoring
that they are not the only implementations, but whatever you install,
you think you have "the" tool.

I would like to change this, and to find out about an agreed standard
for the xattr command that is guaranteed to be supported by every
implementations. Is there some definition like this somewhere?

Essentially, the basic commands are the same for all versions, but they
heavily differ by their options.

What is the opinion, especially yours, Bob, hot that should be?


Here are the different versions listed.
---

(1) http://xattr.sourceforge.net/
See this page which is the man page with links to other implementations
and download. Especially misleading is the reference to Bob's version,
that suggests it is an enhanced version, instead it is missing most
of the features, silently. Options:

-sDo not follow symbolic links.
-lDisplay results in extended format.
-RExpect to edit existing extended attributes; fail rather than 
create a new one.
-CExpect to create new extended attributes; fail rather than 
edit an existing one.


(2) http://pypi.python.org/pypi/xattr
This is Bob's implementation. Options:

-l: print long format (attr_name: attr_value)
-z: compress or decompress (if compressed) attribute value in zip

(3) /usr/bin/xattr-2.6
supplied by Apple. I did not find another source than on Os X.
Options:

-r: act recursively
-l: print long format (attr_name: attr_value and hex output has 
offsets and

ascii representation)
-v: also print filename (automatic with -r and with multiple files)
-x: attr_value is represented as a hex string for input and output


My commentary:
--

(1) is a simple C implementation. Not bad, but nothing that looks
like a good reason to prefer it over Python, except one feature:

The options -R and -C ensure your expectations, which helps to
prevent typos: If you specify -R for instance, the attribute has
to be replaced, i.e. you get an error if it did not exist before.

No hex, no zip, no recursion.

(2) is a nice Python implementation. It has the extra feature of actimg
on zip compressed archives. Non-standard imports

import zlibfor zip entries

(3) is also a nice Python implementation, and pretty similar to (2).
No idea who is the hen and who the egg. Non-standard imports:

import binasciifor hex operation
import string  white space elimination for hex (maketrans)

The hex feature of (3) is a real advantage if you want to clone
certain xattr entries which are binary. You can really use a hex dump,
remove formatting of the listing, and apply it to another file.

The zip feature of (2) is useful if you need to modify archives.

The recursion feature of (3) looks handy at first sight, but actually
its use is limited, because you have limited control of the traversal
of huge Time Machine archives, which tend to have millions of files.
It would make sense if you could filter the many xattr entries of
little relevance, of filter files which have xattributes at all.

It would probably make more sense to add recursion features concerning
xattr to the find command, or invent a new one.


So here come(s) my question(s):
---

Does it make sense to further develop a C version? Assuming "no".

Is there a reason why Bob-xattr and Apple-xattr do not agree on
a common API?

Is there any discussion somewhere that leads these decisions?

What is you intention, how should xattr functionality be in future?
Also in the light of compatibility with other OSses?

Where can the Apple version be downloaded, when you try to re-install
your system python?

I think it would be good to clarify this a bit, and maybe to collect
some information for (mostly) newbies like me.
Would the python mac wiki be a good place?

cheers -- chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key ->  http://wwwkeys.pgp.net/
work +49 30 802 86 56 

Re: [Pythonmac-SIG] [Python-Dev] sad state of OS X Python testing...

[Nicholas Riley]

On Sat, Oct 02, 2010 at 10:37:40PM +0200, "Martin v. Löwis" wrote:
> > I'm already running a Jython buildslave on an Intel Mac Pro which is
> > pretty underused - I'd be happy to run a CPython one there too, if
> > it'd be worthwhile.
> 
> I think Bill was specifically after Snow Leopard - what system are you
> using?

It's still on Leopard but I could use another (slower, but still
probably fine) machine that has Snow Leopard on it.

-- 
Nicholas Riley 

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG