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


Hello friends, in today's session, I am going to deliver lecture on work energy principle, myself, Bipin Patil, assistant professor, department of civil engineering, Valchan Institute of Technology, Solapur. So these are the learning outcomes for today's session. So at the end of this particular session, student will be able to, first one, explain the work energy principle, few points we are going to discuss here, what do you mean by work energy power and this work energy principle and second one, proof for this particular work energy principle. See here, first, what do you mean by work? Now my dear friends, you just focus on this particular figure. What it indicates? Two blocks are present, okay? The distance between these particular two blocks, we consider here as additional load is present here, it acts in horizontal direction that is P. So means here, initially this particular box is present here, this is the present condition of this particular box. When we apply additional load in any one direction, so this particular block moves in the same direction having some displacement. So see here, what do you mean by work? Work is the product of force and distance. So this P is nothing but the force, S is nothing but your distance and the distance should be in the direction of force, means this particular distance should be in the direction of force, in which direction you are applying the force. That is, work is the product of force and displacement. So mathematically, in formulae, we say that work done is equal to force into distance. So this force P and the distance is S and the unit of this particular work is joule. Second one, what do you mean by power? The rate of doing work is known as power. So see here, power is nothing but work done per second. For example, you just consider one person is just transferring one material from one place to another one place. So for that particular, we require force to carry that particular force, to carry that particular material, then to transfer that particular material from one place to another place, we require distance. So during this particular, we require some time. So power, it is the rate of doing work, work done per second, mathematically, force into distance upon time. Now we just bifurcate force, distance upon time, that is nothing but your velocity. So in another way, we say power is nothing but force into velocity and the unit is VAT. Next one, energy. What do you mean by energy? There are different forms of energy. So the capacity to do work is known as energy. Capacity to do work, for example, one work if we consider, so the capacity of that particular person to do the work, that is nothing but the energy of that particular person to carry out this particular work. So basically it is a product of power and time and the unit of this particular energy is joule. Forms of energy, there are different forms are present. Basically I highlighted few sources. One is mechanical energy, second one, thermal energy. Sometimes we call that seat energy. Chemical energy is present. Light energy is the sound energy, nuclear energy, electrical energy and so on. These are nothing but the forms of energy. Potential energy and kinetic energy, we will discuss in this particular mechanical energy forms. Next one, the statement. Work energy principle. See here. It states that when a particle moves under the action of force, so you just remember the first figure, the particle or the block is present there, box is present there, it moves under the action of force. The work done by the force is equal to the change in kinetic energy of the particle. You can see once again, it states that when a particle moves under the action of force, when we apply the force to the particle, it moves. So work done by the force is equal to the change in kinetic energy of the particle. So work done is nothing but change in kinetic energy. Change in kinetic energy is nothing but initial final kinetic energy. The difference between these two that is nothing but the change in kinetic energy is there. Now see, we will discuss regarding the proof. We know that force is nothing but mass into acceleration, okay. So mass and acceleration, it is in a mathematical format. Force is nothing but mass. Now acceleration is just split into change in velocity with respect to time. That is dv by dt. So once again you just rearrange this particular term. Change in velocity with respect to time. So here in numerator and denominator, you just consider change in displacement that is ds. So multiply change in velocity with respect to time that is dv by ds and here ds by dt. So the mathematical format, force is equal to mass into change in velocity with respect to this change in displacement with respect to time. Once again rearrange the terms, force is equal to mass into dv by ds, you just keep as it is. Change in displacement with respect to time that is nothing but the velocity. So just consider this denominator part in left hand side, f into ds is equal to m mass velocity change in velocities there. So integrate on both sides, force into ds change in displacement is equal to this mass velocity into change in velocities there. Now here you just consider the limit. Here we are considering the limit for displacement s1 to s2 and for this velocity you just consider velocity v1 to v2 is there, right. So integrate on both sides, f the limit is s1 to s2 change in displacement ds is equal to m limit v1 to v2 vdv is there. Now just rearrange integrate on both sides, f is equal to s2 minus s1, m is equal to v square by 2 and you just consider limit v2 and v1 is there.   So work done is equal to work done is equal to final kinetic energy minus initial kinetic energy. So sometimes we called as work done is equal to change in kinetic energy. So these particular limits are very very important s1 s2 that is nothing but the displacement is there and these are nothing but your kinetic energy means velocity we are consider here v1 to v2 is there. Now according to that this particular statement it states that when a particle moves under the action of force the work done by the force is equal to the change in kinetic energy of the particle that is work done is equal to change in kinetic energy. These are the statement this is the proof regarding this particular statement. So work done is equal to final kinetic energy minus initial kinetic energy that is change in kinetic energy is there. Now my dear friends you just go through this particular question pause the video and try to give the answer. According to work energy principle a particle of a mass m when subjected to unbalanced force system the work done during the displacement by all forces is equal to change in dot dot means here the options they are mentioned during the displacement. So we just try to identify the correct answers pause the video. So this is the answer of this particular question. So kinetic energy we are considering to prepare this particular session I refer this particular references thank you.


