 Hello, everyone. This is the Circuit Python Weekly for September 20, 2021. This is the time of the week where we get together to talk about all things Circuit Python. I'm Scott, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of microcontrollers. A version of microcontrollers. Sorry, just got an email. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them in Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to the URL adafru.it-slash-discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the US holiday. If the meeting time is changed, we'll notify you via Discord. To be notified, you have to be in the Circuit Python Discord role, so just let us know if you want to be a part of that. There's also a calendar available that we try to keep updated that has all the meeting times. Let us know if you'd like to subscribe to that. We can give you the URL. This meeting is recorded. We record the audio from the Voice Channel and the video of the Text Channel. If you'd rather not have your voice recorded, you're still welcome to participate. Just drop in the note stock. The video of this meeting will be posted to YouTube when the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, please let us know. There's a note stock to accompany the meeting and recording. If you wish to participate but can't make the meeting, you can leave hug reports and status updates for us in the document. We'll read them off during the meeting. The note stock also contains timestamps to go along with the video so you can use the doc to skip to the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. We post the note stock for the next meeting to the CircuitPython Dev Channel on the 8 of your Discord every week, and we pin it in the pinned messages, so check there. Overall, this meeting is held in five parts. The first is community news. This is just a preview of the Python and microcontrollers newsletter that covers upcoming stuff. The second part is the state of CircuitPython libraries in Blanka. This is a statistical overview of the entire project, and it's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up with what we've been up to. Take a couple of minutes and talk about what you've been up to during the last week since the last meeting and what you'll be up to over the next week until the next meeting. The fifth part and final part is in the weeds. In the weeds is an opportunity for more long-form discussions. These discussions can come out of status updates or be something you've identified ahead of time is too long for status updates. And that covers how the meetings will go. With that, I will switch to the note stock and take a time code and read the community news. So, community news-wise, first up we have the exciting announcement that happened earlier today. CircuitPython 7.0.0 is now available. This is a stable release that, as most of us know, we've been working on for quite a while, so it's great to see it stable. It also means that we don't have to support 6.3 as much, hopefully. So there's lots of good stuff in 7.0, and I just want to read off this list that Dan and Ann put together just as a heads up and a reminder for folks what's different since 6.3 because I suspect that we'll be helping some folks through this too. So, here we go. First up is support for the CircuitPython development workflow over BLE. This is still new and upcoming. Camera support on the ESP32S2. QRIO module for QR decoding from the camera stuff. The keypad key scanning module, runtime customization of USB devices, merging in of MicroPython fixes and enhancements as of MicroPython 116. The underscore pixel buff module is now Adafruit underscore pixel buff. The color wheel function was moved to rainbow.io. Supervisor.tixms is now available to allow easier timekeeping. The RGB status LED codes have been simplified and I should take an action item to update the guide for that. A clocking fix for a few samples of the RP2040 boards. Vector.io was reworked and some of its API was changed. In particular, vector shape is no longer needed for user code. We added some new modules at exit, get pass and trace back all from CPython. There are definitely subsets of those modules but it can be handy. We added supervisor.getprevious trace back. So, this allows you to read the exception string from a previous run. Board.led is now consistently present on all boards that have such an LED. Pulse out is no longer needs a P, they'll be out. They manage them themselves. We've fixed a Unicode file system, file name support, so you can do file names that are Unicode. The board ID is now available in bootout.txt as well as board.boardid. And finally, the AESIO, which is for encryption, is on for full builds by default. In terms of ports, in port status, atmsamd presents ESP32, S2, NRF, Raspberry Pi and STM for the F4 series are stable. STM for other chips is actively being improved but they'd be missing stuff and the Litex and the IMXRT10XX which is found on the TNT is all considered alpha and may have bugs and stuff. So, that's the overview of seven. Thank you all for helping with that. It's a huge thing and we're very happy to see it out. Next up in community news, an upgraded Astro Pi deployed to the International Space Station with a new European Astro Pi challenge. To the, to the ISS and beyond, upgraded Raspberry Pi computers are heading to the space for the Astro Pi challenge. News sensors, cameras and machine learning technology. Young people can take advantage of all these features and more. The Astro Pi units in their space ready cases of a machined aluminum will travel to the ISS in December on the SpaceX Dragon cargo rocket launching from Kennedy Space Center. Once the resupply vehicle docks with the ISS the units will be unpacked and set up ready to run Astro Pi participants code in 2022. The Astro Pi challenge, there are two Astro Pi missions for young people to choose from, mission zero and mission space lab. Young people can participate in one or both of the missions. Participation is free and open to young people up to the age of 19 in European Space Agency member states, Slovenia, Canada, Latvia, Lithuania and Malta. And there's more information there as well. Next up, just taking time codes here. GitHub starts to embed thanks to people as contributors to releases. GitHub will now automate making a release notes contributors section based on the GitHub at handles found within the release notes, also known as mentions. And there's some pictures there of what that means. Next up, playable quotes for the Game Boy. Playable quotes for the Game Boy allows creation and sharing of tiny interactive slices of existing games. Simply load a game into the playable quotes emulator play towards the part of the game you want to demonstrate. Click the record new quote button, continue playing then eventually click the stop recording button to complete the demo. Under the hood, the software uses a Python emulator of the Game Boy. A description of how this is done is on joel.fren music. You can see more about the Pie Boy emulator on GitHub. Next up, the IEEE top programming languages. 2021 ranks Python as number one. Which programming languages on top in 2021? It's Python says the IEEE. The annual ranking of programming languages is led by Python thanks to a vast number of libraries that make it incredibly versatile. And there's links from IEEE Spectrum and Tech Republic. And finally, a reminder. Halloween is coming, the Halloween Hackfest. Join Hackaday, Digikey and Adafruit for a Halloween themed contest. They want to see your crazy, creepy, ghostly, spooky and awesome projects. If costumes are your favorite part of Halloween, then why not dress up your outfit with some hacked upgrades? You can even design a ghoulish prop to add to your home's Halloween decor or light up a jack-o'-lantern with LEDs. Whether it's technical, artistic or just plain terrifying, Hackaday wants to see your projects. Check out the Halloween show and tell with Hackaday Friday, October 29th at 1 p.m. Pacific to show off your awesome projects entered in the contest. Don't forget to also share those projects on social media and use the hashtag Halloween Hackfest. Hackaday and Digikey have partnered on this Halloween themed contest to offer three winners an online shopping spree to the Digikey warehouse. And finally, details about this. These stories come from the newsletter. The Circuit Python Weekly newsletter is a Circuit Python community run newsletter emailed every Tuesday to over 9,000 people. The complete archives are available at AdafruitDaily.com slash Category slash Circuit Python. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python and MicroPython developments. To contribute your own news or projects, edit next week's draft in the github.com slash Adafruit slash Circuit Python dash weekly dash newsletter repo. Check the drafts folder there and submit a poll request with the changes. You may also tag a tweet with Circuit Python on Twitter or email cpnews at adafruit.com and we'd be happy to add it as well. And thanks to Ann as always for running the newsletter. All right, that's it for community news. Next up, State of Circuit Python Libraries in Blinka. This is a chance for us to have a more statistical look at the view of the subparts of the project. I will start and then we'll go through the different sections here. So first up, overall, we had 29 poll requests merged from 17 different authors. So thank you to all of our authors. Some new names on here for me, I would say our OS research. So thanks to them. We had nine reviewers. So thank you to all of our reviewers. We had 19 closed issues by 14 people, 13 opened by 10 people. Sorry for the backing up truck. So we're net down six open issues and generally things are rocking or rolling. On the core side, I will say, we had 21 poll requests merged from 14 different authors. So thank you to all of our, yeah. Sorry if you got excited that Amazon was visiting. I don't know. I can't see the truck, so I couldn't tell you if it is one here. 14 authors for the 21 poll requests in the core. Thank you to all of our authors. We had four reviewers as well, so thank you to the reviewers. We have eight open poll requests. The oldest is 16 days old, so we're doing really good keeping up with poll requests. So thank you to all of our reviewers who are helping with that. Issues-wise, we had 10 closed issues by seven people, eight opened by six people, so we're net down two for a total of 414 open issues. We triage, we triage the issues by assigning milestones. We have two issues not assigned to milestones, so we'll have to take a look at those. And we have zero open issues for 7.0.0. And I would just say overall, 7.0 is out, so thank you to everybody who's helped with that. Please take a look, or please help any folks that are having trouble upgrading. If you see any issues, please let us know as well. But thanks again, and we're starting to think about what the next big things are. Yeah, so congrats on 7.0 everyone. All right, next up is libraries. I'm gonna read these off today. So for the libraries, there were eight poll requests merged from six different authors. So thank you to all our authors. We had eight reviewers as well, so that's awesome. I'm getting lots of good reviews. There, for the merged poll requests, the oldest was 36 days open, so good to see that being worked on. We had eight closed issues by eight people and three opened by three people, so net down five as well, for a total of 345 open issues. Four of those are marked good first issues, and it would be great to get more of those marked as good first issues. So if you're looking to contribute to the Circupython Libraries, I'm going through issues, and marking those as good is really helpful. And we're about to enter October here, and October is a Hacktoberfest time, so we tend to participate in that and get some new folks contributing. So good first issues are the ones we tend to mark as the ones that those folks should start at. So think about that. If you want to get started, there's an overview of how to contribute at Circupython.org slash contributing that has updated lists of issues as well, so check that out. We've had a few library updates in the last seven days. GPS, image load, SSD 1306, IS 31, FL 3741, and the TZLC 59711 libraries were all updated, so thank you folks. And with that, I will kick it over to Maker Melissa for an update on Blinka. Hello, Blinka is our Circupython compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week we had zero pull requests merge. There were four open pull requests on there, and there was one closed issue by one person and two open by two people, leaving a net of 60 open issues. There were 9,502 PiWheels downloads in the last month, and we are currently supporting 76 boards. And that's it. Awesome, thanks, Melissa. And that's it for the state of Circupython libraries in Blinka. Sounds like everything's going really well. Next up, we have Hug Reports. Hug Reports is a chance for us to talk about, or a chance for us to thank folks for the work that they've been doing within our community. We like this as a companion or a counter to Bug Reports, which tends to overemphasize problems, but we want to emphasize the cool things that are happening in our community. So this is done as a round robin. I will start and we'll go through the list of folks in the note stock. So first from me, I have two. First off, I just wanted to say, Hug Reports, Dan, for doing the bulk of the 7.0 releases. Releasing takes some time and can be kind of taxing. So thanks, Dan, for taking those on. And then second up, I wanted to say thank you to all the deep divers, the folks that watched my deep dive streams, for sticking with me last week on Friday through some audio setup issues. I watched just the beginning of it and immediately realized that it was my mistake. I had OBS misconfigured. So hopefully we'll take another stab at it next week. I'm using the new mic right now as well. So hopefully it'll all get sorted out. So thanks to all the deep divers for being supportive of that. And with that, I will read off some Hug Reports from Anecdata. Anecdata says, a Hug Report to Tanute myself for the heavy lifting fixing a quirky memory issue. And a Hug Report to everyone for all of the thought and effort that has gone into Circuit Python 7. And next up, we have notes from AskPatrick, W. Patrick says, belated hugs to Fome Guy and Naradok for their super helpful contributions to Circuit Cookie Cutter and the whole library management ecosystem. Hug to the person who designed the artwork on the macro pad. I wish I could see both sides of the board at once. And that person was Philby. And with that, let's go to Dan. Okay, echoing what everyone said so far, thanks to everyone who contributed and tested, contributed to and tested 7.00 final or 7.00 through the whole process. We came out the other end and we have a really good release. Thanks to Naradok for finding a last minute issue with RP2040 that caused a really severe power cycling problem on it. And thanks to Attic Data for testing on that GC memory bug and then to Scott for fixing it. Awesome, thank you, Dan. Next up is Fome Guy. All right, thanks, Scott. This week, I got some hugs for Dura Penza who made some additional improvements inside CircuitPython.org to the downloads pages and also one of the data files to Dexter Starbird, Lay Samurai-Pour-Pay and Naradok, all of whom helped me out with some different tidbits during my stream over the weekend. And then also another hug for Naradok who fixed some issues inside the TLC59711 library that somebody reported over the weekend in the Help With Channel. And also I've seen lots of folks come by recently trying to work on the Pi Ducky project. I think there was a video or something in the newsletter a few weeks back and I've seen Naradok help out a bunch of those folks. So thank you for that as well. And then lastly to Dan H and everybody else who contributed or tested or reviewed for the 7.00 release. Thanks. Thanks, Fome Guy. All right, next up we have Jeff. Hello, I just need to scroll to my answers and then I'll tell you. So first thanks to AnikData and Scott tackling round two of the weird garbage collection memory bug. A group hug to everybody who contributed to 7.00, whether that was through issues, poor requests, comments and reviews. And I should include people who help out here on the Discord as well and the forum. Thanks everybody. There's so many of you. I don't know, we don't know how many there are. Thanks to Dan for actually putting 7.00 out and writing the release notes. And thanks to Katni for covering for me unexpectedly last Monday when I would have otherwise run the meeting. Awesome. Thank you, Jeff. And next up is Jerry. Hi, let's see congratulations to everybody and for the release of 7.00. And special thanks to MicroDev and Dan H for quickly finding, fixing an issue with SDI-OIO on the STM32 builds before it went out. So good luck with it all. Thanks, Jerry. All right, now next up I have notes from Katni. Katni says a group hug to everybody for getting 7.00 stable. Hug report to FOMI guy for looking into creating some good first issues on the library and for myself for covering for Katni in the meeting today. Yeah, we had to convince Katni to skip the meeting. Next up I have notes from LaSamurai Propri who says a hug report to Tanu FOMI guy for the regular streams. Hug report to Tanu, Dan H, Jepler and everybody else for getting 7.00, CircuitPython 7 final out and a group hug to everyone for making CircuitPython such a great community. And next up is Maker Melissa. Hi, hello, I wanted to give a hug to everyone. Everyone involved who got the new CircuitPython 7.00.0 release out, a hug to LaSamurai Propri for working on it. Hold on a second. I'm too late, sorry, my voice is a little hoarse. You want, do you want me to read it for you? Yes, please. Okay. All right, Melissa says everyone involved who got the CircuitPython 7.00 release. Hug report to LaSamurai Propri for working on a major update to the Blinka Display IO library and a group hug for everybody else. Last up, we have notes from Naradok who says hug report to MS Creations for first noticing the RP2040 issue with RC2. Hug report to Hem for joining the helpers team and hug report to Dan H and everyone else for the release of 7.00. That's it for hug reports. Next up, we have another round Robin for status updates. Status updates is a chance for us to talk about what we've been working on in the past week and what we plan on working on in the coming week. So take a couple of minutes and do that. It's a great way to keep track of what everybody's working on, what's on the radar and potentially collaborate on different things. So I'll start again and we'll go through the list. So first up, I got the BLE workflow changes checked in just in time for 7.00. So that should be awesome. Hopefully that's a solid foundation for us to build the clients on which is ongoing work that I'm not doing but I need to check in on. Last week I started on TinyUSB on the Broadcom chips that are on the Raspberry Pis. So there's a lot for me to learn about Cortex-A series chips rather than Cortex-M but potentially bringing circuit Python and TinyUSB to the Raspberry Pi chips could be very, very powerful and interesting. Particularly I'm interested in interfacing with over HDMI to televisions and stuff. It doesn't look too bad. So that could be really, really cool to have circuit Python on lots of screens in your house. So this week I'm continuing the Broadcom work and also checking in on the BLE workflow clients but I am also taking Thursday off to spend it with my sister and her kiddos. Hopefully helping a little bit around the house there. So that's gonna be fun. And that's it for me this week. So let's go to Dan. Okay, so in the past week I released 7-0-0, released candidate three and then there were no bugs that came in at the last minute and there were show stoppers and so I released 7-0-0 early this morning and forgot to press the thing to press update circuitpython.org until a couple hours after that but it's all set now. After 7-0-0, now that 7-0-0 is out, there's a backlog of some things to do. There's post-polling issues of various kinds. In particular, I'll be working on some HID things, some projects and also some remaining issues. And we have some ideas for 8-0-0 that we'll probably talk about later. But it's a long run just so people, I put this in the discord but it was 10 months since 6-0-0 came out. So that gives you some idea of how long it takes to make your release at least. Okay. I think that's actually pretty good but I'm not actually tracked it. Yeah. I mean, we actually were even faster in the beginning but we had less code so we had more and more code and more and more ports to handle each time. We want to add a feature sometimes that involves adding it in five places. So that's the thing to keep in mind. Okay. The nature of the beast. Yeah, yeah. I think MicroPython has even more ports. It's kind of astounding. Yeah. Yeah, and they're more different. Yeah. Cool. Well, thanks, Dan. Okay. Next up is FomyGuy. All right. This week I learned about MyPython. There's a tool called MyPy and it can be used for checking typing information to validate if it's correct or not or missing. I made some improvements to the TileMap game helper specifically around the camera and a cursor. And then I started working on some scripts using that MyPy tool that will eventually run through the entire bundle and try to find all of the libraries that have missing type information and create an issue with a nice, pretty template with a checklist and everything. And so that's what I've been up to. And I'll probably continue most of that stuff this week. Awesome. Thank you, FomyGuy. All right. Next up is Jepler. Hi again. So last week I primarily worked on the ESP32S2 parallel display bus module. It is already working with a BitBang approach thanks to pre-existing code by Kmatch that was improved a little bit by Mark Gambler. But by using the ESP32S2's I2S controller in LCD interface mode, we can do more. We can allow arbitrary data pins instead of just D03D7 or D8 through D15, et cetera. And maybe we can enable a 16 bit parallel mode and maybe the IO will be faster. When I stopped working on Friday, I was facing some weird glitches. I eventually figured out that the glitches were caused by the read pin to the display saying that a read was requested, causing it to drive the pins that the microcontroller was trying to drive as an output. But immediately after I fixed that problem, I was still seeing problems because I think there's a problem with my oscilloscope in logic analyzer mode that some other people have experienced. So it looked like the problem wasn't fixed, but it was fixed. Anyway, so this morning it actually got to the point where it will repaint the display on the Adafruit 2.8 inch breakout, but it's really slow because of all my debug prints. And when I remove my debug prints, I get a weird error that must be like a memory overwrite error or something. So I'll be working further on that. Back to work I have done. I put in a PR to add timestamps to key events. Those record the timestamp when circuit Python detected the key was pressed. No matter how much later you read it out, well, up to 29 days or something. And then I worked a little more on the micro Python version of the garbage collector bug fix that Scott and I worked on and that Scott finished the last part of. Hopefully I've made it acceptable to them now, but I haven't gone looking to see whether there's been a review. So this week my primary focus is that ESP32S2 parallel display. I will PR it when it's working as well as the current code is, but then after that I will continue and try and get the 16 bit parallel display in the ESP32S2 HMI dev kit working, which was kind of my original goal, although that part won't probably be used in an Adafruit product right away. It's my end point anyway. Yeah, so that's what I've got going up and unlike the past couple of weeks, I anticipate putting in a regular for me week of work. All right, well, thank you, Jeff. Jeff, Jeff. I couldn't decide whether to say Jeff or Jeff. Okay, thanks, Jeff. Next up, I have notes from Katnney. I can never type. You'd think I would type better given that that's been my job for over a decade. All right, next up, notes from Katnney. Last week nearly finished the IS-31FL3741 guide. There were issues with the Arduino libraries getting merged into the IDE on Arduino's end that resulted in unknown delays. So everything but the Arduino page is completed. Started the proximity trinky guide as well. This week Arduino live was merged into IDE so I can finish the IS-31 guide now, finish the proximity trinky guide and a huge list of miscellaneous or more guides. On Saturday, got a flu shot, pneumonia shot, and Tdap, the tetanus booster. And I'm now feeling terrible which is why I'm missing the meeting. Worth it though, so. That's, Katnney is currently upgrading her immune system and she'll get back to work after that is complete. All right, next up I have notes from Masamori Prepre who says, last week slash this week, working on a full retranslation of Blinka display IO from the current core. Currently pure Python but speedups like NumPy to be investigated, tracking at github.com slash Adafruit slash Adafruit Blinka display IO issues number 71. And next up let's go to maker Melissa. Hello, so last week I worked on writing a 2.9 inch e-ink display guide and I started working on the new animated gift, a new animated gift player guide. I was out sick for a couple of days last week and I finally got around to testing the new flexible e-ink this morning only to discover I needed to write a new driver for it for circuit Python. So I wrote a new driver this morning and we'll be uploading that soon. This week I will be updating the guide to use that new driver for the newer e-ink, the flexible e-ink that is. I will likely update the Raspberry Pi EPD library and guide page in the same manner and I need to test out a potential 3.5 inch Pi TFT touch screen issue and then I can work on finishing up the animated gift player guide and that's it. Awesome, thank you Melissa. Okay, and that's it for status updates. So the last section we have here is in the weeds. In the weeds is a chance for us to have any sort of longer conversations that we would like to have and as we, we have a couple of topics already. So if anybody has any other topics, please drop them in the notes and I'll hand everything over to you to introduce those. So let's start with FOMI guy. All right, thanks Scott. So I mentioned in the status updates that I'm gonna be working on some scripts to make issues to find, well the scripts will find missing typing information and will create issues on the libraries that have it. So a couple of questions that came out of that process are are there libraries we should exclude this from? Cause they will add additional space to the code and I know some of them are used, they're frozen into the systems and space is tight in some situations. So the ones I had in mind that I think I see stuff like this come up on are the circuit playground and the HID but I wanted to open it up if anybody knew of others. And then the other questions I came up with were should I make Hacktoberfest tags on the issues or just the good first issue tag? And then I assume I think there was something that runs that converts them all or adds that to it. I don't recall how that got done last year. Yeah, so I think there is a blinker run or something that a script that can run that automatically marks good first issues with that Hacktober tag as well. Okay, so I'll do just good first issue on my pass through. And then the last one was do we want to add to and this was a little bit longer term but once we get the bulk of the typing information in do we want to add an actions task that will run my pie to try to enforce it whenever new PRs come in? I just. Yes. Yes, I agree with Jeff. Okay, I'm going to leave some notes here when I reference back to them. Yeah. And then in terms of, I think we can do all libraries because my understanding is that in MicroPython if it sees type of annotations it just basically strips them and ignores them. So where I started out looking at it this morning it makes the MPY files just a little bit larger particularly because you need to say try colon from typing import and then each thing that you use from it like capital L list except import error pass. And so that adds byte codes and that adds the string at least of typing and maybe the string capital L list and capital T tuple to the MPY file. After import the RAM usage was the same and the increased memory usage was in the realm of like 50 bytes per MPY file. So it's small, but it's not quite zero. I mean, I think that's fine still, but. Okay, I can try them out even on those and then we can see like, well, I don't know if there's a way to test exactly but if there is some way to test after there is a branch created with that code in it we could try it out, see if there's any issues that come out of it. Sure, yeah. I mean, I think type information is really valuable so I'm really happy that you're doing this work. I think it's gonna be really important. Cool. Yeah, I've been using PyTerm a lot more as my primary development even on devices and stuff. I always use it for libraries but I've been using on the device a lot more and it's super handy to have the IDE to help you out with all of that. Right, right. Yeah, and that's something in the long term I'd like to see on the mobile side as well of like having good mobile editing I think is gonna rely on a lot of that stuff too. Oh yeah, cause it can prompt you a lot better than having to type like actually type in everything with the keyboard. Mm-hmm. Yeah, and like if you think of this world somewhere between blocks and code like you can auto generate snippets, I guess, where you can say like, oh, you wanna use this function like dragging it over and then you can have all the arguments and you can whittle down which arguments you wanna give as options to select for those things based on the types that it accepts and things like that. Yeah, that would be awesome. Does that have to do with the circuit Python stubs? It's similar in nature but it doesn't use the stubs specifically. It's kind of the same concept as the stubs but it's for the libraries and it's not separated out into different files. Okay, I just wanted to understand. Yeah. There was any difference. It's not really a difference, it's just the method by which it's done. Yep, right. And the main difference is that the stubs are documenting C implemented interfaces. So the stubs are the Python APIs without the implementation because the implementation's in C. Okay, that makes sense. Yeah, so if you ever look in a stub file it will have just like def function name parameters documentation but then it will just have dot, dot, dot as the implementation. Whereas with the libraries it'll actually have the implementation in it. Yeah. Okay, thank you. Useful for the same reason like Fomey guy said. Be nice to not have to guess about things and not have to look at the source to find out whether you're right or not. Right, right. Yeah, I think generally like it's the backbone of a lot of these more advanced editors. So it's an important thing to do and thank you for taking that on Fomey guy. Yeah, for sure. I think that covers all the questions I had though. Alrighty. Well, let's kick it over to Jerry for the second topic. Yeah, so just maybe it's because I haven't paying enough attention but with all the new stuff with the BLE workflow and you know, boards like the Microbit and I think some of the other NRF some of the other BLE supporting boards. We're a good place to go to get started. I know I've tried it in the past it didn't work very well but I can't remember now how I actually found the information. So it's still really early and what I've really realized is that like I've learned to appreciate how much we benefited from USB just working on the host side, right? Like think about all the things that we could do because OS is just support them by default, right? Like HID, MIDI, mass storage, serial we get all of those for free on the host side because of the standard USB interfaces for those things. None of that or not much of that is true for BLE. Like there's no file transfer thing for BLE there's Nordic UART service for serial but it's not that commonly used like there's no de facto app that you would use for that. BLE MIDI might work but that's like not core to the workflow. So it's just really early and it is my intention for us to document it when we have a better story for it but basically right now we're still very much in the like we gotta sort out all the client side of things. So you'll see more information come out as we get further along in the client side of things. Okay, so yeah, that's fine. And absolutely no pressure and no rush on my part. I was just talking about things to play with. So if you do want any outside testing you know, send a note saying, you know and just with a pointer to worry how to get started. So happy to try it but happy to wait. Yeah, I think so there's like three kind of things that we're working on right now. There's code.circuitpathon.org that Melissa did a lot of good work on but it got a bit obsolete when I changed the APIs. So there's some work there to tweak the JavaScript library that that builds on and that can do that can work over BLE web Bluetooth from Android or Mac Chrome but it requires some changes to Chrome on the other things to work fully. So like that's a work in progress and we'll circle back to that shortly. And then we have two apps that we're kind of working on right now. Trevor is working on an app called PyLeap that is a Python focused guide focused way to quickly get going with projects on a device over BLE. And that's probably where you'll see most of the documentation and stuff come first is just with that app work. We've got some targets in the next couple of months not to give too much away. Spoilers. That's fine. Like I said, there's no rush. And I noticed today on the guide pages there's this sort of PyLeap thing that it looks like it's a placeholder for something that may be coming in the future. So I just wanted to make sure that there wasn't something you were looking for help with. So again, no need to do anything to make it available but if there's something that you're looking for outside help with then that's fine. Yeah, soon, soon. So we just got it. So Apple has TestFlight which is like their way to get like pre-release apps to people. So we have TestFlight versions of PyLeap and of Glider. Glider is the other app. File Glider is the official name now. Those we have internally for testing and we're gonna push to get them out to our community soon but we're not quite there yet. Okay, I'll be happy to wait and watch for releases. So I wanna make sure you weren't looking for some testing it. Not quite yet, not quite yet. That's fine, no problem. There's plenty to do. Yeah, if people do wanna learn more that I think the docs of the protocol are pretty good. So if you go to the Adafruit, Belie file transfer repo that's like the Python implementation of the protocol. So it can tell you all the different commands and all of the different and like how that works into the hood. You can actually use that library as well. So I have, there's example code in there of being able to like transfer files from. So I have like, I would have two featherboards on my desk and one would be talking to the other one. And so that should work. Thanks. Yeah. But in the Amazon truck made it all the way here. Oh, great. Back to my drum. And to be complete about this, the other app is File Glider. And File Glider is an iOS app that we're aiming to be agnostic to the thing that's doing the file transfer stuff. So it has nothing to do with Python. And it's trying to do file integrations with the files app on iOS. So basically it's gonna be the bridge so that you can just do file stuff on a device from other apps on iOS. It's not on the app store yet. Correct. All right. So both of those apps will go through like a test flight with Antonio, Trevor, myself and PT. And then once we feel okay with it, we'll start to broaden the test flight circle and then at some point we'll get them on the app store as well. Great. Thanks. Hopefully in the next month or two. I definitely feel a little bad moving off of it because I know that code you don't use rots. And so I do want to still push to get people using this. But at the same time all of the client side stuff is very much outside my wheelhouse. And I'm tired of being Lee. No, like I said, seeing a lot of chatter about it on things and trying to figure out am I supposed, is there something that the community could be doing here? And that's all I was just looking to make sure I had missed some piece of. I mean, if people have the skills to do client side stuff I would love to see people start to pick up these protocols for their own apps and uses. But it's all like, I just merged in the workflow API changes like last week or the week before. So it's still all pretty new. And we'll get there. It's just one of those things that is quite long-term, right? Okay, I wasn't trying to put any pressure on anybody yet. No, no, no, no. Jerry, we really appreciate all the testing that you do for us. But I do want to just like, it's good to talk about this so that everybody's aware of what's going on then. I think we've seen just a lot of people doing USB HID recently, right? And like we've had that for years. Right, so it's important for us to realize that like there are some things that just take a long time to not only do, but also just catch on. And I think, you know, all of a sudden, you know, the keyboard stuff that's come out recently is just, you know, accelerated that. Also there's tools now that impart some pieces that people can play with. So imagine that to be a piece of it. Yeah, yeah. I think we'll get there. We're just, we're still laying all the foundation. And so that'll be, it'll be good. And I'm sure there's bugs and we'll work through those. And that's fine. In the meantime, I'm enjoying a break. I bet. Good, thanks. And I think the pie stuff could be really neat too. So I think you have pies as well. So I'll be curious to get- Oh, absolutely. And I look forward to playing with that too when it comes along. Yeah, awesome. Okay, great. Jeff's got a, I think, quick topic. So let's just go to Jeff here. Yeah, I was just thinking about milestones since we are done with 7-0-0. What actions do we need to do over on GitHub? I think close the 7-0-0 milestone and then do we need a 7-0-x milestone or is that 7-x-x milestone? I think 7-0. Cover what we need. I think 7-x-x is fine. All right, so the only thing is to close 7-0-0 accidentally add things to it. Okay. Any other thoughts on that? Sounds right to me, yeah. All right. I guess one other quick question. I can put the things that we were going to break in 8-0-0. I can put those in our main branch now, right? No, I wouldn't. No, all right. I intend on doing some 7-point-x releases first. Okay, good to know. Otherwise, if we do those breaking changes, then the next thing we have to do is 8, which we could. It's just a number. But I think, similar to 6-0 or where we had 6-1-2-3, I kind of expect similar for 7. It's like we'll do a few feature releases for 7 and I think we can do the MicroPython upgrade, some of the HID stuff Dan's looking at and the display stuff that you're looking at could all go in a 7x. So I think we should stay in stable land a little while before we get ourselves into the abyss that we just are leaving, which is a little bit old, stable, and we're having to direct more and more people to use the unstable one. I think we should bask in the stable release a little while before we get back into that unstable part. One last extension of my real quick, easy question. Do you wanna repeat what you were saying in the internal meeting about where new boards would go now that 7.0.0 has just come out? So we were just talking about whether we would do a pre, Dan was suggesting doing a pre-release of 7.1 because we had new boards, but generally I consider new boards as like a patch release. So like, if you think about semver versioning, which is like, it's like three numbers, right? Like the first one's major, the second one's minor, and the third one's patch, it's a left to right. So the major one is like, we're changing APIs and people have to pay attention to what we're changing so because there could might break. The middle one is we're adding stuff, but that's new stuff and it's backwards compatible if it's on an existing API. So you don't have to worry about whether your code breaks and then the right most one is like, we're not really changing anything, we're just fixing something. And I kind of think that the boards just go in that bucket of just like, I guess they could be in the middle bucket, but like generally I would just put, it happens so frequently that I would put it in the patch bucket. But I think there's already stuff that's been added which would justify a seven one. There were already API additions. So I don't actually anticipate unless there's something broken. Yeah. There necessarily being a 701 or something like that. I mean, we would do it on the 70X branch if we were doing that. Right, right. Yeah, I mean, I think, I guess the other thing I was pushing back is like, I really don't want to have to tell people to use a pre-release. So if you want to do a pre-release for like a week and then do it stable, that would be fine with me, but like I think at this point we can just think of it as stable for a little while. And so if you want to get it out, just do seven one, like that's not a problem either. I just don't want like those boards stuck in pre-release land for a while. Yeah, yeah, I agree with that. At most you would do a beta or a release candidate, yeah. Yeah, but I think generally- You probably make the cycle time of that really short. Like, okay, I'm going to hold off merging some more stuff for a little while until I get this one out or something or I make a branch immediately. Right. I think generally like once we get to the stable release we do actually do release follow-up stable releases directly rather than through a pre-release. If it's been tested, yeah, if it's clear, yeah. If it's like not very risky. Yeah. Like if we did the update to MicroPython 117, like I think I'd want a pre-release for that. But for just board definitions, like it doesn't worry me. Yeah. All right, does that clarify some stuff? Yes, thank you. Sorry, I had another window open and everything has gone in since 7.00. And there's already a surprising amount. That's awesome. I mean, we've been really rolling because of all the awesome contributions we've had. So I'm all on board to keep the release training train going and yeah. Jeff, do you want to talk about the CI changes? Because I know you got hung up on those some. Not really. I don't have my thoughts too collected. If you think that there's something I can do to fix what's going on in my, I would love for you to tell me that. I just kind of got frustrated and felt a little shut down by it. But then when I worked on other stuff instead. So yeah, that's where I'm at. I mean, I didn't, I was mainly, so let me put a time code in. So the- Let me back up. I didn't feel shut like a person had shut me down. I felt frustrated by what the automated is doing to me. Although at the same time, as I said, I'm not confident that we can make these changes and get them right enough that it won't bite us sometime. But anyway, but we're going to do it. We're going to go ahead and see where we get to and we'll get to a good enough place. So that's fine. But yeah, how to fix my particular hang-up that I have, I would love to know how to do that. So the context for folks is that in the last couple of weeks, I changed the way that we build what, how we choose to build boards in the continuous integration test. So basically like what we used to do before is anytime you change circuit Python, we'd build all 200 plus boards that we support. And what I did is what we realized is we saw some cases that were kind of ridiculous, which was like I changed one board and now I'm building all 200 and there's like really clearly no reason that I should be, should have to do that. And it's like a huge waste of resources. It's a huge waste of time that we have to wait. And so I went and added a process where at the end so what we do in circuit Python because that's so costly, we actually run some tests first to make sure that those tests are okay before we build all the boards. And so what I added was at the end of that, there's a stage where we figure out what boards do we wanna build and then that trickles down to the actual board, the builds that happen after that. And I was actually quite surprised, like I was pretty ignorant when I first started this work because it seems like a simple thing to do but it's actually quite complicated because you have to decide what files you wanna consider has changed and then decide based on those what boards you build. And that second part is I think pretty straightforward. It's just like if all the files are, if a file is in a board specific directory you just build that board and you just do that for every file. If it's in a port specific you build all the boards from the port and if it's outside of the ports then you just build everything. So that the second step is pretty easy but the first step is actually really hard. The first step is figuring out what files changes you care about. So imagine you have a pull request which is the simple case which is like I'm building based on MicroPython or CirclePython something and I have three commits along that branch and you wanna build everything for those three commits all the files that all those three commits changed because say the first commit breaks a board, right? The second commit doesn't fix it and you don't want that to be considered okay because the first one would be merged as well and still break a board. So there's this like complexity there of like figuring out which commits you care about and what files they changed. And then so I think that for pull request is pretty clear because GitHub will tell us like, oh, like here's the branch we're on here's the branch we're against and we can figure out those three commits pretty straightforward. The challenge comes is what and the context for what Jeff was doing was he was just pushing to his own feature branch and it has kind of like a default like by default just compare yourself against your own main branch because it's not a pull request, it's just a push. I thought the behavior that I expected to happen was that it would just consider the files from the original commit, but that's not actually the case. That wasn't actually the case for Jeff and I don't necessarily think it's, I don't think it's correctly set up. I thought that's what was gonna happen and we exempt that from any Adafruit Circuit Python branches. So we wanna make sure that Adafruit Circuit Python branches have everything built every time just to be on the safe side. But the way it's set up now, I guess it compares against the main branch and if your main branch is really old or different or whatever, like you end up getting like all the files changed and because all the files are changed, like it actually breaks because of the way that it passes the, or it, yeah, if the list of files that changed is too long, it actually breaks the thing. So, yeah, I think, Jeff, for you, there's two ways we could go about it. One is changing the way it computes the files so not every file is changed, but then we should probably also add a thing that says, if this thing fails because it's too long, then we just default, like send a default value in that causes everything to be rebuilt and not fail. Okay, I think I followed some of that. Yeah, so like we use this library to determine what all the changed files were and it works for PR as well, but it doesn't necessarily work for push as well. So- And you said there's also a special rule if it's a branch in Adafruit organization? Yeah, but that's done on the second phase. Okay, so it would have already been an error. Correct, yeah. So I'm also wondering like if it's a pull request that's going to go into 70x branch, then in the actual pull request, it would get the correct list of files, but if it was in, if it was just a branch in my repository, it would compare effectively, compare circuit Python 7 to whatever was in main and those will end up being radically different over time. Yeah, so pull requests are easy because GitHub provides you the base branch as well. In the case of a commit or a push, you don't get the base branch and so it just assumes the base branch is main. So FummyGuy says in the text chat, I wonder if it would be possible to pass that information from one step to another by writing it into a file. And I think the answer is yes, because an action can write a file, but this action that we use, Dornie slash paths filter, doesn't have an obvious way to use a file. I filed an issue requesting that they add it and I don't think any action has happened on that yet, but I filed it on the weekends. So even if they're a very active maintainer, that's not a bad sign yet. But that occurred to me as well. If there was a file, then this length limit of about 130,000 characters wouldn't matter. Yeah, and once I realized how hard of a problem it was, I was like, I'm just gonna rely on this library and just call it a day. So I think you're pursuing the right thing of either adding something to that or we just replace it with something that we do ourselves. Yeah, once I got past my initial grumpiness, I was trying to be more constructive than I was initially. All right, well, I will try updating my main branch in my fork and see if that changes what happens. The other thing that you could do is we could just change it so that we only do that for pull requests. We could just have it build everything for pushes, but the reason that I don't really wanna do that is because I think when you push, like if I have a branch that I have as a pull request to circuit Python, it runs the CI twice. It runs it on a pull request and it runs it on a push. Yeah, if you've enabled actions in your fork, which I have, I think that's not the default, but since the other way to find out like that I've overfilled a board is to create a pull request or a draft pull request. And I don't like doing that for things that I don't think are substantially ready to be considered. I felt like enabling it on my fork was the way to go and usually it doesn't cause problems except maybe I have to wait a while. So I'm trying to find the way to do, the way that works the best with how everybody else wants to work. Yeah, I mean, I do that too. I just hadn't run into it yet. If- Yeah, there's no reason that I would update my branch called main except to do this because I don't care what the content of that branch is. I do wonder, like it is a setting in that file to say what the default is. Could we change the default to being circuitpython slash main instead of, I don't know what you were gonna say. I was gonna say the branch you pushed to. Like what happens if your base branch is the same branch that you updated? Like will it just do the commits then? On the second push, it just does the second commit. But when it was a newly created branch, it gets this big list of differences. Okay. But yeah, when you do the second push to the same branch it looks like it just gets the much shorter list of files changed in that second commit. Which is what I was thinking it would do. So it's just that first commit case. Which I wonder if you push two commits at once like you have your branch now you push two commits, what happened? Not on a PR run, but on the branch run. Well, I'll have to find out. Yeah, it's definitely, yeah. Go ahead and tweak it any way you find. Like I was mainly focused on testing the pull request case because that's the one that helps us. And I didn't even look at the content of that script that takes in this list of changed files and does something. So I didn't know about these things where it was doing something different if it's a pull request or not. So it, the only thing it does is it says if I'm ate a fruit circa Python then I just build everything. Or it's not a pull request then build everything. That's the only thing that script does. The only other stuff it does is it just does the like for every file in that list figure out if it's a board, port or everything category. And then it just has a set of all the boards that it's gonna build and then it generates the output and stuff. So it's not much of the logic that we're having issue with. I see this, you mentioned that it runs things twice. I mean, when I label a release, when I make a release it runs a PR build and then it runs the release build. So I have to wait for the second one to finish actually. And I don't know why it does that. Well, so I think. Because they have different settings. The release build is run saying that the source of the event was a release and the PR build is done as a result of a merged PR. But I didn't do a PR. I just didn't do a PR. I think it's a push commit. It's a push, it's a push trigger. And the trigger is because you pushed a tag to the repo. But right, so it should do a build if I just push the tag, but I'm not sure if it could tell. It used to be that it would do the uploads twice. Which was actually helpful because often the build failed. And now it does the builds only once, but it only does it on the second set of builds. So I have to wait for that anyway. It's not terrible because it doesn't happen that often, but it just, it delays the build by, you know, it delays the release by an hour or two because of this. So I was just wondering, so I see, so the fact that it's a push of a tag only is the reason, but I don't know if we can detect that. We could probably tell it not to do things based on a tag push, maybe. Maybe. I mean, there's a lot of things in the GitHub actions YML file that we don't even have. Right, I would just worry that it's not, if the only way it's doing the tag, yeah, I just don't want to eliminate the other one by accident also. Right. And usually what happens is that I'm all set to do release and then the build process breaks in some way. So it's not so great. So. I mean, we talked to a lot of servers to suck stuff down. Yeah, yeah. Okay, well, that's helpful. Now I understand why this is happening and it's not related to what you were talking about really. So yeah. Well, it's related to GitHub actions, right? Like, so GitHub actions is basically for every web hook you can do, you can trigger an action. Yeah. And so when you do release, you're doing two actions. You're doing a tag push and you're doing a release. And the way we have it set up now is that we do stuff on pushes and we do stuff on releases. Right, so I'll see if there's a thing about distinguishing pushes. Yeah. But there may not be, yeah. Okay. There's like two degrees of doing it. There's the like workflow level on push thing. And then there's also like, once it decides to run, you get more information about it and you can opt out later as well. Aha, okay. And like this build stuff is using a pretty advanced trick as well. Like jobs can have output and that output has contexts where you can reference it. So like the first job does the tests and decides all the boards to build and that feeds into like the build matrix of each one and blah, blah, blah. It's pretty neat, but it's definitely not simple. All right, okay. All right, let's wrap up folks. We're running, we're over time and blah, blah, blah. This is very, this is even more of the weeds, yeah. I mean, yeah. I've been diving deep recently. Okay, thank you everybody. This has been the Circuit Python Weekly for September 20th, 2021. Let me find my calendar. Where did my calendar go? It's the wrong window. Do we know what next week is? It's the 27th. Yeah, is it on Monday? Yeah, there's nothing special going on. Okay, so next week we'll meet at 11 a.m. Pacific, 2 p.m. Eastern here on the Adafruit Discord server on Monday for the meeting next week. If you'd like to be notified about the meeting, please join the, ask to be joined or added to the Circuit Python ESA's role on Discord. If you're not on Discord, but would like to join, you can go to urladafru.it slash discord. If you wanna support Adafruit and Circuit Python and those of us that work on Circuit Python, consider purchasing from the Adafruit shop at adafruit.com. The video this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available as well as the audio as a podcast. It will be also featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe to that. I gave the URL for Discord. I think that's it. I think I covered everything. So thank you all for hanging in there, especially in our, in the weeds section. And we'll talk to you on Discord and see you all next week on Monday. Thanks all.