Closed bavovanachte closed 5 years ago
Thanks for reporting. It is maybe something around that. Beside the fact that it should be fixed to match wavedrom behavior, I suggest you use subcycles for this case, which is probably better suited.
This will take a bit longer as it is a weird cornercase. You are right about the integer. There is only one non-integer case allowed and this is 0.5 I think. So I have tested adding some subsampling and it looks halfway okay, but then the use of "n" introduces a lot of weirdness in the code. wavedrom does not seem to apply the period to this one (compare vs. using "l" instead in the bus signal everywhere you use "n"). It seems solvable, but is a bit ugly.
That would be the wave with l instead of n:
{"name": "bus", "wave": "h.nh.nh.l..hlx.hlx.hlx.hlx.hlx.hlx.hlx.hlx.hnh.l..hlx.hlx.h", "period": 0.5},
That's the same with subcycles instead of period (which is cleaner IMHO):
{"name": "bus", "wave": "hnhnhln<lx.h><lx.h><lx.h><lx.h><lx.h><lx.h><lx.h><lx.h>nhln<lx.h><lx.h>"},
Solved in c5e792a
Your original code and my suggestions should all work now. I have also added regresssions to not break them in future. If you have time it would be awesome if you could add some of the more fiddly waveforms you are rendering as your own regressions. They are simple to add, you just need to generate the expected list of bricks like this:
w = WaveDrom()
w.lane.phase = 0
print(w.parse_wave_lane("p...", -0.5))
The second parameter is the "stretch", which calculates as hscale*period - 1. This would be highly appreciated!
Thanks a lot for looking into this so fast! My colleague who found the issue checked your fix and it seems to work fine! I'll try to add the diagrams to the regression tests this weekend!
Awesome, thanks a lot. You can also send me wave descriptions that are good and I can create the regression if its easier.
Given the following json
wavedrom produces this result:
But wavedrompy produces this:
Could this have something to do with the fact that period is a decimal number?