I mean he gave us the boost we needed you know somebody that could score off the dribble off the catch like that You know in a team young team like this they're gonna send all their resources at James and myself, you know So they playing super physical and super tight to me and they gonna bring over some help when I drive You know me so guys gonna be open and can was they did a they left him open I guess he wasn't on the scout report, but they left him open and he made plays and in transition He got out top the game for us And the end one was a it was huge for us and I think that pushed us over the top to kind of like Because we were down 10 11 the whole game, you know, so when we got back into it in the end of the third That was huge for us Yeah, we just talked the game I won't call it mentor I mean we are just exchanging information, you know, I'm saying we are trying to He's seeing he's seeing my game from a different vantage point, you know coming off the bench I'm seeing his game, you know, so we just exchanging information and Going over stuff that we see and trying to sharpen our skills and our tools is IQ as mental basketball players first, so It's good to see a young dude like him who's into it like that, you know, I mean it's You can tell he's a student. So we need him to build on this I mean we'll need him to be comfortable because he had a little 11-point game Because he made a couple shots You know, so I'm gonna be I'm always on him, but he always on me too, but I'm gonna be on him even more now What was it came defensively, I mean I Just think we switched our coverage up a bit they were they were getting getting kind of free there in the pig and roll and There's golems getting down here pretty easily after a few screens and You know, so he's wanted to close that space up a bit. We started switching some stuff We should change up our lineup Matchup, I mean and was able to keep them from the paint and we rebounded, you know, they are rebounders, but like We missed a lot of shots in the first half to you know, so it wasn't like oh Yeah, they killed us on the offensive boards too But for the most part that us losing in the rebounds didn't hurt us when we kept getting stops, you know, I'm saying we had on the 38% so You know when you do that when they miss a lot of shots, we still put ourselves in a good position I mean just being in the right spots and making the right plays You know big man Lately big man have been just Other coaches have been using their bigs to help so much off of the penetrators and You know, so when we get space in that corner L was bad with a knock that shot down they feel Last confident leaving him wide open to come help, you know, so He's been taking advantage of those opportunities and to get a double though tonight was huge for No, we had a couple days between those two games and Just wanted to get another day rest and see how it feels after that. So it felt good today


