 Hello, everyone, and welcome to the CircuitPython Weekly Meeting for April 19th, 2021. It's the time of the week where we get together to talk about all things CircuitPython. I'm Jeff, and Adafruit sponsors me to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it-discord. We hold the meeting in the CircuitPython dev text channel and the CircuitPython voice channel. This meeting typically happens on Mondays at 12pm Eastern, 11am Pacific, except when it coincides with a U.S. holiday. If the meeting time is changed, we'll notify you via Discord. If you want to be notified about changes in the meeting, we can add you to the CircuitPython East as Discord role. There's also a calendar available that we keep updated if you'd like to subscribe to that. The URL is in the notes document. And I think our next deviation from schedule is until the end of May, so no worries on that score. This meeting is recorded. We take the audio from the voice channel and the video from the text channel. If you'd rather not have your voice recorded, you're still welcome to participate. The video will be posted to YouTube and the audio only version released as a podcast. If you find we're not available on your favorite podcast service, please let us know. As I mentioned before, there is a notes document to accompany this meeting and recording. That's where you can leave your hug reports and status updates. If you can't make it to the meeting, we'll read them off for you. The notes document contains timestamps to go along with the video so you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so it's great to have the option to skip around. A link to the notes document is posted in the CircuitPythonDev channel on the Adafrit Discord every week. Check the pin messages to find the latest note doc. If you're watching us on YouTube, scroll down for the link to that. All right, the meeting structure. This meeting is held in five parts. The first is community news and a preview of the Python on Microcontrollers newsletter. The second part is the state of CircuitPython, the libraries, and Blinka, which is a statistical overview of the entire project. A chance to look at the project by the numbers as it were. The third part is hug reports. The first of the round robin sections is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community and beyond. The fourth part is status updates. It's an opportunity to sync up on what we've all been doing. We invite you to take a couple of minutes to talk about what you did over the last week or so since the last time you joined us and what you'll be up to until next time. And then the final part is in the weeds, an opportunity for long form discussions. These discussions can be a topic identified during status updates or something you've identified ahead of time as too long for status updates. And that covers how we'll go. I will head back over to the notes so I can tell you community news. And Fummy Guy, I hope you can get the links today. I really appreciate it when you are able to do that. Big landmark, big milestone, not landmark. CircuitPython is now available for 200 boards, a number which may have increased by now, I'm not sure. The slide trinky based on the SAMD 21 is board number 200. CircuitPython is available in 15 different languages and is one of the easiest ways to program microcontrollers. We began with the Circuit Playground Express approximately three years ago and reached 100 boards in January 2020 with the Open Hardware Summit badge. Now a year later we've reached 200 boards. Chips supported include Espressif, Microchips SAMDs, Nordic, NXP, RP2040s ST, and more. A big thank you to everyone in our community who has submitted boards to CircuitPython. And there's blog link, CircuitPython.org website, all sorts of good stuff. Speaking of good stuff, Scott's presentation from the Open Hardware Summit 2021 is now on YouTube. The title I think is Interface Design in Open Source Hardware and Software. I need to watch that one myself and I've got time tomorrow that I'm planning to do that. You can also check out the whole Open Hardware Summit broadcast on YouTube. Next up we've got projects. The River Prairie Troll projects use the CircuitPython, among other things, to create an interactive art installation. The Pico 8 encoders, LOL, you can hook up eight rotary encoders with switches to a Raspberry Pi Pico without any extra hardware. And it's also supported by CircuitPython. Next up, Plan CO2, making a public display of CO2 levels from Makezine. Last up, enhancing the Pimeroni and Viroplus Featherwing plotter to plot CO2 parts per million from the Adafruit SCD-30 NDIR sensor, and that is a link on YouTube. And I'm not sure who's behind that one, but check out that link for sure. The CircuitPython Weekly Newsletter is a community-run newsletter emailed every Tuesday. The complete archives are on adafruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware related news from around the web, including CircuitPython, Python, and MicroPython developments. So because this is a community-run newsletter, we invite you to contribute your own news or project. You can edit next week's draft on GitHub and submit a poll request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. And your own project, your friend's project, your dog's project, we want everything and anything. And with that, I will move on to the state of CircuitPython, the libraries, and BlinkUp. Just a reminder that two or three weeks ago we had a fix to our statistics, and hopefully now we are not missing some of those authors, particularly on poll request activity. This week we are reporting 54 poll requests merged from 30 authors and 14 reviewers. And issues-wise, we had 22 closed issues by 13 people and 27 opened by 23 people. So I mean, first, it's really exciting that we, of course, authors, reviewers, and people active on issues overlap, but, you know, we're getting well into that three dozen people active weekly to help us improve CircuitPython, and that is just really awe-inspiring. Some new names among the authors that I don't recognize are Mick Glenn, Stone Hippo, David Lee Dom, Dee Jeckon, and Scott Monahan. Some of those may have appeared before, but they're less familiar to me. But we appreciate every one of you. And as to the reviewers, it's your review that makes things go smoothly and lets us merge in high-quality poll requests. And yeah, we need all sides to keep things going. And with that, I will pass things on to Scott to tell us about the core. Awesome. Thank you, Jeff. Sorry, I was too busy rolling my eyes at a post on the Raspberry Pi forums. Oh, no. Okay. So for the core, we had 18 poll requests merged from 17 different authors. So thank you to all of our authors. So new names I just want to say thank you to are Stone Hippo, Zodius Infuser. Wow, so many of these names I do recognize. So thank you to those folks. Thank you to the four reviewers. And also thank you to Naridoc for getting this list fixed up last week again. We have 25 open poll requests. A couple of those are quite old. So again, as always, please take a look at those. If folks need something to help out with or want to help out with something, picking up old poll requests is very, very helpful. There's good stuff in these poll requests, and it's sad to see them not get fully merged in. Issues-wise, we had seven closed issues by five people and 12 open by 10 people. So we're up for a total of 427 open issues, which you can see at github.com.com. We have five active milestones and two issues not assigned to milestones. So that's how we triage issues. So we're generally on top of things, and we'll take a look at that later. We have 56 open issues for 7.0, so we're going to have to take a hard look at that list over the next few weeks slash month or two as we work on the 7.0 stable release. Overall, I'd say core work is going well. 6.2 has been stable and 7.x is well underway. Now is kind of the time before we do any 7.0 releases for us to change stuff. So expect to see some bigger changes happening before we get to that first alpha or beta. We hit 200 boards and continue to add more. So we may also want to consider a 6.2.1 backport of the new board desks. If the 7.0 unstable pre-release will be either quite unstable or a long ways away. So we may want to do that too. Anyway, really good. So thanks. Yeah, I think that's really a great idea because we do have a bunch of exciting boards coming out. And typically it's a pretty easy process that just involves copying a couple of files from the main branch into the 6.2 branch. So if that sounds like something that you would be up for, let one of us know and we'll show you how to do that. Yeah, I'm kicking myself that we didn't do those on the 6.2 branch actually. Because if we did them on the 6.2 branch, we can merge the 6.2 branch back into the main one. Going the opposite direction is not really feasible. So we'll end up having like two sets of commits for each thing. Yeah, but that's not a big deal. Commits are free. They're just numbers. Well said. I've been on the receiving end of a similar sentiment. Or I've discharged out a similar sentiment. Well anyway, next we'll pass things to Katnita to tell us about the libraries. Thanks, Jeff. So this section is about all of the Circuit Python libraries, including the Adafruit Circuit Python libraries, a couple of extras like cookie cutter, and also including the community bundle. So we had across all of that 35 pull requests merged from 16 authors and 14 reviewers. And I want to point out two review names that one of them is J Edgar Park who works with Adafruit but has not popped up on our review list previously very often. And the real Fenrir is new as a reviewer as well. And K-Match 98 I haven't seen very often as a reviewer. And so I wanted to specifically thank those folks because like we keep saying reviewing keeps the process moving. And it's not, it's one of those things where, you know, we want to see new people get into it. So I wanted to thank specifically our reviewers versus where we usually are thanking our authors. Leaving us with 53 open pull requests. We had 13 closed issues by 11 people and 12 open by 12 people, leaving us with 330 open issues. You can find all this information and more at circuitpython.org slash contributing. And if you're looking to contribute to Circuit Python on the Python side of things, contributing to the libraries is a great way to start. You can check out the open pull requests and see if anything you can start reviewing there and see just make a comment. If you check out syntax or you find a typo or if you have the hardware test the PR and leave a comment that you did that. That's usually how we suggest to get start reviewing the libraries is to just do that sort of thing and leave a comment. And then eventually we can level you up to actually joining our review team. There's also a list of open issues which you can search by label. Good first issue is a great place to start if you're new to contributing overall. And if you're looking for something a little more complicated bug or enhancement is an excellent search label. We have a guide on contributing to get and GitHub or contributing to Circuit Python using get and GitHub. So if you're new to all of that, don't let that intimidate you. And we're always available on Discord to answer questions. We want you to be able to contribute in a way that works for you. And we are happy to help make that happen. There were no new libraries in the last seven days. And we had a number of updated libraries which I will not read off overall. Although I will point out we have had more updates to the community bundle. Overall, I'm still super pleased to see older PRs being picked up. We had one that was 265 days old that got merged. As well, I'm very excited about all of the updates being made to the libraries through new PRs. Early hug report to everyone who is submitting PRs to the libraries. As always, if you're waiting for us on something in a current PR, please ping us and we'll try to circle back to it as soon as possible. Otherwise, it's worth looking at some of these older PRs and deciding what we want to do with them. But for example, the absolute oldest PR is still active. So the ones between that and the new ones, it may be worth taking a look at them and see whether the original author is still interested in merging it, see whether it can be picked up. And as Scott says about the core, in terms of the Python side of things, that is an excellent way to help as well as to pick up an older PR and get it ready to go with the newer code. And that's where we are at the libraries. Thank you, Kat. And with that, it's time for Melissa to give us the Blinka stats. Hello. For Blinka, we had this week we had one pull request merged by one author and one reviewer. There are seven open pull requests at the moment and that's between all the different Blinka related repos. There were two closed issues by two people and three open by three people, leaving a net of 57 open issues. There were 6,803 Pi PI downloads in the last week, and we are currently supporting 72 boards. Overall, there has been much movement on the Blinka side, but I'd love to see more contributors. Well, I do feel like the number of weekly downloads kind of inches up, so it's good to see that happening. I see it all over the place to be honest. Is it? Okay. I was thinking, oh, I feel like, you know, it used to be 2000 and maybe it's just super high this week or something. Well, yeah, it is pretty high this week, actually. I mean, I've seen it down in the hundreds too, so I'm not sure what affects it. Yeah, probably how much CI we're doing because those will each download Blinka, right? Yeah. Anyway, all right, it's time to move on to hug reports. As an element of positivity in the world, we like to say thank you to one another for good stuff that we're doing or good stuff that they are doing. So to show you how it's done, I will begin and then I will pass it to Jerry and on down the alphabet. So first, a hug report to Dan for briefly being a sounding board about a problem I was having on the SamD51, although I was asking the wrong question. Another hug to paint your dragon, Phil B for excellent code to study for the OB7670 camera and SamD51's parallel capture interface. On a more personal note, GitHub users Joe Callier and Howoff for recently contributing to a desktop Python project of mine to ask Patrick W. For updating circups so that it works with 7.x, although you do have to install the version from Git for now and a preemptive hug release hug release hug report. I'm going to be working on my first Adafruit bundle circuit Python library this week and I know I will be asking for help to get that ready. So thanks to whoever's going to help me out on that. With that, I will pass it to Jerry and then read notes from Jose David. Oh, thanks. So just a hug to Kmatch for the memory guide. Nice. And a group hug to everybody. All right. So, next up after Jose David's notes is Catney. But Jose David writes a hug to Kmatch for the second contribution to my aero library as well as the new memory saving learning guide and a hug to anecdote it for testing my silly solution. Next up, Catney and after that Kmatch. All right, so first up I have two hugs for Naradoc the first one for manually updating the back end of circuit python.org slash downloads to remove the 6.2.0 release candidate link that was still available. And for making for updating the script that generates all of that to make sure that that doesn't happen again in the future. As it stood, when we made a stable release, if there was no higher numbered unstable release, it would continue to show on circuit python.org the previous unstable release as the, you know, latest unstable release and that was obviously confusing. And so Naradoc updated the script that generates all of that so that in the future that won't happen. However, the site was already generated with 6.2.0 release candidate zero or release candidate one or whatever it was. And so there was, I believe a JSON file that needed to have a reference. Yes. And I was talking with our internal person Justin about it and Justin's like, I don't even I've never edited the file like this this seems crazy and Naradoc's like I have a PR for you and so that was perfect. It was amazing. Thank you so much for doing that. We could have waited until we had another unstable release and then just dealt with it in the future, but that's now taking care of and so the huge huge huge hug report for that as well. A hug report to Naradoc forgetting the module filtering or forgetting module filtering going on the board support matrix. To Jose David for the flurry of documentation updates to K match for his first guide, which was on circuit python memory to everyone who helped us get to 200 boards on circuit python.org and unrelated to circuit python. Hug report to the ingenuity team at NASA for a successful first flight on Mars. All right. Yeah, I haven't gone reading the news coverage of the test of the flight because I know I just fall in and not come out all day so after after I'm done for the day. All right, K match is next and then maker Melissa. Okay, thanks Jeff. So first off, thanks to Jose David for the arrow library, which is easy way of drawing arrows pointing at things. And I guess I'd like to amplify all the hugs I received on learn guide and pass some of my own out first to cat me and Justin for help in figuring out how to write a learn guide, and they give me some pointers and fixes to get that get that done. Also, a big thanks to everybody who contributed some ideas to go into that. Specifically, I'll call it David cloud indico and purple samurai. And there was a community member that made a comment. I don't know how to figure out who they were but thanks for that one, particularly related about samd 21 boards which got incorporated yesterday. The, the system for making the guides is really easy to use so thanks to everybody who who designed that so I'm sure a ton of work that went in to making that so so easy to operate and for me to figure out. And last off, for to film a guy for taking the big first step of initiating the move of all the display oh library specifically the widgets into the new GitHub circuit Python organization. Thank you. And yeah, congratulations on that first learn guide I haven't actually read it yet. All right, next up is maker Melissa and then Mark if he's here to read his notes. Could you come back to me I seem to have lost the guy or the document. Yeah, that's fine Mark are you ready to go or do you want me to read them. I can read Mark, who just has a group hug. And, Melissa, did you find your place. I did. Okay, go ahead. Okay. So this, I want to give a hug report to cat me for starting the fund has product guide. I report to Dan Halbert for contributing to blinker and no way for adding the feather RP 2040 to the matrix portal library and group hugged everyone else. All right, Scott you're up next without adequate notice and then after that I have notes from attic data. I got you. Hug report again to came out for the memory saving guide. Hug report to AJS 256 who suggested a fix on one of my PRs that had failed CI it's always nice to see that folks are looking at what I'm doing and it's extra helpful to suggest a fix so thank you. And then hug report to T omich for the queue string space saving PR. That was really neat. So thanks to them. Alright, thanks Scott. I have notes from attic data and then it's off to ask Patrick. So attic data has a hug for narrow dock for testing a small PR I didn't have the board for after Patrick is Dan. But go ahead Patrick if you're here. You're not all right. Patrick has a hug report for Jim Bennett for his help on the Azure IoT library. It's always great to see Microsoft contributing. Alright, Dan is up and then I have notes from David. So thanks to Jose David for tackling a number of libraries and adding better simple example documentation and also fixing a bunch of other things about the documentation and number of those libraries. And thanks to narrow dock for the sort of pipeline improvements that we talked about already and also for the the read the docs dynamic filtering by existing by existing modules in any particular board you can say which boards have such and such a module and it'll it'll narrow it down it's wonderful. Alright, after the notes from David, it will be foamy guy. But first David has a hug for Bill Bingo, known as AT Makers Bill for progressing on the BLE HID to multiple hosts to Chris Young and Bill Bingo for the QT pie hat and the IOT IR learn guide. A hug to K match for the memory saving learn guide and fixing bitmap saver. And last a hug to Kevin Jay Walters for more contribution to the environment plus feather wing and the addition of the CO2 data from sensorion the SCD 30 and hand it to foamy guy and then after that is higher effect. Alright, thanks Jeff. First up hug to K match for the memory saving guide. And a really nice tips in there for measuring and saving memory to lay samurai for pay for help with some sphinx syntax that I was fighting during the stream over the weekend and probably some other folks unfortunately that I may have forgotten who helped me out during that stream. I appreciate all of you to Hugo for working on the vertical progress bar and refactoring a big refactor in the progress bar library. And then lastly to Jerry in who has continued to dig into a weird issue with the, I think this is the right one SMTP S 10 touchscreen driver that does some weird stuff when the device resets Jerry has narrowed that down quite a bit to figure out a reliable way to repeat the issue. So, thank you for that. And that's all for me. Thanks. Thank you. All right, next is her effect and then Hugo gets to wrap it up today. Alrighty, just a thank you to Dan for his continued help on the deep sleep stuff and a group of everyone else. All right, Hugo, take it away. All right, first of all, a bug to host a David for walking me through how to create a whole request or actually getting reviews on a full reviewers on a full request to K matching phone guy further testing of the progress bar over time as I worked on it and updated the pull request and then group house. All right, thank you. Next up is status updates. The time for you to let us know about what you've been working on recently and what you plan to be working on in the near future. It's around Robin the same as hug reports, and I will start it off. So last week I spent a pretty good chunk of time on the I2S out on the IMX RT 10 XX series, but I never had any success in getting the waveforms to come out. So I'm setting that aside for a bit. And instead I started on support for OB 7670, which is a digital camera and the parallel capture device of the same 51 microcontroller. And I've already been able to capture an image with circuit Python and display it with display IO, which is pretty good progress. So this week, there were some things in the I2S out branch that I should separate out and PR in their own right. I don't remember exactly what those were, but I don't want them to get lost forever. I am going to polish the circuit Python library for configuring the OB 7670 camera and also get this core module ready for inclusion. You need both halves before you can use the camera itself. And then I had written, well, anyway, I need to change this next item. And I also implemented a new kind of color conversion for display IO so that if the format of a bitmap in memory is RGB 565 RGB 555 or either of those with the two bytes swapped that the color converter object can fix that for you and display your bitmap. That will go in and be PR with the rest of the stuff for supporting cameras. If I get beyond all of that, the next task is to work on support for a different digital camera module, actually one from ESP, but we're still going to be testing it on the Grand Central. So getting a second camera module to work is next up after all those items. My second coded vaccination is later today. And so my activity this week may be reduced if I have side effects from that. All right, Jerry is up next and then I will read the notes from Jose David. Thanks, Jeff. So yeah, so I've been spent a lot of time this week playing with this STMP 610 issue. And it's, I'm really baffled by it, but making some some product learning a lot anyway. And so the, you know, the basic issue is that, and it only happens on the RP 2040. In fact, I've only been testing with the feather RP 2040, but I suspect it's common to RP 2040s. And if you're using display as well. So if you have a touchscreen, like I've been working with the 2.4 inch feather wing PFT. There's a funny issue that if you when you power up and you run something, the little test program of running, it comes up fine on power up or a hard reset. But if you do a software reset after that, every other time it will fail. It'll it'll say that it can't detect the board because it can't read the version ID. So if you just do another control D and other software reboot, it detects it fine, then it alternates every other time. And I'm just not making any progress understanding why that would be. So I'm, yeah. When you start the driver does it do a reset. Is it possible there needs to be a wave while it resets before you try to read the version ID. So I've tried putting it does do a reset. Well, actually, it doesn't do a reset until after it's determined the version ID. So it actually does one later, and I've tried adding delays in. And, and so I'm thinking this is a circuit Python issue and not a driver issue is where I'm headed. And so I'm tempted if it's if there's no objection to opening an issue referencing this ongoing issue in in circuit Python. My reason for thinking it's circuit Python related is a that it only happens on the RP 2040. And, right. If I, and it has something to do with display IO, if I if I run just a simple test for the STMP, that works fine. And the same piece extent is a weird board because it has this very strange way of determining which SPI mode to be in. And actually I have two different to different either a keyboard feather wing, and it comes up in mode zero, where the TFT feather wing comes up in mode one. And I think I maybe understand why but I'm not convinced. It's, it's always been that way in that driver and there's some notes about it the same way in the Arduino driver that you really can't be sure what you can, which mode you're going to get. But the key is if I, if I, if I release the displays manually at the REPL before doing a control D, everything works fine every time there's no alternate it'll always work fine. So the code that runs the code up to why the first thing it does released displays. So I don't, I don't understand that at all. So I've got to probably park too much detail first that I support but so there's an issue out there. Again, if there's, I guess, but I wanted to check was, do you have any objection to my moving this to a circuit Python issue. No objective for me, it makes sense. I'll do that sometime the next day or two just to, and again I'm trying to narrow it down. And then I've been, I've been using the logic analyzer and all that stuff, but it all of this confirms that it reads the wrong values and it began there's there's something going on there it's reading the information is there just getting things out of order it looks it's getting extras reading in the way. So something's just very funny in the SPI configuration. So fun stuff was though I don't know if any others got chance to watch it this morning but the first flight of ingenuity was really pretty impressive. The helicopter on Mars was really fun to be able to watch that broadcast and watching all these very young engineers get so excited when this very simple little line plot appeared on their screens. You know, the altitude of the helicopter, but it was it was kind of fun to watch this, you know, really, something that could have been created by by me was was the defining moment of the morning, really fun to watch. All right, well now I need to know how they measure altitude on Mars do you know is it barometric pressure like the kind of sensors that we have from it a fruit or some other technology. I don't know how they did it. Again, given the very low pressure. You know, I don't think it was a BME 680 but I suppose I don't know that's a good question or something. Yeah, it would be interesting to know. Yeah. All right, well we better move on as interesting as ingenuity is I have notes from Jose David and then I will pass it to catney. So finish up your notes catney. Okay, Jose David writes that this week libraries documentation and the earth and moon animation in circuit Python vectorial and next week library documentation and an analog clock on circuit Python. After catney I will pass things to K match. My notes have been done for a bit. Oh, it looked like somebody was typing in there. Nope. Okay. Um, so published another new let's see last week published another newsletter. I wrote a read me for the new learn system project bundle, explaining quickly how to use the project bundle. And then passed it on to Justin to make sure that it includes a link to the guy that it was downloaded from and the date. So when you click that download project bundle button above the code in a in a project guide a circuit Python project guide. And it will include a read me with a quick explanation of what's going on there. And a link to where it was downloaded from so you don't lose. So you don't, you don't lose what you were working on, because it will be named code dot pi. And not, you know, led snowboard dot pi anymore so you would want to know where you grabbed it from without checking the code. And that's a tricky guide which includes templates. Finally, I say finally because I've been writing these templates for weeks and haven't actually made any of them live. This is an example of neopix link is is a template. It shouldn't, it doesn't look any different than any other learn page. But all I had to do is add two things to it, instead of having to type all of that out or copy and paste all of that into the guide. So that's exciting for me. I updated the ht u 21f and sh t 31d guides for the stomach qt revisions and I started the fund house guide. So this week, another newsletter, I need to blog those two guide updates. I'm looking into getting an aggregated list of all the circuit Python libraries, including the ate a fruit and community bundles I will be talking to Jose David about this on Tuesday. Because apparently some work has already been done with that. We're going to have it live on the circuit Python org and GitHub. And that's going to be convenient for me because we add that number to the newsletter every week I have the number to the newsletter every week and I manually come up with it by counting the number of sub modules in the community bundle and adding it to the number that we have on the list for the ate a fruit bundle, which is goofy because if we're counting all of them we should really aggregate all of them. So I'm going to be looking into getting that going. And then working on the QT PI RP 2040 guide, and then working on templates that are specific to QT PI RP 2040 and a sense of medium zero as well. So that I can get them into that guide. And I will also be creating a template for installing circuit Python onto RP 2040 boards, because there's very little difference between the boards. And that will be convenient to because every time we create a new RP 2040 board we just put this template page in there and you don't have to worry about pasting all the same stuff and repeatedly which is what we do right now. So that's where I'm at. Alright, thank you. Carter says I think the altitude is via LiDAR. So anyway, we have came out and then maker Melissa. So go ahead. So last week I added to the display. I owe animation library to added some color morphing functions, in addition to the translation functions that were that were already in there. And I use that as part of the new learn guide, which has been mentioned above but there's a link there if anybody wants to take a look. I want to try out the new circuit Python graphics org and push the animation repo up there. See if I can figure out how to do that. Next I want to review the slider widget from Jose David, which looks really cool and it uses a new feature to be added to widgets. So I'm basically going to slide your finger around while it's touched. So I'll get to try that out. And then the next thing, something I've been trying to avoid so I can get other stuff done, but I think it's been sitting on my desk too long now. I've got a teensy 4.1. So I want to see how that behaves on circuit Python since it should be super, super duper fast. So I'm eager to try that. And then last main thing I've been working on is in C with the logic analyzer project to see if we can get good integration between sig rock, which has a viewer for logic signals along with a different boards. So that's where I'm spending most of my time this week. Thanks. All right. Thank you. Next we have maker Melissa and then I will read Mark's notes unless he lets me know otherwise. Go ahead, Melissa. Last week I almost finished the fun house and home assistant guide but need a product guide pages. So I worked on the fun house product guide. And during that I learned about making templates and template pages and they different learn guides like cat name is explaining and I added a few more boards to circuit python.org so that brought us up to 200. This week I'm going to finish up both those guides and play catch up on some good ambition and then possibly get back to updating the VS code extension. That's it. All right. After I read Mark's notes, we will go to Tanute. But Mark says, I need to look at issues slash PRs for something else to work on suggestions welcome and getting the vaccine Wednesday. And after Scott, I think I have notes from my anecdote, but I'm not sure. No, after Scott, it'll be Dan. Hello, I finished the demo code for the BLE file transfer protocol it added offsets and padded values so that they align. I got that working but the PR itself is still failing CI so I've got to take a look at that. I found a bug with struct in the core that I've got a fix. And again that PR but it's failing as well so I've got to get that in. And that's that struct packing fixes a prerequisite for that BLE stuff so that that's top of my list today. I enhanced the get have actions for libraries in the court to better have errors and help solve them. I think maybe I talked about that last week. Dylan's coming in going so are not exactly sure when that will roll out but it's not super urgent. So Dylan will do that when he has time. Last Friday I started the status LED change and we'll finish it at the start of this week as well. We're very much in this mode that doesn't come up very often where we're between major versions, like we've finished 62 and we're kind of sticking there but the next thing we're going to do is a 7.0. So this doesn't come up very often so status LED changes is one thing I want to do. We basically want to hit all of the breaking stuff really early so people can. So we can do it early and make sure it's all stable and in that regard, I was planning on doing the moving the BLE file transfer stuff into the core but I'm actually prioritizing merging in micro Python 115 which is released in the last few days. Because we're in this like rare window of moving between versions so that will mean that the MP why version will change so heads up early heads up for that but I'm going to take a week and see how far I get hoping, hoping to get far enough that it that it'll be worth it to finish the merge so thanks to Dan for doing that prerequisite work as well. Alright, thank you Scott heading back up to the top of the list. It is Dan and then after that I will be nuts from David. Okay, so I've been working continuing working on dynamic USB descriptors. I think I'm not sure if I said last week but the API is largely designed and documented. And I was working. We currently have a some Python code that generates the descriptors and I was changing it so it output more information so I could change things at runtime, but it's just kind of getting out of hand. It's a very general approach and we don't really need it because each different kind of descriptor except for HID descriptors is different and involves different fix ups and is composed in a different way. So I was starting to make the script output a bunch of stuff that I would use later in the C code and I think I'm just going to take our existing descriptors in their hex format form and just write a little bit of custom code for each one and I think it'll end up being smaller, which is important because we want to get this to fit on the smallest boards. Another thing that's happened is that has been true for several months now we have so many contributions from the country from the community that there's just a ton of reviews to do and that occupies a time but it's really good because it produces a new code that's that's feature full and everything like that. Okay. After I read David's notes, Foamy Guy will be up next. So David says I gave my CPX to a friend after showing off all my gear and telling him about Circuit Python and made a list of advice and learn guide links to get him started with the Circuit Python Express and Circuit Python and a discussion with Bill Binko on his multi BLE keyboard project. David, I hope you'll share your list of learn guide links because because that would be great. It's good to see what other people prioritize and I found most helpful. So I'll pass it to Foamy Guy and then after that higher effect. Alright, thanks Jeff. Last week was testing out the new progress bar style vertical progress bars as well as the new examples that are in that repo. And then I started creating the new repositories for the display widgets in the Circuit Python org. And I probably am forgetting a few things for last week. I didn't fill it out as I went. So that's all I got there for next week though. I'll keep going with those new widget repos and I'm going to try to look into PyPy and read the docs getting those set up. I have a topic down in the weeds to discuss that a little more. I'm going to update some well pretty much anything in the learn guide repo that uses progress bar so that it can get the new importing syntax so that we'll be ready to merge that progress bar update. I'm going to look into a change that somebody a user of the stream deck had asked about was having a way to make icons be able to change layers and then also possibly trying to make another sort of level of organization where you can have multiple layers in a group or I guess folders maybe is what they call this on the real stream deck project. And then you can move between those layers that are within that group or you could change over to an entirely different group. So like being able to put your layers together and bounce around like that. And then lastly the other thing I'm going to look at this week is retesting the TLC 59 7 11 LED multiplexer. That's the that's the old oldest PR that's out there and I've tested that a few times and I've got the circuit all built put away somewhere. So to get to get back out and try that out again to see if I can get that get that work in the user working on it said that they tested it with some made of root boards and got it going whereas I could not last time I tried it so see if I did anything wonky there and try to get that up and running this week. And that's all I got. Thank you up next is her effect and then Hugo will finish things up. Okay, so this past week, I rewrote the internal structure of the alarm module so that things are easier to follow and maintain. Those internal changes started with the SP 32 s to and once kind of the first drafts of the nrf and SCM 32 ports are in. I'll hopefully be able to get in there and similar changes just so that they're all on the same page. Basically I was just making it so that light sleep and deep sleep processes aren't overlapping so much when they don't actually share code. Fixed I fixed a bug on the SP 32 s to where the return to alarm objects don't match each other. I got set up with the RP 2040 using the J link so that gdb I have gdb debugging and some basic control tests available as I work on the RP 2040 sleep functionality so I've been starting up on the GC RTC and GPIO. Wake up functions and I'm working on deep sleep for that first. I also moved back to Boston which ate up a little bit of time but that's all done now so this week I'll just be doing more RP 2040 sleep stuff and some other supervisor work that I've been talking about but haven't been able to get to and that's it for me. All right, thank you. And in case anybody's wondering supervisor is a technical term for part of the core C code it's not telling the other programmers what to do right. Sorry. All right, moving on to Hugo to wrap up this section. What's new. All right, so last week I did all the final last changes and tweaks to the progress bars. Examples I created a few more and started working on the D branding or branding of the Python builds that each group that builds their own can brand it as appropriate to keep circuit Python. So this week I will be working on that branding get a first pass going for review I'm hoping and in non tech or personal stuff. Getting my second job Wednesday in the morning so rush hour long drive podcast o'clock. Right, just one random connection. Dan had been talking about this patch that went into you for recognizing boards based on the USB descriptor. And it's possible that this D branding of circuit Python would break that so it might be worth touching base and seeing how we can make sure that works best. And Scott, were you going to step in and say something. Yeah, I just wanted to. I want to make it clear that my my goal with this work is not to make it so that the Adafruit centric one is is call that well my goal is that like wherever the core circuit Python repo is that that we all work on is what gets the circuit Python name I know right now that's like kind of the same thing as Adafruit but in the future. I hope it's not so I just want to make it clear that like my goal is that we very clearly support and brands. The versions of circuit Python that come from kind of the quote unquote official repo and the official CI. But I want to try to make it clear that like I don't assume that that's a Adafruit only in the long run like it really should be bigger than that. Yeah, that's fine distinction but very important. Yeah, yeah, and hopefully it'll become clearer over time. So thank you for doing that I really appreciate it. All right, well we already got in the weeds just a little bit there but now we are officially in the weeds. And the first topic I have has been contributed by Patrick but they're missing the meeting so I will be reading it. So it is a potential list of candidate repos to move into the circuit Python GitHub organization. I'll read these off as they are right now but people are encouraged to add to the list if you like we'll finalize this soon after the meeting. So awesome circuit Python. Sir cop the cookie cutter library repo the not Adafruit dot IO IOT libraries which could include Azure IOT AWS IOT and GC IOT core. The community bundle circuit Python org and the we accessories other than the nunchuck I think is what is being typed right now. Pardon me so Scott do you want to say a little bit about this because I think you are kind of driving this idea right now. Yeah, I think it's really good I think I just need to run these by filling the war I just don't want to I don't want to surprise them when we move things out of that out from under Adafruit so I think these are all good ideas. I just think I want to double check with them about it because no it is a balance between highlighting the things that are Adafruit funded and supported and the things that kind of we just put there because they were. I think the community bundle is definitely one of the things I highlighted it's just I want like it's tricky I want to make sure like some somebody needs to before we move it we need to make sure that like any instrumentation or other tooling that we have around it can handle it if it's in a different place. So yeah I think there I think those are good suggestions. I think I'll I'll take an action item or I'll I'll take this list and just start an email thread with film the more and say like are you okay with this. And then I can report back next week or or you'll just see them move over so yeah I'm. I think those are all good ideas I think. Yeah, awesome circuit by them might have problems just because they it might be linked to from elsewhere. I think there's a transfer a repo from, well at least from a user to an organization GitHub will forward it until yeah that's back into your into your organization or user so I'm not super worried about that but definitely it's something that you can verify and get have documentation will work how you want. Yeah, so I got I did get the OK for the circuit or for the community bundle already so it's just it just needs somebody to make sure that we're not going to break everything if we move it. Yeah, the tooling is almost the biggest. Well I mean there's the human part in the tooling part so thanks for helping us navigate all of that. And I'm happy that people are excited about this I think I'm very excited about it too it's it's I think a realization that we have stuff that really belongs outside of belongs to circuit Python more broadly than just data fruit so I think it's good. So yeah I'll try to run these by filling them or this week just to give them a headset that these are what these are what we're thinking and then if they have any objections I can I can let folks know. All right, with that I will pass it to Hugo for our second in the weeds topic. Hugo are you ready. I am sorry I just lost my place there. So as I mentioned with the poor request warehouse that have you helped me out there. There is a contributing process in the learn guide for people to contribute to core libraries so all the data fruit and a score circuit Python ones. But there isn't any mention about requesting reviewers or assigning reviewers. That's mentioned in that creating and sharing a circuit Python library. So I don't know if it's because it's in the organization or not but since we can't request review from anyone really. If nobody is watching or kind of getting alerts for these changes gets a little difficult to request a review so I was able to get some because I knew where to ask. But others may not have quite that knowledge or forthwith or forthcoming this that are what you want to call it to ask where do I do this. So I'm not sure if it's documentation change or something that would just be needed to hey you're going to do this notifier add a notification for someone. Can you do you want to speak to this at all. So it's there's a huge section of reviewing in the contributing to circuit Python using get and get hub guide, which is neither here nor there it just might explain why it's not in the creating and sharing a library guide. Although it was never it was never I mean that the this other guy came long after the creating and sharing guide so it's just was included there. It the not being able to request a review directly is a is a get hub limitation. That that's what I'm thinking is, if you can't ping circuit Python librarians as a team, you're, you're entirely free to ping me, or I don't want to toss out Scott without, you know, him giving permission but I figured there's there's there's those of us who are perfectly happy to if you ping us directly to then request review from circuit Python librarians. So don't feel like don't feel like if you're pinging us directly that we are assuming you mean you need us to review it. Like we, we understand that, you know, it's not it's that the get hub limitation exists and that not everybody can request can request a review and part of that kind of makes sense because if people were able to request reviews they could start requesting reviews from individuals and that would also go nowhere. It would be about as nowhere as not requesting a review if that individual was unavailable, or was not, you know, that wasn't their focus at the time. It wouldn't occur to them perhaps to then go and have to say like hey I'm not available to review this blah blah blah he just creates extra work. So I can kind of understand why the limitation exists if you're a reviewer, you can obviously request your review from the from the from the circuit Python librarians. I would try pinging somebody if they get it like don't everybody do it. Maybe maybe Tim for me guy if you could just on a PR try and ping circuit Python librarians if it lets you type it out it'll it'll ping I think. My impression was that that didn't work, but I didn't I feel like it doesn't. But I'm not sure. I tried doing a mention in a comment like that circuit Python librarians and it didn't even appear as an option I think it only allowed the individuals who are contributors in that. So I find that sometimes names don't pop up, even the weirdly even the author of the PR sometimes doesn't pop up as an option and I've had to go and make sure that I typed it out manually correctly. So that doesn't necessarily mean that it's not pingable but it's definitely a point in favor of it not being pingable. So what I would say is for now just ping Scott or me or both and you can and Jeff and just just ping us and say hey, you know would like a review from circuit Python librarians, and we can get that going and and you can indicate that to other folks as well. Okay. And you mean on the on the issue and get on the PR. Yeah. Okay, sorry. No, no, no, just making sure because issues don't don't require reviews. So yeah, on the pull request itself just paying the three of us and one of us will make sure that we get a review requested because I understand where you're coming from if if the PR pops in and the review is not requested. For example, it does not show up in my inbox. I have filters set. And it data I'm not sure and that's worth looking into I will add that to my list for tomorrow and it data writes it may have been asked but is there no way to automatically assign circuit Python librarians as default reviewers on all libraries. And I had a thought kind of adjacent to that with this work Scott had done to parse out the the error messages and automatically add a comment. If there was a way to make it take another action if the CI succeeded. So like when you get that green check mark that the PR passed the continuous integration checks, could it then request circuit Python librarians to review. Because that would be in a way even better. Well, I'm not sure because sometimes a reviewer needs to step in and say, here's how you get it working but hopefully with these hints people are going to do better. But yeah, if an automatic process could kick this off, because ultimately we do want to, you know, get everything into review regardless of who it's coming from. Although maybe only if it's passing CI I have divided thoughts about that. Right. Well, the other thing David asks, or says usually if I know someone has the hardware I would ping that person. The problem with doing that is that if, if that person doesn't have time or is unavailable, you've now limited other folks would look at that and see that that person was asked for review and would probably not review the PR. Because they don't want to step on toes or, you know, that sort of thing. So it's much better to request from the, from the review team because that's a lot of folks and that means all those folks would be made available, you know, could somebody somebody's probably available to test. And if not then that's when somebody who has the hardware would have to come forward and so on and so forth but it's, it's not. It's not good to I guess it's not good to basically assign somebody, you know, to a specific thing unless you know for sure that person is available to test it because other people will probably ignore it. I do like the idea of of the automatic reviewing thing because but I also agree with Jeff that there's there's nuances to it like do we wait until, you know, do we wait until the CI is passing or how would we even do that and so on and so forth so I mean there's a lot to look into. To see what we can do but for right now. If you are putting in a PR. Apparently you can tag circuit Python librarians so either tag them in the way that. Fummy guy dead or tag Jeff Scott and myself and we will either way, somebody will get the review requested. I think you could just paste it in. I mean, if you type an at sign name that's not recognized it doesn't have to autocomplete to turn gold. So correct it does yeah no even if it doesn't autocomplete if you type it out and it is accurate it will link and it will work. And I often drag select circuit Python librarians from somewhere else and then paste it in. Anyway, in the long run we can in the long run we certainly can't have get have actions to it. Yeah. But that's a word that that's a future thing and this is obviously an immediate issue right this is what do we do now. So right now either ping circuit Python librarians or ping Jeff Scott and I and one of us will will get the review requested so we can make sure that things don't slip. So that we can track this idea of automatically adding circuit Python these circuit Python librarians as a reviewer so that we don't lose track of it where would it be good for Hugo to file an issue. Oh with how to handle this for yeah for like adding some kind of automatic thing. Circuit Python and I'll label it libraries. Or. That's fine I mean it doesn't if we get it there like better than not yeah we can we can move it if we need to. Yeah. So here are you willing to write up something for an issue in the circuit Python get repo. Absolutely. All right. Thank you. All right. Next we have a topic from Jose David and Dan and Jose David is text only Dan do you want to introduce this issue or shall I. I think I can summarize it. Okay please do. So it just was a David was adding a bunch of new examples and found I asked when I was because I was reviewing one of them. A lot of the examples in simple tests right now. For sensors use that I to see sensors use bus IO that I to see and then they specify as the SCL and SDA pins explicitly. And so the simple test examples and or the examples that Jose David was writing. Could use board that I to see instead of bus IO. The bus IO call. And so the question was did we have any guidance. On. In simple test and or other examples simple examples whether we should use board. Or bus IO and I was I asked Kat me. That question. Yeah we've we've been leaning towards board that I to see. So so I think Jose is saying in the long run. Then we can go ahead and gradually change the simple test examples in the libraries to be bored. And I suggested adding like a comment that says like this uses board SCL and board that is just SDA just so people know what's going on. For beginners. You just add a simple comment. And but I and we can gradually cut it over. I mean Jose is saying we could do this. I don't think we have to do it. It's not an urgent thing. In any way. So but just when you write a new simple test or when you write an example. Use board to see if you can. If it makes sense. So that's really what this is about. A related thing that came up while we were discussing this is that. On some board. That have a stem of board. That I to see is the same as the stem of connector because. There aren't enough I to see pins to make a separate I to see bus. However on the QT PI RP 2040. The stem of connector is different than the labeled SCL and SDA pins. It's SCL one and SDA one. So an interesting point. Is whether we might add a board object. That refers to the SEM a connector. On those boards. I think yes. And Scott does that sound interesting to you. Yeah I think I think you should have a stem I to see entry for anything. With a stem on it. Even if it's shared with the regular. I think that's a good idea. And just link it to the same thing. Right. It should be stem. Stem a QT. I'll ask management about. Exactly. Because it could be STEM a QT. Or instead of stem. May want to choose one or the other. Yeah. Just. Yeah. Just be consistent. Yeah. I don't think we can make it work if it needs to be stem. Divided by QT. That'll be trouble. That will be trouble. Yeah. We have to implement a system. That will be trouble. Yeah. We have to implement a special version of. Slash operation. Okay. Yeah David. David points out there is big stem of two. But I think in general we're not using big stem of. And it can also mean other things like. New pixels for those as well. Yeah. Yeah. Hi gamer and pipe portal have the big one. They do. It's also why it is five volts by default with the jumper to switch it. It's a little bit of a pain to use those kind of with modern stem of QT boards. Which I discover each time I try. We have an adapter cable. I think it wasn't in stock that day. You know how some of the cables are. Right. All right. There's one other kind of sub item. But I think that's asked and answered within the notes document. So I will skip over it. Okay. Unless you'd like to say something about it. No, just I guess. For people who are listening later. There's in the library infrastructure issues on circuit python.org slash contributing. Section for mismatched read the docs.yaml. And this is currently triggering on everything. It's not something that needs to be solved. The check itself has been changed. In Adabot, but we never updated it on circuit python.org. We didn't update the Adabot sub module. So I will get that taken care of tomorrow. The PR is here that fixed it. And that is how. It got resolved. So that was all. All right. With that, it looks like the next topic is for me guys. All right. Yeah, this was, I think we'll be relatively easy, but basically it's just, um, I started making the repos in the circuit python org over the weekend and pushing. Um, I think it's probably expected because it didn't have any, um, credentials in the secrets or whatever they call that inside GitHub where you put those. Right. Um, so the question is basically in the repos in that circuit python org, which account to the circuit python. Um, which account to the circuit python. Um, which account to the circuit python. Um, um, um, which account are those going to use for read the docs and pie pie? And then, uh, Can somebody with access to that put them in or, or is that the kind of thing where like we should be making new ones for that? Um, Go ahead. Go ahead. I was going to say, I think new accounts are the right way to go. Um, Maybe what we do is we just put those in a private repo under the org as a way. To, for us to kind of like share credentials for it. I think generally it's good to have one account that has access to it all that. Like you don't actually use yet. Add your, yet you add your personal account as a maintainer as well. But you always like the, the docs. For read the doc. Yeah. For read the docs. And I guess pipe. Yeah. Well pipe. Yeah. You can have multiple as well if you want to maintainers. Okay. Global secrets. For. Sure. On the Adafruit org. Um, It would be simpler. I think to. We can create a new account. That's not an issue. But I think having global secrets on the circuit pipeline org. Um, Makes sense as well. And for read the docs, we can create a single account. Then you. Um, Homie guy, for example, would create the project on read the docs and then add. You know, Circuit Python account as a maintainer. And then what that means. Is that if you. Um, Stopped working with us, for example. Uh, We would still have access to those. Uh, Document. Um, And would be able to change them. And so that way. It's not limited, but we can figure out a place to keep. Um, The credentials for read the docs, but you don't actually need to do that. Um, We can figure out a place to keep. Um, the credentials for read the docs, but you don't actually need the read the docs credentials for that account. To add it as a maintainer. That's how we do it. We have an eight about account. I got you. Um, and we just like, I go and create the project under my name and then I add eight about as a maintainer. And that that's how we sort of. That's how we tie things together. Um, right now. Okay. Cool. Yeah. I think, I think I understand that. I can handle that. Make those on read the docs and then share them over. Um, so then, uh, Uh, Scott, do you want to create a PIPI account or is that something you would want me or somebody else to do? You're welcome to. Do you have organizational secrets. Access, maybe not. That's a good question. So I could, I could set the. I could, I could make it too. Okay. If you just need an account. Just tell me what you need me to do. And I'll do it. I can create it. Yeah. Katnie, you can do it too. Oh, that I did. Katnie, did you get org level ownership? Oh yeah, I did as soon as it was created. I think I'm an owner on it. Yeah. I don't, I don't think I do. I don't see a settings gear in the spot where I think it would be, but I've never actually used an org like this before either. So I don't know if I'm looking the right spot. But yeah, if one of you. Yeah, I added most folks as just members. Because then I can, I was able to turn off the ability to make private repos because that's where you can like incur costs. Cause the org is actually set up to like charge a different. I see. So I was like, Oh, let me at least set the permission so that like, yeah, you can make repos all you want, but you can't actually make any private ones. Okay. Yeah. If, if one of you could, could spin that up. And then if there's anything that I can do to help with my access, I'm definitely willing to do that. Otherwise, if you let me know, once that's in there, I can try to tie it together with the existing, I put in two of the repos over the weekend. So I can try and get those two set up with that stuff. Nice. Yeah. Katnie, I just gave you ownership so you can do it. Okay. What email address do we want to use because circuit python at Adafruit.com is already being used. Oh, for the account. Yeah. Usually you can cheat it and add pluses. If you do like something, something plus. Like pipi circuit python.org at whatever, like it all goes to the same place. Okay. That's what like that's what I did for at least one of the accounts where it like goes to our internal embedded mailing list. Okay. With a plus. So try that. And if you can figure it out, I'm happy to do it as well. All right. So the action item goes to Katnie. Thank you for taking care of that. And with that, I will pass things to Simon C. Simon, are you planning to speak or would you like me to read this for you? Hello, your audio level is a little low. So please turn it up if you can. Okay. Is that any better? Yeah. That's somewhat better. Okay. So I'm very new to circuit python and the kind of data group discord community. It's been a really great, I think it's been less than a week. So I was looking at a comment that Katnie posted about the animations library growing in size and getting too big for being fully loaded onto smaller boards. And so I suggested some kind of techniques for having a program look at the library and then try to kind of cut out stuff that isn't used. So this is kind of a very old technique from, I think they figured it out pretty well in the 70s and 80s and analysis research and it's definitely has some use in JavaScript for optimizing kind of code shipping and code execution over the web. And I think Python, it doesn't have too much use in this kind of automatic way. It's more like an inspection tool where you can look at how your code is doing with something like NOS or I think there's a tool of vulture that you can kind of look at the output. So I kind of suggested a couple ways to organize like almost like sub slices or sub parts of libraries that you could select to use and put on to the board and I was curious about what different, how it should be, the API should be like and kind of what is best for letting users do this or having Adafruit package these kind of sub parts of libraries. And there's plenty I don't know about how CircuitPython is built and kind of what the language limitations are. I think there's one particular limitation on static, the kind of analysis has to be static and any changes to, within Python, if you say import module, that can be static analysis. But if you import dynamically it doesn't. It's hard to pick up that type of, that pattern. So I'm kind of wondering about language limitations and kind of what people think a good API would be. All right, well thank you and welcome. It's nice to see you join us. Does anybody have anything they'd like to say about that? I know I call on you Scott because you think deeply about lots of things. I try. I think it's really interesting. I know like the thing that, I think the data flow stuff is really interesting. I can see like Python is very dynamic which can make it difficult. But I think there's only a few libraries where imports are actually like kind of as needed. Generally for like how to split things apart it's just like, you know, all the related things should be in a file. Because file is like the level that you import stuff into RAM. Kind of my desired next step in terms of making libraries like less large is just actually instrumenting it. Like I think we would be much better about keeping our libraries small if we simply knew how much bigger we were making them as we changed them. And that's like, that's not related to this. I don't want to like answer with a different thing. But I think in terms of like us maintaining the libraries on the whole that would be a better first step is just instrument it and track how large they're getting. But I could see that I could see that data flow analysis would be really helpful for specific libraries that may need to be restructured to be more efficient. But I've not actually done any data flow analysis myself so I can't really say how feasible it is with Python. I would say there's not that much dead code or something like that. I mean it's really that the libraries are large because they have a lot of features like some sensor or they have multiple things in them like the animation library. So I'm not sure you're going to find out a lot. That would help you shrink them significantly. As Scott said, it makes sense just to make smaller libraries and factor them into multiple things like should we break up the animation library, should the HID library, you know, that kind of thing. Another thing that occurs to me is we're very proud of this trade in CircuitPython where to change your program you just edit code.py. You don't run a series of tools or anything. And taking the animation library as the example you know it would be possible that your tool could statically figure out that code.py doesn't use a particular one of the animations and eliminates it from the CircuitPy drive. But then when you edit your code.py and save it that can change. And in the vast majority of cases we want to keep this workflow where the only thing you need is a text editor not a static analysis package that would run over your code.py plus all of the libraries that it calls for. I think, yeah, the extension of that is like you know, thinking about ways of modifying that we've been talking about like CircuitPython builds that you know have this kind of dynamic addition and subtraction of modules. I mean that could feasibly apply to libraries too where you kind of like specify what parts of the libraries you want available in this particular CircuitPython build, but it's definitely part of just kind of Scott's general philosophy and concern that whenever you reduce something you know it becomes a support issue basically. So size reductions, that kind of dynamic size reduction where you actually build size reductions into like a build of CircuitPython. It kind of makes it not CircuitPython anymore. Which is complicating. There's one kind of tweak on the kind of typical code elimination pattern where you're reducing everything you don't use where you are more saying what you're kind of adding a dependency on kind of, I was calling it a label like a sub part of the library and there's what your code actually uses and then there's what the sub part of the library that label it says these are all the entry points that I need to use this library successfully. So it's a little bit different than this kind of pattern is maybe kind of a combination of both. This is kind of this is what your goal is and it kind of ignores specifically what the importing code is doing. So I'm just trying to get it kind of the heart of this thing. I mean your objective here would be to use labels to outline the parts of the libraries that you need in order to reduce size of a specific CircuitPython build. Is that right? Yeah, I think so and this only is relevant if there is a library that's on library that's big and somebody wants to only use a part of it. I think the tricky part is just doing custom CircuitPython builds is like a complicated thing. You go, Scott. I think this sort of analysis could be a really good way of understanding the mismatch between how the library is structured and how it's used. The principle that I've tried to push from the get go with CircuitPython is that we should have lots of small libraries where whatever is in the library is very tightly related until you're probably using most of it. But I think what we found is that we have some large libraries where they try to do everything which means that they have a lot of stuff that you're importing that you're not using. So I think doing Dataflow analysis where like one thing we do have is we have a lot of examples. We can do something similar like project bundle where we do Dataflow analysis starting with all these different examples and then using that to figure out what the boundaries are for large libraries that we actually need to split. And then you would manually split them later, right? But you would use the Dataflow analysis to inform where those split boundaries could be. So not doing it in a bespoke way. Go ahead, Lucian. Right. Just like not doing it in a bespoke way or every single for a specific build for a specific person but just using it to plan out actual library separations, right? Yeah, you'd identify like clusters using Dataflow analysis but then it's a human action to perform the useful split. Right. I think that sounds really cool. Is that what you're saying, Simon? Yeah. I think the kind of very precise definition of a label. So I think you're right that the typical trend is that Dataflow and code elimination cut out everything that's not used in the build. And I think, you know, let's say there's a setup function that a user needs. So let's say you do that, you know, custom for every time you run something on a board. So let's say there's some custom setup function that somebody should have called but they didn't. So that setup function is eliminated and then they, you know, change the code.py to add it and then it's not there. So that's kind of how it should differ from the typical compile of dead code elimination. Yeah, I think the very precise pattern I was interested in is, you know, a label is a sub part of the library that contains all of the entry points that you need to use that label successfully. So I think that would kind of be like a human created front end to a valid dead code eliminated sub part. But there are existing tools for just looking at what a use doesn't use. So that's, I think Vulture does that reasonably well and so does Incnose. I think just the broader the separation that has to be kind of acknowledged is whether the user or whether a dev is doing the separation. I think that that's just still what I totally get, whether which side you're describing. I was giving that open as something I didn't know enough about I think because I don't know what tools are used to build CircuitPython and I didn't think the CircuitPython would have to come a long way to support that. I think that yeah, I think generally right now we like the broadest thing is just like when we import a module it's like a file level thing. So we think about memory impacts of libraries. It's whatever the contents of a file are plus anything that they import as well as kind of like the units that they're done. And so that's why my bias is like let's change these units so they better align with use. But there are some things that we could potentially do that would be like lazy loading code in CircuitPython so that like we have more flash than we have RAMs generally. So like we could think about if it's an MPY file like maybe when we first parse it we don't actually like load the code in we just say where it is in the file and then only when we actually would have called it we load it in. But I think the reality is that like we're very much in Moore's Law territory for vicar controllers right now it's usually that useful to optimize libraries because we're going to get hardware that is as inexpensive as what we're using now but has much more RAM and flash. So yeah actually now so yeah I'd realize I was hung up on the idea of CircuitPython builds this wouldn't be if you did a fully bespoke solution it would be something that would be like built into circuit. You load the libraries in the file and basically circuit checks the libraries and edits parts out depending on what's in your code.py file as you load as you like save your code.py it would go in and do library editing to reduce size and it would have the full libraries on the host computer and it would reduce them on the CircuitPython end. At least that's what I think you'd have to do if you want to do a bespoke solution as opposed to a long term planning thing. I'm not sure how yeah I'm like Scott said it's like it's a lot of work for not so many boards anymore and it's going to be less boards every year that are going to have those problems maybe. Okay so it sounds like it's more there might be a couple libraries that we want to do this for but it sounds less I think it's a matter of how it is applied. It's definitely an interesting idea. I think we aren't really familiar with applying these kinds of ideas. I recognize the name tree shaking as it applies to JavaScript but it's not a level of abstraction or technology that I think about CircuitPython with. I could kind of see the outline of the circuit feature but yeah. I mean if the VM did it would be amazing right? If the VM has to run less code then that's cool but like Python in general even CPython doesn't do a whole lot of optimization on bytecode at runtime and there's been some discussion in the CPython world about whether they do want to go the route of v8 which is really aggressive optimizations or whether CPython is really there to be a canonical less optimized but canonical implementation of Python. I think whatever you're interested in we're open to. Yeah for instance if it's a source-to-source transformation program that can live and show its promise which is how CircuitPython got started I think basically and now I depend on it so if this interests you you should absolutely work on it and it might find more of a place than some of us are imagining right off the bat because we're not imaginative enough. Another random thing I wanted to interject is I was looking at the size of MPY files the CircuitPython byte-compiled version of Python files and when strings are repeated many times like in a main in the main level and then I think down in functions the strings are repeated in the MPY file and that seems like some really low hanging fruit for saving source size of MPY files if that observation is correct I think they may have changed that upstream already So for any MPY stuff hold your horses on any optimizations the stuff that Micropython may have done already because I know there is a new MPY version with what will merge in. How high priority is the size of a library file that you load onto the file system is that usually a big concern because we usually have a lot of file system flash but I don't want to express M0s as the only place that really matters and that's true those duplicated strings will be merged into one string in memory when it imports. It's kind of like there was one specific library like the Animations library that Katnip was talking about can somebody kind of speak to that issue or is that? I mean the ones I'm aware of are more of the PyPortal-esque ones like this class of libraries that tried to do initialization for you for example can be quite large. The Animations library became more popular than I expected it would and so we were taking anybody who added animations we were just adding them and I think I think that's a problem I want to refactor out the community submitted ones to another because they're not used as significantly as some of the other ones into their own library. Are they in different files or is it a RAM problem or a flash problem? They're all in different files like every animation is in a separate file. It is a flash problem then. You can very easily drag part of the library over and we're not going to tell people to do that. We can tell people to do that on Discord but we're not going to write a learn guide on doing it. Bundlefly isn't going to do it? No, Bundlefly is not going to do it either. Basically I want to slim it down to be able to for example as this was as Nerodoc pointed out run on Neo Trinky was that Lamora was like, yeah, I do LED animations and I said it doesn't fit and she said sure it does and I said it doesn't. She might have just dragged stuff over and not realized it. So that one I think is going to be addressed specifically and I think it needs to be because it is a very ridiculously popular library and we do have tiny boards that folks want to run and we don't have a lot of LEDs from. So I think that's a good candidate for a refactor. I don't think that applies to everything though. And by refactor you actually mean splitting a part into something. Correct. Where some of the animations are actually separate. They would still require the Sturker Python LED animations library. Yeah, I would build on top of it and it would create a situation in theory where we can fit this onto a smaller board and then just like a few other libraries where we have to be very careful with what we add we would have to be very mindful of what we add to the Sturker Python LED animation library as well. If the core and I use an overloaded word if the very minimal part could fit in frozen on some of these devices but that's probably too much of a problem. I think that's the problem. I think LeMore might have tried that. Pixelbuff doesn't fit. Right. Well, yeah. And already on Neo Trinky, NeoPixel is frozen, HID is frozen and pixelbuff is enabled. So PyPixelbuff is not necessary. Okay. So basically I think she created the best version of the build she possibly could and we have to make the library smaller if we want to use it. This may change with the updated MicroPython as well. Cool. Then I will hold off on that for a week. Because like when you freeze libraries in you're basically freezing in the MPY files. Right. The same similar structures. So. Yeah. That'll change hopefully for the better. That could be a pretty big roadblock to getting to 115 if everything gets larger. Yeah. Well, shall we wrap this discussion up? Sure. It sounds like there's kind of two uses. There's slimmed down what is being used and then I think that I want to use this sub part of a library and then give me that slimmed down build this maybe more usable one that I was thinking about. Yeah. I'll keep reading and thinking about it. All right. Well, thank you so much for joining us Simon. Hope to see more from you in the future and we're happy to help you, you know, get up to speed on some things about how the core works. There is a lot to know and even those of us who've been doing it for a while are still learning. So really appreciate you joining us and bringing a different perspective and hope to see you again soon. And that will allow us to wrap up the circuit python weekly meeting. This has been the circuit python weekly meeting for April 19th 2021 and I'll just click back over to my other document for the wrap up. Thank you to everyone who participated. If you want to support Adafruit and circuit python and those of us that work on it consider purchasing from the Adafruit shop at adafruit.com The video of this meeting will be released on youtube at youtube.com adafruit and the podcast in audio only version will be available on major podcast services. It will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe. The next meeting will be held next Monday as usual at 2pm eastern 11am pacific that will be the April 26th meeting if I'm not mistaken. The meeting is held on the Adafruit discord which you can join by going to adafruit.it slash discord. To be notified about the meeting and any changes to the time of day you can ask to be added to the circuit python discord. We hope to see you all next week. Thanks everybody Thanks everyone Thanks all