GHPython sqlite3 module is unusable on Mac

Hello @piac and all,

I wanted to report a bug that we found in GHPython for Mac but I first wanted to take the opportunity to say how incredibly awesome it is to have the updated version of IronPython inside GHPython on Rhino 6. We have been able to assemble a much better set of Ladybug Tools plugins (that we are close to releasing on Food4Rhino) thanks in large part to all of the new modules/capabilities that didn’t exist in the Rhino 5 version (xml, csv, sqlite3, updated web encryption that can be used to securely download files).

Along these lines, we have found that the sqlite3 module in GHPython for Mac is currently unusable. Whenever it gets to the point where we execute an SQLite query, we get the following error:

Runtime error (EntryPointNotFoundException): LockFileEx assembly:<unknown assembly> type:<unknown type> member:(null)

Creating the connection, pointing the cursor, and everything else succeeds. It’s just the execution of the query that fails. So the following code should reproduce the error with the sqlite file I attached in the .zip file:

import sqlite3
file_path = './eplusout_monthly.sql'

conn = sqlite3.connect(file_path)
c = conn.cursor()
c.execute('SELECT * FROM ReportDataDictionary WHERE Name=?', ('Zone Lights Electric Energy',)) (191.9 KB)
The error should be on that last line there and note that the error only happens on Mac (it’s perfectly fine on Windows).

From what I can tell from my quick research, this error seems to be specifically the result of using IronPython on Mac and I verified that the sqlite3 queries work perfectly fine with a standalone installation of Python 3.7 on Mac.

Any insights you can share would be appreciated and I am happy to run more tests on my end if it’s helpful.

1 Like

I can confirm this!
I’ve also tried to connect to other database files of mine, and had no success either! It’s the opening part that fails each and every time.
I guess this is another chapter in the book “1001 Reasons Why IronPython Sucks (Especially on macOS)”!

Anyways, it’s really no use to compare CPython 3.+ to IronPython 2.7. You see, in Rhino we are pretty much stuck with IronPython, especially on macOS, because Grasshopper is largely written in .Net, and IronPython allegedly a 32-bit emulation of the real thing inside the .Net environment/framework.
Now, IronPython is not really developed that much! I imagine Microsoft is not especially interested in pouring money into a scripting language that’s not considered theirs and that’s the chou chou of the Linux and open-source community. I bet they really didn’t see Python becoming so popular with Machine Learning.

What you could probably do, is possibly look for a solution in the .Net framework and try to use that in IronPython.

1 Like


I think you need to test it under IronPython on the Mac, which apparently runs under Mono, but I dont know whether that is comparable to running the python interpreter inside Rhino on the Mac. If it fails on Mono for Mac then you could report the failure to the IronPython team but there are not many of them and this may be low priority for them compared to Windows bugfixes and writing IronPython 3. @diff-arch’s suggestion of using a DotNet equivalent or other workaround sounds like a good idea…


Thank you for confirming the error @diff-arch , and for the suggestion @Dancergraham .

I should clarify that I have a workaround planned if there’s no solution to this issue. We decided to ship the next version of Ladybug Tools with an installation of CPython 3.+ if only because it makes certain simulation workflows much easier and faster to execute. So my workaround would be to execute a sqlite-parsing command with this CPython installation if all else fails. But this probably won’t be as clean or as friendly to people scripting their own Grasshopper components using the Ladybug Tools SDK. So it would be good to know for certain if this is an un-fixable issue before we go down this route.

I will try @Dancergraham 's suggestion to see if I can get it to work with the latest version of Mono. If it fails there, then we know for sure that it’s an issue intrinsic to IronPython and not something that could be addressed on the McNeel side of things.

I would also agree that IronPython3 should be a much higher priority for the IronPython team. That would be a wonderful thing to have!

1 Like