How much is the cost of CAT 6a cable? How much is the cost of CAT 6a cable? What is the difference in cost between CAT 6 and CAT 6a cabling? What are the differences between CAT 6a vs CAT 7? Regularly we are asked these questions as we conduct surveys as a data cabling contractor. CAT 6a price per data point. Large numbers of our clients inquire as to how much an information cabling project is per point. Consequently, the clarification explained in the following section is a decent method to know for pricing purposes. What's more, you can scale the numbers to suit your specific project and you have a good starting point for overall costs. The data beneath will show cost per cabling outlet changes because of numerous elements. These numerous elements, therefore, change the overall price. A decent gauge for CAT 6a cabling cost per information point is £50 to £65 per point. However, the overall cost can change dependent upon numerous factors. For instance, elements concerning the structure, timings and number of links inside the building project. Each project is specific to that building and client. Therefore, depending on those specifics the method and timings of installation will change. Furthermore, as these change, so does the quotation. The main consideration with any project is to ensure that all your requirements are taken into consideration. In too many cases do we see, like for like quotations with items not included which then unsurprisingly increase your cost after you have committed to the work. Following are situations where the overall cost of your CAT 6 cabling project can change. 1. The overall total of CAT 6a cabling ports you require to have installed. 2. Whether the cable is Euroclass rated, LSOH, or basic PVC, i.e. does it adhere to the correct safety codes. 3. The distance from cabinet to outlets for the CAT 6a cabling runs. 4. The construction of the building and the routes within that building. 5. The density of the cabling. Are they grouped or spread far and wide? 6. The building type such as a listed building, warehouse, school, modern office, or residential home. 7. The presence of existing containment for the cabling to be installed into. 8. The requirement for new containment and the difficulties of installing that containment. 9. Are there false floors or false ceilings present? 10. Any external work for CAT 6a cabling required? 11. The timings of the project. Will the work be standard hours or out of hours? 12. The location of the project. 13. Limitations on working hours, access and specific practices such as security clearances. 14. London congestions, parking, travel. CAT 6 cable price, structured cabling estimate. 15. As a starting point, the average of most CAT 6a cable price projects is within the range of 50 pounds per point, up to 65 pounds per point. 16. The average is therefore slightly higher than CAT 5e or CAT 6 cabling installations. 17. For calculation purposes, we have assumed a minimum of 20 to 24 data cabling outlets. 18. Of course, there will be projects where the CAT 6a price will be lower than the average range above and also projects where it is higher. 19. The previous list gives a good idea of what changes the overall cost of CAT 6a cabling. Therefore, the more positive elements that are present, the lower the overall average cost will be. Conversely, the more negative elements there will result in a higher average cost. 20. What would move the CAT 6 data cabling price to the lower pricing range? 21. The bullet points following are situations where you could expect the average CAT 6a price to be in the lower range of 50 pounds to 65 pounds per CAT 6a point. 22. A larger number of CAT 6a cabling points. 23. Labour costs remain steady in some instances when installing 5, 10, 20, or more CAT 6a cabling outlets. 24. This is especially true if there is a high density of cables in one area. For example, pulling 20 CAT 6a cables to one desk cluster is a similar labour time to pulling in only four. Of course, the termination time increases but labour as an average reduces the more cabling outlets there are. Therefore, 100 CAT 6a cables will cost less on average per point than installing 50 CAT 6a outlets. The difficulty of the cabling routes. Some buildings are better suited to easier structured cabling installation. For example, an office with false floors and false ceilings will have a quicker installation time than a school with solid ceilings and not existing cabling routes. Therefore, the easier the routes, the quicker the cabling installation. This results in fewer labour costs and therefore a lower cost overall. This especially applies to the more outlets there are. The density of the CAT 6a cables. As we discussed previous, pulling in a larger number of data cables to the same area uses a similar amount of labour. Therefore, the more densely concentrated the cables are, the lower the installation time. A comparison would be 100 CAT 6a outlets in an office to 25 desks compared to 100 CAT 6a outlets in an office to 50 desks. The 50 desks require 50 individual routes compared to only 25 in the other scenario. In this example not only is the installation time higher, but other factors such as containment and route making might also increase. What would move the CAT 6 data cabling price to the higher pricing range? Difficult cabling routes or requirements for some new containment. As previously discussed, false ceilings and floors make for an easier installation. CAT 6a cables can freely be installed throughout the length of the building and installed in larger looms of cable. However in some buildings, routes are blocked or difficult which increases the installation time. Difficult routes can exist in the following. 1. Solid walls that require drilling. 2. Solid floors that require chasing. 3. Ceilings with solid finishes that require access hatches or significant route planning. 4. The requirement to install cables externally due to no internal routes. In the examples previously mentioned, not only are the routes more difficult, but they can also create the requirement for new containment. Therefore, the installation time increases, and also the cost, and time for the new containment results in an increase to the project total. Additional containment can sometimes result in a project increasing by 50-100%. The location of the building and its access. The location of the project can make a difference. For example, the central London project incurs additional time and costs. The obvious ones are the congestion charge and higher parking charges. However, lack of access to easy parking results in additional time to access the materials and tools from the van. In open areas, they are located directly outside the project. The flexibility of working times and access. Out-of-hours installation or difficult time scales can result in a higher price. However, out-of-hours working can sometimes be the best choice. In some instances working while the building is empty can increase the installation time. However, when comparing like for like, out-of-working hours installations move the pricing to the upper average price. Containment that is not suitable for additional cables. Cat 6 and Cat 5 e-cables have a similar installation requirement when it comes to containment. Whether this is in dado-trunking, false ceilings, or floors. However, Cat 6 a is a larger cable and due to its construction, it has a larger bend radius requirement. Therefore, when specifically installing Cat 6 a into dado-trunking the containment that was once suitable for Cat 5 e or Cat 6 will no longer be large enough or suitable. Furthermore, there will be a requirement for new or additional containment which results in additional costs. What factors increase cabling cost out of the range? Non-standard buildings. These would be the type of buildings where the installation process is never straightforward. This can be due to the building construction, its size or the access. Examples such as 1. Buildings with a requirement for lots of single Cat 6 a cables to a wide area of its building. Examples such as CCTV cameras, Wi-Fi outlets, or access control. 2. Hospitality and hotels. A hotel can have a large requirement for data cabling, but it consists of many small cabling requirements. For example, a bedroom could have 5 Cat 6 a outlets but all 5 on different walls. 3. Large warehouses. The main difference with warehouses is the height inside. Therefore, cabling is usually installed off of powered access lifts. Therefore, installation is more complex and time-consuming. 4. Schools. Most schools are constructed with solid ceilings and very rarely have any false floor. Therefore, internal cable routes are non-existent. Complex routes are therefore common and time-consuming. 5. Care homes. In a similar fashion to schools, care homes are generally solid ceilings and solid walls within. Therefore, complex routing is required. Besides, care must be taken to work around the residence, and this results in additional installation time. 6. Smaller projects with only a few cables. If a project only requires a few Cat 6 a cables, the overall average cost is going to be higher. The installation labor remains the same, so the average cost of that labor over the smaller number of outlets is therefore higher. This would be in an installation such as 5 to 10 outlets. For the comparisons previous, the starting point is 20 to 24 outlets. Cat 6 a versus Cat 5 e. What is the difference between Cat 5 e and Cat 6 a? When comparing to Cat 5 e, Cat 6 a has 5 times the bandwidth. Cat 6 a cables support bandwidths frequencies up to 500 megahertz. Cat 5 e cabling only supports up to 100 megahertz. Furthermore, over the industry specified 90 meters maximum link, Cat 6 a can support 10 gigabit. Cat 5 e is only suitable for 1 gigabit. A general guideline for Cat 5 e in the UK is 35 pounds to 50 pounds per point. Cat 6 versus Cat 6 a. Cat 6 versus Cat 6 a bandwidth and speed. When comparing to Cat 6, Cat 6 a has double the bandwidth. Cat 6 a cables support bandwidths frequencies up to 500 megahertz. Cat 6 cabling only supports up to 250 megahertz. Besides, as highlighted previous, Cat 6 a can transit 10 gig up to 90 meters. By comparison, Cat 6 can only transmit the same up to 55 meters. Cat 6 is most suitable for a 1 gigabit link. A good estimate for Cat 6 cabling price per data point is 40 pounds to 55 pounds per point. Cat 6 versus Cat 6 a installation comparisons. The outlets for the cables are generally different. For example, Cat 6 installations are usually terminated with an all-in-one euro module. The patch panels are generally pre-made into 24 outlets across a single panel. However, Cat 6 a terminations are made onto keystone jacks. These jacks then snap into a shutter such as a euro shutter which then fits in a faceplate. The Cat 6 a faceplate is empty with 24 keystone slots. Therefore, only the cables installed are snapped into the panel. Final considerations. Many elements affect how much is Cat 6 a cabling. Your current technology and any future requirements should consider which cabling is most suitable. Therefore, avoiding the requirements to replace the cabling once your technology supersedes the current installation. Therefore, making an allowance for 100 data points now to flood a whole floor instead of partially cabling 50 will only increase the overall cost less than doubling it. However, if you install a further 50 Cat 5e outlets at a later date, the two projects combined will be more than double. This is due to having to remove the old and also work in a populated office. Therefore, resulting in additional time and cost. For further assistance or a free survey please email or call on the details below and click like and subscribe if you have enjoyed this video.


