We Keep Coding

Strange import error in Emscripten cross-compiled CPython

I am porting CPython to Emscripten, and it builds successfully. However, when I try to run the python.asm.js through Node.js, I get a very strange error inside the Py_InitializeEx(0) call:
Traceback (most recent call last):
File "/lib/python2.7/site.py", line 62, in <module>
import os
File "/lib/python2.7/os.py", line 44, in <module>
from posix import *
TypeError: 'NotImplementedType' object does not support indexing
The error is generated from PySequence_GetItem in Objects/abstract.c, but I don't understand how the execution gets there. If I do import posix before the line that causes the error, the import posix statement finish successfully, and I can call functions in the posix module. Thus, the error is related to from <module> import * line. How is PySequence_GetItem related to from <module> import * statement, and what could be the reasons for the error?
If you want to reproduce the problem, I released the code on GitHub

While investigating what is going wrong, I switched off the optimization (compiled and linked with -O0). The resulting JS executable also failed, but with a different error:
Invalid function pointer '495' called with signature 'iii'. Perhaps this is
an invalid value (e.g. caused by calling a virtual method on a NULL pointer)?
Or calling a function with an incorrect type, which will fail? (it is worth
building your source files with -Werror (warnings are errors), as warnings can
indicate undefined behavior which can cause this)
This pointer might make sense in another type signature:
ii: _dict_keys iiii: 0 i: undefined iiiii: 0 viii: 0 vii: 0 vi: 0 v: 0
495
495
I looked through Emscripten's settings.js for options related to function pointers, and found EMULATE_FUNCTION_POINTER_CASTS which fixed the problem.

Why is there different behaviour from getpwuid and getgrgid?

In Python 2.7, 3.4 and 3.5, grp.getgrgid is capable of accepting a string:
from grp import getgrgid
print(getgrgid('0'))
However, pwd.getpwuid can't do the same:
from pwd import getpwuid
print(getpwuid('0'))
Traceback (most recent call last):
File "getpwuid_test.py", line 2, in <module>
print(getpwuid('0'))
TypeError: an integer is required
This is because inside Modules/pwdmodule.c, getpwuid uses PyNumber_ParseTuple with a converter that uses PyNumber_Index to get a Python integer, and that raises an exception on failure.
However, in Modules/grpmodule.c, grp_getgrgid uses PyNumber_Long (Or PyNumber_Int for an old enough Python) as a conversion first, and as the documentation says at https://docs.python.org/3/c-api/number.html, this is the equivalent of running int(o), which can convert a string to an integer. Only then is it given to PyNumber_Index, by way of a helper function _Py_Gid_Converter
What is the reason for this difference? Is it a deliberate choice based on some history?
The behaviour of getgrgid seems more helpful, and it's odd that it doesn't apply to both functions. Is this undesirable behaviour in getgrgid or getpwuid?

The short answer is because humans are fallible and mistakes happen. Some are doozies and get noticed quickly, others are minor and can go years without detection.
Thank you for helping make Python better!

comtypes: in call_with_inout, ctypes TypeError: 'c_double' object is not iterable

Im working with Agilent IVI drivers in Python 2.7.9 and can't seem to get 'proven' code to work on a particular Windows 7 machine. It executes successfully on other machines.
While this issue seems rather limited to one instrument, it appears to be a broader Python issue, so I turn to Stack Overflow for help. Any help or insight would be great.
The following code
# Import the TLB
from comtypes.client import GetModule, CreateObject
GetModule('AgInfiniium.dll')
# Pull in the coefficients and classes, we'll need those
from comtypes.gen.AgilentInfiniiumLib import *
# Instantiate the driver
OScope = CreateObject('AgilentInfiniium.AgilentInfiniium')
# Make constants of our settings
Address = "TCPIP0::10.254.0.222::INSTR"
resetOScope = False
# Open a connection to the scope
OScope.Initialize(Address,False,resetOScope,'')
# Make a measurement
print OScope.Measurements.Item("Channel1").ReadWaveformMeasurement(
MeasFunction=AgilentInfiniiumMeasurementAmplitude, MaxTime=10)
yields the following error:
Traceback (most recent call last):
File "P:\Aperture\Validation\WMI_BGA_Board\TestMatrixCode\scopeTest2.py", line 29, in <module>
print OScope.Measurements.Item("Channel1").ReadWaveformMeasurement(MeasFunction=AgilentInfiniiumMeasurementAmplitude ,MaxTime=10)
File "C:\Python27\lib\site-packages\comtypes-1.1.0-py2.7.egg\comtypes\__init__.py", line 656, in call_with_inout
rescode = list(rescode)
TypeError: 'c_double' object is not iterable
In my limited debugging attempts, I have seen that this call_with_inout
function tries to convert my Python arguments into arguments for the following C++ function:
public void ReadWaveformMeasurement(
AgilentInfiniiumMeasurementEnum MeasFunction,
AgilentInfiniiumTimeOutEnum MaxTime,
ref double pMeasurement)
It's creating some kind of variable for the pMeasurement pointer that ends up being type c_double, and then complains that it's not iterable.
At this point, this seems like it's local to this machine. I've gone to the extent of uninstalling Python, reinstalling the Agilent driver, and trying two versions of comtypes (1.1.0 and 1.1.1). Yet the problem persists. Any ideas? Thanks.

