Thread: [myhdl-list] my patches
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Sébastien B. <seb...@mi...> - 2011-10-07 21:18:05
|
Hi, could you consider applying the two patches I sent last month? http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list Thanks, Sebastien |
|
From: Ben <ben...@gm...> - 2011-10-10 09:53:03
|
That's not a comment on the content of your patches, but the fact that your tests are at another places burden me. This means, if someone wants to look t it, he has to look at two places at the same time, ... You'd have better chance at someone looking at them if you include the tests in MyHDL testing framework ... This way, also, someone making maintenance on those feature will know if he broke it. Good luck with it ! Benoit On Fri, Oct 7, 2011 at 23:17, Sébastien Bourdeauducq <seb...@mi...> wrote: > Hi, > > could you consider applying the two patches I sent last month? > http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list > http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list > > Thanks, > Sebastien > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Jan D. <ja...@ja...> - 2011-10-17 13:13:07
|
On 10/07/2011 11:17 PM, Sébastien Bourdeauducq wrote: > Hi, > > could you consider applying the two patches I sent last month? > http://sourceforge.net/mailarchive/forum.php?thread_name=4E6E2255.9070201%40milkymist.org&forum_name=myhdl-list > http://sourceforge.net/mailarchive/forum.php?thread_name=4E6DF9C2.7000502%40milkymist.org&forum_name=myhdl-list I believe the guidelines are reasonable, clear, and have been communicated to you before: http://myhdl.org/doku.php/dev:patches -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Sébastien B. <seb...@mi...> - 2011-10-17 13:16:52
|
On 10/17/2011 03:12 PM, Jan Decaluwe wrote: > I believe the guidelines are reasonable, clear, and have > been communicated to you before: > > http://myhdl.org/doku.php/dev:patches So, what's the deal? You just want a hg bundle instead of copy-pasting my email into the patch command? Or are there other problems? |
|
From: Sébastien B. <seb...@mi...> - 2011-10-18 08:52:28
|
On 10/18/2011 10:03 AM, Jan Decaluwe wrote: > The deal is: we work efficiently by agreeing on a spec > first, So, do you disagree with being able to build constant drivers? Or being able to read signals within objects in @always_comb blocks? > you do all the hard work including testing and > fixing problems, Yes, I can certainly improve testing a bit, as has already been pointed out. Other comments? Sébastien |
|
From: Jan D. <ja...@ja...> - 2011-10-20 22:44:18
|
On 10/18/2011 10:49 AM, Sébastien Bourdeauducq wrote: > On 10/18/2011 10:03 AM, Jan Decaluwe wrote: >> The deal is: we work efficiently by agreeing on a spec >> first, > > So, do you disagree with being able to build constant drivers? Or being > able to read signals within objects in @always_comb blocks? Ok. So I describe the methodology for *agreeing*, and you interprete it as me disagreeing. That is just stupid, bad faith and a sign that I'm really wasting my time here. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Jan D. <ja...@ja...> - 2011-10-18 08:04:24
|
On 10/17/2011 03:13 PM, Sébastien Bourdeauducq wrote: > On 10/17/2011 03:12 PM, Jan Decaluwe wrote: >> I believe the guidelines are reasonable, clear, and have been >> communicated to you before: >> >> http://myhdl.org/doku.php/dev:patches > > So, what's the deal? You just want a hg bundle instead of > copy-pasting my email into the patch command? Please. Don't reduce the guidelines to a way to create changesets. (Actually, the guidelines give you two options, at your discretion, exact command line sequences included.) The deal is: we work efficiently by agreeing on a spec first, you do all the hard work including testing and fixing problems, and you get the credit for the work through authoring information. That is what the guidelines try to accomplish. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Sébastien B. <seb...@mi...> - 2011-10-18 09:55:14
|
On 10/18/2011 11:42 AM, Ben wrote: > So what now ? Well, since I disagree with your conservative policies, I will fork MyHDL. |
|
From: Christopher F. <chr...@gm...> - 2011-10-18 11:20:24
|
On 10/18/2011 4:51 AM, Sébastien Bourdeauducq wrote: > On 10/18/2011 11:42 AM, Ben wrote: >> So what now ? > > Well, since I disagree with your conservative policies, I will fork MyHDL. > Since when is *good* Engineering anything but good Engineering? I don't think what is being asked is much different than many other open-source efforts. If you wanted to contribute a change (not a bug fix) to the Python source, I believe you would need to do the same. .chris > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct |
|
From: Jan D. <ja...@ja...> - 2011-10-20 22:51:59
|
On 10/18/2011 11:51 AM, Sébastien Bourdeauducq wrote: > On 10/18/2011 11:42 AM, Ben wrote: >> So what now ? > > Well, since I disagree with your conservative policies, I will fork MyHDL. Yes, please fork off. I will keep the "conservative" policies, thank you. The rest of the community will be thankful that I didn't commit an obviously broken patch that breaks the core tests. Which you could have found out yourself by simply following the guidelines. Imagine what a mess this would become if left to overly self-confident people like you. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Sébastien B. <seb...@mi...> - 2011-10-18 15:15:08
|
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). > 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. > 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. S. |
|
From: Bob C. <Fl...@gm...> - 2011-10-18 21:26:05
|
On 10/18/2011 08:11 AM, Sébastien Bourdeauducq wrote: > On 10/18/2011 04:59 PM, Bob Cunningham wrote: > > 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. I've read your recent messages, and they all started way above my present level of knowledge. I didn't even know what questions to ask! The best I could think to do was to save them, with the hope of returning to them when I've learned more. But by then the issue itself will likely be long forgotten. Not that I need to be involved, but I was hoping to understand a point of view that appears to be somewhat different from the default MyHDL perspective. If I can grab onto a low-hanging branch, I will work very hard to climb up and learn enough to hopefully become a useful participant in the discussion. If you have the time, and if it is worth the effort, would you please try to explain your intent from 'first principles'? As if to an EE sophomore? I'm a 25 year embedded/real-time software developer and Python user, a veteran system and algorithm designer who is comfortable both at the bottom level of DeMorgan's Theorems, and also at the top level of complex digital devices (as black boxes). Way back in the early days of tiny PALs, I did all the PALASM programming on several projects, until it became part of the EE curriculum. More recently, I've spec'ed algorithms for portions of several FPGAs, worked closely with the EEs who implemented them, then tested the programmed hardware. Unfortunately, I haven't been able to understand their implementation, other than to ensure it correctly implemented the specification. I'm presently trying my best to fill in that knowledge gap! Needless to say, I'm also coming from quite a different perspective than most on this list (mainly lack of an EE education and experience). I believe your perspective may be very important, if only I understood it. -BobC |
|
From: Christopher F. <chr...@gm...> - 2011-10-19 14:21:20
|
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 |
|
From: Jan D. <ja...@ja...> - 2011-10-20 23:20:32
|
On 10/18/2011 05:11 PM, 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). In your simplistic view of things. In reality, you have gained zero understanding of what 'yield None' in MyHDL really means. Following the guidelines would at least have told you that there is something fundamentally wrong. > > 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. No, it's your patch that is messy (fundamentally broken even). The guidelines are there to avoid that I have to waste time on such kludgy work. Even after several rounds of insisting, you still didn't get the hint. I've really had it with that kind of unwarranted self-confidence. > > 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. > > S. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Sébastien B. <seb...@mi...> - 2011-10-21 09:10:09
|
What a way to welcome new potential contributors :-) and yes, I will fork (and have a closer look at this "yield None" 'fundamental' problem in my first patch, thanks for pointing it out). On 10/21/2011 01:19 AM, Jan Decaluwe wrote: > On 10/18/2011 05:11 PM, 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). > > In your simplistic view of things. In reality, you have gained zero > understanding of what 'yield None' in MyHDL really means. Following > the guidelines would at least have told you that there is something > fundamentally wrong. > >> > 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. > > No, it's your patch that is messy (fundamentally broken even). The > guidelines are there to avoid that I have to waste time on such kludgy > work. Even after several rounds of insisting, you still didn't get the > hint. I've really had it with that kind of unwarranted self-confidence. |
|
From: Jan D. <ja...@ja...> - 2011-10-21 10:14:18
|
On 10/19/2011 04:20 PM, Christopher Felton wrote: > 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. Right. In my view, MyHDL today has a superior solution called initialization. Look at it this way. Suppose there would be some kind of "constant driver" support from some generator. (Actually, the @instance generator may offer this today, depending on whether the solution should be synthesizable or not. The suggestion to add this to @always_comb seems to clash with its semantics to me.) In that case, how should the Signals in question be initialized? Remember, the initial value is an explicit part of the Signal construction, you have to choose one. (This is MyHDL, not Verilog). It certainly would seem confusing and dubious coding if the initial value would be different from the "constant driver" value. Any code reviewer would spot this as an obvious weak point in the code, and suggest to initialize the Signal to the "constant" value. Which proves that the case for special generator support is without merit, as simply specifying the initial value is a solution that works today. > The support for Signals in a class (object) being identified in an > @always_comb sensitivity list appears to be a good addition. I agree. And thanks for a meaningful discussion. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
|
From: Sébastien B. <seb...@mi...> - 2011-10-21 12:27:17
|
On 10/21/2011 12:13 PM, Jan Decaluwe wrote: > In that case, how should the Signals in question be initialized? > Remember, the initial value is an explicit part of the Signal > construction, you have to choose one. (This is MyHDL, not Verilog). > It certainly would seem confusing and dubious coding if the > initial value would be different from the "constant driver" > value. Any code reviewer would spot this as an obvious weak point > in the code, and suggest to initialize the Signal to the > "constant" value. This does not shock me more than the signal having a different value than its initial one after it has been driven by, say, a AND gate. In my opinion, directly supporting constant logic functions is more practical (e.g. with less typing for the user) and cleaner design than having to work around the MyHDL limitation by declaring a new signal with the constant value you need, and connecting it to the signal you want to drive. Maybe the initial values could be made optional? And give an error if any signal without an initial value is not driven? S. |
|
From: Ben <ben...@gm...> - 2011-10-18 09:43:02
|
On Tue, Oct 18, 2011 at 10:49, Sébastien Bourdeauducq <seb...@mi...> wrote: > On 10/18/2011 10:03 AM, Jan Decaluwe wrote: >> The deal is: we work efficiently by agreeing on a spec >> first, > > So, do you disagree with being able to build constant drivers? Or being > able to read signals within objects in @always_comb blocks? > The point is that we shouldn't be reading your patch and try to understand from it which is the problem you tried to solve. You'd better introduce them in the following way: 1. This is my problem Stop here wait for feedback: Maybe people won't agree that it is a problem, and they might rely on this as a feature. 2. This is an example on how it could be solved Stop here and wait for feedback: Maybe someone can find a more elegant way to fix it. 3. Following patch tries to achieve that. Repeat step 3. until the patch get accepted. 4. Enjoy having fixed something in the MyHDL source code, and having your name in it. You jumped to step 3. without defining the "that", with a note that the tests are hidden on the other side of an URL. This is the reason no one bothered looking at it, we don't want to play hide and seek with your hypothetical issues. So what now ? Now that you wrote a patch, you should introduce it to this list with a description about which problem you faced, and how you fixed it. To this date, I still haven't seen this. (Might be scattered among multiple emails, but I don't want to bother trying to put all the pieces together though.) If you want to make it right, I recommend you writing a MEP (http://myhdl.org/doku.php/meps:intro) and hosting it on the wiki among the other ones. If you do think your feature is so simple that you don't need such a document, mail should do. Good luck ! Benoit. |
|
From: Bob C. <Fl...@gm...> - 2011-10-18 14:59:40
|
On 10/18/2011 02:51 AM, Sébastien Bourdeauducq wrote: > On 10/18/2011 11:42 AM, Ben wrote: >> So what now ? > Well, since I disagree with your conservative policies, I will fork MyHDL. That is certainly your prerogative, but I'd recommend against it. Becoming part of a community can be difficult, but I believe both the process and the result are best for everyone. The goal isn't personal glory or self-aggrandizement. The goal is to evolve the product in a direction that benefits the entire community. If you think MyHDL has conservative policies, you should try to get a Linux kernel patch accepted. The MyHDL guidelines distill the wisdom of the engineering process in a manner that invites community participation. I once tried to submit a Linux memory management patch, and by the time I was pushed and shoved through the community process, another programmer had created a patch that solved my specific problem much better than my original patch, while also solving other issues raised during the discussion. Plus, his code was smaller, simpler, faster, and far better than mine. It was a humbling experience, but it was also massively educational. My main contribution wasn't my patch, but my description of the problem I was trying to solve. Once the community agreed there was a problem, had fully fleshed it out, then agreed that it did need solving, the issue gained a life of its own. I would have saved myself a lot of time, and gotten my problem solved sooner and better, if I had gone to the LKML before I had written a single line of code. Plus, I doubt you really mean you are going to 'fork MyHDL'. Are you going to create your own website to host and document your fork? Are you going to port future changes to the MyHDL base over to your fork? I doubt it: If you were willing to do that much work, you would have started it in this list. What I think you mean to say is that you intend for your patch to never have more than a single user: You. What a waste! I'm very much a digital design and MyHDL newbie, and I was looking forward to the discussions that could have surrounded your patch, not starting with the patch (the patch is the END of the story, not the start). I'm far from ready to look at your code: I would very much prefer to understand the problem you are trying to solve, to see why MyHDL can't handle it as-is, to learn from you, to see how you think, to see how the rest of the MyHDL community responds so I can learn more about how THEY think. But when asked to start at the beginning, you instead choose to take your toy and run away from the playground. Which is absolutely your right to do: The code you wrote is your property, and you can do whatever you want with it. But it leaves me feeling cheated of a great learning opportunity. Please, take a deep breath, take a step back from your code, and try to start from the beginning: What is the problem you are trying to solve? Can you distill it to a small, clear example? Can you help us see that a change to MyHDL (rather than a different design approach to the problem) is the best way to solve the issue? Please? -BobC |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X