00:18 <_whitenotifier-5> [glasgow] DurandA commented on issue #274: Invalid glasgow_config after flashing a modified firmware - https://git.io/JY8MP

11:21 <d1b2> <Nana> @Attie it seems that asyncio.sleep is not waiting (at least when calling: await iface.write (data), await asyncio.sleep (1), await iface.write (data)). But maybe I misunderstood something here and I need to take care of the scheduling?

11:43 <d1b2> <Attie> it should do - could you share your code somewhere?

11:52 <d1b2> <Nana> the actual code for this test is nothing more than: await iface.write([0x00]) await asyncio.sleep(2) await iface.write([0xFF])

11:53 <d1b2> <Nana> and calling it via glasgow script

11:55 <whitequark> add `await iface.flush()` before `asyncio.sleep`

12:09 <d1b2> <Nana> oh, wasn't aware of this one. it did work, thank you

12:20 <d1b2> <Attie> ah, great!

12:21 <d1b2> <Attie> @whitequark - i didn't need that previously when working with I2C... is this new for everything, or only required for certain interfaces (which is my expectation)

12:21 <whitequark> look up how TCP sockets work

12:21 <whitequark> I2C reads are internally a write and a read from the underlying stream oriented buffered transport

12:21 <whitequark> so higher layer protocols hide the flushes (not always but usually)

12:23 <d1b2> <Attie> is this using TCP, or similar concept? I was expecting the auto_flush flag to be at play here

12:23 <whitequark> it is not using TCP (currently), but it is a stream oriented transport that is functionally similar

12:23 <whitequark> auto_flush is just for the gateware

12:23 <d1b2> <Attie> understood, thanks!

12:24 <whitequark> arguably this could be different, but it isn't

12:43 <d1b2> <Attie> could be different, but i don't think it needs to be!

12:44 <d1b2> <Attie> might be good to put an example with the flush gotcha included

