[WIP] API changes #1
Conversation
Proposing a change where a `Peeker` object can be created with a set of
signals instead of a `Peeker` foreach.
```python
p = Peeker(z=z, a=a, b=b, sel=sel)
p.to_wavedrom()
```
This creates a `Peeker` object with the signals to be "peeked" at, in the
keyword parameters the names can be specified. This should work the same
as the existing but you don't need to create a `Peeker` for each signal,
just a `Peeker` for a set of signals. With this approach you can also
create various `Peeker`s at different levels.
Things that should be added:
`Peeker.add_signal(sig)``: method that allows a signal to be added after
creation, could even overload the `__add__`; `p += mysig`
`Peeker.rm_signal(name)`
Add checkers to `to_wavejson` to verify no parameters where passed
via `names` (\*args).
With the API changes one feature was missing from the previous and that was the ability to have a single global peeker that included the signals of all the peekers added through the design. This is handled by keeping track of all the keepers in a global dict. Things that need to be added: 1. add __del__ to remove a peeker from the global list when it is deleted. 2. clear_all function to clear all the keepers from the global list.
|
Thanks for the proposal, Chris. I have a few questions: I like being able to specify the One advantage you list is that only a single You say the proposed change lets you "create various How would I do triggering with a If I had a Another question (somewhat related to the previous two) is what type of object is returned by Let me know your thoughts on this. |
|
I apologize for my late response, unfortunately will be the case for a while :)
Yes there could be a method to do this. If this is a rare case then it might make sense, if this is a common case (using a non-valid Python identifier as the name) then it might be more of a pain compare to the existing. What I would propose is: p = Peeker(a=a, b=b, c=c)
p.c.name = "a+b"
I should of said "maintains" this feature.
I don't know at this point in time, I made these changes shortly after you posted the first version - no triggering existed. I haven't looked at the triggering mechanism you have subsequently added. All triggering issues are TBD. Yes, I would say it would be
Currently |
|
Chris, can we get the features you need by defining a new class called but the original |
|
Chris, I implemented my version of your idea and placed it in the |
|
Hey, Chris. I'll assume my changes satisfied enough of your concerns to be acceptable. I'll close this PR but we can re-open it if you disagree. |
Recently after the first release I wanted to propose some API changes, I implemented the changes and tested. Now I see that development has progressed ... before merging with the latest I figured I better post the proposed changes before investing more development time. The following is a description of the proposed API changes.
Proposing a change where a
Peekerobject can be created with a set of signals instead of aPeekerforeach.This creates a
Peekerobject with the signals to be "peeked" at, in the keyword parameters the names can be specified. This should work the same as the existing but you don't need to create aPeekerfor each signal, just aPeekerfor a set of signals. With this approach you can also create variousPeekers at different levels.The tests and examples have been updated in these changes to reflect the proposed API changes. If this proposal is of interest I can merge it with the latest (???) and update this merge request.