 Hello, everyone. This is the Circuit Python Weekly for November 8th, 2021. It's the time of week where we get together to talk about all things Circuit Python. I'm Jeff, and I'm sponsored by Adafruit to work on Circuit Python, which is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join us anytime by going to adafru.it-slash-discord. While this meeting happens once a week in the Circuit Python Dev Text Channel and Circuit Python Voice Channel, there are a large number of channels that you can visit with people chatting at all times of day from all parts of the world. This meeting typically happens on Mondays at 2 p.m. Eastern Time, 11 a.m. Pacific Time, except when it coincides with a U.S. holiday. If the meeting time has changed, we'll notify you on Discord. There is also a calendar available on GitHub that we keep updated so you can subscribe to that and get it conveniently in your own calendar application. This meeting is recorded. We record the video from the text channel and the audio from the voice channel. If for any reason you don't like to have your voice recorded, you're still welcome to participate by leaving us notes. We post the video and audio of the meeting to YouTube and then from there release the audio as a podcast. If you find that we're not available on your favorite podcast service, please let us know. There is a notes document to accompany this meeting and the recording. If you want to participate but can't make it, that's where you can leave your hub reports and status updates for us to read off during the meeting. As we go through the meeting, I'll add timestamps so that after the fact, you can use it to skip to view the parts that only interest you the most. The meeting tends to run 60 to 90 minutes so we think that that is a pretty handy option to have. A link to the notes document is posted to the CircuitPython.dev channel on the A4 Discord every week in advance of the meeting and if you are watching or listening to us, look in the show notes to find the text of the notes document. This meeting is held in five parts. Next up is community news. A look at all things CircuitPython and Python on hardware in the community. A look at the overview of the community run, Python on microcontrollers newsletter. Second is the state of the CircuitPython libraries and Blanket where I am in big trouble because I didn't copy that into the document to read off. Katnie, can you save my bacon? Anyway, that will be a statistical overview of the entire project and a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports while Katnie, an extra hug for copying that data into the notes document. As a perfect example of highlighting the good things folks are doing and taking the time to recognize the awesome folks around us in the community on Discord, GitHub and beyond. The fourth part is status updates. Status updates is our opportunity to sync up on what you've been up to. We invite everyone to take a couple of minutes and talk about what they've been doing for the last meeting and what they'll be up to until the next meeting. And then the final part, if needed, is called in the weeds. It's our opportunity for long form discussions. They can either come out of status updates or be something that you've identified ahead of time as just being too long to fit within that format. It can grow out of a CircuitPython issue or bug report or pull request on GitHub and so forth. Anyway, that covers the main parts of the meeting and with that, I will skip back to the notes document and head to community news. These are just a few excerpts from the great newsletter that Ann kind of spearheads but takes contributions from the whole community and so I'll just kind of read them off to you. I skipped a couple of the top headlines and I'm going to start with CircuitPython course connecting a robot cat to the internet. In a new LinkedIn learning course, Sherlyn Gonda shows you how to use CircuitPython to program a robot cat that reacts to events while connected to the internet. Sherlyn shows how to code for common hardware devices like LEDs and servos and explains a common messaging protocol for IoT projects called MessageQ Telemetry Transport or MQTT. If you're looking for an internet cat video that actually teaches you something useful, join Sherlyn as she shows how to program this robot cat. There is a link to LinkedIn and the course is $35 after the introductory chapters. Yeah. So next up, Meet the Maker covers Liz Clark from BlitzCityDIY who you may know from her appearances on show and tell now and again. So yeah, the YouTube channel is apparently called Meet the Maker and I'm not familiar with it. I will check it out soon after the meeting. Next up, ZDNet has a list of top programming languages and while they list JavaScript as top at $16.4 million, Python is number two at $11.3 million. They say that it is most popular in DS slash ML and IoT apps so they don't even know about the Python on the hardware world. We'll have to rock it up that list someday in the future. So heading down to some projects, the bare metal circuit Python is running on a Raspberry Pi with HDMI and an e-ink display. Scott is working on a port of circuit Python that runs on bare metal on the Raspberry Pi that is without the Linux operating system. So of course Lady Aida wanted to see what works with HDMI since the REPL is available and she happens to have an e-ink HDMI display. It is awesome. One of the plans is to make a little computer with a keyboard that is just circuit Python. Write code, make art. With HDMI, have the output go to a little portable projector. Kids can make cool kaleidoscopes or make a haku computer that shows the last one made when the power is off since this is e-ink and there is a link to the Adafruit blog. And then next up, there were a couple of cool looking stories from circuit Python school. This one was called, There's a Jedi in my microcontroller sensing gestures with an Adafruit APDS9960 and we've got links to YouTube and that comes via Twitter. So, long story short, there is a lot more in the newsletter so if you just head over to subscribe to it at adafruitdaily.com you will get a lot more in your mailbox tomorrow morning. The newsletter highlights the latest Python on hardware related news from around the web including circuit Python, that's us, Python and MicroPython developments. And we really want to hear from you if you can contribute your own news or project you can hit it next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with circuitpython on Twitter or email cpnews at adafruit.com Send us your project, your friends project, your cats project, just whatever we want to hear about it and we want to spotlight you and get you exposure for the cool stuff. It can be really simple, it can be really complex because we also value the contributions of people kind of at all stages of their journey through circuit Python and computers. So that is all I'm going to tell you about the newsletter. Next up is the state of circuit Python, the libraries and Blinka. This is looking at the statistics from some scripts that we run on a daily basis and that report over the last seven days of activity give or take. So overall across everything on adafruit that is circuit Python related we had 81 pull requests merged which is a pretty big number and Katani will tell us more about why that is a little later. Those came from 16 different authors and less frequent contributors are Tectric and Wei Wang 83. I think 560 has contributed before but thank you and also it was nice to talk to you earlier this morning and then BL3 is a name I also don't recognize. So thanks to everybody especially if you are a new or newer contributor. And then also thank you to our 11 reviewers. Reviewers look over pull requests and offer feedback. They test the pull requests and just help us ensure that the changes that we make are the highest quality. So thanks to those 11 people who help us maintain the quality of circuit Python and the libraries in Blinka as well as those who aren't specifically credited as reviewers but when you comment on pull requests and on issues you are all helping us ultimately create a better program. Anyway issues-wise we had 24 closed issues by 11 people while 14 people opened a total of 15 issues so that's a nice decrease in issues week on week. And I'm not sure whether this is accurate or not but we think we may have removed the Hacktoberfest label from 22 issues. Those are labels left over from the Hacktoberfest contest last month and we're kind of a signal as to PRs that we hoped newcomers could resolve. Moving on I will hand the talking stick to Scott to tell us about what's going on in the core. Awesome thank you Jeff. Okay so for the core the repo github.com slash Adafruit slash circuit Python. In that repo we had 12 pull requests merged from 9 different authors so thank you to all of our authors. We have 4 reviewers who helped support those authors so thank you to those folks. We have 10 open pull requests which is not too bad the oldest is 65 days old and it's kind of an even gradient from there on so we are keeping up generally with things. Issues-wise we had 5 closed issues by 3 people 4 opened by 4 people so we're net down 1 which is great for a total of 447 open issues which you can find on the github repo. We keep track of kind of how we are managing incoming issues through milestones. Generally we prioritize what issues we want to work on based on the milestone and the milestone characterizes usually the release that we're targeting or we want to make sure and fix something for. So we have 0 open issues for the 7.1 milestone we have 21 open issues for the 7.xx which is like anything but before 8 and then we have 7 open issues for 8. We also these milestones also help us track the things that we've just not looked at and we have one issue not assigned to a milestone that we'll have to take a look at although I have done some this morning. Anyway we're continuing to work we should do a 7-1 like I've been saying in the last few weeks but all of us are kind of involved in stuff right now so I think once we wrap up the work that Dan, Jeff or I are working on we'll take a crack at 7.1. If anybody is interested in helping with releases or core stuff let me know. Releases do take some privileges and accesses to things for like blog posts and things but there's no reason that we couldn't have more work done by some core contributors outside of Adafruit. So if you want to get more involved in the core please always just reach out to us we'd be happy to help you level up and get more people working in the core. So that's it. Alright, thanks Scott. Next up is the libraries and that is traditionally a section that is done by Katniss. So step on up. Thanks Jeff. So this section applies to all of the Adafruit Circuit Python libraries which is everything that begins with Adafruit underscore circuit python underscore as well as a few other things such as the community bundle and our cookie cutter. So we had 68 pull requests merged by seven different authors including a couple of the new folks that Jeff highlighted earlier which is great and seven reviewers including our newest reviewer which is also excellent. The list of merge pull requests are all very recent ones which makes sense for reasons that I will discuss later and it leaves us with 58 open pull requests which has increased significantly since that number but will also have decreased significantly the next time the report is generated so that number will probably stay the same. We had 14 closed issues by eight people and nine opened by eight people leaving us with 627 open issues. 260 of those are labeled good first issue. If you're interested in contributing to CircuitPython on the Python side of things check out circuitpython.org slash contributing. You'll find all of this information and more including open pull requests, open issues and library infrastructure issues. These are all things where there is an opportunity to contribute. If you want to get into reviewing you can check out the open PRs. If you have the hardware test it, if you don't feel free to check out the code for syntax or spelling or that sort of thing and let us know that you did that, that's always helpful. As you get more comfortable with leaving comments for review purposes we can eventually level you up to joining the review team. If you are interested in contributing code you can check out the issues. If you're new to everything, good first issue is a great way to start. If you're looking for something a little more complicated bug or enhancement is a great thing to search for. Pick something that interests you and give it a try. If you have a comment let us know you're working on it. If you need assistance we are always available both on GitHub and Discord. The list of updated libraries this week I will not read off but there's a number of them which will probably be longer over the course of the next couple weeks. Overall, I decided to update Pylint. So that's why there's so many PRs. It wasn't terrible. The last time we updated Pylint was far worse and waited a very long time to do it. So when I ran it and it wasn't terrible I figured now was a good time to do it. All those PRs are in. They're not all merged yet but they are completed. So we're in a really good place with that. I updated our pre-commit config file. It was doing wonky stuff with the example code to avoid the duplicate code check and Pylint finally implemented the ability to just disable the duplicate code check very easily. So that's what we're doing instead of doing the weird stuff with the example code because apparently it was running it on each example more than once. It was very slow and it's significantly faster now and only running one time on each file. So that's actually part of what sparked all of this and I'll explain all that later. But overall we are in a good place and I'm really excited to still see a number of the good first issues being picked up by folks. And it's always a great way to get started with this is our good first issues. So thanks. Thank you, Katny. And then to round out this section on the state of CircuitPython, the libraries and Blinka you might cast that next up is Blinka. And Melissa will tell us what is going on in that end of the world. Hello. So Blinka is our CircuitPython compatibility layer for MicroPython, Raspberry Pi and other single board computers. And this week we had one pull request merged by one author and two reviewers. There are four open pull requests still and there have been five closed issues by two people and two open by two people leaving a net of 64 open issues. There was one issue removed. Never mind. Had the Hacktoberfest label but got removed. Let's see. There were 13,232 PiWheels downloads in last month and we are currently up to 77 boards with the addition of the new Raspberry Pi Zero 2W. And that's it. Thank you, Melissa. Next we will move on to Hug Reports. Hug Reports are our antidote to negativity and the opposite of a bug report. If there's somebody in the community who has been up to good stuff, please call them out in a good way and let us know. So I will kick it off and then we will continue alphabetically and then head back to the top of the alphabet to get the people who are before the letter J. So first of all, I have a hug report from Ketney for coming to me about the pre-commit stuff that she will be talking about later. I had some opinions and she gave me a very good hearing and I think we came to a good solution. Thanks to Dylan. Thanks to Keith the EE and thanks to Mark among others for work on all the Pilant PRs that were one result of this. And thank you to Scott for swapping meetings with me while I will be unavailable coming up. And next, let's hear from Ketney. I'm so used to there being more people before me. Not today. Alright, I know. So first up, a hug report to Dan and Rose for a lovely chat about the LED animation library. It was fun to watch them bouncing different ideas off each other and everybody really enjoyed it so that was nice. To Foamy Guy for cleaning up after Hacktoberfest when Adabot failed to do so. The libraries, the issues, labels, that's what I'm looking for. I got there. The issue labels were not removed by Adabot so we did it manually basically and I appreciate that. Another one to Foamy Guy for updating the pie charm page and the welcome to circuit Python guide to actually be useful again. To Jeff for going over the pre-commit config VML update with me. To Dylan for working through the Pilant update. To Keith the EE and Mark Gambler for picking up a lot of the Pilant PRs. And to Keith the EE for looking into an import style difference and reporting back that they were the same thing and making suggestions as to which one to go with. Because that was greatly appreciated as well. I did it a way that I thought was appropriate which was different than the way Dylan had done it on every other PR that she had done and it turns out they're identical but we needed to pick one for style that had been used in a majority of the libraries versus the one that I had done once. So that's been fixed and everything is now the same. That's what I've got. Alright, I will read notes from Keith the EE and then we'll move down to Makra Melissa. So Keith says hugs to Dylan for getting the circuit Python libraries working with the Pilant update. To Ketney for getting Pilant working and helping review the pull requests and everyone for continuing to be awesome. Next we'll go to Makra Melissa and then to Scott. Hello, I wanted to give a hug report to Carter for testing out the Pi Zero 2W and also testing it out with the new release of the Raspberry Pi OS. I wanted to give a hug to Ketney for having a nice chat with me. Everyone who wished me well was out and a group hugged everyone else. Thank you, Melissa. Next up is Scott and then we'll head to the top of the alphabet with Carter who I guess I'll be reading the notes of. Hello, for me, hug report to Ivan, IDRR from Espresso for writing a nice SD library and being open to collaboration. So I'm starting with the SD stuff from the ASP IDF so thanks to Ivan for reaching out to me on that. Thank you to Keith the EE, Ketney, and Dylan for dealing with the Pilant upgrade. I think I missed Mark on there too. Thank you other folks for covering that. Thanks to Gambler for the display IO on LED glasses. I think that's really neat and I hope to highlight it. Hug reports, anecdata, and microdive for the Wi-Fi monitor code. Being able to debug Wi-Fi through an ESP would be really neat. And then lastly, hug report to Tectric and 560 for continuing to work on adding type information into the libraries. That's it for me. Yeah, I need to check out Mark's work on the LED glasses as well because, well, I still don't have a set of glasses so I didn't do it yet, but yeah, that's cool stuff and they definitely deserve a hug for that. Anyway, I have a note from Carter who has a hug for FOMI guy for taking a look at updating text label guide to cover a common mistake. Next, I'll read some notes from Seagrover and then hand it to Dan. Seagrover also has a hug for FOMI guy for the detailed descriptions of the phenomenal concepts and design of display IO layouts and widgets. Next is Dan, then I'll read notes from David. Okay, thank you. Jeff, thank you for improving the bootout.txt updating which got broken at one point and I had submitted a PR which just barely fixed it and you did a more thorough job and I understand you're fixing one aspect of that now and thanks also to Dave Putz again for looking at very hard to fix things that have to do with PWMIO and other pulse things that take a lot of work to understand the low level details of. We really appreciate that. Okay. Alright, thanks, Dan. Alright, notes from David Glaude who I think is listening in. Hi, David. A hug for Scott for continuous effort to make the PySingleBoard computer work with CircuitPython. One for Dan for the custom HID devices learn guide. One for me for the BLE cat thermal printer learn guide and one to Katni for the ATtiny817C saw learn guide. And now I will let FOMI guy round out the section of hug reports. Alright, thanks, Jeff. This week hug reports for GitHub user, I think it's Clarkdotesh but the person behind the KMK firmware so I had a chance to play with that this week and it was really interesting so I definitely appreciate all the work that they did for it. To Carter for discussing some ways to improve the display text guide in the learn system and to Tektrick who has added lots of type info and done several other PRs recently I've seen so definitely thanks to that user. And that's all for me, thanks. Thank you and thanks everybody. The next section is status updates similar to hug reports we will go in a round robin fashion and we want to hear what you've been up to since the last time we had a chance to chat and what you hope to accomplish in the next week or until you're able to join us again. And if there's any place you're stuck and throw out a question and maybe people will answer you in the text chat but if it's a longer discussion or needs to be verbal please put a topic in the weeds and we will talk about whatever is on your mind that's related to circuit python and of course we also invite you to talk about things that are outside of circuit python but that you want to share with us because a lot of us are also friends and pals and it's a community so anyway let us know, tell us how your progress goes laying in vegetables in canned or pickled form for the winter for instance that's not what I'm going to tell you about anyway so last week I had amassed just a bunch of work in branches that were in progress and so I got as many of them turned into pull requests as possible last week and that makes my list look a little bit long anyway, as Dan mentioned I improved bootout.txt writing but unfortunately I broke safe mode there's a second pull request out that will fix safe mode so it's a little improvement where in addition to writing the information that it always wrote it is now going to also write the actual output from boot.py up to 500 bytes or so of it and only rewrite it when it actually changes so it was a little tricky to do but it's a lot better because you can like print I installed my USB descriptor and then you can look in bootout.txt and see that that happened and I think but did not verify that an exception would also appear there I will check on that after this meeting so put that on my to-do list anyway, another PR that I wrote that needs to be tested is to allow mp3d coder to accept file names in addition to an opened file and this is reacting to pilot liking to suggest that when you use open you use it with a with statement and if you are actually doing that with an mp3 file it might or might not be right depending on your goals but if you can just tell mp3d coder the name of the file then pilot isn't going to notice or isn't going to to give you this possibly incorrect advice using a with statement next up on the samd microcontrollers I fixed an arithmetic error calculating the watchdog timeout on the expressive microcontroller parallel image capture now supports what is called continuous capture so your python code can be running on the previous frame while the camera is sending the next frame to the microcontroller and that can like speed the responsiveness of your camera based application port request that was just merged to add an alpha blending routine to bitmap tools so you can say I want a new bitmap or I want to put in my output bitmap one that is a blend of 30% image A and 70% image B and we think we have some camera related uses for this but also I think it's just generally useful because now you could maybe actually blend text on top of a bitmap and this is really only going to work well on the microcontrollers with a lot of memory which is the ESP32S2 with PS RAM right now because of course you need to have your source bitmap A, your source bitmap B and your destination bitmap so already you're using up a ton of memory anyway next one up that is still in progress is dither so you can take a 16 an 8 or 16 bit bitmap and turn it into just a black and white bitmap and we think there will be uses for this again there's kind of a camera project in mind for it but also some other stuff the rainbow IO module there are approximately three boards where we had to disable it because it didn't fit but our goal is to have it enabled on every board that really has the possibility of having color neopixel or other LED on it and I was able to find room on one of those boards and re-enable it we've still got a couple more to go on Sunday I looked around and found some other places that we can save for more size but I haven't turned any of them into pull requests yet there's one that is really not a trade-off at all it's disabling some functionality we don't use there are two more that are kind of slight degradation in functionality but that I don't think anybody is actually using so those will become pull requests someday when we could use a couple hundred bytes in order to fit something like rainbow IO on of our microcontrollers and then the last one up that made my list is I helped with a problem in nvm.toml which is a GitHub repository that includes information about flash chips and reported a bug in Cascade Toml which Scott was kind enough to confirm it was a bug and that bug led to the first problem not being detected right away I guess is the story so anyway this week with dither working I can work on completing the camera to thermal printer project idea so hopefully that will soon become a guide on the learning system using the ESP32S2 with the UART thermal camera UART thermal printer excuse me and then the OV 7670 or other camera so you'll be able to hit the shutter button and have your photo come out it'll be lo-fi similar to Game Boy Camera I guess I never owned one and several of the above PRs that I mentioned will probably need revision before they can be merged and the dither is definitely one of those so coming up after that I will be missing the meetings on November 15th and 22nd and I will be back yeah basically at the end of November my discord activity will probably also be reduced that's what's up with me and that wasn't long enough I have already looked ahead at what Katniss is going to tell us about so take it away and then after you we will head to Melissa all right so I've been talking for several weeks about the welcome to circuit python guide update that is now in moderation but the guide is mostly live so you can check it out now the new pages include the circuit python documentation page which is live and the how do I learn python page which is not yet live also updated the welcome to the community guide to include circuitpython.org and reference the libraries more and link to the new circuitpython documentation page within the welcome to circuitpython guide our new products and photo team is working on new sets of circuitpython compatible board images based on mine and Dan's suggestions two sets of them are done and they look amazing I'm really excited about this last week ended up down when you give a mouse a cookie hole with a documentation build failure on the LED animation library we created to read the docs using an ancient version of Sphinx remotely versus the latest version we were running locally all newly created projects use the latest on read the docs so we do not need to be concerned about this issue on anything created after the 20th of October in 2020 I think that data is right but it doesn't matter we're beyond it so I spent a couple of hours looking into forcing read the docs to use the latest Sphinx which involved adding a new file and changing the existing one then I remembered that the way we were running pyloned on the example code was for some which like I said earlier was doing more work than necessary but also making it slow which is what I was running into trying to fix the read the docs issue so I figured since I was already going to need an adabot patch I should fix that issue as well and then remembered a user running into a pylon locally being different version than the pre-commit issue and figured if we were going to update the pre-commit config file anyway I might as well update pyloned so I ran pylon across the bundle in a crude way and it didn't come back super terrible so I figured it was a good place to do it and went ahead with it so to make a very short story very long winded we're upgrading pyloned on the libraries to 2.11.1 so make sure you've pulled the latest code before working on a library and also have updated your pyloned if you are running it separately to that end I've been merging PRs and I did a few myself as well this week I will be merging any PRs that are left for me thank you so much to folks who have been picking those up and turns out I broke the docs with my fix but I know why so we have a fix which I'm going to bring up in the weeds because it's two options and we pick one of the two I started the guide for the Adafruit monochrome 1.12 inch 128 by 128 OLED graphic display it's in the shop but not available yet so that guide will be it depends on because I won't have the hardware to finish the code parts but the core of the guide will be done this week I'm going to go through existing pretty pins files starting with RP2040 and make sure they're uploaded to the guides and PCB Rebos where they need to be Phil B made a bunch of them that never ended up in their homes continue working on adding a page to the LED animation library guide about loading part of a library this came out of a lot of people wanting to use LED animations on M0 boards that are not express and even M0 boards that are express can't run all the animations so we thought about putting this in the Welcome to Circuit Python guide but it really didn't make sense because it's frankly the LED animation library is really the main thing that people want to do this with however it's pseudo on hold because there's a very basic feature animation sequence that no longer works on M0 I found this while testing it to make sure that the animations that I listed off were still the same that we couldn't run were still viable and I'm not sure I want to write this page with a caveat the sequence doesn't even work it needs to be refactored to work again on M0 but I still want the page regardless because I think it'll be super helpful to folks and I have started it but testing made me pause and I have various miscellaneous things to do and then more pretty pins diagrams and that's what I have going on alright and despite me giving you a hard time your update lasted less long than mine did so just being mean to you I guess anyway next up is maker Melissa and then Scott go ahead Melissa okay hello last week I was out a few days due to an adverse reaction to the booster shot but I'm feeling better now I tested out the Circuit Python SSD 1681 e-ink driver I fixed read the docs from failing on platform detect and I added pen alarm and touch alarm support to portal base and this week I'm going to work on testing out Raspberry Pi with the new OS that just got released today I'm going to fix the issues I came across and then after that I'll possibly start on learning guide for the Circuit Python code editor alright thank you and you said that Carter did already give it a quick test was that test looking good yeah it seemed good I wanted to test it on the Python along with a couple other issues people were reporting recently and so I just figure I do it all at the same time great thank you next up is Scott hello I was struggling a little bit last week with USB troubles I so didn't quite make the progress that I wanted to I spent a lot of get frustrated capital on getting frustrated with non Circuit Python stuff but yesterday I put in a new mother board in my computer so hopefully I won't have to deal with that this week just got to send off my other one to get fixed I got Circuit Python for the 0 to W and the UR output is working however input is not because it depends on the interrupts which I had forgotten and then immediately found that yeah I actually do need interrupts working so I'm working on that it's got a different interrupt controller from the Pi 4 so it's good work to do because it applies to basically all of the other pies so just going to keep finishing that up and then I also put out a call for like a tiny USB like library for the SD MMC cards it turns out Ivan IGRR front wrote the IDF version based on the open BSD code and is open to actually splitting it out of the IDF into a separate library so I started tweaking it for Circuit Python and plan on collaborating with the USB expressive folks so that we can actually have a library very similar to tiny USB I think that they can use in the IDF and we can use in Circuit Python and it will manage kind of all of the standard SD card stuff for us so this week I'm going to try to get everything going on the 0 to W basically to the point that the Pi 4 is at tomorrow I'll be on the Tom's Hardware Pi Cast which I'm looking forward to talk about all of this Circuit Python Raspberry Pi stuff that's at 1030 Pacific so if you want to watch it I think you can find it on YouTube once I do the UART stuff I want to get the SD card reading and writing working from Circuit Python's C code so that's just like getting it working there and then the next step is to connect it up to Circuit Python as a file system and once it's working as a file system then figuring out how to expose the SD card over USB I might just treat it like internal flash at the start but in the longer term I think it would be cool to actually like have SD cards supported kind of more properly because SD cards have the challenge that they can be ejected so that's a that's a new one for us to handle on the internal so Circuit Python is what happens what happens when our file system disappears oh and then the other thing that I'm going to try to do is on my stream this week I want to highlight all of the editors that we've got going so the work that Melissa did is really far along and looks really good so I want to start encouraging folks to try that out on the iOS app side we have PyLeap and FileGlider and I think they're both currently set up so we could actually give out beta access to those apps as well they're doing pretty good so I want to test those this week find any issues and try to start getting particularly this group of folks testing it out and seeing what you find and start trying to start the iteration loop between people trying it and the folks working on it fixing things so check a look keep an eye out for that it should be really really neat and that's just the beginning of all the BLE workflow stuff so it's going to be cool Thanks Scott back up at the top of the alphabet I've got notes from Seagrover and then we will hear from Charles Burniford alright so Seagrover writes working feverishly on a set of retro graphic widgets for display IO the project is heavily inspired by the work of Fumiguy but he uses or but Seagrover's version uses a normalized screen addressing scheme rather than pixel counting in the hopes of achieving personalized independence they've completed two widgets a magic eye tuning indicator and an animated kitchen scale like object had some fun with ployed rectangular conversions in the process and then starting to examine how to create some new display IO graphics primitives to help with arcs and donut circles also looking at issues with accuracy of polygon shapes when compared to rect I'm expecting that it will be an intense and useful opportunity next up is Charles and then after that we will go to Dan sorry I took a little while to get back to the my discord alright we're ready for you can you hear me yes okay I'm looking forward to the I'm really looking forward to bus IO and and HID MIDI because I really want to build a I'm dying to build a bare metal circuit python MIDI sequencer because I've got I've got the basic code of a version I wrote for Blinka and I want to see if I can convert it to bare metal see what happens with that and some of the controls are on I2C so I sort of need bus IO I2C so I hope that happens real soon soon Scott alright we'll keep us posted on your progress with that as it goes Charles I certainly will, thank you alright next up is Dan and then I'll have notes from David okay thanks so I'm continuing to work on the Async IO library in circuit python and last week I had done a demo where you could blink two LEDs independently of each other they kept their own rates this time I made a small demo of making two servos run in synchrony but without knowing about each other so they're stepping through a range of motion over a period of time stopping to wait for a delay every little bit and when one stops the other one runs and then they take turns so this is good for for instance the learn guide that has fairy wings that you wear on your back so the wings would work in synchrony and not bump into each other so the result of all this is that currently what we have does work what I've worked on so far there are a small number of changes to circuit python and a small number of changes to the Async IO python code for micro python and what I think what I'll do is release this for other people to try I'll make a PR that has the necessary circuit python changes which are not incompatible with what's happening already and I already have a repo of the Async IO library and I'll publish that and put it in the bundle and I'll write up a guide with some examples and say that it's experimental and have people try things so that we had talked about making circuit python 8 focus on Async and cooperative multitasking but you might get there sooner than that and the other thing things that we then need to do are come up with ways of say monitoring pins for transitions that are compatible with using them in Async Count IO already does the interrupt stuff that we do but it doesn't have an Async API so we might add an Async API to Count IO or add something to Digital IO that has an Async API or have some kind of wrapper it's not really clear yet and I still also want to make it's really easy to make mistakes when you write these Async IO programs and I want to maybe come up with some more helper functions some class maybe in Async IO that would make it less likely for you to make mistakes okay that's it Thanks Dan next I will read notes from David and we will end the section with foamy guy so David writes in the past printed my covid pass qr code with a clue on the ble cat thermal printer and it worked flawlessly with the security guard and his scanner there is a link to twitter in the notes works in progress adapt cpi basic that was made for the titano to work on the normal size pi portal there's a link to get hub again in the note stock trying to adapt the radio controller to build a joystick USB another get hub link in the note stock the goal is to use a cutie pi to transform a wee super nintendo SNES classic mini controller clv202 into a usb controller and then as for the future I have a pi 0 2 w waiting to be used with circuit python and I have the new at tiny 817 seesaw never did anything with the old seesaw but the new one has a great guide and stem connector and I have great hope to use it alright and foamy guy once again you get to play us out and thanks for getting those links alright thanks Jeff last week I we're looked into mvm a little bit and wanted to try to make it a little bit easier so I ended up making and releasing a library in the community bundle that uses message pack which was added a few months back to the core and it gives you a simple api to store and retrieve arbitrary objects in the nvm without worrying about the details because the normal api built in is a little bit low level you have to kind of pack everything into bytes and worry about how many there are and that sort of stuff so now we have some nice easy functions inside of a helper library I also worked on a list select widget that will draw a list of strings and let you move up and down a little selector carrot and then you can check which one is currently selected which should be pretty helpful for making menus and things like that in display I.O. application so I hope to get that published up this week and then last week I also had an interesting first experience the first time I ever messed with kmk so I built up a little very small proof of concept with just two keys on a breadboard the little neo key breakouts were super helpful for that and I learned how to get that running, configure the pins and the keys and the layers and how to make macros for it and that sort of stuff so it was a real fun first time dive into that project for me this week I am going to work on a new page in the display text guide this will show how to properly update a label over time we see a lot of times folks will come to the help with room or the forms and they'll post their project asking for help and they have a fair number of them have the same issue which is that they end up trying to make a new label each time through the main loop instead of updating the existing one and eventually, well actually pretty quickly they run out of memory so that's not what we want so we'll make a page that shows how to do that and explain the most common problem that you might see if you do it the wrong way and how to correct it and then I still intend to look into the stubs and generator and that's the best way to package like PYI files with libraries that aren't currently on pipi so that's what I got going thanks alright, thank you and now we will head down to In The Weeds and I will let Ketney introduce her first topic think, okay scrolling alright, so the first topic should be quick Hacktoberfest is still on 22 issues primarily the circuit python core I just wanted to know from Scott and Dan, Weather and Jeff, whether you guys want those left alone or do you want them removed? I just removed them okay, I just wanted to make sure you didn't have you know, I don't know, an attachment to them or something no I think, like they moved away from that model anyway so like because it's done at the repo level now so I I don't think they're useful anymore okay, sounds good we'll get that taken care of second topic I broke the docs with my update and my question is do we care about adding Sphinx to the the the actual requirements.txt file for the libraries it means it will install on the computers of everyone using Blinka and it's not needed but for reasons that I can't explain it would make things a lot easier for me and it would avoid duplicating requirements.txt and every existing library repo it's not needed on new libraries so cookie cutter doesn't require an update does anybody care can you tell me real quick why it's not required on new libraries but would be needed on the old ones it's not required on new libraries because read the docs does not need to be told to use the latest version of Sphinx on any of the new libraries because it automatically the latest version of last October is using the latest Sphinx by default so only libraries that were created before that time need to have Sphinx in requirements.txt to be running anything newer than 1.8.5 and they're up to 4.2 well what I did when I was fixing the platform is I actually had a separate requirements.txt under docs and then I just pointed that in the the docs config file yes so that works however it breaks the documentation when there are requirements such as Blinka or NeoPixel or any other libraries because we don't automock anymore because of the fact that Sphinx can actually find the libraries if they install them from requirements.txt and so what's happening is that documentation that has any major requirements for example library it passes locally because both requirements.txt are used locally and then when it tries to build remotely it can't find the libraries because they're not either automocked or installed from requirements.txt so the solution is one of two things either I need to revert the docs folder plus Sphinx which means we have to update two requirements.txt files every time we update any libraries to have any other requirements or two we add Sphinx to the current requirements.txt revert the docs file to be using the one that's in the root directory and everything will work that's another option you can actually just have it with the Sphinx inside the docs and the script that goes and runs when you go and have actions is done you can have it just run both of the requirements oh you can add multiple so to the readthedocs.yaml file you mean well you could put that in hold on let me look up what the name of the script is the issue is readthedocs readthedocs doesn't use github actions okay hold on just a second it seems weird to me that you would have different behavior based on when you created the library that's just what they do it that much is true it's just a fact that's not anything to do with us that's how readthedocs decided to do it they just decided as of a particular time they would run a new version and everything created before that continues to run the old version unless you tell it otherwise well how do we tell it otherwise okay here I just posted a link in here that goes to the line that uses that requirements if you have the pip install and point it to the docs requirements as well or you can even like look at that it exists first then you can have it install the requirements inside there and then it does have to install in everyone else's computer okay that's not for readthedocs right this is not run for readthedocs this is for actions that's what I'm saying but doesn't readthedocs happen oh you're saying I got you now I'm talking remotely in the readthedocs config file you can actually tell it the requirements in there as well that's what I did with it but can you do two requirements files yep yes you have to include all the files in both of them and then Sphinx in the one that's in the docs folder which means there's two files you have to update if you update any of the requirements for that library wait why why do you need the library's dependencies in both the requirements files because readthedocs well because readthedocs only looks at one I just posted like when I edited the readthedocs and platform detect okay I didn't know you could do two yeah this is the fix okay so you still need two but only one of them the one that's in docs just has Sphinx in it and the other one has all the things the reason you need both is because remember we used to auto mock, auto doc, mock import everything yep we don't I'm telling Scott we don't do that anymore because it always created weird problems because it installs the libraries from requirements.txt and then actually finds them legitimately yeah I know so if we switch readthedocs.yaml to only use the docs one which doesn't include all the libraries it fails remotely okay then I guess I don't understand your question well I don't know the background of what readthedocs has changed but if there is this hard cutoff between like the new way and the old way like you mentioned that we can opt the old libraries into the new way like the thing you can opt is still not quite what you get there's no way for you to opt the old ones to act like the new ones without the readthedocs.yaml file that is not without deleting and recreating your project which is yeah we would have to delete like 280 readthedocs projects and recreate them all on the readthedocs on the readthedocs website yeah so like doing this to the existing libraries is the fix wait wait because I actually we could talk to the readthedocs folks and be like hey can you just upgrade all of our stuff potentially because like what I'm trying to avoid is like having this gulf of these ones work one way and these ones work another way forever right like ideally they should work all the same I think that if we put the config.yaml file in they will all work the same I don't follow if we put the readthedocs.yaml file in all of their repositories they would all behave the same but I think I've just been putting the file in the old ones to get similar to the current behavior but it's still not quite the same it's in the existing libraries I didn't update pucky cutter because new libraries are already running the latest and they don't need it I mean here's the deal right there are broken documentation situations right now and this is a quick fix to deal with that if we want to talk to readthedocs and have them update things that's great I don't see that happening overnight and I do see us needing documentation that works no I mean I get that I want to make sure that the work that you're doing especially if it's involving a lot of libraries is the right direction right like like Jeff's point is like well for all of our libraries we need to have this readthedocs.yaml file and therefore they'll work all the same that's good and it worries me a little bit like I don't have the I haven't seen the context for the change that readthedocs did but we probably don't want to be in a world where there's no update Sphinx it's probably and we pin Sphinx in that docs slash requirements.txt file but I also hate pinning things because it means we forget to do anything with them until it's like six versions later and then all of our docs are failing and we wonder why yep yeah I mean it's a matter it's a we haven't locally pinned Sphinx for a long time like we've been dealing with Sphinx updates for I'm not sure how long I could go back and find the PR when we changed it but we've been running latest locally for like a while we were not running latest remotely on previously existing libraries okay so I don't know it's just how I didn't know that Sphinx made readthedocs made this change until I stumbled on the fact that there was documentation that was passing locally and that was why yeah it's documented somewhere very deep in the documentation of readthedocs that if you're a repo no, if your readthedocs project was created before it cut off date it always uses a 1.8.x readthedocs and after that it's using the latest readthedocs but both of those are overridden by having the readthedocs.yml file to configure exactly what you want so that's ultimately the way to get what we want including whether we want a particular pinned version or whether we want the newest we can get either of those where we just have to put the file everywhere but what Katny is doing is like she says tackling the more immediate problem of there are these repos where the docs aren't updating because the build always fails and that's the short term goal to fix and I think that this trick from Melissa is going to be the shortest path to that and without repeating these requirements so just can you please link that thing that you're referring to like this buried doc thing about behavior? I'll find it if Katny doesn't want to we had it in a private chat but I do have the link somewhere I just don't want to click over there right now while we're while I'm screen recording I'm not sure what the link was so I'll let Jeff find it I'll add that on discord after the meeting in the text channel it sounds to me that the approach Katny is suggesting is the right way so for the old libraries that are not working right now we'll add a readthedocs.yaml that has a list of two requirements on it the docwork requirements will have the Sphinx version that we want which will not be pinned so it will just say Sphinx and then I think what we should plan on doing is that going forward so adding the cookie cutter and all of the other libraries we should probably just have that same setup so add the requirements with Sphinx in it for all of the new libraries as well and add the yaml too yaml already exists the file has existed this whole time it's just been updated okay so so that'll be less churn which is nice yeah it's just adding to an existing file so that'll get us to the point where all of our libraries behave the same way when it comes to readthedocs thank you for doing that work yep which one of you is going to file that issue I'll just do it I'm not going to file the issue I'll just straight up update it okay thanks Katny, thanks Scott it's easier to update it to give some place to base the adabot patch off of anyway so I'll update it in cookie cutter and thanks Melissa for already knowing the secret solution no problem I was researching it last week because I was like why is this failing if there's nothing else then unless anybody else's Kat wants to know I will take us to wrap up my cats are asleep okay so this has been the circuit python weekly meeting for November 15th 2021 no that's not right I'm reading what it says on the screen but that's the date of the next weekend November 5th the next meeting next we're going to wrap up the meeting thanks everybody for joining us this has been the circuit python weekly meeting for November 8th 2021 the next meeting will be on November 15th 2021 as regularly scheduled thanks to everyone who participated today if you want to support Adafruit and circuit python as well as those of us that work on circuit python consider purchasing from the Adafruit shop at adafruit.com the video of this meeting will be released on youtube at youtube.com slash adafruit and the podcast will be available on all major podcast services it will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe as I said the next meeting will be held next Monday as usual at 2pm eastern time this meeting is held on the adafruit discord which you can join at any time by going to adafruit.it slash discord to be notified about the meeting and any changes to the time or day you can ask to be added to the circuit pythonistas role on discord we hope to see you all next week thanks everybody thanks everyone