12:44 <d1b2> <Attie> (@Nana , depending on what you're doing/working with, fancy a PR?)

12:54 <whitequark> sigh

12:54 <whitequark> i hate this. "gotchas" that require "examples" to learn

12:54 <whitequark> awful design

12:57 <d1b2> <Attie> ... i get that / sorry for shining a light on it (or perhaps my wording?)

12:58 <whitequark> first you say that it doesn't need to be different, then you call it a gotcha. pick one

12:59 <whitequark> i lean towards the latter, personally

13:00 <whitequark> but it's rather not obvious how to fix it and still keep the throughput we'd like to have

13:01 <d1b2> <Attie> i guess, from my point of view, it's a technical thing, with a technical reason. once you're aware of how things work underneath, it becomes a thing you know to look for

13:01 <d1b2> <Attie> as you say (re throughput), changing this will cause ripples and affect other things

13:02 <d1b2> <Attie> it is a gotcha, but it's also not totally unreasonable... if that tracks(?)

13:03 <d1b2> <Attie> my only thought would be to add a "flush=True" arg to the write, so it can be overridden when you're after the tigher control/performance

13:03 <d1b2> <Attie> or perhaps something more like TCP_CORK, where you can "pause" the stream, put stuff in the buffer, and then say "go!"

13:04 <whitequark> yeah and how many networking applications set TCP_NODELAY the first thing?

13:04 <d1b2> <Attie> buut... with reasonable docs / examples, this extra complexity becomes unnecessary (crosses-fingers)

13:04 <whitequark> er, CORK is different, but that's even worse, it's hidden state rather than state at boundary

13:05 <whitequark> flush=True is, perhaps, reasonable. it should not cause deadlocks, although it may regress throughput, and a lot of things will have to be audited

13:08 <d1b2> <Attie> yeah...

13:09 <whitequark> something to think of later, I guess

13:10 <d1b2> <Attie> agreed

15:51 <_whitenotifier-5> [libfx2] whitequark commented on issue #6: How to write a response in chunks (USB control read)? - https://git.io/JY0T0

15:52 <_whitenotifier-5> [glasgow] whitequark commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY0TN

16:32 <d1b2> <Hardkrash> I like using context managers to temporarily override “default” timeouts and other parameters.

16:32 <d1b2> <Hardkrash> for example

16:32 <whitequark[m]> the problem is that it's still global state, just automatically cleaned up

16:33 <whitequark[m]> so it makes it harder to compose interface implementations, which is the whole point of glasgow as a tool

16:33 <d1b2> <Hardkrash> `with interface.timeout = 5:

16:33 <whitequark[m]> using a defaulted arg is more local, though not entirely so

16:34 <d1b2> <Hardkrash> the context manager can be local as well, and contained in the sub class and tidies up after itself.

16:35 <d1b2> <Hardkrash> in composting in my automation experience chaining the defaulted arguments down the rabbit hole leads to a messier function signature.

16:35 <whitequark[m]> if you stuff the mess into the global state it does not go away, it's just harder to understand

16:36 <whitequark[m]> this is sometimes appropriate but very rarely so

16:37 <d1b2> <Hardkrash> i don't know if i understand how you are defining global here, I don't see the code that i have written as global state. in a mutexed interface it is not at a global level, but I might be missing what makes this global in Glasgow's context.

16:38 <whitequark[m]> a high-level glasgow applet is a stack of interface classes that ultimately operate on an (currently USB) FIFO

16:39 <whitequark[m]> flushing and timeouts are a property of the FIFO

16:40 <d1b2> <Hardkrash> is that fifo a shared resource?

16:41 <d1b2> <Hardkrash> or owned by a stack of classes?

16:41 <whitequark[m]> so either only the lowest-level applet manipulates the FIFO, in which case there is no need for context managers (if you need all writes to look a certain way, you use a function--and a lot of applets already do wrap FIFO writes that way), or multiple interface classes manipulate the FIFO state, such as flushing, in which case it has the same fundamental issues as global state

16:41 <whitequark[m]> in neither of these cases are context managers solving anything. at best you're rearranging things around

16:42 <whitequark[m]> the FIFO is owned by the stack of classes. it's effectively the lowest layer of the stack, the only one provided by the device communication code itself

16:48 <d1b2> <Hardkrash> I see that prospective, but there is the third case that i use. Where some times calls need to have special parameters. in efforts to not burden the function signatures throughout the stack about understanding other layers configurations, you now gain abstraction that can skip layers and ease compostability with mix-ins.

16:48 <whitequark[m]> "abstraction that skips layers" is an oxymoron

16:49 <whitequark[m]> with timeouts in particular, if a certain layer in the stack does not support them, it means they are not supported period. if you try to interrupt a layer that doesn't explicitly opt into that, you have to reset the entire thing, including the gateware

16:49 <d1b2> <Hardkrash> would the phrasing be that a peer layer need not know about it's full peers function signatures?

16:50 <_whitenotifier-5> [glasgow] marcan commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY0ls

16:50 <whitequark[m]> i don't really care about function signatures

16:51 <whitequark[m]> either a layer is designed to be interrupted with a timeout, or not, and if you do design something to be recoverable after an interrupt, function signatures are the least complex of your problems

16:52 <whitequark[m]> to rephrase

16:53 <whitequark[m]> if you use a context manager this way, it means that all of the functions down the stack gain an additional implicit argument that everyone working on them must know about and consider when changing or inspecting

16:53 <whitequark[m]> that is a very large hammer that is sometimes appropriate, but most of the time, making the signature "messier" actually makes it more clear exactly what inputs affect the state at any given level

16:54 <whitequark[m]> if the additional arguments annoy you, perhaps you should reconsider your entire approach rather than shuffling them under the rug

16:57 <_whitenotifier-5> [glasgow] whitequark commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY04T

18:44 <_whitenotifier-5> [glasgow] electroniceel commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY01u

18:55 <_whitenotifier-5> [glasgow] whitequark unassigned issue #281: P and N pins are swapped on revC2 - https://git.io/JYlsx

21:56 <_whitenotifier-5> [glasgow] TomKeddie commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JYEtd

23:11 <d1b2> <mossmann> What part is the yellow LED in the upper right? It looks like it might be more bright yellow and less amber than most yellow LEDs (not that it is easy to tell in a photo).

23:12 <d1b2> <esden> https://cdn.discordapp.com/attachments/613461005392936961/826594779398930463/led-chart.jpg

23:12 <d1b2> <esden> here is the full chart 🙂

23:17 <d1b2> <mossmann> Thanks! I guess I was looking at NCD0603Y1 which is one I have tested myself.

23:18 <d1b2> <esden> yeah it is the Y1

23:18 <d1b2> <esden> these are the same photos as above... just organized and labeled