-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Error when importing pyGHDL
packages
#77
Comments
|
The issue is somehow in pyTooling 4.0.1, and I have no hope that any fix will be backported. This issue can be monkey-patched by changing in @export
class Base(
Generic[DictKeyType, DictValueType],
- metaclass=ExtendedType, useSlots=True
+ metaclass=ExtendedType, useSlots=False
): and in @export
-class Node(Generic[IDType, ValueType, DictKeyType, DictValueType], metaclass=ExtendedType, useSlots=True):
+class Node(Generic[IDType, ValueType, DictKeyType, DictValueType], metaclass=ExtendedType, useSlots=False):
"""
A **tree** data structure can be constructed of ``Node`` instances. This presumably breaks some features, but pyGHDL seems to run okay at first glance. Again, this is a monkey-patch, and the correct fix is to upgrade to a working version of pyTooling. EDIT: pyTooling version 6.7.0 is definitely okay. You can check other versions for yourself by running |
Hi. I'm currently working on a reworked GHDL pipeline, which will also include some dependency updates. You can find this work here: https://github.com/Paebbels/ghdl/tree/simplify-pipeline It uses pyTooling 6.6. Disabling slots, doesn't change functionality, just speed. The problem mentioned by @pidgeon777 is related to an incompatible change in Python itself. pyTooling needed to add some special handling for |
Great! Thanks for the hard work! Do you think there is a chance it will be merged on the main Also, if I understand correctly, your push will solve the |
The merge will be soon. There is also a transition strategy from old to the new pipeline: (1) both in parallel, (2) remove redundant parts, (3) remove unused scripts needed by the old pipeline, ...
Yes and no ... depends on what you use/need. Then there is pyGHDL and especially pyGHDL.DOM itself. All features existing to this point should work - as tested by CI/CD and testcases. While pyGHDL fall behind, GHDL and it's testcases advanced. Especially the I might disable one or two checks to get it released, and start from there with further adaptions. It's hard to translate the IIR, when there is barely a documentation :). |
Hi Paebbels, Thank you for the prompt reply. Given the current state of the transition and the upcoming merge, would you recommend waiting for the merge into the main GHDL repository before attempting to import pyGHDL again to see if the error discussed in this issue still persists? Just to tackle one problem at a time. |
If you want to try, have a look here (latest pipeline): https://github.com/Paebbels/ghdl/actions/runs/11318447350 Here you see: GHDL got build as libghdl and installed as a platform specific wheel to the target system. Then it checks the proper installation of e.g. the LSP executable or the pyGHDL.DOM test utility. Afterwards the LSP and libghdl testsuites are executed (DOM is disabled). If I'm right, there error reported in the issue would have been triggered already by these testcases, independent of the disabled DOM tests. You can activate DOM tests in your local setup and it will report the translation issue. |
Thank you, I'm going to give it a look once I finish my tasks 👍. |
I tried to run this code:
but the second import crashes:
I will provide any additional information if needed.
The text was updated successfully, but these errors were encountered: