Re: [myhdl-list] my patches

[Christopher F. <chr...@gm...>]

On 10/18/2011 10:11 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 04:59 PM, Bob Cunningham wrote:
>> If you think MyHDL has conservative policies, you should try to get a
>> Linux kernel patch accepted.
>
> Done: http://www.mail-archive.com/st...@li.../msg00138.html
> You might say this is a trivial patch, but the MyHDL ones aren't
> complicated either (yet).

I don't know if that is a fair example.  You simply asked to have your 
USB VID/PID for your device added.  And if I read the page correctly, 
there was a month delay (3-Nov - 6.Dec).

>
>   >  Are you going to create your own website to host and document your
>   >  fork?
>
> The MyHDL mods are part of a larger HLS project that will, indeed, have
> its own website. So I'd simply distribute the modified MyHDL along with
> it :-)
>
>   >  What I think you mean to say is that you intend for your patch to
>   >  never have more than a single user: You.
>
> Certainly not, and this is also why I posted on this mailing list in
> order to try to avoid forking. But since getting even simple patches
> reviewed/accepted is messy, forking is probably easier for me.

Don't get me wrong, I don't want to discourage anyone, especially 
someone that is very enthusiastic.  But, at this point, maybe it is best 
what you propose; if your main concern is a path of least resistance.

>
>   >  What is the problem you are trying to solve?  Can you distill it to a
>   >  small, clear example?
>
> See my initial emails (about constant drivers and object support), and
> the links to such examples that accompanied the patches.

The constant driver had a good conversation but the conversation 
remained unresolved.  Best I can tell, constant drivers are supported in 
today's MyHDL but not is a form you would like.  The previous question 
of "you disagree with being able to build constant drivers?" simply 
disregarded the previous conversations.

The support for Signals in a class (object) being identified in an 
@always_comb sensitivity list appears to be a good addition.  There were 
some disconnected conversations about class support etc.  But I think it 
will take some time, without further discussion, before anyone has time 
to review the changes, add test cases to the test infrastructure, and 
determine if this is a small change that might lead to larger future 
changes and if so does the implementation fit.


Regards,
Chris