 Hello, everyone. This is the Circuit Python Weekly Meeting for October 2nd, 2023. This is the time of the week where we get together to talk about all things Circuit Python. My name is Tim, and I'm sponsored by Adafruit to work on Circuit Python. What is Circuit Python, you might ask? Circuit Python is a version of Python that is designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafru.it-discord. We hold the meeting in the Circuit Python Dev Text Channel as well as the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when that coincides with the U.S. holiday. In the Notestock, there is a link to a calendar which you can view online in your favorite calendar app. We also will send notifications out to that Circuit Pythonista's role on Discord, so another perk of having that role is you'll get notices there in Discord when we do have the need to change the meeting to a Tuesday. There is a Notestockument that accompanies the meeting and recording. The final Notestockument includes timestamps to go along with the video so you can skip around and view the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes. After each meeting, we post a link for the next meeting's Notestockument into that Circuit Python Dev Channel over on Discord. Check the PIN messages to find the latest Notestock so you can add your notes for the following meeting. You wished to participate but can't attend, you can leave hub reports or status updates in the document and we'll read them aloud for you during the meeting. The meeting is held in five parts. The first part is community news. That's going to be a look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from the Python on microcontrollers newsletter which goes out weekly. The second part of the meeting will be the state of Circuit Python in the libraries in Blinka. That's going to be a quantitative overview of the entire project to chance to look at the project by the numbers separate from our status updates. The third part and the first of our two round robins is the hug reports section. Hug reports is an opportunity to highlight the good things folks are doing. Take a moment to recognize the awesome folks in our community and beyond. The fourth part is status updates. That is our other round robin section. Status updates is an opportunity to report on what you've been up to. You can take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be up to over the next week until the next meeting. The fifth and final part of the meeting is in the weeds. In the weeds is an opportunity for more long form discussion. Those can be discussions that came out of status updates or they can be identified ahead of time as too long for status updates. And a note on in the weeds topics as soon as you do come up with one if you do go ahead and just put that down at the very bottom of the notes. There's a section for in the weeds. It's best to get those listed in as early as possible. That way they're just there ready for us to read off once the time comes. So with that, we will get going on Community News after I get a timestamp. There we are. This week in the newsletter, a couple items that caught my eye where the Raspberry Pi 5 details have been released on the heels of the supply shortage easing comes information on the Raspberry Pi 5. There's a link here to the official Raspberry Pi 5 page. It also says there are many new features, many requested by the community and enthusiasts for modern computing. There are other links here to the Raspberry Pi blog as well as a YouTube video discussing this new model of hardware. And there are lots of additional details in the newsletter. So I would encourage everyone as always to check out the full newsletter as well where you will find even more great details about this device and everything else we'll hear about. The next item to take a timestamp for is the Python Developer Survey 2022 results. The Python Software Foundation has announced results of the sixth official annual Python Developer Survey. This work is done each year as a collaborative effort between the Python Software Foundation and JetBrains. Late last year, more than 23,000 Python developers and enthusiasts from almost 200 countries or regions participated in the survey to reveal the current state of the language and ecosystem around it. Spoiler alert, many people are using Python and 51% are using it for both work and personal projects. There are links here to the JetBrains page talking about the survey as well as the Python Software Foundation blog post talking about this. And a couple of the high-level cherry-picked stats that came out of this survey, there were 8% of those surveys, those surveyed are using Python for embedded development which is up from 7% last year with 10% using it as a secondary language for embedded work. There were 59% of Python users that use Linux, 58% of them use Windows, and 26% use Mac OS. And I am presuming there folks were allowed to answer multiple operating systems. So some folks use more than one, which is how we ended up with more than 100% there, I presume. The last one here, we have 51% use Python for work and personal projects alike. And then 28% use it only for personal projects and 21% use it only for work projects. Next up we have Open Hardware Month is October. October is Open Hardware Month. You can join OSHWA by certifying hardware as open source becoming a member or where it is safe due to the pandemic hosting a small event. OSHWA is providing resources and making the community and asking, excuse me, asking the community to host small local events, again only if it's safe, in the name of open source hardware. Hector Io welcomes Sid Dermay to discuss everything Open Source Hardware Association. OSHWA, the acronym for that, is planning for Open Hardware Month. Returning guest Aisha Lyfkar-Wilson joins the conversation as Alex Glow explores the process of documenting your projects on the way to OSHWA certification. Now is the perfect time to certify your own project, become a member of OSHWA or get involved in other ways. And there are links here to the OSHWA website as well as a YouTube video discussing that. Our next item here is for Hacktoberfest 10 has arrived. This year marks the 10th anniversary of Hacktoberfest. Hacktoberfest has grown from just 676 participants in 2014 to nearly 147,000 participants last year. There is a link to the main website here in the docs for that. What is Hacktoberfest, you might be wondering. The blurb that they've got here that describes it says join forces in virtual and in-person events to get your projects pull slash merge requests done as a team. Learn new skills and meet lifelong friends. This year we are partnering with Major League Hacking to help the community connect. Open Source projects maintained by community minded coders make the modern internet function. Support the essential work and the folks behind it is what Hacktoberfest is all about. As in previous years, CircuitPython will be participating in Hacktoberfest, marking some pull requests as Hacktoberfest eligible. The list of issues which you can find on circuitpython.org is linked here. You can do a filter on the Hacktoberfest label although I don't believe we have added them to the issues yet but once that has been done, that filter on the website will help you find those. There is also a link to the Adafruit blog post here where you can read more about Hacktoberfest and Adafruit's participation. And the last bit of info related to Hacktoberfest was just a heads up that the rewards system is shifting away from t-shirts this year to virtual rewards as well as the option for the tree planting I believe is still in the mix as well. And the next and final item from the newsletter this week is the Project of the Week, which is a PicoWare sensor that is logging data using MQTT. PicoWare is a tiny board to get started on environment data logging. It broadcasts PMS5003 particulate matter and other StemAQT slash quick sensor data over MQTT. It's also a tiny web server with a JSON API running on CircuitPython. There are links here to Twitter and GitHub for that project as well and there is a nice photo of it in the newsletter. Also, so check that out after the meeting. With that, I will tell you more generally about the newsletter. This is the CircuitPython Weekly newsletter. It's a CircuitPython community run newsletter that's emailed every Monday. The complete archives are available at AdafruitDaily.com. It highlights the latest in Python on hardware-related news from around the web, including CircuitPython, Python and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub. There's a link here to do that. You can submit a pull request with your edits. You can also tag a tweet with hashtag CircuitPython on Twitter and email it to cpnews at Adafruit.com in order to submit those ideas and projects for the newsletters. Next up is the state of CircuitPython, the libraries in Blinka. In the first part of this, we will hear about the overall state. Let me catch my place here as well and tell you a little bit more about it also. State of CircuitPython libraries in Blinka. That is going to be a quantitative overview of the entire project, a chance to look at the health of the project, some stats related to the repositories and things, separate from our status updates. We'll talk about the project overall and then separately discuss the core, the libraries and Blinka. Overall is first up and I will timestamp and tell you about that. Overall across all the repos this week, we had 23 pull requests merged by 11 authors. The names here that were newer or less familiar to me, so these folks might be new contributors or perhaps less frequent contributors, or perhaps just a name that I didn't recognize for some other reason, but those names this week are Maker M0, Pettismith and Rimwolf Redux. Thank you to those folks as well as all of our more frequent contributors. Let's see here. Yes, that was our 11 authors. For those 23 pull requests, there were seven reviewers. That's mostly the usual list of suspects. Thanks again to all the folks who are helping us out with reviews. As always, the more folks willing to review is going to mean the more submissions we can support. Thank you, thank you, thank you to everyone reviewing. There were 19 closed issues by five people, there were 19 issues opened by 16 people, and there are currently Hacktoberfest labels assigned to zero issues, so we'll work on getting that assigned and then those numbers will be represented here as well in future meetings. Next up, I will pass it over to Scott if you're available to tell us about the core. Happy to, thanks Tim. Okay, so for the core we had 12 pull requests merged from seven different authors. I won't highlight the new folks again, but thanks to those folks. We had five reviewers, so newish or infrequent reviewers. I just want to highlight our Paint Your Dragon and ANiC data, so thank you for reviewing. We have 18 open pull requests, which is well under the 25 one page limit, which is great. The oldest one is still 454 days old and I believe that is the multiple like mass storage units in USB and we're just not working on that right now. I'll bug tack. Issues wise, we had seven closed issues by four people and eight opened by eight people, so we're not one, which is great. None of them currently have our labeled hacktoberfest, so we can work on that. We have 727 total open issues. The vast majority, 607 of those are long term. Long term means is a milestone and we use milestones to know to triage issues as we come in and prioritize the work for the folks that are funded by Adafruit. So there are 10 open issues for 8 to X, which is going to be the latest or the most recent stable release. And then 9.0 has 58 open issues. So that's our longer term, bigger changes, stable release that is at least a few months out still. And we have six issues not assigned to milestones. We'll have to take a look at that as well. Those need to be triaged and that's it for the core. All right. Thank you, Scott. Next up is the libraries. So this section covers all of the libraries that are on GitHub under repos that are named like Adafruit underscore, circuitpython underscore, and then the library name. These are the Python level code that allows you to interact with various bits of hardware or provides helper functionality for you to make your projects easier to code. Across all of those libraries this week, we had nine pull requests merged. Those nine pull requests were made by a total of four different authors. So thanks again to the newer name there, Pettismith, as well as our more frequent contributors, Melissa, Dan and myself. We did have three reviewers for those library PRs this week. So thanks to Scott, Dan and myself for library reviews. There is a list of the merged pull requests here. They're all only one day old. So this week was a week of just smaller pull requests that got merged right away. None of the older ones were in the mix this week. That does leave us with 46 open pull requests. The oldest of which is 410 days. The newest of which is back down to just the one day. We had across all those libraries just one closed issue by one person with six new issues opened up by six people. We do have still just zero issues labeled with Hacktoberfest. There are 645 open issues of which 19 of them are good first issues. I will note we've mentioned a few times the lack of the Hacktoberfest labels just as a heads up for anybody who happens to hear this and does. I want to work on contributions for Hacktoberfest just because we don't have the label in them right now does not mean you won't get credit. We can always add the label to any submissions as they come up. We'll also work on getting it added to the issues that are in existence already. But yeah, if anyone does want to be contributing your contributions totally will be counting during this. I believe it's the calendar month of October, but I don't know the specifics. But just because the label is not there doesn't mean it won't count. We do have let's see library pipi stats for the week. In total there were let's see I always don't know the comma there we go 178,065 pipi downloads for the 313 libraries. The top 10 libraries listed out by the number of downloads is here in the note stock if you'd like to take a look at that. As well as the libraries that were updated within the last seven days. There's a list of those in here as well if you want to take a look at those. And with that I will pass it over to maker Melissa to tell us about Blinka. Hello, so Blinka is our sector Python compatibility layer for MicroPython Raspberry Pi and other single board computers. And this week we had well this is for like all the different repositories that are related to it and see. Oh, this week we shifted on me here. Oh, the Blinka library went down here now. Okay, this week we had people request merged by one author that's myself and two reviewers if he's gotten me. And there were four open puller there's currently four open pull requests amongst all of them. And there were 11 closed issues by one person and five opened by three people. And I think the most that was my activity actually. There are currently 72 open issues we were over 100 at some point so it's definitely coming down. And there were there are 17,160 downloads through 5pi in last week and 2,119 pie wheels downloads in the last month. We are at 121 boards. And as from the guy mentioned, it says there are zero issues signed October fest. But October fest actually allows you to put a topic of October fest on the different repos and I don't think it counts that. And I went through already and have just made sure all the Blinka ones are have it assigned. And that's it. All right. Thank you, Melissa. With that, we will move on to hug reports. Hug reports as a reminder is a chance to highlight folks in the circuit python community and beyond for doing awesome things. I'll start and then we'll go down the list alphabetically or however it appears in the note stock to give everyone a chance to participate. If you are text only or missing the meeting then I'll read your notes when we get to them in the list. So I will get us started. Let me get a timestamp. Hug reports for me this week. Thank you to Jeff. We had the opportunity to get together and chat as well as have dinner. So it was a great time. Thanks to Jeff for that and plus one hug report for the introduction to a great new restaurant up in Omaha hug report. Thank you to make Melissa for working on rewriting the necessary parts of Blinka display. Thank you to Vector IO to bring it in line with current core API as well as another one for organizing the related issues and creating new ones to track further improvements and additions of newer core modules like bitmap tools and vector IO. And then my last one for the week. Thank you to Michael Pocusa for continued work on the templating engine. Next up is Charles Bernefurt speed text only for Charles. Got a mic check from him earlier but we'll read I think for now Charles has got a group hug for everybody. I had a couple of usages of Python this week. Thank you. All right. Thanks Charles. Next up is the ship. All right. Thank you to ship. Next up is DJ Devon three whose text only so I'll read DJ Devon Scott hug report for. Tanute Scott for the RGB matrix allocation fix as well as group hug for everybody. Thanks to DJ Devon for those. Next up is Fetty two whose text only as well to anyone who has done any work on circuit Python. It's much easier much easier to use than anything else and it makes development fun thanks to you all. And then Fetty two also has a hard report for Tanute Scott and the rest of the crew for the ESP IDF 5.1 upgrade. If Bluetooth ESP comes from this it will make me extremely happy. Next up is Jepler or Jeff who is missing the meeting. Jeff has a group hug a hug for Liz. I'm jealous of some of the projects you have coming down the pike. I know you'll knock out of the park and then a group hug for everybody that says see you all in November. Jeff is out on vacation for those that don't know and so he'll be back next month. And next up is maker Melissa. Hello. I have a hug for Jeff for good chat made last week and for getting the quality as three guys started. And a hug to the user. For rewriting some of the display, which I ended up using parts of in my huge update. And a hug to pass me for creating a page about telling some of the e-ings apart which came in super handy in a group hug. All right. Thanks, Melissa. Next up is Mark gambler. Mark has a hug report for Biffle Bear on GitHub for the AS 3935 driver. It saved me so much time. I think I forgot a hug for it previously. Mark also has a group hug as I can finally listen to the live meeting. So that's awesome. How's it going, Mark? Thanks for tuning in and thanks for getting your hug reports in there. Next up I will pass it over to Scott. Hello. How to paint your dragon, Philby, for the audio fix PR and the corresponding issue. Awesome. Thank you, Scott. Next up is Todd Bot who's missing the meeting and out sick. So I'll say firstly hope you get to be feeling better soon, Todd Bot. Todd Bot left a group hug and a high for everybody. And that is it for hug reports this week. Next up I will just a timestamp. We'll move into status updates. Just as a reminder to folks, status updates is our time to tell folks what we're up to individually. I'll start and then we'll go through the list alphabetically or as they appear in the note stock. When I call on you, take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be up to 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. If a discussion becomes too long for status updates, we can move it down to in the weeds. So I will get us started with a timestamp first. Last week I followed up on the remaining failed actions that were revealed during but not actually related to the recent patch and release sweep across the libraries. Most of them are related to referencing a core module that hadn't been put into the mox dock list from actually an update that I had made for their back. I submitted fixes for all of those that I could. There were three failures that were different than those. They weren't the same reason and they, as far as I could tell, were something related to the token or the permissions when it tried to upload to either PyPy or GitHub to upload the assets files. So three of those had that issue and I, as far as I could tell, kind of hit a wall and can't really dig much further. I think we need somebody who can look into those repos to take a look. There is a post in the Discord with that further back. I can also pull it back up and post it again if that's helpful. There was one more that was separate from those three that had a different error that I never really could understand the actual root cause of but it's also a weird one because it says it fails to upload the files to the GitHub assets page but those files do show up on the GitHub assets page. So it seems successful other than the fact that it prints a message that says it failed. So that one's kind of odd and I couldn't really figure it out. The other thing that I worked on before I went out of town last week was wrote the first draft of a simple test script for the ESP32-S2 TFT. This was a concept discussed in the weeds a couple of weeks back but when I wrote it I did not have Wi-Fi access at the time so I was kind of working on the sad path so to speak instead of the happy path. I need to retest it now that I'm back home and I have a real network I can join make sure it's good and then I'll get that submitted as a simple test for that device. For this week I am working on enhancing the Automated Releaser Utility that I was working on last week. I am removing some of the hard-coded values and adding functionality that will prompt the user to select what the new tags should be as well as enter the title if one was not supplied with the configuration variable. So this will make the utility more generally helpful is the goal hopefully. I also for this week am going to be testing the ADT-7410 rewrite PR. I think I mentioned it a week or two back but didn't end up getting into it but I do still have the sensors sitting here on my desk to look into that and then the other thing that popped up that caught my eye was all the work on Blinka Display.io so I'm hoping to snag some time to try out the latest version of Blinka Display.io especially with the Pi Game Display library and then work on any fixes that are needed for that Pi Game Display library if there are any to work with latest version of Blinka. And that is everything that I have got. Next up is Dan H not at the meeting but Dan says continuing with MicroPython version 1.20.0 merge working on board builds I have several boards compiling and I can do things in the REPL boards builds are bigger for some reason and I'm researching why. Next up is the Shippu. So I've been trying to write a version of the keypad library that works with touch because I need that for some of the boards I'm using and that's for some D21 and some D51 platforms only. And I was hoping to because there is this Qtouch library by our microchip but it's a commercial library that is able to do this and it can do interrupts on touch so I was hoping to use that. Unfortunately there is very little documentation on how to actually use that mostly because they sell that library so I assume the documentation is all there with the library documentation when you buy it. So I've given up on doing that and the next I have one more approach I want to try not using interrupts but kind of scanning in between of the ticks of the keypad interrupt but we'll see how that goes. So it's possible I will give it on that as well. And the second thing that helps my attention I always wanted to use the April tax library which is basically graphical fiducials that you can track with a camera. For my robot projects it will be useful for all sorts of camera tracking projects I suppose. And it works with OpenMV. The OpenMV people have it implemented in their code so I was hoping I could port that to ESP32 to use it in CircuitBitone as well. So I started working on that but that is also a huge amount of code in there like custom matrix operations and custom mathematical things that I don't fully understand and so I'm also not having much hope with that. But I also discovered that the library that we already use in CircuitBitone for QR codes is able to also return the coordinates of the QR codes that it found. So I'm now in the weeds there is a topic on how to expose that to CircuitBitone and if we expose that I could use QR codes instead of fiducials which is not optimal but still a pretty interesting use case I think. That's it, thank you. Alright, yeah, thank you to Shupu. Next up is DJ Devon3 which is text only. DJ Devon says I'm in the mountains. They have raccoons and skunks as pets. A lovely remote place with internet. Next up is 88CC who is text only. 88CC says working on RP2 ports of the underscore BLEO module have a skeleton implementation in place that I'm filling in with functional code plumbing the depths of background callbacks delighted to see that CircuitPython has limited multitasking. 88CC also says seeking working CircuitPython BLE examples for testing also seeking Wi-Fi examples to ensure coexistence. And I would just add quickly the BLE repo, Adafruit CircuitPython BLE is good for examples for BLE stuff and then there's also some libraries that are higher level that have examples in them as well and then for Wi-Fi requests and many MQTT libraries are great places to find example code for stuff that will use Wi-Fi. Next up is FedE2. FedE2 says I've just finished porting CircuitPython to the ESP32 micromod that SparkFun uses for their weather station and I'm finishing up with pins.c and we'll send a PR. Nice, that sounds pretty cool. And then FedE2 also says recently got some Milky Duo boards to test both Blinka on top of Linux and TinyUSB as mentioned on a previous weeds topic. And next up is Maker Melissa. Okay, so last week I finished updating the Blinka display IO so that monochrome and grayscale displays are now supported. That's been merged in and then I also finished a PR to add e-ing display support to Blinka display IO. This week I am working on writing a learn guide for the new quality IS3 and afterwards I'll probably work on getting back to testing at more displays and e-ings in the display IO and adding examples to the appropriate driver repos. Then I'm going to probably be working on updating learn guides for running the displays in Python. And that's for Matt. Nice, thank you, Melissa. Next up is Michael Pokusa, who's text only. Michael says finished working on the Adafruit template engine, waiting for it to be released. Then I'll add examples to Adafruit HTTP server library that utilize it, created a wrapper for Adafruit HIDs mouse or mouse class, I think that is, for drawing shapes based on SVG or SVG path and or both cubic and quadratic bezier curves. It can also be used for just more complex mouse movement than up, down, left, right. And there are some photos here in the note stock that kind of add a lot of context to what this is talking about. Basically, it looks like a way to convert the data that's inside of an SVG into something that you can put in your Python code that is utilizing Adafruit HID and then it can draw that shape on your computer using your mouse. So if you open up paint or whatever Photoshop, some kind of program that lets you draw with the mouse, it will replicate in your beginning shape, which is super fascinating. So, cool stuff there. Next up is Scott. Hello. So I submitted a quick partial fix for the RGB matrix crashes. Basically, if you recreate the RGB matrix enough, you run out of supervisor allocations, which causes problems. It's still not perfect because supervisor currently will move memory and we don't tell Protomatter that. So it's possible that Protomatter will use the memory even after we've moved it, which is not good, but is probably less of an issue than the leaking of the Protomatter allocation or the supervisor allocations. I also submitted a PR for re-enabling RGB matrix on the ESP in main so that the crash fix is on 8.2 and then the re-enabling is on main for ESP 5.1. That also includes changing the refresh function call on frame buffer IO, which makes it match display IO's refresh call because it is way saner and it actually refreshes when you want it to. Yeah, frame buffer was using the old version. We updated the display IO version but did not update frame buffer IO, so that'll be good and that'll be helpful for the dot clock displays that also use frame buffer IO. And then I have some bigger work to do around these supervisor allocations that are so bug prone. Basically, in MicroPython 120, they add the ability to split the MicroPython heap, so it's not just one big allocation that takes the rest of memory. Instead, it's a bunch of smaller allocations that can grow based on the underlying heap. So there's a heap that lasts the whole time you're running and then there's a heap that MicroPython allocates objects into. And that's basically how we have to work in the ESP port anyway and so I'm gonna make it work that way on all ports. And the huge advantage there is that any time is that we can allocate to that outer heap even if the VM is running. So for these cases where we need a proto-matter frame buffer, we could do it to the outer heap and then we don't have to move it, which is just way simpler than doing all of the supervisor move stuff. So that's what I'm gonna do this week. And it does depend on MicroPython 120, which is not merged in so I'm gonna coordinate with Dan on this work as well. Yes, it will affect low memory platforms. I expect us to have to do some tuning. One of the perks of doing this is that there's a couple of places and displays is one of them where we statically allocate and we don't really need to, right? So right now we have this hard limit for all but one board where it's like one display is all you can do. But the only reason we do that is because we statically allocate space for that one display. So if we move to a world where we can actually dynamically allocate it, we can do any number of displays as long as it fits in memory. How that performs on the Sandy 21 is, you know, I think we'll get fewer static allocations which should leave more memory overall. But I expect we'll have to tune the memory splitting so that it works pretty well even in constrained environments. So yeah, obviously we want to make sure that all of the example code and learn works and I know, Radimir, that you have stuff too. So it is going to be another big change with 9.0 but I think it's going to simplify code a lot, make it less buggy and also make it easier to do dynamic allocations that don't apply to Python but happen when Python is running. So it's going to simplify things. For example, on the Sandy 21, when we're writing to the file system, we need a 4k buffer and we play all these tricks in there to say, oh, if Python is running, we'll try to allocate it on the Python heap and blah, blah, blah. And then once we allocate it to the Python heap, we have to worry about turning Python down and keeping it around and blah, blah, blah. So that's one thing on the Sandy 21 specifically that's going to help, that's going to make it simpler too. So yeah, I fully expect there to be some teething issues and we're going to have to tune it but overall it's going to make things simpler and I think this is going to better align with the direction that we're going with, that MicroPython is going as well. So yeah, I don't expect it to be perfect but I think it's the right direction to go. Lastly, there's a current pull request from Pomeroni where I'm pushing them to make native IO expander support and also expanding some internal APIs so that you can pass something that's not a pin. So specifically like on four wire for displays, they want the chip select pin to be on an IO expander. So I have ideas on how I want to do this but I don't have the cycles to do this because I'm going to do the allocation stuff. So if that's interesting to anyone, please let me know too. And that's my long-winded update. All right, thank you Scott. And that is it for status updates. So the fifth and final section of the meeting is the in the weeds section. Take a time stamp for it. Let me also find this, scroll away from my apologies. In the weeds, this is an opportunity from our long form discussions. These can either come out of status updates or have been identified ahead of time. We do have a couple of topics down in the weeds noted in our document. So I will turn it over to DeShippu if you want to introduce your topic to us. Okay, thank you. So as I mentioned, I'm looking into QR codes a little bit now because I have this Xiaosense board with a built-in camera. It's very nice on the ESP32S3. So a lot of memory for dealing with stuff and a lot of processing power. So it would be nice to have some, you know, vision algorithms in there to build some interesting projects. And one interesting thing you can do is tracking obliques that are somehow marked. And the usual way of doing that is by using FidoShelves. I looked into that, but it would take me a while if ever to get that library working. So I also looked into QR codes because FidoShelves kind of look like QR codes. And the mechanism is very similar. Of course, QR codes are not designed for this particular case. But still, when I looked into the C library that we use in Circuit Python to read the QR codes, it turns out that it sets a two-step process in that library. First, it finds all the candidates for QR codes on the frame, basically, that it has. And saves the coordinates of those. And then as a second step, you can ask it to decode the actual data from a particular QR code that it found. So right now, the way the library works, it just makes those steps right away. So it goes through all the QR codes it found and decodes them and returns the list of the coded QR codes and skips the ones that were too small to decode. And I was thinking if we somehow exposed the information about the found, the coordinates of found QR codes, then we could do a kind of tracking thing where if you have a camera mounted on some servers that can move, you could turn towards to center on a QR code, for instance, to better read it. Or if it's a mobile robot, you could even follow a QR code or go towards it. I think that opens a lot of interesting possibilities. Now, how do we expose that? We basically have two choices. We could use the existing API and add more information to the list that is returned when the QR codes are decoded. Basically, it's the coordinates of four corners of the QR codes. So we could add that to the data that is returned. And the advantage of that is that we know which QR code data goes with which code. We have this mapping between data and which QR code it is. The downside is that we are losing those QR codes that couldn't be decoded. And that the operation that this finding and the coding operation takes longer than just finding them. The other option is to add a separate method. Just find the potential QR codes and their positions and not decode them right away. Then you can use the decode operation. Once again, once you know there is a QR code that is close enough, you can compute the size of the QR code from the position of its corners, for instance. And guess if it's big enough to compute or if you are not even interested in the data in the QR code, you just want to know where the QR codes are. You can just skip this entirely. So I linked to an issue for that. There is some discussions with some other ideas in there as well. I'm willing to implement this. I want to implement that. So basically I just need opinions on how we can do this best. Do you expect that you want the positions that aren't decodable? Or would decodable ones be enough? That's what they think. I don't know how people are going to use this. I'm asking how you're going to use it. Yeah, I'm going to use it on my robots to follow and to do things. So I'm going to only decode the QR code if it's large enough. But you do want the small ones. Yeah, I will scan for the small ones and I will... Potentially I can walk towards the small ones to make them bigger. And then only scan them if they are big enough. But I think it's potentially interesting to have also information. Okay, there are other QR codes on this image that are too small to decode, but they are still there. Well, one thing I thought was we could document QR info as having none payload bytes. Right, so add position to QR info and then also allow it to be none. Right, add arguments to the function that doesn't filter the ones that couldn't be decoded. I wouldn't even do that. But I guess you need that for backwards compatibility. That would actually work. I don't think anybody is using this though, so I would maybe... Yeah, that's another thing. Just do it in 9 and we'll just say now you could have these as optional. Now you'll get the ones that don't have payloads. Another option is to... Right now it finds all the QR codes, the codes, all of them, and returns the information as unnamed tuple. You have all those fields in there, but it's under the hood it's unnamed tuple. We could have it return a custom object, it has its own methods, and then the coding, for instance, could be a method in that object. I would only decode the QR code that you actually want, not all of them. For instance, I think it would make... For the usual use case of just scanning a QR code, you just want to decode the largest QR code you have. Right. In your camera. It's probably also the only one, right? Right, most of the time it will be the only one. So we could have a helper function that sorts them by size and beats the first one and only decodes that one. I wouldn't even worry about that. Yeah, I mean, this is... I think that's fine. You could change the decode function to find and then add a decode method on QRInfo. Yeah, that's another way to do it. And then I could... I guess I could have helper properties on that that actually give you not just coordinates, but for instance, the size of the... Right. That could be interesting. Yeah, I guess I would say overall, just change it to make it work for you. This was mainly added for an upcoming Adafruit camera board as a demo. So the only stuff that we'll have to update is some demos that Jeff has put together for a product that is not released yet. So I think it's fine to make it a bit more flexible for you and we can update things as we... Okay, thank you. And we'll just call that 9.0. We'll just do it at 9, we don't have to do it at 8, and we'll just update it. Okay, that sounds cool. All right. And our other in the weeds topic is from Carter. Carter, do you want to introduce yours? Sure, this is... Most of this is just me kind of catching up on something that isn't new because that pull request, which is closed at a link, I think it says like seven months old or something. But I came across this happening because I got a guide feedback for the display IO guide that said, please update this to the new API change. And that kind of went digging into it and learned about it. And I'm okay with doing the guide update change, but then I asked the bigger question. I was doing this in Discord on Friday and I think Dan was the only one around thinking about it. It was like, okay, how are we going to update all of the code we've got out there, which is what this pull request was kind of asking the question. And it looks like the answer was going to be deferred. So the PR was closed. I'm wondering if we're getting close to that event horizon and we need to start figuring out what we're going to be doing about this. Yeah, I think we probably are, especially I think the big key is that there is a 9.0 out now. And there wasn't back when this was made and that 9.0 is, if I recall correctly, such that the new way works and the old way does not work. I think 8.0 was the one where both worked. So we definitely, I think, anytime we're looking towards 9.0 becoming stable, we are also looking towards needing to do that basically in conjunction with it. And I would say, I mean, from my perspective, I think it's probably fine to work on this at any point now. It was a little early back then, since we didn't have the new version. But I mean, in my mind now that there is a 9.0 that's available that you can download, it's not the, I don't think it's the primary release or whatever, but it's out there and available. Well, it's only absolute latest. We haven't tagged a pre-release yet. And we're waiting to do the MPY stuff until 120 is merged because 120 is going to change the MPY format again. But I think that's actually less important here. I think the decision that we should talk about here is, are we okay turning all of the 7x bundle stuff off? Because, and this is what we've done is like, at some point we say like, we're going to freeze kind of like the 7x bundle world. And then after that we can remove all the backwards compatibility to 7. So I think that's the decision we have to make is like, are we going to stop building new library stuff for 7x? And I personally am comfortable with that because I think we're well into 8 being stable. But that's, if anybody disagrees with me now's the time to bring that up. So for that issue, it's actually about like, CirclePython 6 stuff. And that's just like, at this point, I don't think that needs to be included in the examples, regardless of whether the, we have the 7 stuff included in the bundle or not. What is? Okay. So the issue that's linked in here. Oh, it's less than 7? Yeah. Oh, okay. Yeah. Yeah. And I already have a PR in for the SSD 1680 to remove the old 6.0 stuff. Wouldn't it also be 7? Yeah. Well, when it was, it could work at 6.0 or 7. Or ones that worked in 7 and more. And so at this point, I think removing all that is a non-issue. Well, this change here is getting rid of show and replacing it with the root group assignment. Yeah. Okay. And show works in 7, but it... Okay. So I thought this was about like, in some of the examples that said like, run this code for 6 and 7 and run this code for 7 and later. I thought that's what the issue was. Yeah. So we should be able to remove 6 support from... Yeah. The latest versions of stuff. Okay. That bundle has already been frozen. But in general, that's kind of the question, still the question, because as soon as this happens, all of the existing code is essentially going to break. Because I can see what everyone's going to do. It's like, 9.0 is out. Like, I'm going to go grab the latest, the update to 9.0 firmware. And they're running some cool learn example from years ago. And it's going to all of a sudden break. And we've got tons of CP code in the learn repo that's doing display show. I mean, have we actually removed it? No, not yet. You haven't. You haven't yet. So maybe this conversation may be premature, but I feel like we're getting close to where this is going to happen, right? We're probably going to do a 9x release. Yeah. 9x stable is quite far away. Like months. OK. So let's just do this. Like, we don't even have an alpha yet. OK. OK. Right. OK. So like I said, this is me kind of catching up, because this is the first time I kind of saw this API change. I guess it does say it'll be removed. So we could do that. Looking here. The warning on show is that it'll be removed at 9.0. Correct. We shouldn't do that. We haven't yet, but we should. And you will do that when 9 comes out, correct? Right. Right. So that's, so if we're far away from that hitting, then I guess we can just defer this discussion to that point. But you kind of see what's going to happen. And I kind of have the exact same questions from the guys brought up in that poll request, that second bullet, like how exactly are we going to change things when it does happen? Well, so 8 has both, right? 8 has show and it has root group. Right. So we update everything for the new API and everybody has that available in 8. Right. So this is, we got to move people off 7 onto 8 in order to be able to update the libraries. And the way that we've kind of done that and Fed A2 is saying like, well, our answer to that is basically, you can download the old version, you can download the old libraries, right? And I think there is a place in the learn system where we have like, if you're using this old version of CircuitPython, here's the last bundle we built where you can get all the libraries for CircuitPython 5 or 6 or 7. So I think the first step is to turn bundles off for 7 and then we can link to that and now we can assume with all of our code that we're running on 8 or newer. I see what you're saying. Yeah, that makes sense. And the same way that we should be able to assume that we're running on 6 or we're 7, we're currently running 7 or newer in our libraries. So it sounds like we could start making these changes. Right. Since both are supported. And then the answer for anyone that runs into this, I guess two answers. One is like, we'll just update to the latest firmware so that the code example matches the API. And in those weird cases where for some reason people are wanting to run old stuff, it's like you said, you can go grab it. Right. But I guess the one hanging thing there is, I guess maybe they're kind of on their own for this is they will have to change the root group equal back to show in any code example, right? Correct. Yeah. And I can talk to that in the display IO guide. Like mentioned that at this version break, the old way is this, the new way is this. Right. And just kind of, if you're using old versions, do this, new versions do that. Well, so I think, yeah, so I let's not make those changes until we have that final 7x bundle. Which we could, you know, do, we could make the change today and do it and we'll get it tomorrow. Or today's 7x bundle will be the last one. But we shouldn't start making changes that will break on 7 until we're done making bundles for 7, I would say. Okay. And the answer to that second question in the PR bullet about should we use different wording is no. Basically we're just going to do a simple show is going to go away and it's going to be root group equal. Right. And that's it. Okay. And then should it, so when that PR was submitted, I put both versions in there with the, the one that's old, quote unquote, the going away was commented out. Would we want to still include that or just get rid of it altogether? And only right. That's the question. Yeah. I think I like what Carter was saying is like in the guide, we can include that, but I would not include it in all the sample code. Right. Because in all the sample code, there's a complexity that people generally won't need. Right. Like generally, I agree this table. This, this whole commented out code thing is, is hit or miss. It's, it's, it's, it's an imperfect answer to a, we get a lot of feedback of like, well, I want to see what is the code for this board, this button in this pen? Yeah. We try to like have a huge comment out code block. It's like, okay, if you have this board and this button, and it says, but people just kind of get wrapped around the axle of reading all of that and knowing exactly what the uncomment comment. Okay. But other people want to see it, but I think I agree with Scott. Let's just, you know, it just, so no, you wouldn't have what's in Fummy Guy and your PR. It would be display show goes away and line 27 display group, group equal goes in. Yup. Okay. And then, I won't do anything on that until the bundle sounds like after the seven X bundle. Yeah. So I've got it. Well, that's all. Is that it? I've got the, Okay. If, it sounds like you're, you're volunteering to stay on top of this and, um, yeah, I can do the work when it's time to do it. When the time comes around, yeah. This is what, this target loss Python file. It takes, what we build. Are there any other, are there any other API changes planned for 9.0 besides the removing of show? I haven't done that. Uh, I haven't looked. Okay. We'll have to, we'll have to look for more comments like that. And generally we have issues. Like we haven't a label for, we have a label for, uh, breaking or breaks API. I don't know. I don't know. I don't know. I don't know. Uh, breaking or breaks API. On circuit Python. So hopefully we have issues for those. Uh, as well. Melissa, I know in your display code, you replicated the display limit, but I'm also hoping to get rid of that. In nine. Um, so. So yeah, hopefully we'll get rid of that too. Um, should we reopen this? Uh, or I really, how I should phrase this is, it's going to be much easier for me to remember to do this. If I reopen this thing, because then it will show up in my notifications and everywhere. Yeah. I mean, the conclusion was like, let's defer it until people are on eight. And we're definitely in that place now. Like if you're still using seven, you know, cause like we're doing bug fixes for eight. And so like we're not, we're not going to do any more bug fixes for seven. So people, people need to update. So I'm going to make a PR right now where I delete the seven X bubble. And then once we have 120 merged, we'll start doing nine point zero ones. Sounds good. Yeah. That was good. Thanks. All right. Sorry. I am. I'm here writing a reopen, but it's actually everybody's waiting on me to wrap up. Let me get to the correct window. Apologies. Oh, right. Sorry. Sorry. Sorry. Sorry. Sorry. Apologies. All right. The bottom wrap up. Okay. I'm going to pass it. All right. So that is it for the meeting this week. Thank you to everyone who participated the, let me get, there we are. Okay. That was the weekly meeting again for October the second 2023. Thank you to everyone. If you do as noted at the top of the meeting, if you want to help support circuit Python and Adafruit and those of us that work on circuit Python, consider purchasing hardware from the shop at Adafruit.com. The video of the meeting will be released on YouTube at YouTube.com slash Adafruit and the podcast will be made available on major podcast services. It will also be featured in the Python for microcontrollers newsletter. You can visit AdafruitDaily.com to subscribe to that. The next meeting I believe on the calendar is scheduled for the usual time of Monday at 2 p.m. Eastern 11 a.m. Pacific. I don't, I don't think, I don't think so. I don't think so. I just think it's... Indigenous people's day, but I did see, at least on my calendar it showed, but it sounds like maybe Tuesday then. The host, the host calendar is still on Mondays, but the actual public calendar gets shifted. Okay. I'm always looking at the host calendar. That's probably where I am. So next week we're on Tuesday. I apologize. Next week is Tuesday the 10th of October for next week at the normal time of 2 p.m. Eastern 11 a.m. Pacific, but on Tuesday instead of Monday. So adjust your calendars and reminder for folks with CircuitPythonEast's role. You'll get Pings and Discord as a reminder for that as well. Let's see here. I've lost my spot again. There we are. The meeting is held on the Adafruit Discord, which you can join anytime by going to adafruit.it. To be notified of changes in the meeting, just like I mentioned a moment ago, you can ask to be added to CircuitPythonEast's role on Discord. That's all for this week. Thanks, everyone, and we will see you all next week on Tuesday.