 Alright, hello everyone and welcome to the Circuit Python Weekly for May 10th, 2021. This is the time of the week when we get together to talk about all things Circuit Python. I'm Katny 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 at any time by going to adafru.it-discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2pm Eastern, 11am Pacific, except when it coincides with US holiday. If the meeting time is changed, we'll notify you via Discord. If you wish to be notified of the changes to the meeting, we can add you to the Circuit Python East as Discord role. There's also a calendar available that we try to keep updated if you would like to subscribe to that. This meeting is recorded. We record audio from the Voice Channel and video of the Text Channel. If you'd rather not have your voice recorded, you are still welcome to participate. A video of this meeting is posted to YouTube and the audio is released as a podcast. If you find that this podcast is not available on your favorite podcast service, please let us know. There is a notes doc to accompany the meeting and recording. If you wish to participate but can't make the meeting, you can leave hub reports and status updates for us in the document and we'll read them off during the meeting. The notes document also contains time stamps to go along with the video that you can use the doc to view only the parts that interest you most. This meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. A link to the notes document is posted to the Circuit Python Dev Channel on the Adafruit Discord every week. Check the pinned messages to find the latest doc. This meeting is held in five parts. The first part is community news. A look at all things Circuit Python and Python on hardware in the community. It is a preview of our Python on microcontrollers newsletter. The second part is the state of Circuit Python, libraries, and Blinko. This is 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. Hug reports is an opportunity to highlight the good things folks are doing and taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to, take a couple minutes, and talk about what you've been doing in the last week since the last meeting, and what you're going to be up to over the next week until the next meeting. The fifth part is in the weeds. In the weeds is an opportunity for more long-form discussions. These discussions can come out of status updates or be something you've identified ahead of time is too long for status updates. And that is the meeting. And with that, I'll find my place, and we will get started with community news. So first up, celebrating Mother's Day by making. There is, thank you, guys, for getting the links, an animated flower running on Circuit Python LED animations example on Raspberry Pi Pico. Next up, Melanie McDonough made a Mother's Day project using an Adafruit mag tag with quotes from Glennon Doyle's book Untamed. Next up is KeyCAD 5.1.10 was released. The project announced the latest five stable series. The stable version contains critical bug fixes and other minor improvements since the last release. Next up, there's a video of running Circuit Python tests and fixing the resulting bugs. In Circuit Python, there are thousands of tests that verify the correct behavior of the core interpreter code. Here's a quick peek at how it looks to run those tests and one bug we recently discovered and fixed things to the tests. Next up, Circuit Pythonista and Barela interviewed by Embedded FM. Circuit Python team member and newsletter editor, Ann Barela, was interviewed by Alicia and Christopher White on Embedded FM for issue 372, the motivation of creativity. In the podcast, Ann discusses her work with Adafruit to include tutorials, authoring two books on Adafruit products and being retired from a 30-year career in engineering in the U.S. Foreign Service. And finally, at least for us and not, this is, like I said, a preview of the Python for Microcontrollers newsletter, the Python programming language repository migrates to Maine on GitHub and there is a blog post about that on Adafruit. The Circuit Python weekly newsletter is a Circuit Python community-run newsletter emailed every Tuesday. The complete archives are available at adafruitdaily.com slash category slash Circuit Python. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python, and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub, submit a pull request, or you can tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com and that is community news. Next up is the state of Circuit Python, the libraries and Blinka. This is an opportunity to take a look at the project by the numbers. We'll talk about it in a few sections. First, we'll talk about it overall. Then I will turn it over to Scott to talk about the core. I will talk about the libraries and this week I will be talking about Blinka as well as Melissa is otherwise occupied. So let's get started with that. Overall, and this applies to, like I said, the Circuit Python core, all of the Circuit Python libraries and Blinka as well. We had 72 pull requests merged by 27 authors. There's a few names I don't recognize. Rodrigo Argumendo, RENPAI Tom, JSAVSM, TWA 127. Those are names I don't recognize. There may be others as well. And we had 15 reviewers, which is excellent. In terms of issues, we had 47 issues closed by 18 people and 17 opened by 13 people. So we are very much net down by 30. I did that math right. And that's how we're looking overall. So with that, I'll turn it over to Scott to talk about the core. Thank you, Ketney. Okay, numbers for the core. We had 27 pull requests merged from 16 different authors. Thank you to all of our authors. I will read those off. We had eight reviewers. So thank you to all eight of you. We really appreciate it. We have 19 open pull requests. A few of those are quite old. So hopefully we'll get a glance at those sooner rather than later. But a number of them are also new too. And we're below 20. So I think generally we're doing good. We just have to, if anybody wants to help out, picking up an old pull request is really helpful to get those numbers down. And there's some good stuff in there. That's why they're left open. So if you need help kind of getting your footing in a new PR, let me know. But I think a lot of these old ones are just like looking for a person to give them a little TLC and get them checked in. Issues-wise, we had 11 closed issues by five people and eight open by six people. So we're in M3, which is good. Generally, we are tending upwards slowly. We have 443 open issues right now. And we have five active milestones. Milestones are how we keep track of what issues we've triaged and then kind of on what timeframe we expect them to be that we expect them to be resolved. We have three open 6XX bug fixes, which I know Dan is kind of Dan is on vacation until tomorrow, I think. So when he gets back, I think one of his things is is starting a bug hunt, which should be really good timing for us to get 7.0 stable. And then we have 56 open issues under the 7.0 milestone as well. I think we are planning on doing a 621 or something in the 6XX series so that we don't have to wait for 7.0. But that doesn't, we should still continue to get 7.0 out the door as soon as we can. So I bled into the overall sort of thing, but overall we're getting close to a 7.0 alpha, which is kind of like the point at which we've kind of stabilized enough that nothing super major is going to change in particular the NPY version. We don't want to change again. MicroPython 113 is merged in, 114 and 115 should be doable this week. The dynamic USB descriptor changes are merged in and please try those. And the status LED revamp is out for review as well. So those are kind of like all the things that could be pretty major changes that we wanted to do with 7.0. Now's the time if you want to help take a look at the issues list. I think there are things either tag 7 or tags breaking changes that we should make sure and do in 7.0, unless we're actually trying to wait for 8.0. So we're getting there. It's all good. Please try main and find issues so that we can really get 7.0 stable as quick as we can. All right. Thanks, Scott. Next up is the libraries. So this covers all of the Adafruit Circuit Python libraries, which is adafruit underscore circuit python underscore library name. It covers the bundle, the community bundle, and a couple other extras as well. So overall, across all the libraries, rather, we had 31 pull requests merged from eight different authors and 11 different reviewers, leaving us with 61 open pull requests. We had 22 issues closed by 11 people and 8 opened by 6 people, leaving us with 304 open issues. Six of those are labeled good first issue. If you are interested in contributing to Circuit Python on the Python side of things, go to circuitpython.org slash contributing. You'll find all of this information and more. You'll find open pull requests, open issues, and some library infrastructure issues, as well as how to contribute to translating the Circuit Python core. You can search the issues by label. If you're new to everything, good first issue is a great place to start. If you're looking for something a little more complicated, bug or enhancement is an excellent thing to search for. And with any of the pull requests, if you're interested in starting to help out with reviewing, feel free to comment on an open pull request. That's a great way to start with reviewing simply to check the code, see if it looks right to you, if you have the hardware, test it, and let us know that you did that. And once you're more comfortable with it, we can actually upgrade you to joining our review team, at which point you'll actually be able to submit official reviews and merge PRs and so on and help with the whole process. And the more reviewers that we have, the more authors we can support. So it's a very important part of the process and it's something we're always looking to see more people join up with doing. In terms of library updates in the last seven days, there were no new libraries, but there is a list of updated libraries in the notes. And I see that I did not actually do my little overall thing here. Overall, we've been seeing a lot of documentation updates. I think that that is starting to come to a point where a lot of the documentation updates are done and that's been great to see. I know that there's been quite a few contributions to the community bundle none this week, but I think last week we saw at least two or three new libraries added to the community bundle and we're always looking for stuff like that. We're working on moving some libraries over to the Circuit Python organization on GitHub. And once we do that, we want to integrate the issues and open PRs and that sort of thing on those libraries onto circuitpython.org slash contributing. So it'll still be a one place to go to find all that information if you want to start contributing, you won't have to search around to figure out where to go. So that's I think next step on our list of things to do is to get all those things that we're moving over to the Circuit Python organization settled in their new home and then get everything set up so that people have access to it where it is. And that's about where we're at with the libraries. Melissa's still out so I will go ahead and read off the Blinka stats as well. Blinka is our compatibility layer for Circuit Python running on single board computers such as Raspberry Pi. There were 14 pull requests merged which I believe is a huge number for Blinka. With three reviewers, there are five open pull requests at the moment. In terms of issues, there were 14 closed issues by five people and one open by one person leaving 52 open issues. In terms of Pi PI downloads, there were 9,933 and currently there are 72 boards supported by Blinka. And that is the state of Circuit Python, the libraries and Blinka. Next up is hug reports. Hug reports is an opportunity to call folks out for doing awesome stuff. It's a chance to highlight the great things that people in our community are doing and just a chance to say thanks for anything that you've seen either stuff that you've seen other folks doing or stuff that other folks have done for you, etc. This section is held in a round robin where I will start and then I will go down the list alphabetically. If you are in the notes as listening in or text only, I will read off your notes. If you are in the notes and you are available, I will call on you when I get to you. And yeah, that's about how hug reports goes. So I will get started. First up, I have a hug for Foamy Guy for always stepping up to update things where needed in guides, etc. Thank you to Jose David for continuing to update documentation across the libraries. To Phil B for helping me with some illustrator weirdness. And to Phil and Adafruit for donating to the PiLadies auction at PiCon this year and for sponsoring PiCon. Next up is Kmatch. Hey, thank you, Katnie. First hug goes to Scott. Thanks for all the encouragement and guidance on the Tiny Logic Friend project and also for highlighting it on your deep dive this past week. Thanks to Stargirl, Jerry N, and Mateus for some guidance on extracting Neopixel driving code out of the bootloader and getting it running on the M4 boards. So I appreciate the help and guidance on debugging. Thanks. All right, next up I have some notes from folks. First up is notes from Melissa who says a hug report to Jeff for reading the Blinka notes last week. Then next up I have notes from Mark who has a group hug. And finally, I have notes from NaraDoc who is text only who says a hug report to Hugo for testing the Serial Interface Discovery Tools on the M1 Mac to Dan H for dynamic USB work and all the support and answers to Scott for all of the MicroPython merging and merging and merging into AnikData, Jerry N, and all of the Help with Circuit Python gang. Next up is Scott. Hello. First, a hug report to AnikData for adding the AP mode to the ESP32 S2. I think that may have fallen under the radar and I think folks who are using the S2 will be really excited about that. So thanks to AnikData for that. I thank you to Katnie for covering for the newsletter and then jumping right back into running this meeting. Really appreciate it. And a hug report to my partner Minigree for helping me with pandas and Python data science stuff this weekend. It was a whole new world for me. All right. Excellent. Next up, I have notes from a bunch of folks as well. First up from Charles Burniford, a group hug. Next, I have notes from Dan, who says to Jerry N and Naradoc for testing USB and USB HID fixes to Naradoc for debugging the M1 macOS issues even without an M1 and to Hugo for help in testing and dumping out data for Naradoc to review and to Scott for API discussions and review of the dynamic USB PR. Next, I have notes from David Glauda who says a hug report to FOMI guy for whatever magical thing was shown on show and tell that push an image that you do in the browser to a Pi portal to Kmatch for tiny logic friend contribution and to Naradoc for help at 4am on board.display equals none and the trick which is if not has attribute board display, display.io.release underscore displays. And next up is FOMI guy. Alrighty. Thanks, Kenny. First up this week, thanks to Jeff for integrating the library screenshot maker in with actions on the learn guide repo. We got the first successful run this week, so I was really excited to see that all in place and running. Thanks to PT and Lady Aida for giving me the opportunity to get more involved by making videos and blog posts. And then last one for me this week, thanks to Stephanie and Ann for helping me get set up on the blogging system. Great. Next up is Hier Effect. Hier Effect, I can't hear you. You're lit up green like you're talking, but I don't actually hear anything. How's it going? Can you hear me now? I can. Okay, cool. Sorry about that. I don't know what happened. Thanks to Dan this week for reviews of the new sleep stuff and bug fixes and things I submit this week. Thanks to Krupus, who is a community contributor on the NeoPix module for pinning down a kind of a little rare bug that could occur there. Thanks to Val Hall for finding and testing problems at the Esparino Pico board that so that was a good find, but totally broke the board and he picked it out. And thanks to Anak Data for testing all the fixes that went into the supervisor run reason problem this week. And that's it for me. Excellent. Next up, I have notes from Hugo, who says a hug report to Katnien Philby for the work on the pinout generator. Fantastic looking and bonus points for accessible colors and group hugs. Next up is Jeff. Oh, and I lost my place in the notes. So I want to thank Zoltan V923z for letting me know that there were some build problems between MicroLab and CircuitPython. We're going ahead at about a thousand miles an hour with all these changes, but those can affect their GitHub actions. So I put in a pull request there that I'll mention later. Thanks to you, Katnien and to Scott for covering the Discord meetings. Well, I'll be gone for a few weeks coming up. And also a group hug. All right. Thanks. Next up is Jerry. There's that mute button. Sorry. Thanks to Tan for all the work on the USB HID improvements. All right. Thanks. Excellent. Next up, I have notes from Jose David, who says to CodeNIO, Ali Mustafa Shah, Diwalex, GitHub users for making their first contributions in CircuitPython, to DHirata for all of the help this week, and to Anikdata, Naradak, and DanH for the help on defining precision timing for boards. And that rounds out hug reports. Next up is status updates. So status updates is a chance for us to talk about what we've been up to since the last meeting and talk about what we're going to be up to until the next meeting. It's an opportunity to sync up on what everyone's doing, but it's also an opportunity for people to provide tips and tricks, quick answers to questions, that sort of thing, depending on what's going on. And if something turns into a longer discussion, we can always move it to in the weeds. This section is also held as a round robin where I will start and then move down the list alphabetically, looping back around. If you are, I have notes in the document, I will, and you are missing the meeting or text only, I will read them off. Otherwise, I will call on you when it is your time. And that is how this will go. So I will get started. So last week, I finished up guide feedback from ages ago. I can't remember if I talked about that last week or not. We get feedback on guides through the feedback link. And it goes into a particular system. And I neglected to do anything with it for quite a while. So it built up. And so I finished all that. And that was good. Updated all the Adafruit RP2040 guides and the Funhouse guide with all of the existing templates. So now they all have blank status LED, I'm blanking on the others. There's four. Digital input with a button. And then created templates for CapTouch using pads or pins. So that will work for both, say, a circuit playground, or it's two separate templates. One for things like a circuit playground on Bluefruit where it's actual touchpads. And one for, say, the feather RP2040 where you're using the pins. And then also storage, which is writing to the CircuitPython file system. And then again, two separate templates. One for using a boot.py with two separate pieces of code. I think it's the same template. For using a boot.py using a ground pin or using boot.py using a pressed button. No, it's two templates. And those haven't gone into any guides yet. So they haven't been reviewed. But the plan is to update the RP2040 guides first with all the templates to get them deployed and then move on from there. Generated pinouts images for the RP2040 boards. Images have been uploaded to the respective PCB CAD file repos. So if you want to view what those look like, they were mentioned in hug reports. You can go to the PCB file, GitHub repos for the Adafruit, Feather RP2040, Itsy Bitsy RP2040, and QDPy RP2040. There are SVG files available there. So this week, I'm going to be working on the iSquared C rotary encoder STEMI QT guide. It's a new breakout board that's a rotary encoder that is got STEMI QT connectors on it, runs on iSquared C. It's super convenient. I'm going to, I didn't put this in my notes, but I'm going to go through, I distilled the list of circuit python boards, Adafruit circuit python boards that don't have a board dot led pin for the built in little red led down to the list, down to a list. And I'm going to update that. Shouldn't take long. But it's something that I think needs to be done because we're trying to make the code consistent. So blank code will use board dot led. And we need to have all the boards having that, or we're obviously going to be running into folks having problems, just like they're running into folks with running into problems with D13, because D13 is not on all of them either. So we picked more dot led to be the consistent one. And then I'm going to be doing some very simple preparation for pycon. I want to host an open space and some sprint stuff. But it's all virtual. And there's no guarantee folks will have hardware. So I'm not really entirely sure what that's going to look like. But that's on my plans. And then I'm also going to be continuing on template stuff. Friday, during Wednesday during the day, I will be unavailable because I will be attending the EDU summit for pycon. And then on Friday, the conference starts. And then Monday and Tuesday, depending on what sprints end up looking like, I'll be hosting sprints. So I will be here for next week's meeting, but I will obviously not be hosting as I'm hosting this week. But wouldn't have been available to host anyway. So that's my update. And with that, I will turn it over to Kmatch. Good. Thanks, Kenny. So I've been over the past several weeks primarily been working on a project called TinyLogicFriend, which is trying to make it easy to use these development boards as logic analyzer. So you can basically sniff signals between some chips and see how they're really talking to each other. And I got it to a point where I submitted my first pull request to a project called SigRock and PulseView. It's basically the software that can run on your computer or your PC that can help you visualize the signals that are coming back from a logic analyzer. So if that gets accepted, it'll make it easy so folks can use TinyLogicFriend boards since they won't have to compile the whole software. So that's in progress now. Also I built and tested the TinyLogicFriend firmware on three different of the Adafruit Cortex-M4 boards. And it's just as easy as putting it in bootloader mode and sliding over a UF2 file. So there's a few available there. And also, as I mentioned in my my my hugs, I learned how to add Neopixel indicators onto those boards. So I added that at least you'll have some sense of what's going on on the boards while it's measuring. As for this week, I want to see what it'll take to get the same firmware onto an RP2040 board. And there's actually some good starting points from Mark Comus or Gambler and another Mark, MarkB139, who've done a lot of work to use the RP2040 as a logic analyzer. So I want to see if I can integrate their code into the TinyLogicFriend driver so you can have a wider array of boards available as logic analyzers. And also want to send now that that pull request is kind of pending, maybe let that simmer for a while and get back to some circuit Python work, particularly looking at all the widgets that are in queue. So that's for this week. Thanks. Excellent. All right, next up I have some notes from Melissa to start with. Over the last two weeks, was out last week due to symptoms from second COVID dose, wrote a guide on creating Funhouse projects using the Funhouse library, updated guide with temperature logger example, wrote a guide on using the Funhouse motion sensor to turn a fan on and interface with home assistant, fixed Blinka to work with MicroPython using the Pyboard, added Raspberry Pi Pico support to Blinka running MicroPython, and went through and closed and merged many issues in PRs for Blinka and platform detect. This week, update some ink guides with the new monochrome ink bonnet, continue going over Blinka issues and start a new Funhouse guide. And next I have more notes from Mark Gambler, who says work slash life has been taking most of my mental energy lately, hope to be able to contribute more soon. Next up is Scott. Hello. So 113 has merged in, I believe. 114 and 115 are started. I've done the merge, and I think the tests are passing, but I kind of like couldn't finish them until the previous releases is done. So I'll shoot to get 114 out for review today. And then 115 will follow once 114 is merged in. They're both 14 and 15 are much smaller than the previous one, so I don't expect it to be too difficult. I made a PR for the status LED revamp. It minimizes how often the LED is on. So it's going to change the way that the boards look when they're running, but it will save power, which is good. And it generally has the philosophy that the LED only blinks when it needs something from you. So it should save power. I'm meeting with Damian and Jim later today for a chat, kind of like as the post-merge chat about maybe there are some things that we can upstream to MicroPython that makes it easier for us to continue to merge going forwards. That'll be good debate later, and I'll recap it next week, if anything interesting comes from it. Tomorrow, Wednesday are the Python language summit as part of PyCon. I'm presenting a lightning talk tomorrow late morning. It's just five minutes about comparing CircuitPython and CPython, which I'll talk about on my stream on Friday as well, if people want to see what that is. So I mean, I have to actually practice it today and make sure that the timing is about right. So that's what I'm doing today. Overall, it's an odds and ends week. Getting all these PRs in, being on calls a lot this week. Also have a call on Wednesday with Trevor and Antonio. Antonio is a contractor that does mobile app development that we work with from time to time. So Antonio is going to start working on the Beely workflow-y side of the mobile stuff along with Trevor. So we should see more progress on that hopefully in the next few weeks. So after I'm done with all these odds and ends, the next thing is doing the Beely workflow stuff in CircuitPython proper. So that's going to be really exciting. And so that's where I am CircuitPython-wise. And then I just thought I'd mention on the non-CircPython front, I've been listening to some broadband policy podcasts here in the US and had some back and forth on Twitter with the guy that does the podcast. And he said that what they really need is they need an open broadband availability map in the US, and in particular potentially with even a basic model for the cost of laying fiber to new communities. The background is that in the US here we have a lot of government money that's going to be going towards broadband. And so making sure that that data gets spent wisely is part of the reason that having a map like this would be really useful. So I started working on that. It was really interesting to do like data analysis, analysis sorts of things like joins and stuff and also getting back into map rendering things particularly with OpenStreetMap. So it's been quite interesting and I'm excited to push something hopefully in the next week or two about showing where fiber is and potentially how costly it would be to get it further out into other places. So that's my update. All right. Thanks, Scott. Next I have some notes to read. Starting with Dan who says finish the dynamic USB descriptors PR which was merged. There were some bugs and I have some PRs to fix in to fix those. Verifying that the Adafruit board toolkit is not working on M1 Max, which causes the board detection I added to MU recently to not work. Naradoc has fixes. I will set these in motion. Thinking about how to make some kind of recovery UF2 in case someone has turned off both MSC and CDC USB devices could be safe mode or other or could be a file system eraser. I have a draft PR but this is still a discussion topic and finally will be bug hunting for 6X and 7.0. Next I have some notes from David Glauda who says continue to work on thermal camera with one code that work on multiple hardware with various bilinear interpolation scaling and display IO scaling, PyPortal, Clue, MatrixPortal and Featherwing keyboard plus Feather S2 or Feather RP2040 and testing the new Pico to 0 version 0.4 with pull up resistor. And next I have notes from Fitted2. This is last week adding support for the latest risk 5 boards to Python platform detect and about to push changes to Blinka. This week continuing the translation of the circuit playground guide and stocking any missing translations via or to Spanish via web late API. Next up is Foamy guy. All right, thanks Kenny. For last week I finished up the majority of all the updates to learn guides to change from bus IO to board but there are I think one or two more that I need to finish up this week so that's my first item for this week as well. Back to last week though I created a short video that talks about the new requirement screenshot utility and I also started working on the changes in cookie cutter to add org into project names if you don't select a different prefix and while I was working on that I also fixed an unrelated thing that I had popped up or I guess quasi unrelated but it's the pip installation instructions that go into read me. Those were hard coded with Adafruit so I got a PR out there to fix that now as well. For this week of beginning spun up on the blogging system and writing my first post which will cover that video that I just mentioned. I will finish up the last of those learn guide bus IO updates. I will try to complete those changes in cookie cutter to add org and then I'm going to try to there were a couple of folks interested in that pipe portal screen design management thing so I'm going to try to polish that up and get it published somewhere online so that other folks can try it out on their own pipe portal. That's what I got. Thank you. All right, thanks. Next up is higher effect. Okay so this past week I fixed up some issues with the supervisor run reason as the reason returned when you first when you start up Circle Python and you check try to check why it started up. It should now correctly identify when it was opened by the REPL or the supervisor or an auto reload caused by like saving your file or if it's the first startup as opposed to just saying that everything was an auto reload which is what I was doing previously. I fixed an issue with the Esperino Pico which is neither an SESP nor a Pico but it's a very tiny STM32 board and it wasn't working so now it does. I did an overview of the Adafruit NeoPixel implementation based on some user feedback fixed a minor bug that could come up in some high performance cases. I fixed some issues in the RP2040 deep sleep implementation which should be up as soon as we get the eternal sleep revamp merged and I started up on reviewing the next startup file code which needs some minor changes before it can be put in and so I'll be picking that up which is one of our older PRs in the queue. This week I'll be reviewing Scott's new LE status LED code make sure it plays nice with all of the sleep module stuff. I'll be catching the STM32 alarm up to date for what feels like the bajillionth time it keeps getting messed up by all the cool new features we add. I'll be starting the merge process for the internal sleep and alarm revamp which actually should be a fair amount of work because it's going to involve all of the cruft cleanup for all of the ports that have had alarm merged and maybe had a little leftover issues so that'll take up some time and then I've got the setnext file PR to keep going on and finishing up the alarm power profiling so actually measuring how much power all these different boards with their new sleep modes actually use during sleep so how long will their battery life be what's kind of a typical use case getting all that documented and submitted and then for some fun stuff this past week I ported the first couple chapters of the Genki Japanese textbook into my um python circuit python uh flash card app thing so hopefully I'll have some something to show on show and tell for that with some hardware uh sooner rather than later that's it for me excellent thank you very much next up I have notes from Hugo this is last week work more work on rebranding including templating and clobbing helped out Dan H. and Nerida with the m1 mac usb serial diagnosis and this week finish up rebranding next up is Jeff hello again uh so last week and so far today I've continued helping out with uh mostly fixing tests during the merge process I did a couple of short videos for the ate a fruit blog um one was actually supposed to go out next week but they posted it up this week it's all good uh contributed a fix to find imports which is a python project they had a little bug handling files with a utf-8 byte order marker at the beginning that affected the image uh the circuit by screen drive screenshot the image maker maker so that's fixed now and it was fun to work with them on a new project I've contributed some fixes for obscurity compliance bugs to both micro python and circuit python worked on some build failures in micro lab and I worked on the nat mod examples those do all now work in circuit python with a patch um but I'm also understanding that nat mod is really limited in what it can do so it's not really a solution for expanding the capabilities of the low end boards and also because it needs uh space in the flash firmware so you'd have to take two things out to add nat mod and then maybe you could add one thing back so I don't think it's going to be super useful for the low end boards in circuit python um and then the other thing that I did this morning is the expressive colluga dev kit has its own camera and camera port and I got that demo running uh in the espidf there are some problems with the hardware the images are sometimes corrupted but hopefully now that I know the code works I will find it useful to study and possibly take parts of it for the python implementation so this week is more merge help if needed um and then out of these three we decided in the internal meeting that the next thing I was going to work on would be to work on the rgb matrix support for the esp32 s2 and I will be missing the next two Monday meetings my wife and I were taking a road trip I will be doing lots of walking and a little like light hiking near boulder colorado all right thanks Jeff next stuff is jerry hi so mostly what I played around a lot this week was just trying out the the new versions of 7.0 after the micro python merges on as many boards as I could and in most cases found very few very few issues things are working really well but ran into a really really puzzling but a problem with usb usb h id there was a problem that all sudden it started not working on on any boards I think but that that's now been fixed by dan and uh there's a pr pending um I think ready to be merged for that but as part of that um ran into another problem that still persists on um it started out on the perky m0 but since we don't like to talk about that board I found that I can reproduce it on the cpx on the circuit python express as well so that makes it a real problem and uh it has to do with some really bizarre combination of ir remote and usb h id at least I think so so you know it's probably not going to bother a lot of people and it'd be nice to get these mergers in and then try and figure out what this bug is it's a new issue been opened on it if anyone wants more details you can ask we can talk about it later but uh it's it's pretty obscure I think but it's there all right well thank you for finding the obscure bugs all right next up I have some notes from Jose David and Jose David says last week most of the time working on libraries open issues reviewing some prs from new folks reviewing the gyros excel libraries verify that we were returning standard um si units uh changes were made in three libraries this week continue working on open issues and reviewing prs and that is status updates so next up is in the weeds in the weeds is an opportunity for more long form discussions um things that don't really fit in status updates but that folks want to discuss uh the first topic is Jose David who I think is not in the meeting today so I will read it off um library size versus boards and then there's a link to an issue if somebody could post that into the chat that would be great censor libraries with a lot of features will raise a memory error memory allocation error in the issue above scott mentioned a possible check is this something still on the plan or do we mention as a caveat in the read me in some libraries such as and then another link um which I will post in a moment here if nobody does um another solution is preset some libraries with default values and avoid class build usage and all the registers in the libraries but maintainability of having two versions could be cumbersome comments or ideas I don't know if anybody has any comments on this I mean my my line in this has always been I think we should what we really need first is we need a system to measure how big the libraries are in CI because then we'll be able to actually tell how our changes are impacting things so that's I think that's what I mean by possible Jose is talking about with possible check it's just like we really should track it before we can expect to actually do a good job of of minimizing it um so that that would be my challenge as folks is like I think what we could do is we could have like a QMU build of circuit python that you load you do basically import and then you just see the GC stuff and I think one one thing that be really could be quite cool actually is like if we have that we could probably dump all the memory from QMU as well and actually build like a visual visualization of the memory taken by a module so I think like like I did ages ago for the the heap dump stuff so yeah I think I think that tooling is the thing that we need to really get us over this hump um I don't think that two libraries is necessarily what we want um although I could see like some sensors do a lot of different things and so I think one way to approach it would be that like I would you could split functionality based on functional lines of a sensor um because there may be like some things that you just simply don't need except if you're doing some more advanced things right I think generally you don't want just two libraries for different sizes sake yeah um but but if you did have like purposes different purposes for different things of a particular driver then I think that would be okay so um I know this is an issue it's an issue especially as we have new bigger boards and we also do more library development on Raspberry Pi it's just um it's inevitable and I think I think the the solution is is actually just exposing exposing and making it clear the impact of the changes to the drivers uh on the memory footprint so okay that that is a challenge that I pose to folks I don't have the time to do it myself right right do you mean making the effective libraries into packages so only the needed functionality is imported yeah that could be part of it yeah wait wasn't that what Simon got on and was talking about the other day I don't know or is that a little different where he was talking about like chopping out parts of the libraries to save space dynamically he was yeah he was talking about doing it um programmatically right like programmatically trying to figure out like different segments of code and and potentially also like I think it was unclear whether it was like take that data to inform how to split the code versus like simply post process all the code that you're running and delete all the code that just never gets called right I think there was the question of like is this happening at like load time or is this happening on developer time preemptively right and I think that I think there could be some some cool uses of like we could actually only load function bytecode once we know we're actually going to execute it like I think there are some interesting things we could do in circa Python to like lazy load things I think that his his context Simon was trying to work on a uh GUI and like a set of extension tools for circa mm-hmm and so he was thinking of this as basically being like something that's managed by a program running on your host computer right does all this optimization as you're working right to minimize the amount of code that actually has to be on your your file system on your device yeah and Hugo is pointing out it's called tree shaking usually yeah he is you know I mean yeah I the whole thing seems neat to me but it's not it's not something I know too much about but I know there was a lot of confusion about like what is this a runtime thing or a dev time thing right I think yeah I think you have to do it as late as possible because if you do it too early then you risk um code not working like you expected to work um if you're doing it on the host side and you copy the files over and then you're reading and you were like oh I want to use this property and that property is not there because you did the analysis before you were using a new property sort of thing that you zapped it um yeah I think there's some interesting ideas I just like it hasn't been a priority unfortunately okay sounds good um next is a topic from me two topics um first up I saw something go by about Sphinx being updated I don't I didn't look into whether or not we pin Sphinx or not um but seems like something we should probably look into I changed something with the Sphinx config for circuit by then core is that what you saw go by no no I I saw that Sphinx was just tagged like 4x like 4.0 oh yeah they released an update yeah um and I don't know if we that's why I'm saying I don't know it I did not look into whether or not we have pinned to some previous version or not um so there's two yeah one if it's pinned um we might want to look into updating too if it's not pinned we need to make sure all of our stuff still works the core is pinned at less than three okay I think which is kind of outrageous actually now that I realized that we were a version behind yeah um I'm all for keeping it up to date but I don't know how much of a task it would be to yeah I'll look into it I just wanted to put that out there um so the thing the thing that I changed was there's this um the the thing that does mark down to rst was called recombin mark and that was maintained by the redox read the docs folks but it's kind of stale and there was a there was an issue that was breaking the ci with one of the merges and it turns out there's now a my st parser package that people are now using instead of recombin mark and that's the official like recommendation from the read the docs folks too so I switched that over um with the 113 merge okay I will look into that for the libraries as well um and in that same look we'll figure out what we're running and what we want to do with updating and update it once and see whether or not we break everything and then move on from there okay okay sounds good uh thing two is um it was suggested that we add a template to the library pr's for those that don't know that means when you open a pr um on a library there's text in the text box for the pr um when you open it already and it's like prompts and that that's already the case on the core if you pick bugger um enhancement or whatever the two labels are um where it just it sort of helps you like know what to put in there but I think the bigger reason why it was suggested was so that we can put information in there about um pre-commit and uh running pilot and black on your code before submitting your pr um so far everybody I mentioned too it's been on board I just wanted to bring it up um in a also to verify the design guide yes it was Jose David that made the um that made the suggestion so uh basically the template would suggest you know make sure you're following this design guide make sure that you've run a pilot and black on your code um um it's go ahead I think it's a good idea but it also made me realize that I did that work to automatically follow up with a post if the ci fails correct and I don't know like I thought last I talked to Dylan Dylan was gonna roll it out but I haven't checked with them yet I don't think that's happened okay which is actually a good thing in the sense yeah is is that we could do both at the same time yeah um because it's it's a matter of adding a file to get the template in it's just a file in a in a directory I looked yeah so okay um yeah maybe doing them both at the same time would be good uh sounds good um keen all right that was what I had um thanks next up is follow me guys topic all right this is uh kind of follows out from the one that we talked about last week adding org to the name of these repos so I started making the changes in cookie cutter and I think I got it working to change the name of the folder of the project that gets generated and it occurred to me I didn't know if we wanted that to be on the pi pi name and the read the doc's name and in the name of the python file as well so I figured I would ask instead of uh make my best guess I don't with pi pi I don't think it matters um read the docs it really doesn't matter either um it because the the reason that we were changing that is so that we identified like the difference between the eight different ones and the ones that are on the circuit python org yeah and I don't know that it meant for the for the dot pi file I don't know that one I I would leave to others but for pi pi and read the docs I don't think it matters okay um in terms of the pi file um what is it what would it what would it look like now you get so if you like the name of the library if you put for instance display io cartesian that's the one I've done a bunch of the work on then you end up with a file that's just called display io cartesian believe let me double check though I think that's okay I don't think org needs to be in the pi name yeah that's correct you end up with just display io cartesian which actually yeah that makes sense since there's no circuit python then there should not be any org really I'm not sure why I'm not sure why I didn't catch that one okay so we I won't put it in pi pi or read the docs uh but it will be in the the name of the folder so great I think I can finish that pr up uh sometime later today or tomorrow excellent for cookie cutter yeah agree with agree with Jeff for sure okay uh yeah that's all I had okay and that ends up in the weeds as well um so with that I will wrap up um this has been the circuit python weekly for May 10th 2021 thank you to everyone who participated if you want to support Adafruit and circuit python and those of us that work on circuit python considering purchasing from the Adafruit shop at adafruit.com this video of the 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 on monday as usual at 2 p.m eastern 11 a.m pacific uh next week this meeting is held on the adafruit discord which you can join anytime by going to 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 circuit python east's role on discord and we hope to see all of you next week thanks everyone thanks all