 Hello, everyone, and welcome to the Circuit Python Weekly Meeting for February 28, 2022. It's the time of the week where we get together to talk about Circuit Python. I'm Jeff, and I'm sponsored by Adafruit to work on Circuit Python, as well as Floppy Drives. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. There are over 256 different little boards that you can run Circuit Python on. Circuit Python development is primarily sponsored by Adafruit. So if you want to support them and Circuit Python, consider purchasing your hardware from Adafruit.com and the resellers that we list on the Adafruit.com website. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafruit.it.discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. But people are around 24-7 to talk about all things Adafruit, electronics, 3D printing, and more, so come by any time and stay awhile. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday. In the Note Stock, there is a link to a calendar that you can view or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the Circuit Python Discord role. There is a notes document to accompany the meeting and recording. As we go through the meeting, I add timestamps to go with the video so that you can skip around to see just the parts that interest you the most if you're watching after the fact. The meeting tends to run 60-90 minutes, so we think that's a handy option to offer. After the meeting, we'll post the link for the next meeting's notes to the Circuit Python Dev Channel on the Adafruit Discord. You can always find it in the pinned messages. That helps you add your notes before the following meeting. In fact, it's often helpful to add them throughout the week so that you don't forget your accomplishments or the hug reports that you wanted to give. And as always, if you wish to participate but can't attend, you can leave your notes in the document and the host will read them at the right time during the meeting. We hold this meeting in five parts. Next up is community news where we get a preview of the Python on Microcontrollers newsletter, take an overview of Circuit Python and Python hardware around the internet and the community. Following that is the state of Circuit Python, the libraries in Blinka, where we look at a statistical overview of the entire project, look at some numbers separate from kind of the touchy-feely parts of it. Next up after that is hug reports, the touchy-feeliest part of the whole meeting, an opportunity to highlight the good things that folks are doing and taking time to recognize the awesome folks in our community. An awesome antidote to bug reports, which are what we usually hear about. The fourth part is called status updates. During status updates, we invite everyone to talk about what they've been up to in the last week or so, as well as what you hope to get up to in the following week or until the next meeting that you'll be able to join us on. And then last up is a section called In the Weeds. If we need to have a longer discussion about any of the topics that come up throughout the meeting or that you've identified ahead of time, this is when we will do it. If it's anything that will take too long, please move it down to In the Weeds so that we can keep the status updates section moving smoothly. And that covers the basic structure of the meeting. And with that, I will head on to overviewing community news. We've got a number of kind of big project releases. So I'll start off with the Mew Python Editor, version 1.1.1 stable has been released. There has been a lengthy contribution and beta period with a lot of upgrades, as well as translations. And we've got some links to the Adafruit blog and the Made with Mew website. And there's also an interesting video on YouTube called the Making of Mew, which I think kind of visually shows the Git history of participants and where they work within the code. And that is a little bit abstract, but it was fun. I watched some of it. Next up, we had our own release, CircuitPython 7.2.0. Thank you to Dan over the weekend, and thank you to all the contributors. You can check out the GitHub, and I have failed to put the link in the note stock to find the release notes, or you can go to circuitpython.org to download it. Next up, the inaugural episode, I believe, of the CircuitPython show is going to air on March 1, and will feature an interview with Catney. Other announced guests include Les Pounder of Tom's Hardware, Professor John Gallagher of Boston College, Todd Kurt and Rose Hooper of Maker, and Scott Shawcroft, the CircuitPython lead developer. And there is a bunch of links in the notes document. So check those out. Next up in the project department, picked out as Project of the Week at the Saigon South International School, two Sphero RVRs, two Vex Robotics games, two boards, a Raspberry Pipico and an Adafruit Metro M4 Express, running the same CircuitPython program. Sensing is done via an HCSRO4 ultrasonic sensor attached to the front of each vehicle. Each step of the vehicle's trip uses a different control algorithm from a library, and there's some GitHub and Twitter links about this. I'm not actually sure if it's a contest or just a tech demo, but there's also an animated GIF, so check that out in the note stock. And another project, we have an introduction to software development and coding challenges for blind and low vision coders course, including HTML, ARIA, and Python while using assistive technology. And that is from American Printing House via Twitter. So this is just a preview and some of the highlights that caught my eye from the draft of the CircuitPython Weekly newsletter. And that is a community-run newsletter emailed every Tuesday. You can check out the complete archives at adafruitdaily.com slash category slash CircuitPython, and that's also where you can sign up to subscribe. We always aim to highlight the latest Python and hardware-related news from around the web, including CircuitPython, Python, and MicroPython developments. To contribute your own user project, edit next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. And a big thanks to Ann for almost every week assembling this huge mass of information. And it's just a fire hose of great stuff. It was hard to pick out just a few top items for this. But we're going to cut it short there and subscribe to the newsletter if you want the full details. So next up, we have the state of CircuitPython, the libraries, and Blinka. So we have our lovely bot, Adabot. Check out the events on GitHub over the past seven days and give us a little summary of that. So it kind of keeps us grounded in real-world facts about how the projects are progressing. And so overall, some of the top numbers are that we had 33 pull requests merged from 23 authors and 11 reviewers. And as usual, there are some names that aren't familiar to me and I apologize as I try to pronounce these. We have Millija as one uncommon name. Purples is a relatively recent joiner but has been doing a lot lately. Chabala is not one I recognize. Chow8219. Boy, Rimwolf Redox. Zelwarto. Flam84. So thank you to all those authors of pull requests that we were able to merge. And then those were reviewed by 11 different people. A lot of names that we see every week or most every week. I think Tectric may be new or newer to this list so thank you for coming on board as an official reviewer. So reviewers are the people who enable us to take all these contributions from authors. You do things like check out a pull request, make sure that it addresses the problem or enhancement that it was working on, check the coding for style or possible new problems and catch those early, just generally keeping the quality of our contributions high. So thank you to these reviewers who are listed by name because GitHub calls them reviewers. And thank you to everybody else who comments on the issues and pull requests as we work on them that is always a valuable addition. So next, let's see. I didn't negotiate this ahead of time, but Dan, are you able to tell us about the core since Scott's not here? Okay, sure. So in the past week, we, 14 pull requests were merged by 13 authors, which is terrific. So almost one author per pull request. Thank you very much. There were five reviewers. There are still 16 open pull requests. Some of those are in advance until 800. Some of them are drafts. And there are a couple that, most of them are very new and still in process. So that's good. Three issues were closed by two people and 10 issues were opened by nine people. So we're up on issues and probably need to do some pruning. There are 503 open issues now. There are six active milestones. That's a way of labeling a set of open issues. There are zero open issues for 7.3.0. Actually, there's now one, because I moved an issue into there an hour ago. There are 25 open issues that we hope to fix by the end of 7.xx. There are eight open issues for 8.00. Those are mostly issues that need to be closed once we're done with 7.00.0 and are moving 7.xx.0 and are moving on to the 8.00.0 releases. 18 for libraries and 447 long-term open issues, which are a varying level of urgentness. Three open support issues and one issue now assigned a milestone, which we need to triage. Okay. All right. And of course, as we talked about earlier, a version 7.2.0 was released. So that's a big step forward. I'm going to say everything we said several times. Yeah, we'll probably cover that at least two more times. Let's see. And going back to overall, I skipped the overall statistics on issues. So overall in the project, we had 17 issues closed by nine people while 16 were opened by 15 people. And with that, I will ask Katani to tell us about the libraries. 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 extras. So across all of these repos, 17 pull requests were merged by 11 authors and we had nine reviewers. The oldest pull request that was merged was 64 days old. So we're still slowly getting through the older PRs and most of them were one or zero days old. We currently have 13 open pull requests, which is amazing. It continues to go down. And in terms of issues, we have 13 issues closed by seven people and four opened by four people, leaving us with 617 open issues. 209 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more. You can search the issues to find something interesting to you. You can, if you're interested in reviewing, you can search the PRs. With that, if you have hardware tested, if you don't, you can look at the code for syntax and style and so on. Leave a comment and let us know you took a look. That is always helpful and after you're comfortable with that, we can talk about moving you to the review team. Good first issue is a great place to start if you're looking to contribute, but you've never contributed to open source before. And we have a guide on contributing to Circuit Python using Git and GitHub, as well as all of us available on Discord during the week to help you. We would like to see you be able to contribute in a way that works for you. In terms of library updates in the last week, there have been no new libraries, but there is a list of updated libraries, which I will just leave in the notes if you're interested. And that's, we're still slowly getting through older PRs, which is good. I'm really happy to see that number come down so far. Obviously, there's always going to be some open PRs because things are getting reviewed or whatever, but it's really great to see that number coming down and thanks to FOMI guy who's been putting the effort into going through the older PRs to get those merged. And that's what I've got. Thank you, Katnick. And finally, to round out this section, I will invite Makar Melissa to tell us what is going on with Blinka this week. Hello. Blinka is our MicroPython, Circuit Python in... I'm sorry, let me start with that word again. Blinka is our Circuit Python compatibility layer for MicroPython and Raspberry Pi and other single board computers. And this week, we had two pull requests merged by two authors and two reviewers that leaves five open pull requests. There was one closed issue by one person and two opened by two people, leaving a net of 73 open issues. And there have been 14,985 pine wheels downloads in the last month and we are currently supporting 87 boards. And that's it. All right, thank you, Melissa. Next up is Hug Reports. So there are all sorts of people around us in this community on Discord, on GitHub, on Twitter, in the real world. And in Hug Reports, we invite everybody to tell us about what they saw going on because it was great and supports the community and makes us all better. And so I will start and then I will head down through the notes document in order as it's given. So this week, I just have a group hug for everyone who has contributed to the 720 release. And that's not only those people credited on GitHub as authors and reviewers, but also everyone who shared ideas, filed bug reports, tested their project with pre-releases, et cetera. So if you're hearing this, I'm thanking you for the work that you did. Each release is the best release ever and we are just going to keep going with the support of all you wonderful people. All right, and up next, I have notes from C Grover, who has a hug report to the team and community for the newest release. I continue to be amazed by the pace and quality of the collective community process. Hug to yesterday's wise mentors that encouraged and pushed me forward into a rewarding, lifelong passion for electronics and music, and all the wonderful trappings and friends that come with the territory. And to today's mentors that nurture and strengthen the fabric of new interests, acquired skills, and knowledge. And with that, I will hand it over to Dan. Okay, thanks to everybody who helped with the 720 stable release. I really appreciate we had a bunch of new people working on bug fixes and people submitting great issues and so forth, and it was very helpful. So we're on to 7.3 or something like that, maybe 7.2.1, we'll see. Thanks to T. Ikagami, who got the native module helper for Async.io called underscore async.io. It's called underscore uasync.io in MicroPython, and we renamed it to underscore async.io in CircuitPython, and I had put off doing that because I was having trouble getting some internal thing working right, and T. Ikagami got it working, so thanks very much. And thanks to RimRolf Redux, who submitted a PR which caused a whole bunch of things having to do with type annotations to happen, and we were working together over the weekend about how to help solve that. That was very helpful. Okay. All right, and next up, FomyGuy, what's on your mind today? All right, thanks, Jeff. First hug report is for Adafruit for always striving to do the right thing and serve as a role model during crazy events of the world. A lot of companies are happy to just keep their head down, keep a low profile, so to say, and not really do a whole lot until it starts affecting them directly, and I think it's very admirable that Adafruit will kind of try to pipe up and say and do the right thing in all the crazy things that have happened in the world. Of course, in the last couple of years, but for many, many years they've been doing this, so thank you to them, to Katni and PT, who both went out of their way to ensure open communication was possible, and both have done quite a bit to help me in being comfortable as a new member of the team, so a special thank you to both of those folks. AT Maker's Bill, during a recent stream, I ran across something that I didn't quite understand with DotStars, and AT Maker's Bill went on a bit of an expedition to figure out the answer of what, you know, what I was coming across, basically, and shared what they found, so I really appreciate that to Dan H and anybody else who contributed anything to the new release, 720 Stable, and then lastly, I'll leave it with a group hug to everyone in the wonderful community, because I appreciate all of you. Thanks. Thank you. Next up, I have a note from Jerry, who's missing the meeting today, and he just has a group hug for everybody, and that brings us to Katni. Hello. So, I have a few hug reports today. One for Brent for reviewing some Adafruit IO MQTT code for me in cleaning it up a little. I've not dealt with MQTT before and had no idea what it should look like or what a couple of sections were doing. Brent moved a couple things around, added a few comments, and cleared all of that up. He also provided a link to a guide with MQTT explanations for me to read and link to on my example page, which was super helpful. To anecdote for giving me a place to start with troubleshooting, a very silent failure in some circuit Python code. It just hangs, I'll talk about later, with no error. So, I had no idea where to start and anecdote gave me an idea. And to lemon on the Python Discord server for providing me with some code and a ton of resources for a new project for me that will be a serious learning experience and for putting in the time to help me with it. So, thank you very much. That's what I've got. Thank you. And next is maker Melissa. Remember to unmute. Or would you like me to read it out for you? I'll just go ahead. Yeah, I'm sorry. I couldn't find the unmute button. We've all been there. Go ahead. I want to give everybody involved in getting circuit Python 7.2.0 out and a group hug to everyone who kept things going while I was out last week. Thank you. We missed having you around. Next, I have a note from Mark Gambler who is also missing the meeting today. And he has a hub report for Dan H for async.io. Finally had a chance to try async.io out and it made a project even easier to create. And then I have a couple more to read out for you. Tammy makes things, has a group hug to everyone for being awesome. And Tectric doesn't seem to be in the meeting. And they would like to thank Ketney for giving opportunities to work on library infrastructure. I'm already using my learnings like CI in my own projects. And a hug to anyone who worked on the release actions for libraries. Being able to build MPY files and attached to releases automatically is fantastic. A hug to Fomiguy for the insightful commentary while reviewing my PR on stream. A hug to anyone who's worked on Adafruit WSGI. It's by far my favorite library to tinker with and rounding out Hug Reports, a group hug. And that takes us to status updates. Like Hug Reports, it is held in a round robin and we invite you to let us know what you've been up to since the last time we've gotten together as well as what you plan to work on until we have a chance to meet again. And I will start the section and once again we'll go in the document order. So last week I wrote and released a guide about modifying a PC drive to read flippy disks with Flux Engine or Grease Weasel as well as Adafruit's upcoming Grease Weasel compatible board. I got an Apple II computer for floppy testing and I got my Apple II floppy drive moving its read-write head under the control of CircuitPython. This week I hope that I'll pick up some small CircuitPython work and I will be giving a talk called From Zero to CircuitPython this Saturday for the Devil in Linux users group and then apparently I stopped writing my status updates before I wrote the major item which is I'm continuing to work on the Apple II floppy world. I'm preparing a pull request for Flux Engine so that it can write Apple format floppies on a standard PC drive mechanism and I'm also continuing to work on the hardware interface for an Apple II disk II floppy drive so that it can be connected to Adafruit boards and work with Grease Weasel or Flux Engine host software. And as usual, that's probably going to end up taking the bulk of my time because there is a lot that I'm learning as I do all that. Then next up, I'm going to read you notes from SeaGrover. SeaGrover wrapped up two of three PCP projects. The final one is on hold needing some SMD featherwing sockets. SeaGrover was certain that there were more in the inventory. Also, modified two PiBedge LT's to expand their usefulness. They can support add-on featherwings now. Oh, that's where the SMD featherwing sockets went. Finally, got around to creating the circuit Python Atari Pump Console emulator I've been thinking about for a few years. The new class accepts the traditional oscillator frequency and one-shot pulse width input values and develops the resultant waveform on a PWM-capable output pin. Tests on an RP-20 feather dramatically outperform the original NE555 analog circuit and needed to be throttled back in order to stay in the range of human hearing. Should be relatively simple to admit and Euro RAC CV features. In the notes document, you can find a link to the GitHub repo and the SeaGrover's words, not mine, the annoying stereo demo reel. All right, and now, that's a lot. Next up is day on H. Okay, so as you mentioned several times already, I released circuit Python 7.2.0, which is the latest minor stable release that was on Thursday. I assume you've tried it, maybe some of you may have tried it. I'm preparing for the next alpha release of 7.3.0. I don't know exactly when that will be, but there's some stuff that needs to get moved around and set up for that. I've spent a lot of time in the past week working on various issues having to do with type annotation and typing and libraries for typing and fix some things, but there's still some things that are not quite working. Whenever we add some new type annotation, we used to have a version of circuit Python typing, or we still do have a version of circuit Python typing that's inside circuit Python itself, which was for generating documentation. I'm trying to use the new library that I created a few weeks ago. I'm trying to generalize some scripts that are inside the circuit Python build system so that we can add new types more easily. Some of these fixes are already merged and some of them are in process, piggybacking on at least one existing pull request. I'm learning a lot about doing typing and type annotations in Python. There have been a lot of changes. It's innovative of flux in the cPython world, as far as I can tell. If you have a lot of experience about this, let me know or put in your two cents. It's interesting. I've tried to get by not understanding it as well as I should, and now I need to understand it better. The other thing that I've been working on is an async.io HTTP client. I took the existing request library and made it async, and I've written the code, but I haven't tested it yet. Okay. Thank you, Dan. Next up is Foamy Guy. All right, thanks, Jeff. This one actually might have been two weeks ago, but I think I failed to mention it last week. I ran a cookie cutter for a new register spy library, so we already had the register library, which is, from what I understand, a higher level interface for working with the actual lower level data stream of I2C. That's what the existing register is. There was a PR at one point to add a similar interface for spy, but it was decided it would be better to spin it off into its own library. I ran the cookie cutter for that, and I set up an issue that kind of outlined my understanding of where it stands and what it needs, and I definitely am happy if there's anyone who can provide any more insight, especially if you have experience with the lower level drivers and especially spy is what this one is all pertaining to, which I don't have a lot of experience myself with, so open to input from anybody there. I made some improvements on the PyPortal Winamp project. Specifically, we can now support the PyPortal Titanum with its larger screen, and everything has been resized and looks all nice on that screen now. And then also added the ability for it to auto-generate the playlist by searching the SD card to find MP3 files, so if you don't feel like building out your playlist ahead of time and saving it, you can just run it and it will find at least files in the first couple of layers on the SD card. And then I updated the root certificate, which is inside of the NINA firmware, and then I also figured out how to make APR and CircuitPython to have it pull that latest update as well, and I made test builds and stuff to ensure that that was actually allowing our requests to succeed, and it seems like it has been, so that, I think, is pretty much set at this point, which gets us into this week. This morning I worked on updating the Web Telescope project, which was actually the original motivation for the whole certificate stuff from above, and so I've got that set up, and it appears to be working on the MagTag, potentially helping out with some new Discord bot functionality, and then I also need to circle back around on the GZIP PR. I think there's been a little bit of movement since the last time I looked at that, so I want to check in and see where we're at there and see if there's anything I can help with, and I'll be joining Scott to chat for a little bit on Deep Dive this Friday, and then taking over to do the Deep Dives Fridays following this week, so if folks are interested, you can watch on Friday, and I'll be on there to chat with Scott for a bit. Thanks. Thank you, foamy guy. Next up we go to Catney. Thanks, Jeff. All right, so last week I worked on more templates for both CircuitPython and Arduino for reading the LC709203, which is a battery monitor that's built into some of the newer feathers. Started a template for an Adafruit IO example for CircuitPython that does send and receive, which I didn't... the sending I didn't even know was a thing. And then ran into the Adafruit IO example hanging with no error. It just stops running, and there's no interaction with the serial console at that point. You can still get to CircuitPy and make changes and save them, but it doesn't reload. Once you hit the reset button, those changes that you made are still there, and the code runs again for x number of seconds and then hangs again. Anecdata suggested that the issue might be with the CPU temperature, the microcontroller.cpu.temperature, as apparently they ran into something with it on ESP32-S2. And to do this totally out of order, I just re-run the code with that line commented out and just using a hard-coded number. And it's still running. So apparently that was a good place to start because that's exactly where the problem is. I worked on an Arduino template page for using the built-in TFT on boards. We have a number of them with a built-in TFT, and we don't really have an Arduino page in those guides for how to just get some graphics set up going. I submitted some fixes to the Arduino ST7735, ST778998 library. I think it's actually 89. That's the graphics library for the TFTs that apply to that template. One of them was to make it work better on the TFT feather because the display is smaller than the others. There's what the other fixes are to move around the initialization so that it's all in the same order so that the explanation in the template actually makes sense because the template is in a certain order and it actually doesn't matter what order things are in, but the template is kind of immutable. The code is not, so I just updated where things got initialized. I updated the BNO055 circuit python page to not mention feather M0 because it no longer works with M0 boards and because there were wiring diagrams and references to M0, somebody bought a feather M0 specifically to use with this board and found out, sadly, that it doesn't work. So we shouldn't have an issue with that moving forward in various miscellaneous. This week, Troubleshoot, the Adafruit IOCPU temperature example hanging, I've at least determined that it is the CPU temperature that's causing the hang. The next step is to run it on a Metro ESP32-S2 and hook up a serial to USB with to the debug pin to see whether it actually gives me any useful information when it hangs. Finish the templates, finish the feather TFT guide, I need to write a guide for the feather ESP32 version 2, which, to be clear, does not support circuit python, but will include Arduino and micro-python if I can get micro-python going. There's a question in the forums that applies to the Bluefruit LE Connect Basics guide and I need to update the guide to have a reference to that question. The MCP23017 I-squared CG-PIO expander needs a guide. There's a new TFT that needs a guide. There's a VL53-BCD time-of-flight sensor, I think, is what it is. Needs a guide and we still need to do a template. I still need to do a template for async.io. And then, in my off time, I am working on a house Discord bot for the Adafruit Discord server, which the plan is to initially have a feature that flags when folks post code and it's not formatted or it's not formatted properly and post the message that says, hey, we see that you've posted code, it's not formatted, here's how you format it. It's something that's on the Python server, but it turns out it's not a standalone bot. It is part of a very large, very complex, very tied to the Python Discord server bot. And so I'm actually working with one of the server owners to figure out slimming everything down because just to get it going, I ended up with about half of it in my local repo and that was way more than even he expected that I would need. So I have to kind of tease things apart because there's a lot of stuff that they wrote specifically for themselves and some of them are cool features and I kind of want them, others of them are features that we don't need. So I have to go back, go 10 steps in and figure out what is it a dependency for and then figure out how to remove it. So this is really the first Python project I've ever worked on. Circuit Python obviously quite a bit, but I've not worked with C Python specifically yet and the whole thing is written in Python. So core features I have sort of an understanding of. There's some other stuff that Circuit Python doesn't support that is way outside my wheelhouse. So this is going to be a massive learning experience for me and so far it's been fun and I'm looking forward to getting that finished up. That's what I've got. I looked a little bit about that and there is a daunting amount of stuff there. So yeah, as you muscle through it you will be learning that's for sure. All right. Well, next up is Melissa. Hello. First of all, I wanted to give a late hug report for Raspberry Pi for turning 10 today. Also I wanted to for that and then for my status report for last week I was out pretty much already due to health issues so I didn't get much done but I did add the type annotations for the platform detect repo. This week I'm going to be catching up on stuff because of last week and also preparing to give a talk for the Dublin Linux developers this weekend. That's all I had. Thank you. Next I have notes from Tammy makes things who was on vacation for part of the week so didn't get as much time to work on things as I'd like. But last week I worked on the design of my circuit python library for representing and drawing decks of cards and I fixed my HDMI inputs so I can use my better camera for my Twitch screen. This week I'm planning to do one or two Twitch streams including tonight at 7 MST I assume as Mountain Time and either Thursday evening or on the weekend. I hope to set up a regular schedule for streaming and start implementing my card deck library and there's a link in the notes document to Tammy's Twitch which I think somebody's going to copy into the channel maybe. It's switch.tv slash Tammy makes things. And then on to the last item from status updates which is notes from Tectric. Last week finished my edge badge discord companion project added more effects to the display IO effects library in circuit python org and more type annotations. This week regrouping and finding out what's next. So that rounds out status reports and takes us to in the weeds. This is the time where we get to discuss those looming and amorphous problems and I will start by reading the item from Dexter who is not here in the text chat or here in the voice chat. Dexter suggests consider establishing a trail rating system for various development tasks. Correcting a typo would be a zero while porting to a new microprocessor would be a 10. I can speak a little bit more about this as well because I think this idea came out during my stream. We talked about this with a couple of folks that were watching. Please do. And it's basically like we have right now good first issue which is really good at helping folks find things that they are able to work on. So this is really the core of this at least in my mind is an extension of that idea of good first issue but raising it up to a couple of different higher skill levels. So 0 to 10 is one way we talked about it. Like 0 probably would match good first issue and 10 would be like probably pretty hard. It's something that you really need a lot of experience to try and tackle. Even if we had a fewer number of different ratings even if it was like a star rating or something zero stars to five stars or a smaller gradient of actual different ratings I think this might be a good thing to help folks who are still relatively new who might not necessarily know whether or not they're capable of tackling any given issue or PR. So the core idea is trying to come up with some relatively static rating system where issues in PRs can have this rating applied to them and it doesn't have to be 100% perfect, right? If somebody rates something to be a little bit harder or a little bit easier we're never going to be exactly on the money for everything because everyone has a different skill set as well. So it's kind of an individualized thing but basically a way to give folks a little bit more idea of like this is relatively easy or this is maybe a medium difficulty or maybe this is quite a difficult task that you really probably need more experience to dive into. Even if we just had a couple of buckets like that I think it would help folks find things that they might be more comfortable to try and tackle whereas today they might see an issue or a PR and they might have the ability to do it but they may not know actually what all is going to go into it or how difficult that is going to be for them. So that's kind of the idea it's like a rough rating system that tries to just expand upon good first issue a little bit and lay out a few more categories of good second issue or something like that like it requires a little bit more and then maybe a little bit higher would be a medium difficulty or a hard difficulty or something like that. I think originally we discussed this in the context of the core but I don't see any reason why a similar thing couldn't apply to libraries in other places as well truthfully. And I also don't think we need to necessarily do a massive sweep and apply ratings to everything that's existing it could even be something where like moving forward you take a stab at the rating whenever you create an issue or a PR or one of the early reviews could be adding a rating somebody else could come by and see it and add a rating. I will say probably the biggest technical challenge I think would be like where would we keep this rating and how would we represent it. So we have good first issue which is a GitHub label I don't know that we would necessarily want like more labels especially if we were going to go 0 to 10 but even if we had a smaller range I don't know if labels would be the best way possibly but I think that's probably the open technological question is like how could we actually do something like this and then of course you know the philosophical question of do we want to do something like this. I think I hit most of everything that's mostly what all we discussed I think during the stream so open to ideas from anybody else along those lines. Alright does anybody else have signs that they would like to say about this? Alright well thanks for me guy for letting us know what the context of what Dexter was talking about I don't know what else to say about it right now. I would say just reach out if anybody is watching this after the factor comes up with ideas after the fact I would say just reach out to Dexter and I on Discord you can ping us I hate to be in ping for Dexter but I imagine that they would want the heads up on that so yeah if anyone does end up having any ideas do that and it's just kind of an idea we're kicking around so I'm happy to lay it out and kind of get the thought out there into the community for now. You could also file an issue on the core with all of this information because you know Scott's not here and I agree it's an interesting concept but it does add a separate layer of work if you will but I think an issue to discuss it makes the most sense so that it's not just lost in the massive messages on Discord. Okay cool. Yeah I will try to put a more concise get written down in a more concise way and then get an issue created for it. Alright. Well with that I will move on to the other in the weeds topic which is from Mark who can't be here with us today but says if there is a broad agreement on the Zealot module names PR 6069 in the core I can start work to update that in the next couple of weeks this can always wait a week or for another time if it's easier to discuss them and I guess similar to what Catney was saying about the trail rating discussion probably the poor request is a better place to discuss that although if anybody has an opinion or knowledge off the top of their head about the state of that poor request we'd love to hear it for right now I don't know who's been reviewing on that PR. Yeah I've been involved a little bit I did some of the testing on it and I worked on the project where we first found the need for this I think this my guess is probably that Mark might have been looking for feedback from Scott more specifically I didn't talk to Mark about this this week so I could be incorrect but that's my hunch and I think where we're at on the PR is basically a module so we got this module from MicroPython and it contained kind of two different things one was just a decompressed method which you pass in the full sort of data to and it gives you back the fully decompressed data but there was also a stream type of API I think it called it DecompIO where it could wrap in a stream and just sort of decompress a certain amount of bytes at a time and then eventually if you put it in a loop you could get the whole data and I think where we're at on the PR is that stream concept does not really exist in Zlib the CPython module so my understanding is the desire is to try to match the CPython APIs where we can so since Zlib does exist in CPython we don't want to have part of our API that is different than CPython one so essentially we would get rid of or move the streaming portion of the API that exists to a different place and so there's kind of I think two main possibilities one of them is that it gets more heavily refactored and it gets put into I think is it GZIP there's another CPython module called GZIP which I think can act on streams like this I will say however the API is different it doesn't work the exact same way as the micro Python one did it would require some more substantial refactoring if we wanted it to get it to a state where it matches GZIP that's kind of one option is move it to there and refactor it to match the other option being choose a completely new module named for it that doesn't exist in CPython and therefore it is less of a problem that it doesn't match because it's not matching anything specific to CPython so I think what Mark is after is just input from folks on which one of those options we want to try to aim for and I will say to add to that I guess from my perspective I think that it would be good to get the Zlib.decompress method as is implemented into the core I would be happy to see that put in even if we lost the streaming API for now because that decompress method will help us with a project right we tend to do things based on the project and we have a project where our API is returning compressed data so having that function as it is does match CPython and would unblock that particular project to move forward so I would be happy to see that and then realistically I think I would probably be happy as well if the streaming portion of the API were moved to a new name because it sounds to me and all of the stuff is in the PR there so I don't want to speak for Mark but Mark has put in the PR some notes about this it sounds to me like maybe he is not necessarily going to be or maybe could not get to it for quite a while but is not necessarily interested in doing a more ol' refactor of it right now to try to make it match GZIP so I would lean towards either removing the streaming API altogether or moving it into its own module that is a new name that doesn't match CPython and sort of earmarking it to say you know down the line eventually we would like to refactor this to move into GZIP and to match the API there but currently it doesn't but it does work for what it does so it's worth providing that's kind of where I would lean towards is getting to recap just getting decompressed as is inside Zlib and then removing the streaming or moving it into a module with its own name which is part of what Mark has asked here is like I guess ideas for that name and there are a couple in the PR as well which I'll leave for folks that want to get over to the PR and follow the chain there I think that's probably a good overview on where that's at and what the question more specifically is about that Mark put in here Alright, thank you and belated hug report to FOMI guys for being on top of seemingly everything every issue and every pro request in the system or at least those that need to be talked about and that concludes the in the weeds topics for today and so I will wrap up the meeting once I get to my notes this has been the circuit python weekly meeting for the 28th of February 2022 thank you to everyone who participated live if you want to support Adafruit and circuit python and those of us that work on circuit python consider purchasing from the 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 major podcast services it will also be featured in the python controller's newsletter visit adafruitdaily.com to subscribe the next meeting will be held next Monday as usual at 2pm eastern and 11am pacific that will be March 7th the meeting is held on the adafruit discord which you can join anytime by going to adafruit.it slash discord to be notified about new about the meeting and any changes to the time or day you can ask to be added to the circuit python easter's roll on discord and with that I just want to say see you all next week and thanks again everybody thanks everyone