 Hello everyone, this is the CircuitPython Weekly Meeting for March 22nd, 2020. It's the time of week where we get together to talk about all things CircuitPython. I'm Jeff Epler and I am compensated by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny little computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. We hold the meeting in the CircuitPython text channel and the CircuitPython voice channel. This meeting typically happens on Mondays at 2pm Eastern time, 11am Pacific time, except when it coincides with the US holiday. If the meeting time is changed, we'll let you know on Discord. We also have calendars which are linked from the GitHub about the CircuitPython weekly meeting, so you can add those to your calendar app or view them in your browser. Anyway, also to be notified about changes to the meeting, we can add you to the CircuitPython East's Discord role. You can ask a community moderator or an admin to do that for you. This meeting is recorded. We record the audio from the audio channel and the text from the text channel. If you would rather not have your voice recorded, you are still welcome to participate by providing notes for us to read. The video will be posted on YouTube and the audio will be released as a podcast. If you find we're not available on your favorite podcast service, please let us know. There is a notes document to accompany the meeting and recording. If you wish to participate but can't make the reading, can't make it to the meeting, you can leave your hug reports and status updates in it and I'll read them off. The notes document also contains timestamps, so you can use it to seek only the parts of the video that interest you the most. The 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 in the CircuitPython channel on the Adyford Discord every week. Check the pinned messages to find the latest notes doc. We hold this meeting in five parts. Not counting this one, this is not a part. The first part is community news, where we take a look at all things CircuitPython and Python on hardware in the community, and it is also a preview on the Python on microcontrollers newsletter. The second part is the state of CircuitPython, the libraries and Blinka, a statistical overview of the health of the entire project. The third part is hug reports, an opportunity to highlight the good things folks are doing, take time to recognize the awesome folks in our community. The fourth part is status updates, where we sync up on what we've all been up to. We invite you to take a couple of minutes to talk about what you've been doing in the last week since the last meeting, and what you'll be up to over the next week. The final part is called in the weeds, and it's an opportunity for longer discussions. If you have ideas in advance, or if they come up during status updates, please add them to the notes document and we will cover them in the order that they were added. And that covers how the meeting will go. And with that, I will move on to community news. First up, CircuitPython 620 beta 4 has been released. And since we start counting at zero, it is the fifth beta release of CircuitPython 6.2. Noticeable changes since the last beta include RP2040 fixes and features, enhancements to bitmap tools, and turning off USB CDC by default. It can still be enabled in a custom build. And that actually means turning off the secondary channel for USB CDC. The regular rebel channel is still there, don't worry. Second up, the badges from the Open Hardware Summit 2020 are arriving. Everyone who registered, but of course did not attend the Open Hardware Summit 2020 due to the COVID-19 pandemic. The badges and other goodies are finally shipping out to attendees. And there are a number of unboxing videos and Twitter posts around it. And I actually have mine. And the only thing that I have actually used is the YouDoYou badge, which I think is great and cute. It doesn't run CircuitPython though, sorry. Next up, DigiKey had a Pi Day and apparently there is a roundtable that you can watch on pscp.tv. Next up, the CircuitPython Contentful Blog Showcase. It appears to be a device that you can kind of view an RSS feed of this website called Contentful on. And next up, the Soil Moisture Sensing with MakerPiPico using the Citron MakerPiPico and CircuitPython to measure soil moisture with a comparison of capacitive and resistive sensors plus an SSD1306 OLED display and display IO graphics. And there are also some associated links to learn.adofort.com and Instructables, just in case you want to know more. Finally, the device that many of us need while we're watching a movie, the Pico Mouse Jiggler to stop your screensaver from going off at those inopportune moments. The Doorbell Detector is a quick sensor to detect when a doorbell rings and alert you. Then straying a little bit from the Python on hardware angle, Commandix is a pure Python implementation of various standard Unix commands like LS, CP, and SLEEP. Although I could see that being usable on CircuitPython, who knows. Finally, this one caught my eye, U Schedule for CircuitPython, a reduced version of the Schedule library that runs on CircuitPython. Next up, Raspberry Pi on the Raspberry Pi Pico, how to get Wi-Fi on a Raspberry Pi Pico using an Adalift Featherwing, and that one is from Tom's Hardware. We invite everyone to contribute to the newsletter. The CircuitPython Weekly newsletter is a community-run newsletter emailed every Tuesday. The complete archives are at adafruitdaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware-related news from around the web. To contribute your own news or project, you can edit next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. If you want a preview, you should also follow the whole thing. Follow that link in the note stock directly to this week's draft and know all about it before your friends. Next up, we will transition to the state of CircuitPython, the libraries, and Blinka. As I mentioned before, this is kind of a statistical overview of the project, focusing on the numbers that we can see from GitHub, and it's divided into several parts, and I will start by telling you about the overall statistics. We had 49 pull requests merged from 25 authors. That is more than two dozen eggs, y'all. Some names I don't recognize are Yugeish, R. Pavlik. I think we've had contributions before from K. Tai-Bo, Nathan Y. 3G. I'm not sure if that's a new name, and yeah, so a bunch of the usual suspects, and then we have a full dozen reviewers, another box of eggs, so thanks to all of them, reviewers are kind of the people that enable the development process to go forward because we need to hear this works. I looked at this and it makes sense, and the way you do that is by commenting on pull requests, and if you have the special power of a reviewer by marking the pull request as approved or as changes requested, so let us know if you want to level up from whatever level you're working at now to being a reviewer, if you can test, if you can look at code and make educated guesses and draw conclusions about it, we are happy to get you to where your comfort level is reviewing and enable us to bring in contributions from an ever-growing number of contributors. And the final overall statistic is looking at the number of issues. We had 19 closed issues by 12 people and 34 opened by 22 people, and I'm not going to try and tell you dozens of eggs just off the top of my head, but it's great to see the number of people that are participating, and it's a little less great to see the number of issues creeping up over time, but really that indicates interest in the software and we just need to work on triaging those issues and addressing the most important ones as we can. And with that, I will hand it over to Scott to tell us what is going on in the core. Awesome. Thank you, Jeff. So stats for the core, we had nine pull requests merged from eight different authors, so thank you to all of our authors. We had five reviewers as well, so thank you to our reviewers and a shout out to FOMI Guy and Kmatch98 who are relatively new reviewers there. We have 20 open pull requests, four of those are older than 100 days, so we should take a look at those. And other than that, it looks like we're moving through things pretty well, but as always, if you are related to some of these pull requests, please make sure that they're moving forwards if there's work to be done plan on doing it, otherwise we should just close them. We can always make new pull requests with stuff. Issues-wise, we had two closed issues by two people, seven open by six people, so we're up five. For a total of 424 open issues, you can check those out at github.com.com. We do try to keep kind of at pace with these, although we're growing slowly. The way that we determine what time scale we're going to work on things is through milestones. And so we have five issues, not a milestone that need to be triaged. And then we have 341 long-term issues. These are the ones that we're... This is the number we're okay growing. And then we have three issues around... Or three milestones around 6.0, which looks to have 50 total open issues. We're going to have to take a look at those and prioritize which ones... If they stay there a while, they probably should be long-term instead of in the 6.0 bucket. And then we have seven issues for 7.0 as well. And we'll probably knock those out after we kind of turn the corner between 6.2 and 7.0 work. So I think that's the plan right now is we'll do a 6.2 release. And then after that, we'll start working on 7.6.2. I think we'll hope to get Raspberry Pi stable at that point. And then we'll probably have a couple minor, like a 6.2.1 and a 6.2.2 sort of thing, just for new boards that have the RP2040 on it. But at that point, we'll be working on 7.0 hopefully. So that's it for the core. All right. And maybe this is one for in the weeds, but those pull requests that are older, I think they are going to need extra love because of the formatting changes. And if you do get back to one of those and you run into trouble, we will work with you to sort out formatting stuff, but just expect a little extra trouble because of that. But anyhow, moving on. Next, I will hand it to Katnita to tell us about the libraries if you're available. I am here. Hooray. All right. Thank you. So this section applies to all of the Adafruit Circuit Python libraries. That's everything that begins with Adafruit underscore circuit Python underscore. It also includes the Circuit Python community bundle and our Circuit Python library cookie cutter. So overall, we had 35 pull requests merged from 18 authors and 11 reviewers. So thank you to everybody who is involved in that. The oldest pull request we had merged with 71 days old, which is amazing. I'm glad to see that we're still picking up some older PRs because we definitely have some that have languished. Below that was two weeks and most of them were under a week. Leaving us with 67 open pull requests, which is up and we are no longer as tied into CI updates as we were. So the majority of those are probably actual library contributions, which is great to see. We had 14 issues closed by 11 people and 25 opened by 18 people. So we are definitely up, leaving us with 309 open issues. Only four of those now are labeled good first issues. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all this information and more. You'll find a list of open pull requests, a list of open issues and a list of library infrastructure issues, which are really more for us than they are things that other folks are as likely to be able to fix. The issues can be searched by label. Good first issue is an excellent place to start if you are new to everything. Otherwise, bug or enhancement are also great to search if you are looking for something a little more complicated. But you can scan the open pull requests and scan the open issues, see if anything interests you. With the pull requests, if you have the hardware, please test it. If you don't, take a look at the code for style or syntax, let us know you took a look at it. It's a great way to start contributing as well as reviewing. We're always looking for more reviewers. And the best way to start reviewing is to just comment on a PR and let us know that you took a look at it and do that a few times until you're more comfortable. And then we can talk about actually getting you onto the review team. So that's my contributing thing. We had no new libraries in the last seven days. We did have a list of updated libraries, all of which I will not read off. It is in the notes. And it is also available on circuit python.org slash libraries if you're interested in that information. Overall, I'm really excited to see all of the new contributions. Folks are folks are contributing. That's the important part. And remember that the more reviewers we have, the more authors we can support. So part of the reason why we have so many open pull requests is that we're limited on reviewers. And I know that we are working on getting some Melissa will talk about this and bundling stuff done. It's also great to see more contributions to the community bundle. The community bundle is community supported libraries that Adafruit doesn't necessarily support. But it's for, you know, random hardware that you have and you want to write a circuit python driver for it, it's a great place to put it so that other folks have access to it. So continue contributing. If you have open PRs and you're blocked on something, please let us know. It's the best way for us to know that PR is active is for you to ask one of us for review and we can request a review from the team. So thanks everyone. And by the way, Catney, I think the community bundle did have a new module in it this week. Oh, right. Piper make Blockly, I believe, because I'm the one who added it. Right. Our scripts don't directly call those out. So I try to remember to check but I didn't get it in the doc today. No worries. We called it out verbally. All right. So with that, I will hand it to Melissa to tell us about Blinka. Hello. So with Blinka, this which is our circuit python compatibility layer for Raspberry Pi and other single board computers this week, we had five pull requests merged by three authors and three reviewers of the authors. I didn't I don't really recognize Nathan y3g. There were three open pull requests that are open at the moment and there are there were three closed issues by one person and two open by two people leaving a net of 54 open issues. There were 2,930 six pi PA downloads in last week and we are currently supporting 70 boards. All right. Thank you, Melissa. And if I didn't say it, thank you, Scott and Catney. And that brings us to the first participatory section of hug reports. Hug reports are a moment to appreciate the people around us, whether on Discord, GitHub, Twitter and beyond for the good stuff that they're doing and contribute contributing to the community. I will start to show how it's done and then we'll continue with Jerry and on down the alphabet. So I wanted to thank K match and foamy guy for helping out in numerous ways on some bitmap improvements. In particular, there was one change that I threw over the wall Friday afternoon and said, I think this is a great idea, but somebody needs to test it. And yeah, there were some bugs in there and they worked it out and fixed it for me. So I really appreciate that from both of you. And last week, lady, a day at the lady Ada and I were working directly together on the long delayed Metro M seven. And it's just a lot of fun and it feels like a big honor to get to work with her. I wanted to thank tech and Greg at NXP for the RT 10 XX bootloader stuff. It really just worked. I think that they did big updates on it back in December of 2020. At any rate, it was it was great. And yeah, next, Scott for the RP 2040 flash stuff, which I think we will turn around and apply to the RT 10 series microcontrollers. They have their own way of specifying information about flash for booting. And I hope that we can reuse so that we can build the the the boot blocks that we need for our different devices. A big thank you to Kilogram on GitHub for accepting a pull request of mine into Pico SDK, found a little buglet, fixed it. Yay. And finally, thank you to catney for working on the newsletter. It would look like it was in awesome shape earlier when I grabbed the community news section from it. Next, I will pass the baton to Jerry and then I have notes from Jose David. Hello, I just have big group hugged everybody this week. All right. Good to see you. Yeah. All right. Jose David writes a hug report to the Samurai Pupra for improving the documentation and showing the path to use the same standard as for the core, a hug to K match 98 for the incredible read the docs and graphics work. And a hug report to foamy guy for the stream and the weekly wet blade commit. I'm not quite sure weekly web late commit has a place to meet and discuss. And finally to Dan H for for showing us the way. And with that, I will hand it to catney and after that we will go to K match. Got me off guard. Sorry, I'm looking I'm looking right at the notes. Yeah. Alright, so a huge hug report to and for all the help with learning how to temporarily take over the newsletter. It will be mine for the next month and a half or so. To foamy guy, David Gouda, Scott, PT and the more for sending me newsletter content to foamy guy, Mr D66 and Kevin Jay Walters for PR and newsletter content. To the more for some help over the weekend with deciding where to put a couple things in the newsletter. To Philby for getting me the watered down silk image for the cyberdeck fritzing objects. It turns out that the effort that went into creating the cyberdeck silks makes them incompatible with fritzing, unless I want to spend days fighting with it, which I don't. So Phil made a much simpler version of both of them so that I could make the fritzing objects without having to fight with it. And that was excellent. To Brent for getting the date time library tests passing pilot. To foamy guy for sorting out the minimum duplicate code lines in multiple places at my request, including for our overall threshold increase and to Dylan for increasing them in similarity line threshold for duplicate code checking across the libraries. Thank you, Catney. So for those of you who are following us on audio only, I'll give you the context to Jose David's hug report, which was that on foamy guys stream this weekend, some web late contributors dropped by and they chatted over the weekend. So that was the context of that hug report about the web late item. So all right, came at you are up next and then maker Melissa. Thanks, Jeff. Oh, I see you've lost your 98. All right. Oh, okay. I'll try to make it just to make it simpler for everybody. So okay, well, thanks to you for the fast bitmap loading algorithm that you added last week and a lot of cleanups and paying back some technical depth on the bitmap bitmap handling and dirty rectangle tracking. Thanks to Jose David, particular for jumping in and initiating the Cartesian graphing widget, a lot of good progress already. So the good to see that that to be added in. And last hug is to foamy guy for a lot of code reviews and a lot of suggestions and patience with me and constant encouragement. So and then a special thanks for adding the icon widget that's used in the recent touch deck, and particularly on some discussions we had around that on how to reduce memory usage. So thanks for my guy. Thanks everybody else. Thank you. All right, maker Melissa is next and then I have notes from Mark. I wanted to give a hug to Dan H for your help in getting a strategy for the dynamic bundler mostly sorted out and group hug everyone else. Thank you. Mark writes that he has a group hug. I haven't been around much. So I'm sure I've missed thanking some people. Next up is Scott and then we'll head back to the top of the list where I will read some notes from Anik data. Awesome. Thank you, Jeff. First, I have a hug report to you for something that happened almost a full week ago. But we got this massive code formatting thing and thanks to micro dev but we did have to follow up with a quick some fixes or changes there. And I know it's like unexpected work and not always the most fun. So thank you for leading that and getting that all sorted out. Well, I back for you working with me on that. That was great. And it really made it go fast and feel easy. So yeah, yeah, it's all good. Things like that come up. And so it's good to recognize them, especially when they're like right after the meeting. And I usually only do hug reports at the end of the week. So I miss those things sometimes. Second up, I have a hug report to Katnie for taking the lead on sorting out the duplicate code check. It really helps to have somebody who is aware of it, can answer questions about it and ask folks to get everything sorted. So thanks to everybody who also helped Katnie get that sorted out. Specifically, or next up, I have a hug report to KMAS 98, FOMI guy and Jay Posada 2020 for starting to do reviews and really adding stuff to that that's incredibly important. We say every week that we really need more reviewers and these folks have stepped up and really started helping with that. So it's great to see. And the last up hug report to David Glaude for being a circuit python advocate, I run across to you on the internet a lot and see you really promoting kind of the circuit python wave of life. And so thank you for doing that. And thanks for helping all the new folks get up to speed the circuit python. That's it for me. Thank you, Scott. All right, I have a couple of people's notes to read and the next up after that will be Dan. But anecdata writes a hug report to Jay Posada 2020 and Brent, are you for testing and reviews? A hug to higher effect for the UDP discussion on discord. And finally a hug for Dave Putz for thinking in hex. Next up, Charles Barnford writes a group hug. And now I will hand it to Dan before returning to reading notes from David. Okay. Thanks to 50 or 5D, who's on the Raspberry Pi Pico SDK repo, who has figured out a setting to make chatting change to make an I2C to make the TCS 3470 25 color sensor work with the RP 2040 I2C hardware. And that hasn't been merged in yet. There's some discussion going on. But it's it's a big step in the right direction for figuring out why that sensor didn't work. Thanks to Dan. Sorry, we can merge that into our version of Pico SDK if we want to as well. Sure. And I think we might do that. But they assigned it to somebody more knowledgeable to review, I think. So that's good. Yeah, the discussion was mostly about like, anyway, it's not worth talking about. There was churn in the discussion, which was kind of uninteresting. Thanks to people and help with sort of Python. There are too many to list at the moment, but they've been really stepping up to helping people with their problems. And sometimes they come in and they're just more knowledgeable, like, there's a lot of really helpful people in there now with a lot of knowledge. It's very good. Thanks to Katnip for taking over the sort of Python newsletter past few weeks while Anna's away. That's really great. And it's great to have another person being able to work on it. Thanks to Scott for working on generalizing the RB 2040 flash support. And eventually it'll be generalized maybe to other boards as well, which is an very interesting thing. He's describing flash characteristics and something other than a C header file. Thanks to TYO Mitch who submitted an interesting music playing art PR, and also in the process found some kind of useless code in the regular expression library that is just for debugging and has been on forever for no good reason. And thanks for NMORS who long ago started working on Rotary IO, trying to fix some glitches in it. And there are still some issues, but their initial look at it caused me to go back and look at it. And I'll talk about that later in status reports. Okay. All right, I will read those from David cloud and then I will hand it off to foamy guys. So David has a hug for Bill Binko of AT makers for the nice feather RP 2040 pinout diagram and guide. It is a fine looking pinout diagram. I hug to v923z for continuous discussion on faster thermal camera with or without micro lab. A hug report to me and to K match for the copy from you lab dot array to display IO dot bitmap. A hug to sandy j mcdonald for a first YouTube live broadcast. There is a link in the notes document. And finally a hug to the more for the I spy bus idea to connect screen to board which I must have missed one of the live indifferent broadcasts. So I'll learn about that later. I will pass it to foamy guy and then a higher effect will round out hug reports. Go ahead foamy. Alrighty, thanks, Jeff. This week to start off with hug to JP and Lady Aida for inviting me to collaborate on the touch deck project had a lot of fun working on that. To anecdote of this one, I think is actually a week late. But I wanted to get it into anecdote for making a minimal example of TCP socket communication. We don't have a very basic example of that in the in the repo yet or we didn't. And then somebody in the chat was looking for help trying to figure that out and anecdata stepped up and showed how to do it. And now we'll have an example for it in the future. Thank you to J plusata 2020 Jose David for working on the for joining rather the circuit Python librarians review team like some other folks mentioned to K match for stepping into stepping further into reviewing changes and troubleshooting modifications within the core. That's really neat to see for sure. And then lastly, to make a Melissa for reviewing a fix on tile grid that I had found in blink of display and confirming my understanding of how that was working under the hood. I appreciate that. That's all for me. Thanks. Thank you. All right, higher effect, play us out. Alrighty, thanks this week to TMH for identifying a tricky problem with SPI flash re-entrance, which affects the STM 32 board, the meow bit under certain conditions and was messing up his audio PWM IO PR, but also probably would have affected other things. So good on him finding that. Thanks to Jun to sack for all of their work on the nrf low power module. Just started wrapping up work on the STM 32 one. So it's but they also they did a huge amount of work on that. So that's very cool. And came up with some good ideas that I'll be able to put into my port. Next to anecdata for the work on tracking a bug with setting up UDP servers with the socket module. And thanks to you, Jeff, for your fixes that you've recently added to the IMX port. That's it for me. All right, thank you, everybody. It's always uplifting to hear just the sheer amount of stuff that people are up to kind of seen through the eyes of others. But now we get to see it through our own eyes and words with status updates. Once again, I will start off and we will go in the same order. So last week, I did some bitmap and bitmap tools improvements with, as I said, a ton of help from FOMI guy and K match. So things that are faster are loading PCF fonts, loading certain bitmaps with a different image load and exchanging bitmap data in and out with array and buffer like things, including micro lab arrays. Internally, I've documented how to use the ROM USB bootloader on the RT 1010 EVK and the Metro M7 RT 1011. And one of my activities this week will be documenting that within the learn system. I started working on the backlog of Metro M7 bugs. And we made enough progress that Lady Ada decided to announce the board as a coming soon. So coming soon made a minor bug fix in the Pico SDK, which they merged in today. And I made an experimental PR so that the frequency of pulse in can be set to allow measuring longer pulses at millisecond precision instead of shorter pulses at microsecond precision. This week, I'm going to continue working on a backlog of Metro M7 bugs that have been reported by other people. The first items up are SPI where we've already been able to close some of those PWM out and SDIO, which is not on the Metro M7 but is on the TNC 4.1 and it's kind of a hotly requested item. And as I mentioned, I'll be writing a guide page about using that ROM bootloader. And maybe this week for myself, I'll find time to add support for the jump pin in the RP 2040 that was kind of carried over from last week, but my direct need for it in my project has passed. So fun stuff. My WWVB clock is now a dual processor device with a QT PI to do low level receiving work and the Feather RP 2040 to do the high level decoding work and running the display. And they talk over a UART. And a couple of pieces that I got to build to enable this to work better is jebler underscore monotonic.pi is a small module for creating a real time clock from the time dot monotonic NS time source. And one exciting thing about this is you can set it and query it with sub second accuracy. The downside is if you use certain power saving modes, the monotonic time source doesn't count. So couldn't use this on an ESP 32 but it works really well on the Pico. And so those each time the second ticks over, I need the display to update just at the right moment. And this was important for that. And then the other item and there's there's a link to this in the notes document and then the second gist that there's a link is I implemented the receive only UART using the PIO peripheral for the Feather RP 2040. And that one actually I pull requested into the Adafruit PIO ASM library as an example so you can also find it there. And thanks for getting those links. I will pass things next to Jerry and then I will read notes from Jose David. Thanks, Jeff. Let's see. So last week, I had good intentions of trying to add a battery monitor to the old the magic. L, L, Y, W, S, ST03, MMC, little sensor BLD stuff. But clearly it showed me how little I understand about how these things work. So I'm back to square one and doing some reading and trying to learn enough to have another go at it some point. Now I came across an issue I was playing with the STM32 Blackpill. And when I was running the usual color wheel test with the neopixel ring. I noticed that occasionally you just stall the running nice color wheel would start up. And then it would just sort of freeze for maybe half a second, a second, sometimes two seconds. Then we'd start up again. And it really puzzled me. I've never seen that before. And I run this almost any time they hook up and you know, the new device. So I created an issue on it and trying to narrow it down. It doesn't happen on an STM32 F405. And it doesn't I've never seen it on other boards. It also doesn't happen if I just put a counter in. It doesn't happen. So it definitely seems to have something to do with the neopixels. But baffled, but curious. So if anybody has any clues, take a look at the issue and make suggestions. But I'll keep trying I'm trying to narrow it down to a better example for troubleshooting. There was a minor little problem with the fingerprint library. There's a new a new fingerprint sensor that's available now. And one of the relatively new additions doesn't work on it or failed. And that turns out a little timing delay had to be put into this new set param routine. It's not clear to me why. So I'm sort of thinking about it before I go ahead and PR it. I want to really understand what it's what it's doing. But it was a pretty simple fix. But not quite sure why it why it failed and why why you think why it fixes it. So I'm looking to do a little more. Next week, I just want to keep working on those two things. And fun stuff. Just got two cords of firewood delivered and slowly moving it into the woodshed first got to move the half a cord of remaining stuff from last year out. So getting a good workout. And how big is a cord in metric units? Does anyone know? Let's see the heart 28 cubic feet. So I have to go. All right. Anyway, I'm just I'm just trolling about American units. All right. So I have notes from Jose David. And after that, we will go to catney. So Jose David writes last week created the styles bundle, which is ready for review. If anybody can help them on that, reviewed the ITC peripherals after Scott's review, we'll need to put a hold on that. As the Raspberry Pi Pico SDK does not have all of the functions needed to do the slave read. And I'm not ready or willing to do PIO. Last report on the three to one issue on the core bitmap label PR to introduce directional text and did a PR in the micro plot library that uses circuit Python or micro Python to plot a display, adding the feature to use a to fruit dot shapes dot triangle as a scatter point. This week, the styles library if approved, I can add the feature in the other libraries that could use it, namely widgets, and the Cartesian plane widget, this will allow to plot data from sensors inspired by the great work of K match. And Jose David's fun stuff is happy that now I know what shared bindings means, almost as happy as when I discovered what DHT stands for. And now it is time for Kenny to be followed by K match 98, or just K match. All right. So last week, finish up one big guide, worked with foamy guy to get a reasonable minimum value and then Dylan to increase the duplicate code threshold on all of the libraries to that value. began the process of adding LED as a pin named all the circuit Python boards with a little built in LED. Many of them already have it. I think you be late at huger port to Jeff for managing to get grab and compare files to get me a list to start with. Because I began writing and applying tablets to the circuit Python board guides. The idea being that the circuit Python essentials guide will eventually be tailored to each board guide. And the first one we're doing is blink. However, some have D 13 some have LED some have L none of them have all and a bunch of them don't have LED and LED is really where we want to go with it. So I will be each time I find one putting in a PR for six or seven of them at a time to get all those updated. I added a pinout diagram to the feather RP 2040 guide. Thank you to Bill Binko from 18 makers for making that. It's one of those super fancy. It's one of those super fancy pinout diagrams that's got everything that's going on. And to answer that question, David, it'll be blue underscore LED. And on those boards that have a blue and a red, there's also red underscore LED. We're not removing any of the current names. It's just adding LED to those that don't have it. So I sorted out dealing with getting the tests and the date time library passing, which is to say I talked to Brent about it and Brent followed through on the suggestion of disabling pilot basically on all of the tests because date time is special. It's based on C Python. And so are the tests. So going through and changing variable names and all that stuff was not going to make any sense for that particular library. So we made a note or Brent made a note and then pilot disabled things. So that was super helpful. Updated the clue guide to include debug pin pad info, fix the BNO 0 8x guide to refer to a live package instead of a dot MPI file started the cyberdeck hat fritzing object started the cyberdeck hat and bonnet guide did various PRs and got my final training on publishing the newsletter. So this week, publishing the newsletter solo for the first time. So that's going to be the rest of my day. Working on the cyberdeck in guide, I actually finished the cyberdeck hat. So I think it was the bonnet, not the hat, the bonnet fritzing object this morning. And then I will be possibly adding some stuff to the MIDI feathering guide, which already exists, but it's never been published. And then once I'm through with that and get that into a state that I can hand that off, I will be continuing with the template pages for the circuit Python board guides. Next up is making a neopixel blink for those boards that don't have a tiny LED, but do have a built in neopixel so that folks can still make an onboard LED blink as their first program. And that's where I'm at. I guess I will put out the plea. If you run into over the course of the week, any circuit Python, micro Python, Python on hardware, Python in general, related news items or projects or your own project, please email cpnews at Adafruit.com with a link. So I can get that included and featured in our newsletter and thank you to everybody who's been sending stuff in. You can also PR directly to the newsletter, which a few folks did this week and I greatly appreciate that. Because it definitely makes less work for me. So thanks to everybody. And if you see anything or you're want to get your own project into the newsletter, please let us know. All right, stay busy. It's time for Kmatch. And then after that, maker Melissa. Okay, thanks. Just an advertisement briefly about where the widgets stand right now and what's available. So far, we've got a button, a progress bar, a round sliding switch, new icon widget and a dial. And more as you can tell are coming. As for this, our last past week, I submitted an annotation widget the way you can point at things on the screen and label them easily. Then next I worked on animating the icon widget. So it does some zooming or rotation as you're touching it or releasing it. Other related sort of support functions as I helped extend the read into function, which speeds up bitmap loading and make it suitable for different kinds of files. Then some work on tweaking palettes and colors on both image load bitmaps as well as ones that are on disk. So added some support functions for that. And as for this week, I hope to submit one other widget that's in the queue. It's a flip input so you can select from miscellaneous values you have programmed in. But as well, also dig a little bit more into debugging inside the core and learning how to do that. And the avenue for that is to try and resolve some dirty rectangle tracking in the tile grid function. And then last, another widget kind of have in mind as a scrolling text box. So want to see how best to manage a memory use so it doesn't overwhelm memory when doing something like scrolling. And that's it for this week. All right, thank you. Mark is on deck, although I think Mark was text only for hug reports. So if you do want to talk, let me know. But now it's maker Melissa. Hello again. Hello. Let's see, last week I worked on miscellaneous GitHub issues and pull requests. I started working on trying to develop a plugin based on circa for Visual Studio. But then I after poking around with that for a while, I decided to try and build a lot of the functionality into a central place because of the different languages used in different plugins. And so I started working on modifying the adabot to generate a JSON file with a library info. And while I was working on that, I saw an opportunity to build functionality for a dynamic bundle builder. So I realized, so I got the JSON file generated, but I also realized I need to have the ends up files available on Amazon s3. And so to do this, I started poking at the existing bundle builder libraries. And I've been familiarizing myself with the internal workings of adabot and circa Python build tools. But I'm still confounded by how the release assets are actually attached to the bundle release. Since they appear to be built by circa Python build tools, but it doesn't appear that that's ever called by adabot. So I'm going to talk about that more in the in the weeds. This week, I'm going to continue working on the dynamic bundle builder and hopefully have something to show for very soon. And for fun stuff, I built a video accessory clamp bar and have it on my YouTube channel. And I'll paste a link into the chat. And that's it. Thank you. Alright, so I will read notes from Mark and then up after that is Scott. So Mark updated PIO ASM to implement all of the move operators. And is on vacation for two weeks and can't go anywhere. So if anyone needs help slash ideas on something that should be worked on, let me know. Alright, after Scott, I'll head back to the top of the list. I think I have notes from anecdote. Hello, so I sent out my flash rework PR for the RP 2040 looks like there's not much to change on that. So I'll get back to that today. And then this week will be odds and ends before I switch to be really workflow stuff. I'm going to collaborate with Trevor on that. So I think he's back next week. So this week, I'm going to do kind of odds and ends. And so these are not in any sort of order. So don't get your hopes up. One is hooking up the NVM Toml stuff into the IMX RT build should be pretty quick. So I'll probably do it. I want to take a look at the library read me to just make sure that they have pre commit info in them. And I'd also like to actually do the patch myself just to understand what's involved with that. I one thing that the more has been hitting is unable to build RP 2040s circuit by thumb because of command line length on Windows. So may take a look at that. And then lastly, I also need to take a look at the Pico SDK board settings for our boards, because I think they are pushing them a bit too fast. And folks are having mixed mixed results using them. So I need to take a look at that as well. And then next week should be really workflow stuff, hopefully. All right. Well, anecdote did not, in fact, have any notes. So Dan, you're up now. And then I have notes from David. Okay, so last Thursday, I released 620 beta four. There were so small glitches in the release, but went well. And it was really helpful that I had made up. I had kept a draft release notes up to date as an issue. And kind of updated it frequently. And that saves sort of a lot of effort at the last minute. That was all continue to do that. One thing I noticed on the nrf boards is that if you try to connect to the rep poll, it takes like five seconds for the initial prompt to appear. And it's not the board startup, you can wait half a minute after you go to the board and the same thing will happen. So I tracked that down to a particular commit that's tiny usb related. And tack is going to look at that. I'm still looking at RP 2040 itc issues. There are a few sensors that don't work properly. And some other people interested in these sensors also, and they've been one person sent a poll request to the Pico SDK. And that is in progress right now. And they're probably having somebody who's more expert look at it to see what might be done. One thing that we do for releases is to do download counts, how many people downloaded various versions for which boards. And that information right now is collected from text logging that we do on the Amazon S3 bucket that has all the builds in it. And it's somewhat tedious to deal with those like the number of file log files that we have to download is about 300,000 a month. So it takes a while just to download them and concatenate them to grep through them, even though that's we have a script to do that work. So I looked at AWS and more in more detail. And it turns out there's a different kind of logging called cloud trail. That's somewhat better. And there's also something called Amazon Athena that will can grovel through the cloud trail logs. And we could probably automate this much more and have all the work done on the server rather than doing it locally. So that I'm looking at that. So it's something completely different, basically. And finally, I'm looking at, there's been an outstanding pull request from N Morse for a long time about trying to fix some glitches in Rotary IO, which works pretty well. And you don't really notice that it's missing counts sometimes. But it's not quite right. And so I looked at that I instrumented it. And I looked at some other implementations. There's a lot of there isn't really a definitive way, sort of a canonical way of doing this. Actually, some people put capacitors on their rotary encoders to debounce them. Some people debounce them other ways. And I found yet another way to do it, which looks really clever and really simple. And I'm going to try that out. So that's it. Thank you. So I have notes from David. And then up after that is foamy guy. So David, loud writes, testing the copy from you lab dot array to display IO dot bitmap. Thank you for testing always appreciated. Playing with the thermal camera trying to increase the frames per second using an m4 and an S two on a keyboard feather wing. Trying to use the same code, the I voted badge by Liz as is on feather m4 express and our 52 840 STM 32 and S two. Mapping the feather S two to make code for the feather m4 work with limited changes. See in the weeds. Helping Michael Horn with itus on the Pico and there is a link to a blog entry there in the notes document. And in the good news bad news department. David's feather RP 2040 was do a only runs 30 seconds every few hours enough time to flash, but never enough to see the circuit Python drive. The RMA is on its way. And I'll hand things to foamy guy and then as before how effect will round out the section? Alrighty, thanks, Jeff. Last week I spent a fair amount of time working on the touch deck project. I after that was mostly completed. I got caught up on some outstanding display text PRs and got most of those merged. There's some new ones to take a look at this week. So that's one of the things I'll be doing this week. I did end up creating a helper class for the three and a half inch feather wing. Think I mentioned that last week. And I made a PR for that in the feather wing library and ended up having to do a couple other small refactoring items inside there to get the actions to be happy. I tested out several of the enhancements like bitmap tools in the core, the image load library and then several new widgets in the display layout library. I made an example script that reads from two different Stemma compatible sensors and it puts the output data from them into the new dial gauge widgets. So that was one of the things I did over the weekend on my stream. That was a lot of fun. I created an issue that's documenting some trouble I've had with the STM PE 610 touchscreen driver. It seems to get in a locked up state if you restart the device at just the wrong time. So I created an issue there to document what I found so far. For this week, I will need to finish up the code on the touch deck and get a PR created to move that into the actual learn guide repo. I just been working to my own little repository for on that for now. I need to or I would like to do this one, which is further customize my own touch deck layers. I got a few of them created last week, but I got tons of ideas for more shortcuts to add to mine. I'd also like to get the enclosure printed this week if I can. I'll be testing and reviewing the icon animated as well as the annotation widgets that K match created and then also taking a look at the new Cartesian plot sort of graph outline section that Jose did. All of those are in display layout. I will be working on a simple test for icon widget and animated excuse me and icon animated also. When I first created icon widget, it was for the touch deck and got it merged in quick without an example, but need to go back and put one in there now. And then last couple things this week, I'll be cleaning up that color sys library or it's actually the CPython library today, but it's going to become the color sys library. Get the stuff that's not needed in there deleted and then anything else that needs to be done to get it passing actions and ready to join or be added rather to the to the bundle. And then lastly, I want to look into that new styles library that Jose is working on. So I'll take a look at that this week. And that's all I got. Thank you. Great. Perfect. You are up. Alrighty. This past week, I finally tracked down and categorized a number of the problems that I was having on the deep sleep PR for STM 32. Some of them were related to right access in the RTC. Some of them were other kind of little structural things. And so I finally have just kind of a big list of everything that is just be cleaned up. So that's what I'm going to be starting off this week. Just getting that all sorted out. I also reviewed the audio PWM IO PR for STM 32 from Teomich. I ran into the same issue that he had had with that I presume he had with the SPI conflict that happens between flash and the display. So hopefully we can get that sorted out this week as well. This week, in addition to cleaning up the STM 32 PR, I'll be starting I'll be checking out the UDP issue that anecdote I found this past week. And seeing if there's anything I could do to help with that. And then if STM 32 power wraps up, which it hopefully will in just the next couple days, I'll be starting on low power for the Raspberry Pi 2040. And that is it for me. Thank you. And that brings us to in the weeds, the section for longer form discussion of any and all circuit Python related issues. Today, I will be starting it off. Around these enhancements to bitmap, you can now send a bitmap object to any function which treats them like a buffer such as memory view. However, the resulting view is always read only. And the reason that I implemented it like that is because in display IO, we always kind of update the display as a direct side effect of whatever the circuit Python code is. So if you have a tile grid, and you assign the tile grid at 00 to equal seven, then display IO is going to redraw for you and knows what to redraw. Similarly, if you're displaying a bitmap and you assign the pixel 00, the value seven display IO is going to redraw automatically. But for doing the kind of the highest speed lowest overhead modification of bitmaps, we want to be able to access them like they were memory views in particularly from micro lab. But then there is no way that display IO can be not notified that this or that part of the bitmap has been updated. So I just didn't enable it. The alternative is to add a new method, which the user or the author of the code, after they update part of it all or part of it with, say micro lab, would have to call it and give the correct coordinates for the portion of the bitmap that was modified. And so the pro is it might help fancy animations work a little faster. The cons are users who want this might be better served by accessing the TFT directly rather than using display IO. And the other con is that there's this new responsibility for coders who have to call this new function to avoid an incorrect display. And this would be kind of of the form. Well, sometimes my display doesn't update. And, you know, that in turn is kind of a support problem where we need to teach people and they need to remember to apply it consistently. And I bring this up to get community input as to what is desirable. And I hope Scott has some input right off the bat about this. I think, you know, I, I push display IO to be kind of like works out of the box as much as possible. But I don't also want to prevent people from doing other things. So I think the idea of having a more advanced way of saying, actually, no, this part's dirty. It's totally fine with me. It's just like, by default, that's not what you should rely on. Right. So if you do want to add something, maybe it's a keyword art to refresh, I don't know. Or it's dirty, or it's a function to bitmap that says dirty to us. I was thinking it would be a method of bitmap. Because that made the most sense to me. And it would, you know, strictly add to the dirty area. So if display IO thinks part of it is dirty, and you say, well, this other party is dirty, then it will create an area that encompasses right, right. And yeah, so if you think that sounds good, then I will put it on kind of my medium list to implement. Yeah, to implement that. That's kind of me. The other thing you should consider and this is just for the graphics folks, like, it might actually be better to change the way that bitmap does dirty tracking. So it can actually track multiple rectangles. For cases where like, you have two very different regions that have changed, and you don't want to have to update the middle region that hasn't actually. So there might be some optimization there as well about not like actually tracking multiple rectangles instead. Yeah, like for instance, I'm thinking of a script that I had where we're showing a waterfall graph of frequency using FFT. And there's going to be that moment at which it goes down from the top to the screen to the bottom and then starts at the top again. And at that moment where you return and you're updating that top level, that top row of the screen, right, it's going to chunk if it batches that with updating the bottom one. So that's the example of what you're talking about. Yep. Yep. All right. Yeah, so well, that was uncontroversial. Yeah, just make it optional. Just make it optional. Yeah, we won't break anything for people who are using it the way they're using it now. Yep. All right. So I will pass it on to Jose David, but Jose is lurking. So I will read this out. Do we have a minimum standard for the example code libraries? And there's a link to a poll request in Adafruit Circuit Python DHT. Some example code uses capital letters for static variables while others do not. Some use high level Python techniques such as Lambda functions and other advanced stuff and others try to be as simple as possible. Do we have minimum requirements or is it to the reviewer's criteria? And Katnick can comment on this, it says so. Yes, please. So there are two things that we disable in Pilant, for examples, by default. And that is invalid name and missing doc string. And invalid name is because we don't want to force folks to have to use capital letters for static variables, for example, because it can limit readability. And we really strive for readability and examples where possible. As for using high level Python techniques, the and or rather and versus trying to be simple as possible. Think about it this way. The simple test should be simple. However, even sometimes with certain libraries, that's not possible. But the simple test is sort of the one that has quote requirements. And that is that it just tests what the library does. So in the case of DHT, it would simply make sure that the sensor works done. Beyond that, you're welcome to make all kinds of advanced examples. We encourage folks to contribute. I know, for example, on the circuit playground library, we made a folder called advanced examples. And the only reason we did that is because that library is designed to be for beginners. And so we wanted all those examples to be as simple as possible. And so the more advanced stuff, we specified as more advanced in that particular library, but that really doesn't apply to any other libraries. So if you want to write a super advanced example for a sensor, you are entirely welcome to do so. The only requirement is that the name includes the sensor name from the library. So the name would need to be DHT underscore advanced underscore example or something to that effect. And then beyond that, the reviewer would determine whether or not it's syntactically appropriate or whether there's any kind of thing that could be changed. And that's with any PR period. Obviously, you're going to work with your reviewers if there are any changes requested. But for the most part, examples are up to the folks that submit them. And those two things, the doxtring and the invalid name thing are so that you could put in a function if you wanted to without having to document it inside the example because the examples are not, like there's not documentation built off the examples. The examples are included, but they're not, nothing is built off of them. So we don't have to necessarily document it. It's not discouraged, but it's not necessary for it to pass pilot. So hopefully that helps. One suggestion would be if you are concerned that your example is too advanced, include comments so that you can explain like this Lambda thing is doing this. But again, that's not strictly necessary. It's totally up to you if you feel like you need to include more documentation on a given example. All right. Excellent. Glad it could help. Unless anybody else wants to contribute to that, I will let David do a mic check and then go on to the next item. Is that working? Yes. Yes. Okay. So I'm still in trouble with the pin names because when I was playing with I zero kind of format. And recently I did try to use the same code on multiple feather. And I think I've got a problem with the feather as to because it's not from other foods and it's using other pin names for well known location. And I was trying to find a way to fix that. And I found a very dirty way to do it by making another board that pie that remap and use the original board pie. And I've put the piece of code there. So and in the future I will have the same problem with pickle that does not have I to see an SPI. And that is going to be even more complicated because I will have to fake a board dot I to see function and I don't even know what it looked like. So I was wondering if there was not something missing. Is there a better way than what I did? And then I start to think that maybe the physical pin solution from Timuroni was not such a bad idea because you can say I want to use the feather pin that is located there whatever its name because this is what your feather wing will use. And you know it's there. And yeah that's that's it. So the problem with the physical feather pin thing is that it's like too late to become a standard. The way that I would suggest handling this for pins is board the board module can have multiple names in board for a single pin. And so in the case of like these these ESP boards where they're labeled with the chip name. I've argued with unexpected maker about this a lot like board makers should label it. If it's a common form factor there should be common names. But as you point out there that's not always the case. And so what should happen is that in board we can have multiple names for a single pin. And the first one should be the one that matches the silk screen. But all of the others below that can be kind of other names that also match it that might be want to want to be used for that. So the way to fix it for the feather pin is to have alternate like D or A pin names underneath the IO name that map to the same pin under the hood. So that's and that's true. That's what we do for the feather RP 2040 as well. It's like we both we provide the DNA names because that's just what we started with with feather pin out. And then we also provide the GP IO names because people in C care about what those names are. This is becoming more and more of a pet peeve of mine because I you know we have this very broad view of the ecosystem of like embedded electronics and the people who make boards don't necessarily have that view. And so it's important to like just like you've been advocating for circuit by then it's also important to advocate for like if you're making a standard form factor make sure that pins are labeled in the same way as well. So yeah I think I answered it. I squared C inspire are are particularly weird case and again it comes back to the failures of the board design I think which is just that the Pico does not designate standard I squared C and spy and like that's nothing we we can't do anything about that. We we can't designate and we talked about this a few weeks ago or month. But like basically we can't designate standard buses that aren't designated by the board manufacturer. Yes. So for the item C SPI I'm going to use with a well-known position and so I will have to do that function to create the singleton and have it so that the other piece of code I use I'm not doing it do not need to be modified. I mean the problem with the S2 is that they have the pin I need with that name but somewhere else. So if they were not using those name that would be maybe easy but they use those name for other location. That's like a bug. The code run the code run but doesn't do the expected thing because that's not where the button is. It doesn't even stop because the okay right. So yeah if it's if it's like button related then it should be like you should have a board dot button sort of now because the button on the feather wing. Yeah I don't know. I think David doesn't mean a built in button to the board but I think it's like pin 10 I want to say off the top of my head pin number 10 like is in it they have a pen number 10 but it's in a different spot than the other feathers. So if you hook something up to it and then you run some code that says pin 10 your code won't do what you expect because the pin is. It's not a pin. It's iotin right or something. Correct yeah yeah it does have. I think that the prefixes are really significant and that's why we chose different prefixes so so that they wouldn't be confused. So I think that like if you have a general purpose library you might consider just passing in an I2C or passing in this stuff rather than having it try to use board dot I2C itself. If it could change then the library should take it as a parameter or your your your your common code. Yeah okay like the I love you badge it's just using yeah you copy and paste the code you execute it doesn't work you don't know why and it doesn't work because D9 is not D9 on that feather S2. So like if there was a F a number for physical physical is a whether F no it's with a P okay whatever I mean if there is a new letter and then that would be a feather position or then you could write the code using feather position but of course yeah I don't know. I I don't think that's gonna help you. No we already have that with DNA. I would say if there's a D pin that's not correct in the S2 definition that's just a bug. It's correct because it's matching the silk but it's not the same. Oh but the stock is wrong. On the M4. Well it's not I mean I don't think it's incorrect it's just different than it on the Adafruit feathers. Yeah like it. Yeah like eight eight is not the same place as eight somewhere else but notice the things the silks don't have D or IO in front. Right. No we're careful not to yeah. And they're defined as IO by unexpected maker. They're not D pins they're IO numbers. Oh. So D10 if you use D10 it should match D10 on a feather on other feathers but if you use IO 10 it won't because it's the IO naming. It's stupid. So there is a bug. Okay so there is a bug so okay I just need to document that and then it can be fixed. Okay yeah great. And the second one is smaller it's in relationship to what maker Melisa was discussing and about that creating a zip file with all the library you need for a loan guide that was discussed like six months ago and I've discovered or rediscovered circuit and it's super great and I was wondering could we have a requirements.txt for all the loan guide so that I could use that to get the right library result having to manually copy and paste and things like that. But of course it's a lot of work and it could be useful for creating the zip later because or whatever on where you want to automate that. What I'm working on right now is an automated web service so you could say I need this this and this library and then I wanted to kind of come back with all not only those libraries but any dependencies as well in a zip file right but you will need to have a list to use that in the loan guide. Well what I wanted was so that we could add a dynamic link right into the learn guide itself so we can just update that rather than updating of actual requirements file because not all learn guides are have files in the learn repo. You want to paste in the where is that issue I can't remember which repo it's in. That one's in circuitbethan.org 491 wasn't the plan to auto detect the libraries used by example code as well. That would be great. I know Justin was thinking about it. I mean just checking the imports you could create quickly your list which is all actually good. Yeah that's yeah that's what I'm gonna do. Circuit is great. I think we're realizing that we're putting more effort into it. Right I think that discussion is wound down in which case we will bring our last in the weeds topic up which is from maker Melissa. Okay so it's more of a continuation of the previous discussion here because I am not sure who put together the bundle system originally that creates the nightly bundles but I'd like to learn more details about the process itself because it looks like the bundle the what do you call it the release itself is generated by adabot but there's also assets attached which don't match the structure of the repository itself and it looks like that's built by CircuitPython build tools but I can't see where the connection is between the two. I think if you look in the actions of the bundle itself there's an action which gets run when it's a tagged release and it does things. Yeah and that's true for libraries as well. Well I know it when you release the individual libraries it'll create the assets there with the CircuitPython build tools but on the adabot where it generates the bundle it doesn't actually call CircuitPython build tools which is why I'm confused and I've looked in the actions on that one. Yes it does. CircuitPython build bundles. Okay let's see I'm looking at it here. Yeah. Is it this bundle cron.yml? It's github slash workflow slash release.yml. In the bundle. In the bundle repository. Um so Scott pasted it in the circle. Okay okay I get it now I was not looking there. Okay. It's run in both cases on pull request and on. Okay that was the piece I was missing. Okay thank you. I always have to I always forget this and I have to like figure out what like a diagram somewhere would be really nice. Okay thank you that okay I was not looking in the CircuitPython bundle repo itself so that's where I was missing it. That answers that. I'm glad when it's just an easy answer and not an open-ended discussion. Me too. I think the I think the answer to who added it is me. Okay. So if you have more questions you know who to bug now. Exactly. Thank you. I think I added it. Back when it was Travis. Yeah it's just trying to get all the pieces working together in my head here. Yep. Well thanks everyone for coming to the CircuitPython Weekly Meeting for March 22nd 2021 and thanks to everyone who participated. If you want to support Adafruit and CircuitPython and those of us who work on it 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 on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe. The next meeting will be held next Monday which I believe is the 29th at 2 p.m. eastern 11 a.m. pacific. The meeting is held on the Adafruit Discord which you can join at any time by going to adafru.it slash discord we've got people active 24-7 but this week this meeting is just once a week. To be notified about the meeting and changes to the day or time you can ask to be added to the CircuitPythonistas role on Discord. We hope to see you all next week. Thank you everybody. Oh thanks everyone. David remarks that the the hour of the day will change for many people in the EU because the EU transitions to summer time. So double check that hour particularly if you are outside the U.S. All right thanks everybody. Thanks.