Bird|otherbox has quit [Ping timeout: 260 seconds]
Bird|otherbox has joined #scopehal
<azonenberg>
miek: re edge cases i'm wondering about having the list of enum values be device dependent
<azonenberg>
that would actually not be hard to do
<azonenberg>
so for example rather than having AgilentEdgeTrigger, in the EdgeTrigger constructor when i fill out m_parameters[].AddEnumValue
<azonenberg>
have it specify alternating only if RTTI says scope is an AgilentOscilloscope
<azonenberg>
that's not ideal since it puts scope specific knowledge into the trigger class
<azonenberg>
but it avoids a combinatorial explosion of different trigger types
<azonenberg>
as far as pulse width, it's the polarity of the pulse. So rising means a positive going pulse
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
TiltMeSenpai has quit [Quit: TiltMeSenpai]
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-2/±5] https://git.io/JUB2L
<_whitenotifier-f>
[scopehal] azonenberg 516ccb0 - Removed AgilentEdgeTrigger, now just a special case of EdgeTrigger
DanRoh has joined #scopehal
<azonenberg>
miek: so do you think having pulse width trigger not derived from edge trigger makes more sense?
<azonenberg>
my thought is, a pulse trigger is an edge trigger that's conditioned on a second edge happening/not happening within some time window
<azonenberg>
so you start just like an edge trigger, but then apply the second check
<azonenberg>
This seems like an is-a relationship
<azonenberg>
(anybody else have thoughts on this?)
smkz has quit [Quit: @]
smkz has joined #scopehal
DanRoh has quit [Remote host closed the connection]
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JUBoA
<_whitenotifier-f>
[scopehal] azonenberg e368fec - Initial implementation of pulse width trigger for LeCroy. Calling this the end of the trigger refactoring for now. Fixes #216.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #216: Redesign of trigger API - https://git.io/JJor5
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUBKU
<_whitenotifier-f>
[scopehal] azonenberg 720149c - LeCroyOscilloscope: digital channels now have correct hwname for use as trigger sources
<_whitenotifier-f>
[scopehal] azonenberg opened issue #237: LeCroy: add high speed serial trigger support (WR8K-80B-8B10B-TD) - https://git.io/JUBKq
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #237: LeCroy: add high speed serial trigger support (WR8K-80B-8B10B-TD) - https://git.io/JUBKq
<_whitenotifier-f>
[scopehal] azonenberg opened issue #238: LeCroy: add pattern trigger support - https://git.io/JUBKG
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #100: Add more LeCroy trigger sources - https://git.io/JUBKo
<_whitenotifier-f>
[scopehal] azonenberg opened issue #249: LeCroy: Add I2C serial trigger support - https://git.io/JUBKK
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #249: LeCroy: Add I2C serial trigger support - https://git.io/JUBKK
<_whitenotifier-f>
[scopehal] azonenberg opened issue #250: LeCroy: Add SPI serial trigger support - https://git.io/JUBK6
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #250: LeCroy: Add SPI serial trigger support - https://git.io/JUBK6
<_whitenotifier-f>
[scopehal] azonenberg opened issue #251: LeCroy: Add UART serial trigger support - https://git.io/JUBKi
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #251: LeCroy: Add UART serial trigger support - https://git.io/JUBKi
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #252: LeCroy: Add RS232 serial trigger support (apparently this is separate from UART because inverted polarity?) - https://git.io/JUBKP
<_whitenotifier-f>
[scopehal] azonenberg opened issue #252: LeCroy: Add RS232 serial trigger support (apparently this is separate from UART because inverted polarity?) - https://git.io/JUBKP
<azonenberg>
well that was a wall of text
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #172: UI support for window trigger (two draggable arrows for upper and lower bounds) - https://git.io/JUBKH
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #172: UI support for window trigger (two draggable arrows for upper and lower bounds) - https://git.io/JUBKH
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/JUB6a
<_whitenotifier-f>
[scopehal] azonenberg d41f98d - Initial implementation of window trigger for LeCroy. Fixes #243.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-1/±8] https://git.io/JUBiU
<_whitenotifier-f>
[scopehal-apps] azonenberg 7f8afba - Initial UI support for window triggers. Fixes #172.
<_whitenotifier-f>
[scopehal-apps] azonenberg c3964ab - Removed dead ProfileBlock class that hadn't been used for ages
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #172: UI support for window trigger (two draggable arrows for upper and lower bounds) - https://git.io/JUBKH
<_whitenotifier-f>
[scopehal] azonenberg opened issue #253: Selecting external trigger on LeCroy crashes glscopeclient with an out of range std::string::substr() access - https://git.io/JUBX3
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #253: Selecting external trigger on LeCroy crashes glscopeclient with an out of range std::string::substr() access - https://git.io/JUBX3
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/JUBXG
<_whitenotifier-f>
[scopehal-apps] azonenberg 5488366 - TriggerPropertiesDialog: now provide control of trigger offset. See #12.
<_whitenotifier-f>
[scopehal-apps] azonenberg 64b538f - Timeline now displays trigger position arrow. Might make it draggable later, but for now it can be changed by the trigger properties dialog. Fixes #12.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #12: Add UI for selecting trigger horizontal position - https://git.io/JUBXZ
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #173: Make trigger position arrow in timeline draggable - https://git.io/JUBXW
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #173: Make trigger position arrow in timeline draggable - https://git.io/JUBXW
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUB1n
<_whitenotifier-f>
[scopehal] azonenberg closed issue #253: Selecting external trigger on LeCroy crashes glscopeclient with an out of range std::string::substr() access - https://git.io/JUBX3
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JUBDO
<_whitenotifier-f>
[scopehal] azonenberg 4f83855 - Refactoring: WindowTrigger now derives from TwoLevelTrigger, which can be used for UI event handling
<Bird|otherbox>
azonenberg, something to me says that your situation is kinda like how Square isn't Liskov-substitutable for Rectangle? (in other words, I'd look closely at whether PulseWidthTrigger satisfies the LSP)
<azonenberg>
Bird|otherbox: I'm not sure that's a big deal in this situation
<azonenberg>
you can treat a pulse width trigger just like an edge trigger and ignore the additional settings on it, and it will change just like you expect
<azonenberg>
a pulse width trigger is literally an edge trigger with a second edge trigger and a time-delay check added to it
<azonenberg>
if i were building it in hardware, it would be a tiny state machine around the same trigger circuit
<azonenberg>
So it seems natural to say that an edge trigger is a strict subset of a pulse width trigger that has infinitely permissive constraints on the width
<azonenberg>
This doesn't seem any different from having a base widget class for a text entry that has a subclass for a numeric text entry that does filtering on keystrokes and only allows you to type digits
<azonenberg>
yes, it's not exactly the same behavior, but within the context of how it's used it's LSP'able
<azonenberg>
If you adhered strictly to Liskov, you'd never be able to derive from any widget class to add new features :P
<azonenberg>
So I prefer a looser definition especially in UI-type code: will code presented with a derived class object instead of a base class object be confused?
<azonenberg>
essentially, it's OK if human/outside world facing conditions change as long as the code in the library talking to the object doesn't need to know what it's dealing with
<azonenberg>
because the OO API only exists within libscopehal. The fact that the hardware in the scope does something different for the derived class is fine