chuckmcm[m] has quit [Quit: Idle timeout reached: 172800s]
jscarsbrook[m] has quit [Quit: Idle timeout reached: 172800s]
goro has quit [Ping timeout: 255 seconds]
<supersat[m]>
tl;dr: install pipx with pip, not brew
buta has joined #glasgow
lxdr has quit [Remote host closed the connection]
lxdr has joined #glasgow
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Quit: Cya.]
ewenmcneill[m] has joined #glasgow
<ewenmcneill[m]>
Noting in passing, on older pipx (eg, the one bundled in Ubuntu 20.04 LTS), the install command needs to be `install -e --spec 'glasgow/software[builtin-toolchain]' glasgow` (with "where to find install instructions" and "package name" separate), or it will get to the end, fail to find a package "glasgow/software[builtin-toolchain]" (literally), and remove the venv again.
<whitequark[cis]>
ow
<whitequark[cis]>
didn't that ship python 3.8?
<ewenmcneill[m]>
With that workaround, plus one Python 3.8 -> 3.9 porting step for the Ubuntu 20.04 LTS packaged pipx (json.loads() no longer supports "encoding" in 3.9+), I've got the glasgow software to *install* using the Ubuntu 20.04 LTS / and python-3.9 package.
<ewenmcneill[m]>
It turns out that Ubuntu 20.04 LTS does ship python3.8 as it's "python3", but it also packages python-3.9 as an installable package.... so I've been experimenting to see if I can get the python3.9 working.
<ewenmcneill[m]>
Currently it's crashing with a TypeError somewhere in packaging/utils.py for reasons that are not obvious (ie, a library, not glasgow software).
<ewenmcneill[m]>
If I run "glasgow --version", that is.
<ewenmcneill[m]>
Ah, I see, it's crashing under _requirements_for_optional_dependencies() (under the marker.evaluate) which IIRC was the reason Python 3.8 wasn't supported....
<ewenmcneill[m]>
TypeError: expected string or bytes-like object
<ewenmcneill[m]>
Looks like the packaging markers here in Python 3.9.5 don't like regular expressions....
<ewenmcneill[m]>
With that Glasgow optional dependencies check stubbed out, and an additional package injected (`pipx inject glasgow aiohttp`) then I can get `glasgow --version` to return useful output on Python 3.9.5 on Ubuntu 20.04 LTS ("Glasgow version 0.1.dev1874+gf1e9185 (Python 3.9.5)")
<ewenmcneill[m]>
(Which is as much as I can test, as my earlybird Glasgow won't be here until at least Monday; it's in country now though.)
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
<ewenmcneill[m]>
With some more debugging it appears that the audio-yamaha-opx plugin is triggering the TypeError in the requirements marker, due to ending up as a re.Match(), but I still don't understand why.
<ewenmcneill[m]>
Okay, re.Match() seems to be the result of a regular expression match that ought to have been converted to a string. Detecting that has happened (in dependency) and replacing that with dependency.group(0)works around the problem.
<ewenmcneill[m]>
No idea if that's Python 3.9 specific, or Python 3.9 on Ubuntu 20.04 LTS specific. But I've added the lines of diff as a comment to the gist above in case someone else needs it.
tuxfool[m] has joined #glasgow
<tuxfool[m]>
I would say it is python 3.9 specific, because I did have the same issue in windows
<tuxfool[m]>
I opened a bug report on it
<ewenmcneill[m]>
Oh, interesting. I'll see if I can find that bug report and add some of the above notes to it.
<ewenmcneill[m]>
TL;DR of those comments is that based on the code I found in core python `importlib.metadata` I don't see an obvious reason why this isn't affecting Python 3.10 too (I haven't checked 3.11)
brolin has joined #glasgow
brolin has quit [Ping timeout: 240 seconds]
hei5enbrg[m] has quit [Quit: Idle timeout reached: 172800s]
<gruetzkopf>
the -C1 is one of Atties batch and has seen _lots_ of use
<whitequark[cis]>
niiiiice
<whitequark[cis]>
what kinda use?
<gruetzkopf>
messing with nordic and chipcon/ti parts, programming MachXO2 and Cyclone10
<gruetzkopf>
half-working capture of a custom audio bus
<gruetzkopf>
and playing codec on a PCM64 backplane
<whitequark[cis]>
niiiiice
<whitequark[cis]>
for chipcon i'm going to clean up the years old branches and fix them up, i have far more availability now for that (though still not quite enough)
<ewenmcneill[m]>
TL;DR for above notification: TypeError (due to re.Match being returned) was fixed in Python 3.9 by a backport around March 2022, and I *think* Python 3.9.12 (also March 2022) is the first fixed release. It's a one line change in importlib/metadata.py, to prefer re.findall() over re.finditer().
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<ewenmcneill[m]>
AFAICT also broken in Python 3.10.0, 3.10.1, and 3.10.2; same backport fix in 3.10.3.
hardkrash[m] has quit [Quit: Idle timeout reached: 172800s]
esden[cis] has joined #glasgow
<esden[cis]>
Attie: that is fine. In case I miss the meeting for some reason. I don't have much as for CS updates. People are receiving their "Early Bird" hardware. As well as enclosures if they ordered them separately. As far as I can tell people are happy about what they are receiving.
<whitequark[cis]>
I'm here fwiw
<whitequark[cis]>
happy for Attie to start
<Attie[m]>
sorry, I'm more delayed now.....
<Attie[m]>
be with you soon
<Attie[m]>
hi! let's go... thanks for waiting
<esden[cis]>
👏
<Attie[m]>
so, esden would you like to finish / fill in your CS update, or is that all you'd like to say?
<Attie[m]>
i think people are very happy with the results
<Attie[m]>
(I certainly am :3)
<esden[cis]>
You are biased you don't count :P
<Attie[m]>
haha
<Attie[m]>
whatever
<Attie[m]>
do you have any visibilty on how many of the early bird orders have been dispatched? (i'd guess ~100% by now?)
<esden[cis]>
;) .... but yes, so far I think people are indeed very happy. Some folks have already had a chance to play with it too. And they like what they are seeing. Some papercuts still, but that was to be expected. And I am sure you will talk about it too.
<Attie[m]>
... and have i seen some people recieving cases but no boards? (are these non-earlybird cases arriving before PCBA stock is ready?)
<esden[cis]>
One thing that became clear though, is that those that ordered from Russia are a bit screwed. :( ... due to the Mouser rules, their order is just on hold and cant be delivered or cancelled. Which is very annoying.
<Attie[m]>
oh, poo...
<whitequark[cis]>
how many?
<esden[cis]>
So far only one person.
<Attie[m]>
is that sanctions preventing refunds?
<Attie[m]>
(are they completely unable to pick another delivery addres)
<whitequark[cis]>
I think the compassionate thing to do is to change the address to e.g. <some other address here> and then take effort to reship
<Attie[m]>
s/addres/address/
<esden[cis]>
Yes, sanctions prevent shipment of the product, and they don't have a way to refund money either.
<whitequark[cis]>
exactly who makes this effort can vary
<whitequark[cis]>
but I am sure this can be solved
<whitequark[cis]>
at one point I had a conversation with CrowdSupply where they claimed that sanctions prevent them from shipping a product I ordered to a non-RU address
<esden[cis]>
They also can't change the address to anything else. Mouser is being a bit stubborn about it..3
<esden[cis]>
* They also can't change the address to anything else. Mouser is being a bit stubborn about it..
<whitequark[cis]>
and I had to pull out the big guns, talking to their compliance department
<whitequark[cis]>
after I told them to go and cite the specific legal or regulatory rule preventing them from shipping already paid for orders to an address within EU they relented and did it
<whitequark[cis]>
because there fucking isn't one
<whitequark[cis]>
I may also have complained to the campaign founders <_<
<Attie[m]>
@esden - are you in touch with that person
<esden[cis]>
Catherine: ok good to know that you were able to change things. We might need to talk about this later.
<Attie[m]>
Catherine: would you be willing to support htem?
<Attie[m]>
s/htem/them/
<Attie[m]>
* esden: - are you in touch with that person
<esden[cis]>
Attie: I got one email from a person regarding this issue.
<Attie[m]>
ok
<whitequark[cis]>
Attie: yep sure
<whitequark[cis]>
fwiw shipping works as long as you're doing it as a private person
<Attie[m]>
thanks, perhaps you two can link things up
<whitequark[cis]>
anyone can do it, express mail works just fine
<whitequark[cis]>
but yeah I can
<esden[cis]>
Catherine: ok I will talk to you later about it if we can get that resolved.
<Attie[m]>
any other negative feedback from the CS side?
<Attie[m]>
i see lots of issues / PRs being raised, but we'll discuss that in a bit
<esden[cis]>
No i think that is the only thing that comes to mind.
<Attie[m]>
great - well done again! best of luck with the next squillion units
ar-jan has quit [Ping timeout: 260 seconds]
<esden[cis]>
haha... yeah thanks 😭🫠
<Attie[m]>
on to docs then...
<Attie[m]>
we had a really good session last week, and now have some mega shiny documentation
<Attie[m]>
thank you Catherine for efforts in getting sphinx and CI behaving, and to others for contributions
<Attie[m]>
i'm planning to work on REPL & script mode docs today (probably based around a basic I2C / SPI part)
<esden[cis]>
(I have seen at least one person say "just received it, the docs are awesome" as if we had them forever ^.^)
<Attie[m]>
hehe 🤐
<Attie[m]>
does anyone have areas that they'd like to progress / request progress on?
<Attie[m]>
current "todo" items are: Assembling a device, REPL & script, Dev Process
<whitequark[cis]>
I want to add a "Design principles" page
<whitequark[cis]>
before starting to fill out dev process really
<Attie[m]>
sure, sounds sensible
<whitequark[cis]>
I'll also document firmware. but I think the design principles are very important
<whitequark[cis]>
because it sets the foundation for the entire project
<Attie[m]>
yep
<esden[cis]>
Does design principles include "overarching design goals"? Does that need expanding? Like the fact that you mentioned automatic pin direction detection is a "design goal" in the context of UART.
<esden[cis]>
This might help people decide what worthwhile design goals for a good applet are.
<whitequark[cis]>
esden: I rather want to mention things "we make a tool that acts as a predictable, reliable extension of the operator, which is as robust as possible to both mistakes and external errors; being powerful is not a goal per se, but that foundation allows for some extremely powerful approaches as a result"
<whitequark[cis]>
to contrast to tools that try to be the kitchen sink and everything, or to tools that just do the job good enough and then no one touches it
<whitequark[cis]>
both of which have their place; it's just not this tool
<whitequark[cis]>
the defaults must be as predictable and robust as we can make them technically, and we shouldn't have options that have subtly confusing (data corrupting especially) or dangerous results at all, or at least without a very clear marking of what they are
<whitequark[cis]>
the tool is quite literally a piece of you and it must act the way.
<whitequark[cis]>
I'm confident and happy that the hardware achieves this essentially perfectly
<whitequark[cis]>
the software necessarily will, too, where it doesn't already
<esden[cis]>
Ok thanks for clarifying. Sounds good.
<whitequark[cis]>
I was also reading through our install instructions and I realized that the degree of polish we have for first use is on the level of not just commercial products, but high-end commercial products, think Saleae
<whitequark[cis]>
which is worth celebrating
<Attie[m]>
🥳
<whitequark[cis]>
ran them all on a Windows desktop my headmate gave me a domain account on, works perfectly
<whitequark[cis]>
pretty cool
<Attie[m]>
brilliant, and we've had some other contributions too (e.g: Fedora & FreeBSD)
<Attie[m]>
that's one of the good things about an open project like this
<whitequark[cis]>
I've actually set up Fedora in docker >_>
<Attie[m]>
ah, was that you?... just FreeBSD then, but still
<whitequark[cis]>
yep
<Attie[m]>
last request for docs was the internal analyzer
<Attie[m]>
i think we'll leave that on the request pile for now? (focus on items discussed above)
<whitequark[cis]>
yeah
<Attie[m]>
ok
<whitequark[cis]>
most of the gateware needs at least some degree of rework
<whitequark[cis]>
I don't know how much I want to commit to documenting the current (somewhat broken) state
<Attie[m]>
sure
<whitequark[cis]>
I will also be developing an ILA relatively soon for Amaranth integration'
<Attie[m]>
let's move on to #400 then
<whitequark[cis]>
then we won't need a Glasgow-specific one
<Attie[m]>
esden: would you mind commenting on the alu case publicly? ... will we see a STEP file or similar released?
<Attie[m]>
i know that's come up as a question recently
<esden[cis]>
<whitequark[cis]> "which is worth celebrating" <- 🥳
<Attie[m]>
(if no, then still linking to the product page as an option is sensible IMO)
<Attie[m]>
... looks like those parts of the tree could use some attention too
<esden[cis]>
Attie[m]: *sigh* so the current case is not very useful for 3d printing at all
<esden[cis]>
it is only if you go and do a volume manufacturing in aluminium
<esden[cis]>
plus the microscopic light pipes
<esden[cis]>
it is quite specific to our proces and the manufacturer we have
<esden[cis]>
I think it is much more useful to have a dedicated 3d printable case
<Attie[m]>
re 3D printing, and having a separate design - I completely agree
<esden[cis]>
I do want to work on creating that and contributing to the project.
<esden[cis]>
Unless someone beats me to it.
<Attie[m]>
re ALU case, is it something you plan to keep producing for sale, if people keep buying, etc?... so we could link the store page as a "get yours here"
<esden[cis]>
Yes, we will keep making the aluminium cases as long as people want them.
<esden[cis]>
same with Glasgows .. when we finish fulfilling the campaign
<Attie[m]>
ok, all sounds reasonable to me
<Attie[m]>
does anyone know if the current 3D printable case is compatible with revC3?
<Attie[m]>
(same for lasercut too actually)
<esden[cis]>
This would be good to validate and update if needed.
<Attie[m]>
... i'm more than happy for an "i don't know", and we can take it as an action
<Attie[m]>
perhaps I'll try to get on that
<esden[cis]>
It would also be quite valuable if they were designed with some software that does not require rental payments ;)
<Attie[m]>
hah, okay, maybe not me then
<esden[cis]>
the alu case is done in F360 which is 😬 for opening up.
<Attie[m]>
yeah... I was hoping / planning to share a STEP file, but that's not exactly "source", and I know people prefer that
<esden[cis]>
that said, something is better than nothing :D
<Attie[m]>
from past experience i'm allergic to FreeCAD
<esden[cis]>
we can have a never ending discussion regarding the state of open source MCAD... :D
<Attie[m]>
yeah
<Attie[m]>
ok, let's not link in docs until we A) know they fit revC3... or B) have a revised case that does
<esden[cis]>
That reminds me, I have a todo assigned to me by Catherine -> revC3 bom export. I will try to get that done before the weekend ends.
<Attie[m]>
this looks like a big one, and i see we've also deprecated py3.8 support this week
<whitequark[cis]>
Attie: yeah i don't like freecad too much either :/
<whitequark[cis]>
hold on, i want to continue discussion a bit re: case
<Attie[m]>
oh, sure
<whitequark[cis]>
esden: are you opposed to sharing it? or just consider it not very useful?
<whitequark[cis]>
are there legal issues? are you concerned it will get (poorly) cloned?
<Attie[m]>
beep esden
<Attie[m]>
shall we come back if he reappears?
<Attie[m]>
(i'm still here, turned #glasgow off in the 1b2 discord, dinging myself got boring)
<whitequark[cis]>
yep sure
<whitequark[cis]>
let's go ahead then
<Attie[m]>
ok
<Attie[m]>
#422?
<whitequark[cis]>
#422 is insanely confusing
<whitequark[cis]>
we do need to address it but I have also been struggling to reproduce and I now see why
<whitequark[cis]>
newer patch releases that we use on CI don't trip the bug
<whitequark[cis]>
we ... might want to add the 3.9 variant in Ubuntu 20.04 into our CI rotation
<ewenmcneill[m]>
422 affects older 3.9 (pre March 2022) and older 3.10 (pre March 2022).
<Attie[m]>
makes sense
<whitequark[cis]>
ewenmcneill: which patch versions exactly, can you say?
<ewenmcneill[m]>
FYI, Ubuntu 20.04 LTS Python 3.9 turns out to be in Universe (hence stuck in time at 3.9.5).
<ewenmcneill[m]>
3.9.12 is fixed AFAICT; 3.10.3 is fixed AFAICT. GitHub ticket has links to the commits.
<ewenmcneill[m]>
(The alternative if you want to support old 3.9 / 3.10 is the hack I included in the 422 ticket yesterday.)
<whitequark[cis]>
can you tell me the non-fixed versions so they can be added to CI rotation?
<Attie[m]>
3.9.5 is broken
<whitequark[cis]>
it seems worth it; several people appear to be hitting issues
<ewenmcneill[m]>
3.9.5 is definitely broken. I think 3.9.0-3.9.11 and 3.10.0-3.10.2 are broken.
<Attie[m]>
have you tested 3.9.11, 3.9.12, 3.10.2 and 3.10.3?
<ewenmcneill[m]>
No.
<ewenmcneill[m]>
I only tested 3.9.5 as that was what I could trivally install.
<Attie[m]>
ok, we should add a comment to the ticket to summarise what you've just said (known bad, presumed bad, fixed)
<whitequark[cis]>
currently running docker run --rm -it ubuntu:focal
<Attie[m]>
don't forget python:3.9.11 and friends are docker images
<ewenmcneill[m]>
FYI, there's a Python PPA "deadsnakes" which has backports of later Python (eg, 3.9.18 IIRC) to older Ubuntu, which I found this morning. It may be worth directing Linux users at that if they're on older Linuxes.
<esden[cis]>
On some level I feel bit of ownership over the case, it is a nice differentiating factor of the hardware we make, vs what others might/might not make. I did pay Timon for the time he spent designing it. Plus it is really only useful to those that will manufacture the cases in actual quantity.
<esden[cis]>
so yes, poor quality clones are a factor here too
<whitequark[cis]>
got it. in that case we need to make a note that the case sold by 1b2 is not open hardware and move on
<esden[cis]>
I still, want to spend the time and effort to make an actually useful 3d printable case to contribute to the project instead.
<whitequark[cis]>
it is very important for me to be clear on what is and what isn't OSHW, but it's not critical that everything is
<esden[cis]>
Catherine: understood! Thank you.
<Attie[m]>
👍 - as above, i'd still be keen to link the store page in the "cases" section, and declare it's not OSHW
<esden[cis]>
there will be a separate product page on the 1b2 stores eventually for the cases too.
<Attie[m]>
yep
<esden[cis]>
and cables
<Attie[m]>
Catherine: I've run through the py3.9 and py3.10 versions, and found the breakpoint... see comment linked above
<Attie[m]>
is there anything else to discuss on #422 right now?
<esden[cis]>
so everyone will be able to get the wire harnesses for their glasgows. We will not be tying them to our hardware. I despise products where you can't get replacement cables for :D
<Attie[m]>
100%!
<whitequark[cis]>
yes agree
<whitequark[cis]>
I'm fine with 422 as it is, will take a look soon (prio: hi)
<Attie[m]>
ok
<Attie[m]>
that's all from me i think
<Attie[m]>
anyone else?
<Attie[m]>
otherwise i'll close the meeting and publish minutes
<Attie[m]>
ok, meeting closed - thanks all for attending
<esden[cis]>
thanks Attie for coordinating as per usual. :)
<whitequark[cis]>
thanks for conducting!
<esden[cis]>
Thanks for the good meeting :D
<_whitenotifier-f>
[glasgow] attie assigned issue #422: running Glasgow exectutable produces "TypeError: expected string or bytes-like object" in packaging\utils.py - https://github.com/GlasgowEmbedded/glasgow/issues/422
<whitequark[cis]>
current queue: #422 then #400
<Attie[m]>
np!
<whitequark[cis]>
I think I'm going to enable "projects" so we can all have queues that are publicly visible
<Attie[m]>
thanks! i was just looking how we might label tasks for priority