 Hello everyone. This is the Circuit Python weekly for February 22nd, 2020. It's the time of year, week, when we get together to talk about all things Circuit Python. I'm Jeff 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 anytime by going to adafru.it.discord in your web browser. We hold the meeting in the Circuit Python Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern Time, 11 a.m. Pacific, except within coincides with a U.S. holiday. If the meeting time has changed, we noted on our online calendar and also mentioned it on Discord. If you'd like to be notified about changes to the meeting, we can add you to the Circuit Python East's Discord role. And as I mentioned, there's an online calendar which is kind of the number one source of truth about when the meeting is. This meeting is recorded. We record audio from the Voice Channel and video of the Text Channel. If you would rather not have your voice recorded, you're still welcome to participate via text. The video of this meeting will be posted to YouTube and later released as a podcast on various podcast services. If it's not available on your favorite service, please let us know. There is a notes document to accompany this meeting and recording. If you're watching us on YouTube, it's down there in the notes. If you wish to participate but can't make it to the meeting, leave your hug reports and status updates in the document and we'll read them off. The notes document will also contain timestamps to go along with the video so you can skip to the parts that interest you the most. This meeting tends to run 30 to 60 minutes, so it gives you the option to skip around. And also on Discord, the notes document for the upcoming meeting is always in the pinned messages in the CircuitPython channel, so click up on the pushpin to find the link. The meeting is held in five parts. The first is community news where we take a look at CircuitPython and Python on hardware news from the community. It is a preview of the Python on Microcontrollers newsletter. The second part is the state of CircuitPython, the libraries, and Blinka. It's a chance to look at the project by the numbers separate from what we're all up to. The third part and the first one where you all get to participate is hug reports, an opportunity to highlight the good things folks are doing, and take the time to recognize the awesome folks in our community. Fourth is status updates, an opportunity to sync up on what we've been doing over the last week and what we hope to do in the next week or so until the next meeting. And then finally, in the weeds, which is an opportunity for more long-form discussions, and we invite participation from anybody who has a viewpoint to share about these items. And that covers how the meeting will go. So next, I am going to take my first timestamp and start community news, which I seem to have lost the header for. That's fun. All right, so community news. Python turned 30 on February 20th, and we've got some links to that in the text chat. We've also got another number of milestone, but I'm going to let Katnig give it to us during the state of CircuitPython, the libraries, and Blinka. Scott posted the long-awaited CircuitPython 2021 roundup. A large number of members in the community talked about what they wanted to do with CircuitPython in 2021 and what we need to do to get there. And there is a link to each one of those over on the Adafruit blog. Next, I picked a couple of projects that the community has been doing. So first, Kat outside is a reminder with CircuitPython and an Adafruit MagTag e-ink display. We've got a link to Twitter. Check it out. Although I think that the outcat should be facing away and there should be the, never mind, on the other end. Next, putting CircuitPython on a custom SAMD21 powered USB-C plug tester, also from Twitter. And more Twitter, a hacking prank with a Pico using the Raspberry Pi Pico. Those kids are having fun and it's not hurting anybody. And finally, for this section of the meeting, but not for the newsletter, a CircuitPython class to drive the LEDs and read the buttons on a Pimeroni RGB keyboard with the Raspberry Pi Pico. Links to Twitter and GitHub for the source code. The CircuitPython Weekly newsletter is a community-run newsletter emailed every Tuesday. The complete archives are on adafruitdaily.com slash category slash CircuitPython. We like to highlight the latest Python on hardware-related news from around the web, including CircuitPython, Python, and MicroPython developments. So community, you are the drivers on this. So we invite you to edit next week's draft on GitHub and submit a poll request. Or you can also tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. And that brings us to the second section, the state of CircuitPython, the libraries, and Blinka. I will read the overall and then turn it over to some of the other folks to talk about the other sections. So overall, we had 37 poll requests merged from 22 authors during the last week. So some good names there. I don't recognize KT Ibo, but I think maybe they've had a couple of contributions lately. Luke Schwab, G. Pongelli, Sandy J. McDonnell, I. M. Grant, Oli Mickels. So, yeah, we are always happy to see new authors making the community more and more vibrant. On the reviewers front, we've got people who've kind of become the usual suspects, nine reviewers. But, you know, I always wanted to thank people who are working outside of Adafruit. So, FOMI Guy and S. Patrick W., I'm particularly happy to see you putting in reviews. Reviews are part of making the whole poll request process work because we want to have at least a second set of eyes on every change. So if you want to work up to being an official reviewer, you can comment on poll requests. You can let us know that you tested something, that you looked the code over for problems. If you found problems, let us know, always in a respectful way to the submitter of the PR and other people. But we love to see participation and it helps us increase what CircuitPython can do. On the issues front, we had 26 issues closed by 13 people and 18 opened by 14 people. So the first thing to note is that we had a net decrease in issues over the last week, which is always good. And that we had over a dozen people participating both to open and close issues. So quality activity by the community. And with that, I'm going to head it over to Scott if he wants to tell us about the core. Thank you to our authors. We had two reviewers. We have 23 open poll requests, which is a number that's growing a bit. But it looks like at least, yeah, five of those are open with zero days. We're getting lots of new stuff in, which is great. Again, if you're working on any of these older PRs, please, or if you think you might have open PRs, please take a look and make sure that there is a plan going forward with them. If there's not, go ahead and close them. You can always reopen them later or open a new PR. So we don't generally like to have things lingering. So if you could take a look at that, that would be awesome. Issues-wise, we had eight closed issues by three people and six opened by four people. So we're net down two, which is great for a total of 401 open issues. This number is growing. It's not something to be super concerned about. We do have a category called long term where we think these are great ideas, but we don't intend on doing them immediately. And that category should be the only one that grows. Hopefully what we're doing is we're going through the other stuff. We have some 6.x related milestones. It looks like there's about 55, 57 issues there total. So we should take a look at those as well. But nothing super concerning. We're slowly growing, but slowly growing is fine. I think pull requests is generally where we want to make sure that we don't grow at all. So that's where we are with issues. We don't have any issues that are not assigned to milestones, so it looks like we're up to date in terms of triage. Overall, 620 is going pretty well. I think we'll keep doing betas until we're ready to do a staple release and then probably switch gears after 6.2 into a 7.0 kind of mindset. So keep an eye on that. Please keep testing everything and should be really good. Thank you, Scott. Next, once she finishes taking notes for us, I will hand it over to Catney to tell us about the libraries. And thank you, Catney, for taking notes today. You're very welcome, Jeff. All right, so this is about all of the Adafruit Circuit Python libraries and a few other extras such as the Circuit Python Community Bundle. We had 29 pull requests merged from 19 different authors, including a few of the names Jeff read off earlier. I noticed that in some of those merged requests, we had one that was 57 days old and one that was 21 days old, which is great. It's always good to see that we are keeping up with the older ones, but many, many, many of those were new. So it's also excellent to see all of the recent contributions. We had 19 authors, I believe I said that, and eight reviewers, leaving us with 50 open pull requests. We had 17 issues closed by 11 people and 10 opened by eight people, so we are net down for 284 open issues. There are seven good first issues. That is a label that goes on issues that are excellent if you are new to contributing to Git or GitHub, new to contributing to Circuit Python. They're a great place to start. If you're interested in contributing to the Python side of Circuit Python, consider going to CircuitPython.org slash contributing. You'll find all of this information and more, including a list of open pull requests, a list of open issues, and some library infrastructure issues as well as how to contribute to translating the Circuit Python core. The list of issues you can search by label. So if you're new to things, good first issues, a good place to start. You want something a little more complicated, bug or enhancement are both good. And we have a guide on contributing to Git and GitHub or contributing to Circuit Python rather using Git and GitHub, and we're always available on Discord to answer questions. So don't let that part of things intimidate you. We want to make sure that you help in whatever way makes the most sense for you. Reviewing things, you can basically just take a look at it, leave a comment, let us know you took a look at it. Any reviewing helps. And also, if you have been doing that for a while and you want to level up to actual reviewer, let us know. We can walk you through what that involves. And the more reviewers we have, the more authors we can support. So we're always looking for more reviewers, both on the core with the 23 open pull requests there and with the libraries having 50 open pull requests. Having more reviewers is always an excellent way for us to keep up with that a little bit better. And we had one new library this week, the SSD 1681. And I believe we had two new community bundle libraries as well, which it occurs to me perhaps I should get listed in this data. And a number of updated libraries that I won't read off. And that's where we are with the libraries. Very nice. Thank you, Catney. And with that, I will hand it to maker Melissa with the Blinka stats. Hello with Blinka, which is our circuit Python compatibility layer for Raspberry Pi and other single board computers this week. We had four pull requests merged by three authors and two reviewers. First, there are three open pull requests remaining, and there was one closed issue by one person and two open by two people, leaving a net of 52 open issues. There were 1,361 Pi PI downloads in the last week and we currently are supporting 67 boards. And that's it. Thank you. Next section is hug reports. In hug reports, we invite you to take a few moments to tell us about what the awesome people around us in the community are doing. Usually this is focused on Discord, but people on Twitter and GitHub and all those other places are also fair game. I will start and then we will go down the line alphabetically with everyone who has put their notes or placeholder in the document. So I would like to start off with a group hug and next thank Scott for hosting me on his deep dive as well as everyone who we chatted with. I didn't actually go back and note down those names from the Discord chat, but you know, the community was as always very positive and had a lot of great questions for us to discuss. And I think we went for about 90 minutes. I was planning to be on for 60 and it was just fun to hang out with y'all and with Scott to Zoltan V923Z for promptly responding to ULAB items as usual. We kind of expect that feeling a little bit spoiled. But yeah, and to the PCB design channel folk, including SCUR for giving me compliments on a rather boring PCB design. But one of my goals for 2021 is to get a little more into the groove of designing PCBs, whether or not I actually order them and I shared up a design that, yeah, people are great. So I appreciated that. And next I will pass it to Jerry. And after that I will have notes from Jay Furstein. Hello. Thanks to Dan for getting that second CDC port working. It was nice to have a new toilet. All right, I have notes from a couple of people and then I will hand it to Catney. Jay Furstein writes, how to anecdote and Naradok for helping debug a socket issue in the requests library and to geek mom projects for her LED art and circuit Python talk at PyCascades. I saw the talk go by on Twitter and I haven't watched it yet. I'm not sure if the video is up yet, but definitely hope that I have a chance to see that because her projects. Yeah, they are great. All right, next I have notes from Jose David M. Who is missing the meeting who says thanks to K match 98 for reviewing and keeping the conversation open conversation open to micro dev for implementing you art for the Pico to Naradok for always helping in discord. It is inspiring to witness and to fo me guy and Scott thanks for the streams. It is important as a community builder tool. And in the text chat they are discussing that the videos will be up in a couple of days. So look for those videos from PyCascades. I think they're going to be a treat. I have no doubt of that. And now I will hand it off to catney. Thanks Jeff. So, a spoiler alert for part of my status update, but I want to say thank you to everyone who's contributed to the eight fruit circuit Python libraries and to the community bundle. We've passed 300 total circuit Python libraries available. I want to have a hug report to Hugo for working to add pilot to the pre-commit to ask Patrick W for continued work on startup. Thank you to K match 98 and fo me guy for continuing to work on the circuit Python UI elements and to Crayola for spending multiple days in the labyrinth that is JavaScript to help me with my website and for helping me with my new theme. Thank you. Let's see next is K match 98 and then after that is maker Melissa. So go ahead. Thanks. So first off, thanks to catney Jay for seeing and Hugo for guidance on Sphinx. It's cryptic statements and have especially how to learn about incorporating class inheritance. Still a lot to learn though. Thanks to fo me guy for feedback on the widget and control classes, which are in PR right now. Thanks to Jose. Jay Posada 2020 for a quick improvement on bitmap label, particularly for how to adjust text and arrange it cleanly. And in fact, I use it that same day that he submitted the PR. So thank you for that. And Jeff, thanks to you. I gave you a hug last week, but I thought a little more about it and without starting an arms race on levels. No pun intended. I want to deserve more, more hugs this week that your work on adding the bitmap font to handle PCF fonts. Not only is it faster, but you also thought through all the challenges of getting the font into the right format and even gave a website to convert those fonts. So basically it's a good example of not just solving one, one small issue, but everything that takes to take advantage of it. Special thanks for you for sharing your skills to do that and an example that we can all strive toward. And lastly, Hugo, thanks for improvements in the progress bar and a special call out for your positive attitude. Thanks for all your work. Thanks. Thanks. I'm blushing a little bit over here. All right. Next we have maker Melissa, then read notes from micro dev and after that, Naradok. Go ahead, Melissa. Hello. First of all, I want to give a hug report to Dan H for your help with getting my system set up to compile circuit. Hug to Scott for the groundwork you laid on display. Displays, which made adding another one pretty easy. I wanted to give a hug to K-Mesh 98 for your suggestion about adding rotation matrix portal. So I want to you, Jeff, for reviewing some of my code to ask Patrick W for your work on the cookie cutter templates and to print for writing the date time library and the group hug to everyone else. Thank you. From micro dev, we have a group hug. So next is Naradok and after that and toll. Oh wait. Okay. Naradok is lurking. Maybe it said that and I overlooked it. All right. Naradok says group hug to the whole community for its warm welcome. And specifically a hug for ask Patrick W for more sir cup goodness. To Dan H for the second CDC channel and insights on why Mac Py serial incorrectly identifies the channels and a belated hug report to catney for welcoming me in the circuit python helper role. So we'll go to end toll and then to 10. Hi folks. Hello from the UK. So I just wanted to say thank you to those circuit python Easter's making thoughtful contributions to the discussion over in the repo for the new editor about how we might make the circuit python mode even more polished and useful for our wonderful users. That's it. And for everybody else. Thank you. Thanks. It's nice to hear from you. It's been a little while. All right. I will hand it to Scott. And then I have some notes. And after that we'll head back to the top of the alphabet. First off, thank you to Zodius infuser from Pimeroni for the board support PR that I'm excited to get to today. Thank you to Jeffler for joining my stream. It was nice to have a guest on next. Another PR I'm looking forward to is from June to sack for a PR for deep sleep on the nrf 52. This is something that's definitely been on our radar and it's cool to see it come in even before we expect it. Thank you to Dan H for knocking out a few of our older oldest issues with the secondary USB CDC. And then lastly, in case folks don't know, hugger put the folks over at J-Link who just did a stable release of the J-Link software that includes RP 2040 support. I plan on using that today. So those are all my hugs. Very nice. I'm using the Pico probe and it works really well. But I'm down to two Pico's that aren't permanently embedded in projects. So I don't know how long that's going to be a workable solution. Anyway, I think TG techie is going to talk next. So I will hand it to you and then head back to the top of the alphabet. So yeah, go ahead. All right, at the top of the alphabet, we have notes from a few people. It looks like the next person who I won't be reading those for is the shippu. But now we have asked Patrick W who has hug reports for me and for Katny for the PR reviews on CERCUP. And hugs for microdev and Ski East for picking up the update ESPIDF to 4.3 work and running with it. Next we have notes from Sea Grover with hug reports for Tenuit and Lady Aida for the encouragement to challenge my software development limitations and a group hug to the team and community. Oh, and I was incorrect as to who's next. It's you, Dan. Sorry about that. Thanks. Hug report to Neridoc or Neridoc in Discord who's been doing a whole lot of helping people overcome the usual sorts of problems. It's very helpful to have multiple people who know how to fix things. And thanks to you, Jeff and Zoltan for quick fixes to ULab to fix a bug that I originally thought was a BLE bug, but it turned out I was just using ULab to compute some microphone data and it provoked a certain bug based on ULab. And that got fixed basically over the weekend and is now incorporating this drift. Okay, thanks. All right. Thank you. I'll read some notes from David and then pass it to the Dishapoo. So David writes a hug report to Tenuit for the Circuit Python 2021 roundup and PWM. I'm not sure what PWM. Oh, I guess literally PWM. Dan H for the second CDC serial. Oh, PWM audio out on the Raspberry Pico. A hug report to me for the eight NeoPixel thing with PIO and the book on binary hacks that I recommended in the stream. And to Dishapoo for the Display IO Tetris. So next is Dishapoo and then FOMIGuy. Well, in case Dishapoo isn't there, they have a group hug. I'll pass it to FOMIGuy and then Hyrofect. And then we'll wrap it up with some notes that I'll read. Hugs this week. Anybody who has tuned in to my streams on Saturday mornings, if you caught them live or watched any of the videos up on YouTube, I've been having lots of fun with that and learned new things from the folks who are watching. And that's kind of become one of the things I'm acceptably looking forward to each week. So big thanks to anybody who's checked that out. To Jose, Jay put us the 2020 GitHub for diving into an issue with tab characters that were they're getting basically ignored inside the display text label. And Jose took a stab at tackling that to Hugo for looking into and starting up the PR on a cookie cutter for moving a pilot action inside a pre-commit. And also a couple of, I'm a week or two late on this one, but Hugo wrote up a really nice page that covers some helpful git commands like renaming branches and things like that that I was asking about. And Hugo put that together. So big thanks for that as well. And lastly to Kim, Qash98 is always doing all sorts of great testing and has thoughtful discussions and ideas and things on many, many different layout PRs. So mine, some others, I see that name came out by a lot working on reviewing display stuff and I really appreciate that. So thank you there. All right. And just your note for Hugo made me think we were talking earlier in the internal meeting about whether subdirectories of examples were being correctly piloted. And so, Kenny, you might want to check in on whether this change of when the pilot action occurs is going to affect that as you look at the problem. Totally random. Sorry to interrupt. I'm going to turn it over to Hier Effect for Hug Reports. Thanks this past week to Dan for helping answer some low power questions as I work on that implementation. Thanks to Brent for his testing help on some last straggling socket issues and a group hug to all. All right. And I will wrap it up reading the notes from Hugo, who has a work meeting at this time. What's really more important, Hugo? Anyway, Hugo has a hug report for Kenny for being trusting enough to let me take a crack at the pilot change in Cookie Cutter. To ask Patrick W and me for the input on the pilot in pre-commit change. To FOMIGuy and Kmatch98 for feedback and testing of the progress bar. And finally to Kmatch98 for spring thought and discussion on inheritance while working with Sphinx. And that wraps up Hug Reports and brings us to status updates. In status updates, we invite you to take a few moments to let us know what you've been up to in Circuit Python and beyond. Since the last time we had a chance to talk and what you hope to get up to in the next week or so. Again, it's an around Robin. Works a lot like Hug Reports, but it's a little drier. So I will start and then pass on to Jerry. So last week my biggest work was on code and text for an upcoming guide with driving eight NeoPixels from the Raspberry Pi Pico with a shift register and code running on the PIO IO processor. It was a lot of fun. I learned a lot. I also did various bug fixing that some people alluded to during Hug Reports, particularly in microlab. And I took a patch that I had made to implement a function called memoryview.cast, which is in standard Python and wasn't in Circuit Python. Dan helped me merge that into the core. So if you need it, it's there now. And this morning I looked at the problem on RP2040 with storage.erase file system. Discovered that it has to do with low level USB stuff. So I kicked it over to Tak, who is the author of Tiny USB to look at. This week this got a little bit reorganized in the meeting. So my number one is to work on a second guide of PIO plus Circuit Python, which will kind of look at some of the examples from the SDK, from the manual for the microcontroller itself, and from the examples repository where it makes sense. We'll adapt those into Circuit Python, explain it more or less, try and give an overview of the PIO assembly language, all that good stuff. I'm not sure exactly how long that'll take, and it may come out in bits and pieces. The new PIO guide is finished, but I have a feeling it makes sense to just hold that until after the next beta. So that people don't have to get an absolute latest to try out the code. And at some point I will get back to looking at this Protomatter bug that exists on RP2040 only, and is related to accessing the USB drive we think. And as for fun stuff, the temperature outside is above freezing. So pretty soon after this meeting, I'm going to go out and take a walk. And I've just been reminded that I was supposed to start with a mini in the weeds from Entol. So let me find the right spot in the document to drop that time code, and I will hand it over to you, and I'm sorry about that. So yeah, go ahead. No problem. I hope you can all hear me. So thank you very much first of all for letting me interrupt as it were, and get things out of order. Sorry about that. I have a meeting immediately after this one, so I really appreciate your flexibility. So I'm involved with the Mew editor, and there's been a huge amount of work on Mew during COVID lockdown in the UK and in Western Europe, which is where most folks working on Mew are based. But I just want to shout out and recognize contributions from Frank Morton. I believe Frank is actually on the call. I can see the names in the channel. And others in the Circuit Python community who have made either pull requests or bug reports or suggestions about how the Circuit Python mode in Mew could be improved. And it's become apparent that rather than turning this into a terrible exercising cat herding, wouldn't it be good if we just all got together, had a lovely cup of tea, sat down and had a chat about what we might want to do, and then everybody's on the same page. So if you follow the link that's being posted, thank you, Fomy Guy, in the chat, you'll see that I've summarized basically where we are. I'll drop a doodle poll into that PR chat so people can tell me exactly how all the time zones conflict. And we'll try and work out the best time when we can get together and have a chat and figure out what our story is for improvements to the Circuit Python mode because we hope to make a new version of Mew released very soon. Lots of lovely, shiny things coming in that. Thank you very much. That's it from me. Thank you. I'm not a user of Mew myself, but when you see it in all of our guides, you know that it's very important to how we see people entering the community interacting with their Circuit Python boards. So I appreciate that you're engaging with us on that, and I hope great things come out of it. Meet it. Meet it. Thank you very much. All right. So getting back to the flow of things, now I will hand it over to Jerry, and then I have some notes to read. Great. Let's see. So it's been a bunch of time playing with the new CDC stuff. I've tried out a bunch of different boards that are 52 and the Pico and now 4 Grand Chantral. It's been fun to play with. Now I've got to figure out how to do it. But otherwise, the week was spent with just lots of unfocused explorations of various things like I usually end up doing. I'll probably do a lot more of that next week. I have no idea what I'm going to be doing next. But I am working on getting my bird cam back out for deployment. I had a great success last year with it. The I-0W, the camera built into a birdhouse. Then last year we got two nests in and got to watch the eggs hatch and the chicks grow up and fledge. That was really a lot of fun. This year's big change is to take the new IR camera out and put a regular camera in. I thought the IR would be fun and be able to look in at night, but it turned out not to be very useful and it really degrades the picture quality. So hopefully it gets a bunch better pictures of the little birds this year. Alright, so next I have notes from Jose David who's missing the meeting and after that we'll go to Catney. So last week, Jose updated the base alignment feature for Bitmap Label, which I am really happy to see by the way, a belated hug report, a PR to solve the label not seeing tab characters in strings, Spanish weblight translations, and studying the I2C peripheral. Next week, pull requests to solve the tab issue in Bitmap Label and update Read the Docs for the display library after all the changes. After Catney, we will go to Kmatch 98. Alright, so last week we surpassed 300 libraries. We, and I think this was an excellent decision, decided a few months ago maybe to start including the community bundle and all of our numbers and all of our data, which is why the library section covers some extra special stuff including the bundle. And for the Python on Harbor newsletter, we always include a number and that was kind of actually what sparked us to start including both, was that we decided to start including all of them in that number. And so when I put together that section of the newsletter last week, I noticed that we hit 300 libraries. So that's really exciting and actually we're at 302 now. Last week we hit 300, but we had two, both an Adafruit One and a Community One merged this weekend, which is excellent to see. So there'll be a blog post about that and we'll go into the newsletter. The more that you folks help us, the more stuff we can do and the community bundle is as it sounds entirely contributed by the community. So that's really amazing. There's I think 36 libraries in there. It's not a small thing. It's a significant percentage of the total libraries. So thank you to everybody who's been contributing to the libraries. Thank you to everyone who's been reviewing. Thank you to everyone who's been authoring. Thank you to all of our community bundle contributors for helping us get here. So also last week I finished up the Pico guide. The getting started with Pico guide. We did almost everything we wanted, but there were two things we couldn't do at the time that I'd done the guide. The features hadn't been implemented and one thing we just didn't get to. So that has all of the stuff we want in it now, minus a still being updated FAQ slash troubleshooting page. So that will continue to be dynamic, but the guide itself is done. I updated the guide for the MLX90393, I think, because I typo that constantly guide for the STEMIQT revision. So the STEMIQT rev is in there now and all the wiring diagrams for the new version and all that stuff are there. I added some further documentation to the Feather Can guide. And on Friday I worked with Ann to start learning how to take over the newsletter. Ann's going to be out for a bit and Ann does all of the superstar work that makes that newsletter happen. And so I have been asked to take over that while she is away, which means over the next few weeks this will be popping up in my status update each week because I'm going to be working with her. So we covered some of the initial steps and a bit about adding content. This week I already added the PCV files for the PyRTC to GitHub and worked with Ann on... I'm going to be working after this meeting, going to be working with Ann on publishing, on the publishing end of the newsletter because that happens on Mondays so we couldn't really cover that on Fridays. And over the weekend I forgot to continue these notes. I will finish them when I am done talking. I published a new theme for my website which was a huge undertaking updated to use the latest of things which there were no examples of so it was a matter of kind of doing everything from scratch. But it turned out really well and I'm really happy with it it's got some excellent features thanks to Crayola who I mentioned earlier and I'm really excited about that so that's been published so I can actually go back to publishing content because the way that the site is generated I could have worked in a branch on the update but I didn't of course which meant that if I published content the half working theme would also have been published with it so I needed to wait until I got it into a working state before I could go back to publishing content but I've reached that point so I'm very excited about that and that's my update. And I think that for now you are pausing your hosting of the weekly meetings is that right? Yes, I am not going to be hosting any of these, I'll be attending but I'm not going to be hosting these meetings because the newsletter stuff all happens on Mondays I'm nodding over here but you can't see it The publishing of the newsletter all happens on Monday as it goes out on Tuesday morning and so when you host this meeting there's a good hour, hour and a half of extra stuff you do afterwards depending on how whether YouTube agrees with you or not that sort of thing and so that extra time will be huge for me to be able to put into the newsletter and also to put into working with Anne on learning about the newsletter so for the next I want to say something like 10 weeks I will only be attending, I will not be hosting you will be hearing from Jeff and Scott only Or if you're sick of hearing from the two of us we will take volunteers but yeah, anyway, that's probably too much to hope for I'll pass things to Kmatch98 and then to Maker Melissa So last week I continued work on these graphical user interface elements and actually submitted a clean pull request for just the widget and control classes These are structure, the widget is more about the graphical display and control is more about how the widget should respond to touch events So that's pull request in place there Also a related note is I got Sphinx set up so I could run on my local machine so that helps iterate a lot more quickly on seeing the changes and debugging the weird commands that Sphinx uses And last item from last week is I added some easing functions they're called for animating widgets which make them springy or moving slow and fast however you like them, different options there This week I hope to update the widget and control class documentation in particular I guess related to some other items is to figure out how Sphinx can make sure all the inherited properties are well documented with the vision that people don't have to hunt through a lot of different layers of documentation to figure out all the features of a given class Next I want to get my first widget in a PR which is the round switch So I need to check that to work with the grid layout function which helps to speed laying out different widgets on the screen And once I check that I want to get it documented and send it to QR this week I'll talk about Sphinx there Also the latest progress bar has been making good progress So I want to take a look at that in the latest updates And then last I still want to do list the fancy bitmap functions I need to organize those better so they can fit into the core as an option to build And then lastly, so other quasi, or let's call different stuff So here in Austin it's 70 degrees today which it should be in February but we went through about a week of sub-freezing weather so a lot of work to dig out from that So I'll be working on plumbing which is a lot like software development is playing whack-a-mole So that's for this week Alright, after maker Melissa I believe I'll read some notes from Mark Go ahead, Melissa So last week I finished writing at the 1.5 orange ink guide I added the from ISO format function to the date time library And I updated a project for John Park to use the date time library which used that function I did some troubleshooting on I2C software set issue with Circa Python and the ESP32-S2 and I put some notes in the GitHub ticket I wrote my first e-ing driver for the SSD1681 which is the new 1.5 orange display And I started working on getting the e-paper display SSD1681 driver on Raspberry Pi to work This week I'm going to finish getting that working Just like not writing that spy data for something so I'm setting up a fresh Raspberry Pi I need to update the e-ing guide for the new Pythonian drivers I need to test out a new ST7789 Raspberry Pi display driver for doing the frame buffer copy If that works I'll update the PiTFT script I need to update the gizmo library to test out the SSD1681 display on there And if there's time I'll take a look at adding rotation to the magtec library And that's it Thank you Melissa I have a few sections of notes to read and then up after that is Scott So notes from Mark, also known as Gambler Taking a look at Count I.O. on RP2040 I have a question in the weeds about how to read it in the background Then notes from MicroDev who is also text only today Implemented RP2040 UART And working on merging in MicroPython v1.14 I have got MPY Cross building successfully Ports are next And in the notes document there is a link to the branch itself So if you're interested you can take a look there And I think from there you can probably figure out how to download the code Anyway, if you have questions about using GitHub in order to check out MicroDev's work We would be happy to help you with that Next up is Scott and then TG Techie Awesome, thanks Jeff First up for me I have to finish this audio work I have PDM test code with PIO But it is like hanging and or crashing Like the USB disappears so it's no good But luckily J-Link just added support So I'm hoping today after I get through email and stuff I'll be able to get some time to use the J-Link on the On the RP2040 feather to figure out where things are going Haywire with PDM stuff And hopefully once I get that fixed Then I'll be able to get PDM in working And then have a pull request for I2SL and PDM in The next thing I have to do after that Is I need to add a stop gap for flash size configurations Per RP2040 board It'll be super basic It'll just be the file system size It won't handle like how the flash is connected up And what flash chip it actually is That'll come later But we're starting to see chips hit manufacturers From Raspberry Pi And so we're going to have more boards for the RP2040 imminently So getting a stop gap in there is critical Because we don't want to We don't want to do board definitions With the wrong flash size And then upgrade them to a different size later Because that would require a file system rewrite So that's top of mind And then I want to get your merged in If microdev hasn't finished it And then also rotary I think I want to I have a weight I have ideas on how to do all these things I just need to sit down and do them So that's why I need to finish this audio work So I can move on to some other stuff That's it for me Sounds like your play is pretty full Always It's good Please can be busy I'm busy and employed Yeah All right TGTechi is up next And then I'll go to the top of the alphabet I think everyone's been up to a lot of fun things Okay So last week I Thanks to Dan H Finally I built it working on the smartwatch Which has been Months And months in the making And I ended up dead bugging A raw NRF To do a 40 module And just building it up from scratch And it wasn't Oh my God It's crystal Thing goes away It's because I was controlling it And that's what it was Until I couldn't find it at all Performing In the LC 709203 driver And that's down into the People It's a similar experience And I The non-divisions reveal In non-circuit pipeline New And next week I'll be doing some TGT work Surprise And Trying to wipe the boot Or off of the metronome 4 Which has been very Diverently hanging off With the Poodos Quickly to work On the rectangle Oh memory light Rectangle For display O I meant to get to it last week But school Not in the life Or School needed to And That's all Thank you Moving back To the top of the alphabet I've got a few people to read And then Dan will be up after them So from Ask Patrick W We have Last week They updated CIRCUP To use the requirements.txt Released in the bundles Added pre-commit And made the repo And dev workflow Feel like other CIRCUP Python Library repos And Using a Feather S2 And BME 680 To monitor my refrigerator We think the thermostat is off Because it is freezing things And this week The plan is to start looking At the Azure IoT Library Work to support sockets Next I have notes from C Grover Who submitted the learning guide For improving the low speed Performance of brushed DC motors By adjusting the PWM Frequency parameter It was the result of needing to Obtain smoother start-up movement Of the string car racer And other DC motor-based robots Low speed movement is especially Critical for the string car When it's searching for end of String to prevent an acrobatically Fatal collision The guide provides a few practical CIRCUP Python examples derived from A custom motor testing apparatus That measured motor PWM frequency Response spectrum The motor kit library was modified To permit adjustment of the PWM Frequency as well After the all too long distraction Into DC motors It's time to take stock and Reprioritize the stack of Unloved projects Unless these two picots Managed to squirm to the top Oh yeah After I look into submitting a PR To add UV index and luxe Gitters to the LTR 390 UV sensor library And unrelated Took on a challenge to illustrate A book of poetry for young adults I'm not an artist so this is Definitely out of my comfort zone Learned hide your doodles And so that we have Dan next And then I have weird notes from David Fixed a bunch of things There was an issue with the RP2040 PWM out that The peripheral sum of peculiar And top There's an off by one error That's easy to make so I fixed that And now it means that when you say 100% duty cycle and PWM out It's truly 100% And doesn't have a glitch in it Every 65,000 counts I finished the secondary CDC USB serial channel And a bunch of people are trying that Thank you very much As I mentioned before I was trying to debug a BLE problem That turned out to be a ULAB problem And that was fixed by Jephler and Zoltan Which is great I've been looking at various I2C problems on the RP2040 That peripheral doesn't allow you Zero length writes Which is how we do various things Like I scan for devices And if you look at MicroPython It uses BitBang I.O. for that And so I try to use BitBang I.O. In the same way And it turns out there's something wrong With our BitBang I.O. implementation And I just trying it by itself It doesn't work very well When you try to talk to I2C devices So I've got to debug that It's probably some tiny problem And there are various other bugs That I'm continuing to add And knock off for 6.2.0 But it's sort of like every day There's one or two new bugs that get added So you have to decide What's going to go into 6.2.0 At some point Okay, I'm done All right I have notes from David And Deshipu if you can let me know If you want to try your mic again That would be helpful David writes Received my ESP32C3 Had some failures with reading From more than one LWSD03MMC And adapting and testing Tetris On the U-GamePad 10 And now Deshipu is next Followed by FOMIGuy Having the display I.O. group By making it use the It's only internally So that you no longer Have to specify the margin of size And also so that you can use Some of these methods on it Such as salt And I have a PR app But it's... Adelaide didn't result in simplification Of the code So I have an indie weed To further discuss this All right After FOMIGuy We have higher effect on apologies For the background noise My wife was coming in And out the door And it is very squeaky door So if you got that Sorry, it's out of my control Anyway, go ahead No worries, thanks Joe For last week I merged the PRs There was actually two of them For display text For the base alignment New feature in there That will allow it to line up Different labels Especially when they're using Different fonts When this is most help You can align them up Along the base line That way they look nice Next to each other And you don't have to guess And check on pixels anymore We're doing and testing The progress bar And display layout PRs So Hugo's doing great work On the progress bar And came match On the display layout Libraries, couple good PRs in there Did some work Looking at those And reviewing them I finally made the leap To learn how to I'll say quote unquote Install pre-commit Which is to say Not like put it on my computer But make it run automatically Inside git They use the term install For that to make it go automatically So I learned how to hook that up And figure out how to use that And then last thing For last week is I successfully sent and received Some message packed data Over Laura RFM radio So message packed New module in the core That just got merged in Somewhat recently A couple weeks back And I was able to use that To send some Like JSON data pretty much Across the radios So that was really cool For next week I'm gonna get started On inside the learn system On a new guide that will cover Display text So there's some documentation Out there on GitHub But go ahead this past week To move that into a learn guide So I'm gonna get started moving All that stuff in And getting screen shots And everything together For a real nice comprehensive Guide for text I'm gonna make a PR For linear layout Inside display layout We have grid layout right now Is the first one that's in there But I did have a linear layout From some older work I did So I'm gonna go ahead And put that in this week I need to go and dig out My matrix portal Because I wanna do some testing On that with the progress bar PR There's a new matrix portal Example in there And then last thing for me next week Is gonna be Last thing that I could think of As of today anyway I was gonna be testing out The fix for the tabs The way the tabs are getting Taken out of display text levels So I saw there was a PR Out there for a fix for that So I'm gonna look into that this week That's it for me, thanks Thank you Next I will hand a tire effect And then wrap things up With notes from Hugo Alrighty This past week I hacked a bit At the Ice Word Proceed problems At USB 32 S2 With a debugger Kind of dug in there enough To make sure that it wasn't something Somehow that it was trivial That we had missed It doesn't seem to be that It seems pretty airy I got some decent test results But didn't make a whole Kind of progress there Still kind of waiting on us To wrap up all the stuff About upgrading the IDF And that kind of stuff To hack back into that My big project That was past week Before on the STM32 That's involved a lot of Kind of get various modules Out of other modules So that they can be used Cross modules So putting pin interrupts I had to extract the pin interrupts Out of Pulse-In Which was the only place They were used earlier And into their own Little separate Shareable area So that we can Put them into pin alarm Gonna have to do the same thing With the RTC Which is currently Completely implemented in port.c And really needs to be Implemented across stuff But the benefit of that Is that some of the STM32 modules That were sort of intimidating Because they were going to Require those extractions And all the testing That's required with that Are going to be made A lot easier once low power Is done So putting in RTC Or rotary IO Is going to be a lot Simpler once we get Some of those extractions Out So those might be Some low hanging fruit modules So just kind of really Quickly bang out After the low power stuff Is done So this week I've got a pin alarm Working I just need to Wrap up time alarm There's no touch module On the STM32 Yet we would have one If we had the L Series of STM32s But the F4, F7 And the H7 Don't have them So no touch IO Or touch module For low power wake up Right now So that's what I've got on The list for this week And then Yeah We'll just keep Hanging about stuff After that And that's for me Thanks I will round this out With notes from Hugo Who reports last week Got 98% Through the progress Vertical progress bar updates Fixed issues And suggestions from other PB issues Into the current one And started working On moving pilant To pre-commit This week Wrap up progress bar Refactor and vertical Make sure examples Still work As expected on devices Not just Blinka On computer ones Work on cookie cutter To incorporate pilant Including documentation Of changes To apply to existing libraries Add support for anchoring In progress bar And might take a detour From the progress bar And work issues Work on issues in other libraries And Hugo has opened the suggestions And or requests So that wraps up status updates Thank you very much We will now Head to in the weeds That was interesting We've already heard from Entol But now we will go to Hugo's item Which as he's missing it He invited you to talk about it You feel like doing that? All right Let me just take a quick Oh yes, yes, okay So this was in It came up in the progress bar library But it is I suppose a more general Question than that In libraries where it's Inging from a single Python file into a package Typically we have to go back And change any code That was making use of that library So like, especially anything inside The learn guide repo Or any other examples That might have been making use of that library We have to go and change the imports I figured out a way Tinkering with it over the weekend Where I can put an import Into the bottom of a nitpie In the package And it can make it The original import statement Like without the extra dot And the module name But it can make it work With the original import statement Without having to change anything But what I didn't know is like The rest of the implications Of that I didn't know if importing that thing Would lead to, I guess probably Taking up extra memory sometimes And potentially not getting used by The user So generally speaking my question is like Do we want to do something Like that where we could add Imports into a recently broken Part package library To get it to work with the old You know, importing api Or is it better to just kind of Rip the band-aid as it were And you know All the code will have to change And we have the means to go and do that But not worth necessarily trying To add that import into there So I think generally it is Good to have it in Anit.py for backwards compatibility I think that I mean, the thing That I would check that I'm not positive on Is just that if you import the Individual modules it uses Less memory. I think that's true Only unless the Individual modules then import the top level Thing, like the init But I think that's true Basically like I think it's a good idea Assuming that You get backwards compatibility By having the import in an it But you can also use the specific Module if you need it Yep, it does work on both I did see that when I was messing with it Those work with the new way as well Okay, so I would assume that The new way would use less memory And that means that if we find examples That do have trouble because They use too much memory I would just whack them all those as they come up And just move them to the new api Like the module specific one As needed rather than having to Force yourself to find every single One of them up front Okay, cool I will make a note on That progress PR To leave the little Import that I found there and we'll plan on putting that Instead of init and then keeping an eye out For any reports Of memory issues Awesome, thank you so much for doing that I think the only caveat Worth including here is If there are examples That exist that would Benefit from the new Structure It's probably worth updating Like not, obviously leave The code so that it's backwards compatible But let's say there's an example In the guide specifically with the progress bar That talks about You know expanding To different options for progress bar Or something like that And it ends up being worth updating to use Package import It's still worth even though you set up Backwards compatibility it's still worth checking To see what examples exist already And make sure that none of them Make sense to be updated Okay, yeah because it could I can see how that could add clarity By doing the new import it would kind of add A little bit to that Yeah, in a lot of places It's probably fine just to leave it alone But you never know and so it's just worth Taking, you know 10 minutes to just, you know, search through Learn and make sure that there's nothing That could be useful Cool, alrighty, thank you Appreciate insight from both of you Yeah, that's a good point, Kathy Thank you And that covers it for you guys Talk about the topic there Alright, thanks Next I have a topic from Jose David who is missing the meeting Related to a lot of discussions in discord And the work in the new progress bar I saw that there's a function To transpose A x y tile as a bitmap I'm wondering if we can apply The same to a character and have vertical text I.e. for the progress bar or label Any insight is appreciated So I assume this is The transposing code That I added to the core For The neopixel thing And it is not Directly applicable to Display IO bitmaps Scott, do you have any thoughts about Just generally rotation and Display IO and how that might work It's been so long I know there is an overall Display rotation Which means that kind of in there We do have the code to Rotate a bitmap But we can't do them on a one by one Or a display group By display group Well, I'm sure So the terminal IO for instance Is a tile map So you can rotate tiles In display IO You rotate the whole thing You don't rotate You have a tile grid That has several tiles in it It's larger than one tile You rotate the whole tile grid But I don't see why You wouldn't be able to display Basically So for a A traditional Text label which uses A bunch of tile grids Then you could Rotate each tile grid 90 degrees And get vertical text But it wouldn't work for The bitmap Font where it writes the Pixels of the character No it would because you could rotate that too It would rotate It rotates the whole bitmap So yeah, I think it should Be Possible to make a rotated label Of either kind out of the code we have It's just The one, particularly the One based on multiple tile grids One per character Would need to track where the pixel Where the character positions are Differently But none of this would directly use that new code It sounds like if we can rotate tile grids That it's all there already And foamy guy writes in the text chat Some of the new bitmap manipulation functions That Kmatch 98 is working on Which I forgot about Might be helpful for rotating bitmaps as well That's true, one of Kmatch 98 items Kmatch 98's Items that he's working on Is a general rotation of bitmaps And that would include 90 degree rotations So I think there's definitely A number of directions And so I hope that Jose will try some out and report back On what works or what doesn't work And so now I've got Another In the weeds to read And this one is from Mark Who says I looked at COUNTIO for RP2040 The PWM counter wraps At 65536 So unless the user is actively reading it It would be very easy to wrap And have no indication My thought is to use a background process In port background to just read Slash update this if it's active Just making sure that sounds correct My gut Is that that's certainly one way to do it You should be able to make your background Task run Frequently, but I don't know To call port background you probably have to have ticks Turned on, otherwise it's not going to Necessarily call it And of course Tracking the overflow From an interrupt handler is another way That Is kind of more resistant to stuff that's going on In the foreground of circuit python So I think that would be the better way Just totally off the top of my head Without knowing more about how exactly the PWM Works So there the idea would be You would create an interrupt handler for the overflow And do the thing there Rather than doing it in port background And you were saying something Scott Oh you're right I would do interrupts We don't have anything against doing interrupts In this core C code That's totally fine We do it everywhere It is a little weird on the RP2040 Because the Pico STK Has their own interrupt API And the reason they have that Is because they try to manage the Multi-core part of it But I think I do have Examples in some of the other peripherals Where I've done interrupts I just kind of do it myself Because it's more similar For me to just do it myself Because I've done it before On an acortex M0 before Right For those of you who have The way the interrupts work on the RP2040 Is that there are wires connected From peripherals to what's called The NVIC The nested vector interrupt controller And usually on the same V21 You have one of those for the core But the weirdness with The RP2040 is that it actually has two NVICs, one for each core And so if you're not careful You can end up enabling Running code based on the interrupt In two places And so that's why they have different stuff Since CircuitPython is single core right now I just kind of do it directly I'm happy to help with that If Mark needs more pointers on interrupts And when you say you did it directly Are you saying That's a fine way to do it Whichever way you're more comfortable with Or would it be better to do it your way Or better to follow the SDK As someone arriving at it fresh I think either way is fine I think using the SDK is fine If you read the APIs and it looks okay It's just that like I've poked the registers on an NVIC before What I want to be able to do is actually Control it directly from there So that's what I've done Just like directly writing the registers Of the NVIC I think either way is fine But I just kind of like I like to do it myself Alright Next we have an item from TG Techie This is a bit of a library In the week There's I believe a long running bug As mentioned before In the LC709203 After-driver chip That's the battery state of charge chip It has on the new Ishbrige board Where it will Presently respond to Request for expertise With a CRC error And what's happening out of the The chip isn't responding at all If you clear the In the library you clear The right buffer Before reading and writing You'll see that it doesn't change Except for the libraries Manually manipulating it And I know the clock does use Clock correction As curious if anyone had similar issues Where chip could be responding And it does sometimes But not always Common game people do iSquared C devices vary a lot And to how Responsive they are I think you're on NRF Right, like you're doing it from an NRF Yes I would So it's not just one unit It's in multiple ICs How do they have different addresses Sorry Not on this So I've tried with multiple versions I broke this because it overheated That one I know for a fact That having a logic analyzer makes All of this much I can't Do it without a logic analyzer Simply because then I know I can determine what's on the wire So I know source of truth of what I should be seeing from the inside But generally it's just Problems like this come from Just not reading Either the datasheet has something That tells you don't do this more than This often Or they don't But that's still true So it's probably just a quirk of the chip The chips have to Being an iSquared C peripheral is non-trivial Because you don't know What is going to happen until You get the data And you don't have any responsibility Or In iSquared C you only have clock stretching To basically like To say wait back to the The main Part of the iSquared C So iSquared C peripheral Is pretty tough You might find that there's timing Or requirements in the datasheet That just aren't being enforced That should be I'm a bit surprised here If you are getting All zeros That means that the chip is still hacking Every response It's not like SPI Where you just pull the pin down You're just reading zeros It still requires cooperation So apparently the Peripheral is still working on that other side It just has no data It's strange Well yeah, the other thing that occurred to me Is generally there are pull ups So if your device stops Doing something that it should have been doing Then The bus is going to end up in a high Value state And see ones not a low value state And see zeros I'm a datasheet I'm also curious If i get m4 or m0 And i'm going to run some Test But When i The other thing i remember About this chip Assuming that we're talking about the same one Is At one point i was going to look at it And i was admonished to make sure i had a battery hooked up And that if there wasn't a battery hooked up It wouldn't malfunction So i don't know whether you have a battery attached Or not, but definitely attach one And see if that changes the behavior If it's not there now It definitely does Okay You're welcome And for the last item I will pass it to Dishapu Okay so As i mentioned i tried to Work on this display IO Group thing And the initial idea was to make it Inherit from Alice So that groups are practically LISPs With some extra functionality in them That would be nice For reasons That you get all Of those methods For free basically And the second one is that you save a lot of space Because you don't have to Have all those wrappers All these parameter parsing And so on That could actually Shrink the Code we have in there And the problem i had With that is that It seems that Not all, some of the code In circuit bankon Assumes that a C Plus Is the last class Inherits from So there is this sub-object Member on the Instance And there is a lot of code that always Returns to sub-object Zero Instead of Proper index for the type That is code So there is this quite assumption That it's always like the top class Inheritance Hierarchy I wonder if there are If We want to work on this To make it possible to have More than one class In the hierarchy One of them more C class In there And I'm just not sure That's Yeah, I mean, when I recommended You doing it that way, I knew that was something Of like, I'm not sure it's possible Or supported I mean, if you're digging in the pipe Folder and doing that, it's always good To check to see if microphones changed it Um It would, I think It would be nice to have, but it's It's going to be a Kind of a lot of work, I think, so Yeah, maybe not even A lot of work, but pretty easy To make a mistake That affects the whole runtime Yeah, I mean The unit tests we inherited from MicroPython Are pretty good, so I wouldn't Worry a ton about Breaking Something in the VM itself Because of those tests, but Um If you don't want to do that, it's totally fine If you just want to have a list object Inside the group, instead of being a subclass Of it, you'll have to Redirect some of the function calls You want to Yeah, that's what I did in the end But the side thing is That makes it Larger than it was With its own dedicated code Reusing the list code makes it Larger Yeah Yeah, you mean code-wise? Yeah, I mean Yeah, yeah, I I don't have a good answer So a thing that I've seen The core doing There are, for instance When you think about things that store Collections of bytes or characters There are a bunch of types that are really similar There's string, there's binary There's Array And so they pull this trick Where there are distinct types With no other base type But they have The same structure layout At least for the initial fields And then you can put the same Methods in the Methods of your object Right, I'm wondering about Using this trick for all the layer Layer objects Because a lot of code Right now is The code that Checks what type This particular layer is And then calls The proper Methods on it And a lot of those methods are just identical Just take different types And if we Make the struct so that all the Shards At the beginning of the struct We could just cast Them At least for those common operations We could Cut them to the base And extract type And not care About checking I was thinking about that as a way To allow group to have The behaviors of list And so that would complicate Letting a group and a tile grid Then you couldn't make those Have the same initial fields So you could pick one or the other But not both We have more to win Doing this with layers And of course the other way To kind of get rid of those If it's this type do this And if it's that type do that Are protocols which are Tables of function pointers And we use that in audio samples And then it's also used in the core Like for File IO I think So that's another way If you want to unify this code That's checking for Types of layers as you call them Would be to adapt it To use protocols Most of those are just Setting a particular flag Or something like that A very very small function Just the fact that this flag Is in a different place In each of those objects Yeah it would be nice if that could be Regularized it might save some real Some important amounts of code I guess The other thing that Certain me about The list thing Is you would need to Intercept any call That actually changed the list So like the subscript A sign You would have to do the thing And then potentially redraw your screen So you can't only Do the list operation You have to do the list operation And then do something else I'm sure you're aware of that That's why we need We still need some wrappers But only on some methods Not on all of them And that's why also I cannot just expose The users I agree with that Because that would be Also some solution But then we miss the updates I think it sounds like You have a good grasp of this And it sounds like We did the nested list sort of thing And that's just the Cost of it I think adding a bit of size to it Is not the end of the world Well it depends on all those nearly full ports But We can often find a little storage to get back Right now The only one Pailing is the french translation Of the QTE Huxpress QTE by Huxpress I'm not sure What to do with this I tried to district with Inline limit But it doesn't seem to work I can take a look at that too Okay thank you If it's that close I think It would be great to just Yeah wrap that one up It would be great to just wrap that one up Yeah wrap that one up So basically I copied The special case for german Applied it to french Yeah It didn't change anything Maybe I got the language code wrong Okay well I'll look at your I'll look at your Is it pushed to your repo Yeah it's up Yeah I can look at those I've been trying to Decrease the number of special cases For various languages I just make the whole build smaller We don't have to do that Do a fresh build thing And it makes it consistent Across all languages Yeah exactly I noticed that the most problematic language Is always the one that has Most recent translations Interesting It does change over time Well to get off on a slight tangent I think as you Transition from a purely english Set of messages To a partially translated one To a fully translated one There's like this change in frequency And so the effectiveness Of the compression can change And also the translated messages I feel like they're Typically more verbose than english And I don't understand why that is But it seems to be the case Sounds like we have a direction on that And it'll be nice to see this work done So thank you for working on it But if that's it I will step ahead and do Wrap up So this has been the CircuitPython Weekly Meeting For March 22nd 2021 And Thank you to everyone who participated If you want to support Adafruit and CircuitPython And those of us who work on CircuitPython Consider purchasing from the AdafruitShop at Adafruit.com Did I say March? Well I was thinking about March Anyway, the video of this meeting Will be released on youtube At youtube.com 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 is March 1st I think At 2pm Eastern, 11am pacific And just a warning that In just a couple of weeks the US switches To their summer or daylight saving time So Check out the online calendar For notification about that And apologies for saying March 22nd I meant February 22nd But I just looked at the calendar to verify That the next meeting was in March So stop laughing at me Anyway This meeting is held on the Adafruit Discord Which you can join at any time By going to adafruit.com To be notified about this meeting And any changes to the time or day You can ask to be added To the CircuitPythonistas role on Discord We hope to see you next week Thanks everybody Thanks everyone