17:34 <d1b2> <mwick83> hi everyone! I just got my own glasgow thanks to @Attie and I started to experiment a bit with the cli tool and the spi_master applet. Well, what I instantly started to think about is how the glasgw framework is supposed to be used in a scripted environment. What I mean: Suppose I have more or less complex SPI device, which I want to interact with, but not by calling multiple calls to the cli tool, but by running a loop/event based script, e.g. I'm

17:34 <d1b2> sending a command, get the response and depending on the repsonse I send something else and so on. I saw the run-repl command, which is should work for very simple scripting, but I would rather like to write my code in a separate python file. How would such a scenario be best implemented? Do I write my own Applet that subclasses from the SPIMaster Applet? Or does the "cli" have an exported API for such scenarios that I can import and make use of in my own python

17:34 <d1b2> script?

17:36 <tnt> I think at the moment you pretty much have to write your own applet.

17:37 <tnt> alternatively you can make your own applet that act as a server through some RPC mechanism to interacti with whatever external script you need.

17:41 <d1b2> <mwick83> @tnt okay, thanks. I see, I thought I was missing something obvious. So, yeah, I guess writing my own applet would be the way to go

17:42 <d1b2> <Attie> glad you received it ok!

17:42 <d1b2> <Attie> i'd also suggest writing your own applet... possibly extending the existing, and overlaying the run(), or possibly adding an interact() function if that suits

17:43 <d1b2> <mwick83> yes, that's what I hand in mind. Just wanted to make sure, I didn't miss an obvious API of the cli for such scenarios

17:43 <d1b2> <Attie> don't forget that only the first execution will build and load the bitstream, so subsequent executions of the same applet should be pretty quick

17:44 <d1b2> <mwick83> It's not that easy to get a quick overview of the intended usage of the applet/cli flow 😉

17:45 <d1b2> <mwick83> actually, I'm not quite sure how to organize my workspace for such more or less personal / custom applets

17:45 <tnt> AFAIR I think being to import some python module and interact programatically in a larger app is a goal but ... not done yet.

17:59 <d1b2> <mwick83> is there a flow/possibility to manage own applets kind of out-of-tree?

18:19 <electronic_eel> mwick83: whitequark thought about a way to have out-of-tree applets, but IIRC there wasn't a clean and easy way to do it. so it is currently not implemented yet

18:28 <d1b2> <mwick83> Got it, thanks

21:57 <whitequark> electronic_eel: there is, I believe, using pip

21:58 <whitequark> it's just that I haven't got around to it

21:58 <electronic_eel> ah, so I misremembered

21:58 <d1b2> <Attie> a similar mechanism to pytest's plugins perhaps?

21:58 <whitequark> regarding the original question of mwick83 though, it is also reasonably easy to run glasgow applets (or their chunks) in the Python REPL; it's not currently discoverable though

21:59 <whitequark> Attie: I think so, there's basically one setuptools mechanism for that

21:59 <electronic_eel> how would the import work for an external applet?

21:59 <d1b2> <Attie> sounds good

21:59 <electronic_eel> is it using more ... than we currently have to go out of the tree?

22:00 <whitequark> no, you'd just go `from glasgow import`

22:00 <whitequark> since the setuptools plugin would also reference glasgow explicitly, no way around that

22:01 <d1b2> <Attie> iirc, you define a custom entrypoint for the package (alongside the CLI entrypoint), using a special name... other packages are then able to discover their plugins for example

22:01 <electronic_eel> but then you don't call the normal glasgow cli from the shell, but your own program

22:01 <electronic_eel> or am I wrong there?

22:02 <d1b2> <Attie> so here, glasgow as it stands would be updated to "discover" other installed packages that provide relevant entrypoints

22:02 <whitequark> electronic_eel: with setuptools plugins, you'd just get extra applets in the list

22:03 <whitequark> electronic_eel: https://setuptools.readthedocs.io/en/latest/userguide/entry_point.html

22:03 <d1b2> <Attie> re mwick83's original question, I was considering suggesting something like pexpect to drive the python interface

22:03 <whitequark> that's horrible

22:04 <d1b2> <Attie> haha, okay... maybe not

22:04 <whitequark> re "I saw the run-repl command, which is should work for very simple scripting, but I would rather like to write my code in a separate python file.

22:04 <whitequark> "

22:04 <whitequark> you can do something like `exec(open("myfile.py"))` in the REPL

22:04 <whitequark> and we should probably just add an option to run-repl that executes a file so this isn't necessary

22:04 <d1b2> <Attie> yeah, fair

23:15 <d1b2> <Attie> this seems to be a non-trivial problem, as it's necessary to call device.demultiplexer.flush frequently

23:15 <d1b2> <Attie> currently in run-repl, "frequently" = between each statement

23:16 <whitequark> Attie: REPL should be already calling that internally

23:16 <whitequark> if you mean for scripts, then you only need to flush *there* while waiting on user input or somesuch

23:16 <d1b2> <Attie> it is, i was referring to the concept of handing over to a file instead of using the cli as it stands

23:17 <d1b2> <Attie> ah, okay

23:17 <d1b2> <Attie> ... but presumably it's important for the user script to hop into an async function fairly quicly, otherwise other things will jam up?

23:18 <whitequark> it really depends on the applet

23:18 <d1b2> <Attie> okay

23:18 <whitequark> most applets we have are request-response where you get natural synchronization points

23:18 <d1b2> <Attie> i thought i was nearly there with a PR, but i'm not sure it holds up well enough at the moment

23:19 <whitequark> there are a few issues, for example the whole REPL stuff really ought to parse toplevel code (or REPL stanzas) in async mode

23:19 <whitequark> but that requires uh, python 3.8? 3.9?

23:19 <whitequark> something very recent

23:24 <d1b2> <Attie> ok

23:24 <d1b2> <Attie> i'll put that one down for now, even though it would be very nice to have

23:27 <whitequark> okay, it's 3.8

23:27 <whitequark> https://docs.python.org/3/library/functions.html?highlight=compile#compile

23:27 <whitequark> New in version 3.8: ast.PyCF_ALLOW_TOP_LEVEL_AWAIT can now be passed in flags to enable support for top-level await, async for, and async with.

23:29 <d1b2> <Attie> is 3.7 support a hard requirement still?

23:30 <whitequark> no. 3.9 got released, so we can (and should) bump our minimum python version to 3.8

23:31 <whitequark> the policy is to support at least two latest python releases

23:31 <d1b2> <Attie> ok, i might keep playing with it for a bit, even if it's not merged / useful for a little while

23:36 <whitequark> i think we can merge it if/when you implement it