Re: [LabPython-Users] Updates to the project

[Daniele N. <da...@gr...>]

Hello Rolf,

the first thing I would like to do is to update the LabPython presence
on SourceForge to reflect the current status of the project:

- the code has moved to the OpenG SVN repository,
- python versions up to 2.7 are supported,
- provide a location where to download the latest binaries,
- there is active interest in the project.

Would you like to give me access to the SorceForce project to do that?

Later, I would like to move the code repository to GitLab. What do you
think about this?

On 05/03/16 05:47, Rolf Kalbermatter wrote:
> Not sure which email address Jim would prefer. I'm sure you know about
> his company but he may prefer a different email address mentioned than
> his company address. For me that is certainly true both for legal
> reasons as this was something private rather than from my employer and
> also the fact that work email tends to change sometimes.

While I have been exposed to LabVIEW for quite a long time now, I cannot
consider myself an expert nor I'm much involved with the community. All
the company names I encountered researching contacts for the LabPython
authors were new to me.

> The LabPython code got moved at some point into a subproject of the
> OpenG Toolkit and as such the latest version is in the SVN repository of
> that project. I did recently make minor changes to it to fix the runtime
> errors when loading with Pyton 2.7.

I found the code repository. It seems that it has been imported without
preserving the CVS history. I'll see how difficult it is to stitch
together the two.

> I'm aware that Python has no guarantee about ABI compatibility between
> versions. However reality was that it seemed to work pretty good from
> version 2.2 up to 2.6 and with that minor change I committed recently
> even allows loading with 2.7.

The size of the structures changed, and I believe also the position of
some fields, and some of the API is defined in terms of macros. I'm
surprised this can work at all.

> Another issie is that the Python project
> maintainers never seemed to be very supportive about embedding Python
> into another program and concentrated mainly on extensibility. Any
> inquiry from me about that was at that time either ignored or outrightly
> refused.

I'm surprised. Embedding of the python interpreter is definitely a
supported and documented use-case.

> If you look at the code you will notice that I make use of the
> interpreter lock, but somehow that seems not enough to make Python run
> stable from within a multithreading environment. It could be a
> shortcoming in the interpreter lock handling in the LabPython code,
> maybe caused by internal changes in Python in later version  after 2.3,
> or it could be a fundamental problem, for instance the use of thread
> local storage within Python.

I haven't understood all the details of the implementation, but from a
coarse analysis of the codequick look at the code, there are a few
constructs that look suspicious. Test cases that cause troubles in
LabPython would be definitely useful.

Cheers,
Daniele