Grail (web browser) installation on Scientific Linux

I'm not sure if Grail browser is a good choice nowadays, however I want to try it, because I have some problems about graphics running on Firefox-Fermi. The next, is what I obtain after trying grail-0.6 (tgz)
# python grail.py
Traceback (most recent call last):
File "grail.py", line 43, in ?
from Tkinter import *
After installing "tkinter" adequately, I run "grail.py" again, and I get
# python grail.py
/root/grail-0.6/grailbase/app.py:6: Deprecation Warning: the regex module is
deprecated; please use the re module
import regex
/usr/lib/python2.4/regsub.py:15: DeprecationWarning: the regsub module is
deprecated; please use re.sub()
DeprecationWarning)
Traceback (most recent call last):
File "grail.py", line 499, in ?
main()
File "grail.py", line 108, in main
app = Application(prefs=prefs, display=display)
File "grail.py", line 248, in __init__
self.stylesheet = Stylesheet.Stylesheet(self.prefs)
File "/root/grail-0.6/Stylesheet.py", line 21, in __init__
self.load()
File "/root/grail-0.6/Stylesheet.py", line 45, in load
massaged.append((g, c), v % fparms_dict)
TypeError: append() takes exactly one argument (2 given)
but now, I'm not able to understand the message at all. May you advice me about this problem?

Wow - that's a blast from the past! My advice is to give up: Grail hasn't been touched in more than a dozen years. It's dead.
The error message you're getting stems from a change made way back in Python 1.6 (released 5 September 2000). Here's the message from the release notes:
The append() method for lists can no longer be invoked with more
than one argument. This used to append a single tuple made out of
all arguments, but was undocumented. To append a tuple, use
e.g. l.append((a, b, c)).
So, you can:
Give up. Recommended ;-)
Install an ancient version of Python; or,
Change that line to
massaged.append(((g, c), v % fparms_dict))
and see what breaks next ;-)
About the next problem
Python 0.9.1 is extremely old, from early 1991. The language changed in many, many ways before 1.0 was released.
According to the old Grail home page, Grail 0.6:
requires Python 1.5 or newer, and Tcl/Tk 8.0 or newer.
So find Python 1.5 if you're determined to pursue this ;-) Note that the .append() semantics were changed in version 1.6, so the original .append() code that hurt you at first should still work OK in 1.5.

Openoffice3.1 pyuno confusing errors

I'm trying to get the sample and other sample codes i find for pyuno running with openoffice 3.1.1 and python 2.5 with no luck.
Unfortunately, pyuno does not give any clues about what goes wrong.
In [1]: import uno
In [2]: local = uno.getComponentContext()
In [3]: resolver = local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", local)
---------------------------------------------------------------------------
com.sun.star.uno.RuntimeException Traceback (most recent call last)
/opt/openoffice.org/basis3.1/program/ in ()
com.sun.star.uno.RuntimeException: : 'tuple' object has no attribute 'getTypes', traceback follows
no traceback available
below is the output of execution of /opt/openoffice.org/basis3.1/program/officehelper.py
which basically boots the headless office instance and returns a related context object.
den#ev:/opt/openoffice.org/basis3.1/program > python officehelper.py
Traceback (most recent call last):
File "officehelper.py", line 42, in
from com.sun.star.connection import NoConnectException
File "uno.py", line 273, in _uno_import
RuntimeException = pyuno.getClass( "com.sun.star.uno.RuntimeException" )
RuntimeError: pyuno.getClass: expecting one string argument
pyuno takes only 1 argument and it hasto be a string, as defined in http://udk.openoffice.org/source/browse/udk/pyuno/source/module/pyuno_module.cxx?rev=1.14&view=markup
i could not manage to get pyuno.getClass work anyway.
any suggestions about how to get pyuno working?

In [1]: import uno
In [2]: local = uno.getComponentContext()
In [3]: resolver = local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", local)
OOP gone wrong, imho. i know its OT, but i tried getting uno to work before, and gave up. this is pure Steve Yegge Prose (read up on http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).
when you translate those lines into a more speakable form, they come out roughly as:
"Let 'local' be the result of calling method 'get component context' of 'uno'. Let the 'service manager' be the attribute 'service manager' of 'local'. Let 'resolver' be the result of calling the 'service manager' method 'create instance with context', using arguments 'com sun star bridge uno url resolver' and 'local'."
omg. no surprise something is wrong with a program that is so atrociously over-specific, convoluted, and self-referential while being not self-aware... you call a sub-method of 'local' and that sub-method has to be told what 'local' means? say what? hats off to the fearless developers who can cut through this. happy debugging.
ADDED:
thx for comment and points.
the pyuno problem i cannot do anything about in fact, but i encourage to persue a patient trytrytry approach with a clear deadline.
i also suggest to file an outright B.U.G. with the pyuno people (if they are in fact active—i got the impression that this was a rather silent project) because of the nonsense error message: the method in question appears to request one string argument, and it gets one, and it complains it did. this is so not helpful to the degree it becomes reasonable to declare a code fault.
in this kind of situation i often look into the sources. but you already did that, right?
i hate people to ask back ‘why do you want to do this?’ when i ask for help. however, sometimes someone (maybe you) does come up with another workable path in the process, one that does not include a solution to the particular problem, but helps to solve the superordinate one. so, if i may ask: what is the big picture?