 Okay, got my time stamp, we're going. Hello everyone. This is the Circuit Python weekly meeting for Monday, January 9th, 2023. This is the time of the week where we get together to talk about all things Circuit Python. I'm Dan and I'm sponsored by Adafruit to work on Circuit Python. You might ask, what is Circuit Python? It's a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to sponsor Adafruit and Circuit Python, consider purchasing hardware from adafruit.com. We host this meeting on the Adafruit Discord server. You can join anytime by going to adafruit.it-discord. We hold the meeting in the hashtag CircuitPythonDev check channel, text channel, and the Circuit Python voice channel. Typically, this meeting happens on Mondays at 2 PM US Eastern time at 11 AM Pacific time, except when it coincides with the US holiday. In the notes doc, there's a link to a calendar that you can view online or add to your favorite calendar app. We will also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the AdSign Circuit Python Discord role. And that role also gives you permission to talk in the chat channel or use for this. And I'll note that I'll mention this later, but next week is a US holiday, and we'll be pushing the next Monday, so we'll be pushing next week's meeting to Tuesday. There's a notes doc to accompany the meeting and recording. The notes document contains timestamps to go along with the video so you can use the document to view only the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes, so this gives you the option to skip around. After each meeting, we post the link for the next meeting's notes document to the Circuit Python dev channel on the Adifu Discord. You can look at the pinned messages to find the latest notes doc so you can add your notes for the following meeting. And I will post a link to the notes doc, again, just in case you haven't seen it. If you wish to participate but can't attend, you can leave hub reports and status updates in the document for us to read during the meeting anyway. We hold a meeting in five parts. The first is community news. The second is the state of Circuit Python. The third is hub reports. The fourth is status updates. And the fifth part is in the weeds to where we have some extended discussion if there's something to talk about. So with that, I will start to read community news and take a time stamp, not two time stamps, just one. So let me start. So Circuit Python in 2023, every year we take time to, we ask for input from people to talk about their goals for Circuit Python in 2023 and beyond. Just like in past years, there's links in notes doc to all the previous years. The team would like everyone on the Python and Harbor community to contribute by posting their thoughts to public place on the internet, preferably by Wednesday, January 28th. If you'd like to comment about Circuit Python in 2023, you could post a video on YouTube. You could post something on the Circuit Python forum in our forums. You could make a blog post on your site. You could post on Mastodon. You could make it just on GitHub any way you want to write up or speak what you want to say. So tag that with hashtag CircuitPython2023 and email CircuitPython2023 at Adafruit.com to let us know about your post. So we can post it on the Adafruit blog. Post, you can cover any topic related to Circuit Python. There's a link to the blog post announcing this in the notes. And it's also on this court server right now. And already we just have that blog post. But I've seen at least one or two posts from other people right now. Scott's assembling these together. And he just came back from a vacation. So he'll be updating things as they happen. OK, that's one thing. Next thing, there is Bluetooth support for Raspberry Pi Pico W, which is likely coming in January. We're not talking about Circuit Python support for Raspberry Pi Pico W yet. We're talking about library support in the Pico SDK. It'll be in the 1.5.0 release. And then we'll start working on adapting that to our implementation of Pi Pico W. We don't know exactly what priority it will have, but it's very interesting to us as the Pico W was at the beginning for its Wi-Fi capability also. And there's a link to explaining all this in the note stock and in Discord right now. OK, that's the news that I selected from the Circuit Python, the draft of the Circuit Python Weekly Newsletter. The Circuit Python Weekly Newsletter is a community-run newsletter that's emailed every Tuesday. Archives of it are available. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python, and MicroPython developments. We are very interested in having you contribute your own news or something that you see that looks interesting. You can contribute to the newsletter by submitting a pull request to the draft, or you can tag us with hashtag Circuit Python on Twitter or Mastodon, or email cpnews at Adafruit.com. Any of those is fine, however you'd like to get it to us. OK, we'll move now on to the state of Circuit Python, the libraries in Blinka. This is a quantitative overview of the entire Circuit Python project that gives us the chance to look at the health of project separate from the details of what we're up to. We'll talk about the project overall and then separately discuss the Circuit Python core, the Circuit Python libraries, and Blinka. OK. So overall, in the past week, there were 30 pull requests merged by 24 authors. There are a bunch of people I don't recognize who might have not been contributed before. Xeas0930, Priestbh, Mattermachiak, 2231 Puppy. Maybe they already contributed Phonix232, and MontalXGPT, and Furbrain. And in the 30 pull requests, there were 10 reviewers of those pull requests. And the result of all this was that 21 issues were closed by nine people, and 14 issues were opened by 12 people. So we're net ahead in terms of closing issues. And the next up is the Circuit Python core. Since I'm going to read a bunch of stuff, Jeff, would you be willing to read the core? Sure, just give me a moment to scroll back to that. So in the core, which is the part of Circuit Python implemented in C, that you typically load as a UF2 file, we had 17 pull requests merged by 14 authors, including some names that are less familiar to me, Jay Greco, Xeas0930, Phonix232, as well as some regular contributors. So thanks to all of those 14 authors, as well as the 14 reviewers Dan, me, MicrDev, and Scott. In terms of pull requests, we've got 21 that are open. And it looks like about half of those are in draft state, and half are not. We aim to work on your pull requests in a timely fashion. But if you are waiting on us, please give us a ping. And we would love to help you get your in progress pull request back on the road. And if you have one that's been in draft for a long time, do consider coming back and deciding how to move forward on that as well. Anyway, issues-wise, we had 10 closed issues by four people and six open by six people. And it's nice to see the number trend down, although it does not trend down every week. That leaves us with 588 open issues. We mostly track issues by milestones. The milestone that we're paying the most attention to right now is the version 8.0.0 milestone, which has nine open issues that we'd like to resolve before making a stable release of version eight. There are also 32 open issues we'd like to solve during the stable cycle of version eight, and two issues that we're already postponing until version nine. As well, we've got 513 long-term issues. And what that means is Adafruit is not currently prioritizing working on that. It doesn't mean that we wouldn't love for you to pick up that issue and address it, especially if it's directly affecting you and how you use circuPacton. And I think, big thanks to Dan. There are zero issues not assigned a milestone. Keeping on top of that and triaging the bugs is really important, and I appreciate that that's happening. So as we've been saying for a while, basically the focus of the core is still towards version eight and issues come in and issues go out and we're just working on getting that number down. So if you can help us out with that and if you can test with the betas and give us feedback, that is always wonderful, and we appreciate you all for doing that. And that about wraps it up for the core. Thank you, Dan. Okay, thank you, Jeff. Okay, next up is libraries, and Katnie has agreed to read that. Yes, I have. All right, so this applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit Underscore Circuit Python Underscore on GitHub, as well as some extras, such as our community bundle and our cookie cutter. Across all of those repositories, we had 12 pull requests merged by 11 different authors and eight different reviewers. Two of those, actually, one, two, three, four of those pull requests were over two weeks old, so I'm glad to see that we're still, one of them was over a month, so I'm glad to see we're still chugging through older pull requests, and it looks like the rest are just keeping up with newer ones, and we then have a total of 46 open pull requests. We had 10 issues closed by five people and eight opened by seven people, leaving us with 601 open issues. 92 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more. If you're interested in reviewing, check out the open pull requests. If you have the hardware, test it. If you don't, look at the code, see if you see anything that looks a little weird to you, otherwise let us know you looked at it, looks good. That's always helpful. Leave a comment and let us know what you did, and once you are comfortable with that, we can talk about leveling you up to the review team. If you're interested in contributing to Circuit, or to Python code or documentation, check out the open issues. All of them are listed by repository, but the title is also included, so you can kind of scan that page and see whether there's anything that interests you. If you are new to everything, check out good first issue as a label. We have a guide on contributing to Circuit Python using Git and GitHub, and we're always available on Discord to help out, so don't let that process intimidate you. We wanna make sure that you can help in a way that works for you. This week in high PI download stats across all of the libraries, we had 96,312 PI PI downloads, and the top 10 are listed in the node stock. As for library updates in the last seven days, there have been no new libraries, but a short list of updated libraries. There is a new community library, though. Ooh, this is new to this report. CircuitPythonMagCal from FurBrain is a new community library, so if you're interested in that, check it out in the community bundle. And as far as I know, that's where we are with the libraries as I haven't been here in a bit, so I won't go into any deep explanation or anything today. All right, thank you very much, Katnity. Okay, next up is a report on Blinka. Melissa will read that. Hello, let's see. Kind of lost my place in the document here. Okay, so Blinka is our Circuit Python compatibility layer for Raspberry Pi, MicroPython and other single board computers like the Raspberry Pi. This week we had one pull request merged by one author and one reviewer. There are currently four open pull requests amongst other repositories. There was one closed issue by one person and zero opened. There are currently 86 open issues. There were 24,008 Pi PI downloads in the last week and there were 6,812 Pi Wheels downloads in the last month and we are at 100 ports and that's it. All right, thank you very much, Melissa. Okay, next up is Hug Reports. It's a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. I'll start and then we'll just go down the list alphabetically to give everyone a chance to participate. If you're text only or missing the meeting but you have Hug Reports and notes document, I'll just read those off as I get to them in the list. Okay, so I'd like to thank Jeff for diagnosing the duplicate volume ID issue on Mac OS which was kind of obscure and fixing it right away and it solved a problem for somebody else and we're not sure if this problem, I don't know if it was new in Ventura or not but it was necessary for it to be solved. So that's, thanks very much, Jeff. Thanks to Yousafis, Anecdata and Makal Pukusa for continued in fixing and testing of the HTTP server library which has grown a great deal in functionality and reliability since I hacked it up several months ago. Thanks, everybody. And welcome back Catney and Liz and Scott from extended Christmas vacations or over the new year, the holiday vacations I would say. Okay, next up is 2231 Puppy. Would you like to read something? Or I can? Sure, okay. So first of all, I'd love to give a group hug to everyone here and hug to Melissa and Dan for merging my board into Circuit Python. Okay, thank you very much. Everybody really loves this board. I haven't yet had a chance to see the show and tell about it, I'm gonna go look at it soon. Next up is Anecdata, I'll read their contribution. Thanks to Jeff for realizing USB volume IDs could be colliding and for adding exception chaining to requests. Next up is C Grover in text only, a hug to three community members that diffused a problematic issue on Discord while patiently and skillfully answering the underlying question. There are some amazing folks in there and a group hug. Next is David Glode, thanks to DJ Devon Three as I'm on the list for getting one of the last TR Cowbells. Thanks to Fomy Guy for coding live streaming about the TR Cowbell. Liz and all the other authors of the MIDI related learn guide and 2231 Puppy for his show and tell project that is projects that are always great including the latest e-fidget. Okay, next up is DJ Devon and would you like to read yours? Yes, I am here, I will read. I'd like to send a big hug to JP and Fomy Guy for coding live streams every week to Phil B for an exceptional Scorpio learn guide. If you guys have not checked out the Scorpio learn guide and what the Scorpio board will do, the detail he goes into is exceptional. A hug to Anne B for finding all the neat hot off the press news for the blog and newsletter letter every day. It's a daily source of enjoyment and inspiration. And a hug to all the circuit Python developers, PR contributors, reviewers, beta testers and helpers. And a hug to Lady Aida for all the new hardware and developments coming in 2023. It's all very exciting stuff. That's it. All right, thank you very much. Next up is Fomy Guy. All right, thanks, Dan. Hug report this week, just a group hug for everybody. Kind of echoing the sentiment there from DJ Devon for everyone who makes this project a possibility. Hug report for Biffo Bear on GitHub who submitted several improvements to the Ethernet library, Wiznet library 5K. Hug report for Mate Macheck. I think is maybe how that's pronounced but I could be incorrect there. This is another GitHub user. They submitted PR with some really nice improvements to the Sparkline graph widget that's in the display shapes library. They not only improved the memory efficiency which allows you to use more lines on your chart before you run out of RAM. They also made it to where you can draw multiple lines on the same chart. So if you want a chart like multiple different sensors or something like that on the same chart you can now do that. So thanks to them. And then last one for me, thanks to Noa and Pedro for creating and publishing the 3D models for the stem amounts that are Lego compatible. I had a nice opportunity come up to use those and it was very helpful to be able to just log in and download that and print one out. So thanks. All right, thank you Tim. Okay, next up is Jeff. Hello again. Yeah, so I have a group hug for y'all. If this is the only community that you participate in you might forget sometimes how much higher functioning we are than some other places on the internet and you're just great people to be around. A hug specifically to AnikData, Bill88T, RetiredWizard and all other folks chasing weird bugs. You know, you encounter these things and sometimes I take a stab at what the cause could be like with the volume ID thing and it pans out and sometimes it doesn't and we all are working together to ferret out whatever we're not understanding yet about these problems so that we can get them solved for everybody and it's great working with y'all. A hug to you, Dan, for staying on top of the issues and assigning the milestones, that's super helpful. And a hug to everybody testing the betas. Without you, we wouldn't be able to get all the bugs out. Just, you know, don't file so many bugs so that we can get to the end of the list. And that's what I got. All right, thanks, Jeff. Okay, next up is Katni. Hello. So I have a big group hug. Thanks to everybody for keeping everything smooth while I was out. We all built this community to be able to help itself in a lot of ways and I'm grateful for that to a very deep extent. And it's always nice to know that I can leave if I need to and know that there are very few things that would actually require my attention because everything else is heavily handled by everyone who is in this community and folks that are around. So thank you so much for all being amazing and I'm glad to be back. Okay, thanks, Katni. Next up, maker Melissa. I have a ag report to Scott Fern, encourage me to take some time off for the holidays. I have a report to you, Dan, for updating the web work flow guide with the settings.toml instructions. I know that I have a report to you for reviewing, bring this guide last week while it's still catching up and a group hug to everyone else just for keeping things up while I was out for the holidays. All right, thank you. Okay, and the remaining ones are text only from Mark Gambler, group hug to all as I have not been around a lot lately and from McCall-Fecusa. Thanks to USFS for reporting an issue in 80 Fruit HTTP server, testing its behavior on ESP32S3 and insightful discussion on Discord of possible solutions. And then finally, and Scott would normally be here is also not here today. All right, let me just update a timestamp here. Okay, next up, we have status updates. It's our time to sync up on what we're doing. I'll start and we'll go through the list as before. When I call on you, you can talk about what you've been doing since last time and what you maybe are planning to do until the next meeting. And this is an opportunity also to provide tips and tricks relevant to what people are working on. And if we get into a more involved discussion, we can move it to the weeds section at the end. So I'll start. As has been true for several weeks or even months now, I'm really concentrating primarily on just fixing 8-0-0 bugs which come in all flavors and sizes and genuineness or not. So I've been working on that. I did try an upstream fix for I2C on the ESP32S3 that I was hoping would fix some problems we have with sensors that go to sleep or do clock stretching. And unfortunately, that fix did not seem to fix our problems with those sensors. So I need to understand more clearly why that's true. Maybe does it work better on Arduino or something? Maybe we're doing something wrong or maybe it's still the case that we just have I2C devices that the S3 is not very happy with. And we have been talking about doing a, maybe even a release candidate soon, but we still have a backlog of bugs and we also have a bunch of fixes since beta six. It's been several weeks since beta six. So it may do a beta seven just to make it easier to point people to a version to test. So we'll see about that. Okay, next up is 2231 Puppy. All right, so I've been working on a case design like an enclosure for my e-fidget. So like, because that's the first step is selling them for me. So I need to learn CAD for that. And that's really all I've been doing. Okay, it sounds good. Okay, thank you. Okay, next I'll read Cgrovers. After adding two more lists like functions, the current version of pallet slice was submitted to the community bundle. The original reason for pallet slice was to allow a display IO dot pallet object to be easily modified by ULAB array. Posting a related issue for CircuitPython ULAB that apparently generated some interest and quickly evolved into a discussion that went completely over my head. I haven't seen that at all, I'll go look at it. Found a fun rabbit hole, replicated a 40 year old guitar pedal PCB and KiCad for the second time, but this time the original hand-drawn copper trace design was preserved. Two of the pedals fundamental chips are no longer available and haven't been for quite a few years. So the exercise resulted in discovering how to create an accurate restoration. Oshpark now has the Gerbers in hand and is preparing to give the design the after-drought treatment. I have an ice picture frame waiting for the restored PCB when it arrives. Okay, next on the list is to resume the PCB design for the precision VCO Eurorack module and send it off later this week. Of course, there won't be any distractions. We will see, right? Okay, next up, I'll read David Glode's contribution. Not much going on, acquired two more Bluetooth scales which are weighing machines. There's a link to that in the hope to reverse the protocol and make Wi-Fi connected version. I already tried to sniff it but there are too many Bluetooth devices at home so I plan to test it at the end of my garden when the weather permits. I know about that. Yeah, I see Bluetooth devices from other people's houses too, even. Okay, next up is DJ Devin 3. Hello, I have not done a lot of coding lately. I've been focused most on enclosure design. I documented the hardware ITC bus fix for TR Cabo version 1.2 which involves cutting two traces, adding bodge wire to three places and the fix finally puts both multiplexers on bus zero, frees up bus one for Stemma or just general use for anything that's on the ITC one bus pins. So it's not every pin, it's only a handful that are spread out throughout the Pico. I started printing a prototype enclosure. It took 16 hours to print one of four sections because my print bed is eight inches and the PCB is 12 inches. I have to print it in multiple sections. I just got the printer so I'm still learning Fusion 360 and CURA. Quite pleased with the progress I've made so far. Using heat set inserts to connect the two lower halves together and mount and mount the PCB. They work great and they're very simple to use. The board mounts right into place and it fits like a glove. I'm getting all the parts together for a second batch TR cowbells. Version 1.2 is to go out this month. The list is growing and I will have to stop accepting inquiries soon. The parts required is substantial. If you want one, DM me. They are completely free kits. Currently they offer is only for well-known community members, circuit pytenistas or out-of-fruit folks due to an address exchange being involved to current owners. Please don't hesitate to give me feedback. All board is shipped with the Johnny 5 on the box because all I want is input. Okay, thank you. All right, sounds good. Okay, next up is Foamy Guy. Right, this past week I implemented some save and load indicators on the display for the MIDI sequencer. It's, I've previously implemented the ability to save and load loops onto the disk as long as you have your boot py set to make your drive writable. But it just kind of happened. If you weren't watching the serial output, you would never really know that it was successful or failed or not. So now that actually outputs some information to the screen. In addition to using it for saving and loading indicators, it also has some general labels that can output more information for just all of the different states whenever something goes right or wrong, there's actually a way to tell the user about it now other than serial console. So that's nice. I've been getting back into the swing of things with PR testing and reviews so far. The Sparkline one was the one I jumped into first as well as a couple other typing ones. And then the other major one I've gotten into so far are in the WisNet library. It did take me a bit. I had to actually circle back around to a different PR from a little while ago, which fixed an issue that affected my environment. So I had to spend a bit of time getting back into a working state. And now that we're there though, I think I'm ready to actually dive into the other PRs that are open for Ethernet. So that's probably where I'll continue on. This morning, somebody was mentioning an issue copying code from the NeoPixel examples, specifically from Read the Docs. So I dove into this issue a little bit and it turns out there was a weird behavior with a certain version of the theme. And we might wanna try something to fix it. I got some more notes on that for the weeds it may be a bit deeper. I tested last night, in fact, I just tested a proof of concept for using a time of flight sensor, a distance sensor to be embedded inside a Lego table football game. Specifically it's tucked up in the goal and the hope is that I can use this to detect when the ball goes into the goal, therefore knowing like that a team scored and then if I have one in each goal, we can hopefully know which team scored and ultimately we can use that to make an automatic scoreboard. That's kind of my plan for that project. For this week, my main thing, which I actually mentioned last week in failed to do is to actually write my circuit Python 23 post for real this week and that's what I've got going on, thanks. Okay, thanks very much. Next up is Jeff. Hello again. So over the past week, I fixed a couple of small bugs. The one with the volume ID that we've discussed a little bit before I won't go into. Another where an exception would chain to itself, which was undesirable and different from standard Python. I offered a PR in the hopes that increasing memory allocated to LWIP would solve a weird problem, but it did not. And this morning I opened a PR to 80 fruit requests to improve error recording using exception chaining. It does this thing where it retries several times and in so doing it would lose the original exception with exception chaining we can actually link that original exception and show it when we raise the final, I retried and it didn't work out exception. This is not a circuit Python, but it would be useful with circuit Python. I started working on an RP2040 firmware that would understand the ST7789 style LCD instructions and emulate an LCD. And there are some interesting challenges and Phil B and I are trying to collaborate on this. So maybe something interesting will come out of this, keep your eyes peeled. So this week I need to update the reverse TFT draft PR for the part with PSRAM and set it for ready to review, continue with the ST7789 emulator and I will look into number 7346 and try again to reproduce it. And I may need to read it more carefully because I was looking just before the meeting. My one line summary in my own head was MDNS stops responding on PicoW, although it actually says something about disappears from the list of devices in the circuit Python webpage. And those are two different things. The way things appear is via MDNS, but maybe there's another reason other than MDNS stops responding. So I didn't actually test what the user reported. I tested something else, which was could I do MDNS resolution on my Linux computer? Anyway, next up, I also assigned myself 7427, which is an exception remaining in the title bar after it should be gone. And that's all I know about that so far, but I know that Dan I think added some stuff to try and only rewrite the title bar when it changed. And I'm guessing there's just a little buglet in there. And if I need a break from serious stuff, my next guide on deck is still the next mouse to USB HID guide the code is written, but I just have to write all the text, get the photos, all that fun stuff. And next week I am out all week. I'm not out out, I'll be at home, but a friend is coming to visit and we plan to spend the next week hiking on open source software, not circuit Python, such as Linux CNC. And that's what I've got on my table. All right, thanks Jeff. Okay, next up is Katni. Hello, so I have been out for two and a half, three weeks. I am back. If you reached out about anything in that time, please feel free to ping me again. I tried to skim some stuff on Discord and get to my unreads, but some of them were so many messages ago that they didn't even show up when I scrolled. So I may have missed messages. I still have a bunch of email to go through and I may miss something while I'm doing that as well. So don't hesitate to ping me again if there's something that you needed from me while I was out. This week, getting caught up on email notifications and messages, doing anything related to that, like updating my to-do list with anything I find actionable in all of that. Tomorrow I'm gonna be syncing up with Liz to figure out what guides for new products I need to pick up. Liz was around while I was out and so she was assigned a bunch of the new product stuff and I don't, I don't know which stuff she has and which stuff is still outstanding. So we'll be syncing up to make sure that that list is accurate and then I can get started on new product guides. And that's pretty much it for me because there's obviously a lot of new product stuff that came out in the last couple of weeks that need guides. Not related, but partially related to making things. I have an order out for delivery that is mostly spudgers which I'm inordinately excited about. They're black ones that I used to use like two decades ago when I worked at Apple and I didn't realize I fix it, carried them. So I ordered a bunch and those are gonna be getting here soon. So I will have a bunch of things to spudge with. Anyway, very exciting. That's all I got. Okay, thanks, Caddy. Okay, next up is Melissa. Last three weeks, I was out for about a week during that time for the holidays, just didn't have a meeting with it, think or the couple of weeks ago and I missed it on last week. And so anyway, I worked on the CircuitPython installer wizard that can be used directly on CircuitPython.org website. This week I went and finished up the installer at least to work in the state. And then I also need to write in my CircuitPython 2023 wishes and I think that's it. Okay, all right, thank you. Okay, so and as I mentioned, Scott isn't here so we don't have a report from him. So the final section is In the Weeds, which is an opportunity for more long form discussions that either come out of status updates or people are identified ahead of time. If you think of an In the Weeds topic at it before we get to that section so we don't have to query people for that. So, FOMI Guy has a long thing about read the docs, theme versions or style versions and also I would just note that Jeff wrote some stuff at the end of that. So but if you wanna go ahead, Tim. All right, yep, thank you. So this ties back to something that was mentioned in the Help With channel this morning, is how this was brought to my attention at least but it's, there's a couple links in the docs if folks wanna go to some of these pages that I mentioned but the gist of the issue is here that a certain or certain old versions of Sphinx RTD theme which is the theme that our docs use when they're hosted on Read the Docs. An older version of that theme had a bug where when you copy code from the page the example code specifically, like code that was included as a literal include inside the docs config. When that page gets rendered and then a user goes and opens it in their browser, copies code out of there, the copy includes the line numbers which is no good because then you have to go remove all those line numbers of course to get the code to execute. There already was a PR and a fix inside Sphinx RTD theme. We just need to get the systems to use the newest version and I think this problem will go away. The good news there even is it looks like there's another link in here to Read the Docs documentation for default versions. If I understand their stuff correctly, the default versions on all the libraries that were created after a certain date, I think it's like October 2020 or something like that. I don't remember the exact date but all the ones created after that date actually just use the current version always whereas the ones before that date, the project creation date, if it's before that date then they use that old specific version which doesn't happen to have this fixed. So the consequences for us are all of our libraries that were created before that date, they have this problem where when you copy the example code off the Read the Docs page, it includes those line numbers. In order to fix it, I think if we get it to use the new version, that will just go away. So there's I think a couple of ways to do it and I've got an idea in mind and it looks like Jeff put an idea as well. So essentially what I had, let's see, let me actually catch up with what Jeff mentioned as well just so I don't speak out of turn. Yeah, okay, so that's basically the same. So yeah, if we, inside of Docs requirement text, if we put the Sphinx RTD theme, we don't have it there but it turns out RTD has a default backup for it so it installs it anyway even though we weren't specifying it. If we go ahead and specify it in there though I believe it should take whatever version we specify in which case we can either pin it to whatever version we want or just leave it unpinned and it will always take the new one which is what the more recent repos do anyway. So the two questions that come out of this are do we wanna try to do that? Maybe starting with the NeoPixel library or if there's another one that's older that we know of for sure to check with. We could try it on one if it works then we could apply it to the others. If we do wanna try it and it does work then the next question becomes do we wanna do it on all the libraries the same even though only the older ones need it or do we wanna try to isolate the ones that actually do need it and do it on them and leave the new ones alone since they don't technically need it and they already behave? Okay, so let me answer your second question first. Absolutely every library should be updated. Having different things like different config files and stuff is just bad news for later updating if needed. So that is what I would suggest there. As for the rest of this I think it's just fine too to force the update. I would not start with NeoPixel. I find another one. So it's so highly used. So use Jeff's link there. To grab a one that is definitely before the thing is using the updated thing and try it on one of those slightly less bonkers used libraries. Yep. And then absolutely if that fixes it apply it across the board. Okay. We have, there is a test library, right? I don't know if it's old enough. But there's no actual documentation on it. Oh, okay. We didn't go so far as to add library code. There's like a couple pieces of like hello world stuff in there but there's no docs. But if it's still, if it's older then you could add docs and if it formats with the old stuff then you would know that. So that's another one to check. I guess. I mean, first of all, I feel like that's making more work. Yeah. Okay. Second of all, I worry that because there's because it's not a fully flushed library. There may be other variables. Yeah. That's a good point. So like that's really good for like testing out, you know, other CI type stuff because that's just standard. But like, yeah. I definitely think using the test for this documentation bug is probably not the best way to go. So and I will go ahead. I was just going to say that sounds good. And I was going to also say, you know, you can pick a library, a real library and don't worry about using up version numbers. Okay. Like version numbers are free as Scott says a lot of time. And so if you, if you have to bump something, a few minor version numbers, that's fine. Nobody cares. So. I will find. Don't be parsimonious about it. The older one from the list. Thank you, Jeff, by the way. I don't think I read that one when I was reading out the board. So yeah, Jeff put a script there or the output from a script that gives us them in order. So I'll grab one of the older ones that's not quite as widely used as NeoPixel tried out. And then if that works, I'll mention it in the channel here and I'll get started on a way to move it out to the rest of them. I think that's something Adabot can do. Yep. I believe so. Yeah, with the patches. So you could ask Eva or Tectric, like they do this kind of thing a lot. So. Once I get it, can you confirm that one? If, okay, so once this is all confirmed, it's perfectly fine to not make 300 PRs with this. Right. So there's like four libraries. I think you have to make PRs. NeoPixel is one of them. But for the rest of the libraries, just push it. Don't worry about making every PR. Sounds good. I will look into that. All right, thanks a lot. Okay. So finally, we'll wrap up now. Thanks everybody for participating. I will just note that next week, the meeting will be on Tuesday instead of Monday because Monday is a U.S. holiday. So we'll remind you of that in the usual way through Pings and stuff and the pin message in the Circuit Python Dev channel. But thank you everybody for participating this week. We really appreciate it. All right, anything else? If not, I will stop recording.