 Hello everyone. This is the Circuit Python Weekly Meeting for January 10th, 2022. It's the time of the week where we get together to talk about all things Circuit Python. I'm Jeff, and Adafruit sponsors me to work on Circuit Python, which is a variety of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing your hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. We hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with a U.S. holiday. In the notes document, there's a link to a calendar you can view online or add to your favorite calendar app. You can also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the Circuit Python East's Discord role. And early warning, next week's meeting will be held a day late because in the U.S. we will be observing Martin Luther King, Jr. Day on Monday. I mentioned the note stock. It accompanies the meeting and recording. We add timestamps to it to go with the video, so you can skip to the parts that interest you the most. As we tend to go over 60 minutes sometimes, it is a really great option to have. After each meeting, we post a link to the next notes document in the Circuit Python Dev Channel on the Adafruit Discord. You can check the pin messages to find the latest note stock and add your notes throughout the week, or at least in advance of actually starting the meeting. And if you wish to participate but can't attend, you can leave your hub reports and status updates and just mark it that we need to read it out loud for you. So, the structure of this meeting, we hold it in five parts. And next up is community news, a look at all things Circuit Python and Python hardware in the community. It also functions as a preview of the Python on microcontrollers newsletter. Next up after that is the state of Circuit Python, the libraries and Blinka, a statistical overview of the whole project, a chance to look at things by the numbers separate from what we're each up to. Next up in the first participatory section is called Hub Reports. We take an opportunity to highlight the good things folks are doing and recognize the awesome people all around us in the community, on Discord, the forums, GitHub, YouTube, Twitter, and beyond. Even the real world can apply. The fourth part is status updates, the opportunity to sync up on what we've been up to. Take a couple of minutes and talk about what you've been doing since the last meeting and what you'll be up to until the next time we get together. And then the last part, if there are items and I haven't checked, is called in the weeds. If we need to do a more long form discussion, something that you've identified beforehand or something that comes up during status updates, this is the place to do it and add just at least a placeholder as to your topic as early as you can and we'll cover them in the order that they are in the document. And that is how things are going to go. So next, we will turn to community news and topping the list is the Circuit Python in 2022 survey. As 2022 starts, Scott Shawcroft lead Circuit Python developer requests the Python on hardware community take time to share their goals for Circuit Python in 2022. Just like in past years, and there are some links to the previous three years of documents in the notes, Adafruit would like everyone in the community to contribute by posting their thoughts to some public place on the internet. Here are a few ways you can post a video on YouTube, a post on the Circuit Python forum, a blog post on your site, a series of tweets of tweets, or a gist on GitHub. Please consider sharing your thoughts. When you post, please add hashtag Circuit Python 2022 and email CircuitPython2022 at Adafruit.com to let the teams know about your post. And then we will blog it up on the Adafruit blog, and I think Scott will be doing some summaries later. And so we call this a survey, but it's really free form. You fill out three pages of How Satisfied are you from a scale of one to seven? This is more an essay form. So check out those past years and tell us what's on your mind. No matter what your experience level is, we want to hear from you. So please do it. Next up, Tyobi declares Python programming the language of the year 2021. We've won the second time in a row. This award is given to the programming language that has gained the highest increase in ratings in one year. C-Sharp was on its way to get the title for the first time in history, but Python surpassed C-Sharp in the last month. We started at position three at the beginning of 2021 and left both Java and C behind to come the number one of the Tyobi index, but Python's popularity didn't stop there. It is currently more than 1% ahead of the rest. Java's all-time record of 26.49% ratings in 2001 is still far away, but Python has it all to become the de facto standard programming language for many domains. Next, using both cores of a Raspberry Pi Pico in MicroPython, DIY Electronic Music has been doing MIDI slash musical visualization projects with the Raspberry Pi Pico. Dual use of an LED matrix and a 4x7 segment display was a bit slow, so they looked to use the unused core on the Pico to provide extra processing power. One core, this is a quote from DIY Electronic Music, one core is listening to the MIDI and updating the LED matrix. The other is keeping the eight-segment LED scanning showing the latest MIDI command slash node received. And there are a bunch of links. Thanks for getting those for us, FOMI Guy. Next up, we have Product of the Week, an LED choker. This is a very stylish and wonderful alphanumeric necklace that you can make yourself. They say, My new favorite project, a text display choker for status updates at the club, uses an Adafruit alphanumeric display featherwing and a feather M0. Protogrid hosts a button to switch patterns and CircuitPython lets the owner edit the code to add new text. Another project, it is a keyboard. It is the CircuitPython plus Raspberry Pi Pico USB HID, a tiny 2x8 inch keyboard and there are links on YouTube, Hackaday IO and Reddit. And there is a lot more. This is just a preview, so that was not a great segue. 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. To contribute your own user project, edit next week's draft on GitHub and submit a pull request with the changes. You can also tag a tweet with hashtag CircuitPython on Twitter at adafruitdaily.com And anyway, what I was trying to say was this is just a preview, there is a lot more in there. So, subscribe if you're not a subscriber and also send us your projects because again, no matter your skill or experience level what you are doing is cool and we really love hearing about it. And yeah, that's it for the community news. Next up is the State of CircuitPython, the libraries at Blinka. So, we've got a lovely little script known as Adabot that gathers statistics from GitHub every day covering the last seven days. And I'll start off with these statistics that cover the whole project which is the core of the libraries at Blinka. We had 38 pull requests merged from 25 authors and some names that are less frequent or unrecognized by me were the Infinity S. Tokland Pontus O. B. J. N. Hur Aaron Tusko Electrical Electric Algorithm and Danny Staple And then in reviewers, I just want to give a shout out to the kitty our very own Anne B for doing some reviews here in CircuitPython land. And with that I will hand it to Scott to tell us about the core. Hello, thank you Jeff. Okay, so the numbers for the core. We had 11 pull requests merged from 11 different authors which is awesome. I won't highlight the new names here because Jeff already covered that. We had four reviewers for those 11 authors so thank you to all of our reviewers for supporting our authors. We had 14 open pull requests. Basically three of them are 100 days or older so as always please if you're involved in some of these pull requests that have been around a while please decide whether they should be open or close them if we want to do them a little bit later. So that's where we are in pull requests. Issues-wise we had eight closed issues by four people or opened by four people for a net of 464 currently open issues which you can see by going to github.com www.shrut.com.au www.shrut.com.au We track kind of where we are with issues by making sure they're triaged and kind of prioritizing them using the milestone system on github. We, 7-1 is released but we still got a milestone with zero open issues which is good. We have a 7-2 milestone with four open issues and we have 17 open issues for 7.x.x. Those are kind of like the most urgent things. And then we have one issue that's not assigned to milestone that we'll need to take a look at and sort out. But I think that's it for the core. All right, thank you Scott. Next up is Catney to take on the topic of the libraries. Thanks Jeff. So this applies to all of the Adafruit Circuit Python libraries which is everything that starts with Adafruit underscore circuit python underscore as well as a few extras such as our community bundle. So this week we had 20 pull requests merged from 12 different authors and 8 reviewers. I want to call out that amongst those merged pull requests, 8 of them are 22 days or older and the oldest one was 304 days. Which is amazing because it means we're getting through some of the older pull requests and that leaves us with 33 open pull requests across all of those repos. There were 19 issues closed by 9 people and 13 opened by 13 people leaving us with 637 open issues. 239 of those are good first issues. If you're interested in contributing to CircuitPython and the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more. If you want to join us in a reviewing capacity check out the open pull requests and see if anything interests you. If you have the hardware test it, if you don't take a look at the code and know that you did, that is super helpful. If you want to contribute code you can check out the issues. Good first issue is a great place to start if you've never contributed before. Otherwise bug or enhancement are also good things to search if you're looking for something a little more complicated. Leave a note on the issue that you're working on it and we are always available to help you. We wrote a guide on I wrote a guide on contributing to CircuitPython using Git and GitHub as well. We are available on Discord all week long to assist you. We want to make sure that you can contribute in a way that works for you. In terms of library updates in the last seven days we had two new libraries added to the community bundle. ANSI escape code and non-blocking serial input and a number of updated libraries which I will not read through they are available in the notes. Overall we're still getting through the older pull requests so if you have a older library PR expect to see some action on that sometime soon. Which is really great to see an early hug report to PhoneMeGuy for working through that. That's what I've got. Thank you. And then to finish this section I will invite Melissa to tell us about Blinka. And we can't hear you Melissa or at least I can't. Alright well I will just go ahead and read out that section then and we'll come back to you when we get to hug reports. So Blinka is a Python library that brings circuit Python compatibility to the Raspberry Pi MicroPython and other single board computers and in the last week we had seven pull requests merged from four authors and three reviewers leaving six open pull requests and issues-wise there were three closed issues by one person leaving 69 open issues the number of PiWheels downloads in the last month was 14,001 and the number of supported boards is 87 and that is the status of circuit Python. Next up is the section of hug reports. Hug reports are kind of antidote to bug reports we want to hear about people here on Discord in the community and beyond who are doing positive things to make a difference and usually we concentrate on circuit Python stuff but you know when you need to give a hug we want to hear whatever it is. This week I just have a group hug because y'all are great and I've been enjoying the few circuit Python 2022 posts that have come in so far and yeah so an extra hug to everybody who has written those or who is on the fence to write one um yeah so that's what I got. Next I will read notes from Cgrover who is text only and Cgrover has a hug to Foamy Guy for last Saturday's very informative stream not only did it help to explain some missing details of circuit Python board definitions it also showed some examples of excellent code plus documentation in the circuit Python PR pipeline particularly that of 560 alright and next up is Dan hello. Okay um well I'm jumping the gun on with something that Scott has been doing which is to help our helpers in Discord I'll mention in the circuit Python channels Jerry Naradak, Deshipu, and Anikdata and then in the other channels that are not circuit Python related but I'd like to also mention Ichiro Furusato and Mad Bodger, Ed Keys, Todd Bott Scare and Ben Minus and I'm sure there are others that I forgotten at the moment they've really made this a great community for people seeking both help with both the circuit Python and with other things okay thank you Dan here here um next I have notes from David who has a hug for Katny for making the floppy disk playlist on YouTube and one for FOMI guy and others that left ready to use vector IO sample code in issues I made all of my tests based on resolved issues they are known to be working minimal pieces of code alright and next is FOMI guy alright thanks Jeff uh hug reports this week first to GitHub user 560 um who did a PR recently on the APD S9960 they left a really really nice PR with a lot of great details and empirical testing data and all kinds of rationale for the changes they made and stuff like that so I wanted to highlight that person who did again a really great job on a PR for that library to you Jeff you had a post about the matrix chat system which I was not familiar with other than KMK is the only time I ran into it and you had posted some information on discord that uh finally gave me a better idea of the bigger picture of what that system is and how it works and I appreciate that to NeroDoc lastly as well for testing out a PR on HTS 221 library and then NeroDoc also suggested a good improvement this weekend for one of the recent changes to the DPS 310 library and we got that improvement put in over the weekend so thank you to NeroDoc for that and that's what I have, thank you that's great, thank you next I have notes from Jerry who's missing the meeting today but has a hug for the continued improvement and expansion of the Broadcom port and to Dan for jumping in to add deprecation warnings to the TinyLaura guides and next we have Katny, hello hello so my first hug is to Mark Gambler for the updates to the IS-31 FL-3741 library and patience with me getting to sorting it out where the updates should live it's a foamy guy for continuing through the older library PRs to Sheehan one of our learn developers for sorting out a script to convert a template page to a static page and learn for an unusual situation I ran into with refactoring a specific template page it saved me a ton of time and frustration in manually copying a very lengthy guide page to P.T. and LaMoure for incredible support during a rough situation to Jeff, Dan, Anne and John Park for further support and a group hug to everyone else alright thanks Katny next I have notes from Keith and then Melissa let me know if you want me to read your notes or whether you want to try it again anyway Keith the EE says hug report to everyone for being such a welcome and helpful community alright go ahead Melissa okay can you hear me now? yes I can let's see I just wanted to give a group hug to everyone alright thank you next up we have Scott hello hug report to Naridoc, to Shippu and A.N.I.C.T.D.A. for really being helpful with folks in help with CircuitPython over the weekend in particular there was some person that was a little upset that it wasn't as easy as we had claimed it was and they were super patient with them I admire because I don't always have that patience and I'm realizing I should have thanked the CircuitPython 2022 folks as well but I'll wait until next week to do that alright and Zoltan you get to round out the section thanks Jeff so I haven't been around for quite a while I just couldn't fit the meeting into my schedule but first I would like to start out with a group hug it's good to be back and second I would like to acknowledge Jeff's hub in the past six months he's been there always on GitHub at least whenever I asked the question he was I don't know happy to jump in but at least jumped in so thanks for that Jeff alright you're welcome I'm laughing a little bit because you and the other contributors you do the bulk of the lifting and it's like I come in with one little piece so anyway thank you for that I appreciate it yeah but that's the missing piece of the puzzle so that's quite crucial alright and with that we will move on to status updates in this section we invite you to tell us about what you've been up to since the last time we had a chance to chat and what you're getting up to in the near future and this is a round robin just like hug reports I will start and then we'll go down through the alphabet or at least the order that things are in here because it doesn't always follow the alphabet anyway so last week and this week is centered around floppy disk drives last week I got basic flux reading working in circuit python flux of a little pulses of magnetic data that are on the the floppy disk and this week the goal is to add real time MFM decoding and I have a plan so when that's done I'll be able to say questions like okay what is the actual content of track 1, sector 1, head 1 of the disk and get it back as binary data so that'll be cool if it works when I do need a break I'm going to see about implementing the PIO code for 8 parallel neopixel strips without a shift register and that will support the upcoming Feather Scorpio product I have a pull request in Adafruit PIO ASM that I need to return to and in other news I did a pure C program with ESP IDF it was a lot of fun and there's a link in the notes document it is so a lot of GPSs have the ability to do a one pulse per second output and my friend wanted something like that but he wanted to top rate off of the wifi network so this thing gets the time with NTP and then it just makes a pulse every second for 100 milliseconds forever it was fun to do just a simple C program anyway, so that's what I've got and next in the document is Dan so we'll go slightly out of order go ahead Dan oh, okay, I can alright, that's alright so last week I wrote an example of using neopixels with async.io so you can control the speed and direction of a neopixel animation that's sort of a canonical example and that will get used in a bunch of places probably you can't see it yet because it's still being reviewed in CircuitPython 7.10 the PDM microphones stopped working on CPX and in general and I'm really puzzled as to why I found one problem but that didn't fix it, it was just making something volatile and so I need to do some more extensive debugging like going back to a version that seems to work which is also problematic it turns out and this was all stymied by some kind of new bug in the Linux kernel where if I stop CircuitPython like in GDB and so the USB connection goes away then the USB driver in Linux now gets so upset that it takes down all the device, takes down the entire USB controller including all the devices on it like my mouse and keyboard so I have to SSH in from elsewhere and reboot, it's ridiculous so I've upgraded to the upcoming Ubuntu 2204 which has a newer kernel I had tried a newer kernel in 2004 and it seemed to be better but there are other problems with using a random kernel that's not signed so I'm trying 2204 so if other people see this problem let me know also they made some mistake and I don't know what it is okay, thank you all right, next I have notes from a couple of people first, Cgrover writes a week of refactoring disassembled and rebuilt the retro RPM calculator code followed by the redesign of three PCBs to accommodate a new round of scarce part availability issues upgraded to existing IoT projects to CircuitPython710 and lined up four more for similar treatment depleted a large share of my maker budget with an Adafruit order and finally found a suitable round TFT display for the 6E5 magic eye project a flexible PCB will be needed looking forward to the experience my first and then David notes under the heading of CircuitPython testing display IO and vector IO on a Raspberry Pi 0 2W changing screen resolution and searching for floppy drives, floppy disks and floppy cables in non-circuit Python news drilling holes in thick walls finding acceptable paths between rooms to place Ethernet backhaul for a Wi-Fi upgrade and better connectivity where I am teleworking and next up is FummyGuys so take it away Tim all right, thanks Jeff this last week I should say I wrapped up the guide for the busy simulator Pi Portal and submitted that in for moderation so that should be coming out soon continuing on with PR testing and reviews, like Catney mentioned a couple that stood out to me this week that I will highlight are DPS 310 library which now has a minimal basic version which makes it easier and or possible to use on some of the smallest builds and then you can also import the advanced one to get all of functionality from that driver and the APDS 9960 which is the little light-based color and gesture recognition sensor and that one got some improvements that make it better at recognizing gestures and also got kind of a really nice overhaul on the documentation page as well in that library so some cool stuff this week or last week again I should say for the stuff coming up this week there are projects on the table a web telescope the James Webb telescope that is currently I guess in space on its way somewhere not entirely sure where it's going but it's part of the way there and I'll be able to keep up with the status of exactly where it's at using a new Pi Portal or MagTag project that will show the current status of that and then another one that I think will be fun coming down the pipeline this week is some llama-based nostalgia with a Winamp skinned MP3 player for the Pi Portal so there are apparently this was a little news to me but there are apparently thousands of these Winamp skins out there that are just kind of ready-made little gooey packages with BMP files in them so we can kind of reuse those and make an interesting little Winamp mock player on the Pi Portal which sounds like a fun project this week also I want to continue building out documentation for the Minecraft Feather I'm putting together a repo with some markdown files that show how to set it up I think I also want to shoot a video that shows the setup process it's a little bit involved to get everything going for it so I think a video will be a good format to show folks how they can make that themselves if they want and this week I also need to write a post for CircuitPython in 2022 and that's what I have going on thanks. I hope you enjoy that Winamp project I suggested you for it because you know so much more display I.O. than I do so that was the genesis of the suggestion there. I think it looks neat I definitely think it looks like a lot of fun to play with I'm pretty excited so thank you. Alright, Katnie you are up next. Alright so last week was a short week for me I sorted out a home for the IS-31 updates added mirrored CircuitPython pages to the QDPy ESP guide and merged the ESP32-S2 bootloader install and the ESP32-S2 factory reset templates to prep for for gutting the bootloader install template what happened here was we ended up with two templates that had a significant amount of duplicated information and most folks are looking to factory reset they want to get back to where their board started then more folks are in that situation than our folks who need to install the bootloader so the bootloader install page is still going to exist it's still going to go in all the guides but it is instead going to point to the appropriate section in the factory reset template so if folks are like hey I want to fix my bootloader I clobbered it they'll go and they choose to go to that page it links to the appropriate spot on the other page but there's no more duplicated information that way if we do need to update something we're updating it in one place not two which is always our goal so that was merging the two in preparation for gutting the other one which I didn't do yet because there's I have to actually go and link appropriately in the guides that the template already exists so so this week starting the Feather TFT ESP32 guide I'm going to get that done just enough to make it live so real basic pages and then refactor the bootloader install template page and then fix the instances of it that are already existing in guides then I'm going to bounce back to the Qtpie ESP guide and finish that up which involves adding the circuit python essentials templates and I think a couple other things and then once that's completed bounce back to the Feather TFT guide and finish that once both of those guides are out of the way I'm not quite sure the order in which the rest of this will be done but the arcade Stem and Qt breakout needs a guide the MCP4725 has been updated to have Stem and Qt connectors on it and so that guide needs to be updated for the Qt version I need to create a circuit python essentials .star status LED template there's already one for multiple LEDs so really it's just copying and pasting and making LED and .star singular not plural so that'll be quick and then creating a circuit python essentials template for async.io which the example that Dan thought was going to be reused in multiple places is that it's going to be reused there for sure so that'll be the example for async.io that will go into all the board guides so everybody can when they go to the board guides we'll see async.io exists and what you can do with it in basic fashion and then any other miscellaneous stuff that comes up but this is definitely going to last me for a week or two so you'll probably see quite a bit of this next week as well thank you next is maker melissa hello so last week I finished up the blink of display .io changes that are and was able to leave it in a working state it's not completely redone but if any community members want to work on it I'd be happy to provide guidance I added a bunch of the missing boards to circuit python.org and they started working on porting little fs to javascript to use with whippersnapper and this we call continue porting little fs and that's where I'm at alright thank you next up is scott hello I'm just about wrapped up on the raspberry pi it's still somewhat unreliable on the sd card unfortunately but it's not clear to me how bad it is and I don't really have any leads so I'm going to leave that I do need to finish up the learn guide that's I think my going to be my goal today so that we can get it in time for the shows on the Wednesday I also am working on a branch that enables turkish builds electric algorithm has been requested and has been translating for turkish and I know that it's great for the translators to be able to actually get access to the builds for that so I think it's ready I took a look in the core messages seem to be there although I'm sure there's some work to do but I it's I think it's motivating to see that so I want to do that today if I might have to do some I'm hoping I don't but I might have to do some tweaking to get things to fit but we shall see that's why I have a build going right now just off my own bridge so that's going on after this raspberry pi stuff is kind of like finished up there's one PR to get in and that should be easy it's all green so I think I'll go in shortly once I'm past that I'm going to ramp up back up on the ESP32S3 I watched Desk of Lady of the Last Night and I'm pretty excited about all the different cutie pies that she's been making and so although I'll be working primarily on the S3 a lot I'm hoping a lot of the work that I do does translate to the C3 and the ESP32 in particular I'm looking at adding BLE support which would be really cool so I'm going to make sure there's no major bugs on the S3 that it works okay hammer those out if they come up but I think BLE will be my focus besides that I also want to do my circuit python 2022 posts this week I know there's been a few coming in so thank you to all those folks I've got a couple more small ones to post on the blog today and I do want to let everybody hear now first one of the major things that's going to be in my 22 is that I'm not actually going to be working the entire year because my partner and I are expecting our first kiddo in March which I'm very excited about but it means that I'll basically be out April plus or minus two weeks depending on when the baby comes and then it's looking and this is depending on when the baby comes but I'll be taking a 12 week stretch off kind of later in the summer as my partner goes back to work and that's looking like if the baby hits their due date it would be like late August through September and October that I would be out so not a whole lot of major projects for me because I will be figuring out how to be a dad as well but I want to let everybody here know that when you hear me talk about what my personal plans are in terms of what I'm going to be working on this year that's a major factor in it so I'm excited, we're excited so my hope is that my goal is to get kind of the S3 BLE stuff wrapped up before I go on leave which we'll see so yeah I'm excited last up the Washington State Legislature is back in session and they are starting to do committee hearings around some broadband and digital equity stuff that I just can't not testify for there's also a right to repair bill in committee on Thursday so I'm going to be a little distracted with that but I'm hoping it's not going to be too bad it's all zoom so it's just going to be me in committee meetings and hoping to testify and provide some influence over what these bills include and if you want to know more about that I'm happy to I know I think C Grover is actually in Washington too so if you want to know more about that I'd love to talk about it well I'll just say on behalf of everybody who may be listening in stunned silence congratulations to you and your partner and all the best wishes for that stuff what an adventure you're going to have I know fingers crossed that the hospitals aren't too bad by the time that we decide to have a kid by the time the kid decides to come alright let's not worry about that just yet anyway once again to round out the section v923z take it away thanks Jeff so I have just released version 4.0 of microlab that adds optional complex support this has been a recurring request from the community I was fighting this off but unfortunately I had to realize that there are functions that produce complex results even if the input is real so it turned out to be inevitable this version also adds a couple of new functions and with the help of some members of the circuit python community not least Jeff we squashed quite a few smaller bugs so that's what's included in 4.0 and recently people have opened quite a few future requests so in the coming weeks I will be working on those and that's about it from me alright thank you we probably need to figure out when to pull request version 4 into circuit python soon as well so give us a reminder if someone namely me doesn't get around to that alright anyway with that we will pass on to in the weeds this is the time that we do longer discussions that don't fit within the other portions of the meeting and it looks like we've got a couple of topics and I will then pass things back to you Zoltan because you are our first well if Tim wants to stop his topic then that's fine with me oh no I think oh do you need to down you decide I was going to say either way is fine with me okay well if you have to leave earlier or something like that then just go ahead I am good to go okay actually I think I have formulated my question in writing what is the best platform independent way of writing data to a file and I have one way which works in Unix but I don't know if it's really platform independent that's what I listed and then then posted a different solution so I just wanted to ask what is the difference between using a stream or using first stream and then going with that pointer or using f write or f write to write the data to a file what are the differences I tried to wrap my head around this but I have to admit that it's probably too deep in the source code of micropyton and I couldn't really dig out all the details so basically I just tried to hijack the vid open context manager and I think this is what mp built in open does but I am not quite convinced that that's the best way so if anyone could comment on this I would be grateful and to give context to the issue someone wanted to actually write numerical data or arrays into a file in order to exchange data between the PC and a micropy or a microcontroller and we decided that the best way probably would be to use a standardized numpy save function and it has a very well defined format which I implemented but I still have to write the data to this so if anyone could comment on that I would be grateful so did you want to write to a file specifically or to some stream I want to write to a file so what numpy.save does it takes two arguments a file name that's a string actually so you have to open the file with that name and the array and then writes the contents and some header into that particular file so I don't really need streams it just seems to me that I could use streams but I am not claiming that that's that's a proven solution so if you say that fopen and fwrite is better than I'm they're just a little they're closer to what's going on at the lower level but if there's any if there are other numpy functions that write to a stream then maybe you would want to do it in a different way that take an open file or something like that so I looked up how to do it only to do this writing to boot out that text so that's the only reason I added that is that I had to book this up a few years ago so the distinction between those two pieces of code one well they're kind of the same thing and Dan was getting at it a little bit there's what are you writing to is it any kind of thing or is it in this case the amounted DOS file system so in Dan's code there is this initial FS argument and in the code that writes out the boot out.txt we already we always excuse me we know that where we are writing the location of that is within the circuit Pi drive if you were to mount an SD card then you would have to figure out which FS object is associated with the SD card there'd be more than one but when you use the open when you call built in open like you do then it does these steps of interpreting the path so if it starts slash SD and you've mounted an SD card there will automatically switch the access over to the SD card and that is a very nice thing to have otherwise it would come back and say I tried it with an SD card and it doesn't work okay so I have a full example of doing this to write things in the GIF IO module in circuit Pi so if you want to see how I did it there I would recommend taking a look but it's very similar I use mp get stream raise to get that object that has the right thing in it and of course for my purposes I have to check if it's opened in byte mode or not because if I wasn't in control of the opening then it could be in either mode you're gonna be in control of it yeah and then I just call the proto points at write and later close okay that would have been my next question I have to close the stream because the context manager does that but that doesn't work at the C level so that's true yeah okay so what's missing from my code is definitely this instruction to close the stream yeah and that's a little bit weird it involves calling an IOCTL if you look at that GIF IO code it's working and tested okay thanks a lot now that's great thanks a lot so I think with that I would just pass it on to Tim wait wait wait I wanted to add a couple things to this as well the solution that you have that uses the stream stuff I would imagine the micropython people want you to do as well because they also support non-FATFS file systems yeah that's right so that is what I imagine as well and then the other thing I would caution is that I think these calls may end up back in the Python VM so just make sure that you're aware of that what does that mean it means that like you're in C but you may end up actually running Python code okay that doesn't always happen so just be aware of that okay but what are the variations of that all my kittens will be killed or what will happen if that happens I don't really know I think general I think it's less likely in circuit Python because we're just fat focused and the underlying fat stuff is all in C again but you are kind of going through you may go through one layer of instruction because I think right can be Python implemented okay and so it's just a like Python currency thing right you have to be aware that like some Python code could be running intermingled with other Python code okay yeah well that's good to know so yeah it's just like if weird stuff happens that might be why the SD card support in MicroPython is written in Python right so that's an example of where you go from Python into C and back out to Python okay well this might might be a bigger subject but actually I wanted to ask what is the way of mixing Python and C code so NumPy uses this notion of passing arguments in Python mainly and doing only the low level stuff in C but that means that you have a library which is part Python part C and I couldn't yet figure out how to do that in MicroPython so because MicroLab is actually compiled into the firmware so that's not separate as NumPy from Python and at the same time you would have Python code and C code and you would want these to be under the same namespace so I think what them pointed to was that I could do the file handling in Python and simply generate the row string or the row byte string in C and then pass it on to Python and that would write the data to wherever it has to write the data but that would require that I mix Python code with C code and I'm not quite sure I know how to do that or if it's possible at all well it's already done for instance SD card access in MicroPython does that and there are other examples of frozen or not frozen okay so MicroPython code gets called from C I can't remember another example but they actually have some other I think there's some other examples so okay so it's an interesting notion so you are saying that it's possible and then I should just the SD card handling well it works because when it's doing a write to a stream the stream code just takes a stream object of which an open file is could be a Python object and it knows that I'm trying to remember some other examples but there was several times I've seen recently in MicroPython and it was like we don't need to write this in C we can just write it in Python but it might get called from C there were some other examples and maybe there would be like if you ask in MicroPython 4 or something or look in there you might find some similar examples okay that's a great idea thanks a lot so I think I should really pass it on to Tim now thanks for the comments alright thank you go ahead for me guy I think let me pull the notes back up so the root of this issue is essentially do we want to include requirements in libraries if those required libraries are only used for typing so an example of this which I linked in the doc there is to the requests library the requests library recently got typing and some of the types come from things like the whiznet library or the ESP32 spy library and those are only used for typing inside requests it's perfectly fine for you to write a codepy that uses requests and you will probably have one or more of those libraries in order to connect to the internet on your circuit python microcontroller but it won't rely on anyone in particular for requests to actually import since it's only used for the typing so the root of the question is essentially do we want to have those as you know quote unquote real requirements put them in requirements.py and I guess maybe setuppy or somewhere I'm not sure if there's other places where it would need to get listed so that those get installed ultimately we need them all to get installed inside of the actions container when Sphinx runs I think we need them all in there at least so that it can include the right links and the right types for everything that it has access to do we want it to be okay like if you are not that if you're just running it on a microcontroller you're not worried about the Sphinx container or building the docs is it okay for it to get distributed without those requirements essentially that's kind of the first high level question and then I think there might be followups I guess depending on which one of those two directions we kind of side on well I'm pretty sure that for circuit we wouldn't want to install all of those onto the circuitpy drive it's kind of my first thought and then my second thought is this is probably this might be something that would be better handled by defining an interface I think was the technical term within typing which we did for something just recently in circuitpython there was a case of can I yes it was for font exactly somebody wanted to add static typing to say a font is required here and they had a choice of listing built-in font and bdf font and pcf font but the other alternative is to create an interface object which just lists the methods and properties that something has to have to work with this and so basically you'd say the type would be a socket interface instead of listing out all these individual things and that is what I would be tempted to do so that and that would if I understand correctly that would remove it as a requirement entirely essentially the requests would go back to being fully self-contained with everything it needs right that block from line 46 to 51 would not be there it would be replaced with other stuff okay okay yeah I think um that makes sense yeah that makes sense to me I like that so that we don't have a bunch of extra added on requirements and then I guess it just kind of depends on how you run into a situation where it's not quite like that or I don't know if there's any others that have come up but it may be the case that any kind anytime we run into something like this it might be better to side with just making that a little prototype or whatever the little internal one is there's also a requirements.txt within the docs folder I noticed that one I didn't know how it behaves exactly though or is it okay to add yeah I saw something but I didn't know if it you could add stuff it's not ideal because if we do need to update that then the patch would skip it because it's different but in like obviously we have files like this that are different in different libraries when there are one-off situations where there's no other options it sounds like we have another option here so I would opt for that but for your own future reference if we do run into a situation where we legitimately need to have some kind of requirements for things to work and it's on a library that is meant to run on smaller boards and we can't add new requirements because project bundles would then download them and everything would be out of memory and so on then that is available that's good to know then I think that answers it for me it sounds like probably the action item is just to eventually make a PR for requests that changes that over to use more generically defined types right inside of requests instead of importing I will throw that on my list and I think that is everything I wondered about for today alright great and that was the second item in the weeds so now it's time to wrap it up and I just need to find my spiel for this this has been the circuit python weekly for January 10th 2022 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 of this meeting will be released on youtube at youtube.com slash Adafruit and the podcast will be available on major podcast services it will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe the next meeting will be held on Tuesday I believe that is January 18th at the same usual time 2 p.m. Eastern 11 a.m. pacific because on Monday we will be observing Martin Luther King Jr. Day in the United States the meeting is held on the Adafruit discord which you can join 24-7 by going to adafru.it slash discord to be notified about the meeting and any changes to the time or day you can ask to be added to the circuit pythonistas role on discord we hope to see everybody next week thank you very much all thanks everyone