If the BDFL and everyone else who have merging rights are missing for an unknown amount of time, I suggest you use DrPi’s repository either until they get back or until you decide to fork the project. The longer you wait, the messier its gonna be to get back on track.
I’m just a (somewhat inexperienced) MyHDL user who’d hate to see this project die, so I thought I’d add my opinions to the discussion.
It would be such a shame if the project dies just because two people become inactive, especially when there clearly is a community willing to submit pull requests and take the project forward.
IMHO, 7 months of no communication at all is a very long time. Had I been in your position, I think it would be a good time to consider making a fork.
I’m not trying to whip you guys into working more by the way. Just adding my two cents in the form of some opinions.
ok so this is one of the critical down-sides to github, which i’ve been mentioning for many many years but of course it really does not help because, having ridden in on the “social media craze” github is extremely popular.
personal github pages are personal. they do NOT work as TEAM pages. RepRapFirmware and Marlin Firmware are both total chaos as a result. if you do not understand this clearly, try to find the TEAM that is responsible for maintaining either of these projects. try to even find a TEAM web-site. what you will find instead is dozens of forks.
please for goodness sake everyone, please understand that if you want to develop a TEAM project please use sourceforge, savannah.nongnu.org, or set up your own fusionforge (it’s not that hard). these and alioth.debian.org are all based on the same codebase: a free software project that was originally project 1 on sourceforge, which was SPECIFICALLY designed around TEAM collaboration. it includes GROUP permissions. there are MULTIPLE ssh keys uploaded for git repository commit access. the project is organised around the PROJECT name NOT the PERSONAL USER GIT REPOSITORY.
consequently if any one person decides to stop working on the project and for whatever reason even goes to the extreme of no longer responding, even if all the other admins do not respond, sourceforge provides a mechanism to allow you to request to become a new admin. it takes a long time (deliberately) but it is possible.
in direct contrast you CANNOT request to take control of another person’s PERSONAL github page. because it is PERSONAL.
with fusionforge and derivatives you can always continue to do git pushes and pulls to github and/or personal github repositories: you can even use “git remote update” and you can even use a little-known feature of git to add two or more repository lines to the same entry in the config file.
so i’ve been around software libre for over two decadees, now. sourceforge, savannah, alioth, bitbucket, gitorious - all the quotes unpopular quotes software libre project management sites - are all based around team management. they all allow multiple people’s ssh keys to be added, all with the same commit rights, to the same repository. github does not permit this.
personally, when managing free software projects, i install gitolite3 and then, as people approach me, i add their ssh key to the repository so that they become a member of the group. it means that people need to properly coordinate… but it also means that you now have a single place for people to go to which is no longer critically dependent on a single person.
I know this is an old thread but it seems to be a very important one for a new user such as myself to understand the direction of myhdl.
As a new user of myhdl and add-ons myhdlpeek & pygmyhld from @devbisme I’m really excited about writing HDL in python with all it’s benefits. In particular writing tests is so much easier (at least for me where I have 10X the experience in python over verilog).
However, reading this thread I’m worried if I should invest my time here or just suck it up and write in Verilog? Myhdl seems to be very capable with lots of great examples from several contributors but there are bound to be bugs/enhancements that will continually be needed.
Perhaps there are work arounds that those more experienced have figured out. In fact, @josyb and @DrPi helped me with an issue I was having yesterday. This actually gave me a lot of encouragement that there is an active community willing to help newbies like myself. Thank you very much!
My basic question is whether myhdl will continue mostly “as-is” with workarounds suggested by the community or if there is a plan to continue active development (possibly via a fork)? The latter of course is a huge responsibility and undertaking and one that folks just may not have time for.
So should I stay or should I go?
I look forward to your inputs about the present & future of myhdl
Surely the question to ask is what benefits would come from not using MyHDL? Specifically, what exactly are you worried about? Even if the community evaporates tomorrow, you’ll still have what you’ve written and it will still convert just fine.
The migration path from myhdl->Verilog is not hard (MyHDL writes the verilog for you!), though you might want to refactor things a little.
So, the question in my mind would be, do the myriad benefits of using MyHDL over Verilog now exceed the potential cost of having to migrate at some point in the future? To me the answer is a resounding yes, but obviously you might reach a different conclusion.
Moreover, the MyHDL code base is pretty easy and accessible to hack on. We take the view we’ll just maintain it ourselves if we have to (and in practice, we do). The cost of maintenance is much less than the cost of writing in Verilog .
@hgomersall you make several valid points and I tend to agree that MyHDL as-is is still probably better than verilog. But I think your last point is the one that is both good & bad. It’s unfortunate that many of the enhancements individuals have made can’t be integrated into the main code base so all could benefit and not have to re-invent the wheel.
To be clear, all our changes have been merged into the MyHDL master. My point was that we don’t hesitate to make changes. There are lots of things that people are working on and for whatever reason haven’t been raised as pull requests, but these are invariably features well over and above what Verilog or VHDL can offer.
OK that’s very encouraging! Based on comments such as these earlier in this thread I was (wrongly?) under the impression that PR’s weren’t being merged. This thread is pretty old so something has changed in the past year or so?
And this in response to publishing individual hacked/enhanced code:
Things have considerably improved since I wrote my original lament. @cfelton was given commit rights and we cleared out the backlog.
About viability: there a numerous people using MyHDL as is; it basically works and once you get the more subtle points you will be breezing along … at warp speed (compared to Verilog).
Of course together we can and will improve MyHDL to become even better.
Hey! Our team is considering MyHDL for a few large projects. We see great potential in MyHDL but have some worries rooted in our past experience with it in the recent years. We had found a series of bugs, but no one with commit rights was available, and we ended up fixing things in-house. This was an undesirable outcome as we had to devote time and resources for people to learn the internals of the tool and the changes made to it.
@josyb , @cfelton , what is the situation right now? The last commit on master is from three months ago, and there are 22 open pull requests, all of them are older than that commit. If we were to open new pull requests to add features and fix bugs, what are the chances of them getting reviewed and merged?
Should we consider any other tools, perhaps ones under more active development? I’m planning to give nMigen, magma and HWT a try.
@kmaork
Unfortunately I am more or less in the same position as you: our team is using it and is relying on in-house enhancements too. So we must call on @cfelton and @jck to clean up the PRs.
Assuming it’s hard to get maintainer permissions, and that it is legal according to MyHDL’s license, why don’t we open a central fork of MyHDL (“MyHDL 2”?) with a broader maintainer team, and try to revive the development effort?
From my perspective, the current source code tree has become rather unmaintainable and there are too many incompatible forks around. Plus, there are some architectural limitations that make large procedural HDL generators a real PITA. And the current core architecture is not easily extensible in an orthogonal way, such that change A does not break user B’s code.
However, I’m all up for a fresh discussion on a new architecture. The problem is, that there are many divergent understandings that made some of the software/python folks drop the discussion entirely and go for nmigen.
I think the myHDL community should pick from both sides: (n)migen architectural tactics, but classic HDL style readability.
I’ve got a prototype for a new approach ready, however it’s still in a unstable/experimental stage when it comes to MyHDL compatibility, plus it currently supports (direct hierarchical) VHDL output only. But maybe it helps to distill a wish list or open up the ‘next generation’ discussion.
There’s a binder (executable jupyter notebook) repo plus docker container with plenty of examples for sneak-peeking, entry point:
From the forking perspective, I guess noone will stop you from taking the lead. If the ‘owners’ (whoever that might be) express concerns about the naming, you just rename it, as far as I can see, there’s no trademark involved, so no cease-and-desist-nonsense expected.
Have you really tried? Yes, some of the enhancements and additions didn’t make it easier.
Beware, setting it all up may be quite a task
About the rest: @hackfin : van twee walletjes eten has a negative connotation …
I feel your post here is mostly inappropriate: you are advertising your own work which IMO is not in the interest of the mainstream MyHDL user. Can I suggest you start your own discussion channels?
Yes, I have. I’ve looked at plenty of those many forks before making this last ‘jupyosys’ attempt to move forward. Other than that, I’m afraid I’m not much of a community guy.
I don’t see any negative connotation there with v2we (well aware of the meaning). You could also turn it into ‘v2 working environment’. It’s just a pun…
Further: You’re misunderstanding, I’m far from advertising, as this is a prototype.
The mainstream users will live what with they have, from what I gather from this thread, it says ‘future’. Not much has happened on this thread since…
Good try to work you out of that . Too late, the first definition sticks.
To the Flemish van twee walletjes eten definitely has a negative connotation. Even for the Dutch: https://onzetaal.nl/taaladvies/van-twee-walletjes-eten/
Still, the right thing to do was to start a new thread. This thread started discussing the low activity to update the main MyHDL branch.
.