 Hello everyone. This is the CircuitPython Weekly Meeting for May the 30th, 2023. This is the time of the week where we get together to talk about all things CircuitPython. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that's designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to help support Adafruit and CircuitPython, consider purchasing hardware from their site at adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join at any time by going to adafruit.it.discord. We hold the meeting in the CircuitPython Dev text channel, as well as the CircuitPython voice channel. This meeting typically occurs on Mondays at 2 p.m. eastern time, or 11 a.m. pacific time, except when that coincides with a U.S. holiday, such as this week when we are running the meeting on the Tuesday, which is what we do. So if there is a clash with a holiday, then we will bump the meeting up to the following day, the Tuesday following that Monday. The time stays the same, so 2 p.m. eastern, 11 a.m. pacific on the Tuesday, like we are doing this week. However, I do believe we're back to the normal time and day next week. There is a notes document that accompanies the meeting and recording. The final notes document includes time stamps to go along with the video, so you can use those to skip around the video to the parts that interest you most. The meeting tends to run about 30 to 60 minutes. After each meeting, we'll post a link for the next meeting's notes document in the CircuitPython Dev channel on the Adafruit Discord. You can check the PIN messages there to find the latest notes doc. You can also add your notes into that document throughout the week. There's no need to wait for Monday or Tuesday or whichever day the meeting is going to be. Starting typically within an hour or so of the previous meeting ending, then that new note document will be made available and you can fill in anytime until the next meeting. Speaking of the meeting, it will be held in five parts. The first part of the meeting is going to be community news. This is a look at all things CircuitPython and Python on hardware in the community. There's a preview of the Python for microcontrollers newsletter. However, as the newsletter does ship, so to speak, on Tuesdays, it's not so much of a preview this week, but a look at the newsletter that came out today. The second part of our meeting will be the state of CircuitPython, the libraries in Blinka. There's a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. The second section and the first of our two round robins is the Hogwarts section. Hogwarts is an opportunity to highlight the good things folks are doing. Take the time to recognize awesome folks in our community and beyond. The fourth part of the meeting and the second of the round robin sections is the status updates section. In status updates, it's an opportunity for us to report on what we've been up to. We have a couple of minutes to talk about what you've been doing in the week since the last meeting and tell us what you'll be up to over the next week until the next meeting. The fifth and final section is in the weeds. In the weeds is an opportunity for more long form discussion. These discussions can come out of items in the status updates or they can be things identified ahead of time as too long for status updates. So that covers how the meeting will go. So with that, I will scroll us down to community news. Take a timestamp and start us on the community news. So first item this week is there were two new versions of CircuitPython released. The CircuitPython team simultaneously released CircuitPython 8.1.0 and a new beta 8.2.0 beta 0. 8.1.0 remains unchanged from the 8.1.0 release candidate reported last week and 8.2.0 beta 0 incorporates some interesting new features such as continued enhancement of SynthIO as well as alarm.sleep memory for the RP2040 port. There are links here to the Adafruit blog as well as the release page on GitHub. If anybody is interested in those things. Next up is Microsoft device script for programming microcontrollers. Microsoft has quietly released a technical preview of device script. It brings a professional TypeScript developer experience to low resource microcontroller based devices. Device script is compiled to a custom VM bytecode which can run in very constrained environments. It uses visual studio code extension to make integrated development environment with full debugging. So this is a new way that Microsoft has published for being able to write programs for your microcontroller. We're all of course very used to writing Python programs for our microcontrollers but Microsoft has released this project to allow you to write TypeScript which is interesting. So if folks are familiar with TypeScript and want to give that a try there is a link here to GitHub to check that out. And then next up in the news this week is the project of the week which was a handheld Lora messenger using the WIO terminal. This is a handy Lora messenger. It's built using a WIO terminal with a QWERTY keyboard. The keyboard matrix is scanned by GPIO with the software written in CircuitPython. There are links here to Twitter, Instagram, Tindy and YouTube if you'd like to learn more about this neat little handheld messaging device. And so with that I will tell you a bit more about the newsletter generally so all of these items came from the CircuitPython Weekly newsletter which is a CircuitPython community-run newsletter that's emailed every Tuesday. The complete archives of that newsletter are available on AdafruitDaily.com. 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 you can edit next week's draft on GitHub which is linked here in the notes document. There is a repository for the newsletter and you can find the drafts folder inside there and they're all just dated files inside there so you can find the one for the upcoming date and then edit that to add your news item or project. Another thing that you can do if GitHub is a little bit beyond your capabilities that's okay as well. You can also just tag a tweet with hashtag CircuitPython on Twitter or you can simply email to cpnews at Adafruit.com. So next up we will get into the state of CircuitPython, the libraries and Blinka. A note about this as it says here in the note stock this report contains information from the previous seven days. Any changes such as PRs or issues or anything that's been merged etc that were made today are not included in this report and the reason why I wanted to mention that today in particular of course we are having the meeting on Tuesday where we normally do Monday which means that it has actually been eight days since we last read the stats which means that there is actually one day worth of stats that fell through the cracks so to speak so if anyone's interested the report is still there you can go find yesterday's report if you would like but I just wanted to mention that because it was the bounced week where we're doing the meeting on Tuesday we do have a bit of stats that are not going to be represented in here but we of course appreciate all of the people who made those contributions nonetheless. So for overall section this week we had 51 pull requests merged from 16 authors I've highlighted a couple of names here for folks that were either newer or less familiar to me at least so these folks might be newer or less frequent contributors or it could just be the case that I hadn't happened to see their name before but those names are Charlie Hotel, Pham Huvin, TK Rue let's see here at Alan Torre and Nathan Y3G and Andy Bing so thank you to all of those folks as well as everyone else and my apologies if I did miss anyone who was a newer contributor we appreciate all of the contributions for sure so we had seven reviewers this week so thank you to all of our reviewers those do look like the usual list of suspects so thank you to all the folks who are consistently doing reviews for us of course we can't get folks to be able to become authors unless we have reviewers to look over their work so a very important part of the process is the reviewers thank you to all of those folks and then overall we're looking at 23 closed issues this week by 12 people with 19 issues opened by 15 people so net down a little bit on issues overall next up I will send it over to Scott if you're available to tell us about the core sure okay so that's for the core we had 13 pull requests merged from 11 different authors so thank you to all of our authors we had three reviewers so thank you as well particularly to Mark for doing some reviewing we have 23 open pull requests a number of those are drafts a lot of those are drafts especially the old ones and we're under that like one page threshold that I shoot for so that's great and I'm sure these like two we have what five that are two or three days old so those will probably get handled today or have been handled today already on the issue side we had six closed issues by five people and nine opened by six people so we're actually a little lower than normal in terms of the numbers of people that are involved and we're also plus three issues so we have a total of 648 open issues and we'll work to get those down we have seven active milestones these are used to track prioritization for those of us that are funded by Adafruit those folks that aren't feel free to pick up other stuff as well 820 has zero open issues and there are 36 open issues for 8xx and there's also 30 open issues for 9.0 so that's kind of we're looking good for 8.2 and then we're going to have to figure out and reprioritize for 9.0 which will likely come next we have one issue not assigned to milestone so we'll want to make sure that everything's been triaged today as well so that's it for the core alrighty thank you Scott next up I will hand it over to Katni if you're available to tell us about the libraries I am how's my audio sounds good excellent so this section is about the circuit python and python community libraries it applies to all of the Adafruit circuit python libraries which is everything that starts with Adafruit underscore circuit python underscore as well as the Adafruit community bundle and the Adafruit circuit python bundle and a couple extras so across all of those repos we had 34 pull requests merged from three different authors and four reviewers thank you to everybody who got through those a lot of those were some infrastructure things by one author and almost all of them were reviewed by put in by Tektrick and almost all of them were reviewed by Dan thank you very much to both of them for taking the brunt of this recent sweep and that leaves us with 59 open pull requests we had 13 issues closed by six people and nine opened by nine people leaving us with 614 open issues and 51 of those are labeled good first issue if you're interested in contributing to circuit python on the python side of things head over to circuitpython.org slash contributing you'll find all of this information and more if you're interested in reviewing check out the open pull requests leave a comment, let us know you took a look once you're comfortable with that we can talk about leveling you up to the review team if you're interested in contributing code or documentation check out the open issues they're listed by repository and you can view all the title text so you could do a search and page if you are looking for something specific or you can just find something that interests you leave a comment, let us know you're working on it and go ahead and get started if you are new to everything, good first issue is a great place to start we also have a guide on contributing to circuit python with using git and github so don't let the process intimidate you and we are always available on discord to help you out we want you to be able to contribute in a way that works for you in terms of library pypi weekly download stats the total statistics over 310 libraries or total downloads over 310 libraries was 129,250 and the top 10 libraries are listed in the notes doc, I won't read them off but it's an interesting short view into what people are interested in Neopixel is almost always at the top, no surprise there library updates in the last 7 days we had one new library circuit python underscore NAU 7802 that was a transfer from the community bundle to ate a fruit because we want to be able to support it and the author did not want to continue to do so so we shifted it around and got it to a place where it will remain up to date and we had a few updated libraries that I will not read off that's where we are with the libraries thank you catney next up I will send it over to maker melissa to tell us about blinka if you're available I am, so blinka is our circuit python compatibility layer for micro python raspberry pi and other single board computers this week we had 4 pull requests merged by 3 authors and 1 reviewer there are currently 3 open pull requests amongst all the repositories there were 4 closed issues by 3 people went up and by 1 person leaving a net of 96 open issues there were 12,891 pi pi downloads in last week 7,513 pi builds downloads in last month and we are at 119 supported boards and that's it thanks melissa next up we will be getting into the hug reports section hug reports is a chance to highlight folks in the circuit python community and beyond for doing awesome things I'll get us started and then we'll go down the list alphabetically to give everyone a chance to participate if you're text only or missing the meeting then I'll read the notes for you once we get to your turn so I will kick us off let me get a time stamp here right there so hug reports for me this week thank you to mr good bits I believe on discord who shared some tips and fixes for my code that I was working on during the deep dive this past week thank you to djdeb and 3 for submitting some fixes and improvements across a couple of different libraries and examples in the past week or so and then group hug for everybody and so next up we will hear from dan okay thanks so I'd like to thank all the people who have been doing translations I went back just a little more than a year and there are quite a few people I'll just say them quickly AGS-256 Alvaro Andy Bing Atalantor Bergdahl Bill ADAT Warren Roney Shyamaloon Sanjijiao Electric Algorithm FABFJ Posada 2020 Hextat LisaApple LeeSan00 Naradok Pixel Clay Santus URFDVW Runsiabend Tuamura and Yutaro those people there's a lot of people they've been working on translations it's wonderful to have people doing that because we can't do it so we really appreciate these native speakers and others who are working on translations okay thank you Dan next up is djdeb and 3 who's text only so I'll read djdeb and has hard reports for Atventure and at L.Pakinen for helping with a PWM function for controlling a 4-pin RGB LED over BLE with the Adafruit Connect app djdeb and also has a hard report for Naradok for letting me know I was using the wrong SSD 1306 library and also a hard report for Seagrover for the Cedar Grove Itsy Bitsy breadboard adapter ECB and so with that I will send it over to Jeff next hello I have a group hug and then a hug to Mark and Todd Bot for keeping me interested in the synthesizer work thank you Jeff next up is Katni I have got a group hug for this week so thank you Katni next up is maker Melissa I have a group hug for this week as well Melissa next up is Michael Pocusa who is not present so I'll read Michael has a hard report for me, Foamy Guy for extensive testing and reviewing the PR for Adafruit HTTP server library and Michael also has hard reports for Naradok and Holiday Hero for discussion about implementing a templating engine into Adafruit HTTP server and next up is Scott hello first a hug to TK Roo for two board desks and now CircaPython.org templating experiment hug to Justin for taking a look at PySigRock over the weekend and trying to figure out why the latest version doesn't work a hug report to you Foamy Guy for digging into why hiding lines slows everything down that's a really weird problem and then lastly hug to Chris Reed from PyOCD for meeting with me last week to help with getting the MCU flasher code that I'm working on working on top of PyOCD probes so you can use it from your computer as well that's it for me alrighty thank you Scott next up is Tektrick who I think is probably not here I don't see in the list of discords so I'll read Tektrick says hard report for DJ Devin 3 for great example fixes hard report for me Foamy Guy as well as Naradok and others who have caught and fixed interesting packaging and CI issues over the last couple of weeks and a group hug as well from Tektrick for everybody so that is it for hug reports next up we will get into the status updates section so as a reminder status updates is our time to tell folks what we're up to individually I'll start and then we'll go through the list alphabetically when I call on you you can take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing until the next meeting it's also a good opportunity to provide tips and tricks relevant to whatever people are working on if a discussion does become too long for status updates then we can just go ahead and move it down to the weeds section towards the end of the meeting I will get us started for status updates as well so last week I finished up the testing on the new HTTP server library that included many new functionalities and got that merged in finished up some testing on the EPD library for the typing PR mostly trying to run it on a device and confirm the types of a couple of different values that were used internally inside there I started investigating an issue in display in the core that's causing hidden elements to take extra time to render which I noticed now I did not write a complete sentence about but that's what that is if you have lines that are hidden it makes the display refresh really really slow even compared to the same lines that are visible which seems odd so I started looking into that learned a little bit about it but definitely need to keep going a bit further to find the actual meat of it over the past weekend I did enjoy a bit of time off over the long weekend which included taking a short day trip with my wife over to the next weekend over to see a concert however before hitting the road I did whip out the matrix portal and got a script on there to scroll the logo of the bands that I was interested in which was a fun little thing to do to hype myself up over that weekend as well I also have polished up finished some documentation or maybe let's say started some documentation and published the initial version of a library called somewhat unimaginatively circuit python RGB LED HTTP server which is basically an API that allows you to interact with neopixels and dot stars via HTTP requests so you run this on your circuit python device you have your LEDs hooked up to that and then from other devices on your network you can instantiate the strips and turn them to different colors and play animations and do all that same kind of stuff for this week I have been circling back to some of the typing PRs that went in around the time of Picon but haven't had any action since then to see what I can do to get them moving forward and then I also intend to dig a bit more on that display I O issue that's what I have got for my status updates next up we will hear from Dan okay so last week I made releases for circuit python 810 final and a couple days after that for 820 beta 0 so we're well caught up 820 beta 0 has a lot of synthio changes in it there's still a little bit of work going on on synthio but the API I think is relatively stable now so please try it out I'm working I got this idea after getting frustrated about how long it takes to run make fits of modules to try to make that be port specific and originally thought it might be automatic I'm not so sure that's a good idea right now and I'll talk about this in the weeds but I still think it's a good idea to make it port specific if possible for 9.0 I've started re-reviewing Greg Nevarov's async hyo port from CPython and I will start merging in the version 1.19.1 of micropython and then we're going to do v1.20 Jeff will probably do that so we can catch up to micropython micropython's changes and bug fixes okay that's it next up is DJ Devin who's text only so I'll read DJ Devin says submitted some quick PRs to fix outdated syntax in the SSD1306 and PCA9548 examples within the libraries I think these kinds of code updates could be labeled as good first issue because they're even easier than type annotations and I think those if I recall correctly those are switching like bus.io over to board ITC if anybody knows of more of those those could definitely be a good first issue labeled finished a rechargeable RGB LED candle powered by an itsy-bitsy NRF 52840 the itsy-bitsy does not have battery capability until you put cedar groves itsy-bitsy breadboard adapter on it uses BLE with the Adafruit Connect app to change the color of a single 4-pin RGB LED DJ Devin added Flickr Pulse and Rainbow didn't use any animations libraries the PWM animations are coded from scratch which I am quite proud of people having issues with people having issues running a PyPico with an SSD1306 display and multiple ITC sensors is an issue I see come up regularly in the help with circuit python channel DJ Devin has created a basic example and will be submitting it to the examples in the library user timex40 on Redo is having a hard time getting open sky networks API authentication working with circuit python yes Adafruit has a subreddit API tracks a single transponder or all transponders in a geographic area for multiple let's see for multiple of commercial aircraft types I jumped right in jumped right on it and within a day created three API examples for Adafruit request library there are rate limits and daily limits you get 100 calls per day if you're unauthenticated and 4,000 calls per day if you are authenticated to use the authenticated version simply sign up for the website and provide your username and password in the settings.toml file and so next up I will pass it over to Jeff hello I'm right this moment trying to debug the problem with audio filtering so I need to find our notes document here bear with me for a second so yeah I'm doing more synthio work as I just let slip we merged a great pile of stuff last week but one thing that kind of diverges from what I implemented to what our community wants is in audio filtering so when you want to do a high pass or low pass filter I used an inappropriate technology so I'm trying now to adapt it to what I think is better suited which is a filtering methodology called by quads and that if I can get it going will work on a per note basis so each distinct note or sound will be able to have a different frequency filter applied to it and outside of circuit python I'm working on a project to do a fully self-contained CPM emulator it will use the pico the dvi feather to show your output on display and the USB host feather so that you can attach a keyboard to it and inside will be like a 1980 CPM environment that's literally running those old programs I've been working with the USB host feather today in Arduino and it works pretty slick I hope someday we get that working in circuit python but that's not what I'm taking on right now anyway that's up with me thank you Jeff next up is who's missing the meeting so I'll read Jose says advantage of some free time to catch up with some of the recent foamy guy streams they inspired me to work in a simulation library for the HT 16 K 33 it currently works with the 8 by 8 matrix and the 7 by 4 7 by 4 segments as well as the 14 by 4 segments with similar code to the circuit python HT 16 K 33 library there is a link here in the dock if anybody would like to check out that new library that Jose worked on the other item that Jose has here in status updates worked on worked in the scale library this was a library that Jose created a long time ago but it's now been updated and added to the community bundle and showed the capabilities in discord show and tell channel that's pretty cool thank you to Jose for filling those in in the note stock next up is catney all right so last week published the canary nightlight guide really excited about that ran into a ton of issues getting it going in the first place because there's some issues with my whatever I was writing for my code in the ESP 32 s2 the s3 worked perfectly so luckily I helped from Jeff to figure that out and so on and so forth and you know multiple times figured out the code needed to be refactored and so on and it was a very welcome conclusion to have that done and working I was off Thursday through today and late Wednesday I picked up the 40 dvi feather guide and I started that a while ago and then it got bumped priority wise by other things and then obviously I was not working so this week I will be finishing up the dvi the feather dvi guide was actually much further along than I thought it was which is excellent thank you past me and then the next step is the neokey breakout guide and the TRS jack breakout guide the neokey guide will have code examples etc the TRS jack guide is simply penouts and schematic etc so not much going on with it other than using it no code needed and that's probably what I'm working on this week there's a bunch of other stuff on my list but it's for the next two days that is my stuff in order that's what I've got next up is maker melissa see last week I finished up the magic storybook project guide that I collaborated on with erin the guide is now live I fixed an issue with the circuit pipeline code editor that was preventing text highlighting from working properly and I updated the raspberry pi ST7789 kernel display driver to work with the correct offsets for the 1.14 inch display as we continue looking at the raspberry pi installer display issues then I'll check out some of the work platform detect pull requests and issues I'll take a look at the at some of the circuit pipeline.org that I've coded our issues as well and I'll possibly be updating the matrix portal library and that's where I'm at thank you melissa next up is scott hello okay so I added spy support to the pirate code and got it working with flash ROM which is a cool tool it's usually used for like motherboard chipsets I think I jumped the contents of an external flash so I just had like a metro and I just connected resets so that the MCU wouldn't start and then clipped on to the flash chip and was able to copy the contents off so that was pretty neat I circled back to polishing the MCU flasher code the CMD21 works the 51 works sometimes but other times it doesn't and it works it's pretty bad I need to poke at it to figure out what the J-Link is doing differently because it seems to work still and I need to test the NRF 52 but I don't actually expect any issues with that I'm going to be mixing that with adding one wire and UART support to the pirate code and that'll align the mode numbers in the selection which will be kind of nice I did briefly try TAX, tiny USB host changes for the IMX RT but I didn't have much luck and it can be really frustrating debugging that so I just didn't do it yet so that's kind of on my longer to-do list something that's been on my mind a lot inspired by Jeff that I mentioned before the meeting was I've been thinking about like modular synthesis like Eurorack really is somewhat interesting to me but it's pretty expensive to get into like even just a like amount for your modules like a case is like a hundred plus dollars which I just think is kind of absurd so I've been thinking about a separating the how you interact with it apart from the actual audio generation and I think that Jeff's stuff is really interesting so I was thinking about making these mini synth modules that mirror the classes in SynthIO that Jeff has added would allow you to use it like a physical synth but in reality all you're doing is changing the structure of the SynthIO classes under the hood in Circuit Python so I thought that would be cool and it would be hopefully a lower cost way to get into modular synthesis so I've been thinking about that as well and that's PCB design and all those sorts of fun things too the last leaf for status updates is Tektrick who is missing the meeting so I will read Tektrick says last week applied the jQuery and pylon patch to all the libraries updated the buildci to run pytest and switch all libraries with tests to use pytest added the ability for a couple repos to build wheels for download from pypy started creating a buildci check to verify if libraries are correctly labeled modules or packages and then Tektrick says for this week finish up the new library CI to check on the module slash package verification repair a patch for how docs are built they're currently built from within the libraries docs folder but they will now be built from the root folder which I will have to keep in mind and then the last thing Tektrick says is catch up on a few PR reviews and that is it for status updates so the fifth and final section of our meeting is in the weeds take the top time stamp for that and then I'll tell you about it in the weeds is an opportunity for long form discussions that either came out of status updates or were identified ahead of time and put into the notes document you've got any in the weeds topics please make sure they're added into the bottom of the notes document we do have a couple there now so we will get into those anybody else knows of topics go ahead and add those while we're talking though that way we're not waiting around at the end so first item in the weeds is from DJ Devin who's text only so I will read this one out let me do put a time stamp in there let's see here there are three similarly named circuit python libraries for the SSD 1306 display this cost DJ Devin some time using the wrong library it worked right up to the point of using display dot show and then through errors if it fooled me it definitely could fool someone else also scrolling through the circuit python bundles library bundles slash lib folder you will come upon the Adafruit circuit python SSD 1306 library first due to the alphabetical order there's got to be a better way additional info was added by Dan H it looks like so there's three repos the Adafruit circuit python display I O SSD 1306 which is the newest of the three I believe that one so that's the full name of the repo that I gave if you're using it in code of course you would omit circuit python so that import would be Adafruit underscore display I O underscore SSD 1306 that's the first repo the second repo is Adafruit circuit python SSD 1306 so no display I O in the name this is the non display I O driver so this one was older a little bit I assume the import for that would be Adafruit underscore SSD 1306 again sans the display I O in that one and then the third repo is Adafruit underscore python underscore SSD 1306 which would be imported as Adafruit underscore SSD 1306 capital it looks like and it says here that one was deprecated and archived and it was a CPython library and it's not in any bundle but sounds like maybe that was the oldest one a precursor to all of them perhaps even from before the time of circuit python and then DJ Devin mentions as well there's similar situation for the SSD 1305 as well and there may be a couple others basically any displays that existed before display I O with drivers I don't necessarily know the best way to approach it that would be any different than what there is day though because it's basically like there's essentially two drivers that are supported the display O driver and the non display O driver they both deserve their spot in the bundle as far as I'm concerned we could potentially try to rename one or the other but then there's a whole lot of code out there that uses it that would have to get changed as well for the imports eventually have to change the settings in the repo or something like that if we actually change the repo name I don't know that it would be as much work as it would be to try to make a change like that but potentially it could make it less confusing I don't know it's a bit of a tricky problem I would say I don't think there are very many displays out there that have the older non display I O drivers I run across a lot more newer drivers that are just by default display I O so I think that is kind of the way going forward but there will always kind of be these ones that just did before that and thus have the other the other driver does anyone have thoughts on like naming scheme or any kind of way that maybe that could be made less confusing maybe we could link to each driver and the readme file I'm just going to say like this is the display I O driver for the non display driver driver go here I've seen something like actually I don't even check I mean there are quite a few like just beginning with SSD besides 1306 there's 1351 3125 1305 1327 so there's a lot I mean the SSD is a company right so all of their driver supports will start with all these are frame buff no actually some of them are not display I O so the naming is not consistent yeah I think maybe what happened is they so the original pre display drivers would have been just like a to fruit underscore circuit path on underscore SSD 1306 but then display came along new repo was created with display I O in the name for those drivers that had frame buff versions but then like moving forward I think there's not making frame buff drivers anymore so the new ones are not having that display I O word in the repo I think is the inconsistent part there are only two drivers that are frame buff or at least have frame buff in the description that overlap of the other ones and those are the 1305 and 1306 so ideally to make the name consistent we would name the non the frame buff ones to be like underscore frame buff underscore SSD something and then rename the other ones the other way and do that on a major version boundary and then change all the all the learning examples of which there aren't that many probably if any you mean basically always you mean to change the class name or to change the repo name or both both because we really need to be consistent we really have to swap we have to get rid of the underscore display underscore names now maybe it's not worth it okay we could we could also rename the the frame buff ones to be to include frame buff in the name and then that would make it more obvious so there's sort of like two steps here one is to add frame buff and deprecate the old name and the other is to really almost swap the names or make the display I one be the not be the name without any modifier yeah which I think is how it is on the newer it is it is right right right yeah I think adding frame buff to the old ones probably in my mind the thing that might help the most because that would make it so that when you see the name of the library if it has frame buff in it then it's the old driver and if it doesn't then it's the new driver and you know it will be display oh whether it does or doesn't have display oh although it would be good potentially to be consistent as well and go add display oh to the ones that are missing it but I think even just even just doing frame buff on those ones would probably help out quite a bit in my mind right and I've noticed this DJ Devon is not the only person like I've helped a number of people who had this problem and I myself was confused or I had to ask which driver do you mean you know and stuff like that so I think it's worth at least doing the renaming of the not of the frame buff ones to include frame buff in the name so maybe we can start the danger of renaming anything is that you break existing guides and libraries that you see yeah but it seems to fix the guides so and GitHub does it puts in a redirect automatically when you rename so why don't we maybe when DJ Devon is back online can ask them about what sounds good I mean caddy do you have any particular thoughts about this not really most of what you folks are saying is the things I would also consider above all I want consistency in some form but what that consistency should be for this particular situation is I think the thing we need to make a decision on because I don't really have a suggestion for that part of it so maybe after the meeting like I won't pursue this like maybe I'll just see what is in the what's in the learned guides okay and see how much work it would be to change that and I can report back in the channel that would be good I think that's a that's an important piece yeah I mean we do obviously have folks who can be assigned that to do it but it's important for us to consider like is that worth the time and how much time would it take and so on so I think that's a good next step is to figure out how much work it would be to actually change all this and then start making decisions about whether to change it yeah yeah alright I'll do that I'll do that okay worth mentioning as well I think Jeff put in the chat here kind of with regards to one of the other things DJ Dev mentioned which was that it it was not obvious that he had the wrong library until kind of like the very end all the code was written he ran it and it gave this potentially cryptic error which says like function takes one argument but two are given basically because show in the frame buff driver is not expecting any arguments but show in the display oh driver is expecting either a group or a tile grid um Jeff leaves us with the question could we add specific error handling to show that has a more useful error I think that's also probably a really good idea that would help on those frame buff drivers they could check if you pass them a group or a tile grid um eventually without importing display oh somehow probably would be best um they can't they can't check that then yeah because or I mean really it could check if you pass it anything I suppose we don't even a dummy second argument and like that I think would probably be a good idea as well for the errors because it does if we leave somebody a breadcrumb there um I think that helps make it less confusing overall as well whereas right now like show is going to go away in 9.0 oh what was that show is going to go away oh display that show is going to go away using the property now as well yeah yeah so that we encourage people to use the property so right this would be only for a short period of time that's true which um you can assign an unexpected property of a Python class so that's an error you'd assign the the property and then nothing would happen so that'll actually be a worse head scratcher it's like the display initialized and nothing showed I assigned my group to the root group property or whatever it's called and I got nothing so part of this so making adding a setter that always rejects setting that property to the frame buffer classes basically making those yeah so let me see about renaming them first because that would solve the problem more obviously yeah okay um alright anybody else have thoughts or ideas on that one uh up to the next one I will uh pass it over then to Dan for the next item okay so this is really kind of a build when you clone the repo and then you want to get the sub modules the circuit python repo you do make fetch sub modules at the top level make fetch some modules plural and it's really it's it's been somewhat slow it's really a lot slower now first because of the Broadcom port because there's this Broadcom firmware repo that is huge and in fact that's kind of why we added fetch sub modules instead of just telling people to use the appropriate git command because it would fetch this all of this 10 gigabyte module which is kind of ridiculous and took forever and then also the silabs port has some large sub modules now too which is a problem so uh even though we've kind of optimized that either by using partial clones or by using depth one it still takes minutes even if you have a fast uh fast internet connection so I kind of like if there was a port specific fetch in each ports make file so if you went to say the atmel-sandy port you could type make fetch port sub modules or something like that and it would fetch the ones just for that port um I've been looking how to about how to automate that and then there are two issues about automating it one is which sub modules do you fetch and that the answer to that is maybe we should just have a list but then you have to update it or maybe we should use the directories because everything in lib you may as well fetch and everything in ports name of the port you might fetch but you're not going to fetch a different port sub modules in a particular port and the other thing about automating is should it be something that's done so automatically that it happens when you type make and you're making a board and that's possible too um it's really slow to do that if you if you do uh get sub module update minus minus in it that's like doing it for all the sub modules takes also like 30 seconds which is kind of ridiculous so you don't want to do that because it does a lot of work for each sub module get sub module status if you want to try that you'll notice that it prints something in the first column it prints a space if the sub module is fine it prints a minus if it's never been fetched which you probably haven't seen and it prints a plus if it's like off if it's if it's at the rock commit so uh I started writing a tool to parse that I originally started writing it in shell and that was a waste of time so then I started writing in python um but I kind of want to figure this out and I meant I put this all in an issue and then bill 8080 noted that he sometimes like wants to work disconnected from the internet so he will do a top level make fetch sub module so he said don't take that away because I might want to work disconnected and I didn't hadn't that occurred hadn't occurred to me but I take that as a consideration so is there anything else that in terms of people's work flow that they would like prefer or not I mean I sometimes do something where I deliberately set a commit says a sub module to a different commit than the quote official one in order to do some debugging or something and if the make target tried to reset it every time I might get kind of annoyed about that so that's what I was thinking about maybe not automating that part yeah I think at most it should automate making an initial um making that initial sub module so if it's not there at all if it's not initialized do initialize it yeah I think that would be fine but to ever change it without my specific permission I think is likely to make me lose some of my work um I understand why some folk might want that because then they're freed from thinking about some modules at all and some modules are cognitive load we don't want but I think doing it explicitly is fine but making it making it possible to get less another thing that we have is we have the scripts that the CI uses which are those in tools don't those also make some choices about what to what some modules to initialize depending on what is being done they do but they don't do it in the way they're sort of like use cases different like they're much more interested in doing a shallow clone and using the caches and stuff and I'd rather use partial clones if we can um I'll look at those scripts they're sort of a lot more complicated and I'm not sure if they're as applicable but I'll look at those it would be nice if when we were all down there was just one set and if if you create for instance better make file rules maybe those could be used from the CI process but I'm not totally familiar with what the CI process is trying to do there and it uses a kind of a different technique for figuring that stuff out um which may be better or worse I'm not sure the other thing is that this gets get sub module status function which is actually really useful it only prints things in like a human readable format which is kind of annoying you can't get that information easily um otherwise but I could print a warning like if your sub modules are off maybe this is a nice solution if your sub modules are not what they expect to be when they do make board it'll say hey you need to update your sub modules these sub modules are not what I expect them to be and then somebody who like pushes their repo forward but forgets to update the sub modules would not get confused they'd see that warning so I think that maybe that's the easiest that follows in your your idea of like doing it not doing it automatically but nevertheless we could warn people so maybe I'll do it that way I'll look at all this and I'll also look more carefully what the CI does it's not I appreciate you looking into this Stan I appreciate you looking into it thank you it's really not sub modules are not there's a lot they could be a lot nicer to use than they are you can like get sub module for each it only does for each over the sub modules that have already been admitted it skips the ones that haven't been admitted so that's another complication so you have to parse which sub modules there are manually so if you're doing get there's usually the porcelain flag porcelain is like I want to script it and it's fragile so they call it porcelain yeah but it doesn't have those but sub module doesn't do that it doesn't have porcelain flags yeah I didn't know yeah I'll look more carefully though at that but it's not in documentation at least what I want so I'm ending up it turns out if you use get get config it can parse the dot get modules file because it's a standard format and you can actually extract things from it but it doesn't there's no like JSON output alright I'll stop talking about this because it's really it's even more in the weeds the weeds are very tall here but thanks for everybody ideas about this I've been really liking how fast how much faster fetch sub modules is now anyway it is nice yeah it is yeah I would definitely appreciate any possible improvements on that I don't do it very often and so when I do it's just I go do other things it's much worse for those who don't do it regularly than for those who do which is weird so we don't think about it as much and if you have a slow internet connection it's like go eat lunch yeah okay thanks Dan and everybody else for that conversation that will get us to the end of in the weeds so I'll go on with the wrap up just a reminder for everyone this has been the circuit python weekly meeting for May the 30th, 2023 thank you to everyone who participated again if you'd like to support Adafruit and circuit python and those of us that work on circuit python consider purchasing hardware from the Adafruit shop at Adafruit.com the video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available under major on major podcast services it will also be featured in the python for microcontroller newsletter visit adafruitdaily.com to subscribe to that the next meeting will be at the normal time on Monday next week at 2 p.m. eastern 11 a.m. pacific this meeting is held on the Adafruit discord which you can join at adafru.it slash discord you do need to have the circuit python easter's role if you would like to speak during the meeting so if that is something you'd like to do and you don't already have that role just ask us for it but with that that's going to do it for today so thanks again everybody and we hope to see you all next week thanks everyone