 Hello everyone, this is the CircuitPython Weekly Meeting for May the 16th. This is the time of the week where we're going to get together to talk about all things CircuitPython. My name is Tim and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that is designed to run on tiny computers called microcontrollers. The development for CircuitPython is primarily sponsored by Adafruit, so if you want to support them and the CircuitPython project, consider purchasing hardware from Adafruit.com. This meeting gets hosted on the Adafruit Discord server. You can join any time by going to adafruit.com. We hold the meeting in the CircuitPython dev text channel as well as the CircuitPython voice channel. This meeting typically happens Mondays at 2pm Eastern time, 11am Pacific time, except when that coincides with a US holiday. In the note stock, there is a link to a calendar that you can view online or add to your favorite calendar app, and we will also send notifications about the upcoming meetings in the Discord. If you would like to get those notifications, you can ask to be added to that CircuitPythonista's role on the Discord there. There's a note stock to accompany the meeting and the recording. The notes document contains time stamps that go along with the meeting. Oh, I forgot to start my time stamper. It's realized, so we'll be a couple of seconds behind about a minute and a half behind. I'll try to adjust those afterwards. Let's see, sorry about that. Let me get back to where we were here. The notes document contains time stamps to go along with the video, so you can use the doc to view the parts of the video that interest you most. The meeting tends to run about 60 to 90 minutes, depending on how many folks we have for our round robin sections, so this gives you an option to skip around if you are watching the meeting after the fact or listening to a podcast. You can check out those time stamps to find the sections that you are most interested in. The notes document is pinned in the CircuitPythonDev channel. If you click the little pinned message thing up near the top right inside Discord, you will see a link to that note stock, and that gets updated each week, so you can always hit that link earlier in the week in order to add your notes for the upcoming meeting as well. So this meeting is going to be held in five parts. The first part will be community news. This is a look at all things CircuitPython as well as Python on hardware. This is a preview of the Python on microcontrollers newsletter, which comes out on Tuesdays. The second part will be the state of CircuitPython, the libraries in Blinka. This is going to be a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we are all working on individually. The third part is going to be hug reports. This is the first of our two round robins. This is an opportunity to highlight the good things that folks in the community are doing. Take time to recognize awesome folks in our community. The fourth part is status updates. Status updates is the second of our two round robins. This is an opportunity to sync up on what you've been up to since the last meeting, as well as take a minute to talk about what you will be working on until the next meeting. The fifth and final part is called in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or they can be identified ahead of time as topics that are likely going to be too long for status updates, so they can go down in the weeds. Again, that is down at the bottom of the note stock. If you have any topics that you'd like to add, you can add those anytime throughout the meeting at the bottom. That covers how the meeting will go. Next up, we will take a look at the community news for this week. This week in community news, we have the Raspberry Pi Pico Learning Path. Thanks to our brand new and free introduction to Raspberry Pi Pico Learning Path, young coders can easily join and make their own cool Pico projects. This free learning path has six guided projects to help kids to independently develop their coding skills and their skills in physical computing and electronics, and there is a link here to the Raspberry Pi blog to learn more about this. Next up, we have PyCon US 2022 highlights. Some highlights provided by Eric Mathes wrote out their personal highlights from attending this year's PyCon, and there is a blog post linked in the note stock for that as well. Next up, folks can provide the Microbit Educational Foundation with your feedback. The Microbit Educational Foundation recently released a beta version of the new Microbit Python Editor, and they would like to hear about your experience using it. They are most interested in teachers to help test and improve the Microbit Python Editor by using it with your students and help shape the future of learning text-based coding with the creativity of physical computing. If you're a teacher and you are interested in teaching Python with the BBC Microbit, we would welcome your feedback, so there is a short form where you can fill out to apply to give feedback for that study being done by the Microbit Educational Foundation. A couple of projects to highlight in the community news this week. There is by, let's see, our very own Todd Bot posted on Twitter a link in a GIF and some other information about this project, which is dual screens, two GC9A01 round TFT LCD displays being driven by a Raspberry Pi Pico. The whole thing is battery powered using the Adafruit QDPi BFF. So take a look at that and there's a link to the Twitter thread in the notes. And then rounding out community news this week, we have a smart cooler monitor using the Circuit Playground Express and Circuit Python. So this was a video released on YouTube. I believe it was the Toronto Makerspace, something like that. They posted this video and it's a person who is going over the coding for a smart monitor that will live inside of a cooler. So it tells you what the temperature in the cooler is like and whether it's gotten too hot, you know, maybe if it got left open or something like that. So take a look at that one. There's a blog link for the Adafruit blog and I think the original source on that one is YouTube. All right. So all of these items have been a preview of the Circuit Python weekly newsletter, which is a Circuit Python community run newsletter emailed every Tuesday. The complete archives can be found on adafruitdaily.com. Again, there's a link for that in the notes. And it highlights the latest Python on hardware related news from around the web, including Circuit Python, regular C Python for desktop computers, as well as MicroPython developments. To contribute your own projects or news, you can edit next week's draft on GitHub. There's a link for that in the notes doc. You can submit a pull request with your changes. You can also tag a tweet with hashtag Circuit Python on Twitter or email to cpnews at adafruit.com if you would like to submit ideas for the newsletter. All right. So that gets us up to the state of Circuit Python, the libraries in Blinka. So let's see here. This is a statistical overview of the entire project by the numbers. It gives us a chance to look at the health of the project separate from what we're all working on. We'll talk about the project overall and then separately discuss the core, the libraries, excuse me, in Blinka. So first up will be the overall stats for this week. And I will read those. Let's get a timestamp here. So overall this week we had 37 pull requests merged by 24 authors, which is great to see. I didn't highlight these ahead of time, but I'll run through real quick in the names that I don't recognize as regular contributors. I think are, let's see, J.C. Rise, J.C.E. Rise, Ryan S. Keith, K.T. Kinsey, 37. Let's see, Dave Clark, W.T.U. Murrah, Matt Land, Big Tuna 94, Simon Vale, WLCX, W.A.I., W.E.N.G. 83. Those look like the folks that are new at least to me. So thank you to all those folks as well as all of our authors across everything this week. We had seven reviewers. So thank you to all of our reviewers, of course, the more folks that we can get reviewing, the more authors that we can support overall. So definitely thank you to all of those folks. In terms of issues, we had 30 closed issues this week by nine people with 23 opened by 17 people. So we are net down a couple of issues this week, which is great to see. And that wraps up overall. So next I will take a timestamp and pass it over to Scott to tell us about the core. Hello. Thank you, Tim. So for the core, we had 21 poll across merge from 15 different authors, which is awesome and amazing since I've been out. Some new names for me on here are Simon Vale, WLCX, Y.W.E.N.G. 83, BigTooner94, all new names to me. So thank you to those folks. We had four reviewers for those 21 poll requests. So thank you to them as well. We have 13 open poll requests. We have two that are over 200 days old. So those are the ones that we should take a look at. I know last week I think Dan mentioned that some of these are waiting for 8.0, which maybe we're getting close to. We could talk about that later. But yeah, we have 13 open poll requests generally, kind of even. So we'll keep an eye on those. Issues-wise, we had 19 closed issues by four people and eight opened by seven. So we're net down 11, which is awesome. For a total of 511 open issues. We use milestones to track kind of where we're at in terms of triage and things. So we have, this number is definitely not right. Minus five issues not inside a milestone. But that's always a good category to take a look at to see what we've got to triage that we haven't triaged yet. We have zero open issues, both for the 7.2X and 7.3O, which is very exciting and thanks Dan for that hard work. And then we have 35 issues for 7XX. So I think that maybe we should end the weeds, but maybe it's time to get 7.3O official and then we'll officially stable. And then we could switch over to an 8.0. It might be time to do 8.0. We'll see. Okay. And that's it for the core stats. All righty. Thank you, Scott. Next up, I will send it over to Katnie to tell us about the libraries. Thanks, Sam. This section applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuit python underscore and a couple of extras like the bundles and our cookie cutter. So over the last week, we've had 14 pull requests merged by nine different authors. A number of the new names that Tim mentioned earlier are on this list as well. So thanks to everybody who is a recent contributor. And we had six reviewers. So that leaves us with 30 open pull requests. And in terms of issues, we had 11 issues closed by six people and 15 opened by 12 people. So we're up a little bit, leaving us with 644 open issues. 191 of those are good first issues. If you are interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all this information and more, including open pull requests, open issues, and some library infrastructure issues list. If you're interested in reviewing, you can take a look at the open PRs. Let us know that you took a look. If you have the hardware, test it. If you don't, look at it for syntax, spelling, et cetera, and leave a comment. If you are looking to contribute code or documentation, check out the open issues. And if you're new to everything, good first issue is a great place to start. We also have a guide on contributing to Circuit Python using Git and GitHub. And we are always available on Discord to help out as well. So don't let feeling new intimidate you. We can make sure that you are able to contribute in a way that works for you. In terms of library updates in the last seven days, we had one new library, Adafruit Circuit Python Floppy. Thank you to Jeff for that. There are a number of updated libraries, which I will not read off, but they are available in the notes. Overall, it would say that I want to call out Tech Trick, which I will do again in Hug Reports, for running a patch over the weekend to get a couple things that were sort of crucial to the libraries to get the code updated and updated our cookie cutter as well to be the latest code so that any new libraries coming out have the proper updates to them. And so I wanted to say thank you very much for that. And that's what I've got. Excellent. Thank you, Katni. And rounding out our state of Circuit Python, let's pass it over to Melissa to tell us about Blinka. Hello. Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi and other single board computers. And this week we had two pull requests merged by two authors and three reviewers. There are currently six open pull requests amongst all the repositories. And there were zero closed issues by zero people and zero open by zero people, leaving a net of 77 open issues. There were 9,511 pie wheels down those in the last month and we are currently supporting 88 boards. And that's it. All right. Thanks, Melissa. So next up will be the first of our round robins. This will be the Hug Reports section. And again, this is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. This section will be held as a round robin where I will start and then we'll go down the list alphabetically as names appear in the notes document. Excuse me. If you are text only or not present for the meeting when we get to your notes, then I'll read yours off. Otherwise I will pass it off to you to read your own notes for that section. So getting us started. My Hug Reports this week, first one for community member Paul SK for trying out the new tab layout as well as working through the process to make a PR to share a more advanced example with some I2C sensors and some hot plug capability that will recognize when you plug and unplug them. So thank you to Paul for working through Pylint and all the other pre-commit checks and things to get a PR put in for that. Next up, thank you to NirDoc who shared a trove of permissively licensed font files from a different project. It's always great to find a bunch of different fonts that we can utilize in circuit Python projects. So thank you NirDoc for finding and sharing that. User AIOUE on Discord. I think that's the username from Discord, maybe GitHub, I could be wrong, I'm not sure. They posted steps in a PR that other people could use to kind of follow through those steps to learn how to test out a PR. It's something that maybe we take for granted a little bit like testing different changes that are in a PR. But this person wrote out some nice easy-to-follow steps that somebody may find in the future and get benefit from. So thank you to them. Thank you to Dan for making the new CircuitPython beta released recently. And then I also have the last hug report here for PT and Lady Aida for showing some neat geodes and other minerals and things last night on the desk of Lady Aida. It was fascinating to see some of the different ones. And I will also add one more that I didn't put in. Thank you to Paul Cutler for putting the links during the community news section in the chat. It's great to see folks doing that. So next up for hug reports is Dan H. Okay, thank you. So thanks to Scott who returned and then we had a good video talk about catching up and what are our priorities going forward. And also, Scott also did some immediate bug fixes for BLE auto reload stuff. Thank you very much. Thanks to Naradoc for two things, for adding frozen module listings to circuitpython.org and also in Read the Docs so each board now lists which frozen modules it contains. That's really helpful. Also for noticing just a few minutes ago, we were having trouble with monster mask boards and it appears that there may be a different flash chip on some builds of these boards. And Naradoc noticed that we were only supporting one of the chips, not both. Thanks to Tech Trick for making all kinds of documentation improvements, linking to guides and stuff like that. This is really helpful because right now in the past Read the Docs and the guides have kind of lived in separate worlds and it's nice to have them cross-linked now. And welcome back to TGTechie who is a way I think maybe doing school stuff and is coming back and has, as before is pushing the boundaries on trying to do things in the core language that are unusual and useful. Okay. Alrighty, thanks Dan. And Jeff is out the suite. So I will read his sub-report. Jeff has a hug report for Katni. Thanks for helping add a library to the bundle and knowing the cause and solution of the three problems encountered while you were working with him to do so. And then next up is Katni herself. Hello. So reiterating hug report to Tech Trick for applying the patches to the libraries and updating Cookie Cutter over the weekend. Hug report for Radimer, Scott and Dan for helping me far more deeply understand MPI files. Radimer had a very long conversation with me explaining things. I understood the gist of MPI files but I did not understand the details and Dan and Scott jumped in at the end with a couple more details and it was all very helpful as I'm writing a guide on library file types. Next up Tech Trick for helping me make a style decision on that guide to Dan for RC0 and everyone I missed because I know I missed something and a group hug. Alright, thanks Katni. Next up is Maker Melissa. I just wanted to give a group hug to everyone. Alright, thanks Melissa. Let's see, next up is Mark Gambler. I see you are here, Mark. Do you want to read yours or I can read them for you? Looks like probably text only. I think so. So Mark has a group hug this week for everybody and then next up I will pass it over to Paul Cutler. I'd like to give a hug report to Todd Bot for helping me with the request library this weekend. He got me on the right path and I was able to finish my project so I'm very excited about that. And then a second hug for Liz Clark for being a guest on today's episode of The Circuit Python Show. Alright, excellent. Looking forward to that one. So next up is Tammy Makes Things who's not attending so I'll read theirs. Hug report to Katni for a great chat last week. Hug report to Fome Guy, me for the Deep Dives and other live streams from which I always learn something and a group hug to the community for being awesome. So that's great. Thank you to Tammy and next up I will pass it over to Scott. Hello. Hug report to Katni for all of the PILEAP testing and really helping Trevor keep going on PILEAP. That's very exciting. Thank you, Katni. And then also thank you to Trevor for letting me know the reload issue and being patient with me as I worked through that. Alright, thanks Scott. Next up is Tektrick who is text only today. So I will read theirs. Hug report first for Katni for helping me roll out the bundle library patch to commit files this weekend. Zero botched patches that have been found at least. Thank you also again to Katni for offering to teach me how to use Adabot for future patches this week. Thank you to Fome Guy for helping review some PRs that I've been working on as well as helping move forward some of the ones from PyCon. And lastly, Tektrick has a group hug. And next up and rounding out hug reports is TG Techie. Hello everyone. We start off hug reports. I have a specific hug for Katni for a very warm welcome. And it's after I sent my first text in the channel. And then for Jay Epler. I believe that's Jeff, correct? Yep. And Dan for the swift response to my PR adding a little bit of documentation. Another hug for Dan for adding the from future import annotation support. That's fantastic. And I believe Scott, you added parallel display support in the like the parallel display class. But if that was not you, thanks to whoever did. And a hug for the community because you continue to be so awesome. Thank you. All right, excellent. Thank you, TG Techie. And it's great to see you back around. So that wraps up hug reports. So next up we will go on to status updates. And again status updates is our time to sync up on what we're all doing. The section is also held as a round robin where I will go first and then we'll go through the list alphabetically again as they appear in the notes document. So take a few minutes and talk about what you have been doing since the last meeting what you think you'll be doing until the next meeting. This is also a good place to provide tips and tricks relevant to what people are working on. If a discussion does start to become too much we can always move it down to end the weeds to continue it on later. So I will start out the status updates. Let me get a time stamp here. So last week I did some hardware testing for a couple of different PRs on the EMC 2101 fan driver as well as the RFM 9x radios which are things that I have a little bit of experience with but not a whole lot of like practical projects or anything so it took me a bit to get wrapped back around how to get those hooked up and how they're expected to work and stuff but it was a nice fun experience to do some more sort of nuts and bolts hardware related things. I spend a lot of time working on screens and so it is always fun to get out into more analog sort of non-picture world sometimes. Let's see, I also tried out Paul SK's new tab layout example which shows a bunch of different data from sensors so that was really neat. Thanks again to Paul for sharing that. This week got started on at least writing the project code for a new version of the PyPortal interface. There's a learn guide, I think it's called PyPortal user interface or something like that which I think was written probably back when Display.io was brand new. It's a great learn guide that I have referenced many, many times but we do have some newer features in Display.io that make it hopefully easier to write that sort of project nowadays. Hopefully we can have the code be a little more understandable and easier to repurpose into other people's projects. I started my attempt at that. I've been making a few widgets to try to make it easier to do that with this goal in mind and so I finally have gotten enough of them knocked out that I have started on the actual project and then ultimately I hope to create an async.io version as well so we can have a place to point folks who want to do user interfaces with async.io. I put in this weekend a pair of PRs into Blinka Display.io to bring a couple APIs in line with some of the newer features that were added to the core. Upcoming this week I would like to complete the remaining touch ups on the last few PRs that were submitted during PyCon and I got a few of those knocked out this morning. I think there's maybe one or two left so I'll be doing those this afternoon. I will be testing and reviewing that tab layout example from Paul SK. I noticed something this weekend where Blinka Display.io doesn't want to show bitmap labels so I intend to look into that a bit and figure out what's going on there and then the last thing I have is to try to wrap up the testing around the hidden vector IO, vector IO shapes and make any remaining adjustments. I have a PR open for that but I just need to circle back and see what's left to do on that one so I hope to wrap that up this week and that is it for my status updates so next up I will send it over to Dan. Okay, thank you. So as mentioned that released sort of Python 7.3.0 released Canada 0 yesterday we know of one possible fix for the monster mask board but other than that we hope that we can turn this into 7.3.0 final suit. There's some ongoing issues on ESP32 S3 with I2C there are a number of different bugs in the expressive ESPIDF repo we were having trouble with the fuel gauge, the battery gauge that's on the S3 feather seems to, it does a lot of clock stretching and it seems like ESP32 S3 is trouble with that so I managed to recreate this problem in a simple example in ESPIDF and I've submitted that to an existing bug which is basically the same thing in the ESPIDF repo and I think hopefully we'll get the attention of the person who's been working on I2C bugs and it will be fixed. Okay and then continuing this week I will circle back to working on some Wi-Fi issues problems that have been come up with requests and or the matrix portal library where things just crash and also I'll continue working on the port testing library that I'm working on which vets that a port to a particular family of chips is working properly and once we finish 730 final we've still got almost a couple dozen bugs in the 7XX milestone that we should work on before we finish this or else start working on the Minado I don't know. Okay, thank you. Alright, thanks Dan. Next up is Jeff who is not present today so I'll read Jeff writes last week he worked on let's see finished up enhancements to the PIO guide also published the Adafruit Circle Python floppy library into the bundle and read the docs and then for this week Jeff is in Paris, France. It currently sounds like a lot of fun. Next up welcome back and I will pass it over to Jerry. There's that button. Hi, thanks. Oops, that didn't work. I'll try and post a picture but it may not work. So I just got back from 10 days without internet and boy was that exceptional. Nice break. And I just wanted to give folks a heads up that going forward I'm going to be greatly reducing my presence both here on discord, particularly here on discord and in the forums um me to reduce the cat presence to get um yeah during this this trip I had a lot of time to reflect on my life's priorities and uh and I there's some things I just need to focus my attention on and other than what I've been doing in terms of uh hanging around on the chats a lot and um I'll be around. I'll be an active user of CircuitPython but I'll just be devoting a lot less time to discord and the forums so uh and I'll probably not be attending these meetings regularly but I will be around and um available if anyone needs to reach out feel free. This is a great community and I really appreciate all all it's given to me so um like I said not going away just back and off quite a bit thanks all right yeah thanks Jerry um next up I will pass it over to Katny Hello so last week I taught Liz how to make fritzing objects which is a pretty big deal because it's a very involved process at times and she picked it up immediately and that was excellent I proved her first fritzing that she did on her own which is very well done I started and am probably 75% through the file library file types guide page I finished all my guide feedback that had been backed up for quite a while and I tested PyLeap for PyLeap and for CircuitPython updates this week I plan to finish up the library file types guide page I'll be doing a new guide on documenting how to add any project to PyLeap continue testing PyLeap pick arbitrary fritzing objects from older products for Liz to create just to make sure she's solid on the process and that to give her a little bit of practice because we don't need any new ones right now so or if we stuck to only those her practice would be limited to when we actually have new ones and then we found some tool or PC found some tools to help make your github profile excellent using markdown and other things and so I'm going to be doing a short guide on that as well it sounds like and then also we're moving I didn't add this to my notes it's in my other notes um we have a guy that has every I squared C address well not all and not every but has a bunch of I squared C addresses for a bunch of different boards and we get a lot of people requesting us to add a bunch of boards and so what we're going to try to do is have the actual address lists live as a github repository and then use the markdown embed feature and learn to actually embed those in and then people can just do PRs to add their requested I squared C address I will be doing the beginning part of that but then I might tag a couple people in to to help out with that if they're interested but that is not a super high priority and that's what I've got all right thanks catney next up I will pass it over to maker melissa hold on just a second I lost to get the document here uh okay so uh last week I worked on I wrote a guide using runestone to edit circuit python on our code on iOS devices I worked on the 2.7 inch E in guide which will be the last revamped guide and this week I'm going to finish up the E in guide and then I'll deprecate the more generalized E in guide and start working through guide feedback for guides that I worked on but weren't actually under my name so um that's it all right thank you maker melissa next up I will pass it over to Paul cutler last week I finished editing three more podcast episodes and I've got guests planned through the end of September and still more people to invite so that's exciting including a couple people in this meeting that I want to reach out to so don't be surprised if you hear from me and then um I mentioned it earlier but I completed a personal pie portal project that I've been working on off and on when I'm not working on the podcast when I hit a button on my website it now sends an image directly to my pie portal automatically and that image is typically a covered art from a record album so I'm a big music guy so that made me very happy that's all I got awesome thank you Paul next up is Tammy makes things who's not attending so I'll read hers let's see if we didn't get anything that she was hoping for done last week because of work and personal conflicts but this week uh Tammy's hoping to get back to regular live streams on twitch.tv there's a link in the notes if you'd like to follow Tammy on twitch um so getting back to streams this week working on the display IO card deck library uh trying to do a couple more PR reviews and uh getting let's see getting my project list organized so I can be a bit more focused alright and next up I will send it over to Scott thank you Tim okay so last week was my first week back after six weeks off for paternity leave uh since then I've caught up on email and I gave up on catching up on the discord chats so uh I've caught the last few days and I got over the weekend but um like I didn't go through six weeks of discord chats um the first kind of one of the main things is the BLE workflow was broken um by the reload work that happened in 7.2 uh so I did two fixes for that this week uh and now we keep BLE active through the wait period that happens after the VM is done um that's new so what we used to do is with the old reload code we would actually wait for subsequent writes while your code was still running um but Dan switched it to be clearer where the very first time we think we're gonna reload we stopped your code and then we wait after that um you may have noticed that working with circuit pipeline I think it's a better change but it did uh break the BLE stuff because the BLE stuff when the VM gets shut down the BLE stuff gets reset and that was a problem so BLE now gets kind of reset twice um or at least in two stages um so I think that's good and thank you to catney for testing it um I'm working on switching the NTP library to actually using sockets to do NTP um I should cross this may need to change get time on ESP32 spy I'm just gonna not deal with that so I've got some examples to change um and I'll do that and the more is gonna do the review for me so that should mean that we should be able to use NTP on the native sockets which will be cool and then on Friday I I found this um these arm development studio files which are used uh defined properties of like arm cores um and that includes some of the registers like the sys tick registers and these registers are not usually in the SVD files that vendors provide um but I found this project that was doing conversion from these ADS XML files to SVDs and uh those registers are really handy especially if you want to know like what the active active interrupt is and stuff so I just hacked up a quick python script that um converts these ADS XML files to SVD files so um should be able to use existing tooling for SVDs to be able to look at the registers that are kind of common for a given arm cortex core which should be cool um and I put a link there and I was talking with the pyocd person a bit about getting support in there as well and there was like some xslt file to do the transformation it was like I didn't want to deal with that so I just hacked it up in python um which I enjoy doing uh this week uh I gotta wrap up the NTP library changes I'm gonna try to do that today um and then I'm starting on the web workflow um I did the mdns stuff before I leave the next thing up is kind of secrets management um basically where do we store wi-fi credentials so that both like user code and circuit python core code can access it um I do think this is maybe something broadly we're gonna want to do in terms of just like setting the behavior of circuit python over time um so if you have opinions about this please let me know not right not immediately but um reach out to me if you have opinions about this um one thing LaMoure was talking about was being better about like obfuscating credentials so they're not so easy to look at but I think that's kind of a it's kind of a like if it's not super secure maybe it's better that we just make it obvious it's not secure rather than trying to be a little secure um anyway the thing that I'm thinking about is there's a .env library um which stores credentials for regular python projects in a .env file and I think I want to try to mimic that with circuit python so I'll just add a subset of that library that we need and then we'll also have access to some c functions that can read and write that file um so that the core can say like hey get me this key out of this file and if it's there then it can like automatically connect to wi-fi and keep that connection consistent and stuff like that so uh that's the direction I'm going web workflow which could be really exciting so uh if you have thoughts and stuff please reach out to me all right thanks Scott definitely exciting stuff um next up is tectric who is text only so I will take time stamp and then read uh last week tectric uh wrote and deployed a script for patching the pre-commit config yaml file in all of the libraries in the bundle as well as in the cookie cutter repo um added more documentation to the core relating to linking to learn guides and other resources for modules uh worked on making uh max 72 19 bcd digits chainable uh turned out to be harder than he had thought at first so it's still a work in project uh progress um and then this week tectric writes uh learning to use adabot with catney uh many more infrastructure files need to be patched across the libraries so gonna try to plan that out to start writing scripts if adabot can't do it um still working on refactoring the a t e c c library had a small hiccup while uh excuse me had a small hiccup receiving the wrong part uh looking at writing a data class like or adders like library for adding similar out of the box functionality to classes uh via decorators and fields uh and then maybe the following week looking at the adafruit logging differences from c python logging to see if moving some things around would be more helpful uh thanks to ask patrick w for offering help to test uh and then next up i will send it over to tg techie thank you and before i get on to uh my updates uh congratulations scott um and dan if if that is the same battery gage chip that is on the adafruit's fuel gage board um doesn't the nrf have some trouble with that as well it doesn't have trouble so let's okay with the s3 okay maybe it has different trouble or maybe i'm not nice to my circuit boards um okay thank you so uh i've been um moving on to my sass updates i've been away for quite a while um i think it's about a year excuse me um so but uh short version highlights um i'm on break from college and i was from college were finally getting to write c code in the computer engineering program for the first time in jr here which doesn't make a lot of sense but was a lot of fun um and learning how to study which was interesting um otherwise i've also uh i tried type python and shall absolutely in love with in love with it um because it makes i find it makes my life programming a lot easier other people love it for other reasons as well um i also helped a senior design project at the school run circuit python on one of their boards a metro at 751 but they forgot to add flash to it so we had to fill it stuff to see if we could get to use the internal file system and it took some hacking but um we were able to shrink interpreter side enough down where we could fit in three fourths of the flash uh if i'm remembering the ratio correctly just a lot of fun um last week i had an opportunity just doing whatever i wanted so of course i came back to circuit python um and i've been for years now uh working on making an easy to use graphics framework for python and circuit python um to touch back at etc uh the idea being i wanted to be easy to use but um while doing that i've been writing type code and was generic and i have been having trouble getting the generic code to run on both the circuit python interpreter and the c python interpreter without like adding decorators and very carefully using specific classes that sometimes aren't actually classes if they're running in circuit python etc so um having more experience with things i branched circuit python and added one one specific function uh and to add uh under class get item support i have thoughts on how to do it efficiently and etc and i think it's a larger discussion but not should work but that's what i did do last week and it was a lot of fun um and finding the mp type type object was also a lot of fun it's really cool um next week i have uh more the same that and finishing up a class um i have sort of two two quick questions oh maybe three three um and if they are grow past as you said i'm totally around to talk about them in the weeds um for prs regarding documentation is it like is there suggesting for grouping related unrelated or like is it fine to have a bunch of smaller prs if it's improving the description to a function or something um i will let other folks chime up if they have ideas as well i would say personally i don't see any issue with small prs um so yeah i would say if you spot something that you can take care of and are compelled to do so go ahead and make a pr for it it doesn't matter if it's just a small thing um yeah that's that's my view on it awesome thank you um i did some googling around is there and uh something came up when i accidentally submitted a pr for something else active accidentally way preemptively um is there a specific version of the typing library circuit python targets or supports or is that just up in the air oh i see some people typing yeah i think the short answer is it is up in the air a little bit i would say the thing that we are pinned to most directly right now is um in like the blinker libraries they currently and i think it's set for three seven i would have to go look at one of them to be sure but i think like setup pie inside of the uh blinker libraries is pinned to a version of python and so that's kind of the thing that we're most directly tied to i think that that was updated when we first started adding typing into the blinker uh layer of libraries but i'm not a hundred percent sure if that's when we did it specifically um but i would say also i think we kind of updated it to just the lowest one at the time that kind of had everything we needed um not necessarily chose it because it supported all of the exact things that we were planning on doing or or using so it's certainly likely that it will get updated in the future to point to one of the newer ones which definitely do have lots of uh helpful things for typing okay thank you and i'm assuming type extensions are allowed using the type extensions module is fine um but i can search for that outside of beating yeah so for those on audio typing extensions for three six in some cases if it's not there but try to avoid trying to get people to use at least three seven um thank you mm-hmm and uh lastly after coming back from from the long hiatus um a bunch of like the tooling around circuit Python has improved a lot which has been a lot of fun to see um i noticed well learning how to use pre-commit um i ran it on the whole circuit Python repo and it reformatted 30 plus files i don't know if that is intentional i have noticed that as well i also don't know if it's intentional my understanding of what has happened is that lots of people and i think even the guides tell you to do it this way um people run with pre-commit install so like pre-commit installed into the repo to make it automatically run whenever you actually do make a commit and i think when you do it that way it uh it only runs against files that are actually in the commit so in that case it only runs against the files that you changed but if you run like pre-commit uh run dash a or pre-commit run all which i do a lot of times on libraries if you run that command in the core i have noticed as well that it does um reformat a bunch of like uh python code that's in various places in the core um so i would definitely defer to maybe uh scott or dan or anybody if anybody knows about those files or if we want to just make that change and merge it to main uh but it's definitely i have seen what you are talking about i think no those files come from micro python and they don't use the same rules so we don't for merging reasons we'd rather not change them from the upstream i see i wonder maybe worth looking into i don't i'm not super familiar with pre-commit configs i wonder if there's a way to um block those i guess black though black really wants to do everything maybe not but yeah so that's uh that's what we got there it is it is known and it is uh intended to be that way so yeah your your options oh go ahead some of these files are not from micro python um my reaction is that i get some differences sometimes if i'm using different versions but i would just actually make a pr um because that will run it on uh the ci and that that will the ci may say like oh some of these are wrong if the versions are misspatched otherwise i would say we we could do them um generally i don't have a trouble i don't think we should have trouble with formatting issues when merging micro python because we could always run the pre-commit stuff on micro python before we merge it in um to minimize that as well that's a good point yeah like that's a whole idea with formatting yeah but we should i thought we were set up to be the same as micro python i thought we chose to do that i i when you said they didn't you mean they come from third party libraries that micro from there i mean in this change there's some stuff in like ports at mel uh there's some stuff that's going in the sub modules right it's not it's not going in the sub modules yeah you wouldn't get a different circuit on them yeah well just i would i would say that yeah i would we can we can you could pursue the individual things and try pr would be yeah i would make a pr on it just to see if the ci agrees with you because i do have versioning i also i wouldn't be surprised if it's a we have incompatible crust uncrustified versions yeah maybe yeah yeah i actually have i've been having to downgrade mine ah is there a way where do you know what version that you have to downgrade to i'm downgrading to zero seven one i think i'm gonna write that down and or make a pr oh no i have zero point seventy four point zero that might actually be too new zero i think i did up your zero but you think it should be seventy two it should be seventy two zero seventy two dot zero i have i have the downgrade command that i've had to run the the ci will test it will catch it because the ci will disagree with you basically what you need to do is you need to match the version in nubuntu of uncrustified okay but i'm not a nubuntu so i get the newer one faster love it and not love it sometimes i feel you but it means that i find out all these things early um thank you welcome back good to be back yep alright so next up and our final section for today is in the weeds and again to reiterate in the weeds this is an opportunity for more long form discussions that could either come out of status updates or they can be topics that folks have identified ahead of time and put in the note stock if you have any in the weeds topic please be sure to add them down at the bottom of the note stock and we will just go through them in the order that they are in there so first let me take a timestamp actually in the weeds and then our first in the weeds is actually also from tgtechie so why don't you tell us what we are gonna talk about here tg alright so i have two in the weeds topics in here but maybe the second one should go at the end first one as i mentioned before i accidentally submitted the PR too early before actually adding proper content but it brought up a discussion about optimizing for the type checking variable in the type module so python has in the typing module a predefined variable that looks like it's true to the typing system type checker but it will always be a false run time and there was discussion between Jeff and Dan about optimizing around that it settled on using the try accept syntax i have a link in the meeting notes if someone wants to see their discussion before i go into the weeds the circuit path on optimizer around failed try imports imports inside of try statements for frozen modules is that true the issue is more that it doesn't during the it compiles all that code so it takes up space in the mpy file so is that what you're asking yes i should have asked that directly shouldn't that's the point the point is that like i had originally said oh could we just put it inside try accept and jeff said but then it wouldn't get optimized away where because it's not a constant optimizer it's not an optimization that's dependent on a constant so whereas if you use an if statement it's dependent on a constant and it can say i'm just not going to include this code because it's always false okay so that's why to do it that way so but okay is there interest in trying to reduce that mpy compiled size yeah because we have because like the sort of playground express library is very tight so if it has time that we want to not to include as little of that type checking as possible in that final library so i want to before so my thought was just is there a need for a separate facility that performs the same thing but is provided by sugar python here and i'm not sure it's going to work because we also wanted this to work under regular c python and so my pie for instance knows about type checking all caps type checking it doesn't know anything about micro python and my my my pie is not going to do the right thing um a particular annotation so i mean you can uh there's a there's a python typing thing called literal or you can say something is like always literally true but i'm not intended i believe my pie can see that and will interpret another variable as always true maybe that would work but that would be the thing is that the idea was to make this code be as compatible as possible with the currency python so that's what i was saying without blinker yeah if you don't write it with blinker then you because blinker is going to have to provide the mechanism so you're going to have because blinker is blinker maybe with this literal true thing but i was going to say like you know blinker yeah blinker could define that thing but it's not necessarily going to solve the problem so um so which which problem the problem that whether my pie knows what the value is or not what meaning of it so okay um if it if it did would there be interest in using that as a way to basically i think if that works i think there's a way where we can like just add a add that constant and then my pie will see it as if it's tech checking really should practice my explanation for this uh i didn't sorry it's a little jarbled um so i would say write this as an issue or as a pull request and and i think we'll talk about it i think that's probably there okay how it works out i think that would be yeah that's fine thank you okay um and the next one is is kind of a like relating to typing except it would be a adding a feature once one function i don't know if it's best to discuss this discuss this now and maybe it should just be uh j please put it in a pr we already are using proto we have this library circuit python underscore typing and it's using it provides protocol things already are you asking about adding it in the circuit python core uh there's right now micro python is all annotations okay it doesn't do actually do anything with the annotations it just throws them away and and so there's no the only support for annotations is in the sense that if you run through something through my pie it might notice or um you know idees might it might help idees but micro python itself and we use that core doesn't do anything with annotations it just throws them away yes um uh and i'm sorry i think there's or what i found is there's two of the has support for uh defining protocols i believe there's two maybe just one um things that you can't put in type annotations that the typing module needs uh for like a generic class being the type bars and the uh generic open bracket closed bracket classes not supporting but it can't because um i might have an image handy when you define a generic class like something that contains something else you want to type it you that code has to run a little bit you know it ends up not doing anything if we were to support that the syntax requires it just to run time a little i think we have libraries that are already using this notation and they're they're they're compiling okay so like if you look in the circuit python typing repo there are some things that are defined with protocol and they're used in some libraries like in some of the ble libraries or wi-fi libraries they can't remember which they're running on circuit protocol yeah they definitely do the protocols that are used in that typing library definitely do work on circuit python yeah and so micro python just throws away protocol open square bracket something closed square bracket just like at a syntactic level yeah that's what i'm telling you micro python doesn't do anything with annotations oh oh annotations including the ones that aren't oh i thought i misinterpreted that description that uh i know the first question ages ago it doesn't put them in the syntax it doesn't do anything with them okay okay okay i i did not realize that the parentheses in the class list were included there i must miss that one when i was testing yeah super cool thank you look around some of the libraries it's been more a lot of more recent stuff honestly since about like octoberfest was kind of our first dive in but also we've done a lot of more work recently with python sprints and stuff but if you take a look around some recent pr's across the libraries there's lots of new typing stuff so you can see kind of what types of things we have done and what types of things do do work today yeah so tectric is doing a lot of this work and if you just if you like clone the bundle repo and get all the sub modules you can grab through all the libraries and find uses of protocol get grip okay we'll do thank you yeah for sure thanks tg techie next up in the weeds topic is from tom aio u e attending but can't talk so I'll read this one let's see yeah no this is definitely the right place to talk about it so Tom says pi portals are amazing devices great screens wi-fi speaker sensors micro sd slot and more all built in they deserve to be more popular to support this I've created an issue on circuit python org github which I will see try to copy this and paste in the chat for us so that's on circuit python org the website circuit python org the proposal that Tom has is simply adding tag categories for pi portals to the learn site just like the circuit playground and its variants have I believe this would make the pi portals more popular and approachable as they be easier to discover and learn about and I think this page is this the page that lists a bunch of projects for that device so we have something called groups maybe cat me wants to say something about that in the learning and learn guides my overall thought on this is that this is not the place that can make that decision but just because once you get into stuff that's actually going into learn there are other people who need to be part of that decision who don't attend this meeting we do have groups that are not currently super prominent I think still but they're working on that which is where you can make a set a set or a list of related projects and then they all sort of show up in one place as for adding categories to learn that's definitely outside of a decision we can make here the issue I read through it earlier it's very thorough I can definitely pass it on to the right folks but I make no guarantees as to whether or not it'll get integrated and unfortunately I greatly appreciate the issue but there's really no way for you to help with this other than the issue which was excellent but learn is a proprietary system unless you are part of it as an author or technical contributor you can't really make changes to the learn system which is where this would have to go so I just want to let you know now there's not really a whole lot you can do beyond what you've already done for us but there's a couple I think small solutions which is like at creating a pi portal group which I actually suppose on some level you could help with if you wanted to pick seven projects or something pi portal related that you think sort of embody the pi portal as a product that would make making the group easier there is a list it looks like I don't know exactly the right terminology for it but product slash product ID and then slash guides this basically gives you a page that is really almost the exact same kind of content that was on that circuit playground page which it has basically overview of the device and then a list of all of the relevant guides I think the issue is that it doesn't it's not necessarily that easy to find that's true I happen to know where it was linked from you knew the link exactly and other folks don't necessarily know that link or know to click on it so making something like this more prominent might be useful but also if you look at the explore and learn I see what you're saying I think you're requesting something different than I think you are and that's where the disconnect is I think there's kind of two places I can think of like the issues on circuitpad.org is really good for the categorization of boards but when thinking of learn stuff I think support at adafruit.com is the latest apparently they tried that okay because some of that stuff gets forwarded onto the internal themes right and like you said Katni unfortunately it's pretty closed learn is still pretty closed yeah so I can at least bring the issue to the attention of a couple folks but like I said I can't make any guarantees so I want to make sure the expectations are accurate alright thanks Katni your input definitely next up is let's see a topic from Tectric who is text only so I'll read it this one out I was kind of involved in the PR as well the specific PR here I'll link it it's this EMC 2101 fan driver I think the topic is a little bit more general than the specific PR basically the gist of it is the driver this fan driver has support for different levels of functionality like for instance you can use a fan with a tachometer pin which tells the driver how fast the fan is moving but you can also use the same driver without a tachometer pin but the actual chip that's on board has like a status register and in this PR the author of it basically set it up to where it would pull the status register every time it tried to do some other action like if you tried to set something or read some other register or something it would also read the status register and then raise an exception if it was one of the values that indicates a problem which if you're not using all the functionality it would be one of the problem ones so the specific case here was like you could use the fan driver without the tachometer the fans I have because I did some testing on this and the fans I have don't even have a tachometer pin and in the current version of the library I was able to hook them up and run the examples and stuff and obviously it doesn't tell me the speed that it thinks the fan is running because it's not hooked up to it but everything else was able to work fine it was able to drive the fan as well as change the fan's speed at least in that one way direction it could tell it how fast to go but I think kind of the general question is like philosophically do we want do we want libraries to raise exceptions if the user is only using like part of the functionality essentially like if they don't care about the tachometer do we still want to raise an exception because the status register says that something is wrong or do we want to allow that library to be used you know to the best extent it can given what is hooked up in it in the way that the person is using it and then if we do want it to be able to run do we want to have like a strict mode or something that will actually enforce the status register and raise the exceptions and if so like what do we want the API to look like just an argument in the constructor you know tell it strict is true and then it will raise exceptions if it finds errors in the status or do we want to do like a subclass of the main driver class or something like that that contains that functionality I think that's the the gist of it Tectric if you're around in text and you have anything to add you can drop it in the discord there my intuition is that we it just shouldn't raise an exception okay I think that it's a trap to try to support everything with a particular driver especially when we're doing driver development we really do kind of want to hit the hit the main points of it but not be exhaustive and checking status register raising exceptions for everything sounds exhaustive to me I think my my gut says that you don't really want to raise exceptions at all what you really want is just a access to the status register that the user code can check okay so we'll make sure I don't recall in this case if it is like a public method without an underscore but if it is not if it does have a leading underscore maybe we make that part of the public API by removing the leading underscore and then user code could always pull that and do right if they care about that okay I like that approach yeah that's kind of what I feel like I see what you're saying with the like otherwise I have to tell it whether I care about it or not right yeah kind of weird yep okay so I will I can leave another and updated comment on that one and see where it's at and make the necessary recommendations there so thank you yeah feel free to at me on there too if you want me to chime in okay yeah we'll do yeah thanks I appreciate your input and then the last actual in the weeds topic is your scouts so go ahead yeah so just thinking about how we want to organize versions like Dan did an RC0 for 7.3 which is what main is right now do we want to call main 8.0 at this point because there are some pull requests that are waiting and we have issues open for 8.0 as well the one confounding factor is that MicroPython 119 is do pretty much any day but I I'll check with them later if they have a better idea but it will require a new version a new major version because it does have MPY changes so and of course I don't know how quickly we'll want to adopt it as well so do we want to do 8.0 now but know that if we adopt 119 we're going to need a 9 I think that even if we don't do any official releases at 8.0 but then we merge in MicroPython I think we should just switch to 9.0 anyway just for clarity in terms of what MPY people should be using any thoughts I I don't think we should go to 8.0 yet I don't see any reason to go to 8.0 yet because there's like not a theme or anything well I mean there's two reasons to do it right one is a theme and two is breaking stuff yeah so I mean there are all these there are all these right I think what I say is like I'm willing to continue on 7.x mm-hmm until something happens where we need to break it the only reason to go to 8.0 right now is because we keep on having to turn off one wire I owe that's like the only reason there are a couple other things that so I what I feel like is like 1.19 will come out right you probably wait a couple of weeks I mean we can start merging it and have an 8.0 alpha you know at that point but and then there'll probably be some bugs which they'll probably have to fix and we can incorporate those but the major the the jarring thing which is the MPY format is I think we should wait for that because otherwise it's kind of a support problem yep that's fine in me I yeah I might also introduce some incompatibilities with the web workflow stuff I'm doing I'm not entirely sure at least you know I want to change it so that in particular cases sockets and like the web the Wi-Fi connection itself will be maintained across resets which is not something that happens right now yeah and so so right so the problem is if you do that before we do the 1.19 merge right yeah but I'm not I'm not entirely sure that's the case because it's likely because I know Naradoc already kind of said like well I like how it is now where I can manage when it's on I think it's more likely that like I introduced this dot env stuff and then if there's a flag in there then it works this other way and that would be backwards compatible so that would be okay I I was thinking I was wondering you know what if you if you have a jarring change like the MP why why I think that regardless of anything else that is actually actually the actual massive change that should cause a major version change yeah I agree with you there oh yeah we always do that we always do that because if you don't wait for that if you don't wait for that I can see a problem with the with the library bundles being all sideways well I mean it's just a matter of whether we do eight now and then nine later or we just wait for it yeah there was one there was one time I think when we made an MP why change while we were in alpha and that's what you're trying to avoid right is that what you're saying it just makes no it makes no sense to do that yeah numbers are free so I think I think I think just to get some information from Damien is probably great to say like how imminent is this so yeah I'll bugged in later yeah yeah I I don't have chats with Damien Jim's yeah that's gonna reply to me on discord if I bug him okay so yeah double check I've heard that it's imminent so it shouldn't be that long yeah they were trying to do it on a tick tock schedule but I think they're behind a little bit so yeah and I don't know I don't know how hard it will be for us to integrate you there so that's the other question yeah and whether it's actually worth it I don't know what else is in 119 decided the MPY stuff because I don't think we're going to benefit from the MPY stuff ourselves yeah prerequisites it's just that format will change right I mean changing the actual format or something right so yeah I can live in yeah linear flash memory yeah which is cool you just want to be I just know I I would be deathly I think when you said 8 and then when you decide whether or not the MPY is good then go to 9 or you have to when you decide about the MPY you're gonna have to make a major version change right no matter whether you do it at 8 or 9 yeah yeah so I think it's fine I think I think what we'll do is we'll just wait for 119 and then we'll do 8 because nothing is blocked on the new version well there's PRs that are blocked on the new version that's okay they're not critical all right I'll add that to the notes yeah thanks Scott sounds like we got the plan forward for now so that was our last the weeds topic so doing a wrap up for the meeting here this has been the CircuitPython Weekly Meeting for May the 16th thank you to everyone who participated if you want to support Adafruit and CircuitPython as well as those of us that work on CircuitPython consider purchasing hardware from the Adafruit Shop at Adafruit.com the video this meeting will be released on YouTube at youtube.com slash Adafruit the podcast will be made available on services will also get featured in the Python for Microcontrollers newsletter visit AdafruitDaily.com to subscribe to that the next meeting is scheduled to be held on Monday as usual that's going to be May the 23rd I believe at 2pm eastern the standard time let's see this meeting will be held in the same place on the Adafruit Discord which you can join at adafru.it slash discord if you want to get notified about the meeting or any changes to the day or time you can ask to be added to the CircuitPythonistas role on Discord and then we'll ping you through there if the time is going to be changing so that does it for this week's meeting thank you again to everyone who participated and we hope to see you all next week thanks everyone