<electronic_eel>
i think i'll go to bed soon, i'm quite tired today
<d1b2>
<Attie> ok
<d1b2>
<esden> Yeah, so as for documentation it is in my opinion very important. We had one dedicated new user in @nanographs and they had a bunch of issues getting glasgow software stack installed. It would be good to get my guide I put on gist and integrate it into the actual docs.
<d1b2>
<Attie> i did one ages ago too on my personal site
<d1b2>
<esden> This is linux specific, but we need a similar thing for Mac and Windows
<d1b2>
<Attie> I've been talking with wq about a docker image to A) allow archiving off versions, and B) accelerate a "get it and go" process
<d1b2>
<esden> On mac things are even worse as the default python version is too now.
<d1b2>
<esden> *new
<d1b2>
<Attie> anyone else have feelings on docker (I'm very in favour, wq less so, but can see the utility IIRC)
<d1b2>
<Attie> re mac: oof
<d1b2>
<Attie> the big "functional gap" i can currently see is for out-of-tree applets...
<d1b2>
<esden> I am fine with docker. But I had great experience using github actions and Sphynx
<electronic_eel>
i'm not really into docker, but i see the utility for it. if someone has a totally borked python install and no venv helps, a containter might be a good solution
<d1b2>
<esden> I have full config for that, and it is much closer to what would be natural for Glasgow that is very python centric.
<d1b2>
<Attie> again, that'll be important when we get a spike in users, as currently it's all in-tree, and we may get lots of forks with certain featuresets
<d1b2>
<Attie> [oot applets]
<d1b2>
<esden> with sphynx we can have an integration between hand written docs and autogenerated ones from the sourcecode.
<d1b2>
<esden> so I think that would be a better choice
<d1b2>
<Attie> but yes, GH actions for generating docs would be the way forward
<d1b2>
<esden> oh duh... my brain is too tired... I thought you were talking about documentation 🤦
<electronic_eel>
i was thinking glasgow software too
<d1b2>
<esden> As for docker I am not a fan of it at all
<d1b2>
<esden> especially not for user machines
<d1b2>
<esden> A good venv setup is much better in my opinion
<d1b2>
<Attie> heh, sorry - i should have made it more clear... 1) I'm working on docs, 2) i think docker would be handy for quickly getting started
<d1b2>
<esden> we need usb... getting that done well in docker seems like a nightmare to me
<d1b2>
<Attie> @esden - even if the process for a new user, who only wants the standard applets, becomes "run this" vs "follow this series of steps"
bvernoux has quit [Quit: Leaving]
<d1b2>
<esden> especially in a way that works on all three platforms
<d1b2>
<esden> but I am not experienced enough with docker to judge
<d1b2>
<Attie> ... i'm not at all suggesting that docker is THE ONLY way, but rather A way to get things running
<d1b2>
<esden> @Attie if you say so. I only used docker to install web services. 🙂
<d1b2>
<Attie> heh, fair enough
<d1b2>
<esden> we have to be very careful how we spend our very limited developer resources
<electronic_eel>
i think suggesting venv as primary way to install is a good idea. but i prefer to have an alternative, if the whole python install is broken or similar.
<d1b2>
<esden> maintaining multiple ways to run things might or might not be a burn of that sparse resource
<d1b2>
<Attie> yeah - docker is a "reduce the support load" type approach... it'll fundamentally be "the linux way" wrapped up into a box
<d1b2>
<esden> ok, that makes sense
<d1b2>
<Attie> so, if I may summarise:
<d1b2>
<Attie> 1. Documentation - Attie
<d1b2>
<Attie> 2. Docker image(?) - Attie
<d1b2>
<Attie> 3. CS - Esden
<d1b2>
<esden> I am very happy to test the docker image, or any of the installation docs
<electronic_eel>
but the docker container won't work out of the box on windows, because usb, right?
<d1b2>
<Attie> re docker on Windows, I don't know, but I'll investigate...
<d1b2>
<Attie> I thought it was like Mac, where it's basically a Linux VM behind the curtain
<d1b2>
<esden> @Attie CS stands for...?
<d1b2>
<Attie> or, or WSL2 by the looks of it
<d1b2>
<Attie> CS: CrowdSupply
<d1b2>
<esden> ahh right 😄
<d1b2>
<Attie> 🙃
<electronic_eel>
yeah, i think they are running it on wsl i think. and wsl had issues with native usb last time i looked
<d1b2>
<Attie> good to know, thanks
<d1b2>
<esden> I am happy to provide my Sphynx config for the docs generation @Attie it does require a bit of poking to get up and running.
<d1b2>
<Attie> thanks - let's talk separately for that as/when?
<d1b2>
<esden> @electronic_eel I heard WSL2 has a much better time with USB... but again that needs testing.
<d1b2>
<esden> and WSL2 is only on W11 afaik?
<d1b2>
<Attie> are there any other items we should discuss, beyond 4?
<electronic_eel>
if someone just wants to verify if their glasgow hw is ok, running a live linux and starting the container within it might be a way for windows users
<d1b2>
<esden> There is a lot of installation testing needed for all the platforms anyways. We need to collect data about the current state of things.
<d1b2>
<esden> I would like to get some help getting the curret glasgow selftest applets back up and running on the RevC3 hardware.
<electronic_eel>
oh, yeah, the selftest is an issue
<d1b2>
<Attie> ok, 5. self test on revC3
<d1b2>
<Attie> who has access at the moment?
<d1b2>
<Attie> (to hardware)
<d1b2>
<esden> I think I sent one to electronic_eel a while back?
<d1b2>
<esden> I definitely have them here.
<d1b2>
<esden> dragonmux has one
<d1b2>
<Attie> ok - electronic_eel, are you able to support with that?
<electronic_eel>
yeah, i have a revC3. i bodged the leds, but otherwise it is ok
<d1b2>
<esden> Yeah if it is just the leds that will not interfere with the tests getting back up and running
<d1b2>
<esden> I did some hacking on the tests a bit ago. But it is not finished and not merge worthy. But I am happy to share and explain what I have.
<d1b2>
<esden> Also I might be able to get one or maybe two more boards that are not reserved for CS backers that I could send.
<electronic_eel>
the issue with the self test is the same thing that plagued revC2, that it doesn't activate pullups/pulldowns, but expects defined voltage levels as inputs, correct?
<electronic_eel>
or is there an additional issue with selftest in revC3?
<d1b2>
<esden> I think I got that enabled in my experiments.
<d1b2>
<esden> the internal FPGA pullups.
<d1b2>
<esden> but then the results were still questionable
<electronic_eel>
i planned doing something about selftest for some time, but didn't get around doing it yet
<d1b2>
<Attie> perfect - i just used an off-the-shelf ribbon
<d1b2>
<Attie> electronic_eel - ok, thanks
<d1b2>
<esden> @Attie I will see what I can do so that you do have the up to date hardware. Even if you don't directly help with that specific topic it is important that you have it I think.
<electronic_eel>
also i won't be able to do it next week, as i'll be travelling and have to do some preparations first...
<d1b2>
<Attie> appreciated, thanks
<d1b2>
<Attie> ee: no worries
<d1b2>
<esden> @electronic_eel no worries 🙂 I hope your travelling goes well. 🙂
<d1b2>
<Attie> so, I think last call for talking points, before we call a close?
<d1b2>
<esden> sure sounds good
<d1b2>
<esden> I mean I don't think I have anything else.
<d1b2>
<esden> For now 😄
<d1b2>
<Attie> I don't know what usually happens for Aramanth meetings... any minutes, or quick notes?
<d1b2>
<Attie> hah
<electronic_eel>
irc logs1
<d1b2>
<Attie> I'm tempted to put something in Github, just to formalise the result
<d1b2>
<esden> @Attie can you just make a summary list as above with 4 added?