 Hello everyone. This is the weekly, excuse me, this is the CircuitPython weekly meeting for March the 28th, 2022. This is the time of the week where we get together to talk about all things CircuitPython. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that is designed to run on tiny computers called microcontrollers. The CircuitPython development is primarily sponsored by Adafruit. So if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted in the Adafruit Discord server. You can join anytime by going to adafruit.it We hold the meeting in the CircuitPython dev text channel as well as the CircuitPython voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern or 11 a.m. Pacific except when it coincides with the U.S. holiday. In the note stock at the top, there is a link to a calendar that you can follow through and open up in your favorite calendar app, which has a list of all of the upcoming meetings, including ones that might get changed to a Tuesday for the case of a U.S. holiday happening on a Monday. We also send notifications about the upcoming meetings in Discord. You would like to receive those notifications asked to be added to that CircuitPythonista's role on the Discord. There is a notes document that accompanies the meeting and the recording. The notes document contains timestamps to go along with the video so that you can use the doc 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 if you'd like. After each meeting, we'll post a link for the next meeting's notes document in the CircuitPython dev channel on that Discord. Check the pinned messages to find the latest notes doc so that you can add your notes for the following meeting. If you wish to participate but can't attend, you can leave hug reports and status updates in the notes doc throughout the week, and then we will read them during the meeting. This meeting is held in five parts. The first part is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of this Python on microcontrollers newsletter. The second part is the state of CircuitPython, the 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 are all working on. Next up is hug reports. The third section hug reports is an opportunity to highlight the good things that folks are doing, taking time to recognize the awesome folks in the community. The fourth part is status updates. This is the second of the two round robins. Hug reports is the first round robin. Status updates is the next one. This is an opportunity to sync up on what we've been working on for the past week and what we intend to be working on for the next week until the next meeting. The fifth and final part is in the weeds. This is an opportunity for more long form discussion. These discussions can come out of status updates or they can be identified ahead of time as things that may be too long for status updates. That is how the meeting will go. Next up, we are going to get into community news. Let me scroll just a bit and do a timestamp. This week's community news. It's a boy. For folks that don't know, the lead developer of CircuitPython, Scott Shawcroft, him and his partner are having a baby or at this point have had a baby. The baby and the mother are doing well. Scott will be on paternity leave for folks that don't know for the next six weeks. Of course, the whole Adafruit staff as well as Python and Maker communities wish Scott and his family well. Next up, we have Twitter communities, which I believe this is a new feature that's being rolled out to Twitter. This aggregates people with common interests and there are two Python slash microcontroller related communities. There is a MicroPython community and a CircuitPython community that now exists on Twitter. There are links to both of those in the note stock if anyone is interested in joining. Next item in the newsletter is a major Thawnee update. Thawnee is a Python editor and there has been a new version released. This is version 4.0.0 and it is the beta one release and they are looking for help with testing and reporting bugs as well as bug fixes. There is a link to the GitHub release page in the note stock. Next up is the return of the MicroPython wiki. So per Matt, the MicroPython wiki is once again up and running. The media wiki-based site collects knowledge and resources and links for anything and everything related to MicroPython, both for users and developers. There is a link to that in the note stock as well. I believe it was down for a period of time due to some issues that were occurring but it is now resolved and back available again, which is nice. And the last item in our preview of the newsletter today is new circle bar features. So this one caught my eye from the newsletter. This comes to us via Twitter from a Twitter user named at digital maker CIC. They have added a feature to the Pico Circuit Python circle bar class, which is a helper class that allows you to draw circles. The new feature allows us to draw lines around the circle at arbitrary angles, I believe is the idea here. So this could allow you to make tick marks if you want to measure out like a dial or a gauge or something like that. It looks like it also may be possible to use for a pie chart as well, which I think would be another interesting use of this. So thank you to digital maker CIC on Twitter for adding that enhancement and sharing it with all of us on Twitter. Details for the newsletter. The Circuit Python weekly newsletter is a Circuit Python community run newsletter that's emailed every Tuesday. The complete archives are available online at AdafruitDaily.com. It highlights the latest Python on hardware related news from around the web including Circuit Python, Python and MicroPython developments. To contribute your own news or product project, you can edit next week's draft on GitHub. There is a link again in the notes doc for that. You can submit a pull request with your changes. You can also tag a tweet with hashtag Circuit Python on Twitter or email cpnews at Adafruit.com to get those stories into the newsletter. So next up, we will take a look at the state of Circuit Python, the libraries in Blinka. All right, so overall we have had in the past week 46 pull requests merged by 22 authors. I did forget to go through and highlight some of these, but taking a quick look right now, the ones that do look new to me are Unicycle Dump Truck, Zodius Infuser, and let's see, I will probably mispronounce it and I apologize, KG, Cure, Nawan, Sapatura, W-T-E-U-E-M-U-R-A, Wittemura. Yeah, those look like the ones that I don't recall seeing before, so thank you to those new contributors as well as everyone who contributed to Circuit Python and the libraries this week. We had in addition 15 reviewers. It was nice, we got quite a few reviewers going, we always make sure to point out, you know, the more folks we have reviewing, the more folks we can have contributing. So this is definitely good to see 15 different reviewers. We had 28 closed issues by 14 people and 25 opened by 18 people. So next up, I will send it over to Jeff to tell us about the core. Hello, so I'm telling you today about the core, which is the C code that implements Circuit Python and which is a fork of MicroPython. So our numbers are 14 pull requests merged from 10 different authors and those are all usual people, so thanks to all of them. And as well, we had five reviewers and thanks in particular to Jerry and Mark for pitching in from outside the Adafruit organization. It's great to have those pull requests reviewed by people and it'll be even more important while Scott is on leave. So on to the next item, we have 13 open pull requests and three of those have been open for more than two months, so it would be good to take a look at those and move them along. If you're waiting for effort or for action on Adafruit's part, please feel free to give us a ping. You can give me or Dana Halbert on GitHub a ping and we will help you get your pull request back on track. Issues-wise, we were up a little bit with eight issues closed by four people while we had 10 new issues opened by eight people, leaving a total of 510 open issues. In the core, we like to track them by milestones, which basically prioritize the work that Adafruit wants to do before we make a release. For 7.2x, we have no open issues, which may mean that we need to do another stable release. For 7.3.0, we've got four open issues, so we're hopefully closing in on the next kind of feature bump of CircuitPython. And looking at the longer term, for 7.xx, we have 23 open issues and for 8.0.0, we've got 10 open issues that we're waiting on to take because they are, for instance, incompatible changes, which we only take on purpose when we have a major version bump. And there are three issues not assigned to Milestone. This is another item where I at least depend on somebody else to assign issues to Milestone, so we will need to make sure to keep on top of that. Narrative-wise, I have been working a lot on floppies and I don't really know what's going on, but we are in a time of trying to keep the software stable, make sure that we add new boards as they come in and work on some things like compatibility with ESP32-C3 microcontroller and just keep things in good shape rather than make any sweeping changes or implement any huge new features. And that's what's up in the core. All right, thanks, Jeff. Next up, I will pass it over to Katny to tell us about the libraries. Thanks, Tim. So this applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore CircuitPython underscore as well as a couple extras. Over all of those repositories, we had 30 pull requests merged from 14 authors and 12 reviewers. And that leaves us with 27 open pull requests. Of those merged PRs, three of them were over two weeks old, which is good to see that we're still picking up some of the older PRs, and the rest of them were four days or less, so it's great to see that we're keeping up with new PRs as well. We had 16 issues closed by nine people and 12 opened by nine people, leaving us with 616 open issues. 201 of those are labeled good first issue. If you're interested in contributing to CircuitPython on the Python side of things, consider going to CircuitPython.org slash contributing. You'll find all of this information and more. If you're interested in reviewing, check out the open PRs. Leave a comment that you took a look. If you have the hardware, test it. Let us know what you see, whether you think it's good to go, or if there are any changes you'd like to see. This is always helpful, and once you're comfortable with that, we can talk about having you join the review team. If you're interested in contributing code or documentation, check out the open issues. If you're new to everything, good first issue is a great place to start. We also have a guide on contributing to CircuitPython using Git and GitHub, and we're always available on Discord to answer questions. We want to make sure that you can contribute in a way that works for you. There are a number of updated libraries in the last seven days, but no new libraries this week, so I will not read that list off, but it is available in the notes. If you are interested in seeing what has been updated. In terms of libraries in general, we're still seeing folks picking up a lot of miscellaneous bugs and adding type hints, which is one of the major good first issue PRs. Thank you to everybody who's been reviewing those as well, because obviously we can't move forward with folks contributing if we don't have people reviewing, so both things are incredibly important, and that's what I've got. Excellent. Thank you, Catney. Next up, I will send it over to Melissa to tell us about Blinka. Hello, Blinka is our CircuitPython compatibility layer for MicroPython, Raspberry Pi, and other single board computers. This week, we had two pull requests merged by one author and three reviewers. There are currently six open pull requests amongst the different repositories, and there were four closed issues by four people and three open by three people, leaving a net of 74 open issues. There were 12,820 PiWheels downloads in the last month, and we are supporting 87 boards, and that's it. Excellent. Thank you, Melissa. Next up is going to be the first of our two round Robins sections. This is the Hug Reports section, and again, this is a chance for us to highlight folks in the CircuitPython community and beyond for doing awesome things. As mentioned, this section is held as a round Robin where I will start and then we'll go down the list alphabetically all the way through, and I will read out notes for anybody who has marked absence. Otherwise, I will pass it off to you, and you'll have a chance to read in the voice channel your notes. So kicking off Hug Reports. My Hug Reports this week, first one is to John Park for the wonderful bite-sized CircuitPython parsec segments. John's been doing these for a little while now, and I've always thought they were a really great utility to help folks learn some kind of basics of CircuitPython. They're just a few minutes, and they explain a core concept in a nice basic way and show examples of it. So they're really great, and especially the last couple have been relating to DisplayIO, which is definitely something I'm always interested in. So that's been great to see as well, but just generally the CircuitPython parsecs are great. So thank you to John for putting that out each week. Thank you to Dexter for trying out and reviewing a PR that I made over the weekend for a new page layout inside of the DisplayIO layout library. Thank you to, or I should say Hug Report, and congratulations, of course, going out to Scott, and definitely wishing the best for him and his family. And then last up, I just have a group hug for everyone in the community. Let's see, I forgot to take a time code for myself. Let me do the next one here. So next up is Anecdata, who is lurking. Anecdata has a Hug Report for Neeradoc for helping me reason through a data structure question and in general for providing lots of support on Discord. And next up is Dan. Thank you. I'd like to thank Scott for some last-minute fixes, which he put in just before the baby arrived. And congratulations to the whole family, as everyone has said. Thanks to Jeff for fixing a bug in the SAMD51 tick counter. When it turns out there's a hardware weirdness where it doesn't occur when we think it was going to occur. That was great to take to work on his part. Thanks to Gambler21 for continuing work on Zlib, which is adding Zlib functionality. That is in process while we work out the API. And thanks to Katni for some guidance on library versions issues and renaming of things that we're using, old versions of old names for Pixelbuff. And I think that's all straightened out now. Okay, thanks. All right, thanks, Dan. Next up is Jeff. Yeah, I just want to say congratulations to Scott and family. It's easily the biggest development that they have ever undertaken that they're embarking on now. Absolutely. Thank you, Jeff. Next up is Jerry. Hi. Also, I'd echo the congratulations to Scott and family. Thanks to NeuroDoc for quickly putting in a PR to add the MakerDiary dongle status light and then making it really trivial for me to add the same PR to do the PCA-10059 dongle. And then a group hug to everybody else. All right, thanks, Jerry. Next up is Katni. All right, first of all, super huge hug to you, Tim, for hosting the meeting for me today. I want to give a hug to Tammy Makes Things for a lovely conversation last week. To BlitzCityDIY for learning how to do new product guides and StemAQT revision guide updates and for putting together her first StemAQT rev update on her own. A hug report to Jepler for helping me figure out how to fix my MicroPython PR to pass CI. It failed, and I was given a suggestion as to how to fix it by Damian, who is the main developer on MicroPython. But it was, I'm sure, very clear to people who understand it, but I don't, so Jeff was able to help me figure it out and I really appreciate that, and a group hug. All right, thanks, Katni. Next up is Kmatch. Thanks, Tim. First, I've got one big hug for Jeff and other friends who created the frame buffer display code, which I'm starting to delve into and trying to help her hand. And especially thanks for Scott for pointing me towards it. And of course, congratulations to him and his partner for the new edition. Thanks. Thank you, Kmatch. Next up is Maker Melissa. Hello. I wanted to give a hug to Katni for helping me with some ego-related stuff that I had forgotten. Congratulations to Scott and his family and group hug to everyone else. That's it. Thanks, Melissa. Next up is Tammy Makes Things. Thanks. Happy Monday, everybody. Hug to Scott and his family, of course. I want to give a hug to Katni for the great conversation we had last week and a group hug to everybody. All right, thank you, Tammy. And next up is Tech Trick, who is text-only, so I'll read them off. Let's do timecode Tech Trick's hug reports this week. First one is to me for helping debug some PRs where Tech Trick did not have the right hardware to test it. Next up is a hug report to Naradoc and Anecdata for always answering questions about CircuitPython, both in and out of the Help with CircuitPython channel on Discord. Next up is a hug report for Dan H. For helping fix some Read the Docs build errors that Tech Trick noticed. And then another hug report for Jeff for working, let's see, for the fantastic inspiration for my stepper motor-based instrument with their CNC machine video. And then lastly, Tech Trick has a group hug for everyone. And that does round out the hug reports section. So next up is status updates. This is the second of our two round robin sections. Status updates is our time to sync up on what we're doing. This section is also held as a round robin where I will start and then we'll go through the list alphabetically, giving everyone a chance to participate. So when I call on you, take a couple of minutes to talk about what you have been doing in the past week since the last meeting or what you will be doing in the next week until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. And if a discussion does become too much for the status updates, we can move it down to the in the weeds section. So with that, I will get started, the first time code. So last week, I worked on some various VectorIO helper library classes. Specifically, the newest ones in the past week was a rotated polygon class that allows easily manipulating polygons to arbitrary rotation angles. You used to be able to do this, but you kind of had to calculate the points yourself. Now you can just declare your points in sort of a standard plane and then apply a rotation to it after the fact, which is kind of nice. With that new functionality, I created some neat animations and kaleidoscope rainbow effects that I thought were really pretty. So that was a lot of fun to play with. Another thing that I did this past week was worked on a page layout class. This makes it easy to build user interfaces that have multiple pages and allows you to switch between them. Ultimately, this is destined to get used with a tabbed layout. And then my aim altogether with all of this stuff is to make a newer updated version of the PyPortal interface example project, which is in a learn guide. I think that was created back when Display.io was first released and we have a couple of things that make life a little bit easier nowadays. So it will be good to make a up-to-date best practices version of that learn guide, I think. Next up for this week, I am going to try to make vector IO shapes support the hidden functionality that tile grids and groups currently have. So inside Display.io tile grids and groups have a property called hidden. So I am going to set it to true and then they will not get drawn on the display. But it turns out that vector IO doesn't quite have all of the code it needs for that. So I am going to make an attempt to put some of that in so that we will then be able to use hidden on vector IO shapes. Another thing I have going on this week, I want to finish up the refactoring and changes that are made within the slider widget and get the first version of that published over in the CircuitPython organization. I also want to look into some possibilities for outline only vector IO shapes. I have seen a couple of folks ask about it. Currently we don't have a super easy way to do it, but it would be nice if we had a helper class maybe that allows you to make essentially a shape that is not filled in, just draws the outline. So that is the stuff that I will be up to this week. Next up I will pass it over to Dan. Okay, sorry, I am finding the mute button. I have done a lot of reviewing and testing PRs. That means we have a lot of contribution, which is really great. I did some cleanup on the Aid for Request library. I have some more cleanup I would like to do, maybe clean up the exception so they are more like the original request library. This was all somewhat of a prelude to writing an async version of the request library, which I am testing by modifying or kind of simulating the cheer lights demo, which is an LED animation that uses data fetched from the web to determine what color to do. It is synchronized all over the world. That was the point of it. The demo uses the mag type library. So I am thinking about whether we might add some async capability to the mag type library in the long run or to portal. Oops, like Dan got cut off mid-sense and is no longer in the room. I am guessing discord and or Dan's computer crashed. But I think he was just about to say possibly adding async capability to the portal base library, which is what mag tag library builds on top of. And then the last item in Dan's status updates is doing a 7.2.4 release with some fixes we want in the stable release and also a 7.3.0 beta zero release as well. And that is the end of what Dan had listed in status updates. My discord crashed. Yeah, no worries. I read off your last bullet point there, but if you have anything else to add, you could certainly. No, that's it. Okay. Alrighty. Next up is to Jeff. All right. So last week I added the Apple Flex format called A2R to flux engine, but it needs some more work. And the ultimate goal being to convert it to a format usable for emulation called WAS. I worked on a rare timekeeping bug on SAMD51 and the fix is set to be merged if it wasn't already, but I think it is merged. Today I worked on making cookie cutter work on Windows and there will be a little discussion of that down in the weeds. This week I'm getting back to concentrating on more Python stuff. I'm going to do about a 50-50 split of my time, I guess, because there are still floppy items to get wrapped up. And I will do that first by checking my assignments on GitHub, although I think I need to pick up some stuff that may not be assigned to me yet. So it's kind of to be determined. Thank you. Alrighty. Thanks, Jeff. Next up is Jerry. There's that button. All right, again, let's see. So I submitted a really trivial PR to add the status LED or GB status LED to the PCA-10059 dongle. And it was also added to the Maker Diary dongle and the nice thing is that that makes it, it really helps from trying to do the BLE work flow to be able to see when the light turns blue. And then a question came up in Discord about using the ESP-AT control library. And I haven't played with it in a long time and haven't heard much about it. So I did some testing with it. And it actually still does work. And it worked. I tested it with a little ESP-01 module and then with one of the Adafruit ESP-D266 breakouts. And it still works fine with the RB2040 Pico, at least. And I also tried it with both the... The guide still uses the 1.6.2 version of the firmware, but the Espressif is up to 2.2.0 and there's a build from Citron that works with, is compatible with it. And both of those versions still work. If people are playing with it, the newer builds, I think, if I understand the things I read in 2.0 release, the Espressif changed the pinouts, the default pinouts on the ESP-AT266. And so you have to be careful building it. But the Citron build is still compatible with the pinouts that we use. Get rid of the cat. Out. And then in the guide for the ESP-AT control, that guide says it's deprecated. It's not supported, not recommended because the ESP32 SPI version is so much better. But I noticed the library code itself doesn't mention anything about being deprecated. It's still out there. And I was just curious what the real status of that library is. Is it intended to be not supported? Is it supported just as needs come up? I know it's not being advanced. Is it discouraged to be used? Is it encouraged? Jerry, I can look into that. OK, because it is still useful. And I can't remember what the major drawbacks to it are, if any. So I've sort of discouraged people from using it, but I'm not really sure there's a reason to. Similarly, I was reminded by another forum post that a couple of months ago discovered some issues with the RFM9x library that if you want to use the non-default spreading factors, or some of the other configurations, they don't really work very well. And there clearly are some issues in the way that the library handles certain spreading factors. So it needs some attention. And it's on my to-do list. But if anybody else wants to look at it, they're welcome to too. It's going to require some really careful studying a data sheet. There's some very funny little things that have to be done when you get to the higher spreading factors. So it's there to look at if anybody cares. Thanks. All right, Jerry. Thank you. Lots of interesting stuff going on. Next up is Katny. All right. So last week, I finished up my MicroPython PR. The ESP32 Feather V2 uses pin 20 on the ESP32, and pin 20 was not exposed in MicroPython. So I submitted what I thought would be a simple fix to expose the pin. It failed CI because of the ESPIDF version that it was attempting to use. And Damien was very kind in the PR and suggested that I include a thing that says it has to be higher than this version. And it basically depends on what the version being used is. And I had no idea how to find that or where I was supposed to put this check. And Jeff figured out what Damien was talking about and told me where to put it. And so when I put it in, it passed. And Damien merged it. So that's my first contribution to MicroPython. I updated the CircuitPython Internet Test page for ESP32 S whatever and C whatever. It should work across all of them to be standalone using the project bundler and deleted the CircuitPython Internet Libraries page, which was rendered unnecessary by the Test page update. Helped Liz with her first DemiQt revision guide update. Updated the Wi-Fi example in the Adafruit IO template to not crash when Wi-Fi or Adafruit IO connections are lost. And updated the code walkthrough in the template to reflect the changes in the code. I updated the AIO template to refer to the CircuitPython Internet Test page for creating secrets.py instead of using a code snippet in the template. Liz completed her first DemiQt revision guide update on her own and I proved that before we put it in moderation. And I started the MicroPython page on the Feather ESP32 v2 guide, which it turns out my update actually didn't do anything because MicroPython is still building using ESPIDF version 4.2 and there's an update in 4.4 that tells things what pin 20 is and without running 4.4 in 20 still is nothing. Exposing it the way I did doesn't actually expose it unless you're using 4.4. I filed an issue for that and Damien said that it was already on their list but there were some things that they were, I guess, still trying to do, get fixed up, whatever, before they could move to the updated IDF. So this week there's a new library that I need to get added to the bundle documentation setup, all that stuff. I need to update the CircuitPython NRF 52840 guide to include something from the forums. I have the link, I haven't looked at it, so I don't know exactly what's supposed to go in there yet. The Qtpy ESP32 S2 was updated, so the PCB files and GitHub and the schematic fadprint in the guide needs to be updated. I need to update the I2CQT rotary encoder guide on the pinouts page to have an alert suggesting hardwiring VIN to a power supply if any unusual behaviors noticed. The Neo Slider guide has some code that should be in a repo instead of being a code snippet in the guide page. I need to update that. I need to do updated PCB files for the Bluefruit LE Sniffer Revision. And then after all that, finish the ESP32 V2 MicroPython page. There are two adobot patches I would like to run. They would be my first, so either I will do them or I'll get even to do them because they do need to be done. And then once those are done or before they're done, I need to update cookie cutter to include those changes as well. I still have the Essentials template for async.io. I also need to think about some more PILEAP project ideas or more existing project support to PILEAP. PILEAP is an application that if the guide, if an ADFORT guide is PILEAP-enabled, you can connect your Bluetooth-enabled microcontroller to the PILEAP app on your phone, and then the applicable guides will show up and you can go to them and just click a button and it dumps the code onto your Bluetooth board via Bluetooth and then your code runs. So you can just kind of slurp stuff right off guide pages onto your device without actually having to deal with the code if that's something that you are interested in. And I need to beta test PILEAP when our dev is ready for the next beta test. And then after that, whatever else comes up. That's what I've got going on. All right, thank you, Cadney. Next up, I will turn it over to Kmatch. All right, thanks, Tim. So I continue working on the ESP32-S3 and how to interface it with basic displays, RGB dot clock displays, so-called. And as part of that, I've been using a bunch of random wires, but I finally broke down and learned how to use KeyCAD and design my first PCB. That thing arrived and it actually works. So it's got a backlight driver and connects to all the multitude of pins to the ESP32-S3 dev board. So that's good, make my life a lot easier. Next, I'm working to integrate that into circuit Python and as mentioned before, looking how to integrate this new type of display interface with the frame buffer code is there. I got it to compile, but haven't got any pixels running yet. So that's what I hope to get done this week. I actually have some troubles on actually how to debug, so I'll drop some comments in the Discord maybe. I can extract some good information from you guys. That's what I got for this week. All righty, thanks, Kmatch. Exciting stuff, as always, in the display world. Thank you. Next up is Maker Melissa. Hello, so this week I worked on creating the template pages for the ST7789-based displays. I worked on the 1.47-inch and the 1.9-inch guides. I fixed an issue with the ESP tool where some boards didn't have the MAC address showing correctly. I fixed an issue with BlanketDisplayIO with the rotation for 90 and 270 with opposite of the circuit Python displayIO. Let's see, I fixed the Euler angles for the web serial 3D model viewer online code thing. I updated the PiBadge conference badge learning guide with some new keyboard code, and I updated the Arduino ST7789 library with an ST7789 display specific example. I updated Arduino image reader library with some 1.47 and 1.9-inch display specific examples. I actually added a few other displays too, which I'm going to use later. This week I should be able to finish up the 1.47 and 1.9-inch guides like today. And then I'm going to go through the Raspberry Pi TensorFlow guide and update the intense flow links. So they're in the latest version. Make sure they work first, though. I'm going to take a look at the LibGPIOD versioning issue in Blanket. And I'm going to take a look into an issue with the ESP32C3QDPI, not working on the web serial ESP tool. And I'll possibly update some other display guides with the new templates. And I'm going to also be meeting with Paul Cutler for a podcast recording. And that's what I have going on. Thank you. Can I ask a quick question? Yeah, on the Raspberry Pi TensorFlow stuff, are you going to be working with Bullseye but with the legacy camera? Is that the standard you're trying to run with? No, I'm going to... Wait, no, Buster, I'm going to be using for that one. You're not going to upgrade to Bullseye? I tried out the Bullseye with the latest thing and it's really complicated to get it and installed right now. And I'm waiting till it's a lot easier for users. Okay, so you can stay with Buster. Okay, thanks. All right, thanks, Melissa. Next up is Tammy Makes Things. All right, thanks. So last week I started working on fixing the PICU tool so that it works properly with circuit Python boards that have larger amounts of flash. Now that I understand what the problem those checks were trying to solve is, so I'm going to continue working on that. I didn't do a whole lot else because I'm in my last two weeks before I transitioned to my new job and things have been super hectic. So this week I'm Twitch streaming Tuesday evening and Saturday morning, I think. I want to finish up the MacroPad MIDI project I've been working on and get back to my display I.O. Card Deck library and I'm not committing to anything else this week or probably next week because of work stuff. So that's what I'm going on. Alrighty, thank you, Tammy. Next up is Tectric, who is text only today. So I will read their status update. Last week, Tectric worked on tested PRs for adding multiple Wi-Fi settings to the portal base derived libraries, adding, let's see, type annotations to some larger libraries like Phona and RSA, submitted PRs for adding Adafruit bus device dependencies for a few libraries that could make use of it but that weren't previously, I should say. A minor update to a few libraries to make sure that the CI and documentation wasn't building or passing. Probably, I guess, the documentation in CI was not passing previously but Tectric looked into the updates to get them passing. Created a community library for Polulo's TIC stepper motor controller. This is the first ground up Circuit Python driver library that Tectric has created. So that's a really nice accomplishment. Forked the Adafruit RTTL library into one that can play RTTL music on a stepper motor, which I think that's like a tone generation library. I don't know what RTTL stands for but I think that's what that is. And then for this week, Tectric has trying to get Stepotron build in a housing that will amplify the noise and exploring the MIDI libraries to see about getting it working with a MIDI controller. And that rounds out our status update section. So our last section, which we'll do next is in the weeds. In the weeds is an opportunity for more long form discussions, either ones that came out of status updates or things that folks identified ahead of time. In the weeds topic, if you do have any topics and you haven't added them yet, please feel free now to scroll down and put your topic into that bottom section in the notes document. Right now we have one topic that was added by Jeff, so I will pass it over to Jeff to talk about Cookie Cutter. Hi. So I wanted to talk about the compatibility of our Itifruit Cookie Cutter with Windows systems. In the, you can make a file name, a template, and then it uses the template language. But unfortunately, it uses the vertical bar character and those aren't okay in file names on Windows. The fix is to use Cookie Cutter 2.0.2 and for reasons that I really haven't dived into yet, you can't install this directly from PyPI with PIP. And it does have some incompatible changes compared to version 1. So the question is whether the slight inconvenience of having to install it from GitHub to GitHub, still with PIP, but you have to give a longer PIP command line, is that worth fixing things for Windows users? And I have a link to the issue, which is basically you run it on Windows and get an error, as well as my link to a possible fix. The fix uses a new feature that's only in 2.0 And basically it's a way that you can pre-compute those values in the file name, not have to have those special in particular the PIP character in the file name. So assuming that this tests out for someone else, what do we want to do? Do we want to take the change? Do we want to say it's too bad? You just can't run this on Windows without using WSL. I'm looking for people's thoughts. Yeah, this is a good question. I'm happy you brought it up and thank you for looking into it. I do know that one of the things that may be possible in the old version, I don't necessarily have a preference on updating versus not updating, but I do happen to know one of the changes I made a little while back effectively got rid of some of those pipes in a file name. At the time I was not really trying to do it to fix anything on Windows, but we had basically come to a point where our file name had too many logical conditions inside of it and we actually got too large for how long a valid file name could be and I set it up to where the base folder for the newly created library I took all of the logic out of the name of that folder and instead basically put it all into a variable and then we're able to substitute that variable's name into the file name. I don't know for sure if it will work for 100% of everything, but that might be there might be a possibility to use a similar technique where we change those file names into variables and then we can set the actual value somewhere inside of actual code where it will not bother it that it has the pipes and stuff in it. So that might be another option that's on the table. Yeah, your comment on that pull request then would be useful because if I saw that I don't think I understood what was going on. Yeah, I can do that. I'll find that older one and put a link back to it. Yeah, I figured I looked into a couple of ways to bypass all of that stuff in the username back then. Is it possible to remove all the special characters and just have a whole file name be a variable? That's essentially what I did. It still does I don't remember the exact reason why but there is still some logic in it right now. The top level folder is called cookie cutter and temp repo and then temp repo was the name of the variable. So for some reason I did end up with cookie cutter and I don't recall the exact reason. I think it would be great if it was just an alphanumeric file name because all the spaces it makes it horrible to type and just it's just difficult or curly braces and all that. I mean that would be great. Jeff, I did read the whole bug about why isn't there a 201 or 202 release and there's kind of a lot of dithering about they don't seem to be willing to publish an alpha or a beta release. So they consider this 2.0.2 to be alpha quality and so it's on the list. That's what we're basically saying and some people are saying well why didn't you publish it as such and there wasn't an answer for that but the last discussion was only a few days ago. You also suggested using somebody else's repo which has a real release and that is on PyPy and that would be alright too. I think either of those things is fine until they resolve that but if if if there is a way to do it and getting rid of nearly all the special characters in the file name I think that would actually make the whole thing a whole lot more readable because it's very difficult to browse either locally or at GitHub with all the junk in the file name. It doesn't really help you read it. I can certainly agree with that having one of my tasks was I needed to rename files at the command line and that was a special kind of punishment I think for being a person who uses the command line to manipulate file names. Yeah. So why don't we wait and see whether alright well maybe I will write on that issue and just say it would be really helpful to Adafruit if this were published because it would be at this point. Yeah and right even published even as an Alphabet because the way to get it tested is to publish it. I mean that's our experience. Our experience is that the more releases you make the more testing you get. Yeah. There will be bugs and you want people to test it. So that's what I was saying. Yeah. Don't worry about it. Publish it with known bugs. But if there is a way if the other PR So on the topic of trying to remove those because I definitely agree with both what you said and what Jeff agreed with as well. The names of those files are super gnarly and it does make it pretty difficult to figure out what's going on. The technique I ended up with and I'm going back through and I'll definitely put a comment with a link to everything I did on that new issue. I think the technique I did is there's basically post run hooks which is a chance for it to call a Python function after it has done stuff and I did the rename inside of that. So I gave the file a much more static name and then in that post run hook it renames it to the actual long one with all the gnarly logic and stuff into it. I see. I actually removed that because during the testing on windows that it doesn't break that was one of the things that didn't work. So in fact I've reversed that. So there's no way to avoid having the name have the special characters in it temporarily. I think at least the curly braces have to be there. If you're going to use cookie cutter to do the computation of the file names, it could be that we could try again and knowing that we need it to run on windows as well do it in this post processing step. That would be a different approach and it's one that it is true would work within the current version of cookie cutter. Yeah. Can I ask a question? I was looking at that and that technique looks like it comes comes right out of the back shell. You know that bar, giving you multiple options using the bar characters and things like that. Yeah. It's like a tag filter. It's specific to the templating language I think that the cookie cutter sounds like a bash shell style thing that I know exists and I know it exists in Jinja, but I don't know what I'm not familiar with cookie cutter enough with the actual internal guts of cookie cutter to say I think that it's the same. I think also we're probably not the first people to have this problem or concern. No. I was wondering if it had already been discussed maybe without resolution. Yeah. The issue that I found said use version two. They had closed it. They didn't say we agree we shouldn't have junk in the file names. Here's a way to get around that. Nobody has said can't we have cookie cutter? The workaround for having the vertical bar is to use this new facility in version two. Here's a better way to use templates to determine the name of a file. That's what I was hoping. Not that I've seen. I think that getting people to install a specific version or to use the answer or whatever it's called version for now. I mean I guess it's mentioned into a bunch of requirements .text files or maybe it's not. It's just mentioned in the guide. I think that would be fine until they unless they resolve this in a PDA you could do something about it. So I think that's okay. Alright well definitely moving forward to some review on the PR. I think LaMoure who is the person who kind of bumped this in importance because she's a windows person if she tests it and says it works for me I think that's a good pointer to go ahead and merge it and then maybe we can do something more sophisticated in the future but there are some built-in tests but I don't know how comprehensive they are so it may be that some more human testing also wouldn't hurt. Alright well as always I appreciate the feedback and if you have any for us after the fact there is an open pull request link from the note stock and you can add your notes there. We want to hear from you. Yep and I will post a comment on there with what I learned before in a link to my previous one and so we do not have any other items for in the weeds as of now so let's go ahead and do a bit of a wrap up here so this has been the CircuitPython Weekly Meeting for March the 28th thank you to everyone who participated if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing hardware from the Adafruit Shop at Adafruit.com The video of this meeting will be released on YouTube at youtube.com and the podcast will be made available by all major podcast services it will also be featured in the Python for Microcontrollers newsletter which you can visit adafruitdaily.com to subscribe to the next meeting will be held on Monday as usual I believe this is the case I actually am not looking at the calendar right now so I apologize if I'm wrong I believe next Monday though is normal time which is 2pm Eastern 11am Pacific and the meeting is held on the Adafruit Discord so you can join by going to adafruit.it and if you do join the Discord you can get notified of the meetings including ones that do happen on different days by asking to be added to the CircuitPython Easter's role on Discord we will send out pings to folks with that role and that is all for today so we hope to see all of you next week and thank you again to everyone thanks everyone thanks everyone