I am working on a Python script that will rely on rosetta being installed. Rosetta is a dynamic binary translator for Mac OS X which allows many PowerPC applications to run on certain Intel-based Macintosh computers without modification. Is there anyway for to check the OS to see if rosetta is there?
Haven't got rosetta installed anymore but if I recall correctly it would give some kind of usage screen if you just type translate (rosetta command line). If so, something like this should work.
if os.system("/usr/libexec/oah/translate > /dev/null 2>&1"):
print "Not installed"
else:
print "Installed"
If you are really just trying to check whether something with a PPC dependency will likely run, you could do a loose check that the running CPU type is PPC or the running OS X version >= 10.4 and < 10.7 since those are the OS X versions where Rosetta is supported and, at least on 10.6, OS X will automatically prompt the user to install Rosetta when needed if it wasn't already installed. Note that the Darwin kernel versions are different from the OS X version number, i.e 10.4 -> Darwin 8, 10.5 -> 9, etc.:
>>> import os
>>> os.uname()
('Darwin', 'kitt.local', '11.4.0', 'Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64', 'x86_64')
>>> un = os.uname()
>>> darwin_major_version = int(os.uname()[2].split('.')[0])
>>> cputype = un[4]
>>> can_run_ppc = cputype.startswith('ppc') or (darwin_major_version > 7 and darwin_major_version < 11)
>>> can_run_ppc
False
There is no official way to get this.
Rosetta works via a program called /usr/libexec/oah/translate. Officially, this is an implementation detail which is subject to change, and therefore shouldn't be relied on. However, we know that it never did change until 10.7, when Rosetta was killed completely, so it's safe despite the caveats. Maria Zverina's answer works for that (if you add the path), and it's probably the simplest. Or, maybe, just check for the presence of such a file instead of running it.
Alternatively, Rosetta came with Intel 10.4-10.6 (earlier versions of the OS were PPC-only and didn't have Intel). Again, officially you're never supposed to rely on OS version, instead using the appropriate APIs to check for features. But in this case, there don't seem to be any appropriate APIs, so maybe this is appropriate. Except for the caveat that you don't have to install Rosetta with 10.6, so this won't detect users who turned off the checkbox. If you want to do this:
import platform
release, versioninfo, machine = platform.mac_ver()
versionbits = [int(bit) for bit in release.split('.')]
rosetta = (versionbits < (10,7) and not machine.startswith('ppc'))
(Note that this is also "bad" because on some versions platform.mac_ver() does some hacky stuff that you're not supposed to do—the right way to get the OS X version bits is to call Gestalt. But mac_ver() is part of the standard library, so at least you can rely on it doing the hacky stuff as well as possible, and it being widely tested.)
If you're not actually after Rosetta, but whether you can run PPC either natively or via Rosetta, that's even simpler. All pre-10.7 versions that don't come with Rosetta are PPC; all 10.7+ versions can't run PPC period. So, just "release < '10.7'" does it. (Again, with the caveat that 10.6 can optionally skip Rosetta install.)
Try to run:
brew config
Rosetta 2: true
Related
I am working on Windows 10 presently and need to put some code if the platform is Windows 10. So, I checked in python docs and read about platform module. This is what the documentation says :
platform.win32_ver(release='', version='', csd='', ptype=''):
Get additional version information from the Windows Registry and return a tuple (release, version, csd, ptype) referring to OS release, version number, CSD level (service pack) and OS type (multi/single processor)
When I tried the same function on my Windows 10 machine I got below :
>>> platform.win32_ver(）
('8', '6.2.9200', '', u'Multiprocessor Free')
But, I was expecting the release to be 10 instead of 8.
So, any idea if I am missing something here ?
Also, can somebody please tell me if there exists any other way to detect if the windows platform is Windows 10 ?
The problem is python uses GetVersionEx to determine the version.
As you can read here, Microsoft doesn't support this anymore and offers a different API.
However, you can always call the new API yourself, or check the registry value at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
You can also use WMI to get the Win32_OperatingSystem instance.
I'd also like to note that specific version checking is generally considered a bad practice.
First of all I am quite new with both python and Linux.
That said I am trying to communicate to an FTDI UM232H chip using the pylibftdi library.
I am running my scripts on Linux Ubuntu 12.04.
I installed the library that I got here:
http://pylibftdi.readthedocs.org/en/latest/
and apparently everything worked fine.
I was also able to run some of the examples successfully.
I then tried to write some code to communicate with the device: I wired it in a bus powered configuration (in order to get power from the USB), then I short-circuited TX and RX pins so that what I am sending on TX will be read back on RX.
I do not get any error, but I am not able to read back anything on RX.
Here is my very simple code:
import pylibftdi as p
import time
test = p.Driver()
print test.list_devices()
#This is not working
#print test.libftdi_version()
dev1 = p.Device(device_id='FTUBL36A', mode='t')#, chunk_size = 0)
dev1.flush()
dev1.baudrate = 9600
len = dev1.write('Hello World')
time.sleep(1)
res = dev1.read(len)
print 'res: ', res
Also I am not able to get the libftdi_verion information, even though I installed it.
Does anybody have an idea of what I am doing wrong? Has anyone else ever experienced such a problem?
Thanks in advance!
I'm afraid I don't have a full answer, but some observations (I would make this more concise and put as a comment, but I don't have sufficient rep).
Disclaimer: I'm the author of pylibftdi
libftdi version / installation
The Ubuntu libftdi package (even latest 13.10) is 0.20. This is particularly confusing / annoying since the Ubuntu package name is 'libftdi1'. Prior to (real) libftdi 1.0, there isn't a ftdi_get_library_version() function, so libftdi_version() won't work with the Ubuntu default package. The next version of pylibftdi recognises this and gives an appropriate response.
To install 1.0, follow the instructions at http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00014.html (e.g. the following worked for me - note I'd previously had the Ubuntu libftdi1 package installed, and other dependencies may be required):
$ sudo apt-get install cmake libusb-1.0
$ git clone git://developer.intra2net.com/libftdi
$ cd libftdi
$ git checkout tags/v1.0
$ mkdir build; cd build
$ cmake ..
$ make
$ sudo make install
$ sudo ldconfig # ensure the new library is recognised
Following this, getting the library version should work:
$ python -c 'from pylibftdi import Driver; print Driver().libftdi_version()'
(1, 0, 0, '1.0', 'v1.0')
Data reading errors with UM232H
Note that the latest libftdi (repeat things above but use git checkout master) seems to work slightly better for me, and your program above works perfectly for me with a UM232H (I obviously omitted the device=... parameter, but otherwise left it unchanged). If I replace 'Hello World' with 'Hello World' * 10, writing and reading a longer string, then I get a truncated value returned, typically only 29 bytes. I'm not sure why it's this value; with earlier libftdi versions it seemed to return 17 bytes consistently. Very odd.
With other devices (UB232R, UM232R), this all works perfectly as expected, so in the (admittedly unlikely) event you have a choice of device, you could consider switching... Note the FT232H chip is relatively new and support in libftdi may not be as solid as for the older devices - but equally possible is that I'm incorrectly assuming it should work in a similar way to the older devices in pylibftdi.
Other thoughts
I've tried blacklisting ftdi_sio (add blacklist ftdi_sio to the end of /etc/modprobe.d/blacklist.conf), which stops the Linux kernel doing who-knows-what with the device on plugging it in (the Rx/Tx LED flashes several times when plugging in without this and the ftdi_sio module is loaded. I'm not sure this is necessary or makes a difference though.
Note that there's no guarantee that a read() will return anything previously written to the device (assuming an external Tx->Rx loopback), due to internal buffering in the device, and various driver layers (including USB). These are just streams, and framing should be done in the application layer. Having said that, it 'just works' on a UB232R, and even taking this into account seems the UM232H seems to have issues with pylibftdi for serial mode.
Bitbang mode seems to work fine for UM232H / pylibftdi.
I'll continue investigating and update this answer if I find out anything more.
The sequences control+r and fn+delete that used to do recursive search / delete the following character do not work anymore in python 2.7 / Mac OSX Lion. Instead, a ~ appears each time I use fn+delete. I am using readline for tab completion (which also had to be changed according to python tab completion Mac OSX 10.7 (Lion)). Any ideas how to fix it?
Thanks,
Bruno
According to http://pypi.python.org/pypi/readline:
"Mac OS X, do not ship with GNU readline installed. The readline extension module in the standard library of Mac "system" Python uses NetBSD's editline (libedit) library instead, which is a readline replacement with a less restrictive software license."
So, you can install it with the command:
sudo easy_install readline
Else, you can use tcsh shortcuts; control + d to delete the following character and Ecp + p for history search.
For recursive search you can configure libedit by adding following line to ~/.editrc
bind ^R em-inc-search-prev
or right from your .pystartup file
readline.parse_and_bind("bind ^R em-inc-search-prev")
I have installed iPython and Readline on Mac OS X Snow Leopard and am having difficulty getting tab-completion to work properly.
For example, when I do
import sys
sys.<tab>
the tab key only registers as a normal tab. However, when I do
import sys
sys.<alt+tab>
it works as it should, returning all possible completions.
I would appreciate any tips to get this working properly. I know it seems trivial, but "alt+tab" is a pain compared to "tab".
I am using these versions of iPython and Readline:
readline-6.1.0-py2.6-macosx-10.6-universal.egg
ipython-0.10.1-py2.6.egg
Cheers,
David
I had a similar problem and I fixed it by using the new stable release of iPython (0.11). According to the iPython website this release is "a major new version and the result of over two years of work."
An iPython egg based on Python 2.6 can be found here.
I'm working on a couple of Linux tools and need to prevent installation on Windows, since it depends on FHS and is thus rendered useless on that platform. The platform.platform function comes close but only returns a string.
Unfortunately I don't know what to search for in that string for it to yield a reliable result. Does anyone know what to search for or does anyone know of another function that I'm missing here?
>>> import platform
>>> platform.system()
'Windows'
For those that came here looking for a way to detect Cygwin from Python (as opposed to just detecting Windows), here are some example return values from os.name and platform.system on different platforms
OS/build | os.name | platform.system()
-------------+---------+-----------------------
Win32 native | nt | Windows
Win32 cygwin | posix | CYGWIN_NT-5.1*
Win64 native | nt | Windows
Win64 cygwin | posix | CYGWIN_NT-6.1-WOW64*
Linux | posix | Linux
From this point, how to distinguish between Windows native and Cygwin should be obvious although I'm not convinced this is future proof.
* version numbers are for XP and Win7 respectively, do not rely on them
On my Windows box, platform.system() returns 'Windows'.
However, I'm not sure why you'd bother. If you want to limit the platform it runs on technologically, I'd use a white-list rather than a black-list.
In fact, I wouldn't do it technologically at all since perhaps the next release of Python may have Win32/Win64 instead of Windows (for black-listing) and *nix instead of Linux (for white-listing).
My advice is to simply state what the requirements are and, if the user chooses to ignore that, that's their problem. If they ring up saying they got an error message stating "Cannot find FHS" and they admit they're running on Windows, gently point out to them that it's not a supported configuration.
Maybe your customers are smart enough to get FHS running under Windows so that your code will work. They're unlikely to appreciate what they would then consider an arbitrary limitation of your software.
This is a problem faced by software developers every day. Even huge organizations can't support every single platform and configuration out there.
>>> import os
>>> os.name
'nt'
"The name of the operating system dependent module imported. The following names have currently been registered: 'posix', 'nt', 'mac', 'os2', 'ce', 'java', 'riscos'." (c) http://docs.python.org/library/os.html#os.name
import os
if os.name == 'nt':
#yourcodehere
Try this:
import platform
if platform.system() == "Darwin":
# Don't have Windows handy, but I'd expect "Win32" or "Windows" for it
Edit: Just saw that you tried platform.platform()...platform.system() will work better for this case. Trust me, use it. Dark corners lie in platform detection.
distutils will do this too, if you ask it nicely.
You could always do something bad like os.path.exists() on a Windows file...but platform is as reliable as it gets in the Python standard library.
Edit 2: Another helpful answerer pointed out platform.system() is exactly equal to "Windows" on his Windows machine.
From help(platform)
system()
Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.
An empty string is returned if the value cannot be determined.