 Hello, everyone. This is the Circuit Python Weekly for April 8th, 2021. It's the time of the week where we get together to talk about all things Circuit Python. I'm Jeff, and I'm sponsored by Adafruit to work on Circuit Python. It's April 5th. Thank you. 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 and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it.discord. We hold the meeting in the Circuit Python 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 a U.S. holiday. If the meeting time is changed, we'll notify you via Discord. If you wish to be notified about changes to the meeting, we can add you to the Circuit Python East's Discord role. There is also a calendar available that we keep updated, so you can subscribe to that. There's a link in the notes document. 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 are still welcome to participate. The video will be posted to YouTube and an audio only version released as a podcast. If you can't find us on your favorite podcast service, please let us know. There is a notes document to accompany the meeting and recording. If you wish to participate, but can't make the meeting, that's the place to leave your hug reports and status updates. We'll add timestamps to the document to go along with the video so you can use the doc to find only the parts of the video that interest you the most. The meeting tends to run 60 to 90 minutes, so it's good to have the option to skip around. A link to the notes document is posted in the Circuit Python channel on the Adafruit Discord every week. Check the pinned messages to find the latest document. This meeting is held in five parts. The first part is community news, which is a preview of the Python on Microcontrollers newsletter, and a look at all things Circuit Python and Python on a hardware. The second part is the state of Circuit Python, the libraries and Blinka, a statistical overview of the entire project. It's a chance to look at the project by the numbers. The third part is hug reports, an opportunity to highlight the good things folks around us are doing, and a moment to take the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is the opportunity to sync up on what we've been up to. Take a couple of minutes, tell us what you've been doing in the time since our last meeting and what you'll be up to before the next one. The fifth part is in the weeds, an opportunity for long form discussion. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates, and that covers the major parts of the meeting. With that, I need to find the right spot in the notes document. Take a time code and tell you about the Circuit Python community news. And I hope FOMI guy can drop the links in. I did not arrange that with you beforehand, but we've got a plethora of Circuit Python keyboards and macro pads from Reddit. Thanks, FOMI guy. Using the Dazzler and GameDevino Circuit Python to create a sprite animation from Tiny Letter. How to use Circuit Python with GPIO pins on a PC from Tom's Hardware, a Raspberry Pi macro pad from JMDawson.co.uk, and a Circuit Playground Ambient Weather Reactive Orb. That's a very rectangular orb, and that one is from the Adafruit Forum. Yeah, and the cubicle picture that I'm talking about is in the note stock, so check that out. That's just a tiny sample of what is coming from the Circuit Python Weekly Newsletter emailed every Tuesday, aka tomorrow. The complete archives are on adafruitdaily.com slash category slash Circuit Python. We aim to highlight the latest Python on hardware-related news from around the web, including Circuit Python, Python, and MicroPython developments. To contribute your own news or project, you can edit next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with hashtag Circuit Python on Twitter or email cpnews at adafruit.com. If you're thinking, oh, my project is too small to be in the newsletter, it's not. We love to show what people are doing and showing people at every skill level that they can begin and get started and do an interesting project is one of the things that is really, I think, key to the whole idea. Anyway, that wraps up Community News, and next we will go on to the state of Circuit Python, the libraries, and BlinkUp. Basically, every week we pull a bunch of stats from GitHub, summarizing what happened over approximately the previous week, and also add a little bit of narrative about how we see the project progressing as a whole. So overall, in the last week, we had 40 pull requests merged from 22 authors. So some names that are less familiar to me are JPUdev, Mbyte, and then we have some people who have been pretty consistently contributing lately, Bergdahl, Kmatch. Yeah, a lot of these names are less familiar. Ryan G14, I think we've had before. Lyuspov is another one I'm unfamiliar with. So thanks to all those authors, when you are contributing to Circuit Python, you really help us advance the project. And also, I want to thank the eight reviewers. It's people we're familiar with seeing. But if you can help out by commenting on pull requests, giving pull requests a test, just generally giving feedback. And if you want to advance to actually being able to review, which means you can mark a pull request to be accepted, we are happy to add these people because that's what enables us to turn these contributions into high quality contributions that we are happy to bring into the fold. And anyway, the last overall number is we had 22 closed issues by 11 people and 22 opened by 16 people. So we were net up two issues, which kind of overall the trend is to more open issues. But it's good to see the numbers of people involved. So with that, I will pass it to Scott to tell us about what's going on in the core. Thank you, Jeff. Okay, numbers for the core, we had eight pull requests merged from nine different authors, which is amazing. M Byte is a new author here. So shout out to them. We had three reviewers, Gambler 21, Jepler and Dan Halbert. So thank you to our three reviewers. As always, we're looking to level folks up into the reviewing role, because that means that more people can get their code reviewed and merged in. We have 21 open pull requests. A number of those are aging, so we should take a look at those. Maybe I'll get some time this week to do that. But if anybody's looking for things to do, picking up old pull requests is really, really helpful. You may, after you read through an existing pull request, you may see that there's like a few things to do to finish it up. And it could be really helpful. I know, in particular, there is one pull request that is for an ESP32 S2 board specifically, and that pull request came along before Expressive was giving out USB PIDs. So that is an example of a pull request that I suspect somebody could pick up and finish, which would be amazing. So that's my plug. Issues-wise, we had four closed issues by three people and seven opened by four people. So we are net positive, which is not always the good thing. But we try to be as aggressive as we can. We have 419 total open issues, which you can see by going to github.com.com. We have six active milestones. We have two open for 620, which I think is going to go out today. We'll hear more from Dan later about that. And we have 53 open issues for 7.0. So that's a change. Dan's gone over through these. So we use milestones to triage the issues we're working on. We have four open support issues, which I suspect we could close. And we have two issues not assigned to milestones. So we'll want to make sure and take a look at those. Overall, Dan's been taking the lead on 6.2, which has been great. And we've already turned the corner on main. So the main branch is now 7.0. So if there are changes that need to be done that will cause us to break APIs, make sure those can happen on main now. Because whatever we release from there on will be marked as 7.0, which is exciting and it unlocks some stuff. So thank you, everybody, for that. And I'll hand it back to Jeff. Yeah. And the incompatibilities have already started. So if your micro lab code doesn't work anymore, that is because you'll have to change it. But we'll talk more about that later. I will now pass it to Ketney, who has been taking notes for me. Thank you very much to tell us about the libraries. All right. Thanks, Jeff. So this section applies to all of the Adafruit Circuit Python libraries. That's everything that starts with Adafruit underscore circuit Python underscore, as well as a few extras, including the Circuit Python community bundle. We have 31 pull requests merged with a couple of the names that you mentioned earlier. 14 authors total and seven reviewers. We had, wow, 1, 2, 3, 4, 1, 2, 3, 4, 5, 5 merged pull requests that were older than a week, older than, yeah, older than a week. Most of them were older than two weeks, which is excellent to see that we're picking up some of those older pull requests and getting them taken care of. And it's also pretty clear that we're staying on top of a lot of new ones. We had, or that leaves us with 57 open pull requests, which is up, but I know that we've been working on some new stuff as well. So that's not entirely surprising. We had 15 closed issues by 10 people and 14 opened by 11, leaving us with 315 open issues. Six of those are labeled good first issues. If you're looking to contribute to Circuit Python on the Python side, check out circuitpython.org slash contributing. You'll find all this information, open pull requests, open issues, and library infrastructure issues. You can search the issues by label, good first issue, as I mentioned, is a great place to start if you're new to contributing to open source in general. If you're looking for something a little more complicated, look for bug or enhancement. If you want to get started reviewing, take a look at any of the open PRs. You can just post a comment to them, say you took a look. If you have the hardware, give it a test. Let us know that you did. That's always helpful, regardless of what it is that you do. It's always helpful to have another set of eyes on a PR. So we greatly appreciate that. And that's a great way to get started reviewing. Once you are more comfortable with things, that's when we can level you up to actually joining the review team. So that's a way to do that without necessarily jumping right into it if that's not what you're prepared to do. In terms of library updates in the last week, we have one new library, Adafruit Circuit Python Fun House, and a number of updated libraries, including the community bundle, but I will not list all of them off. And that's where we are with the libraries. Thank you, Katny. And the last subsection, Makar Melissa will tell us about the state of Blinka. Hello. For Blinka, which is our Circuit Python compatibility layer for Raspberry Pi and other single board computers this week, we had one pull request merged by one author and one reviewer. And that leaves, we have eight open pull requests at this point between the different repos. There was one closed issue by one person and one open by one person, leaving a net of 55 open issues. And there were 275 Pi PI downloads in the last week, and we are currently supporting 70 boards. And if you'd like to contribute to Blinka, as Katny had mentioned, you can go ahead and either help with reviewing pull requests that are outstanding, or you can submit them either bugs or enhancements or whatever else you want. Thanks. Thank you. And now we moved to our first round robin section, which is hug reports. And I will start and then I will read some notes from Jose David and after that pass to Katny. So I want to start with a group hug and apologize for being a little bit disorganized today. The other hug that I know I want to give is to GitHub user, the flow one, who contributed an enhancement to one of the libraries. There was an issue that it infiled saying, you know, this, there seems to be an arbitrary limitation. And I looked into it a little bit and said, Yeah, it looks like that is just kind of arbitrary. And the number can be increased. And they filed a pull request, and I was able to merge it. And now everybody is happy. So I mean, that's a really good outcome and a new contributor, whether they'll return or not, I don't know. But it's always fun to see that happening in the world and to make it happen. And I forgot to take my timecode. All right. So Jose David, who is text only today, has a hug report from Naradoc for pointing the right direction to modify the adabot script to make the page list community libraries, a hug to Johnny Bergdahl for his first PR, and a hug report to all weblet translators, all languages, you make circuit Python easier for more people. Your work is important. Thanks for keeping this up. And let's continue the fun competition. So next is Ketney and then Kmatch. All right. So I have a very short list today because I also forgot to add notes until right before the meeting. So a hug report to everybody who sent in newsletter topics. I know I got emails from a couple of internal folks, but also from David Glauda. So thank you very much for those. And thank you to Jay Pasada 2020 for submitting a PR to the newsletter with a news from around the web submission. And a hug report to everyone I missed this week. I'm sure I'm forgetting things that I meant to hug report. Like I said, I did not get to my notes until right before the meeting and a group hug. Thank you. After Kmatch, it's Melissa. Good. Thanks, Jeff. So first off, first hug goes to David Glauda for some tips on memory saving and circuit Python. Next was thanks to Mark Gamblor and two users on GitHub, C-Harkster, and Mark B-139, which has a lot of great groundwork on how to use microcontrollers as logic analyzers. And a related note for all the work on TinyUSB, TAC has built a great, and I guess the community members have built a great capability, and especially want to call out another user, PyGru, who has one special capability using USB to talk to tests and measurement equipment. So there's a huge asset there and it's great to see all the work and makes life a lot easier to use that. Hey, thanks. Thank you. All right. After Melissa, I'll read notes from Mark. I wanted to give a hug report to Dan H for tackling the circuitpython.org with the new release. I know he was having a little trouble with it. To a hug report to Nikita UT for submitting a pull request to fix the web serial 3D model viewer. And group hug to everyone else. All right. After this, I will pass it to Scott. But Mark writes a hug report to Kevin J Waters, Tanude, Jeff, and David Thatcher for review comments on the audio mixer. After Tanude, we will head back to the top of the alphabet and I bet I have notes to read. No, it will be ask Patrick. So go ahead, Scott. Hello. Hug report to Trevor, who works on iOS for Adafruit here for jumping in on circuitpython, got him going last week, running circuitpython on stuff. Hug report to Dan H for release managing 620 and for the interrupts as an exception's idea. Ideas are good even when they prove to be troublesome. So I just want to encourage everybody to really be creative and put ideas out there. So Dan, thank you for doing that and leading the way. And last up, hug report to Tio Mitch for the core contributions. Really happy to see lots of fixes and additions coming from Tio Mitch. So thanks to them. All right. Thank you. Ask Patrick W. Hello. We don't hear from you a lot. Hello. Yeah. Sorry. I usually am watching these in the middle of the night. So but today my schedule permits me to join in. I wanted to do a deep vibrator. Hey, thanks to David, Jose David M for their work on adding the list of libraries and descriptions to the community bundle repo. It's always cool when I open an issue thinking I'll fix it, but then someone else does it and a group hug to everybody. I mean, I'm always kind of lurking around the back room and this is a really great community and a fun place to participate. So I appreciate it. All right. Thank you. Hope you have more opportunities to join us in the future. All right. I'll pass it to Dan and then read notes from David Cloud. Thank you. Okay. So thanks to Lucian who's working on sleep on the STM32 port and he's reviewed Junzusek's NRF sleep poll request, which has been really helpful, having a second set of eyes on that. And also we've had several discussions in which he Lucian has pointed out like, so like, why is the sleep code doing this? And it was like, oh, that's actually, it shouldn't be doing that. So that's very helpful. Thanks to Junzusek who's persisting on the sleep PR for NRF, even though it's been like a month now, but we keep deferring it for various reasons. Thanks to Johnny Bergdahl, who's been translating Swedish for a long time, and finally said, I don't really like these English error messages that much, they could be better. And he submitted a PR for that. So that's great to have the translators saying commenting on the quality of the messages and not just doing the translation. That's really helpful. Thanks to Scott for starting an earnest working on BLE workflow and in the process found several long-standing BLE issues. Thanks to Katni for doing the Certified Python newsletter the past few weeks and producing really excellent results while Ann is away. Thanks to Bepedric and Marcos Diaz, who found an HID error on macOS, which I thought I was quick to dismiss as a macOS problem, but it turns out we had actually changed something. It's still an macOS problem, but there's not quite as much finger pointing. And thanks to Deshipu who looked at his old issues that were marked long-term and cleaned some of them up. That's really helpful. Okay. All right, I have a couple of people's notes to read and then up after that will be Fome Guy. David Glaude sends a hug report. Thanks to all the YouTube streamers and friends. It's great to learn about design and implementation of an API, discover new project ideas, see how an engineer thinks about what parts to use, how to run a company, new products, etc. To Dan H for all the releases, RC0, but also all those before. And to Rickantha Michael Horne for progress on the Pico quarter. There is a link in the note stock about that if you're interested. And Deshipu says a hug to Dan H and everyone involved for figuring out the mystery of the macOS HID mouse. So next up is Fome Guy and then Hierophact. All right. Thanks, Jeff. This week, first hug to Scott and Trevor for getting started on the BLE workflow for Circuit Python and iOS. I'm excited about that. Keeping an eye on it and hoping to work on the Android side of that implementation. And then also thanks to Jose David for many great improvements in Display.io across a bunch of different libraries and creating new widgets and the new styles library. Jose has been doing a bunch of great work on Display.io stuff. So I appreciate all of that. And that's all for me. Thanks. All right. I'll pass it to Hierophact and then after that Hugo will get to round out the section. All righty. This week, thanks a bunch to Dan for continued and greatly appreciated help on understanding parts of the Deep Sleep API. And also thanks to Dan and Warrior and Wire and all the others in the GitHub for interesting discussions regarding the interrupts, interrupt systems and ideas which may end up impacting the Alarm API. And thanks to you, Jeff, for your continued work on IMX, getting some new modules in that. That's very cool. And that's it for me. All right. Hugo, go ahead. First of all, thanks to Bergdahl or Johnny Bergdahl as we've seen sometimes for catching that potentially confusing error message for memory management and making it easier for everyone. Second, the Hug Report for the Weblight Gangs quote unquote for just helping each other on and keeping each other honest and just encouraging each other. And finally, Group Hug for the community. Thank you. That rounds out Hug Reports and brings us to status updates. In status updates, we want to hear what you've been up to since the last meeting and what you'll be up to before the next one. And feel free to go a little bit outside the bounds of Circuit Python and tell us about something that's going on in your life if you feel like sharing. Once again, I will kick off. I haven't put in my notes before the meeting, so I'll just kind of wing it. But the majority of my time last week I spent on the PWM output on the IMX RT microcontrollers. That is in pretty good shape now and is available in our main branch. So we invite you to check it out and leave us issues for anything that you find is wrong. Other stuff that I did included doing some timings of these new ways of accessing the bitmap data. And the thing that I was excited to see is we've talked about improving the audio input capabilities of Circuit Python so that we can read in audio at the same time as we do processing. And basically with these changes, we would be able to on the NRF microcontroller keep up with the incoming audio data if only we could sample it in the background when we want to do an FFT and show the result on the screen, which is really powerful level of processing for Circuit Python. I did some work related to encoders on the RP2040 microcontroller and also I updated microlab to the newest version of microlab, bringing that into Circuit Python version 7. So as I mentioned before, that is a big incompatible change and basically all software using microlab needs to be changed. At least the imports need to be changed. We will eventually update the guide that we have on that, but we will do it much closer to the time that we release version 7. This week my focus is I2S out on the RT-1011 microcontroller, which will presumably work on the others in the family, although I'm just testing it on the one. And anything beyond that, there is stuff that I would like to improve in the microlab documentation and just whatever else comes along. I have a couple of PRs that I need to bring to a mergeable state as well. And yeah, I think that wraps it up for me. I guess I do want to share that I missed the meeting last week because I was getting my COVID vaccination, had to drive an hour and a half away, but it was available and I was able to take the opportunity to do it. So I encourage you to get a COVID vaccination if you can where you live. And with that, I'll pass it. Let's see. I'll read notes from Jose David and then I'll pass it to Katni. So Jose David last week worked on the slider widget. This allows us to control non-discrete things using a resistive screen, PWM voltage and others, and there's link to a pull request. Also a PR to modify Adabot to make the community libraries page, a styles library, quote, I think it is ready to move out of my repo. There are more links there in the document. A display button library need to review a PR and modify the examples and display text corrected the extra arguments issue. This week, Jose David will start working on the color picker widget and need some assistance from the C graphics folks and we'll also move the new widgets into new libraries. All right, Katni, you are up and then came match. All right. So last week published my first solo newsletter that was successful, including all of the miscellaneous things that happened throughout the week related to the newsletter as well. I did some catch up on some older to-dos that had been missed. It was all stuff I needed feedback on and so I went through my whole list and panged on a bunch of things and got responses on everything and so I checked off a number of older things on my to-do list, which was good. I have continued on the templating quest, which is to create templates of the circuit python essentials guide and then all those will be added to the circuit python compatible board guides. The idea being that instead of there being a general guide that sort of tells you in general how to do something, each board guide will have a set of tailored pages that match exactly what that board can do and have wiring diagrams for that board, etc. So I decided to go the route of doing all the templates first and then I will dump them into the board guides once I've actually completed the templates. This week, more newsletter stuff. It's going to be the case for a few more weeks that there's a lot of newsletter happening. I have great respect for Ann and all that she does now that I mean I did before, but now that I'm actually doing it, my respect has increased. And then once I get the newsletter out this week, I will be starting on the guide for the Neo Trinky, which is a new product we have, and I will be continuing on templating, which is also something that's just going to be on my list for quite some time because it's a huge undertaking to update something like 45 boards guides. So anyway, that's where I'm at. All right, thank you. Neo Trinky is so cute, by the way. Anyway, but next up is Kmatch, and then after that, Melissa. Good, thanks, Jeff. So following on with an into the weeds topic from last week, I created a document to capture some of the intermediate level or so-called intermediate level memory usage tips, particularly things that folks tend to run into when they're using a lot of graphics or fonts or displaying a lot of text. So it's open for business and eager for folks input. There's a GitHub link here that you can go either raise an issue there or ping me on Discord or yeah, somehow tag me, so I'll take a look at it and I can add it into that. If I misrepresent anything, please correct that so it can help folks help solve their problems or have a place to point folks to something they can read to try and get some ideas of how to solve their issues, as well as supporting in the Discord chats. A tangential project, which isn't exactly CircuitPython, but some of the same folks involved, is I've started looking into extending a project that Scott had started almost a year ago on one of the streams called the TinyLogicFriend, and it's basically how to use existing open source software for visualizing logic analyzer traces called SigRock and how to interface that with basically any Adafruit board. So I'll be working on that or looking deeper how to do that. And I actually got my first call and response between that software and an Adafruit board. So I sent a heart back. I appreciated that. So that's what I've got for this week. Thank you. Next up is Melissa and then Scott. Hello. So last week I wrote the new FunHouse library. I updated some minor issues in the portal-based library as well. I learned TypeScript enough to fix the library management section of the VS Code CircuitPython extension. I created a repo for the dynamic bundler. This week I'm going to work on trying to get ESP home working and work on the VS Code extension stuff a bit more. And that's all I know that I'm doing for sure. Oh, another news. I finally got my COVID vaccine scheduled because I became eligible today. All right. Great. All right. Next is Scott and then after that, ask Patrick W. Hello. So I created creation IDs, which is a superset of USB IDs for identifying boards over BLE advertisements. I also created a creation. There's an Adafruit CircuitPython BLE creation library as well to go with it that shows you how to scan for creation IDs and advertise them. I got that to Trevor. That's what Trevor's using for displaying a really friendly grid of boards that are seen by a device when you're doing pairing stuff from iOS. I created the prototype file transfer service, which is Adafruit CircuitPython BLE file transfer for transferring files over BLE. I'm starting in Python first and then it will get brought into CircuitPython once things have been proven with the iOS side. I'll also plan on writing a thorough read me spec of what the protocol is as well there as a way to get feedback before we put it everywhere. I had a question for folks and maybe this is better in the weeds, but if you've done this before, let me know on Discord or something, but I'm looking for ideas for doing generative LED animations, basically taking a one-to-four byte number on any particular board and producing a short, unique animation. The idea is that when boards are advertising, they'll do these unique animations and in the grid of boards that you see on your phone, the models will actually be animated in the same way so that you can pick out the thing that's doing a particular animation in case you have two boards of the same type. Once you initiate the connection, it would be nice if both your phone and the board also showed a second different animation to confirm that the connection that you created is the one you expect. If you've got links to that, let me know. I think I needed a primitive thing that ideally doesn't take too much space up, but I think it would be really helpful in doing BLE pairing. And then the last step, the thing I have to do later today is I'm presenting on I'm presenting on interface design at the Open Hardware Summit on Friday morning, so I've actually got to do those slides. So yeah, looks like we have a couple ideas. Generally, after our RGB LED status flashing the line number, I don't really want to do just flash counts, but I also don't want to do just purely color either because color is something that not everyone can perceive. So a mix of blinking and having different numbers of lights and stuff is all pretty interesting, and it may vary based on board's capabilities as well, whether it's a single color LED, there's not a whole lot you can do with flashes. But yeah, I think it would be cool to have a standard, like here's some code that is in all these different languages that, given a particular number, can produce a seed. And I think it does need to repeat as well, because I don't want to try to sync up the phone side with the device side, so it should just repeat. Anyway, yeah, I don't want to go to in the weeds when I'm not in the weeds. All right, I guess in that case, it's time for Ask Patrick W followed by Dan. Hey there, I've been slowly working on the Azure IoT for the, it's actually CPython sockets format that was implemented into request, then end to end QTTT. Originally I was waiting for an ESP32 SPI based board, and I got all that, I think, you know, Postal Service Shipping United States has been weird. But anyway, getting that working just to see the sort of quote unquote original working did require changes, and I've got that working, and it works with IoT Hub, but it does not work with IoT Central, and if you don't know what that is, one is the pass offering and one is the SaaS offering for Microsoft, and I'm sort of stuck there and I'm basically just whittling away at it, try to get underneath the library and figure out what's going on and why that's different. It's something that's specific to IoT Central, obviously. But anyway, once that is working, I will then switch over to getting it working on the native Wi-Fi of the ESP32 S2, but you know, this is all like a slow background thread for me. And then one sort of ask for maybe MicroDev or Bruce on the ESP IDF update to version 4.3, if there's anything that I can help with or if anybody else can help with, let me know. For those of us on M1 Max, we're still having to manually work around that. But also there's also goodness in the IDF update as well. All right. Thanks for that. Next is Dan, and then I have notes from David and Shippu. Thank you. Okay. So last week, I think Wednesday night, I released 620 RC0. We haven't had any, though there are bugs, the only one that seems to be a showstopper that we should really fix for 620 final is the Mac OS mouse HID problem, which I mentioned previously. So given that there's that just one change and we tested it, we may go ahead and do just 620 final in the next day or two, or zero to two days, I guess I would say. And instead of doing an RC1, I know it would be good policy, but we tend to, we can always do a 621 or something gets messed up. When I was doing 620 RC0, there were some untested changes in the GitHub actions stuff that has to do with generating automated changes to sort of Python.org, and they didn't pan out. And so I ended up sort of scrambling around on Wednesday night to fix up CircuitPython.org. There were like three or four different problems, but that's all fixed now. There's a thing, there's another USB thing. I turned off something called USB remote wake up, which says whether a device can or cannot wake up. The host device, it turns out that tiny USB doesn't quite support that in all platforms yet. So we really should turn it off. I found out about this problem because I read all the MicroPython issues and full requests, and it's important to track MicroPython because they have a lot to do with us, obviously, since we're forth from them. And then I proposed this idea which sounded good at the time, but was kind of a bad idea about treating an interrupt as a Python exception. Worry of Wire pointed out some problems with it, but it provoked a really good discussion on Sunday in the Discord chat about what should we do with interrupts. This is really important because I want to keep provoking this discussion and come up with a simple and sane way to deal with interrupts without providing a tool that makes it easy to hurt yourself, given our subject audience. So I'm really happy about that. Okay. So after the notes that I have to read, we will go to Fome Guy. David Glaude reports trying Blinka on a Pi Zero to see if my Circuit Python code works there. Testing LED shim code on Pi Zero with Blinka and Feather RP2040. Trying to find a uniform naming for Pi Zero, like the 20 by 2 pinout, see that in the weeds topic. And trying to figure out what are the differences and when to use Adafruit ST77089 or AdafruitRGBDisplay.ST7789. Next, notes from Dashipu. I'm doing research for making another handheld game console, this time with a 3.2 inch screen and hopefully much better sound and controls, still struggling with some decisions and some experiments that need to be done. Fluff Micro, a Fluff M0 in an Arduino Pro Micro form factor for easy replacement in projects, and some progress on the MIDI Ocarina. Alright, next is Fome Guy, then Hirofact. Can't hear you, Fome Guy. Alright, I'll read the notes from Fome Guy. Last week, put together a new page for the Custom Fonts Learn Guide that talked about the Bitmap font library and showed a few examples of ways it can be used. Testing and review of the new Cartesian widgets and other display IO related PRs, and implemented basic cursor rendering and movement in the Tiled Map Helper class. This week, worked on point click with cursor to move, tile map game mechanic, and streaming one hour earlier this week Saturday, 9 a.m. Central, due to a vaccine shot appointment in the afternoon, for which yay, yay each time. Alright, Hirofact is next, and then Hugo gets to round it out. Alrighty, so last week, I laid out the boilerplate for the RP2040 alarm system, and started digging into the sleep docs on that looking for gotchas. I found and resolved an issue with the objects returned from light sleep versus the objects that are added to the global array for light sleep, which were different. I've resolved that for STM32, but that should ideally be resolved for all the different ports. I fixed a remaining issue with the STM32 where objects weren't being returned properly from deep sleep, which had to do with, I don't even remember what it had to do with it. It was complicated and weird. I submitted a STM32, the STM32 alarm PR for final testing and review, finally yay. And I've been catching up on the interrupts discussions, as they may have implications for the alarm API and other power related stuff. So hoping to see some more discussion on that. This week, I'm going to be putting in the alarm RP2040 alarm system, getting a control going, putting in the initial implementation and testing that. I'm going to be retesting the changes to audio, P-A-W-M-I-O today. Hopefully just get to merge that. I'm laying out some internal changes to the alarm structure. Well, I'm planning them. I'm going to run by Dan and see if they're viable going forward to simplify the internal APIs, which people don't see, but they're kind of important just because we have to maintain them and things are a little bit rounded about right now. So hopefully we can simplify that. I've got some CI fixes that need to go to the STM32 PR apparently. And amid all that, I'm going to be moving to Boston, back to Boston, post COVID here. So hopefully that won't disrupt things too much, but it'll be good to be back in an office. And that's it for me. Thank you. All right, Hugo, tell us what's up. All right. So last week, I did some pull requests based on infrastructure changes that were pointed out in the contributing page on the CircuitPython website. So failed checks, didn't have actions, things of that nature. This week, I got some feedback from Tony Guy on a PR head open. So incorporating that and looking for otherwise other issues that can help probably do some PR reviews or I reckon help that. And interestingly, since I've had a drawn out battle between push to talk on Discord and Windows, I found out that remapping caps lock to an hide number F key and using that push to talk actually surprisingly works. So there go my push to talk to Lawrence. I hope. All right, we all knew that keyboard was you or that key was useful for something, but we just disagree on what it is. With that, we will move to the final section called in the weeds. So this is the time for longer form discussion. And I think you kind of know how it goes because you've already added a number of topics. So I will pass things to ask Patrick W to introduce the first topic. Thank you. This probably won't take too long, but I thought it was discussing rather than just handling. Thanks for fixing my typo stand for rather than just tucking in a GitHub issue. So there I, as I was working on Azure IoT, I found that they're the library itself to use Adafruit logging. And so I added that to requirements that text, but that broke the build because Adafruit logging is meant to be circuit Python. And if you were running Azure IoT library on, let's say in Blinka, you would use the CPython logging library. So that broke the build for that. So I then opened this issue in the circuit library, which is that for there's essentially two things, two conversations going on there simultaneously. One is that we need a way somehow to express a requirement that is circuit Python only and make Melissa had a good suggestion of using the like environment dash requirements that text format. And you'll see this in projects where they do that for dev or use it for test. And that's pretty common. So I think that makes sense. I think we just sort of get like group thumbs up on that. And the suggested was circuit Python dash requirement dot text. And then requirement dot text would be requirements, I should say dot text would be for quote unquote CPython. They kind of own that one. So I don't think we would change that. So that's one thing. And then there's a kind of another kind of underneath in that thread, which is should we switch circuit to use the JSON that is being generated in the bundle generator, which I'm not really for or against that. It's just I think more thought of, well, are we saying all bundles should have a JSON now? And that's our approach. So those are my two subtopics for this. The JSONs generated automatically now when bundles are created. So they will all have the JSON. But there's one of the things in circuit that I was talking Scott was there's a there's a wish that someday there'll be more than there'll be a third party bundle. So are we saying, oh, bundles, even if they're not created by the build system that they should have the JSON, I think that's kind of my question versus requirements that tax is just like people do that already. Well, I'm trying to make it so that a lot of the plugins use the JSON. So I think having that as a requirement is a good idea. I don't find that as long as it's like what people put the community wants. Yeah. And I mean, I would like I would like to see third party bundles still use the same bundle tooling. It's mainly just like the name of it. Okay. But ideally, like all the all the infrastructure and the tooling around it would be the same. So like if Pimeroni or Sparkfun have their own bundles or the community bundle, like it should still use all the same things and work the same way as the 803 bundle. So then how do we handle I mean, since essentially the JSON is just the requirements reformatted, you know, well, it does include it includes more information because it includes the stuff dependencies. How do we does this environment dash requirements, circuit Python dash requirements make sense? So you do that as well. Yeah. And I would update the JSON to use that circuit Python requirements one. So we do. Okay. And then circuit would then process circuit Python requirements JSON either that one or you could have it processed out of the JSON directly. Yeah, it would be the JSON. I mean, we switch it to use the JSON. But would there be I guess we'd have to work out the format of the circuit Python specific requirements like an example of where the library is circuit Python only because there's a CPython library that you should use if you're doing Python and using Blinkup. Right. I guess another question is, should we make the circuit Python requirements only have the things that are in addition to what you would normally have on the requirements dot text? So that's interesting because today we I have to admit, I mean, I say I, I added the future for dependencies to circuit, but it's ours. The, I have to, I'm ignoring things that are that I know example, not circuit Python, like Blinka, and there's one other one that I can think, I can't think of off the top of my head. So I'm already sort of like ignoring stuff there. And I wonder if circuit should, like if it should be more of an even split like circuit Python requirements at Texas for all things that are circuit Python only and requirements at Texas for all things that are CPython and not mixed the two anymore. I see what you're saying so that we don't have to worry about ignoring it anymore. Yeah. And then maybe even the names like the name in the libraries, the light, the name of the library and the circuit Python requirements can be the circuit Python name. Like the name of the folder I got you. Yeah. I would, I would caution against having copies of all the requirements in two places. I think treating requirements.txt as the, like all of the, all of the implementations need that or all of the environments need these things means that like if you add a dependency, like you, you usually only have to add it in one spot. Right. That was my thought on that was the maintainability. Yeah, but you get a, you can't add Adafruit to, you can't add Adafruit logging or any other circuit.txt, it breaks the build for that. Right. That's what the circuit Python requirements would be for is adding that sort of stuff into. Right. So only, okay. So it'd be, it would be always process requirements at text, ignore all the things that are not circuit Python specific and then layer on top, circuit Python dash requirements.txt. Yeah. But the JSON building process would be the one place this logic lived and not in circuit or each program processing the JSON. Yeah, we just got to see how it works. Okay. That'll make it simpler on everything else. Okay. I think, I think we have an answer then. Which I think you may want to just move to like some circuit Python requirements JSON instead that matches the, the resulting circuit JSON format. Because the problem you're going to run into with, with circuit Python requirements is that like the things that you put in there are not going to be beyond PyPI necessarily. And so the question is what name do you use? That's a good idea. You're really going to use the name that's going to end up in the JSON. You're not going to use the one that matches like a requirements txt format. Yeah, because the circuit Python requirements.txt wouldn't be checked on each check-in like the requirements.txt is. That's a good point. If we do it in JSON format, then we have less processing to do and less can go wrong. And potentially we could actually add a check for the JSON then. Yes. I also think that the circuit Python requirement should be optional only if there's stuff that it needs that the Python doesn't. Right. Because basically we have to say like what built-in, what C Python built-ins we actually need is dependencies. Because in C Python they're assumed to be there whereas in circuit Python they're not. Yeah, today I only, I am personally only aware of data for plugging in. Right. But like we're also doing like color sys is going to be one and requests is going to be weird as well. And date time. Yeah. So I think my proposal would be that we actually have like a circuit Python dash requirements.json file that matches the JSON format that is in the bundle. It's just like a much smaller, much smaller thing. Well, is it complete or is it incomplete and that does it re-list the things that are in requirements.txt? That's a good question. And does it list only the top-level dependency? So you have to, those dependencies. I think it should only list top-level dependencies because otherwise when you add an intermediate-level dependency you have to go change everything that used it. Whereas the build system that sees the whole bundle can resolve it if that's useful. Right. So the, another wrinkle in this, since we're in the weeds, is... This is different than I thought it was going to be. The other wrinkle is that Python is really moving towards like pyproject.toml files. Python's going to add that to that bug. And they include requirements there as well. So like the problem with requirements.txt is there's actually like other places requirements set up like set up to py and pyproject.toml. And I think the world is trying to end up in a pyproject.toml world. So it might actually be worth to just do... I think you can extend the top-level kind of sections of pyproject.toml and we could just add a circuit Python section into there. And then at least even if you have dependencies duplicated, you have them duplicated in the same file. But maybe that's a big... That takes a small change and makes it even bigger. Well, it's really confusing right now because there are some projects where the dependencies instead of the py somewhere it's in terms of text and somewhere it's implied in pyproject.toml and how private pytoml works varies depending on what you're doing, whether you're doing a local or remote pip install. I don't understand this yet and somebody it's not well explained anywhere that I've found. Right. And this is like... Yeah. The whole reason we have a bundle in the first place is like Python doesn't know what they're doing with packaging. So like let's just do the simplest thing for circuit Python. And I don't disagree with that at all. And I think, you know, it could be one thing today. Right. You know, another three months or so. Yeah. So I, you know, we've identified there's only a few libraries this impact. So maybe the right thing to do is just do a circuit Python JSON file in it that we use. And it's like, it'll be easy to find as long as we name it the same. And so if we do want to move all of the libraries away from setup to py to project to toml, like we can do that then because that's a huge amount of work otherwise. Having made JSON format or something like that would also allow to generate any other requirements, whether it's requirements of text or Python.toml, whatever it is, as needed as a build task, wouldn't it? I mean, yeah, it would allow us to automate it, but if we were just going to use something like flit or something, then like, I don't know how easily you can say like, oh yeah, before you actually do this, like before you read the py projects to toml run this other thing, like I don't think that's necessarily easy. Yeah, because it replaces the setup that py, right? Yeah. Or sections of it maybe. Okay. So I think we came to a conclusion that says we would like to create a JSON file for listing the additional requirements within that file. So those are on top of anything that goes in the requirements.txt that supports essentially using that library on Cpython and via Blinka. And Melissa, can you, I'm assuming you'll take point and define like what that looks like since you're handling the JSON stuff? Sure. And then when that's implemented, then I'm happy or anybody can do it too. I don't know, circa can come by and swap circa to use the JSON bundle. And then we will can have, we can drop the requirements.txt from the bundles just because you know, we don't need the same information twice. All right. Well, before we move on, David had put some questions in the text chat. One of them got covered, but I'll just read out the other two. And if we have a quick response. So first, can we get the example and simple test with a circup command? That's what I will do just after downloading the library. And I know the answer is not right now. But is that like on anybody's roadmap? Anything else to say about that? Well, if it's important to you and there's not an issue filed about it, I recommend filing an issue on circup and maybe somebody will implement it. Then the second one question was what about built in library? How does circup know if it's frozen or not? And the answer is it doesn't. As far as I know, for instance, the Adafruit bus device, which is not strictly speaking frozen, circup installs that if it's called for in a requirements.txt, whether or not it's already present on the device. And that's just the way it is. And for most devices, it doesn't matter because we've got the spare space available on the circuit pie drive. So does anybody have something they want to add to that before we move on? Yeah, I think if I'm understanding correctly, David, there's a pie zero is not a circuit Python board, meaning it doesn't manifest the volume circuit Python, that there's nothing then for circuit to install. In fact, circuit will just fail to run at all if it doesn't see a volume circuit Python available. So you would then use PIP. Oh, but you can't because it's a circuit Python library. So yeah, I don't know why you would run a circuit Python library. You would use the C Python version of that library, like instead of Adafruit logging logging. Well, I think the idea may have been, well, suppose I'm familiar with circup but not PIP. Can I use circup anyway? And the answer is no, not right now. I mean, I've just moved to Blinka and yeah, I have to find a way to do it. And I was super happy with the thing I was doing outside of a single board computer. So I have to find which library I have to download. What's the full name on the PIP site? And it's a bit more complicated because it's different from what I used to do. That's the only thing. All right. Well, David, it seems that your mic is working. So do you want to go ahead and introduce your next topic? Yeah. So I've got two points. The first one, maybe we can just do it in the chat with Melisa, but I have that mini PI TFT that I use both on CircuitPython and on the Raspberry Pi and on the Raspberry Pi with CircuitPython or with the CircuitPython library. And then the parameter were not the same. And I think there was a mistake and I was not using the same library to access the screen. And I don't know why I was using one or the other and why they are different. So I was like, okay. And the parameter to offset the pixel are not the same. So I was like, hey, wait, there is a mistake in the library. Oh, no, it's not the same library. This is the inch. Sorry, go ahead. No, if you have the answer, yeah. It's historical. Okay. And which one should I use? So the RGB display one, it predates display IO. It's kind of like the frame buff model. My bias is to use the other one because I think display IO is good. And now we actually have some blinkers for it as well. But yeah, it's just historical that we have both. And okay. And then the other story is, so I'm trying to use the same code on various boards which have the same pinout or the same socket, like a 2 by 20 on the Raspberry Pi, which a lot of single board computer have. And some of the adapter I have also have so that I can put better and have the pin like on the Raspberry Pi. And so I wanted to have a single naming. And I figured out that on the Raspberry Pi zero, we use the BMC numbering, which is not the physical location numbering. And it's not the silk numbering, which is the physical numbering. And we use the X, X like on circuit Python board. But some board or at least one board, maybe the Coral Google something board, use GPIO underscore P for physical location. And that's great because it's the same numbering as on the silk. And it's not D like in use and with conflicting values on the feather side. And so I was wondering if we could have GPIO underscore P a number, which is the physical location of the pin on that connector for all the board, which have that kind of connector. And then if somebody want to write code for a hat or a fat or a bonnet or whatever the name, the same code will always work. I think it's a really good idea. One thing, I think it's a bit long. So maybe you could just call it Pi XX, like whatever the number is for that two by 20 is like the standard Pi header. Maybe I would just call it that. I don't know. In general, I don't think it's labeled very well on the actual pies. So it's messy on Raspberry Pi side because with those numbering, it's a mess. And they've changed from one version of Pi to another version. So no doubt, but yeah. They changed the numbers they call it between. They've changed the BMC for the same physical location at some point or something like that. Right. So I think it's like, I would just take the same approach that CircuitPi does is like the BMC is the Broadcom name or number. And that should be usable, but you should also be able to use just the Pi number, right? Like the number on the two by 20 connector. And I would probably call it Pi to make it clear. Like kind of the prefix is the namespace or numberspace. Scott, do you want to say anything about whether that would conflict with Feathers use of DXX for the GPIO pins? Because I'm not sure why that would be a conflict. I think just don't have the 20 pin or the 40 pin header. Right. I wouldn't consider it a conflict. I just generally don't like A and D as prefixes largely because they imply incorrect data at times, right? Like A pins can still be used digitally usually now. And like, yeah, I just don't think it's a very good prefix. So I think my pick for a prefix for the numbers on a Pi two by 20 connector would be Pi, Pi. So you would have Pi. All uppercase or Pi with a lowercase i. I would do all uppercase to match. But it doesn't actually matter. The idea is just pick one and be consistent. Yeah. But I think it's a good idea. This is exactly why I need to cover this in the talk that I'm going to give on Friday. I've just checked a few single board computer and all the single board computer I have are from Raspberry Pi. So like, I don't have a bigger boom or Coral or a Jetson or whatever. So it's and I could check in the pin.Pi to see what's in use. But there is a lot of indirection goes like you've got that MCU. Then it's the same as this board. And it's very difficult without the board to know what's available really. Or I need to better understand. But I think because the Raspberry Pi kind of established that connector, I would suspect that yeah, the mapping internally will be different. But the naming of just like Pi one through 40 will be consistent. Or whatever the Pi pin out name. And for most of it's SPI or it's Eric's takes or it's I to see. And so it's okay. But a lot of hats. They also use other GPIO for picking LED or whatever. So then and that's where it's become more. Right. For the ones that are on the connector. Yeah. The main reason we were going with the D numbers so that you didn't have to change your sketches as much to go back and forth between circuit Python and Blinka. But it's not the same number. It's D with is not a digit. Right. I mean, like for instance, if you have D4 or something like that, then there's usually one on like a feather and Raspberry Pi. Yeah, I don't. I think I think it's important to not try to draw. Like those are those are two different interfaces, right? The feather interface is different from the Pi interface. Right. Like they're physically different. Yeah. Yes. And I think that means that like it's better to not try to have names that cross over those. There of course is like the standard buses are probably exceptions to that where you want SDA and SEL potentially. If another interface, like if another form factor also designates those two pins, like they should be named the same, obviously. But generally, I would go, I would bias towards being more specific in the prefix that you use. So D and A are generic GPIOs generic. So something like Pi would make it clear that you're talking about the Pi 2 by 20. And what other physical form factor that is like that, like the fact of standard? We don't have the problem with the micro bit or the clue because there is only one for the moment. And if there is another clue, then I guess you're going to make it right. Are there other kind of standard connector where this kind of problem could exist? I'm sure there are. And yeah, I'm sure there are. But like Arduino and Raspberry Pi are by far the two largest, I think. Maybe like Nucleo. Like the Nucleo boards have pretty consistent pinouts. As well, like they have like three different sizes of Nucleo boards that are in the same form factor otherwise. So yeah, another one that comes to mind is this M2 form factor series of boards from Sparkfun. Right, the Micromod. Like sometime last fall, PT had put together a list of, I think, three different companies that were coming out with microcontrollers in that form factor. And there was very little agreement, like even down to which pins were power on ground. So that's not a standard. It's just some things that have the same cut out on the edge. Right. But that's what happens when advanced communication about what you're doing is not happening. With Adafruit parts, we've got the Itsy-Bitsy family, the Cutie Pie family, the Feather family, their Metro family. And we try to be good about them in terms of consistency. We do the best we can because we recognize the importance of it. But other people don't do the same job. Sorry, David. I'll stop talking over you. Yeah, I was confused about the Itsy-Bitsy because I was thinking it was like the Tinsy. And so I was hoping to be able to use the Tinsy to Feather adapter for my Itsy-Bitsy. And apparently, it's not the same thing at the same location. It's just exactly the same spacing between the pins and it's not the same. Oh, God. Yeah, I feel you. This is exactly why I want to do a presentation on it. Think about this when you're introducing a new form factor. I mean, sometimes people don't even think like they make one board and they don't expect to make a second one in the same form factor. So there's all these things that they don't think ahead for. I'm just thinking of Unexpected Maker and the ESP boards that he creates. Yeah. Yeah, that's a good point. It's early days, I think. Yeah, well, so that's the thing. You have to be early on the board when there is a new format so that it's consistent. Like for the Pico, the Pico, maybe they're going to make other boards with the same form factor because there is already a certain number of accessories for the Pico that you can put on top or below or whatever. So yeah, okay. Okay, I'm going to try to do a peer on the link, I think, for the P numbering. Okay. Yeah, that would be good. I mean, ideally it would match soak numbering too, but that's not under our control. But I'm okay having alternative numberings as secondary names. And we have space in the memory of a Raspberry Pi. Oh, yeah. Next, we have a topic from Jose David who is text only regarding issue 4516. I saw some discussion regarding the size of lists. Is there any guideline on how much data we can put in a list? Why is the limit higher for dictionaries? I've used dictionaries with over 2,000 entries, three items for each entry all ints. So was 3516, I don't remember what that was. I think this is the Pi stack exhausted when creating a list. Yeah. And I don't think it's deliberate at all. I think it's just an artifact of the way it's implemented. And it's just, it's for literal lists and dictionaries. Not the size of a list. Not the size in general. You could make a dictionary that's large and add things to it one at a time or whatever. Right. Yeah, I was just like, oh, that's, it's a consequence of moving to the Pi stack. And it's probably that that code should just switch to not doing it on the stack if it's that large. Yeah, I don't know how easy it is to change what a list literal does. I mean, that would be what does the byte compiler do and all these sorts of things that I think we'd be reluctant to dive into when there are workarounds like having your data come from a file or so forth. For that particular use case, for having a large literal list, you're going to start caring about like how much does the byte code, does the byte code, how much storage does the byte code take? Because that might become a substantial fraction of your RAM. And so doing something else I think would be the better thing to do. Right. And I kind of suspect that's the case of like, it's in the constant table that goes along with the byte code. And then it gets copied to the stack because you might mutate it, something like that. My impression was that if you have that list, that it contains an instruction that says push the first element of the list, push the second element, push the third, and so on for a thousand times. And then it says make a list with a thousand items. That's partially what I know from standard Python. And just guessing on the fact that that is kind of the same with a list. Anyway, it's just a guess as to what's going on. Yep. But yeah, that's the consequence is it uses a stack that's proportional to the size of the list and the tuple. And I suspect the dictionary, but I'm not sure. Maybe dictionaries are different. All right. Jose David, second topic. Now that we are moving some widgets out of the display IO layout library, could we add more features? Widgets were in the light side because they were in the display IO layout library. Yeah. So I think this is, I just thought that this was the approach folks were taking of putting widgets in display IO layout. And so I asked them to be moved to separate libraries. And so I would say, yeah, of course, you can add, you can add more features now that they're separate. I don't know if FOMI guy or K match have further ideas on that. But generally, I think, I generally, I think we should keep libraries small because it makes them easier to find. Like it's hard to find all the widgets under display IO layout, because I would assume display IO layout was layout related stuff, not the widgets themselves. Yeah. I don't know if you can hear me. I kind of stepped away and just popped back in. But I think it sounds like we're talking about a splitting layout. And I'm definitely on board with that. We, when we very, very first asked about it and started talking about it, we were talking about Colonial GUI. And I think we switched it because the first thing we had was more of a layout. And we had in mind to make more, more layouts. And what we've kind of gone on to do is add a bunch of widgets. Okay. Yeah. Because of my subject with the layout library is like, you're going to have like horizontal layout, auto wrapping layout, like vertical layout, that sort of stuff. Yeah. And the grid, I think the grid layout fit that. And we have linear, I don't know if linear layout ever got added, but I have one of those floating around somewhere. Okay. Yeah. That's the sort of thing I would expect in this library. And then the things that match that interface that the layout stuff needs, like that can still be separate repos. I know there's a bit of an overhead to separate repos, but I still think it's better in the long term. Yeah. It sounds good to me. Do you have a preference between like Adafruit circuit Python widgets versus Adafruit circuit Python GUI? No, I would just pick one. Okay. Just make it consistent so that it's clear that like all of the, all of the repos that have this prefix match this interface and work with this, with display IO layout. Okay. Cool. Yeah. We can spin that up this week. Yeah. Would you want a prefix like layout or display IO to be in the repo name? Yeah. Display IO, I think for sure. Yeah. Yeah. Yeah. That's signed with me. If that wraps up that discussion, then Dan, your topic is up. I just briefly, so I opened an issue 4542, which is linked in the notes, which asks that people who have an idea that for using interrupts in circuit Python, that they need something that involves interrupts, and they might code it using interrupts and say MicroPrython or Arduino, that they write up their use case and put it, or put it in issue 4542. We don't have to discuss that now. This is going on for quite a while. But it would be nice to collect lots of different use cases, because I can think of some, but it's great to have people suggest their use cases, and then sometimes they suggest mechanisms too. So just look at that issue if you're interested. And thanks for driving that. All the interrupt folks are really hard to make them take a step back and figure out what they're trying to actually do. Right. I was trying to be kind of specific. Yeah, exactly. Thanks. Yeah. We'll crack this nut. Yeah. This is Warrior of Wire. I just wanted to say thanks. Hey, hi. Just wanted to say thank you. I hope I don't come across as too brusque on my issues. Sometimes I give an ocean of words, and it can be a little overwhelming. But I just wanted to say thank you, and I super appreciate you putting out ideas and having discussion on this. It's greatly appreciated. No, I don't mind at all. That's why I mean, you explained yourself, and you did a great job explaining the reason. That was really helpful. And I want to stir things up and get people to think about it in unusual ways. I just want MicroPython is interrupts. Why don't you do that? And there's a reason to think about. Considering that asyncio, for instance, which is not exactly interrupts, has two or three substitute libraries because people find the original one difficult. I think that we can think about things in that way too. Like, how can we make it? I think you did a great job of having a strong opinion while still being polite, which I think is a great skill to have. Yeah, not something that every community does. Good on that. Yeah, super cool. If we end up wanting to talk about it more, feel free to have me. Yeah, I have strong opinions, but I need to find some time to actually put some C into it and to actually play with it. I have some ideas, but yeah, probably whoever starts writing C first is going to win. Well, feel free to write out those ideas because we have a lot of folks interested in it. It's possible that somebody else may pick it up before you get a chance to actually implement it. Yeah, I mean, if you suggested some sample APIs, and I think even if they're not implemented, that's fine because I think it makes people think about how they might use those or whether they need a variation on it and like that. Great. I really like writing example code that doesn't work just to see what the example code looks like. Right, when I was doing that, I realized problems with a couple of the naive ideas, like having a context manager to say, hey, no interrupts allowed inside of here. And it's like if your interrupts, like if you have too many of them, or if they arrive too quickly, you can interrupt your way out of your context handlers all the way out the top of your application, and you just have a race condition with your interrupts, or you have to allow yourself to miss interrupts if they arrive too quickly, which also may not be desirable. Yeah, there's a lot into the weeds we could go with this, but yeah, it's a good topic. And last, we have a topic from Katni. All right, we can keep this quick. So we're going to turn this into either a learn guide. I just linked it in the chat or a learn page. Does anybody have thoughts on whether they think it's enough content for a standalone guide or do we think we're going to expand on it at some point at which point it probably makes more sense to have it as a standalone guide? Or should we just add it as a page to the Welcome to Circuit Python guide? My preference would be to have a separate guide. Okay, that's kind of what I thought too. I just wanted to get a second opinion on that. And I think, yeah, I think the reason is that there's a lot in the Welcome to Circuit Python guide already. And people do get lost in those weeds sometimes, so I think generally, yeah. So I think having a separate guide, and like you say, that gives us the flexibility to expand it and split it into separate pages and that sort of stuff too. I agree with a separate guide because I think it's going to help that stand out and it would also appeal to people who are more advanced as well too. Yeah, that's what I thought. And it feels like something that other folks may have stuff to add to it as time goes on. And like this may turn into one of those guides where the more features that we add that help this particular issue, the more that we need to add to this guide. People plug in a search term like memory saving. Would that, if it was in the original guide, would it even come up or will it still come up? Yeah, if it was a page in a guide, it would still come up. You might not know to click on that guide because you would just see the Welcome to Circuit Python in the description of the guide, but it would bring it up if you punched it in. Yeah. If we have like cross references to guides are good and I think you might even think about like can we prune the current, like the non-UF2 boot loader's page, for instance, you know, maybe that should be its own guide, just in terms of to reduce the number of things in the left-hand column or something like that. Like a beginner doesn't even know like, what the heck is he talking about? And so in the long run, yeah, maybe that he would like slimming down the existing guide and putting pointers off to specialized guides that are not referred to very often or something. Yeah, that's fine. Extended topics or something like that. At the end. Thank you back off of what Dan was just saying. Putting things like that in a beginner guide can also tend to scare off beginners like, oh wait, I have to think of all these things as opposed to just five minute, you know, get that first blinking LED, get that first to win. For sure. I agree completely. Yeah, that was all. Sounds good. I'm on my topic over. All right. Thanks, you, Katny. Thanks, everybody. I'm going to wrap up the meeting because we have been at this for about an hour and a half. So time to find my end of meeting spiel. Thank you, everyone. This has been the Circuit Python Weekly Meeting for April 5th, 2021. Thanks to everyone who participated. If you want to support Adafruit and Circuit Python and those of us that work on Circuit Python, consider purchasing from the Adafruit shop at adfruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe. The next meeting will be held next Monday at the usual 2 p.m. Eastern, 11 a.m. Pacific time. The meeting is held on the Adafruit Discord Server, which you can join by going to adafru.it slash discord. The chat is 24 seven, but the meeting is on Mondays. To be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Python Easter's role on Discord. We hope to see you all next week. Thanks, everyone. Thanks, everybody. Thank you.