 Hello and welcome to the CircuitPython Weekly for June 7th, 2021. This is the time of the week where we get together to talk about all things CircuitPython. I'm Scott and I work for Adafruit 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 in CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. That's the short link for it. We hold the meeting in the CircuitPython DevTex channel and the CircuitPython Voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday. The meeting time is changed. We'll notify you via Discord. If you wish to be notified about changes to the meeting, you can add you to the CircuitPythonistas role on Discord. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We record the audio from the voice channel and the video of the text channel. If you'd rather not have your voice recorded, you're still welcomed or participate. The video of this meeting will be posted to the Adafruit YouTube channel and the audio is released as a podcast. There's a note stock to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, you can leave hug reports and status updates for us in the document and we'll read them off during the meeting for you. The notes document also contains timestamps to go along with the video, so you can use the doc to view only parts of the video that interests you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. A link to the notes document is posted in the CircuitPython Dev channel on the Adafruit Discord every week. Check the pin messages to find the latest note stock. This meeting is held in five parts. The first part is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of the Python on microcontrollers newsletter. The second part is the state of CircuitPython libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. The hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up what we've been up to, sync up on what we've been up to. Take a couple of minutes and talk about what we've been doing in the last week since the last meeting and what you'll be up to over the next week until the next meeting. The fifth part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. That covers how the meeting will go. With that, I'll get started on community news. Community news is a preview of the Python for microcontrollers newsletter, which is released every Tuesday morning. If you want to join that, go to ateafruitdaily.com and click the Python for microcontrollers checkbox there. These are a preview, but not all of everything from the upcoming one. First, CircuitPython 70 Alpha 3 and 630 stable have been released. CircuitPython 630 is the latest minor revision of CircuitPython and is a new stable release. Notable changes since 6.2 include many new boards, many corrections to existing boards, and the addition of a consistent board dot led to most boards. And there's links there to the ateafruit blog and the github release notes. CircuitPython 70 Alpha 3 is an alpha release of CircuitPython 70. It is relatively stable but contains a number of issues still to be addressed for 70. The Python APIs it presents may change. Notable additions to 70 include runtime customization of USB devices, merging in of MicroPython fixes and enhancements as a MicroPython 115, simplification to the RGB status led codes and a clocking fix for a few samples of the RP2040 boards. Next up in Raspberry Pi news, the RP2040 single chips are going on sale now for a dollar. On Tuesday, June 1st, the Raspberry Pi Foundation announced that RP2040 microcontroller chips are available from their approved reseller partners in single unit quantities, allowing people to build their own projects and products on Raspberry Pi Silicon. Next up, there's this cool project, PiRTOS, which is a real-time operating system for CircuitPython. Check out the ateafruit blog and github there for the note stock. Next, ateafruit's been switching the default branch of CircuitPython library repositories from master to main. Over the course of the next few weeks, ateafruit is switching the CircuitPython repositories to use main as their default branch instead of master. This changes a continuation of past efforts to depart from language deeply rooted in centuries of racism and the subjugation of people based on the color of their skin towards language that is inclusive for everyone. These changes have sparked others in the electronic and maker communities, sparked fun, make, and more to think about the history of words, how they're used, and changes we can make together. And there's an ateafruit blog. Dee Harada, who's leading the work, says, next few days, probably only 90 libraries left to go. So thank you in advance to Dylan for doing that. It's great to see that making, lightning progress as everything that she does goes. Okay, Q&A with the programming with microcontrollers in CircuitPython author Armstrong Sabaro. A-Press recently published a book programming microcontrollers in CircuitPython. Ateafruit asked author Armstrong Sabaro some questions about both he and the book and had Armstrong on our show and tell to. And that's it. This is a preview of the weekly newsletter. The CircuitPython Weekly Newsletter is a CircuitPython community run newsletter emailed every Tuesday. The complete archives are available at www.ateafruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware related news from around the web, including CircuitPython, Python, and MicroPython developments to contribute your own news or project at its next week draft on GitHub by going to github.com slash Ateafruit slash CircuitPython-weekly-newsletter and check out the drafts folder there and submit a poll request. There's a way if you click the little pencil icon in the top right while looking at the draft, you'll be able to edit it. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnewsatateafruit.com and as always thanks to Ann for putting the newsletter together and leading the charge on that. All right, let's go to the second section. The second section is a state of CircuitPython libraries in Blinka. This is a chance for us to take a more objective statistical view of the project and kind of ground ourselves in some numbers that we want to that we keep track of so that we don't get too far from the reality here. So overall, we've had 46 poll request merge. This is over the last week. We had 29 different authors. New folks for me reading this off are GM Paris, Gomi, HGY, StoneHippo, WolfmanJM, Daniel Ballin, Rephad is new, CrackknotSnowman, DJIX123 are all like pretty new folks. We had 15 reviewers so thank you to all our reviewers. Without reviewers, you can see there's like a two to one ratio between reviewers and authors. So the more reviewers we have, the more authors we can support. So if you're interested in reviewing leveling up your CircuitPython game, let us know. We're happy to help you do that. Issues-wise, we had 26 closed issues by 11 people and 13 open by 12 people. So we're net down 13, which is amazing. Thank you to all the people involved in the issues as well. We really appreciate it. And let me go to the core. So for the core, we had 23 poll requests merged from 17 different authors, which is awesome and six reviewers. So we're definitely like have not quite the same ratio as before. So more reviewers are always welcome. We have 19 open poll requests. The oldest is 257 days old. And we have a couple more that are just turning the corner on the 200 days mark. So I think the the main call to action here for the core is like really if people want to get started with it, please take a look at those these pending PRs that we have open. It would be great to close them. I know there's a couple that are specifically for adding board support. So they should be really easy or relatively easy to pick up and kind of finish to completion. Of course, boards are a little bit trickier because like if you don't have it, it's hard to test. But yeah, we'd love people to take a look at what those are. Mark says, is there a process to take over an older PR? Just comment and ask if the author if the original author is about. Yeah, I think you could chime in there saying like, Hey, I'm interested in working on this. And if you have edit rights, which we're happy to add people to, you can you should be able to actually usually you're able to push to the original branch for the PR as well. So that's what I mean by take over. And yeah, if you're interested in that mark, just I'm happy to help you do that. Okay. Issues wise for the core, we had 13 closed issues by six people and seven open by seven people. So we're even down as well. We have 458 open issues. And the way that we kind of keep track of our issues is we have milestones, milestones, we tend to have give us an idea of like, how soon we want to work on things and kind of what category to some degree they are as well. We have four issues that are not assigned to milestones. So these are ones that no one's looked at and categorized. So we always want to make sure and take a look at those because they could be urgent and critical. We have three open issues under the six point X bug fixes, which are probably the most critical. And then we have 56 open issues for 70. And then we have 375 long term ones that are just general long term stuff. And with that overview that I have here is very straightforward. Thanks to Dan. 630 is stable and released and 70 alpha three is released as well. So folks, please test those out and let us know what you find. I think seven is actually in pretty good shape. I think we'll be able to get that out not too long. Although we're still changing some APIs with that. Okay, so that's the core overview and the core stats. Let me kick it over to Katny for the libraries. Thanks, Scott. So this applies to all of the Adafruit circuit Python libraries, including everything that starts with Adafruit underscore circuit Python underscore, as well as some extras such as cookie cutter and the community bundle. So this week we had 22 pull requests merged from 14 different authors and 12 reviewers. We had a significant number of them that were older than two weeks, including one that was 206 days old. So that's been really great to see, leaving us with 44 open pull requests. We had 12 issues closed by six people and four open by four people, leaving 304 open issues. If you're interested in contributing to circuit Python on the Python side of things, go to circuit python dot org slash contributing. You'll find all of this information and more, including open pull requests, open issues, and some library infrastructure issues. Feel free to check out the open issues. You can search by label. You can also take a look at the open pull requests and see whether or not there's anything that interests you. If you want to get started reviewing, check out the open pull requests. Take a look at them. You can check for syntax. You can check for spelling. If you have the hardware, you can test it and then leave a comment and let us know. And once you've done that a few times, and once you're comfortable with that, we can level you up to actually joining our review team. If you're interested in actually contributing to code, check out the issues. In terms of new libraries this week, we had one new library, simple text display, and a number of updated libraries. In terms of contributing, if you're new to Git and GitHub, don't worry about it. We have a guide and we're always available to help. We want to help you contribute in what any way that works for you. So overall, we're seeing steady work on getting through the older open PRs as well as keeping up with new PRs. It's great to see all the work being done both on the Adafruit and community libraries. We're working on getting all the libraries moved over to main from master as the default branch. So please verify whether the library you're working on has been moved and work within this change. It should be completed within the next few days. If you need help moving your local repo over to main, feel free to ask us on Discord. It's a pretty simple process, but the easiest way to do it if you don't have any current work is to just start with a fresh clone. But we are around and we can help you out if you want to actually go through the steps to do that update locally and keep anything that you're working on. And that's where we are at the libraries. Thanks, Katny. All right, next up, let's get the latest Blinka updates from maker Melissa. Hello. So Blinka is our circuit Python compatibility layer for Raspberry Pi and MicroPython and other single board computers. So this week, we had one pull request merged by one author and two reviewers that leaves three open pull requests. There were one closed issue by one person and two open by two people leaving a net of 57 open issues amongst all the different repositories. And there were 5,380 Pi PI downloads in the last week and we are currently supporting 75 boards. Overall, there hasn't been a whole lot of work this last week, mostly just little fixes, but it's good to see some work at least being done on it. And that's it. Thanks, Melissa. All right, next up, we have another section called hug reports. Hug reports is a chance for us to say thank you to folks for the work that they've been doing. It's a great way to highlight just all the different amazing things that people are doing and giving credit where credit is due. So this is done as a round robin. So I'll start and then we'll go through the list of folks in the note stock and circle back around when we hit the bottom of the alphabet. So first for me, a quick single hug report to Antonio who is working on the iOS app for the BLE file transfer stuff for collaborating on debugging glider, which is the app and circuit Python. It's always great to work with somebody who's like totally willing that the bug might be there is but also could could be my bug as well. So it's really, really collaborative and I appreciate Antonio for working with me on that. All right. And next, let's go to v923z. Thanks, Scott. I haven't been here for a while. So I have a number of people to acknowledge first yourself for fixing the macros in micro lab, then for for helping out with documentation for circuit Python, right, circuit Python compilation. Then Jeff for tying up number of loose ends, especially and the workflow flies and running after the garbage collector issue. And finally, I would like to thank David Glody for raising an interesting question. He wanted to upscale his thermal camera images using micro lab. And we had me discussing this question for quite a while, considered adding a new function to the core. But it turned out that you can do that already with slices. And it also turned out that Python code is not necessarily efficient. I'm really glad that he went to great lengths benchmarking the proposed solution. So thanks for that date. And finally, what came out of this is a small chapter in the in the documentation. And in particular, the the image upscaling issue you can find in the link that I have just posted. Thanks. Awesome. Thank you. Always happy to have you drop in the meeting. Okay, I have a quick couple to read off. First from Dan, who's absent says group hug, including all of those who helped with supported and tested 630 and 70 alpha three, the amount of work in these releases is phenomenal. Next up is de herrada. Yeah, so one second. Yep. Hug report to lady for helping me out with MOSFETs and stuff like that. Because I really had no idea what I was doing. And then a group hug. Awesome. Thanks, Dylan. All right, next up, we have a couple of text folks. So I already does off as well. Her effects is group hug. I was out last week. And next up is foamy guy, who says hug report to ask Patrick W for reviewing a PR to make cookie cutter behave nicer with spaces in the library name and catching several spots that needed changes that I missed. Next, let's samurai prepare for working on some solutions for the version string of the pi PI stubs upload and to the Ruiz brothers for making a super cool functional rotary dial or rotary encoder crank in a single print design. Next up is Jeff. Hi, sorry, I'm just googling the crank because that's something that I wanted and I didn't know they'd done it. Yeah, I just have a group hug this week. Thanks, everybody. Thanks, Jeff. All right, next up is Jerry. Yeah, likewise, a group hug for me. Thanks for everybody. Thanks, Jerry. All right. Next up, we have notes from Jose David, who says hug report to Keith EE for his first PR in circuit Python, also for reviewing my documentation PR hug report to Daniel ballon and blue jazz CHN for sticking with the PR hug report to the samurai for all of the work this week. It was a lot of fun and hug report to Jerry and for answering the question I assume. And next up is catney. All right, so my first report is to Carter, Mark gambler and J for CN for helping me test some code. I was having some really weird behaviors that I couldn't figure out and subsequently a hug report to Carter for figuring out that the seesaw library has a bug. Hug report to the samurai for posing the idea of a circuit Python community code of conduct. I'll talk more about that later. And hug report to Dylan for all the work on moving the circuit Python libraries to the main default branch. Thanks, catney. All right. Next up, I have notes from Mark. Mark says hug report to foamy guy and catney for some suggestions. I passed on to someone on Twitter looking for a circuit Python development environment. And last up, we have maker Melissa. I wanted to give a hug report to the samurai for testing and fixing an issue with Blinka on the Pico with I2C. And everyone else. Thanks, Melissa. All right. That's hug reports. Next up, we have the section status updates. Status updates happens in a similar way as around Robin, but this time we want to hear a little bit about what you've been working on and what you plan on working on in the coming week. And it will just go the same style. So I will start. So I got directory listings and file readings and writings working from Glider, which is the Beely file transfer app. Connecting is still a bit painful. We don't correctly store bonding information and use it well and all that stuff. So a lot of forget this device and reconnect sort of stuff. I'm working on improving the internal identity keys management so that scanning a resolvable address of bonded peer actually gets resolved by the soft device. This should hopefully allow the test script to reconnect after bonding. And I'm out starting Thursday through all of next week to visit family. So I'm ticking a vacation and I'm very excited about it. Yep. That's it for me. I will be out next week, but I'll be back in two weeks and no deep dives for the next two weeks as well. All right, let's kick it over to V923Z. Thanks, Scott. So first of all, have a great time. So in the last couple of months, I have still been working on on Microlab, reviewed a couple of PRs. Someone added a complete module to SciPy, the SciPy port actually, with two functions. Fixed a number of corner cases. Kevin Waters pointed out that some functions didn't behave properly. I think I sorted out everything and then added CMake support for ESP32 and RP2040. Some of it came from Gadgetoid. Then fixed the garbage collection issue. Jeff was instrumental in that regard and worked on the docs. So in the coming weeks, I would like to work on adding a complex support and the block read support. I will come back to that in the weeds. And I would also like to add the option to reuse the firmware size at the expense of RAM. Someone brought this up on GitHub and I am coming around. So I was first a bit reluctant, but I am coming around and will try to see if it's workable. And I wanted to think of electronics, but there's a shortage of ICs at the moment. So I have to put it on the back burner and instead I decided to try some Julia or learn to some Julia. So these are my plans for the coming weeks. Awesome. Thank you, V923Z. All right, let me go to the top. All right. From Dan, Danza, who's out today, says release circuit python 630 and 70 alpha 3. Working on keypad scanning support, one button per pin is about to be tested, matrix support, and then shift register support will follow. And next up is DHirata. Yep. So last week, I started moving on the circuit python libraries to main and then just like do some messing around with petrobanning led strips using MOSFETS. And this week, finishing up the move to main and probably a few other random things I'm forgetting. All right. Thanks Dylan. All right. Next up, we have notes from DHirata or not, sorry, from higher effect. We just did DHirata. Last week, higher effect was off. This week, finish all the sleep testing sketches, bus documentation, and submit for testing. Next up, we have notes from FOMIGuy. FOMIGuy says, worked on the action steps for uploading stubs to PyPI, PR created, and I think it will work once PyPI credentials are added to secrets, renaming the rest of the display IO widget libraries to include org in the name and other changes required by this. I made some code for Rotary Trinky to use it as a brightness and scrolling crank. Next up is Jeff. Hi. So last week, my main work was on the ESP32S2 camera input. And this week is continuing to work on that. And also adapting in some code to initialize a different camera module called the OV2640 based on demo code. And the status of that is I had some data coming in in the middle of last week, but it's corrupt and I don't exactly know what the corruption was because I only had an ASCII viewer that I could do and that's not so great. Anyway, and another note that I may need to revise or just throw out the code that I adopted in as a library because Espressive has done at least two major incarnations of this camera library. There was one in one examples repository and now there's another one in a separate specifically camera repository that is pretty different. That new one works better, but it's the old one that I based all my initial work on. As far as the parallel image capture class in Circuit Python goes, there are going to be incompatible API changes. Initially with the examples of the SAMD51 and the Raspberry Pi RB2040, the pins that had the parallel data were always sequential, but on the ESP32S2, they can be in any order non-sequential. And so that means we have to change the API. We're not going to keep the old one since it was never released. And kind of making clear what I was saying a minute ago, our primary interest in hardware has changed from the OV7670 to the OV2640. According to Lamor, the OV7670 is obsolete. You can hardly get it anymore, so they would not make a product out of it. The OV2640 is pretty readily available. It's what ships with Espressif's Kaluga Dev Kit, and it's probably the one that they would build a product around at Adafruit. So that's why in a number of ways, this is kind of starting from zero and why it's taking a long time to get something going. And in Outside of Circuit Python news, I fixed my kitchen sink this weekend and did not have to call a plumber. I'm really happy about that. Nice. Good job, Jeff. All right. Next up, we have notes from Jose David. Jose says, last week, testing and reviewing some PRs, like BitBang.io, working on a PR for the issue on the SI4713 and some documentation, and reviewing PR for the SGP40. This week, review the PR for the MAX31865. Modify learn guides for the BME280, DPS310, and the Blinko with MicroPython as it uses the BME280 sensor. PR reviews and testing is needed. Next up is Katny. All right. So last week, published the Rotary Trinky Guide, finalized testing of the page replace feature in learn. Let's see. It published the Adafruit Circuit Python Simple Text Display Library. Somebody made a request for this to be pulled. It was in the Clue Library. Basically, it allows you to display lines of text on a display, display IO, display very easily. And I wrote it into the Clue Library originally with the plan of using it with the Clue sensors. And now we have boards like Funhouse, which also has also has sensors on it and a display. So they wanted to be able to use it with Funhouse. So we split it out into its own helper library is the short version of the story. Fixed the Rotary Trinky board files, the actual PCB files, the fritzing and the pinout diagrams. We wanted to match what we put in Circuit Python, which it turns out was swapped. So we matched Circuit Python across the board. So it's sort of like fixing it backwards versus updating all of the pin definition and so on to match. And that meant I learned some Eagle stuff this last week as well. And then started the Slide Trinky Guide. This week, huge list. Update CircuitPython.org to include the 7x bundle. Update the Readme for the project bundler. The project bundler is now going to include two folders, one for 6x and one for 7x. And the Readme doesn't refer to any of that because that's new, so the Readme needs to be updated to match. I need to submit a PR to update the Code of Conduct on Cookie Cutter. We updated some real basic stuff, but we never updated it on Cookie Cutter, apparently, which I didn't notice until a discussion came up about which is the next thing, which once I've submitted that PR and it's been merged, I'm going to submit another PR to start a discussion on how to word the Community Code of Conduct. It was brought up that the Adafruit CircuitPython Code of Conduct was going into community libraries, which indicates email supported Adafruit or contact community moderators and so on and so forth if you're running into issues and it doesn't really apply to the community libraries. So we're going to start up PR and then open a discussion on how to word it more generally to refer to project maintainers and projects instead of specifically to Adafruit and CircuitPython. The Feather RP2040 CircuitPython install page was written before we created the template, and so we're going to replace it with the template, which will actually be the first time that we'll be using the page replace feature that was recently added, so that'll be good. I'm adding a CircuitPython Neopixel example to the Rotary Encoder QT breakout guide. It's not intuitive how to use the Neopixel and somebody left feedback on the guide about having some more information about that, and it took me quite a bit to get it going, so I figured add an example to the guide so that other folks don't have to figure that out, and then file an issue on the CSaw library regarding the behavior of brightness in Neopixel. We're not sure how we're going to fix it in terms of whether we're actually going to make it work right or whether we document how it currently works. It works the way it does because CSaw is small, so it doesn't have the beefiness to handle how brightness is normally calculated, so it may just end up being documentation. The Max 98357 fritzing apparently has an incorrect description, need to fix that. The AMG 8833 Feather Wing was never added to the AMG 8833 guide in terms of the board files and the downloads page, so I'm going to be adding that, then continuing on the slide Trinky guide, and finally starting the new QT RP2040 Trinky guide once I get the rest of this done. It's only a short list, right? Yeah, just a couple things. Awesome, we'll keep up the good work, Catney. Thank you. All right, and that's it for, no, I take that back, sorry, almost forgot, Baker Melissa. Baker Melissa, you're up. Okay, let's see, last week I finished up updating the Google Steps on the Ink desk calendar guide. I worked on a guide for running voice to JSON and said Python to create a nice customizable voice assistant. I updated several more boards on circuitbython.org, and this week I'm finishing up the voice to JSON guide and possibly I'll start a new guide with Microsoft Lobe. Awesome, that's it. Thanks, Melissa. All right, now we're done with status updates. Thank you, everyone. Now we're on to in the weeds. This is the last section. This is a chance for us to discuss any sort of longer form stuff that we need to discuss. If you have topics, please drop them in there. Now we do have one to start with, otherwise we'll keep going. Okay, so let's kick it over to V923z for the first topic. Thanks, Scott. So, short one, what is the deadline for 7.0? Or is it already past that? And I would, in particular, like to call out to Jeff and ask whether he still wants to bring in the implementation of this block reader before 7.0 is out. I don't really know what that pull request does. If it's good and you put it in your main branch, then we'll get it next time we pull in microlab. Right, the problem is, so you mentioned that you wanted to convert RGB 565 data or operate on such data. And so I implemented something along these lines. The original request came from Abraham at OpenMV. And I would love to merge it. The problem is I would need a second opinion. And somehow they were enthusiastic at the beginning, but then I haven't gotten any feedback. So if you want that merged, then you would have to say something about the code or the implementation. Otherwise, I would leave it open as a draft, because this is a huge change, not in terms of NumPy or SciPy, because it's not going to change anything on that side. Still, I don't want to bring in something that's half-baked or, well, not properly implemented. And that's why I would need someone to look over my shoulder. Yeah, I see there's a lot of code here. I really can't give kind of a snap. Okay, so my point was not that you should comment on it right away. The question was whether I should mount an effort to tie it up before 7.0 is out, or you don't think that's relevant for 7.0, or it's simply not so urgent. I can gladly put this off. I don't think it's like, if you have any doubts about it, I would say it's not critical. We try to keep our pace up, so we'll always have a chance to integrate new stuff that you're doing. In terms of 7.0 timeline, I would like to start pushing us to finalize all of the API changes we're doing. And I haven't looked at this PR, but if your PR is just adding additional APIs, we can do that whenever. But I can tell you what this is about. So it would allow you to define your own data structure or data container, whatever it is, on the C side. And then you could simply define a function pointer. And I would take that whenever I have to sum, for example, an image. I don't have to get the whole image. I would simply take the function pointer from you. And then whoever is using this feature has to implement the function pointer, or the function that the pointer points to, to return values that could be consumed by the microlap functions. So, well, I don't know how important it is. So I know that it can bring in some nice features. So, for example, if you have a megapixel image which doesn't fit into RAM, then you could still do numerical computation on it, simply calling microlab or numpy functions if you implement the function pointed to by the function pointer. So this is sort of an abstraction layer between microlab and whatever you have. And I don't even have to know what you have. You implement it your way. I don't even have to see it. And then you can simply hook into all of the functions that work with numerical data, which are already implemented in microlab. So one idea was, and I think it was by Jeff, that you could then calculate the average of an image which is encoded in RGB 565. You just have to provide a readout function and with that you are done. So that's the PR about. I implemented a couple of test cases, I don't know, some mean and a couple of others before doing everything or implementing it for every function. I would need some feedback from somewhere. And that's why I'm bringing this up. It's not urgent for me. This was an external request. Somehow it has been abandoned. But if you see some potential in it, then someone should chip in with an opinion on the implementation or the concept actually. No, I think you're approaching it the right way. It's good to make sure that you have people who are bought into the functionality besides yourself. I would say that that's what I would expect on the circuit python side too of Jeff or maybe David stepping up and saying, yeah, I do want to integrate this into circuit python. We do have these structures that are storing data in these packed formats. For interoperability in microlab, that makes sense. But just what you're saying is when we've talked as well, I leave this part to other people. I think for our case, it's good that you're on here and you're advertising it in case people do want it. But I think it's totally fine for us to wait and see. Okay, then let's leave it at that. Yeah, thank you for all your work. It's microlab is really great. Thanks for the prototype. I probably mentioned this image thing in passing, and it would be nice to have someday. But I don't think for Adafruit or Adafruit products that we need to rush this in in order to be able to do image processing on RGB 565 values, there may be a camera someday it's down the line. It's not scheduled or anything. Okay. Well, as I said, it's not urgent for me. I have other things to do. So I just wanted to put this out into the open. If anyone has interests, then they should speak up. Comment on the draft. That was basically my point. Okay. Thanks. Thank you. All right. And last up we have Catney. So I wanted to reiterate the move to main because we are deleting the master branch to avoid the confusion that we did end up with leaving it in Circuit Python. I haven't tested yet to find out what error it throws. You really should be working on your own branch anyway. So it's something that should be pretty seamless. But I want to make sure that everybody remembers and understands that this is a pretty major change and to update everything before you start work locally. Make sure you're running the latest version of the libraries. And like Dylan said, this is something that should be done in the next few days completely. The Git and GitHub guide will need to be updated. It currently refers to both master and main because of the fact that we had interim time where some were on main and some were on master. But it does explain how to deal with a main branch. So while the guide will need to be updated because it refers to both, it does actually refer to main at the moment. So if you need assistance on working with a different default branch, it's there. But I just wanted to make sure that everyone knew this because the deletion of the master branch is going to be the thing that possibly folks run into if they're not aware of this or paying attention, etc. But I'm really glad we're doing this. This is absolutely excellent. It's something I've wanted to do for a while. So I'm glad to see that we're doing it. But it does affect contributors. So I wanted to reiterate that. I will probably continue to do that for the next couple weeks just so that if folks are listening in once in a while, they can get the benefit of that as well. That was all. Thank you. And I do want to point out that we didn't delete the master branch in the core for a long, long time and did have things crop up that were caused by leaving it there. So I think you're totally right in just deleting it right now. Yeah. I thought about it and just decided it wasn't worth the hassle because it's much easier if it just throws an error and folks cannot push to the wrong branch. Open PRs have been hit or miss as a side note. Everybody who's got an open PR, be aware that we can go in and change what branch it pushes to, but every so often, it auto closes a PR and it cannot be reopened. If we run into that, we will contact you and ask you to resubmit or if it's something that is something that someone submitted and is not around, we will probably recreate the PR ourselves so that we don't lose contributions. This is rare, but it did happen. So I just want to give a heads up. I don't. I actually found it in the question is, do you have a link to one of those PRs that was closed? I could find it, but I found I had notes from the first library that we moved over, which was the Circuit Playground Library, and in those notes, I wrote that one of the PRs auto closed and could not be reopened. So I would have to dig through the Circuit Playground Library to find a PR that was closed that couldn't be reopened, so I'm not sure. I don't know that Dylan's run into that since she started the rest of the libraries, but the first time I did it, I ran into a problem. It could also be something that GitHub was working through, if you think about it, because this has now become a much more common place situation, and it may just have been buggy early on. But anyway, just know that if we run into something with an open PR, we'll be sure to contact the author and you can link to a closed PR so we can keep track of any discussion, and that won't be lost. It'll just, it won't be on the current PR. Sounds good. Thanks for giving folks a heads up. Yep, absolutely. All right. This might be a recent record for how quick we've gone through this meeting. So let me do the wrap up. So that was the Circuit Playground Weekly for June 7th, 2021. Thank you to everyone who participated. If you want to support Adafruit and Circuit Python, and those of us that work on Circuit Python, consider purchasing from the Adafruit shop at Adafruit.com. The video this meeting will be released on YouTube at youtube.com slash Adafruit, and the podcast will be available everywhere we know of. It will also be featured in the Python for Microcontrollers newsletter. Visit AdafruitDaily.com to subscribe. The next meeting will be held. Drum roll. Let me look at my calendar. Next week, next Monday, our regular time, Katnney is hosting. This meeting is held on the Adafruit Discord server, which you can join by going to the URL adafru.it slash discord. If you want to be notified about the meeting and the note stock and any changes to the time or day, you can ask to be added to the Circuit Python nieces role on Discord. And with that, we hope to see you all next week. Thank you, everyone. Thanks, everyone.