Why not create a technology that people can do it just automatically and effortlessly? So tell us a little bit of how we can use the cheat coil. Whether it's going to sleep, you can turn it on. Is there a timer or do you have to set a timer for it on your phone? How does that work? It's very simple. You just connect it and we have a tablet with all the frequencies on there. Or you can use our website which has the frequencies. You play those, you connect it to the coil. You can play it for 30 minutes.


Welcome. This is the 2nd of June 2023. It's documentation office hours. Thanks for joining. Topics that I'd put on the agenda 2.401.1 released. 2.401.2 release is in four weeks. Chris is the release lead. Yep. Is it two weeks or four weeks? It should, so release candidate is in two weeks. Yeah. Okay. So I just got them confused because I have to get the drop set on me in two weeks. Right. Exactly. So Doc's team needs to create the change log and upgrade guide for 2.401.2. Internationalization poll request, end of life notifications and main newsletters. So Ashutosh with you here and with Chris here, are there other topics you'd like to add to the agenda? Yep. She's Doc. Okay. Google summer of code. Yeah. Cause like two projects are like directly related to Docs. All right. And so we've got the, we've got the Docker quick start. Yep. Project. And we've got the alternative build process. And no, let's call it what it is. Versioned documentation for the Jenkins handbook. Yep. User handbook. Okay. So any other topics you want to add? Google summer of code and Ashutosh, this is yours if I remember correctly, isn't it? Yes. All right. So let's talk to that one. That seems like, and if there are conversations we need on version documentation, we can certainly have them. Otherwise, I think we've got a meeting scheduled in 12 hours or so. Yeah, we do. Okay. Any other topics that need to be on the agenda? Okay. Then let's take this one first. So Ashutosh, do you have questions or do you have topics you'd like to discuss? Not right now. Bruno just recommended me to attend the office hours for docs to get familiar with the team and how things work here. Okay, great. And are you comfortable with the places where we're currently using Docker in the Jenkins documentation and some of the terrible flaws of that? Yes, I'm familiar with the documentation. Okay, great. Super. All right. Well, we're happy to have you here and look forward to your contributions. So I am curious, how's your experience been in trying to use Docker compose to make an easier way to set up Jenkins and its agents? What's your experience been so far? For the first Docker compose file, we decided to go with a simpler file for battery beginner user experience. So I'm building a first Docker file right now. That's this on this week's bucket list. And I'm getting some errors and they are getting fixed. So I'm working towards it. First file Docker compose file will be completed by end of this week, I think. Oh, good. All right. So would you like to show us a demonstration of the compose file? I would love to see it if you're willing to share it or point us to a repository so we could look at it and talk about it. Yeah, we'd like to see it too. Very good. I'll share the link in the chat. All right, thank you. I'm not a compose expert and therefore forgive me using you as an education as a point of education. No, I'm not that experienced either. OK, so. Yeah, and this is the experimental repo for the project. Perfect. OK, so using a modern version of compose and the Jenkins LTS version. Running as that seems dangerous. I'm a little surprised you're choosing that one. What motivated you to choose a route? No, this is for I was just experimenting. So I gave all the permissions. I was getting some errors, especially with the SSH keys. I was using RSA first and this RSA was not working. So that's why I get the error and we used ED 25519. That solved the error for keys. But we still don't know why the RSA was not working with. Ah, OK, well, so in terms of documentation, I much prefer ED 25519 keys because there's there's so much shorter text. The document, the open SSH people say they're also more secure. OK, so so and now now the and you're doing privilege true for the same reason, I assume that, hey, while you were doing development work, you wanted to be sure that permissions didn't get in your way. Yes, yes, that's the reason. And now you've already got an agent configured. Does it actually work for you? Is this is this working successfully? Yes, and this one is working successfully. That's why I said all the things to route and privileged because of so I didn't get in my way. Great. And so just for experiments right now, yeah, absolutely. And and experiments, it's it's perfect that you're doing it this way. So this is the ED 25519 private key. And this is the public key. And here is your oh, this must be your RSA private key. Yes. OK, good. All right. Well, so and I can I I am no fan of RSA public keys because of that scroll bar. So thank you for using it 25519. That's a good choice. Yeah, but we recommended it to me, too. I was using RSA, but I was getting errors because of RSA. So he recommended it, too. Very good. And now this one is using. Oh, no, I see. I'm looking at the wrong file. Now, this is your your current one that's that you're experimenting with. We had seen its user root privilege true. And and before we go to production, I assume those will be gone. But we have to be sure we understand how how and what. Yes, Bruno also created a full request yesterday. I think it was eight hours ago. Good. OK. But this is he said there are a lot of things in it. So I have to look into it. I haven't looked into it right now. Oh, that's interesting. OK, so I I would I would have hoped we didn't have to do that. But then again, I'm not sure how the host key operates in that environment. These are just ideas. We haven't finalized it. Yeah, good for him. OK, so now and in terms of generating the compose files, are there specific techniques you use to make those to create those compose files? Are there are the tools that help with that? Right now, I don't know how Bruno created all these files because he opened the PR eight hours ago. So I haven't seen much about much what is happening in those files. OK, and now I've I apologize. I've lost myself. I'll just click that link again. Here we go back to the OK. All right, well, so this is this is already encouraging because it looks like what one of the problems that we have in the demonstrations in the in the the samples that we create is we end up running things on the Jenkins controller. And that's a bad that's a bad pattern. So what you've done here is already. Reached past that problem so that we could now set the Jenkins controller to have zero executors and only run things on this agent. Nice. All right, well, Ashutosh, thank you. Anything else you want to highlight in terms of of how your experiments are proceeding? Experiments are turning out fine. I was wondering how the process of setting the documentation will go. That's why Bruno recommended to attend the meeting. Plan was to just see if I get familiar with the team with the first meeting and discuss about documentation later when the Docker files are completed. OK, would you be OK if we spend a few minutes looking at the documentation together and talking about how how we might think it would it would change using a compose file? Yes, yes, of course. So so Chris and Meg, this is where you jump in and and give guidance as well because the things that I like about so the compose file is one way to solve this horrible, awful, terrible experience of installing. You never heard me say that. But the Docker install process here is let's see how many steps are in it, right? It's too many. You've got to you've got to do. Step one, open up a terminal, create a bridge network. What? OK, and then then you've got to do. Run this monster, terrible thing that turns on that does does the Docker in Docker. And then you've got to run this created Docker file that brings in the latest Jenkins LTS. And then you've got to build it and then you've got to run it. So we're already five horrible steps into this before you've even reached the post install wizard. OK. So my dream is that Ashutosh's work will replace those five horrible steps with one command. Docker compose up and the file name Ashutosh. I know that that's a long ways off for you and I'm OK with it being a long ways off, but that was my hope. Chris or Meg, do you have a different opinion on how we should how we should hope for this? Yeah, I agree with what you said. So it's a replacement of what we have for now. Good. All right. Meg, any guidance from you in terms of of ways that we should look for making this this experience better? Don't look like. Yeah, Meg, you're muted if you're saying anything. OK, she may be away there.  And then is it going to be a similar process for Windows? So the Windows, the Windows documentation today uses uses the Windows installer. OK, so that won't change based on what what Ashutosh is doing. But oh, maybe what you were asking was Docker on Windows. Is that what you were asking? Right. Yes, except for Max and Lenny. So I think so. And I think if if we are if we are as if we are as lucky as I hope we will be the Windows and Mac OS, the Windows, Linux and Mac OS will actually become a single thing. Ah, because you don't really have to be the only reason for the the differences between these is this exotic stuff with Docker and Docker. Right. And I am hopeful that Ashutosh in in investigating can find ways to to do that in a way that works with with containers on Windows and containers on Mac OS and Linux. Now, the assumption for me is that in each of those three platforms, the container is actually ultimately running a Linux variant inside the container. And that's the default way that Docker CE runs on Windows is it runs with Linux containers underneath. So so Ashutosh, does that sound OK to you? Or were you assuming that you would have to do something somehow with Windows based containers on Windows? No, I was also assuming that will be a single file for every opening system. Great. So the the the dream then, Meg, is that the on Mac OS and Linux section disappears and the on Windows section disappears. And it just becomes this is how you do it. This is how you do it. And it's a simple command Docker compose up and the the single file. Right. That'll be lovely. Yeah, that's the match that's supposed to be Docker. You can run this. It doesn't matter what operating system you're on. You get in it and right. Well, and in this, the thing we need here is and this is that's the thing that Ashutosh is doing for us is creating a multi container configuration. Right. So here's the agent container. Here's the controller container. And I suspect for tutorials, there will have to be somewhere in here a Docker and Docker container or something that gives Docker agents to the controller as a as though we're a cloud. And I don't know which of those it is. But yeah, that's that's the the likely destination we dream of. First step, I would love to get rid of this awful ugly things that are here. And then then we can consider going further from there. Great. Very nice work. I got some question about the Docker compose file prepared by Ashutosh. It's like I'm wondering if it's a good idea to put like like under Jenkins with start no as well. And also to add the size to it. Oh, so Chris, I missed that you're suggesting restart. So restart setting. Yeah, we start setting to set to no for the Jenkins controller. Oh, no, why would you set it to no? That's interesting. I thought that it was typical that for Docker, I had to set it to restart some other setting. Now I've got to go look and see what it was. But I remember that I've got a setting in mind that says something about restart. I just don't remember what the restart setting is. OK, we should look into it. OK, so here I've got let's see, looking just a minute. So in LTS with plugins and there is a Docker underscore run this one. OK, so some here how I said, oh, yeah. I set restart to on dash failure. Now that may be the wrong thing, but for me, it works. It lets me do a restart and then the controller comes up again inside. OK, maybe we should add this to it for now and test it. So Ashutosh, have you had any experience with a restart setting? No, I haven't. I don't have any experience right now. I look into it. OK, great. Good, good question. OK, and also how about S H M size? Just in case if it's not enough. But I think for this purpose, it should be the default, I think. I don't remember like the default was less than 5 GB. So if you want more than that, we have to add the S H M size. And so you said S H M size is S H M underscore size. S H M underscore size. OK, and I'm not setting that, so I must be OK with defaults. But that's a that's a setting that can be controlled in the in the service definition inside compose. Yeah. Well, that would that would certainly give us a better chance of assuring that Jenkins had at least a minimum. Now, is S H M underscore size defining the maximum value for it or the allocated value or I don't remember because I did I did search for it a while back. Let me see. S H M size. So that's that's basically just I think it's a max size of the dev slash dev slash as you can in document. OK, oh, and this is interesting. OK, so so S H M. Yeah, because like we wanted to some problems of it for get lab parking when we're doing the config for macOS. Ah, OK, so so this. So OK, so I'm not sure I guess I need to read the instructions. What S H M size is. OK, so Belena talks about it as interesting. OK, so needs more research. Ashutosh, you've got the good question. Any other questions, Chris? No, just those two. They follow. All right. Excellent. Ashutosh, congratulations on being accepted and thanks. Thanks in advance for your contributions. Good luck with your investigation. Thank you. Look forward to seeing the next stages. Exactly. Good work. All right. So let's see the questions we had were. Oh, I should embed the embed the link to Ashutosh's example because that way I could play with it later. OK, and then it was questions from Chris and Ashutosh of the recording of this session will be available on community.jankins.io roughly 24 hours after we've done the meeting. So you'll be able to refer back to it. Um, so it was should we set S H M underscore size needed it for GitLab plug-in, right? Yep. Modernization. So if the GitLab plug-in project. Because I always it would just drop like I mean that the instance we just dropped by itself after a while for my computer anyways. OK, and then the other was should we set restart? To and my question was, should it be to on dash failure? And yours was should be should be was it should it be on on failure or no? Yeah. And I don't I don't know which of those is most correct. I know that I've been very happy with on failure in my configuration. And then questions from me. And I think Ashutosh already answered those. It was should we have privileged through? Should we have? User well and route. And I think that the hoped answer, the way Ashutosh described it was the hope is no on neither of those. But for now, it's it's in his is his experiment is prototype. OK, great. Ashutosh, anything else you wanted to highlight there before we go on to other topics? No, nothing else. OK, all right. Chris, anything you want to note on the versioned documentation for the Jenkins user handbooks? Maybe we the thing is I think we should like start talking with Inva or Gavin about setting up about how to how to move forward with hosting. First draft of the work to dark star. Jack, so I know. So and so I was thinking we wanted some time before we would make it visible globally, but we would like a preview first. Would it be OK if we have need we need to have a preview site? Configured. So that we can see the site in action. And that may need coaching from. Gavin Mogan, good, all right. OK, or Jenkins Infra. And I think they may be able to help as well. But good, all right. Anything else on versioned documentation? I think we are about to have like something to show for in maybe next week. But so we'll report back next week. Oh, good. Yeah, because we're working on like moving to images manually because it cannot be automated according to Vending. OK, say that again. So what's what is the images? Because they have to move to the new structure. So it's like that then like all the other links would have to be updated one by one. And that could be like time consuming. So it may take a week. I see. OK, so and that's because of Antora's different way of handling images or? I think because, yeah, and I think it's for Antora. Like the way that the images are stored may be a little bit different because like right now it's it's more centralized, but maybe in the future. So it's depending on the module, I'm not sure. OK, I'll need to take a look at Vending to find out. Great. All right. Thank you. OK. Anything else on that topic? No. All right, next topic then was the 2.401.1 change log and upgrade guide, and that's visible here. So here is the change log. And here is the upgrade guide. Oh, and and there are two mistakes that we detected. I should note that that's good. Mark made two mistakes in assembling the change log that we detected while we were doing the presentation of the what's new in in 2.401.1 to at least two items were already delivered in earlier releases. So I'll get those removed. Any questions or concerns on the LTS process or the the content of the of the documents? OK, and so for 2.401.2, it'll probably be me creating it, but Kevin may be back in time to do do a revision of it. So Kevin returns returns June 12. He may be able to oops. Let's put that in the correct location. Oops, Kevin returns June 12. May be able to do the change log. Anything else on those topics? No, good work. OK, next one is a victory. This pull request from Jeffrey Chen came in two weeks ago or so. And what Jeffrey did was he brought back a stalled pull request that was originally proposing to take content from the internationalization instructions on the Wiki page. And this is something that was done all the way back in 2019. It was started. We did long series of conversations about it. Meg, many others have been involved. And we then said, hey, this is stalled. We're going to move it to stalled so it's not distracting us. Jeffrey Chen brought it back. What he brought back, though, was. Incomplete or not quite what I thought we should do. So I proposed some alterations to it. Jeffrey accepted the alterations and we ultimately deployed it as. Let's look at the page and now here. So here we've got first pieces that internationalization internationalization and localization is no longer work in progress. This is good enough. It's production. All right. Developer tasks, translator tasks, both relatively short lists and entry for Chinese localization still. And pointer to how to configure IntelliJ to make your job easier doing localization. With links inside the page to more details, then right next to it on the page is the crowding integration that Alex Brandis has helped configure and makes it much, much easier to translate plug-in text from one language to another. So thanks to Jeffrey. Now, Jeffrey has continued and has made the next step, which is another poll request. And the next poll request will probably need the same kind of work on it. It's this conversion of administering Jenkins and Jenkins best practices. And the challenge here is that many of these things are already covered elsewhere. And we have to find the correct locations in the documentation to put them. And I'm not sure that Jeffrey is able to to do that. So so this really will require more, more work from from those of us who have got some deep experience with Jenkins and its documentation. Yeah. Meg, is this one you want to take a look at it and document or add some comments on? I would. Yeah, I will definitely be interested in reviewing this one.  No need to feel like it's obligable that you're obligated to do it. But if you've got capacity to do it, this would be a great one. This would be a great one. Bruno has gone through and made linguistic changes and style changes to to bring things up to our common way of doing things. And Jeffrey has already applied those changes. So what you're seeing should be already first level first draft. Good enough to review. OK. And let's put a link to that one inside the. OK. So and let me the point of this is to get any useful information from the Wiki merged into the existing docs. Right. Right. The goal is to to take the content that's being proposed here and find the best homes for it. OK. And that's that's a structural question, not not as much a content question. Right. It's OK. We read the text and the text says this and then we have to decide do we already have something that says this? And if not, where should this be put? Because I don't think we want a new page called administering Jenkins. No. Right. We've already got plenty of pages like that. So and and I suspect we don't want. J N D I environment entry. So so there there's some things in here that are just flawed and discover those as we're working. OK. But we're not going to talk about whether the split between management and administration is always saying, et cetera, that's beyond the scope of this. Right. Well, it's what what I was thinking is let's find the right place to put this kind of content if it doesn't already exist. And if if you feel like it belongs in managing or administering, I'm fine with that admitting that we know that the distinction between those two is flawed and imperfect, right? I mean, managing Jenkins. Why is admin? Why is there a managing Jenkins page and then a system administration or a section? And then so, yeah, the those things are. Not terribly logical. Right. But it's always a problem because life. Oh, wonderful, though. This should be good. Yeah. So well, it's it's worth it's worth at least. I think I think there is much to be done, much value to be gained here by going through it and identifying every every one of us who sweeps through this will find things that we can improve, things that we can do to make it better. Great. Great. Anything else on that? That poll request from Jeffrey Chen. No, that's good. No. All right. Then the next item I had was end of life notifications in Jenkins core. So this one is we've got a with beginning with Jenkins two dot four hundred seven. We've got a warning that appears to users now if they are running on an operating system that will be end of life in the next six months. What that mean? What, Meg? Oh, I was just saying, yay. Yes, exactly. So if it also announces an early end of life for Red Hat, Red Hat Enterprise Linux seven and its derivatives like CentOS seven. So that early end of life is because that thing is such a pain to support that we want to get it out of the Jenkins project sooner as soon as we can. Yeah. Now, we've got the next step on this and the next step hasn't started yet, but it will be coming, which is container end of life. So this was operating system end of life. But we also have a problem that we need to be able to say container end of life. Oh, yeah. Where what we've got is, for instance, there are some containers that we've got some containers that are done with Arch Linux. It's a low volume distribution. We don't have anyone in the maintaining team that's interested in it, so it's not being maintained. And therefore, it's it doesn't make any sense for us to retain it. But we need to in some way find a way to announce to the users, hey, you're using a container that we're going to stop updating or we've stopped updating. The other kind is this one has already covered CentOS seven controllers. A controller container or yeah, these are containers. So controllers and this one is already showing the end of life warning because it's using CentOS seven. OK. But we've got others, for instance, Alma Linux eight. That we think we want to end of life. And one way to do it is to declare the end of life and make it visible and tell people your migration path is to this other operating system. Yeah. Or to this other container image. Any questions on that one? No. All right.  So off the top of my head, is there going to be any attempt to record this historically? No, because we do end of life anyhow. This is just we're warning them, right? With some people, someone a year from now comes in and wants to know what happened, you know, what the path was out of CentOS seven or something like that. So we don't do that, right? We don't need to do that. Well, actually, good, good question. So as you're thinking about, so we're we're pointing people to this blog post for right now so that they have a reference to the dates and the and the plan. I've wondered should we have an end of life table in the Jenkins documentation somewhere, eventually, but I wasn't sure that that would be as helpful as. As as the version documentation, which will give us a place that we can describe which platforms we tested with a specific version anyway, right? Except that some some because. Unfortunately, users do not upgrade when we think they should. Right. Some like a little bit. And every once in a while, somebody comes out of the woodwork who was just, you know, 15 versions behind. Or something. I don't know because the table would also be kind. I don't know would it be a pain to maintain or maybe not because once it's dead, it's dead in that stage, you just become keep adding stuff, right? Well, and maybe this is something this is a topic to discuss with Chris. So certainly today we have let me describe what we have today. So today I'm going to play note it this way, Meg. Should we document the tested. Operating systems at Jenkins release, right? So in the version documentation, should we we note the operating systems that were run through automated tests? So in the packaging repository today, tests container can test installs of all sorts of operating systems, Fedora, 37, let's see, Red Hat 8, Red Hat 9, Debian 10 and maybe what we want is some way of of declaring. Hey, here are the things that were tested so that when we have version documentation, we see that 2.401.1 was tested with this mix of operating systems. Chris, what do you think as a as release lead? Could you envision something like that or? Yeah, I do. Because I think it's kind of like what it's a based on version of Java we're using for Jenkins is similar in nature. So I think we should document it properly. Right, right. Yeah, and it's even Java versions, right? Because it's hey, we're using 11 this and 17 this. And we also ran tests with 19 this. Yeah, right. Good, interesting. OK, good, interesting concept, Meg. I'm not entirely sure how to do it, but we've got something like it already in. Well, let me show this page because I was just checking it today. In the Jenkins documentation, we have a page called choosing the version, a Jenkins version to build against. So this is guidance to a developer of what value they should set for their Jenkins version in their palm file. Right. And it tells them 2.375.4 or 2.387.3. Now, five days ago, those numbers were 2.361.4 and 2.375.4. This documentation knows when we release a new LTS and puts the latest LTS there, one back there and two back there. So something like that, we could probably extract the tested operating systems from the packaging repository as well. Yeah, good idea. If somebody wants to know what it was a couple of releases ago, they can go back to those other release notes. Exactly. You don't have to give them a single historical textbook on the whole thing. Mm-hmm, right. Of course, see, I want the textbook, but I wouldn't know that. I don't know that I'd want to have to write it and maintain it. Well, and that's the thing that I'm not especially interested in putting this kind of information or the operating system to be tested into the changelog, right? Because for me, that's different than the features in the release. But I guess we could consider putting it in the changelog instead. It just, for me, that feels like not of interest to most people. They want it on one platform and theirs. Good. OK. Did that answer your question, Meg? Yeah. It'd be interesting to mention this to some of the other maintainers and stuff, see what they think about it, what they hear from. Because I'm sure if they get called into the crazy cases where somebody's like three years behind, they haven't upgraded for three years and now they want to know what to do. Right. Right. Good. OK. Yeah. All right. Anything else? Any other questions or topics? I've got one last item and then we can close. Cool. Hey, the main newsletter, I've got to do some writing for it. And onward we'll go. OK. I've got a question for Ashutosh. Have you guys, like, for the project, for Gizok project, for Docker Quickstart, have you guys planned how to draft the documentation needed for the Docker complex examples? Can you predict? I don't understand it. Have you planned, like, how to draft the background details? So it's like, is there, like, any processing place? Like, how do you review the, like, on top of the Docker compose files? So you also have for the documentation you have on Jenkins.io. So some passages, too. So, Chris, let me test to see if I think, if I understand. I think what you're referring to is something like this, where the lines in the compose file or the lines in the compose file itself have little bubbles that tell us this means this. Is that what you're saying? It could be. Yeah, it could be. And also, it's like, I'm just wondering if they have a process, like, so Ashutosh can start, like, drafting. No, we, right now, we haven't had discussed anything like this. OK, OK. Cool. I'll check back later. Well, and so the idea that the compose, for me, the ideal that the compose file would be self-documenting is really, really helpful. But the challenge with self-documenting in the compose file is then it becomes mostly comments. I don't mean to document in the compose file. It's just to document it for Jenkins.io. Because, like, we're not just using the Docker compose file, for example. So there's, like, there's some background information behind it, too. And those, like, Ashutosh may want to collect as he goes along, and he may not want to wait until the last minute to do it, because then he may have forgotten, like, most of the details. That's what I'm asking now. I see. So I think what you're suggesting is there are probably assumptions that Ashutosh is making, and it may be good to capture those assumptions or background information. For instance, this one, hey, temporarily privileged true because we want it, but long term, we don't want it privileged to temporarily use a root. Long term, we definitely don't want user root, that kind of thing. Okay, I'll remember this and keep it to the bucket list of our next meeting with Bruno. So we figure something out about this. Great. Thanks, Ashutosh. Thank you very much. Thanks for this. So the idea is some form of running notes or lab notes or don't forget this. Or I did this because to remember current decisions, right? Right. I guess it didn't work. Right, exactly. Yeah. The other cool thing about that is sometimes those running notes are a great source for an eventual blog post about, here's this technique we didn't deploy all the way to production, but it works in some cases very nicely for this. Great. Thank you. Anything else? Okay. Thanks, everybody. Recording will be available probably within 24 hours.


God has already provided all the wealth you need. He's already provided all the healing you need. You're not waiting on a healing, He's already done it. It is finished. I'm not waiting on God to supply my needs according to His riches and glory, they're already supplied. When He said it is finished, He put a nail in it, it was over. Pastor, I don't see it yet, just keep your eyes open. It's been hidden in you from the dawn of time, from the foundation, and the more understanding you have, the more you can unlock. He said, behold, I give you keys to the kingdom, not keys of the kingdom, keys to the kingdom. And when you work the right key, ladies and gentlemen, that's the reason why you've been standing there with a ring of keys and the devil's not afraid of you if you don't know how to use them. But if you know how to put the key in the right lock and in the anointing of God, you can open the door and He will flot you with blessings you have not room to receive.