 Hello, and welcome. This is the Circuit Python Weekly for June 13, 2022. 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 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 any time by going to the URL adafru.it slash discord. We hold the meeting in the hashtag Circuit Python Dev text channel and the Circuit Python voice channel. We generally do not look at the text that goes along with the voice channel, which is anything in Discord. This meeting typically happens on Mondays at 2 PM Eastern, 11 AM Pacific, except when it coincides with the US holiday. In the notes talk, there's a link to a calendar. You can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive those notifications, ask us to add you to the Ad Circuit Pythonistas Discord role. There's a notes talk to accompany the meeting and recording. The notes talk contains timestamps to go along with the video so you can use the doc to view only the parts of the video that interest you most. This meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. After each meeting, we post a link for the next meeting's notes document to the Circuit Python dev channel on the Adiford Discord. Check the pins messages to find the latest notes doc so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. The first part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python on Microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This is a statistical overview of the entire project, and it's a chance to look at the project by the numbers separate from what we've all been up to. The third part is hug reports. It's an opportunity to highlight the good things folks are doing in the community and taking the time to recognize them. The fourth part is status updates. It's an opportunity to sync up with what we've been working on. I take a couple of minutes and talk about what you've been up to in the last week. And since the last meeting, what you'll be up to over the next week until the next meeting. Lastly, we have in the weeds. It's 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's how the meeting will go. With that, I'll get started on community news right after I take a timestamp and switch over. So community news. First item is a chance for us to talk about all things CircuitPython, Python, and CPython related. So I'll start here. The headline for the newsletter tomorrow, from the newsletter tomorrow, is the CircuitPython 8.0.0 Alpha 1 release. The CircuitPython team, specifically Dan, has released the CircuitPython 80 Alpha 1 version of CircuitPython. It is relatively stable, but there will be further additions and fixes for the final release. Note that major number changes, such as version 7 to version 8, may have application programming, aka programming interface API changes, that are incompatible with the previous major version. In 8.0 so far, notable changes are we've added Talgrid.contains. Analog in values are full range from 0 to 65, 535, instead of having 0s on low order bits. Onewire is only Onewire I.O. and is no longer in bus I.O. Orbit bang I.O. Gapad shift has been removed. Please use keypad.shift register keys instead. And we've added .env support, which allows you to do os.getenv values, and they can be set in the .env file on the CircuitPython drive. Next up, we have a bit of a T. So Phil likes to create CircuitPython posters for every major version. And we've got a final version internally for this. So we're pretty excited about it. And this newsletter is going to be the announcement of what the CircuitPython 8 poster is. And it's pretty exciting because it's a collaboration with a company that we are not going to quite tell you. And it shows the CircuitPython together. Some example previous posters along this theme were our kind of like co-poster for 7.0 with MicroPython. And then 6.0 was also with Nordic. So we've got another company working with us on CircuitPython 8.0 poster. So that's going to be very exciting. So subscribe to the newsletter if you haven't yet. To do that, you can go to AdafruitDaily.com and select Python for microcontrollers. I'll talk about this a little bit later. But since I'm teasing it, I might as well tell you. You could also look after tomorrow at AdafruitDaily.com slash Category slash CircuitPython, I think, is where it will be if you don't end up subscribing. OK, another time code. Next up, we have PyLeap is available in the Apple App Store. The PyLeap app is available on the Apple App Store for iOS, iPad devices. There's a blog post about it. Take complete projects from the Adafruit Learn system and transfer them directly to a Circuit Playground Blue Fruit microcontroller board without opening a code editor or connecting to a computer. PyLeap is Adafruit's app for iOS and iPadOS. It allows programming a Circuit Playground Blue Fruit anywhere with various completed projects, including sending Rebos to your Circuit Playground Blue Fruit, loading up sound files, and using light and sound sensors. PyLeap is available on the App Store. I believe it works with Clue as well. So it's Circuit Playground Blue Fruit and also Clue. And it works wirelessly over Bluetooth Low Energy. OK, next. And Catney confirms that it works for Clue as well. Next up, we have PyOhio has announced their talks for PyOhio 2022. It'll be online July 30 with streaming talks and community discussion. There's a link there at pyohio.org. And there's info via Twitter as well. And note that Circuit Python team member Catney will be giving a talk, Simplicity and Fun, Learning with Circuit Python. Next up, the PSF board election dates for 2022 have been announced. The PSF board elections are a chance for the community to help find the next batch of folks this year, the PSF. This year, there are four seats open on the PSF board. You can see who's on the board currently on python.org. Nominations for the new board members opens June 1. The timeline is nominations open June 1. The cutoff for nominations is June 15, so in two days. And these are marked as Anywhere on Earth, AOE. That's when the voter application cutoff date is as well, June 15. The candidates are announced the next day on the 16th. Voting starts the 20th and ends the 30th. Nominations should be made through a form on the python.org site. And you will need a python.org account to do that as well. You can nominate yourself or someone else, but no one will be forced to run, so you may want to consider reaching out to someone before nominating them. And thank you to FOMA guy for putting the links in. Next up, more CPython news. Python 3.11 speedup benchmarks. Last month, Python 3.11 beta one was released as their first preview of this major update to the Python programming language. Besides new language features and other improvements, Python 3.11 performance is looking fantastic with very nice performance uplift over prior Python 3 releases. Besides changes affecting the Python language itself, Python 3.11 has been landing performance work from the quote, faster CPython project to speed up the reference implementation. Python 3.11 is 10 to 60% faster than Python 3.10, according to the official figures and a 1.22 times speedup with their standard benchmark. And Pheronix has some info in addition to the Adafruit blog. And with that, we should say thank you to Ann for putting all of these juicy details together in our newsletter. The CircuitPython Weekly Newsletter is a CircuitPython community-run newsletter emailed every Tuesday. The complete archives are available at adafruit.doe.com slash category slash CircuitPython. It highlights the latest Python on hardware-related news from around the web, including CircuitPython, Python, and MicroPython developments. To contribute your own news or project, edit next week's draft on github.com slash adafruit slash CircuitPython dash weekly dash newsletter and there's a drafts folder there that you can edit or you can submit a, and submit a poll request there with the changes. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnewsatadafruit.com. And Mr. Certainly is providing a live review saying really digging the newsletters are a great way to keep up to date. So thank you all and thanks to Ann for being the editor for that newsletter. Okay, next up. The State of CircuitPython Libraries in Boyka. This is our second section. This is a kind of statistical overview of the health of the project and its sub-projects really meant to ground us in some numbers that we kind of think are kind of key indicators of the health of everything. So first, overall we had 25 poll requests merged from 15 different authors. So thank you to all those folks. A couple of names that I haven't seen very often or are new are R. Tiley, Isaac Ben and Shyamaloon. Thank you to those new folks in particular and thank you to all of our authors. We had seven reviewers. So thank you to our reviewers as well. You make it possible for those authors to get their code merged in. So thank you reviewers. Issues-wise we had 16 closed issues by nine people and 12 opened by 11 people. So we're net down four, which is great. And we're starting to hit the double digits on the number of people doing issues. So that's very cool too. And with that, I'll switch to the next section, which is the core. So the numbers for the core. We had 12 poll requests merged from 10 different authors. So thank you to all those folks. We had four reviewers. We have 14 open poll requests, which is I think down a little bit from last week, which is nice. We do have a few of them that are getting quite old. So we should take a look at those again as well. We have five closed issues by three people and six open by six people. So in the core, we're up one for a total of 516 open issues. We generally use milestones to gauge how we're doing in terms of triage and what our priorities are, at least for those of us that are funded by Adafruit to work on Sucker Python. We go by these milestones. We have two open issues for 7.3x and 45 for 8.0. And no issues not assigned to milestones. So that's pretty good. We do, we'll definitely want to triage those 8.0 ones because that's a lot to do before we have a stable release. So we'll have to decide on those later. But for now, we're early enough in 8.0. It's not super urgent. Okay. And with that, I will hand it over to Katnip for some numbers about the libraries. Thanks, Scott. This section applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit underscore circuit python underscore as well as a few extras, including the community bundle and our cookie cutter. Over all of those repositories, we had 11 pull requests merged by five different authors and five different reviewers. Of those merger pull requests, one of them was 113 days old. So I'm really glad to see that we're still getting through older PRs. And that leaves us with 24 open pull requests. We had 10 closed issues by seven people and five opened by five people, leaving us with 639 open issues. 184 of those are labeled good first issue. If you're interested in contributing to Circuit Python and the Python side of things, check out circuitpython.org slash contributing. It has all of this information and more, including a detailed list of the open issues. If you're looking to contribute to, by reviewing, check out the open PRs. Leave a comment if you have the hardware, test it and let us know. All of that is helpful. And then we can talk about leveling you up to our review team. If you're looking into contributing in terms of code or documentation, check out the open issues. You can search them by label. Good first issue is a great place to start if you're new to everything. We also have a guide on contributing to Circuit Python using Git and GitHub, which will definitely help you out if you're new to either of those. And we're always available on Discord to help. So don't be intimidated by the process. We want to make sure you can contribute in a way that works for you. In terms of library updates in the last seven days, all of them were updated, which is why the list is way too long to include, as said in the notes. We did a couple patches and it led to two sweeping releases across all the libraries. So not any huge deal that happened, but that's why it shows if you check the stats that every library was updated. That's what I've got. Awesome. Thank you, Kenny. I think we do need to make an Eva bot at some point for doing releases too. Okay. Next up, we're going to ask Maker Melissa for an update on Blinka. Hello. So Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week we had two pull requests merged by two authors and two reviewers. There are currently four open pull requests amongst all the repositories. And there was one closed issue by one person and went open by one person, leaving a net of 75 open issues. There are 8,588 PiWheels downloads in the last month. And then we are currently supporting 89 boards. And that's it. Awesome. Thank you, Melissa. Okay. And that's it for the state of Circuit Python libraries at Blinka. Our next section is hug reports. This is the first of two round robins that we do where I will start and then I'll go through the list of folks in the note stock. If you're marked as text only or lurking, I'll read the notes off. Otherwise I will call on you and you can unmute and read things off. So hug reports is a chance for us to say thank you to folks for the awesome work they've been doing within the community. I will start and then we'll go down the list. So let me take another timecode. It's hard. I don't have my numbers labeled on my keyboard. So sometimes I have to think about it. Okay. First up, hug report to Shyamaloon for a bunch of additions to the check translations. So that's been awesome. Hug report to Gambler for many contributions and reviews. Hug report to Dave Putz for the pulse and rework and the rework test and review. And a hug report to Kurt E for the Espress FURT fix. And next up, we have Notestorm C Grover who says group hug. And now we have Dan. Okay, thanks. So thanks to Artiley who, as Scott mentioned, is a new contributor. And PR turned on collections.deck, DEQUE in circuit Python, which was the thing we should have done a while ago. So thank you. And then a group hug for everyone who's working on library fixes and enhancements. My inbox is filled with library changes and PRs and reviews, it's wonderful. Okay, thank you. Thanks, Dan. Next up is FOMI guy. All right, thanks Scott. First hug report this week for Dan for making the new beta release as well as a group hug for everybody that contributed. Hug report for a GitHub user mu-cx who found a specific issue with some of our example code that had indexes for weekday names that were different than the way that CPython does it and submitted a fix for one of those. Hug report for TechTrick for helping resolve an issue that came up in a test case inside circuit with the change that I made last week. And lastly for me, a hug report this week for Kmatch who made Bitmap Tools rotozome actually quite a while ago, but I've been playing with it a lot the last few days and continue to find new and interesting things that it can do that I didn't quite know about. So thanks to Kmatch for that. Awesome, thank you, FOMI guy. Next up is Catney. All right, first up hug to TechTrick and Eva for adding scripts to the new tools directory in the Adabot repository. Both of them have been doing a lot of library updates and both of them have developed tools to help with things that the Adabot patching software can't do or that if it misses something or skips something, how to do the cleanup following the patch. So both of them came up with their own tools and they seemed really solid. So I decided we should actually add them to the Adabot repository so that in the future, if other folks want to be able to do these things, these tools are available. To Jerry for continuing to help with my mailbox project. To Mark Gambler for going through the mailbox code with me and providing some pseudocode to illustrate his ideas. And finally to Dan for a nice chat and for adding some ideas to the mailbox project as well. And that's what I've got. Awesome, thank you, Catney. Next up is Maker Melissa. Hello, I just want to give a group hug to everyone. Thank you, Melissa. Next up, I have notes from Mark who says a hug or words to Dan H for a quick answer about doubles and circuit Python. Next up is Tammy. Hello, I just have a group hug for everybody this week. Sweet, thank you, Tammy. Okay, next up is Tech Trick. So, my first one is for all of the maintainers and the regular contributors that have made contributing to circuit Python fun and meaningful and who got me to this point recently. New, new, really, really new is that I'll be the eight of the sponsors who work on circuit Python part time. So, thanks to everyone who got me here. So, Foamy Guy who originally organized and manages the type annotation PRs that originally got me hooked into contributing regularly to Catney who has always had a bunch of library improvement projects and those have kept me going. And for trusting me still to this day not to squawk and rebase anything accidentally, of course. Everyone who I've interacted with so far in the community it's really awesome to just open up the laptop and start working on things and chatting with people. It's the community is by far my favorite part. More technically, this week, thanks to Dan for helping me figure out why my Bluetooth, my Blufruit Connect scripts weren't working. Turns out you can't send, I think it's more than 20 bytes in the app and that was driving me nuts trying to figure out where there's a bug in my code. I'm sure there are, but that wasn't it. And a group hug. Awesome, thank you, Tektrick. And congrats on the part-time sponsorship. All right, that's it for hug reports. Next up we have status updates. Status updates is also around Robin, but this time we want to hear kind of what you've been working on in the last week and what you're working on in the coming week. Although I tend to not structure it that way. So I will start for my own update. I merged in the translation changes, including optimizing the translate function and stuff, but I can't remember if I said that last week so I thought I'd mention it. Just about ready with auto Wi-Fi changes. So it's behavior depends on .env file, so it should be backwards compatible. Basically, if you have your Wi-Fi credentials on the .env file, Circa Python will join the Wi-Fi before user code starts, generally. This is a prerequisite for Web workflow stuff because we may want to be on your Wi-Fi while user code's not running. That change also includes terminal IO support for the title bar and changes to the default display IO group that adds a title bar tile grid. So whereas what we used to do is we used to position Blinka in the upper left and then the terminal to the right of it unless it's tall and then it switches around. But basically now what you'll do is you'll get Blinka in the top, you'll get a text or a tile grid next to Blinka that is the title bar. So it's not scrolling text and then below it is all of the scrolling text. And the nice thing about that is that it's a place to put text that you know that will always be on the screen. And in this case of this auto Wi-Fi stuff, we put the IP address of the device there or the Wi-Fi status and IP is the interesting bit. I'm running into some code size issues that I'll need to resolve before it gets merged in. And then the next step is to work on the basic HTTP server that will be kind of the foundation for the Web workflow. It looks like we'll need to add in polling to the sockets which is kind of unfortunate, but we have ways of doing that if we need to. So basic HTTP server will do some redirect stuff, some host name checks, some super basic authentication and then you'll be able to push, pull, delete files and also get connected to the serial output over a Web socket if all goes to plan in the longer term. Okay, so that's my status update focused on the Web workflow stuff. Next up we have notes from C Grover that I'll read off. C Grover says, I made progress with the display IO based RGB matrix brightness slash gamma class. It works nicely for predefined display IO objects such as bitmap palettes, labels and shapes. Still running into issues trying to get the class to autonomously discover objects by walking the display IO group tree. Also found that creating a modifiable display IO palette class object through inheritance is problematic. Not all of the needed base methods are revealed after instantiation, a head scratcher particularly given my skill level. Lastly, we'll continue work on one, gaining a better understanding of display IO group tree attributes and two, defining and describing the palette type inheritance behavior. Even if the answers are not found there are acceptable work rounds. The current version of the matrix brightness tool process can become very useful. Thank you, C Grover. Next up is Dan. Okay, so as mentioned I released CircuitPython 800 alpha one. It's not a milestone so much as just a snapshot of all the changes since we forked 73X from the main line. So we just try to keep, every few weeks we try to get a release out. I've been spending most of my time debugging problems with ESP32 SPI, particularly on the matrix portal. It seems like there are at least two different problems. One is related to RGB matrix in particular and the way it works internally. And the other is some other problem which has to do with the airlift co-processor not responding after a while. Maybe when it's getting commands too fast or something it's not really clear. But there are two different things going on here. Like I can reproduce the second problem without using RGB matrix at all. So I'm gonna be working on trying to make RGB matrix work better and then also look at the other problems. Okay. Thanks, Dan. All right, next up we have notes from Dexter. Dexter says, working with Blinka on the Pi Zero W, 1.3 inch TFT joystick bonnet and trying out 8.0 and MDNS on the Funhouse. Next up is PhonyGuy. All right, thanks, Scott. Last week I updated SirCup in order to make it recognize and install libraries on builds of SirCup Python that are 8.0 or newer. So any of the builds remain or now the newly released beta version. I started creating example codes to illustrate some of the stuff that bitmap tools can do. We've amassed a collection of interesting manipulation functionalities but there's not a ton of documentation code like example code out there. So I'm trying to create some more of those to share. I created a kind of a reaction speed game with a NeoPixel strip where the light will bounce back and forth and there's a big button that you have to press. You try to press the button in order to stop the light in the middle. So it kind of tests how fast you can recognize it and click in the middle and then it just speeds up each time so it gets faster and faster as you keep going. I took that to a little art fair event locally here over the weekend and had a couple of folks played it and enjoyed it. I talked with some of them, especially a couple of kids who played it the most about some different improvements to make for that so that was a lot of fun. This week continuing some bitmap tools examples. I still have a few more things inside the rotazoom function and then a few more other functions to build out examples for. This morning I did some refactoring in a PR for the iter tools library to make it mimic the CPython kind of like format better. I have some touch sensors or like touch breakouts, capacitive touch breakouts on the way to do some testing on the NPR one to one library to check on a specific kind of type annotation syntax and how it relates with Npy and if it can run on the microcontroller. And then lastly this week, I know we still have some older circuit path on six compatibility code for on this bitmap specifically that is sprinkled around learn guides. So I figured I would start going through some of that stuff. Now that we have beta eight out there, I figured it's probably time we can start getting rid of the circuit Python six fallback stuff and just go with seven as the main implementation for stuff. So I'll be working on that this week and that's what I got. Thank you. Awesome. Thank you filming guy. Next up is catney. Hello. Last week I published the QDPyPico guide. This is an ESP32 chip. So at the moment there's no circuit Python support but there obviously is Arduino and micro Python support. So the guide covers both of those. Check that out if you picked up one of those boards. I started a GitHub profile guide. The idea is how to make your GitHub profile memorable and representative of you. There's a ton of tools available which I narrowed down to eight out of probably 200 that were available in one place. And I'll be highlighting those tools and updating my own GitHub profile in the process so that the guide shows it in action as well as explaining where you can find this information. And also talks about what kind of information to add because not everybody knows what to add to a profile. I certainly struggle with that. So that'll be good for me and also good for anybody else who struggles with that. And then the next guide I'm doing is a GitHub action status tower light guide. I have this little USB tower light and I'm gonna have it match the GitHub action status of a repository, probably circuit Python. And so the colors will match the status colors. And then otherwise, I lost Friday to taking my cat to the vet. The blood work came back significantly improved from last time. She has kidney disease and we put her on kidney food. And the blood work is apparently excellent now. It just turns out she's very dehydrated and now she needs subcutaneous fluids daily. So that will hopefully not turn into an ordeal. But that was a whole thing that happened at the end of last week. This weekend I went to Motor City Pride. That was a lot of fun. And then as well, I got the mailbox project working again, but I need to rewire the read switch to the opposite direction from the current one for it to be working properly. We'll be scrambling this week to make the code do what I want it to now that I have the basic code working and I'm definitely going to get some help with that. And finally, my talk was accepted to Pi Ohio. So once I get through the mailbox project, I'll begin to prep for that. Recording is due on July 17th, if I remember correctly. So I have a bit of time but I'm also really, really, really good at leaving everything to the last minute. And that's what I've got. I feel you. I feel you in that. Awesome. Thank you, Catty. Next up is Maker Melissa. Hello. So for me, last week I worked on the SMTPE external driver for the touch screen driver for the Raspberry Pi and making some progress on that. I tested the TSC 2007 touch screen driver and some more and found my hardware wasn't passing some of the basic tests as possible. My touch screen was damaged in storage. Anyway, I have more hardware now, it's working great. This week will be a short week for me and I'll be out in the next couple of weeks for foot surgery and recovery. And before that, I'm going to continue working on the touch screen stuff and go through any guide feedback and there's time I may look at some of the HT16K33 issues. And that's it. Awesome. Thank you, Melissa. Okay, next up is Tammy Makes Things. All right. So last week I didn't do any of my Twitch streams because of a combination of work stuff and a recurring internet outage in my neighborhood that has been ridiculous. I've had six multi-hour internet outages in the last two weeks. So thankfully I have a new internet provider now. So hopefully that problem is solved. I figured out how I need to fix the graphics rendering test that I did for my CircuitPython card deck library. So the next time I stream, I can fix that. And on Saturday, I attended the desert pie Python meetup and spent some time chatting with some other hardware interested folks and singing the praises of CircuitPython. This week, now that my internet is working again, I wanna get back to streaming and adjust my streaming schedule a little bit to be better aligned with my work schedule. I wanna keep working on the card deck library and specifically now that I'm into the graphic rendering stuff, I wanna get some progress on that, maybe work on some other pull request reviews if I have time. And I've been invited to give a demo of CircuitPython at the next desert pie meetup in early July. So I need to start figuring out what that would look like and planning for that. And that's what I've got. Awesome, thank you, Tammy. Do you mind disclosing who your new provider is? I switched to Verizon 5G home internet and it's astonishingly fast and so far much more stable than Cox has been. Yeah, very interesting. I'm getting almost 500 megabit downlink and I'm getting about 175 megabit uplink on average. Wow, that's awesome. I hope it stays that way. I'll be curious to see, you know, in my non-CircuitPython world, I've been interested in broadband. Yeah, I will be too, but it's also has the advantage of being $100 a month cheaper than what I was paying Cox for continuous outages. So. Yeah, that's pretty wild. Yeah, we'll see how it goes. We're spoiled here. You can get Fiber for about 65 a month. Oh, nice. Yeah, I would get Fiber if I could, but I can't get it in my neighborhood, so. Yeah, yep. You guys need to get on that. Okay, thanks. Thanks for indulging me. For sure. Okay, next up is TechTrick. TechTrick. Yep. So last week, as mentioned, I added the new RIP to Inovot. And as a bonus, I need them all platform and tool-individed scripts previously they relied on the GitHub command-lining interface, which is great, but not, but requires additional installation. That's a little bit, you know, more convoluted. So secondary thank you to Pi GitHub and GitPython projects for making it really easy to write Python scripts for who came up to GitHub and use Git, respectively. They're fantastic. Also fixed the libraries affected by the Eight of Fruit Logging update that happened, I think last meeting, so there was some cleanup from that. I also started working on removing gamepad shifts, as mentioned, just going away in CircuitPython 8 from one of the Learn Guide examples. As far as I know, there are two more, and this is one of them. So I am gonna try to get that out of there. And then also as mentioned, I continued working on the image transfer for the Blue Connect library. It's implemented in Arduino, so trying to get it in CircuitPython. So this upcoming week, I am hoping to finalize that if it really gets something working. I'm not able to send data, but getting them to agree on it is a little more complicated than I thought. Additionally, I have a few GitHub issues that I've opened over the last few months, so I'm gonna try and burn those down this week, some of them are documentation and other small fixes, so wouldn't be nice to get that done. And then I feel like I've said this for the past meetings, but I feel some cleanup required from one of the eight of our patches that I have a list of, so that could be fairly quick, I just have to get on it. So I'll try to do that this week as well. And that's all I can have. Sweet, thank you, Tektrick. And that's it for status updates. The last section we have here is in the weeds. In the weeds is a chance for us to have any longer form discussion that we wanna have. We have two topics here, one I've added and one Mark's added. If folks have other topics, feel free to add them below mine since we're gonna take a little time here to talk about other stuff. So Mark, are you around or should I read it off for you? Yeah, I'm here. Great. So this weekend, just to bring everyone up to speed, I was playing with the GPS module I have and realized that it would make a good candidate for Async.io, the basics of the library has it calling an update constantly, which would fit that model sort of perfectly. So while I was already in there because there's a precision issue currently outstanding that I've got to fix for on my own, I was thinking about, well, can I add Async.io support? But I'm not aware of any libraries that have it today, that I could sort of use as a template. So what we talked about in Discord this morning very briefly was to create a second library, basically, or file. I just put, for example, Adafruit, GPS, Async.io, just for example. And then the primary library could support the Async.io one. It could just be a subclass wrapping the primary class. But my assumptions with this would still exist in the same MPY file and the same repo, but I'm not sure if that's a correct assumption or if that's how Adafruit would kind of like to see this done. And so I'm just looking for any comments or concerns, questions. I would do it as a completely separate repo. And if you need to depend on the original one, then it would be a dependency. And the thing about Async is that typically what's going on is that some low level retreat routine has to be declared Async. And then because Async is infectious, Async def is infectious, then it goes up the chain from that. So I had worked on making an Async group. I have like a rough draft of an Async version of Adafruit requests. And 99% of the code is the same, but there's no way to refactor it to not, it's kind of, or you know, I could kind of refactor the utility parts of it or something, it's really a nuisance. So. Yeah, and it kind of makes sense because I'm sure 99% of this would be reused, but also 99% of it is pretty much never gonna change. Yeah, I mean, if you think about, you can say like, well, I'd like to duplicate the original API, but you could think about, is there some restructuring of the API that would be different? I don't know. Or if you take the original API, which is maybe a little too high level or something, could that be broken down into something that you could call? Yeah, GPS is a pretty simple example. Yeah, yeah. Compared to requests for sure. Tetrick in the chat just posted, is it possible to have a fork at the current library so you can pull the feature updates easily? That's an interesting idea, yeah. Yeah, I think that's a good idea. Yeah, yeah. The same thing is gonna be true of requests, yeah. So I'd be interesting to, I haven't had, I don't have time to work on the requests right now, but I think it would be interesting, that's a better first library to look at than requests. So if you, and you could look and see whether, I mean, I would also look and see whether you see some similar like CPython libraries that are async. There are many request style libraries that are async in CPython, but they're big. They're really complicated, like AIO, HTTP, AIO, HTTP, or there's some other ones too, ASKS, I think. So maybe see if there's some lower, some simpler libraries that are also async and see if there's some way of rethinking the API that would be easier. That's all I could suggest. Yeah. Hey Dan. What? Yeah? Yeah. Maybe to structure it so you can figure, in terms of trying to figure it out. Couldn't you make it a, couldn't you turn the async, the DPS library into a package and then make async a separate section of it? Yes, we could do that. And that's what I originally did in requests, but there's still possibly a lot of code duplication and it takes up space. Yeah, okay. Yeah. Got it. That makes sense. Yeah. Because if the, however it's the changes to make async work might not be that small. Right, exactly. Small enough to get away with that. Okay. Yeah, yeah. Unfortunately it's like this, not an add on. Yeah. One thing I did point out for Mark earlier that I bring up here is just that, I think it's safe to assume that async stuff is gonna run on larger ports or larger boards. So it's okay to have like the async stuff reference the original library, but I wouldn't do the reverse. Okay, that makes sense to me. Maybe I'll take a run at it and see how it looks like. Yeah, yeah. I think it would be interesting. No matter why you'll learn something. I hope you communicate what you learned to us. That'd be great, yeah. Yeah, for sure. And just so you know, Dan, I looked at that precision error. So I also want to try to PR that one in. Because yeah, that's just a float limitation. Yeah, yeah. Okay, good. I do think, Mark, that you're exactly right. This is a good test case because I do see a world where we have a lot of async libraries for folks that want to live in that world. The other place to look is maybe look in MicroPython and see what they've done. Because they're definitely ahead of us in the async world. Yeah, that makes sense. I'll take a look there too. I haven't really looked into it a whole lot besides yesterday, so. Yeah. Ping Jimmo from CircuitPython Dev, and he might have some thoughts for you too. All right. Cool. That's it then. Thanks. All right, and last up, I just wanted to make a note and tease folks. Since I've kind of like heads down on this web workflow stuff, I think it's time we could think about adding ESP32 support to CircuitPython. Kind of in the same vein as our C3 support. So if there are folks here that like working in Expressif and have a bunch of ESP32 boards they're interested in supporting, now's the time that we could start merging that in, I think. Any folks have comments about that, or? What is the, like on a vanilla ESP32 board, is there some sort of standard flash size? I was just curious. That's a good question. Like if you took like. I don't know. Yeah, like what is it there? There are all these like jelly bean sort of ESP32 boards. Maybe there's no consistency about how much flash they add. Well, you should probably look at the ESP modules, right? Yeah, yeah, that's a good idea. So if we just pull up. Like even the module, like the module we use for the airlift is. We could just support certain boards like Whippersnapper does. So we use a room 32. I can't remember. The room is without extra something, right? It's without PS RAM, I think. Okay. Don't they have a product? And some of these modules are actually marked as, like not recommended for new designs, but that might be true of all ESP32, I'm not sure. I think it would be good, maybe not to do specific boards like Melissa was suggesting, but maybe have minimum requirements. Yeah. Like minimum this much flash. I mean, you might be able to make a generic build, which might save a lot of. That's what Microbython does, and I really don't like that approach. You know, like. I like specific stuff because then you didn't customize it. I know you're worried about how many builds we're getting. Yeah, yeah, of course I'm worried about that. We can solve that problem. Right. The Microbython situation is ultimately very confusing as well to new folks. Raise my hand here. Okay. Because I had to deal with it recently. And that single build thing is because of how we have provided things in CircuitPython since the beginning, it's awkward and it took me a bit to figure out that these two very different boards that I was dealing with used the same Microbython build. So I kind of agree with Scott. I would rather see more specific things. Well, what I'm thinking about is that, yeah, I'm thinking about people who have their own boards and it's great to have boards, a lot of boards, but if we get a lot of like, oh, I made six copies of this board for me and my friends, I'd really rather not spend the CI time on that on those. So I think if there's a generic build available to say like, oh, this works with a room module or something like that. Just say like, if you made a board that basically all it is is a breakout for the room. Use this build first or something. Cause a lot of boards are like that. They're like, oh, this is basically a carrier board for a module, so that's, and I think if we express it that way, that's fine, okay? So, but I agree, right. To not express it that way is confusing. That's the guy I want to ask. So I'm looking at their product selector, express as product selector, and there is one module, or maybe it's not a module, but there's only one thing listed with zero flash. That must be just the chip. Yeah. And then the minimum flash after that is four megabytes. Okay. Four, eight, 16. Well, that's pretty nice. Yeah. And it's 512 K SRAMs. That's nice too. So yeah, I think that's something. Oh yeah, type sock. Right. So that zero flash one will be paired with a flash externally. Do micro dev or unexpected maker make any plain vanilla ESP32 boards? I believe unexpected maker does. Like that, the original tiny Pico is. Yeah. The original tiny Pico I think is ESP32. Yeah, I mean, there's a lot of ESP32 boards. That's why this is pretty interesting. And like with the web workflow, I think it's going to be very cool. Right, right. So yeah, maybe we just say four megs. Like if you don't have four megs of flash, then the only way you're going to actually get that is if you've used a chip, use the chip yourself and put an external flash that's smaller than that. Cause all like this list on from Expressive still has lists all their older modules as well. And they had fours too. Cause I think there's one C3 board that has two megabytes. So we should just say like four megabytes. And that's more like because the C3 is kind of like the ESP8266 replacement. Yeah, that's true. There is a C2, I don't know, did you hear about? I saw that. I did see that. It's not really available. Yeah. It's going to be more interesting when we can get our hands on these chips. There's also, they've announced like a C6 that does Wi-Fi 6 as well. Oh really? And an H3 or something. There's more coming, but it's really a matter of what we can get our hands on, I think. Anyway, that's a T's. It's something I'd like to do at some point, but first I want to get this web workflow stuff going first and then we'll do ESP32 if we haven't gotten to it sooner. All right, let me wrap us up. So thank you all. This has been the Circuit Python Weekly for June 13th, 2022. Thank you all for participating. If you want to support Adafruit and Circuit Python then those of us that work on Circuit Python who are paid by Adafruit, consider purchasing from the Adafruit shop at adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available in major podcast services. It will also be featured in the Python for Microcontrollers newsletter if it's adafruitdaily.com to subscribe. The next meeting, I believe is normal, let me double check. Yep, we'll be on June 20th which is a week from today at the normal time which is 2 p.m. Eastern, 11 a.m. Pacific. This meeting is held on the Adafruit Discord server which you can join by going to the URL adafru.it slash discord to be notified about the meeting and any changes to the time or day. You can ask to be added to the ad Circuit Python Easter's role on Discord and you'll get mentioned with notifications about that. With that, we hope to see you all next week and have a great week. We'll see you on the Discord. Thank you all. Thanks, everyone.