Skip to content
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

Does not look to be actively maintained #21

Open
michael-etzkorn opened this issue Sep 12, 2021 · 14 comments
Open

Does not look to be actively maintained #21

michael-etzkorn opened this issue Sep 12, 2021 · 14 comments

Comments

@michael-etzkorn
Copy link

michael-etzkorn commented Sep 12, 2021

It's a shame that such a great idea for a simple hdl parser which isn't tied into a larger bloatier package of tools and keeps within the simple scripting framework of the very popular scripting language python (does not require compiling as c++, more suitable for scripting, more widely used than perl) is no longer being actively maintained.

That being said, there are forks out there that are continuing the groundwork of this repo (it'd be nice if we could merge and move forward some of these ideas together so engineers aren't busy duplicating each other's work):

https://github.com/zhelnio/hdlparse (default parameter support, comments in parameters parsed correctly)
https://github.com/andresmanelli/hdlparse (I don't know much about vhdl, but seems this provides support for parsing entities).

@Paebbels
Copy link

I could offer to host this project under https://github.com/hdl, but we would need a maintainer to take care of it.


/cc @umarcor

@umarcor
Copy link

umarcor commented Sep 12, 2021

Agree. Should we move/fork this to hdl/parse, I would provide an index/list of the open source HDL parsers I am aware of (GHDL, rust_hdl, pyVHDLParser, Verible, Surelog, Yosys, hdlConvertor, etc.) (see https://github.com/Nic30/hdlConvertor#similar-projects), along with an explanation about why a Python only solution is useful despite being feature-limited on purpose.

/cc @mithro

@umarcor
Copy link

umarcor commented Sep 12, 2021

I'm pinging @andresmanelli, @KatCe, @vvvverre and @zhelnio. Those seem to be the users that have been improving the project lately: https://github.com/kevinpt/hdlparse/network. Maybe any or some of them wants to take care of co-maintaining.

@vvvverre
Copy link

I agree that it would be nice to pull together the work that everyone has been doing. I agree that there is a high risk of repeated work with the current situation. There are a few features I like which are already in other forks.

I am happy to be a (co-)maintainer of any new repo. It would be great if we could get a few of the active devs together to set up and maintain a new repo.

@Paebbels
Copy link

@kevinpt How should we proceed?

I assume you don't have the time anymore nor man-power to maintain this project in the future. Even if you have the time or you get somewhen later find more time for this project, you still can be a maintainer at a new namespace.

  • Should we fork this repo and integrate the contributors work in the https://github.com/hdl namespace or
  • @kevinpt can you transfer the project to HDL or
  • Do you have other suggestions?

@andresmanelli
Copy link

Hello all ! I'll be happy to contribute with my fork, but I can't assure I'll have bunch of time to maintain (my repo was waiting for some PRs for a year now). I could try though and give a hand.

I merged two PRs that were pending (one from @KatCe and one from myself).

Unfortunately this also breaks https://github.com/kevinpt/symbolator, (see kevinpt/symbolator#8 for example) and now with the new VhdlParameterType in place, there some adjustments to be made. So my question is, shouldn't we/someone do the same for Symbolator ?

@umarcor
Copy link

umarcor commented Sep 13, 2021

Precisely, earlier today I found that CI in im-tomu/fomu-workshop is failing because of Symbolator. I asked @mithro and he told me that they forked it to symbiFlow/symbolator some time ago. They did not fork hdlparse, though.

Therefore, it might make sense to either fork this to symbiFlow/hdlparse, or move both symbiFlow/symbolator and a fork of hdlparse into org hdl. @mithro @mgielda @PiotrZierhoffer @kgugala, what do you think?

For completeness, in the context of GHDL, we've been working on pyGHDL and pyVHDLModel, which provides a potential replacement for this repo's VHDL parsing capabilities. We would like to tweak Symbolator so that it can use either hdlparse or pyGHDL.dom. I would find it sensible to have a similar effort done with Verible/Surelog/UHDM (if not done already).

Anyway, out of courtesy, I would prefer to have some feedback from @kevinpt first.

@umarcor
Copy link

umarcor commented Sep 13, 2021

@qarlosalberto @smgl9, I can never remember it properly: are you still using hdlparse and/or symbolator in TerosHDL? Or did you replace the functionality with your own solution based on tree-sitter?

@qarlosalberto
Copy link

We use tree sitter VHDL, tree sitter Verilog and we draw the diagram with our own JS library :)

@KatCe
Copy link

KatCe commented Sep 14, 2021 via email

@umarcor
Copy link

umarcor commented Sep 23, 2021

After discussing it with @Paebbels, @mithro, @PiotrZierhoffer and @kgugala, I think we all agree on having Symbolator and hdlparse forked/moved to github.com/hdl.

@michael-etzkorn
Copy link
Author

Thanks for helping keep HDLParse alive! I've found it the easiest to get started with of all the parsers I've looked at. I did notice as I was using it some things to improve so expect a pull request from me in the future on the new fork 😄 I'd also be willing to chip in to maintenance / reviews / documentation on the new fork.

@mithro
Copy link

mithro commented Sep 23, 2021

The SymbiFlow fork has been moved to github.com/hdl -- see https://github.com/hdl/Symbolator

@umarcor
Copy link

umarcor commented Sep 23, 2021

I forked this repo to github.com/hdl as well: hdl/pyHDLParser. Let's continue the discussion in hdl#1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants