M1 Issues #38
Comments
|
Hi @cosina, This is a known bug in M1. We are still working in a solution. |
|
I just did more test and the last version it works is Python 3.8.9 Problem does not seems to be related to M1 generation only because running 3.9 Inte (but on M1 machine) falied as well. |
|
I dig a bit more: MacOS Monteray has a build in 3.8.9. ANd this version is DIFFERENT than 3.8.9 downloaded from python.org. The main difference seems to be that the built-in version is a framework-based version which enables GUI applications. Therefore as long as I use a built-in python3 everything works, but using any version from python.org fails. See: https://github.com/python/cpython/blob/main/Mac/README.rst |
|
Hello @cosina, Can you share more details? It would be good if you share screenshots, step-by-step to reproduce and a sample script. Run "kill -ABRT {PID}" to send a SIGABRT when your app hangs to generate a crash report. Thread 0 is stuck waiting for thread 1 to finish but thread 1 can’t finish because thread 0 is holding a lock that it needs to acquire. See it bellow: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread Thread 1:: Dispatch queue: com.apple.root.utility-qos.overcommit Thread 2: Thread 3: Check out this thread for similar issues: https://developer.apple.com/forums/thread/695702?answerId=696925022#696925022 |
|
Hi, See the image and used Python version details
I tested it also on my older, Intel based Mac - same conclusion. |
|
Great, let's try it :) |
|
Maybe we are talking about different issues. Give us more details, please. |
|
OK. Let's systemize this
|
|
I understand it works when GUI is loaded by Python. Thus, this is a workaround for the real issue. |
|
Hi, However, it seems a found a workaround. The problem is indeed a deadlock on I create a utility package: // Init screen context on MacOS
library macosfmxrunner;
uses
System.SysUtils,
System.Classes,
Macapi.AppKit,
PythonEngine;
var
gEngine : TPythonEngine;
gModule : TPythonModule;
function PyInit_tatukgis_macos: PPyObject;
begin
try
Result := nil ;
gEngine := TPythonEngine.Create(nil);
gEngine.AutoFinalize := False;
gEngine.UseLastKnownVersion := True;
// Adapt to the desired python version - Will only work with this version
gModule := TPythonModule.Create(nil);
gModule.Engine := gEngine;
// This must match the ProjectName and the function name pattern
gModule.ModuleName := 'macosfmxrunner';
gEngine.LoadDllInExtensionModule();
Result := gModule.Module;
// this line did the trick !
TNSScreen.Wrap(TNSScreen.OCClass.mainScreen);
except
on E: Exception do begin
WriteLn('An error has occurred: ' + E.Message);
end;
end;
end;
exports
PyInit_tatukgis_macos;
begin
end.
If I call: import macosfmxrunner import delphidmx everything seems to work nicely. Furthermore, problems with text entering also seem to be resolved. Tomek |
|
Hi @cosina! Thank you for your contribution.
The dynamic linker first runs the initializers. After that, Python will consume the exported method (the PPyObject as module). So, in theory, that wouldn't solve the deadlock issue, because it doesn't affect the code execution order. Maybe it may work at times and fail at others. I bet the first initializer running in your code is the TScreen one, that's why you first see the TNSScreen. But, there are others to be loaded as well. Maybe the initializers were sorted, maybe it was purely luck (hahaa), it's a deadlock... |
|
Maybe pure luck. I use the official delphifmx build from PyPi. Calling this code after library initialization force the app to initialize GUI context before importing delphifmx At least I have more luck than ever running Python distributions from python.oirg I will test it on several different Macs in the coming days. I also set test runners... so let's see. |
|
Well, the first step in library loading (after loading symbols to memory) is performed by the dynamic linker, which is the "initialization". At this moment, every code placed into the Delphi "initialialization" section will run. So, the "PyInit_tatukgis_macos" will only be triggered after we have the library loaded and initialized. Did you get the point? |
|
If I remember well, the Python version distributed by Conda has GUI initialized. The Python version distributed by python.org doesn't. |
|
You can compile your own Python and try both flag options, with and without GUI initialization. |
|
You miss the point - the helper package does not call fmx at all! So any FMX packages were not initialised upon loading. |
|
Ahh, it is a totally new package. Now I got the point. |
|
I would need to share another library with delphifmx, but it would work at least... |
|
But it import can be added on |
|
Yes, exactly. |
|
The dead-lock issue is fixed in this latest release. Check it out: https://embarcadero.github.io/DelphiFMX4Python/changelog/1.0.5-changelog.html |
|
I just tested on my M1 and M2 mac's and it worked fine. |
jimmckeeth
added
the
Awaiting Feedback
MacOS version: 12.4 /
Chip: Apple M1 Pro
Python ARM compilation
DelphiFMX runs smoothly on Python 3.8. Hower it hungs on Python 3.10 just upon importing:
"from delphifmx import*"
The text was updated successfully, but these errors were encountered: