 Hello and welcome to the Circuit Python Weekly for March 1st, 2021. This is the time of the week where we get together to talk all things Circuit Python. So I'm Scott and I work for Adafruit on Circuit Python. Circuit Python is a version of microcontrollers, a version of Python designed to run on tiny computers called microcontrollers. Many of us who work on Circuit Python are sponsored by Adafruit, so if you want to support them and Circuit Python by extension, consider purchasing hardware from Adafruit.com. This meeting happens every week on the Adafruit Discord server. You can join any time of going to the URL adafru.it-discord. We hold the meeting in the Circuit Python Text Channel and the Circuit Python Voice Channel. It usually happens at 11 a.m. Pacific, 2 p.m. Eastern, except when it coincides with the U.S. Holiday. If the meeting time has changed, we'll notify you via Discord. If you wish to be notified about the changes to the meeting, you can ask to be added to the Circuit Python Easter's role as well. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We record audio from the Voice Channel and the video of the Text Channel. If you'd rather not have your voice recorded, you are still welcome to participate. Just add notes to the note stock and I'll read those off. The video of this meeting will be posted to YouTube and the audio is released as a podcast. If you find this podcast is not available in your favorite podcast service, just know. There's a note stock to accompany the meeting and the recording. If you wish to participate but can't make to the meeting, you can always leave notes in there and I'll read them off. The document includes time stamps to go along with the video slash audio so that you can skip into the different bits there. Meeting tends to run 60 to 90 minutes depending on how many folks we have and how many topics we have to cover. A link to the note stock is posted in the Circuit Python Channel every week for the next week's version. So it should be available for a full week. Check the pin messages at the top. So this meeting is held in five parts. First is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of the Python on microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look up the project by numbers separate from kind of what we're all up to and how we feel about it. The third part is hard reports. It's an opportunity to highlight the good things folks are doing, taking time to recognize the awesome folks in our community. Fourth, and that hard reports is done is around Robin, which we've talked about before the meeting has started. This status updates is another round Robin. It's an opportunity to think about what we've been up to, taking a couple minutes to talk about what we've been working on and what we plan on working on in the coming week. Lastly, in the weeds, the last part is in the weeds where we have an opportunity for any longer form discussions. To add topics there, please add those to the note stock ahead of time. That's how the meeting will go. First up, we will... I'll talk about community news. First up on community news, we reached 70 single board computers supported by Blinka, which provides a base layer for Circuit Python libraries on Linux single board computers. It is a PIP installable Python library that runs in normal desktop Python. One can port their microcontroller to an SBC or vice versa. Blinka reached a milestone this week, and now supports 70 different single board computers. So shout out to Maker Melissa for leading that effort. Next up, if you didn't know, we have a Circuit Python subreddit. The Circuit Python subreddit on reddit.com crossed the 2,000 member mark. Thank you to all our Reddit readers for choosing to get your Python fix on our subreddit. And also a huge thank you to Ann B, who posts all the content there and really runs the subreddit. So thank you to Ann. The Python developer surveys for 2020, the results have been released. So the Python software foundation are excited to share the results of the fourth official Python developer survey conducted with the help of JetBrains. More than 28,000 Python users from almost 200 countries took part in the survey this past October. With the help of the data collected, they are able to present the summarized results, identify the latest trends, and create a Python developer profile links there to the Python software foundation's announcement, along with the JetBrains one as well. And lastly, Happy Birthday to Raspberry Pi, which turned nine. The original Raspberry Pi launched on February 29th, 2012, making this low cost single board computer nine years old. It really doesn't seem that long ago. With 38 million units sold, the Raspberry Pi power is a huge community of makers, students, and businesses. What started as a small project meant to increase applications for Cambridge University's computer science program has become a global movement. And there's a link to a Tom's Hardware article about it. And as always, this is a preview of the CircuitPython Weekly Newsletter, which is a CircuitPython community run newsletter emailed every Tuesday morning. The archives are available at AdafruitDaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware related news from around the web, including CircuitPython, Python, and MicroPython developments. It is developed in the open. To contribute your own news or project, edit next week's draft on GitHub. The repository is GitHub.com slash Adafruit slash CircuitPython-weekly-newsletter. There's a drafts folder in there, and you'll see the latest draft in there. You can submit a pull request with changes, or you can tag a tweet with hashtag CircuitPython on Twitter or email cpnews at Adafruit.com. And that includes projects and stuff that you've been working on, so we want to hear about all of it. So thank you to Ann and Katnie for putting the newsletter together. And next up, we're on a roll. State of CircuitPython Libraries in Blinka. This is kind of an objective overview of the health of these, like, broad projects and the sub-projects themselves. It's meant to kind of balance our, how do we feel about everything's going with actually some numbers. So first up, I'll talk about numbers overall. So overall, we had 27 pull requests merged from 19 different authors, which were, you know, we're hitting right around that 20 mark every week, which is amazing. Some new names in here that I don't really recognize. Biffo Bear is one of them. Adam Candy is another. I don't know how to pronounce that. And R Rotman are all new names. So thank you to our new authors. We had nine reviewers. Thank you to all nine reviewers. As always, we're looking for more reviewers because they help us scale about, scale out the number of authors that we have. Issues-wise, overall, we had 23 closed issues by 14 people and 25 opened by 22 people. So again, a lot of people are involved. We're about net zero in terms of open and closed issues. So overall, things are going pretty well. For the core, which is like the CPython core of CircuitPython that loads on the microcontrollers, we had four pull requests merged from four different authors and two reviewers. So thank you to everyone there. We had 26 open pull requests, which is kind of a lot. But while let's take a look at those, generally we do tend to get a lot of them done early on in the week. Issues-wise, we had five closed issues by five people and seven opened by six people. So we're net up two issues for a total of 410 open issues. We have seven active milestones. This is the way that we keep track of, like, which issues we've triaged and kind of what the priority is for them. We have five issues not assigned to milestones. So we'll have to take a look at those. We've got 11 open issues for 6.2. And we have 42 open issues for 6XX. And I think generally for 6.0, we're going to have to take a glance through all of those issues to reprioritize them. I think generally we want fewer in those categories. So overall, I think 6.2 is rapidly approaching. There's a lot of really good stuff for the RB2040 and some reliability stuff for the S2 that will go in that. And I think it's likely to be the last kind of sub release of 6, unless otherwise we'll probably move on to developing 7 at that point. And there's seven open issues that are related to being able to change things up for 7.0. So I kind of expect we'll do a 6.0 stable and then move on to 7. So thank you to Jeff for trying to capture my rambling in the notes. And with that, let's hand it over to Katni for a library update. Thanks, Scott. So this applies to all of the Adafruit Circuit Python libraries and a couple of extra things such as our cookie cutter and our community bundle. There were over all of those repos, 20 pull requests merged from 14 different authors and eight different reviewers. Thank you to all our authors and all of our reviewers. The oldest PR that we merged was 41 days old. There are four of them that are over two weeks, which is excellent. A lot of them that are new. Both of those statistics are important because it means we're getting through some of the older PRs, but it also means that we're keeping up with what we have coming in. We had, that leaves us with 55 open pull requests, which is an increased, but that's fine. We had 18 closed issues by 10 people and 14 opened by 12 people, leaving us with 286 open issues. Again, that's across all of those repos. And we have seven good first issues. If you're interested in contributing to Circuit Python on the Python side, go to circuitpython.org slash contributing. You will find all of this information and more, including all of the open PRs, all of the open issues, and a list of library infrastructure issues. And you can search the issues by label. If you're new to all of this and you'd like something that is simple to start with, try good first issue. If you're looking for something a little more complicated, try bug or enhancement. You can also just do a find in the page and if you have a sensor and you want to see whether there are any bugs available for that, you can do that as well. There is a guide on contributing to Circuit Python using Git and GitHub. So you're not alone there and we are always available to answer questions. We want you to be able to contribute in a way that works for you. So if you're new to all of it, don't let that intimidate you. We are here to help. And we have a fairly lengthy list, not relatively speaking, but a sizable list of updated libraries and no new libraries this week. In terms of all of the libraries, we had a situation where Pilant was updated and a previously existing check that wasn't working started working. And the way that we do examples in our libraries means that there are many libraries with examples that have very similar code because with Circuit Python, often the list of imports and the hardware setup is the same, even though the rest of the example may do something entirely different. And so we wanted to make sure that this check, which checks for duplicate code, was still running on the libraries because it's an important check, but we wanted to make sure it stopped running on the examples because of the way that the examples are written. It's appropriate that they have duplicate code. So all of that said, we now have Pilant running in a different way, and it works with the way that we have our examples and with that duplicate code check. But we are waiting on the patch to be applied to all of the libraries. So for those of you who are submitting PRs and finding that they're failing on code that you didn't touch, I greatly appreciate your patience. Please let us know if you're comfortable with it. I can actually walk you through making the changes manually or help you with it or do it myself to get that library ready for your PR. So I just want to let everybody know if you have outstanding PRs and you're running into that, we do have a solution on the way that we can do sooner rather than later if necessary. But other than that, everything else is pretty solid. We've had a lot of development on all the libraries and it's really been great to see. Awesome. Thank you so much, Katni. All right, next up we have a Blinka update from maker Melissa. Hello. The thing moved on me here. Yep, we're adding too much stuff. Okay, so for Blinka, we're going to play a single... Hey, Melissa, your audio is messed up. Oh, is it? Yeah, it's chopping in and out. Okay. Peter, could you read notes off? I'll read them. I'll read them off. Thank you. All right, so for Blinka, we had three poll requests merged from two different authors. The person I definitely cannot pronounce, A-N-H-M-I-U-H-V and maker Melissa, so thank you to our authors. Two reviewers as well, so thank you to the reviewers. There are four open poll requests, and a couple very... been open for a while, but two others that are a lot less. Issues-wise, there were zero closed issues by zero people, four open by four people. For a total of 56 open issues, if you want to check those out, you can go to gab.com. slash Adafruit. slash Adafruit. Blinka. slash issues. Pi PI downloads in the last week is 1,452, along with now 70 supported boards. So that's the Blinka update. Next up, we have Hug Reports. Hug Reports is a chance for us to say thank you to folks for the work that they've been doing. It's done as a round robin. I'll start and go through the list. If you do want to participate in the round robin, please make sure that you have at least your user name in the notes, if not some notes as well. Say that you're lurking or unable to attend along with your name if you need me to read them off, so that I do that and not just wait for you. Okay. And with that, first, Hug Reports to MicroDev for taking on the 1.14 merge. You are in NVM for the RP2040. MicroDev has been doing a lot of awesome work, and the 1.14 merge is a huge task. So I'm excited to see that. Thank you to FOMI Guy for the streams every week. If folks don't realize it, FOMI Guy has been streaming regularly on Saturdays. I caught some of the stream this week, and it was exciting to watch. Very excited for that. So thank you, FOMI Guy, for doing those streams. Hug Reports to June 2, SAC, for working on the NRF 52 sleep stuff. Hug Reports to OMSI for helping with the Ninja Build thoughts. We talked a bit about it on my stream on Friday, and I noticed that they went and added some notes to the issue for brainstorming there, so that's been super helpful. So thank you to them. Thank you to Ndiko for helping folks on the Discord. I went back and looked at everything, and they were being really helpful, and a new person to the community. I don't want to discount all the awesome other folks, so just thank you everyone for being so awesome. This community has been growing like crazy in the last year in particular. Those of you who joined in the last year, you're welcome, you've been amazing, and then those of you who previously said, well, thank you for helping us grow, and continue to be the awesome community even as we grow. I think it could be really challenging to kind of keep the ethos, so all of you are a part of that, and I really appreciate it. I don't do group hugs that often, so consider that a group hug. Next up, we have notes from TG Techie, who's unable to attend. Hug Reports, Jerry N, for helping debug the LC709203F and NRF 52 840 issues. Hug Reports came at 98 for the continuing streams and the community hug. With that, I'll hand it over to V923Z. Thanks, Scott. So, beyond the group hug, I would like to single out two people. That's probably an oxymoron, but anyway. First, Dan, for bringing up a subtle issue with regards to the Buffett protocol, I removed the function in the microlab C code thinking that it's not really required because there was an explicit version of that, but Dan pointed out that that's actually quite important. So, thanks for that. And I would like to thank Jeff for actually fixing the bug or reintroducing the function and lending me a helping hand with quite a few bug fixes and integration issues. So, thanks a lot, Jeff. Thank you, Zoltan. And also, I should say, one of the reasons to go to 7 is that we can move to the mainline or something of microlab, so we don't have to keep maintaining two versions. It's another reason for us to kind of move into the 7 zone, so to speak. All right. Next up is Dan. Hello. I'd like to thank a new contributor, Junto Sack, who has been working on light and deep sleep for the NRF 52. They have an application for it themselves, but have really jumped in feet first trying to understand a lot of code that's very hard to understand about how sleep works, which is complicated. So, thanks for the PR and thanks for continuing to work on it. It should be done fairly soon. Thanks to Scott for reviewing a fix. I have a fix for the RP2040 digital in-out, but I've revised it like three times because each time I make it, I forget another corner case. And so Scott pointed that out and it's in review again. Thanks to Lucian for discussion on ESP32-S2 I2C problems with or without Wi-Fi, but I understand where he got to in his debugging so far. And then thanks also to Jeff for discussion on Sunday about ideas I had had kind of waking up early in the morning kind of ideas about how we might speed up translation builds and change the way translations are built so that there's less work done. And that's still, it's a long term thing, but thanks for talking to me about it. Okay. Awesome. Thanks, Dan. Next up, we have notes from David Glaude, who says, lurking, sorry for the long list. Don't apologize for the long list of hug reports. Hug reports are awesome. Okay. So first up, hug reports to Katnien Carter for the SCD-30 CO2 sensor guides. Hug report to myself, Tan Newt for the audio stuff on the RP2040 and helping out on Discord. Hug report to Todd Kurt on Twitter, Todd Bot for the rotary encoder on the Qtpie idea. Hug report to Joey, Jose Castillo on Twitter for making me want to have a Castillo F91W. Hug report to Liz Clark, aka BlitzCityDIY for MIDI Learn Guides. Surely one of those will be useful. Hug report to Gwiz for wanting to start an ENUK translation. Hug report to Microdev for you are on the RP2040 and a hug report to KMatch98 for finding an issue, for finding a fix for an issue I raised more than a year ago about the Bitmap Saver library. And next up, we have FomiGuy. Alrighty. Thanks, Scott. This will be a hug's one to Naradok for offering folks a great help on the Discord and the Help With Channel. Hug's to Jose or Jay Podesta 2020 on GitHub for catching an issue with TileGrid, the way that we worked on inverting the XY for the vertical text that Jose was working on last week. Caught an issue with ESP32S2 and then also a shout out related to Dan H, DeShipu, Microdev, and GitHub user RSBone12 all looked into that issue and offered up solutions or testing or other various things. So I appreciate all of those folks. And then lastly, anybody who checked out my streams over the weekend and especially Hugo and anyone else who pointed out a couple areas where I could improve, I had some broken links and descriptions and the volume was a little off. I definitely appreciate folks pointing that stuff out so I can try to get better. And that's all for me this week. Thanks. Awesome. Thank you, filming guy. Next up is Hirofax. Alrighty, thanks this week to Dan for the low power discussion. We had a little trade off of IceGridC versus low power stuff. And I appreciate him filling me in because low power is complex. And on that note, also a thank you to Gene Tzak, who as Dan noted has been taking on the NRF low power and having gotten into that, the work that they've done on that is really pretty great. So very, it's a lot of work. So thanks to them. And then a group hug to the community. Awesome. Thank you. Next up is Hugo. Are you set up with? There you go. Yeah, I different to talk about none different computer. Sorry about that. No worries. So first is thanks to Katnium ask Patrick Dilley for the feedback on the cookie cutter fixes. And next one guy for the discussion on how to handle the progress and the value variations there. And when you phone guy, I was a David and you came out during, for the guys stream about just how we can handle strings and different options for him and tabs in those strings for display item. Awesome. Thank you. Here you go. All right. Next up is Jack Blair. Hello, I just got to find my place in the dock real quick. So I have a bunch today. I want to thank Katnium Hugo Dylan and probably some others for jumping in to deal with the pilot updates that Katnium was talking about earlier. Creola and I had a nice chat about LEDs and more and it was just fun to hang out with her. I wanted to thank the ship for speculating about a mystery board. There's a blog I read and every month a picture of a PCB is posted and people are invited to guess what it is and what it is. To make her Melissa, congratulations on getting that milestone of 70 boards in Blanca. Scott, happy to see you adopting this new way of tracking participants in the meeting. I just hated for that and we're doing it. So that's great. And I want to thank Dan back for the informative chat over the weekend. Dan said, you know, do you have a minute to chat? And I'm pretty sure we were there for at least 90 minutes, but it was a well spent 90 minutes and just nice to hang out with my colleague. Awesome. Next up is Jerry. Hi. Thanks to Microdiv and you, Scott, for all the work and getting the, you are working for the RP2040. Nice to have it. Awesome. Thank you for testing it. All right. Next up is Katnium. All right. So hug reports to Ann for working with me on learning how to take over the newsletter. That's probably going to be a fairly common hug report for the next X amount of time. To Dylan for working on patching the libraries to get the pilot update taken care of. To Hugo for sorting out getting pilot to run as we needed it to on the libraries. A general hug report to everyone who has PRs in that are currently failing due to the latest update. Thank you for your patience while we sorted out the right solution to this issue. And finally a hug to Fome Guy for submitting his stream to the newsletter via PR. Awesome. Thank you, Katnium. All right. Next up is KMAS 98. Thanks, Scott. I think I have to correct a misdirected hug from TG Techie this week, but I'd gladly take it and pass it to Fome Guy for the live streams. So thanks, Fome Guy for that. Scott, thanks to you, Mark Gamblor and Dan for helping add a new module and giving me good examples to follow for doing that. Next to Katnium and Hugo for the pilot work for the similar lines errors, primarily on the example code. And lastly a hug to Riskable. It's a Discord user who shared on the show and tell channel a cool Oreo shaped magnetic rotary input. And he explained how or why he needed two sensors to get the rotation direction. So thanks for that. And it made me hungry all at the same time. Thanks. Awesome. Thanks, Kmatch. All right. Next up is Maker Melissa. Okay. How does my microphone sound now? It sounds good now. Oh, good. So I want to give a high report to the lady there for the crash course on working with Linux device drivers. Everyone who submitted new Blinkaboard's to get us up to 70 to Astronaut for taking the time to help narrow down what was causing the display noise issue on the BrainCraft hat. Do you, Scott, for reading the Blinka notes and a group hug to everyone else? Awesome. Thanks, Melissa. All right. Next up, I have notes from Mark Gampler. He says hug report standard for putting out an obvious fix I need for count IO and adding initializers to the PIO state machine group hug because I'm probably forgetting someone from earlier this week. And micro dev is not in it. So I'll read off micro dev as well. Micro dev says hug report to Jerry N. A. J. S. 256 and Lady Aida for extensive testing of the RP2040 UART. Hug report to Tandu for reviewing and providing constructive feedback on the UART PR. And next up, we have notes from Jose David who says hug report to everybody. Thank everybody for supporting each other. Hug report to Hugo for insightful ideas and willing to do things in the spot, like with the type annotations. And a hug report to Tandu and Fome Guy for the learning experience during the streams. And with that, that's everyone. So thank you all for hug reports. Next up, we have a round robin, but this time it is for status updates. This is a chance for us to talk about what we've been working on, what we plan on working on in the coming week. Again, I will start and we'll go through the list. My notes are already out of date a little bit. So I, for myself, I got audio bus checked in and UART is checked in as well. I had to do just a couple more corner cases on UART. It's tough. In my notes, I say I'm hoping to knock out rotary IO, but I've handed that off to Jeff to do later this week. And then do flash rework. Oh, I did say in the notes flash rework may come sooner and in fact will. Basically, what's happening is that the RP2040 chips are being sent out to folks. And because those boards will have different flash chips on them, we need a better way to manage all of those different flash chips. In fact, over the weekend, Lady8 was working on Feather RP2040s and put a 4 megabyte chip on that didn't work and then decided to switch to 8. So everybody can be thankful that the 4 megabyte didn't work because it looks like kind of the core boards will come with 8 megabytes instead of 4 from 8, which I think is generally better. It might add a little bit of cost, but it's twice the space. So I think it's worth it. Yeah, so I also forgot to say I'm out on Friday. I'm taking a three-day weekend, so I will not be around on Friday. Stream will be on Thursday. And so I'm hoping to make some progress in that time. Okay. Next up, we have notes from TGTechie, who says, last week, ramping up for a small first batch of the TGWatch production, tested a new hot plate, posted a get notification once TGWatch is on sale quiz on Twitter. If you want to follow them on Twitter, they're at TGUnderscoreTechie. Commits a friend to try circuit Python? Good intentioned villain laughter. Please don't actually do that. Integrated optional switching regulator into final rev of TGWatch. Aligned screw holes with the reset button on the watch to remove an entry pointer for water. Next week, test if the LSM6DSO library is compatible with the LSM6DSOX IC. Bring the prototypes up to parity with a revision for TGWatch. Test gasket maker with gray watch body and some internal restructuring to optimize for memory in the TGGUI app, or API. And next up is V923Z. Thanks, Scott. So in the last couple of weeks, I've continued work on microlab, fixed a number of smaller bugs, added a couple of functions, sorted out an Indiana's problem. Someone was trying to fully transform data from an ABC and they got garbage and it turned out that all the bytes were swapped. So I added a function with which you can fix the Indiana's. But what's actually quite... Well, it's all consuming in a sense is a new module that I'm trying to add to microlab, which would allow some sort of lazy loading of huge amounts of data. So to put this in practical context, the first request came from OpenMV. They have these camera modules which produce megabytes of data per frame. And the question was whether you can calculate anything on an image using microlab if you can't possibly fit the data into RAM. And it turned out that it's possible. And in fact, the solution is embarrassingly simple. But in any case, I have to implement it. So with this new module, without breaking NumPy compatibility, you would be able to attach a function pointer to a numerical array. So your array would hold the shape and the strides, but no data whatsoever. Instead, you could have a function pointer which fetches the data when it's needed. And I think there are a couple of applications that could be interesting for CircuitPython. One is the image processing that I have already mentioned. The second is that you could store or offload data to an external storage device, for example, an SPI RAM. And it would enable you to work with much more data than what actually could fit into standard RAM. And a fun application could be... So the data don't even have to reside in conventional RAM. It could even be pixels in a display. So what you could do in principle is attach your function pointer fetch the data from the display, do whatever transformation you want to do on the data, and then push it back to the display. So if you say that, well, this image is too sharp for me, then you could simply pull in the data line by line, run a convolution on it, and push it back to the display. So this is something that could be fun, could be useful, I don't know. I would actually be interested in hearing some suggestions, opinions on this subject. So in the coming weeks, I'm trying to finish the extension module, and once I'm done with that, I would like to roll out version-free. Awesome. I haven't even started thinking about cameras yet, so you're way ahead of the game there. All right, let's go to the top. Thank you for the update. And next step is Dan. I'm scrolling over. Yeah, I was scrolling too. All right. So I spent a lot of time last week. There's a particular sensor, a color sensor, the TCS74 through 25 or 34, whatever the number is, and it works, it doesn't work on the RP2040, and there were several problems. One of them was that the RP2040 hardware doesn't support I2C rights of no data when it's just an address. So that's a problem. But eventually, I fixed a bunch of these bugs. Some of them haven't gone through the PR system yet, but it's still the case that this sensor works with BitBang I.O. on the RP2040 and not with regular bus I.O.I.2C, and I do not understand why, and I'm probably just going to give up on this for now. Somebody else saw a similar problem on a completely different board like six years ago with the same sensor. There's no ernoerata or anything. It's not worth figuring this out further since there's a workaround. But I have a lot of background information now. As we mentioned, I talked to Jeff about speeding up translation builds, and we have some in-the-beats discussion of that also, mainly to try to... Our build times continue to creep up because every time we add a new board or a new translation, it's a product of board times translations, and it gets larger pretty quickly. So it would be nice to figure out how to cut this down. And I wrote up an issue with a proposal that may or may not make sense, but it's sort of the motivation for it remains. I will start working on Beta3 release notes immediately after the meeting, and we can hope to get Beta3 out after we push a few PRs into the release. Or into main. And the other thing I'm going to work on is that I will be like the third or fourth or fifth person at least to start trying to debug what's wrong with I2C on ESP32 if you... It seems to interact with Wi-Fi badly and or it doesn't work when you do a soft reload. And there could be several reasons for these problems and I'm trying to try to narrow it down. Okay. Awesome. Thanks, Dan. Okay, next up I have notes from David. It says, Testing audio on the Pico Plus Pico demo including playing with the RTT-TL Christmas tune. Using SirCup for the first time. Can we have the same thing for firmware upgrade? Testing Rotary encoder on QDPI. Making a MIDI version at ToddBot also made one. Using the Kibo Mini on a Pico using Pico2Zero adapter from Red Robotics. And non-CP, acquired for my son, the software FL Studio a Belgian music program. And acquired a MIDI keyboard my first MIDI thing since my Sound Blaster Pro. Nice. And next up is FoamyGuy. Hello. Alright, status updates this week. Or last week I should say I reviewed PRs in display text for one for fixing the tab characters one for adding a way to do vertical text. And I also tested out an issue that came out of that second one on the mag tag. I started working on importing maps from Tiled the game map editor software to get those maps to be able to import into SirCup Python code. And I got last week also the bulk of the display text learn guide down and out of my head onto the pages, which is good. So this week I'll be going back over that a few more times with some editing passes and touching up all the final details. Also this week I will, if the opportunity is there I was going to say I would help out with the pylon PR. It sounds like maybe we might be another week or so out from that, but I'm definitely willing and interested to learn what's going on there and help out if I can whenever I can. Other stuff this week is a couple final reviews on a few PRs for display widgets, especially after that pylon is taken care of or if we take care of it on those specific libraries that would work too I think. And then lastly, the thing I want to get to you this week as well is look into some more and document an issue that I found with TileGrid and Pallet transparency specifically inside of my Pi game display. It doesn't seem to affect microcontrollers or even Blinka on the right Pi so I must have done something weird inside of my display that's making it draw some stuff kind of strange so I'm going to get looked into that this week. That's all I got, thanks. Awesome, thank you for having me, guy. Next up is Hierophact. Alrighty, so this past week I worked on the SCM32 low power module though I got a little bit interrupted by some personal stuff so I didn't get done, but I did break out the EXTI which is the external interrupt and real time clock modules for the SCM32 so those are good for SCM, those are going to be used in the low power but are also kind of good to go for rotary IO and RTC after low power is done might be easy to do those. I did some low power testing just you know kind of in the silver intermediate early phases and it's a personal thing I sold my first feather wing for circle python so that's kind of fun. This week I'm going to be continuing my low power work and also running some ESP32 modules under some more extensive tests for some upcoming hardware so that's what I have going on and that's it. Nice, and you should link us to your feather wing as well. Oh, good, yeah. For the for my dynamic, the dynamixl motors which are kind of a a fancy brand of robot motor so I'll also be doing some robotics kits for circle python as soon as I finish up some 3D printed parts for them. Awesome, yeah definitely link us. Alright, thank you. Next up is Hugo. Alright, so last week I wrapped up but I did the progress bar changes for vertical but the difficult code issue was the pilot caught up samples, examples, documentation all that good stuff and did a big cookie cutter to do the pilot checks to make the way we discussed a while ago. This week I'm fixing the issue where the change I made to make the pilot work has called me out on something actually I'm the issue on the mag tag and an issue about customizing your cows in the layouts in HID. Awesome, that would be great. Thank you, Hugo. Next up is Jepler. Hello. So last week I worked on examples for PIO and a number of those were added to the what is it called the PIO ASSUM library and I'm working on some guide text. I worked on the RGB matrix problems that LaMore encountered on the PICO like mostly on Thursday and Friday and there were a number of red herrings but finally this morning I cracked one problem but so now it works for LaMore at all which it didn't at first but she still saw a crash at least one time running a script updating files so I'm going to go back and test that some more before we merge it in. We'd really like for it to be solid rather than you know mostly okay. So as for the PIO examples the goal is to send the guide to be published this week even if it's short like it just has one or two fully explained examples. The more testing of the RGB matrix on RP2 that I mentioned and we talked in the internal meeting and Scott and LaMore thought it would be good if I started to work on the rotary IO for the Raspberry PICO and a part of that is that I plan to add a some kind of way that you can run a PIO program that accepts input and check whether there's input waiting for you without blocking which would be useful for a variety of reasons not least of which so that I can start prototyping the rotary IO decoder purely in Python and as for fun stuff my receiver using circuit Python now works very reliably it needed a combination of like bypass capacitors but also just not to be too near my real desktop computer time zone correction works now and in theory then this would follow future US daylight time rule changes because it gets the information in the broadcast it just needs a display so I'm looking at all of the eight segment displays from and I'm going to pick something up probably this week so that's kind of my project that I'm continuing with when I'm not working working awesome thank you Jeff all right next up is Jerry Hi so a bunch of testing with the this issue of the LC 709203F battery what do you call it battery information board and it doesn't work on the NRA 52840 and it's sort of a known issue that's been out there for a while so I tried um tried getting some screenshots of some large analyzer probes of it but you know and I got some but I don't make a lot of sense to me so I don't know if anybody else has been looking into this but anybody wants the issues out there and the stuff's on there and any suggestions about what to do with it it's a nothing jumped out to me as to what the problem is other than it doesn't work and it looks different but it's not clear that it looks bad you know the decoding of the of the exchanges looks reasonable so something's weird um and let's see but and it's also intermittent like I found some situations where I would do things also the problem go away briefly but then it would come back so it's seems to be there most of the time on most NRA 52840 boards the clue was really bad the sense is the one that I got working for a while then it broke again um so um and then it spends a bunch of time playing with the UART stuff on the Pico with the GPS thanks for getting that in there and then there was another issue that came up on the forums the people were finding that if you took a GPS and put a feather wing and put it on an STM 32F405 it didn't work it wouldn't get a fix it seemed really odd that you know it would work on other boards we're not on that one and I was able to reproduce it and it turns out from my testing anyway it looks like it's the proximity of the antenna not necessarily the GPS itself because when you use an external antenna it was fine but if I took if I took the external antenna and stuck it right on top of the 32F405 it stopped working it lost a fix so something's emitting from that board the um GPS antenna doesn't like so again that's documented in the forum post and just keep myself busy I've been really frustrated with it just a really common thing of my Linux box crashing whenever I disconnect USB circuit python boards from it lately the NRF 5280 has been really bad at it but all the boards doing it to me so I've been moving everything back over to my Raspberry Pi 400 which may be a little slower but it's been really stable so I do a new circuit python home there's an issue for that right I believe so there's been one out for a long time I should go back and look at it but it's one of these things that comes and goes but and Dan had checked it out it seems to be a pretty clear Linux kernel issue that they don't care about we should we could ask Tak to look at it if he hasn't yet okay yeah I mean I don't have a lot of information it's just frustrating because sometimes it'll work fine and other times it's just every time I disconnect I gotta wait for the machine the machine just reboots yeah so and it's a fun stuff I finally I've got my bird cam out we noticed some bluebirds a lot of bluebird activity in the yard into various bird feeders so I quickly got my bird cam out to see if we can entice the bluebirds into it and been doing a lot of playing with the home assistant on a Raspberry Pi 4 setting up a local MQTT broker which has been a lot of fun to play with that's it awesome thank you Jerry and yeah if it sounds like Carter's had this USB issue too so it's probably something we need to figure out what common hardware is and then ask TAC to look at it it's not a tiny USB it's like I tracked it down to a kernel thing but why is it only on some builds like I don't have this problem well it only happens on a new Buntu as far as I can tell or maybe on other at least a Buntu with that particular kernel maybe but I don't know it doesn't happen on a Raspberry Pi at all yeah I think it has to do with timing also and just the details of the drivers but you know I tracked it down to various things that the kernel sees which the kernel should be upset about and the response I get on the kernel mailing list is on the USB mailing list is like that's not our problem you shouldn't do that so I think there were some ameliorations that we can do but basically the whole idea of a drive disappearing and reappearing is like we're not going to handle that I don't get why I've never seen this like I've been running Linux for a month or two now and I haven't had this problem at all I don't know yes I it may have to do when something goes wrong to certain drivers to decide whether they're more robust or not and so it may have to do with the AMD motherboard support but yeah all right well that's bummer I can talk to you more about it yeah but yeah yeah happy with my USB ports okay let's keep going that's in the weeds territory thank you thank you everyone thanks I'm glad we had that issue at least okay I've got notes from Jose says last week PR for the tab detection for label and bitmap label PR for vertical label and PR to sample type annotations this week going to go back to peripheral for the Pico and open to Python requests or others if you teach me I'm willing to learn that's good and next up is catney all right so last week I did some new product stuff for the PPS 62827 it doesn't require a guide but we added the info for the product into the actual product entry in the shop so if you pick one of those up there's info there did an update to the guide for the BMP 388 for the Stemic UT revision of the breakout thanks to Hugo again for sorting out the pilot and pre-commit and sorting out getting pilot to run the way that I needed it to to stop duplicate code checking the examples I started the guide for the BLM kit it is a board that Adafruit designed and will be donating to groups for workshops and so we're going to put a guide together for that and started working on the circuit python examples for it and spent more time last week working with Ann on picking up the python for microcontrollers newsletter this week continue the BLM guide help folks with their PRs regarding the pilot fix from a guy I will definitely take you up on your offer to help out with that and I will make sure that Dylan reaches out to you because it would be excellent to have more than one person who can run these patches so I will have him reach out to you when he actually does that so you can see that process as well and then I'm going to be working on the guide for the Feather RP2040 which will be in the shop soon, spoiler and continue working with Ann on the newsletter awesome thank you Katny alright next up is KMAS98 okay so continued work on graphical widgets this week so I updated the documentation on the widget and control classes to support those widgets particularly thanks for the feedback and I incorporated that into the most recent PR also related note is how to document those classes so I explored how Sphinx can draw inheritance graphs and I need to test that in the build system to see if it also works there as it does on my machine next I created a new module for holding any bitmap manipulation tools called bitmap tools and it has a first a rotation and zoom scale function as its first entry into that and a placeholder for anybody else to add new bitmap related features next I created or updated the blip function and incorporated several errors in the process but I think those are fixed now basically so if you're trying to scroll something you can safely do that in any direction inside of your own bitmap and I needed that so I could create a scrolling text box widget and then last thing from this past week is there was an issue on the bitmap saver function where you can save from your screen to a file bitmap file and it showed a feature of the core function which has got exposed I think for this function and that function doesn't copy unowned pixels I think that's probably how it's supposed to work in the core but it doesn't rewrite into your buffer over previous pixels if there's nothing there so I think that's how it's supposed to work in the core but it just caused a little issue with the bitmap saver so if you think it shouldn't work that way let me know and I'll take a look at it but I think there's a solution just in the bitmap saver library to refresh your buffer reset it so I guess I would assume it would just do the black if no pixel was found I think it doesn't write anything if no a group owns it so basically it leaves whatever in the buffer was there so it left streaks what the last row was I think the core needs it to be that way but I think when you exposed it that bitmap saver wanted to write black so I sold it just by refreshing the buffer in the bitmap saver library so that it zeroes out everything as a first solution so if you don't think that's how it's supposed to work let me know and I'll take a look okay upcoming so again the continuation of widget work I want to get the switch submitted for a PR in particular I want to get a good set of documentation on how that works so that other folks may be able to follow that sort of example and then make more widgets I want to look at the progress bar PR from Hugo also want to update my dial widget with the latest class functions another annotation widget and also a scrolling text box with scrolling buttons and then last I want to add one more bitmap tool with a fill region currently there's a fill tool to fill a full bitmap but not a pretty small region so I want to add that as well thanks K match all right next up is maker Melissa hello so last week I spent a good chunk of the week hacking on the mini ptft display drivers so that a single driver would work with each of the three st7789 displays along with rotation and offsets and I updated the ptft script to be more flexible with the different rotation settings with different displays using the power of python I implemented the offset logic that I had developed during that into back into our Arduino library so it's much cleaner with I updated the raspberry pi fan service script to make use of the built-in fan service on raspberry pi boards but on other ones that I'll use the existing method we're using before I updated the circuit python.org website with more blinker boards bringing us up to 70 and I started diving into a conflict between the braincraft audio driver and the braincraft display this week I'll continue looking at that and then I need to look into memory issues on portal base with the matrix portal I wanted to update the lib GPIOD pulse in on blinker to load either like a 32 or 64 bit compiled version depending on the raspberry pi os version I wanted to add a matrix portal display rotation option and I've been meaning to add a magtag wifi enable option for a while and that's it awesome thank you melissa next up is there are notes from mark who says last week fixed slash submitted count IO for the rp2040 this week we'll try to get parallel bus for the rp2040 done but life got in my way and that's it for status updates thank you everyone next up we have our final section which is in the weeds so in the weeds is a chance for us to just talk about whatever we need to talk about that might be a longer discussion so the way this works is that folks have put topics in here previously with their name and we'll kind of just go down the list of topics so first up we have dan and jeff so take this topic up if dan doesn't mind as dan talked about during his status updates he's looking at some ways that actually during the build process for a given number of translations we can hopefully speed things up but I was looking at our translation statistics and another thing that we can do is stop building certain translations and I'll kind of take these in order from how they're cut to how debatable I think it is there are two translations that were requested on weblate and we added them but zero translations have actually been made so if you download either the hindi or the greek builds they're labeled as such it just comes up fully in english I think that we should probably stop publishing those they are not helping people they're actively well they're not helping people the next category is translations that are have only a few messages out of the out of the whole and are not seeing active work so this would include potentially the check translation and the Korean translation which are three and seven percent translated and then finally there is a translation that exists more or less just for monolingual english people to be able to check whether the translation machinery works and it's called the pirate translation you know I think it adds things like are in the middle of messages just for fun and I think that we could remove that from the official builds without harming the ability of any person to use circuit python so if we remove those five translations that I believe reduces the number of translations by about a third and would make a pretty big difference in the build time a pretty big favorable difference and then before I take comments on that I want to say I mentioned we have these two translations with zero messages actually translated weblate has a very nice feature where someone can request that a translation be added however there's no way to communicate back to that person so we've made a change on weblate that instead of being able to request it there they're directed to our existing pull request about adding a language and now we have told them you know add a new issue on github about the language you want and then we have an open communication channel with these people and so for instance there was recently a very strange kind of African regional language requested and it turned out because the person later came and talked to us on Discord that they were looking for a British English translation and this is an example of we couldn't resolve this using what we had on weblate and that's why changing the process so they would request a fresh translation by an issue on github is going to help things and I don't know whether we will choose to add a British English translation but it might go great with the Raspberry Pi Pico kind of as two flavors that go together so with that I'm done with the exposition and I'm happy to hear comments. I want to just say somebody asked this morning about which of these is somebody actually using the pinion translation and so it turns out that without the much work at all I was able to look at the download counts for the downloads for various languages and I have the January data and what I see is that for translations that are unused there's usually like around a thousand downloads or there was in January and then for translations that are used it goes up from there so probably some translations are being downloaded everything has been downloaded automatically like maybe some people are just downloading everything I'm not really sure why but that's what we see in the server the HTTP server log but what I did see for instance is that the pirate translation actually has only 2,000 downloads unlike say the empty Hindi one which had about a thousand so a thousand seems to be like a and then it goes up from there like English is like almost 50,000 so and the pinion one was also had a noticeable number of downloads so it was not like nobody was used so this is kind of an easy way to tell like are these translations interesting or not to anybody right so I don't know what it says about the pirate translation that's kind of a just I think I think it's obvious that Greek and Hindi could be turned off and builds like clearly if we shouldn't advertise them as such if there's like literally nothing that's been translated I think percentage is not necessarily the best measure but I think what we should get out of this is like okay here's the bar right like this is the point that a translation is turned on that we actually care about and that we build and I think that bar is actually like what we need to do is we actually I don't know if Weblight has a way to do this but we should really flag like all of the core messages as core things right like all the prompts and things that you get and then in terms of error messages like we could just do error messages as like a percentage but like there is this core set of translation of messages that like we should really point people to is like these are the core ones that we need before we start giving it out which is exactly the experience you're talking about Jeff of like you download it and the prompts you get should be in your native language right and sorry go ahead no I was like that's what I think I think I think if we if we pick a core set and then if we could get that in Weblight of like here's the ones that are like the baseline and then everything else is on top of that is a bonus Hugo were you starting to speak I thought I heard somebody else no alright I must have just imagined it so Hugo had said though in the voice channel is there a Weblight option to be notified when new translations are needed unfortunately I don't think that there is and then I'll also read some comments that David left in the notes document he says in response to don't build the pirate translation just when Pi Moroni starts to embrace circuit Python you want to do that really and I mean I see it's a fun it's a fun connection but for me I'm happy to see pirate translation remain but for me translations are about helping people making it available to people who don't speak English and need it in another language and I don't see the pirate translation as as useful but we don't have to be joyless either and David also comments alternative don't build all translations for every pull request but only for release and I think that the reason we need to build it for every pull request is we will discover oh this pull request is full but only for a particular language and some months that language is German some months that language is Japanese on Fridays it's French we don't know why they all just have slightly different characteristics when you bring different configuration options into it and this and that so I think there's a reason that CI builds everything every time because when you try to short circuit that you will end up surprised that the configuration you expected to work doesn't work at the time you're doing a release and that's exactly what CI is for avoiding I fully understand the CI but I mean if you test one release out of 10 one PR out of 10 or if you test for space only on the place where you know it's going to break because this is a place where we are very tight you can have the benefit of detecting those problems without having to compile for each and every PR I just I don't think you have a good enough gauge on what that is I don't think you want to do that I think you always want to build what you want to release otherwise releases like releases are already taxing to do and if we end up adding this like we don't detect these early problems and have further problems at release time like that's just going to make it harder to release the cost we're talking about here is like Microsoft is paying for CI time and we have to wait a little longer like I would much rather wait a little longer every time than have to worry about like issues popping up only at release time it's also the motivation for like can we speed up CI how can we speed up CI right and so that was like the translation stuff so I think that that I agree that I agree with Scott that you don't know you have a problem until you try it and that's the whole point of CI so I don't mind spending the time on that because it is for instance it may be that the NRF build has a lot of French BLE messages but there aren't a lot of German BLE messages or something it's not consistent across boards or languages necessarily so so my proposal would be let's start by turning Hindi in Greek and check in Korean and let's establish a baseline of like this set of messages must be 100% and then everything on top of that is a bonus in terms of like when somebody comes to me like oh I want to do sets whatever translation we can say start with this set get that set 100% and then all of these other ones are a bonus and that would be would you be willing to make up that list or I assume it would be things like what you see when your program runs when your program finishes when you enter the REPL when you type help we could probably simplify by just saying main.c anything from main.c would be that set I will look whether I think that you could like do a search for that on Weblight yeah I can look into that and I can also make a pull request so that the translations to be done are maintained in the the GitHub YAML files for the CI does that make sense or should it be in the scripts in the tools folder or whatever that is uh there is some place that reads the local directory to figure out all of them and do we want I think it's build board info maybe do we want a a block list or an allow list for that I wonder if we could actually do it automatically like actually just look at all of the translations from main.c and only pass them through maybe that's too hard let's do the simple thing first I would do an allow list because a block list will handle new translations well I will do a PR for an allow list and I would appreciate it if you would write up what we want kind of as a baseline and then we can reevaluate the check and Korean based off of that because it's possible that that's exactly what one or the other of them did the other option is it starts with every message that started with a in English and that's not as good and I suspect Hugo will have a good feel for this too because I think they were looking at the help text is actually not something we translate well because it's not hooked up I don't think because it's a multi-line thing and we don't handle that I think we either had a discussion or there's an issue about actually being able to translate the help text and we should figure that out yeah this does seem familiar do you mean the doc strings spot no not the doc strings just like if you type help parentheses in okay yeah right we talked about like putting a placeholder in the code and then that placeholder would be what like the source string that gets translated right yeah but I think in general like having a policy around this would help new translations as well of like okay start here right like right now it's kind of just like congratulations here's all these random error strings and so if we could if we could better tier our translations on what to do and then use that as a policy for inclusion I think that would help everybody but yeah let's see how far we get how much we gain back from just turning Hindi and Greek off as well like I think pirate's fun and it's already there so it's like not a lot of cost to leave on all right I put all that in the notes we have our action items so I think it's time to hand it to the next person all right let's hand it off to 93 Z thanks Scott so I think Jeff has probably already answered my question the question was if it's safe to rely on the garbage collector if you have well basically circularly reference referenced objects so I have an example here I stripped it from the original code there's no guarantee that it works but it should display the idea there's a a pointer to object A in object B and vice versa and what happens with the garbage collection in such a case is it okay if I have such a construct in my code or is it absolutely not safe that was basically the gist of the question and I just would like to ask Jeff then to confirm that this is okay he linked a Wikipedia article but he didn't actually say anything about whether this applies to micro python or circuit python okay thanks Dan breaking news Dan says that yes we use market sweep garbage collection thanks a lot yeah so the stuff that's in the notes that people are saying is that Jeff said it's a market sweep garbage collection that handles circular references with that difficulty with the link to the Wikipedia article and then v9233 was asking like is that what we use in circuit python or micro python and the answer is yes right okay thanks I would encourage you not to do that simply because I think it makes it confusing about ownership I think it I think having circular references makes it harder to track ownership within C code that's correct I agree with that more for humans than for the software is what you're saying Scott exactly so this is actually a convenience because if I want to implement this extra module then in this new construct where I have the header and the function pointer I still have to store somewhere a reference or the properties of the original and the array so the easiest way for me is if I simply link the original and the array if you say that that's not very elegant then I can simply copy the header by hand and that's not such a big issue so if you say that that shouldn't be in any code then I can go the other way that's absolutely no problem I think it's fine to have back pointers I don't think if you need them you need them no the word need is a very well loaded one because I don't actually need it it's convenient but there are other ways but if it takes more space or something I would say it takes more space right so you have to copy them things in this case you can just pass the pointer and then you are done I mean the problem is if you eventually especially in C code that doesn't have Garb's collection it can be a bit of a nightmare if you need to so one okay but one reason I actually for this was that if you later change the header or the type definition of the ND array then if you use a pointer then it's automatically updated in the code if you copy things then you have to make sure that you copy things but on the other hand I see your point Scott so I I can be convinced I mean I'm not saying don't do it I guess this is the point where I would expect you to have at least a comment saying like how they're related how one implies that the other is still around and this is why Rust is interesting right like Rust is interesting because they formalize ownership and so I would just like just add a comment like I'm not saying don't do it at all I just think like it can be unclear sometimes okay and I trust you to make that judgment yeah okay excellent when I was writing GUI toolkits the parent would have pointers to the children and the children might have pointers to the parent right okay so yeah right yeah it's similar right but like one of those things implies ownership and one of them doesn't yeah right right so just just being able to say that of like this will disappear when this other thing disappears that's something right okay excellent and in circuit pi in circuit pi then a micro pi then it's about like which one gets pointed to by a root pointer for example I heard somebody else I was waiting for my turn okay well it's your turn now so go ahead so there are three boards that work with an RP2040 and I have the Raspberry Pi 0 kind of size one exists from red robotics and that's the one I'm playing with there is one from other fruits in the top secret and there is one from Arturo and I'm pretty sure they are not gonna have the same pin outs mapping the same RP2042 pins from Raspberry Pi stuff and I would love to write code that work for the tree so and maybe I've never used Blinka with the Raspberry Pi 0 but I guess there is a name for each pin in Blinka side and if that name is also working in circuit Python on the RP2040 one of those three ways then the same code will work on the four possible stuff and I don't know to get to that point I mean that's exactly the right intuition I think something that I've kind of started realizing I need to hound people on it's like your board defines your pin names not the chip itself I was pushing the maker about this bunch actually and so I think you're exactly right and I think you're exactly right as well to we should look at the pin naming in the board module that's used in Blinka for the Pi 0 and then either we have board definitions in circuit Python that do the mapping between those names and the RP2040 names or we have a library that does it instead and this is the weird zone that we are in right now with the module carry board relationship versus board board stuff does that look like the physical fed up pin from Pimaroni that we were not super happy with or no I don't think it looks like the they were I think with the issue there was that they were picking a new numbering they did a feather board but then they decided to name them all different names and so I think the right way to go about it is like and LaMoure was talking about this last night in her I want to say deep dive but her desk of Lady Eda was like at some point you build a board it's the first of its form factor you pick all the names but the second one you make should just have the same names like regardless of whether the pin number is actually batch or not like you should still call every pin by the same name and I think that was the problem with the Pimaroni stuff is like I think their physical pin stuff was like trying to like re-number it from one again and it's like no just call it the name that we already call it standardly there is something with a QTPI and the Xiaomi which is something from the QTPI to the Xiaomi and I was ready to rename the port number and it was magically working so I was like oh great same size, same pin and that's how it should be I actually applied to do a presentation at the Open Hardware Summit this year for that I was like I know what I could talk about for 20 minutes like name the pins the same please like when you design a board what I'm going to do is use the name from the board I ask maybe make a table and then whenever there is something migrate to that I think that's the easiest for me yeah I think I know Arturo has a table oh yes he made a mapping of all the pin usage but he wanted to know where I to see was where SPI was and stuff like that and yeah I mean I think you're right you'd like see what Blinka does on the Pi Zero and start there yeah that would be the right naming yep that's what I think and I mean the benefit of the fact that the Pi Zero doesn't label any of those 40 pins means that you could call it whatever you want you don't have to worry about mismatching with what the silkscreen says because there's no helpful silkscreen on those yeah so I think you're exactly right David okay I think that's it last up is Hugo just since we're talking about those pilot updates earlier especially with Dylan going through and applying that change to each repository it occurred to me that any pull request out there would still fail because the check on github actions happens on the branch again that the pull request is on and not a merged version with its target I don't think that's true actually so I just had somebody update build.yaml and precommit config.yaml on an active PR and it did run everything properly if someone updates it on the main branch will the PR execution pass? oh no it still has to be pulled into the PR I think it depends github actions does run on a PR on the merge commit into the main branch that it's being proposed for the problem is that if it runs and it fails and then you don't update the PR again it doesn't try with the newer version of main it doesn't do it again with the new merge so one way that catney is talking about is you could just merge into the branch and then you know for sure that you're using the latest one or if you just I think there's another commit to that branch like if there's other work to do like I think that will cause it to happen as well it's not very clear no but I think that I do think that there are going to be situations where folks are going to have to pull the changes into the PR and so I think having a document which is what we've discussed here having just a document that has an explanation of how to do that is not a bad idea because when we run into that we can say hey we've already got this documented you know here's exactly what to do and that'll help folks out I think just in the event that this does happen that way because you're right it depends there are times when a PR you can rerun the code as many times as you want and it still only runs it from a previous point and so you exactly I think Hugo if you're willing to write and I think markdown probably makes the most sense because then you can have text and code mixed together if you want to write up a document that quickly explains how to do that I would really appreciate it and you can post it to tag me and post it in the CircuitPython channel and then we'll have that available okay sounds reasonable and Scott your point since it doesn't rerun the GitHub actions I'll add a little verb in there just how to make essentially an empty commit just to just like a touch on the pull request so that it will be triggered I think I would just do the merge manually into the branch instead of just doing an empty commit just do the merge and then you know for sure that it's merged in sounds good awesome thank you so much let's wrap up through our full 90 minutes here okay this has been the CircuitPython weekly meeting for March 1st 2021 thank you all for stopping by and participating if you want to support Adafruit and CircuitPython those of us there are a number of us that work on CircuitPython who are paid by Adafruit consider purchasing from the AdafruitShop at Adafruit.com the video of the meeting will be released on the Adafruit YouTube at youtube.com slash Adafruit and the podcast will be available shortly thereafter the newsletter will also feature a link to this so you can subscribe to that by going to adafruitdaily.com check the box for Python for microcontrollers the next meeting will be Monday next Monday I believe yes at the normal time of 11 a.m. Pacific here on the Adafruit Discord server you're welcome to join by going to the URL adafru.it slash Discord we're there all week if you want to get notified about the meeting or participate up and speak at the meeting please ask any of us to add you to the CircuitPython NISAs role on Discord your name will turn purple if you don't have any other roles that are higher than it and with that thank you all so much for being so awesome we'll see you next week thanks everyone