 Okay, hello everyone. This is the Circuit Python Weekly for Monday, April 4th, 2022. This is the time of the week where we get together to talk about all things Circuit Python. I'm Dan and I'm sponsored by Adafruit to work on Circuit Python. Might ask, what is Circuit Python? It's a version of Python designed to run on tidy computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing hardware on adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join that server anytime by going to adafruit.com. Behold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern time, 11 a.m. Pacific time, except when it coincides with the U.S. holiday. In the note stock, there's a link to a calendar you can view online or add your favorite calendar application. You also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the AdSign Circuit Python Easter Discord role. As we said, there's a note stock to accompany the meeting and recording. The note stock contains timestamps to go along with the video, so you can use the dock to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you an option to skip around. After each meeting, you post the link for the next meeting's notes to the Circuit Python Dev Channel on the Adafruit Discord. Check the PIN messages, that's the push PIN image at the top of the channel, so that you can add your notes to the following meeting. If you wish to participate, but cannot attend, you can write up hot reports and status updates in the document for us to read during the meeting. The meeting is held in five parts. The first is community news, where we go over things that have to do with Circuit Python and Python and other things about Python and microcontrollers. The second part is the state of Circuit Python libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers, separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part of the meeting is status updates. Status updates is an opportunity to sync up on what we've been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you will be up to over the next week until the next meeting. This can be Circuit Python related or if you find that you're not doing a lot of Circuit Python work because you're renovating your kitchen, you could tell us that too. The fifth part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long to discuss in status updates. So that's how the meeting will go. So I'll start with community news and take a time step. And as I mentioned, this news comes from the Python and microcontrollers newsletter, which will come out tomorrow. We've just taken out some of the most interesting items that are relevant to Circuit Python from that newsletter. So I just want to note two new versions of Circuit Python came out last week, Circuit Python 724, which is a new stable release, and Circuit Python 7.3.0-beta.0, which is the first of the 7.3 series that we made a release for and so that we don't have to keep telling people to find absolute newest from the S3 buckets. As Ann reminds us, subscribe to the Python or microcontrollers newsletter by going to AdafruitDaily.com. In 724, we fixed an I2C power default thing on the Feather ESP32-S2. That board was revised recently and the new fix enables the I2C power to be on by default for both the old and the new versions of the board. And we also fixed the supervisor.reload function, which stopped working. And 7.3.0, the most interesting features to look at are experimental MD&S support. That means you can do things like find your board by typing CircuitPython.local in the web browser, some debugging help, hardware debugging help on a couple of boards, several boards, and some initial experimental USB host support. And also we merged changes upstream for MicroPython 1.18, which includes fixes and a few new features. We've got two other, three other interesting news items. I won't read this whole item, but Evan Upton, who's head of Raspberry Pi or the founder of Raspberry Pi discussed supply issues for Raspberry Pi. As you know, if you tried to buy a Raspberry Pi, they're really hard to get and they get sold out quickly. And the article that's a link in here is a good way for you to find out like what's going on and what Raspberry Pi is trying to do to mediate the situation. Evan recommends that you buy from authorized resellers. Don't be, don't buy a bunch of resell them on eBay. That's no good for anybody, except that one person to make a lot of money. And we really discovered that. And you should be able to get them if you keep trying. And they hope to keep working on this problem. So read that article, it's very, very interesting and helpful. The next article is about Adafruit.io. We reached a milestone. Adafruit.io is now storing over 1 billion data records. And the interesting thing about this is that in free accounts, most of that data in free accounts is deleted after 30 days. So this means that we have a lot of free accounts. And we also have a lot of people who are paying and they're keeping their data around. That's very interesting. You could read more details in the in the in the document. And finally, there's some interesting stuff that you can now use markdown the markdown markup language in Google Docs on the web, you have to enable it by selecting automatically to take markdown from tools, the tools preferences menu. And then it will notice that and you can use various features of markdown, not all of them, but you can use bulleted lists, you can use headings italic involved, strike through and links, and they will be expanded correctly. So take a look at that. It's a nice new feature in Google Docs. Right, I'll take another timestamp since that's where we are so far. I'll just we remind you the circuit Python weekly newsletter is a circuit Python community run newsletter emailed every Tuesday complete archives are at adafruitdaily.com slash category slash circuit Python that highlights the latest Python on hardware related news from around the web, including circuit Python Python and Micro Python developments. You could we love it if you contribute to this newsletter, you can do that by submitting a poll request to the on GitHub to adafruit slash circuit Python dash weekly dash newsletter. You can also contact us on Twitter with the circuit Python hashtag, or you can email CP news adafruit.com any of those are fine ways to get stuff into the newsletter we always appreciate contributions. So we'll move on to the next section now, which is the state of circuit Python library in Blinka libraries in Blinka. I'll take another timecode. Overall, in the past week, there were 44 pull requests merged. 19, there were 19 authors of the pull requests. I noticed a new user bite evil, who may or may not have contributed to before also maybe WR Diego and see Hemingway are unfamiliar to me. But I'm not sure. There were 12 reviewers of those 44 pull requests. And they were 18 closed issues, closed by 10 people and 21 issues open by 15 people. So relatively stable work kind of still kind of keeping up. Jeff, would you like to do the core part of circuit Python? Oh, sure. I suppose I can. In the core, our numbers were 11 pull requests merged from eight authors. And in this list, I don't recognize ero NGD. So thanks for your contribution. And we had three reviewers, including one by Scott. Maybe that was one he'd reviewed before going on leave and was merged subsequently, I'm not sure. As far as pull requests, we have 12 open, including several that are over 100 days. But I think those are in draft and are waiting work by the submitters before they move forward. Issues wise, we were the source of the additional issues with three closed by three people and nine open by five people, leaving us with 519 open issues. As far as the work Adafruit does on circuit Python, we prioritize those in the core with milestones. So the number of milestones for 7.2 point x, we have two open issues. For 7.3, zero, we have four open issues. For 7xx, we have 24 open issues. And the rest are things that will be addressed on a longer time scale, particularly when it comes to the long term issues. That doesn't mean that we don't hope someone will work on them. That means Adafruit isn't prioritizing that work right now. So if you want to help out, you can take a look at those long term issues and fix something that is going to be meaningful to you to implement or fix. And also, we've got eight issues, not assigned to milestone. I was going through some of those earlier. But I'm a little bit timid about assigning milestones, so I didn't finish it up. Anyway, as far as narrative about the core, Dan has really covered what we've been up to in terms of releases already earlier in community news. So I don't need know that I need to expand on that. More or less, we are in a phase of trying to make the software more stable rather than staking out grand new features, and that'll probably continue for the moment. And yeah, that's what we got for the core. Thank you. Okay, thank you, Jeff. I'll just note that some of the issues that are hanging out, some of the pull requests that are hanging out right now are they await merging in 808 because they break backward compatibility. So that's why some of them are so old. And it's perfectly fine that they're there. It's just not obvious. Right. Thank you, Dan. I'd forgotten that. Yeah, that's so it's not, it's not terrible that we haven't merged those. We're not, we're just waiting. Okay, let's move on to libraries. Now. So cat, that's your bailiwick. Go ahead. Thanks, Dan. So this applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit underscore circuit Python underscore as well as a few extras. Across all of those repos, we have 31 pull requests merged by nine authors and 10 reviewers. In terms of merged pull requests, three of them were over a week old. And the rest of them were all very recent, which is good because it means we're keeping up with older PRs but also keeping up with all the new ones. That leaves us with 26 open pull requests. And the oldest is 552 days old. I know we're still working through some of those. And some folks are just slowly contributing. And we want to, you know, enable folks to do that. Where it's where it's happening. So that's part of why some older PRs are still open. We had 11 issues closed by seven people and nine opened by eight people, leaving us with 620 open issues. And 199 of those are good first issues. If you're interested in contributing to circuit Python on the Python side of things, check out circuit python.org slash contributing. You'll find all of this information and more if you're interested in reviewing, check out the open pull requests. Take a look for syntax so on. If you have the hardware test it, leave a comment and let us know. It's always super helpful. And when you're comfortable with that, we can talk about upgrading you to the review team. If you're interested in contributing Python code or documentation, check out the open issues. If you're new to everything, the good first issues are a great place to start. And there's also a guide to contributing to circuit Python using Git and GitHub available. And we're always on Discord to help out. So don't be intimidated by any of that. We will enable you to be able to contribute in a way that works for you. In terms of library updates in the last seven days, we had one new library, TSC 2007. And a huge list of updated libraries that I removed from the notes document because it was too much. But I did link to the library report where we get this information every week. And so if you're interested in that list, you can check out the actual report. In terms of library stuff, one of the key things we're doing right now is showing up the library infrastructure setup. We have come up with fixes to our CI and to various other infrastructure files in the libraries, but we've been bad about adding it to cookie cutter, which means new libraries aren't getting those updates. And we've been bad about adding it to all the libraries, which means not every library is the same where it should be. And early hug report to tech trick for going through all the libraries and figuring out where the changes are and what differences there are and where we need to make changes either to cookie cutter or by patching the libraries. So I'm really happy to see that we're doing that because it's definitely something that we should have kept even all along. But it's, you know, it's a lot of work. So I understand why we didn't always get to it. So that's something that we're in the middle of doing. And I hope to see that finished up relatively soon. That's what I've got. Okay, thank you, Kaden. Okay, next section is a report about Blinka, which is a compatibility layer for Circuit Python on single board computers like Raspberry Pi. So you can use it to write to run Circuit Python code, not in Circuit Python, but to use Circuit Python code and libraries. Melissa, can you go ahead and read the Blinka section? Sure. As Dan mentioned, it's for our compatibility layer. It also works on MicroPython. And this week, we had two pull requests merged by two authors and two reviewers that the six open pull requests amongst other repositories, there were four closed issues by two people and three open by three people leaving a net of 73 open issues. We had 13,442 pi wheels downloads in the last month. And we are now up to 88 supported boards. And that's it. Okay, thank you, Melissa. Okay, the next major section is hug reports. Hug reports is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. We each take turns doing this I'll start to sort of set the trend and then we go down the list, which is mostly in alphabetical order usually. So I'll take a timecode here. So I didn't have a chance to really be thorough about this, but I'd like to thank Jeff for doing a lot of reviews and coordination with me on reviews and PR as well. Scott is out. So now there are two of us instead of three of us doing a lot of core stuff right now. So thank you, Jeff. Okay, C Grover is not his text only today, so I'll read their contributions. Thanks to Foamy Guy for providing the core of a fun project and learning experience that will become gifts for my two of my favorite cat lovers. So that's mysterious. You'll have to read in discord about what that is. Thanks to Todd bot and MZO for a quick and thoughtful code review. Their discussion led to the expansion of my Python skills into into a previously undisclosed undiscovered realm. And thanks to WSU's Jay Snyder at all for the very practical Python course reference. Okay, next is Foamy Guy. Thanks, Dan. First hug report is for C Grover for who made some enhancements in the Niko Kitty animation project that I worked on a little while back, including adding support to have multiple kitties running around of varying colors. I suspect this is probably what the gift that C Grover is talking about as well. The next hug report I have is for Warrior of Wire for offering some feedback and pointers on some plans and an attempt I made at implementing the hidden property or the ability for vector IO shapes to be hidden within the core. Definitely appreciate their insight. To Tammy makes things for streaming on Twitch. I've got a couple of Tammy streams in the last week or so and there's it's great to see more folks out on Twitch working on this kind of stuff. And then lastly to you, Dan, for as well as everybody else who's contributed for keeping the new releases flowing 7.2.0 and the new beta as well. So thank you for that. Thank you Foamy Guy. Okay, next up is Jeff. Hello, I wanted to start with a hug for Jerry. Thanks for the bug reports. And you shouldn't necessarily be so meek about them because if problem affects you, it may also be affecting 10 people who didn't mention it to us. And in particular, I mean this. I'm referring to this issue where with the newest version of the compiler on Mac OS, MPY cross wouldn't build. Thanks to Catney for taking the time to catch up last week. Couple of thanks to you Dan, one for engaging me about issues and pull requests. And also for your funny April Fool's Day post last week. Okay, thank you, Jeff. That post is about circuitous Python. And I'll leave it for you to find it if you're interested. Okay, next Jerry. Hi, it's a group hug to everybody for me. Thanks. Thank you, Jerry. Okay. Next is Catney. Hello. So I have a hug report to Eva for the excellent walkthrough and notes on doing an adabot patch. And for helping me run through running my first one on my own. To Jeff for stepping in when the patch failed entirely due to an issue with my get setup. And it's a problem that Eva and I almost certainly would not have figured out. And Jeff figured it out very quickly. To tech trick for a ton of work. Put into determining what needs to happen with the library infrastructure related files and cookie cutter and across the libraries to get them updated and in line with what they are supposed to be right now. To Dan for publishing the latest releases to circuit Python. To Professor John Gallagher for a lovely discussion about how circuit Python has worked out for him in higher education and spoiler, it's working out great. To Jeff for a lovely chat last week. Also to Dan for writing a very thorough guide on async IO from which I was able to grab a lot of explanation for my template page and for reviewing my template code. And to Mark gambler for helping explain async IO in a simplified manner as I was struggling to understand it and help it and providing feedback and something worth adding to the template. And a group hugged everyone. Okay, thank you. Okay, next up is K match. Thanks, Dan. A hug to Ennec data. Jeff and Dan all three of y'all for guidance on allocating memory on ESP 32 s three. In particular, thanks for giving insights and help on even things that are on long term milestones. So thanks for for spending some of your precious time on that. Thank you. All right, thank you. Okay, next is Melissa. Hello, I wanted to give a hug report to blue who for agreeing to maintain the web serial ESP tool, the founder of Nabucasa to buy evil for adding the goddess them three board to Blinka, which brings us up to 88 boards now. And to you, Dan, for being helpful with Blinka and circuit python.org to Jeff for the Pilates auction ticket and group hugged everyone else. All right, thank you, Melissa. Okay, next is Mark gambler. Oh, it says lurking group hugged everyone. Sorry. And Tammy makes things is out here. I'll read their contribution to group hug for everyone. And next is Tecdrick. You want me to read? I go ahead. Yeah, so thank you for the interesting project for looking into the libraries, specifically the cookie cutter and the library library patches. It's been a lot of fun. And I've really enjoyed it. Group hug or group hug, I guess, also hug to rim wolf redux for the input on a MIDI related PR. I'm pretty new to MIDI. So it was nice to get some some feedback for someone who knew a little bit more than I did to you, Dan, for the long awaited circuit is Python release, big fan. And yeah, group hug. All right, thank you very much. Okay, so we're done with hug reports. Now, and we'll move on to status updates. Take another time code for the section. And then I'll start. So this is where we just talk about what we have been doing and what we plan to do coming up related to circuit Python. Or what else if you're if you're busy doing something else. So I'll start with time code. I'm trying to type quietly. And I make a lot of typos that way. I released circuit Python 7 24, as mentioned, to support the new version of the Adafruit Feather ESP 32 board. And also support and also make it its use of IDC power be compatible with the old version of the board. And I released circuit Python 7.3.0 beta, so that there was a latest for people to try that's much easier to point to. You can just go to circuit Python.org and find that one. I'm still working on a fix for a problem with board dot you are on RP 2040 boards. This was a I have a fix for it, which is straightforward, but there's still a very odd problem about what have strange things happen when you connect your pins from that board to another unpowered board. I had a test set up. And I was getting errors. And I don't understand what it is. But it's probably not worth looking at in great detail right now because very strange things happen when you have pins connected to unpowered board sometimes you back power that board and it it can act oddly. So it may it may be something that it's just a hardware problem. And the after I get that's work that working I'll be working on issues with ESP 32 SPI, especially on matrix portal, a lot of people are having problems with the their web, their web set up by crashing after a relatively short period of time. And we want to try to nail that down and figure out what's wrong. Alright, next, I'll read C Grover's contributions. There we go. Can't type. C Grover says finish the multi cat version of FOMI guys Neco cat project. It's compatible with pi portals and TFT featherwings. Final version will become two gifts gifts using 2.4 TFT featherwings and pink RP 2040 feathers. The challenge now is to install it in an appropriately creative enclosure. Suggestions are welcomed, except for anything looking like a litter box. Okay. When testing projects on the pi portal, Titanic, I noticed that the display brightness range wasn't similar to the other pi portals and TFT featherwing displays. The Titanos display brightness PWM signal is operating at a frequency which seems like 50 kilohertz, which is too high for the fan 55333 backlight controller. The datasheet notes that a frequency above one kilohertz may cause a brightness non linearity tests on the 3.5 inch TFT featherwing same display same backlight controller, confirm that a PWM frequency of 500 Hertz works best and restores the entire brightness range. We'll submit an issue for display IO display for further testing. And there's a reference to an issue that Sea Grover put in their own repo. And I'll just note that I had some conversations with Sea Grover about this. And he's going to do some audio testing about it too. Just to make sure that injecting 500 Hertz doesn't cause a 500 Hertz spurious signal that you could hear. Okay, next up is foamy guy. Right. Thanks, Dan. So today, and a little bit yesterday, I've been catching back up on some PR reviews. I had a couple of weeks where I was spending a couple of nights a week teaching class. And so I had reduced time to kind of focus on circuit Python stuff. But that class has concluded. So now I'm getting back to or my usual schedule, which is nice. I on the deep dive, I think it was on Friday, I made an attempt to implement the hidden functionality inside vector IO shapes. And I got it partially working, but still needs to do some some more work in there to get it working in all cases. I worked on extending the page layout that I built last week to be used in a tab layout that this is like a helper class that allows the user to easily create tabbed pages with labels for each page. And the whole is that eventually there will be touchscreen interaction as well. So you can touch on the tabs to change between them. This week, I have been doing some thinking about and I think I'm going to take a make an attempt at implementing a bitmap patch loader is kind of what I'm thinking of it as we're calling it. This will basically use a relatively small spreadsheet along with some configuration details. And then it will have the ability to create a tile grid at an arbitrary size that uses the corners of that small spreadsheet but then repeats the tiles in the middle to achieve whatever larger size you want. This will allow us to keep our assets small, but be able to build larger panels at runtime to display them on the screen. The first kind of usage I have in mind for this is the actual visual tabs inside the tab layout that I'm working on. But I do have a couple of other things in mind where I think this will be helpful as well. A couple other things I'm going to be getting into this week. I'd like to update the code in the Niko Kitty project to use this new multicat version that SeaGrover has kindly created and shared with us. And then I'm also going to dive in a bit to Adabot some more. I took a look last week and didn't really find the exact part of it that I needed. But basically what I'm trying to do is figure out a way if we can make a draft indicator on the contributing page. So PRs that are listed there will have like an extra little flag or something if they are marked in draft status. And I think Adabot is ultimately where that data comes from. So I'll be taking another look into that. And that's what I have for this week. Thanks. All right. Thank you, Foley guy. Okay. Next, Jeff's turn. Hello again. Just two short bullet points. Last week, I think I fixed the SAMD 51 every three days bug, although I think that still needs to be merged. And this week, I already made good progress on several issues assigned to me in the core. Some of those PRs are failing to build and I will scratch my head about that later after the meeting. I'm going to spend at least the first half of this week on Circuit Python before heading off on floppy stuff. And Friday is my yearly birthday, so I will be out most of the day, at least in the afternoon, but maybe all day. Thank you. All right. Thank you, Jeff. Okay, next up is Jerry. Hi. So I spent a bunch of time last week playing with the ESP 32 CT build, C3 builds, just trying to check out how they were working. And it's some interesting results. So if anybody else is trying them, just a heads up. In order to use them, in order to be able to write, since there's no US, no CircuitPy drive with those, in order to be able to write to them, I use a modified version of RShell that just used except Ben Aske, because the default version looks for you, Ben Aske, and it won't run. So I put in a PR to fix that, but it's still pending. Also using screen, when that's not available, just to check the REPL. So on the ESP 32 C3 Dev Kit board, the expressive board, everything works great. RShell connects. I can talk to it. I can upload files. The REPL works fine, and a little Wi-Fi test program works just fine. But so then I tried the QDPy ESP 32 C3, and things just didn't work. So, you know, that's what I really wanted to bring up, in case anybody else has tried. I'm really curious if anybody else has tried this. So RShell just couldn't connect to it at all. And I think the reason is because the REPL is not working reliably. So when I was screened to connect to REPL, I could connect, but the characters are missing. When you go to print out a format, like the help modules, you know, it only prints out nice lined up columns. They were all erratic. Cutting and pasting into the REPL didn't work very reliably. Things would get dropped. And so I think that's what's causing the RShell problems. So I'm not sure what's going on there. And then I tried doing just a manual import of Wi-Fi. And that just caused the board to just stop. It just totally hangs. And in fact, the only way I can get it back was to power cycle it, even a reset didn't work. So I don't know what's going on there either. So I created a couple issues in the repository. And again, if anybody else has had any experience with the QDPy, it'd be nice if someone else can verify that it's not just me. I did try running my MicroPython version 1.18, the ESP32-C3 USB build on the QDPy. And it seemed to work okay. That took me a couple of tries to get it right. But it finally, once I reset it enough times, it actually seems to be working okay. So that's it. Okay, thanks. Thank you, Jerry. Okay. Thank you very much also for working on the C3 because it's true. It's very early, and it's really nice to have all these things aligned up. It certainly seems like there's something wrong with both transmit and receive on the UART USB. Yeah, that's, yeah, that's one of the questions. One of the, you know, it was hesitant to put these in because I know it's early, very early on this board. So, but I figured since it's out there, I might as well start opening issue reports on it because it is, it is their fuel to download. Yeah, and can look and see how weather, why it works on MicroPython, it doesn't work for us. That would be helpful. Okay. Thanks a lot. Okay, Kat and you go ahead. Thanks, Dan. Apologies about the really, really long status update. So last week I ran my first data bot patch on my own. It took a bit to get through. But once we got through the bumpy parts, it went really well applied to all the libraries, and fixed a major issue caused by dependency of one of our CI files causing everything to fail. Basically, dependency to black was updated in a way that in a way that made black fail, unless you were running the absolute latest. So it was either we had to pin that dependency or update black, which made a lot more sense. So that was good. Got through a huge amount of miscellaneous that have been piling up for a bit here was mostly little things, but it was adding up quickly. Added a MicroPython setup page to the feather ESP 32 v2 guide. I met with Professor John Gallagher to talk about his experiences with Circuit Python and education for a talk I submitted to the Education Summit, which is a small get together before PyCon about Python and education. It hasn't been accepted. But I don't want to wait to the last minute to find out it was. If it's not, I'll at least have part of a talk put together. I wrote up an example using a button to control two neopixel rings using async IO for the async IO template. I mostly finished the async IO tablet after a lot of help. Thanks again to Dan and Mark. I ran into issues with testing pyleap. So I'll be looking into that this week. And Liz finished her first product guide late on Friday. So I'll proof that this week. So this week, the first thing on my list is to proof Liz's guide so she can get that into moderation because she's, I think now blocked on me, she may still be blocked on a Arduino issue. I need to blog up the feather v2 MicroPython setup guide page to update. I can cross off the look into why pyleap testing isn't working properly because apparently I needed to be added to the list specifically, which Trevor took care of. And so now I'm in the middle of updating the iOS or the OS on my iPad, because the newest pyleap requires the latest OS, I guess. And then I need to get the gifts for the async IO template. The plan is to upload them to GitHub, and then add an extra template area in the guide page to say use one of these two depending on what your hardware setup is. There's two different hardware setups possible for the async IO template. One is a built in button and the other is an external button. And I thought that it should at least match the wiring diagram. So there's really no way to include two separate ones depending on what is what you have to make that decision when you fill in the template. The next thing on my list is to write up the guide for the QT Pylypo BFF. Sometime this week, this is a little bit out of order, verify the cookie cutter and patch PR is put together by tech trick, and then go through the get ignore PR. And then begin thinking about more projects to add to Pyleap, porting existing ones or coming up with new ones. And the thing I didn't mention about figuring out pyleap testing is that I'm actually going to go through and test all of the recent additions to Pyleap projects to make sure that everything that was added works for me. And that's what I have going on. All right, thank you, Cadney. Cadney always has a lot going on and her contributions are tremendous. Thank you. All right, we'll go on to K match. Thanks, Dan. So continue working on using ESP 32 s threes LCD peripheral, which can drive fairly simplistic displays. I'm trying to get that into circuit Python. The first thing I did was sort of fill out the file structure for a new module old clock display that can use a frame buffer and use the ESP 32 s three to drive this kind of display. And next thing was, as I mentioned, the hug report, thanks to help from the team, I got it to allocate memory to draw into the frame buffer and attach that to the screen. So I do my first pixels. That was good. It is hard coded in the constructor. But at least I saw something wiggle. So that's good. And this week, hope to get actually the circuit Python code able to draw to the clock display. And if that works, repel should be within reach. But we'll see if we can get that done this week. Thanks. All right, thank you very much. Okay, next up, make a list. Hello. So this week, our last week rather, I finished up the 1.47 inch and 1.9 inch display guides. I updated the Raspberry Pi for TensorFlow guide. So it's working now. And I fixed Blinka to work with both older and newer versions of live GP IOD. I tested out the ESP 32 C three QT PI on the web serial ESP tool. I recorded a podcast on the circuit Python show. And I added a bunch of new boards to circuit Python.org. And I spoke with Nabucasa about maintaining future updates on the web serial ESP tool. As we come working on updating guides to point to the Nabucasa version of the web serial is web serial ESP tool. I'm taking a look at possible a possible improved Raspberry Pi display driver. And I'm seeing what we'll take for a personal performer up there to point to the NPM package for web serial ESP tool. And that's it. All right, thank you, Melissa. Okay, I'll read Mark gambler. Mark submitted the revised Zlib PR. Once it is acceptable, I can create an issue to track the possible improvements discussed in the current PR. So they are documented. And if someone else wants to grab them, they can. Off on vacation Saturday for a few days to New York City, getting to try again for the vacation, I had to cancel almost exactly this date in 2020. You all know about that. If anyone from the community is in New York City or around and wants to beat up for coffee, let me know on discord. Alright, next step, I'll read Tammy makes things submission. Last week on Twitch, two Twitch streams last week finished up for now my macro pad MIDI project and began the implementation of a circuit Python library to represent decks of cards with display IO support. Oh, I get heart of the we will see solitaire. Okay, began work on a fix for mreli since Pico tool to work properly with boards that have large flash flash capacity. This week, planned Twitch screams went put planned Twitch streams Wednesday at 530pm, say that fast six times. And 530pm Pacific time on Sunday at 9am Pacific time schedule subject change. I'm planning to continue work on my circuit Python card deck library, continuing to work on the Pico fixes. Super busy with work this week last week at my current job so likely times constrained again this week. Okay, and that's Tammy makes things thing a contribution tech trick you can go ahead. Yeah, so this week worked on the proposed patch to the libraries as well as the cookie cutter update, which is a topic for in the weeds. Additionally, I've been adding more functionality to the tick stepper motor controller library I've been working on. On top of that, went through some PRs and issues just trying to burn those down a little bit. I think earlier in the week, I had done some more type annotations, as well as put a few other things into place like some protocols for LEDs to make typing for those libraries easier. I know they're used in a few places so that all giving them a central location will be pretty nice. Added a few other random updates to a few libraries. I noticed there were some missing dependencies. So nice to get those. So all the right libraries are downloaded on install from PI PI. And then on another note, I registered for my first grad course. It's on microcontrollers and embedded systems. So thanks everyone here. I'm sure my mechanical grad advisor was very confused, but something I wanted to do. So thanks everyone for that. This upcoming week, I'm going to continue working on the patch and the cookie cutter update with cat me and everyone here. Additionally, I know there's a few more things to add for that tick stepper motor library to get a more thorough functionality for it. There's a couple things I got to follow up on on some PRs like the portal base. We're looking at trying to add multiple Wi-Fi libraries. So thanks foamy guy, related hug for the feedback on that and starting to plan for Python this year. Alright, thank you very much, Tectric. And thanks for all your work on the libraries. It's been tremendously helpful. So that wraps it up for progress reports will now move on to in the weeds where we have this is for sort of long reform discussions that require more dialogue and a cogitation about things. And so cat me and Tetrick have a kind of a multi part thing here and I I'll turn it over to them. All right. So here's the basically what's going on with tech trick head sort of touched on. Is that I asked tech trick to compare the CI type files, including dot get ignore across all of the libraries, as there are files that should be identical, and it has become pretty clear that they are not as well. We haven't been great about updating cookie cutter with all of the changes we've made to the library. So the newer libraries are missing out on some of the important updates. To that end, Tectric put together three PRs. All of them can be discussed, but I think the one that should involve the most discussion is probably the dot get ignore file. So the first PR is to cookie cutter for a dot get ignore. Basically, it was determined that there were significant differences across the libraries and the dot get ignore file. And so I asked Tectric to pull together from all the libraries, every entry in all of the dot get ignore files. And this turned out to be much bigger than expected. It is almost certainly worse than discussion as well. I'd like to see it better organized with comments as headers, but neither Tectric nor I know enough about what's going on with some of these entries to do a solid job of organizing. So if anybody's up for that, please let us know. So basically, this PR has everything that all the libraries have. The thing is, some of the stuff shouldn't be in there for any of the libraries in general. Others of it, I'm not, I don't have a clue why it would have been added or what would have led to its inclusion, etc. And so there, I haven't had a chance to go in and review it in detail. Dan already provided a bit of feedback on a couple of things that should be ignored or should not be ignored, rather should not be in this file. So if anybody has any thoughts on this, opinions, information, whatever, please feel free to review this PR and you can do, if you go into the PR and you go to the files changed section, you can actually provide feedback on specific lines if you haven't previously reviewed. Obviously if you have, I'm telling you something you already know. But it's worth, I want some feedback on this because it's something we're going to backport into all the libraries once we have a settled idea of what we want in there. And I just, I feel like other folks should have a say in what goes in there. So that is the sum up of that PR unless anybody has any opinions now they want to talk about. I can cover the rest of what we, what I covered in the weeds here. I'm a broken record about this but I just can't stop myself. So here I go. I think the better way to deal with gitignore files is that the gitignore file would list anything that is created during the normal course of doing build steps that are included within the thing itself. So like if you have a library that builds Sphinx documentation, you would ignore that any of the files created by Sphinx because everybody who works on the library will create Sphinx files. It's just part of working with it. On the other hand, if there's a file that everybody who uses OS2 ends up creating in there, well, hardly anybody uses OS2. A very small minority of people do. And so adding that to the gitignore of every library is not a good way of going about it. And instead that person who uses this particular environment can put it in their personal but system wide gitignore file. And then they never have to worry about it in any project again. So the distinction is between files that are created in the way that we expect everyone to work with the library, such as by running Sphinx, or by ways that only some people are going to interact with the library. For instance, one person uses Idea, one person uses Vim, one person uses PyCharm. They each create different files. That person, each person can deal with that by adding that to their personal but system wide gitignore file rather than by putting them all in in a vast laundry list that no one really understands. But I think I've already put this point of view forward and we've decided that that's not what we're doing. So I'll try not to go through this field ever again in the future. It's okay. You're free too. I agree with that actually. But I think maybe we need a section in our GitGuides about how to, maybe we already do, in your own global gitignore file. We absolutely don't. Because every GitGuide, every major GitGuide that we've written is based on the one I wrote and that definitely wasn't included in the one I wrote. Because it is true. Yes, maybe you can cover a few things like Tilda or something. But in general, it's the responsibility of the person doing the editing or whatever to clean up their own things. My only concern about that is that there are like four major IDEs that most folks use. And not everybody understands Git, etc. And I don't see why we can't include the mishmash of, because there's only one file from each thing typically at the bottom of the Gitignore and call it good to at least help out the folks that are using these four major IDEs, I guess. That's fine. That is a very pragmatic approach. I think what we should not do in the future is take in an individual library a PR to change the Gitignore file. My environment creates . whatever files or whatever it is. We should say thank you and kindly turn them down when they're at it. I don't mind being pragmatic. I mind the very long list that is tough to vet because it's so extensive. I agree. And that's why I was absolutely blown away and immediately wanted this put into a draft, the PR for this, and wanted to discuss it because this is not good. None of the CI slash infrastructure files should be changed in individual PRs because something on your machine made a change. The only place that these should be changed is in cookie cutter. And that means everybody needs to discuss that change at that point and decide is it worth adding and then we have to patch all the libraries because that's how this happened was that everybody who produced anything added it in whenever they produced it and some of the stuff is ancient. So this has just been coming in since the beginning of these libraries I think and we just haven't ever pulled it all together. So I think what we'll do is actually keep this PR as a draft so we can like look at it but I think it makes the most sense to actually separately put together because the editing this is out of the question to basically separately put together all the things that make sense and open a new PR and then make a decision off of that, off the new PR to include whatever we need to include to deal with our build stuff and then add in the four files that are typically generated by the four major IDEs that are used and then be done with it and any updates to it have to happen through cookie cutter and have to go through a discussion. Chadney? Yeah? I had a thought about that. Why not have a base get ignored that belongs in every library just the way it is and then have a way to put that say at the end at the very end of the get ignore a marker that's a marker followed by whatever whatever personal things they need for their working locally and then just lop that and just basically you lop that off. That's not really tenable there's a personal get ignore like there is a global get ignore that you can put on your computer that applies to everything you do with git and that's what we're going to push folks to use if they have personal files that are being included and are showing up in their you know get status when they try to make a commit to have it do any kind of splitting and all that stuff is just that's a lot of overhead. Okay I just it's just I guess I've been lucky so far in my tinkering not to have needed to add any extra stuff to the cookie cutter really. Yeah well I mean the problem is other people added a lot of stuff like ignore. So we're now dealing with the large list of things that were randomly added. Okay I hope you have good luck with that because thank you I think we will see what I've seen what kind of a mess things like that can do to do to what should be a simple simple thing. So I will I will put together yeah I've looked at at I think I've looked at that before Jeff. At least something related to get ignore docs. Yeah I mean that's pretty technical language there so we'd want to boil it down for people who are less conversant than that. Yeah for sure so I'll put together what I what I think is everything that we would normally generate and then the the few extra files that I would like to include and then I will tag circuit python librarians on that so everybody who is a member of that group can can comment on that and I don't see a reason not to wait until we have another meeting so that I can bring it up in the meeting in case there's anyone who doesn't or who is not part of the circuit python librarians team can still take a look at it and add in or you know pull out something that they think shouldn't be there or think should be there. And then we'll go from there. That's that's what I'm thinking because I I don't want to ask anybody to edit this file and I certainly don't want to. So I'm going to go ahead and put together something new that fits what I think is right and then bring it to everybody again to have this conversation only much shorter. Does that sound good? Yes. Okay perfect. Thank you Kenny. Yeah absolutely this is why I wanted to bring this up because that was a that was a bonkers file. The next two PRs don't really need discussion that I know of but I wanted to bring bring it to people's attention that the TSC 2007 is a very recent library so it's using the latest cookie cutter. So it was this was an excellent idea on TechTricks part to add everything to this library that should be added to cookie cutter to get it up to date with all the other libraries. And so that includes it's all infrastructure stuff like that's that's what we're making changes to and it will get everything in line and then once that is settled the next thing which is the library to the BME 680 because when we do patches basically you submit a PR to a random library just to make sure that CI passes because otherwise you don't know whether the patch will pass CI and if you're going to if you're going to submit it to all the libraries you don't want to break all the libraries. So this is like a first step to that. This is all the things that need to be patched across all the libraries because they're different. So it's it's two separate pieces to all of this. I don't think those two really need much discussion but if anyone is familiar with like super familiar with the library infrastructure please take a look and leave a comment if you would like to about changes you think should be seen or shouldn't or whatever. All of this is based on comparing the libraries across all of them and comparing cookie cutter and comparing new libraries to old libraries and so on and so forth a lot of a lot of effort went into this. Thanks again to TuckTrick. So those things will be handled separately the cookie cutter thing will end up being a PR to cookie cutter and the patches have to be divided up so that they actually will apply to as many libraries as possible. So that's the next step with those two things. So I think I think that's everything unless TuckTrick do there anything else that I didn't cover here that you thought should be covered? No I think I think that's pretty much everything yeah for the for the gate ignore I ran it twice because I thought I was getting some garbage data. It really is that big. No I think that's everything. Yeah there were a couple places I think just the only thing I'll say is for the BME library I think that if the BME library had it but it was a concern that maybe others didn't I think I like added a comment so if anyone does look at that just know that those added comments just kind of represent that. But yeah no I think you touched on everything. Excellent. Yeah the only other thing I would say is that I think that the pilot RC is different in a bunch of the libraries and that isn't included in the proposed patch. So it might be worth taking a look at those in a couple of other libraries because it's possible the BME 680 happened to come up you know the same. Yeah I can take a look at that. I'll double check my output and whatnot the only thing I could possibly think of is that if we had patched it for all the things but it may be a scenario where all of the libraries outside of cookie gutter are up to date and there's nothing that cookie gutter explicitly got that the libraries didn't is the only thing I can think of. And that's entirely possible I just I want to make sure that that's for sure before we move forward with patching because if we need to patch that I want that to be on the list. Yeah I'll double check my the output of my scripts and just make sure that that's the case or if it's otherwise. No problem thank you. So that covers our in the ways topic and that's the only topic you've got so Dan you are welcome to do your thing. I'll just say I'll say one more thing which is not really part of this we can defer it but we also talked very briefly about eventually replacing setup.py with pyproject.toml. Yeah that's a whole nother project on itself but yeah that'll be this yeah that'll be another patch. So if anybody has has experience with pyproject.toml let us know make suggestions thank you. Okay all right well that wraps up this meeting we just ran just a little more just about an hour I'll take a final time code next week's meeting is same time same channel April 11th 2 p.m. U.S. Eastern Time 11 a.m. U.S. Pacific Time thanks to everybody who participated today if you want to support Adafruit and CircuitPython and those of us who work on CircuitPython consider purchasing from the Adafruit shop at adafruit.com we will release a video of this meeting on youtube.com slash Adafruit I'll be doing that later today and the podcast will be available on major podcast services that happens mysteriously automatically. It will also be featured in the python.com for microcontrollers newsletter visit adafruitdaily.com to subscribe to the newsletter so thank you very much and we'll see everybody talk to everybody next week thank you Dan thanks everybody I'll stop thanks everyone thank you