So five o'clock, let's get started. So I'm David Strauss, I do work with Pantheon. We're one of the earliest adopters of SystemD on a pretty wide scale, and I've done substantial work in code bases of a few projects, everything from Drupal to some database systems. And what I'd like to talk today about is improving the quality iteratively of the SystemD code base in terms of how we structure our memory management, how we structure our data structures, how we audit our code base, and improvements that we can make toward that. We have a lot of patterns that get used all over the SystemD code base. There are over 1,000 instances of cleanup routines where we have to have code that basically does in reverse order all of the allocations that are being done that are not automatically cleaned up. This often manifests in the code as check for error condition, if it's an error condition, set a return value, and then go to a finished routine at the end of the code to be able to do cleanup. Sometimes we even have multiple finished routines because there are different nesting levels of allocations that occur. I don't have any problem with the fact that it's go to, but it's actually pretty tedious to maintain the reversal of the allocations at the end of code when we have patterns like that. We have over 4,000 instances of using cleanup macros in the code where we manually are assigning with GCC's extensions to C. This is actually non-standard C, the idea of running some sort of routine, almost like a destructor, in order to clean up memory once an object goes out of scope. On the upside, this means that the object gets automatically cleaned up without the sort of routine I just talked about. On the downside, it means that we have to have cleanup macros that are often type specific, and we have sometimes cleanup macros that go several levels into their freeing operations in order to provide the right corresponding cleanup for a particular data type. And when you implement this, you have to use the appropriate cleanup macro to go with a particular data type because there's not an implicit link between the two. And we have over 6,000 lines of code that provide functionality that's extremely similar to things that are part of the standard template library for C++. This includes strings, sets, hash maps, bit maps. Overall, we dedicate an enormous amount of code to recreating C++ style functionality in the system decode base. We even have our own kind of attempt at a class hierarchy with things like units where the idea of a unit is basically an abstract superclass and things like services and sockets and targets, you name it, are all basically these sort of concrete subclasses of that where there's certain attributes that are inherited by all of these units and these units also provide their own. We do these through a combination of structs, macros, and these sort of lookup v-tables that basically provide a way to take things that are methods that are stored on each of these things with different implementations for these different unit types and then map them to the actual routine that runs them. It's not really regular C. In fact, system D can't compile on a C compiler that just only does regular C. Some of these things like cleanup routines, use compiler implemented features that go beyond regular C and actually use parts of the C++ runtime. That's actually, when you do something like a cleanup macro in GCC, it's actually throwing that into the same portion of the code that would run in the compiler if it were running a destructor on that particular object because it tracks the life cycle the same way. And in fact, almost every C compiler these days is based on building a C++ compiler and then implementing a subset of the functionality to compile the C. And I think a lot of this is really clunky in terms of the developer experience for people improving the system D code base for people reviewing it, learning about it. And I think it creates a pretty high barrier to entry to getting additional developers and even having ourselves work on improved code. So take something like this, relatively fresh code and system D code base, pretty kind of leaf project in the sense of this isn't a core routine, this isn't part of PID one, this is just a utility running on the shell. But we have this thing here where we have a vector of these strings and here you see a cleanup macro that's being assigned. This cleanup macro was written specifically for this use case of having the, basically a variable length vector to strings and that's why it's cleanup strv free. We have cases where for a lot of the data structures there are specific behaviors being implemented on them like for the hash map. The string hash ops is defining that it's operating on strings. And then we also have to figure out whether this is even the right call for cleaning up this hash map we've created, ordered hash map free, free, free. And if we get this wrong, we leak memory. And in the case of this utility, not a terrible consequence. The reason why I chose this utility is later I'm gonna go over a conversion I did of it incrementally to convert just this particular utility to a much more concise and safe in my opinion kind of minimalist C++ code base. And also I was mentioning before when we're doing these sort of finish routines where we go to them, we have to order them appropriately because it's not automatic that things get unwound in the order that they get created. And if we order these incorrectly, we could end up with use after free scenarios. If we, for example, free the container structure before we free the members of the structure. So there's a lot of things you can get wrong even in this small set of code. And additionally, we've overloaded the concept of ints throughout the code base to be able to return success values and actual return values with error codes that we basically have the convention through the code base of values below zero indicating an error, values above zero being a sometimes a return type and zero just being success. But there's not really a great way to enforce this if you especially if you're refactoring the code from something that is returning say a Boolean style success value to this sort of situation. And in fact, if I run analysis on this particular piece of code, it isn't correct. The freeing of the hash map is leaving some lingering things in terms of still reachable with the dynamic analysis. No, it's not leaking. It's just the implementation. So in any case, even if this is not leaking, it's creating a false positive in terms of analysis of the code. Yes, it's also fixed. I actually ran this analysis as of earlier today on the master code base. Literally more recently than that. More recently than this morning. Okay, I ran this analysis this morning using Valgrind. And so ultimately like my argument here and you'll see in the later slides that this is kind of part of my point is that it's often not clear whether we're doing something wrong or whether we've implemented it right and we're confusing the dynamic and static analysis. The going forward to some of the other concerns that I have is we're so oriented around things like these event loop structures and we actually lose a lot of type data in that process where we have things like this where we send an avoid star. It basically got de-typed earlier to avoid star and then we're re-typing it back to a manager pointer here. This is really hard to validate. You can, some systems like Covairty can get a little bit of validation going on this but they're using a lot of heuristics to do so and there's almost no runtime or compile time validation on this sort of setup because if this is not actually a pointer to a manager this will just crash. And we just can't analyze it well and so we're confusing tools all over the place. In this case, this is using Clang Analyzer where if we use, this is a pretty popular static analysis tool that's built into the LLVM code base. It's totally open source. It's a great tool for diagnosing things and it doesn't work on our code base because we use functionality like cleanup free that it doesn't understand. In fact, this code, it does not leak because the cleanup free gets invoked if this has been set to something and it goes out of scope but the analysis tool considers it a potential memory leak. In fact, there are about 306 instances of this in the code base where the static analyzer associated with Clang thinks that there's a problem even if there's not. And it's really hard to get down to where the actual problems are in the code base and continue to improve code quality if we have false positives. And I think that we can also start looking at some of the constructs that have been added in modern C++. And this is totally different than the C++ that a lot of people have grown to hate because there's a lot of reasons to hate old school C++. It has awful template systems. It has awful pointer and smart pointer systems. But around 2011, they actually decided enough is enough and that they would add things to the language that were mostly supporting the idea of confidence in design around memory safety. That means that in terms of ensuring things are free, ensuring things aren't used after free, ensuring that the handoff of ownership of data is extremely clear in the code and enforced at the compiler level. And all of this gets supported down to the static and dynamic analysis layer. As a sort of kind of spectrum here, there's a big difference between a lot of these systems, but I see this sort of span where you have the sort of standard C, which doesn't do some of the stuff that we rely on in terms of things like cleanup. Then you have our sort of GCC flavored version of C that system D is written in and that uses that has extensions that rely on some of the C++ functionality, even if it's not C++. And then you have systems that are gravitating more and more toward the idea of enforcing safety as the means of using the system. You look at something like Rust and it's designed from the ground up to prevent you from doing things that will cause unspecified behavior or unpredictable memory allocation or other patterns that we see in broken code. But C++ 2011 goes a long way toward that and we can actually convert code iteratively toward that of the current code base and gain some of these constructs that allow us to be confident in the memory cycle of a lot of the implementations we're doing. The specific sorts of conversions that I think would be useful would be going from cleanup macros and go to finish to using proper destructors on these objects. This would reduce a substantial amount of code in the code base and ensure that things get unwound precisely in the opposite order that they were actually wound up in the beginning and can simplify a lot of our return cases for handling errors because we don't have to create these multiple jumps to different layers of unwinding through this sort of go to finish or even multiple level unwinding structures. We could be getting typed data that are going into callbacks in the sense of instead of handing void stars through things, we could be using lambdas that can actually get built at compile time and ensure that we actually maintain type safety all the way through a callback of an event loop. And we could be using systems like references, move semantics and smart pointers to ensure that we don't actually have cases like the possibility of handing a null pointer to something that is expecting something to be there, which means we could remove quite a few assertions in the code base because we wouldn't need to assert that a memory address has been assigned for something that is being handed over one of those ways. And as we provide APIs to different parts of the code, handing over the ownership of data objects where say one function creates an object and then hands the ownership of that memory to its caller can be actually enforced at the compiler level all the way from the early development time. And in fact, when we look at the total results, almost all of the things that we're getting dinged on are the things that we could be selectively using some aspects of C++ to mitigate in terms of destructors, smart pointers. RAII is the idea of resource acquisition is initialization. There are many cases in the code base where we are constructing something as far as we think, but we're not 100% sure if it's constructed and then we have to check error values to see if it's been constructed properly. And RAII means that if it's been constructed and we have the data and we're moving forward in the code, it actually the invariance of whatever thing that we're working with are being held. So just looking at the distribution of issues here in terms of possible null pointers, possible leaks, I'm not saying we're actually doing these things wrong, but I'm saying that it's creating a lot of noise for us that we can't look at a report like this and know with confidence that we're getting a good result of kind of not having a bunch of false positives. And there's really no way to solve this with piracy. I mean, you could put comments in the code to tell the static analyzer to ignore those lines, but that doesn't really help. We could be doing manual freeing of these things rather than using the cleanup things, but I think that's more dangerous than what we're doing today. So in some ways, we basically need to, if we want these tools to work for us, we have to work within the bounds that the tools expect. Because it's not really about just that code works and that we've gotten a low defect rate just in production after lots of periods of iteration. It's about whether we can look at a piece of code and analyze it and be confident before it goes out the door that it's actually correct. So just to kind of clear up what I'm not pushing for at all, I'm not pushing for any kind of generalized conversion to idiomatic C++. I'm not pushing for any sort of extensive use of objects or even adding many exceptions to the code base. It's about using some of these facilities for memory management and about using some of the high level data structures. And we totally wouldn't be the first project to do this. GCC did this years ago. Sorry if these slides are a little text heavy, but I'll just summarize what it's basically saying here. When GCC looked at this, they started looking at it about 2008. And by about 2010, they had decided to use a subset of C++ where they basically said, we have a C-based code base. Let's take a handful of features from C++, allow those specific ones to be used in GCC and thereby allow using more elegant structures. And one of my favorite arguments around this is that C++, and this is, I think, Ian Lance Taylor of Google saying this, that it supports cleaner code in many significant cases and it never forces us to do anything more ugly because we can always use C. Like C with very few exceptions is directly usable within a C++ code base. In terms of the effect on the projects, they actually saw for modern style systems in terms of multi-processor, multi-core systems. They saw no impact to bootstrap performance of running the program, but they actually saw improvement to the execution time of a lot of their stuff because they were able to use better optimized data structures that were available in libraries and in things like STL that were generally better tuned, especially on a platform by platform basis than the data structures they could write manually in their C code. And they saw absolutely no drop-off in contributors. They saw no drop-off in commits. There was no sort of exodus that this created on the project. I know a lot of people panic around the idea of as soon as something touches C++ that everyone runs away from it, from like a kernel developer perspective. Like I know the kernel team is like really ideological on this. And I think the argument is actually way stronger today than it ever was for GCC given the advancements that have been made in 2011 and 2014 with the code base. So I think that we could do a lot of small improvements. I think that we could be taking leaf utilities like command line tools and certain daemons that are not relied on by other code as an initial foray into this. We could be focusing on cleaning up analysis results where replacing these sort of cleanup things with destructors, replacing some of the freeing routines with destructors, replacing some of the way that we hand off data to be in a more semantically validatable method at the compile time. And then we could eventually graduate to doing deeper work on core code that is actually relied on by other systems and even exporting symbols as C wherever we want in terms of libraries. So there's really no limit to what scope we could choose for this because we can always maintain the libraries and symbols that we export to the rest of the world just as we have today. There's no real dependency there. And eventually we could remove all those unused macros and data structures that are largely redundant with what C++ supports. So I did this to sysctl.c. It dropped the lines of code by about 26% and this is not even counting any retirement of libraries within SystemD, I'm talking purely this single file. And just to kind of compare the sort of structures that I'm using here, we can just, we can forego a lot of the boilerplate that we have to apply today. We don't have to have these finished routines. We don't have to have the manual freeing. We don't have to have this sort of bespoke, like for SystemD invocation of these hash maps in terms of like this ordered hash map new stuff that is basically being handled at a higher level here. And I'm a rather a fan of some of the semantic error codes because they actually provide a way to distinguish between the idea of an integer and an error code which can be useful for refactoring. So we basically can simplify the code a whole lot. Whoops. In terms of the typed error codes, just returning when we're done, letting the destructors take over and using these high level specifications for how the data structures work. So what I did is like in the conversion, I was able to drop many of the requirements on the internal libraries and add a handful of external ones. I don't actually have a strong opinion on some of the extra libraries beyond STL. I think we could benefit a ton just from using some of the basic C++ stuff. In the case of this rewrite, I did use some of the boost stuff just because I thought it would be fun. And that helped cut the code considerably. But I think that from the memory safety perspective and analysis perspective, we could get all of the gains that I've talked about without touching boost at all. There are some weird things in terms of C++ doesn't really like the hash map container that we have in system D because it relies on some GCC features that are not part of normal C and don't actually that conflict with parts of the C++ standard because they're the sort of add-ons to GCC that are actually using parts of the C++ engine in terms of doing things like type checking. So it's not a problem in the C code itself. It's only a problem in the actual code that gets converted to C++. So this doesn't create a widespread problem. It just meant that I had to replace the hash map with a vector or a hash thing from STL for the code that I was converting. So with that, I'll open it up to questions. We have a couple of minutes left. I have a question. So the first part, I agree, like we can improve the code base. The second part was like, you're referencing some example from project that happened like 10 years ago, like the GCC moved to C++. And at the same time, you're also referencing, I want something which is correct or safe. So I'm aiming at rust and then you say, but I actually want to use C++, which is a kitchen sink, but just a proper subset. So we still have to be very careful. So the question is, given that other projects like Firefox, VLC, Tor, of there are a few more Gstream or what else, they are already moving into the same direction and they are directly aiming at what you were mentioning at first, like a safe language. So why are you actually suggesting we started writing these now in something which is not having what I wanted to do before. So it's like, I was kind of like trying the same experiment in Rust with the new MazeZone BIOS system and it's nice, but I cannot like force people into that and I'm not proposing for that. And so I'm surprised that you're like proposing to get into that direction, but not even doing that. And my question is why? So I don't think Rust is viable for a substantial portion of the system decode. It doesn't support forking, for example, as part of the core operations.  And forking is a pretty core part of running a PID one for the system. The other issue is that there's no real way to iteratively move. We would basically have to take file by file and rewrite entire subsystems and create bindings for C, which you can do, but it's a much higher impedance bridge between C and Rust than it is between C and C++. It's impossible for us to even go in the C++ and change part of one file to improve some of the verification operations for it. And I agree, it's C++ as a kitchen sink and you have to be careful what parts you pick of it, but I think that there's substantial redundancy with what we've done in the current code base with what C++ is designed to offer. And I mean, the kind of example I gave is somewhat proof of the fact that you can do this sort of thing iteratively. I took one file, changed the build. I changed the build information in terms of the MISIN setup to be able to support C++ for the project. Just a few lines of code changed there. And a few lines of code changed in the sysctl.c and suddenly I'm able to build that particular utility as C++. So your point is that the standard library of Rust is not flexible enough, first. And the second one is that you want to retain the C compatibility at any level, like internal and external. I think that, yes. I think that it would be totally reasonable to rewrite certain isolated parts of SystemD in Rust. I think that there's no way really to move PID 1 to Rust. But you're not arguing from that here. You're saying I don't want to move all of SystemD into that. I want to start, right? Sysctl or... I think that that's really from a risk mitigation perspective that we could be doing it for small parts of the external project and then kind of working the way inwards. And part of what I was providing with a GCC example is it's so low impact as a change. And so it doesn't create any kind of gigantic burden of work for the whole project that it didn't, for GCC, the conversion didn't create any sort of period of time where they weren't implementing new features or they weren't making improvements, which is the thing I would worry about for a larger conversion. One point on Rust is that the official compiler supports x86 and ARM and everything else, you're on your own. So if you want to support something like MIPS or one of these other platforms, you also get to be a compiler maintainer. Yep, that's a decent point. Part of why I was emphasizing the support in GCC and compilers, we already support for everything. Everything I'm talking about here would be supported on all the same build environments that we're already supported on. Oh, no more time, sorry. Thanks.


learners, I welcome you on the market mechanism. This chapter is included in your first semester economics paper that is introduction of economic theory 1. In this class, this is the broad syllabus which I am going to discuss in this class. At first I will start with demand supply framework that is Sahida, Jhugan or Gothan Next I will meaning of demand Sahida or Gotha, Tarpasad law of demand Sahida Vidhi, Tarpasad I will discuss law of supply, Jhugan Vidhi. Then we will discuss about concept of equilibrium or third, Bharat Hamotar Dharana. Next market equilibrium or third, Bazar Bharat Hamotar. Next I will discuss some static analysis. So, first I will start with demand supply framework. So, what is demand? Basically demand is a desire for a commodity which must be supported by its purchasing power. In other words, in economics to create demand by a consumer he has to satisfy two aspects. The first one is he has the desire to purchase that particular commodity and secondly he must have that purchasing power. Thus, let us now discuss the second aspect of demand supply framework. So, we can explain it with the help of a very simple example. Suppose, if I am giving an example of consumer A, consumer A wants to purchase a mobile handset that cost around 10000 rupees. Now if consumer A has that amount of purchasing power that means if he has the ability to pay 10000 rupees for purchasing that particular mobile handset, then only he can create demand for that particular commodity. Now based upon those things there is a famous law in economics which is known as the law of demand. So what is law of demand? I am going to call it as Sahida Bidhi. What is Sahida Bidhi? Sahida Bidhi often says that other things remaining unchanged that demand for a commodity and its price are always inversely related. So, in the last three years, some of the other things have been changed and some of the other things have been changed. So, in the last three years, some of the other things have been changed and some of the other things have been changed. But next I will talk about supply. What is supply? Supply is a fundamental economic concept that describes the total amount of a specific good or service that is available to consumers. That means there is a basic difference between total supply and total production. Total production may not be equal to total supply. The total supply means that part of production which is available in the market for consumers. Now, like the law of demand, there is also a famous law that is known as supply of law of supply. The law of supply states that the price and the supply of the commodity are directly related. So, in the last three years, the demand for a commodity was less than the demand for a commodity. So, the demand for a commodity was less than the demand for a commodity. So, what I will do after this? I will talk about the equilibrium and market equilibrium in the next period. the concept of equilibrium and market equilibrium. The equilibrium, to explain equilibrium in a simple language, equilibrium is a state of rest where there is no tendency to change. So, according to one of the famous economics, G. J. Stigler, a equilibrium is a position from which there is no tendency to move. That means, if a economic essence or a aggregate of economic essence reach the point of equilibrium, he will not show any willingness to change his position. Now, the term market equilibrium represents a balance among different buyers and sellers. Now, what is the basic condition for market equilibrium? As we have already discussed, the concept of demand and supply, a market is in simple language, a market is in equilibrium when demand for a commodity or demand for a factor of production is equal to supply of that particular commodity or supply of that particular factors of production. Now, what is this equilibrium? That means this equilibrium is a position when a consumer deviates from the point of equilibrium. Now, as I have already told you that a market is in equilibrium when demand is equal to supply. Now, if for the time being, if I am assuming that demand is greater than supply, so what will happen? That means, there is a problem of excess demand. Then what will happen? When there is excess demand, the price will increase and ultimately it will bring a balance between demand and supply. Similarly, what happen when there is a when there is supply is higher than supply is greater than demand, then what will happen? Price will fall down and ultimately it will bring to the point of equilibrium. So, next we will study about the different types of equilibrium. The first we will start with static equilibrium or what is static equilibrium? Static equilibrium means when two economic agents or aggregate economic agents reach the point of equilibrium when we ignoring the another variable or another factor that is time. That means in case of static equilibrium, we are not considering the external variable that is time. For example, if I am saying that in case of law of demand, it establishes a relationship between price and demand. It implies that we are not considering the price of a particular commodity at a particular time or we are not considering the demand of a particular commodity at a particular time. That means we are ignoring the time element in case of static analysis and static analysis is very popular in economics. It occupies an important place in economic theory as well as in analysis. So, next I will sum the comparative static. Comparative static is a determination of the change in the endogenous variable of a model that will result from a change in the exogenous variables or parameter of that model. Comparative static analysis is to come up a kick city hill. Now, what is advantages means any variable define a particular variable and if they define one phenomenon, then what is advantage means So, endogenous means any variable defined within the model and what is exogenous refers to a constant term or parameter which value is already defined outside the model. So, like static analysis comparative static analysis is also very popular in economics. So, one of the classic example of comparative static analysis is I think all of you know the ISLM model. That means the ISLM model basically is a classic example of comparative static analysis where ISLM model try to explain the equilibrium in both money and product market. As I have already told you the classic example of comparative static analysis is the ISLM model where IS curve explain the equilibrium in the product market and LM curve explain the equilibrium in the money market. So, another classic example of comparative static analysis is the Keynesian model which is also very popular in economics. So, dynamic analysis is also very popular in contemporary economics. So, it was professor Ragnar Frins which is considered to be the pioneer who introduced the concept of dynamic analysis in economics. Now dynamic means we are considering the time variable. So, in case of static analysis we are ignoring the time variable, but in case of dynamic variable what we did we basically introduce the time variable. Now, if I am giving the example of static analysis what happen in case of static analysis if I am saying that I am trying to establish a relationship between price and demand then we are not saying that price for a particular time period. For example, if I am saying that the price of a commodity at t and the demand for a commodity for the time period t minus 1. So, those kind of relationship can be explained with the help of dynamic analysis. In other words economic dynamics considers the relationship between relevant variables whose values belongs to different points of time. A system is dynamic if its behavior of our time is determined by functional equation in which variables at different points of time are involved in an essential way. So, like static and dynamic static and comparative static analysis dynamic analysis also occupies a very important place in economics. So, these are the things I want to discuss in this class. So, initially we discussed about demand supply framework then we discussed about the concept of equilibrium or that Vara Hamata or Dharana. Next the market equilibrium Bazar Vara Hamata. Next the static equilibrium Steeley Hill Bishlekhon then comparative static analysis or third up a kick Steeley Hill Bishlekhon and last, but not the least dynamic analysis or third Gotihill Bishlekhon. So, I believe that you got some ideas about market mechanism for my class. Thank you for attending my class. Thank you again.


Good morning Brighton, I'm very happy to be back here for the third time and after speaking about the optimism of technology and the future of money I would like to talk to you about people. And this is me when I was five years old in Romania. I grew up in the mountains in a small village in Transylvania and as I grew up I realized that my creativity and my access to inventing things, to testing things, my way of learning was conditioned by the fact that the girls were supposed to play with Barbies and dolls and the boys were allowed to do more technical things and they would have like these extreme games like the Transformers. So as I grew up I realized that played a very important role on my self-confidence and also on my curiosity. So I decided to create Hackydemia in order to allow both boys and girls to play together and to learn by doing in a very experiential and empirical way and we started organizing workshops for kids around the world and we would teach kids how to build microscopes from old webcams, how to design basically robots, how to test the water that is like that they are drinking, test the food they are eating. We also taught kids to teach each other so this is actually the best part of Hackydemia is that once one of them is understanding they can teach others and after a while we really realized that children and young people like to get involved in meaningful projects in their local communities. So we wanted to show that we should give them a chance to get involved because it's about their future as well. And about this point I met all these people from Afrilabs Network. These are founders of different organizations and movements in Africa and they invited me to go there and work with them and teach them how to teach kids. So we started this initiative called Afrimakers because it was about makers in Africa and why is it making so important in Africa? Because making in Africa is not only about a hobby or building some gadgets, it's actually a cultural manifesto. It's at the heart of what people are doing. It's not a commodity, it's a necessity. So you could notice how people are building boats out of a tree, how they are like creating their own fridges because there's no other alternative. They have their own welding gas and we decided based on this know-how and local tradition to actually enable and empower young people to solve problems in their local community and we selected 10 teams from all around Africa to propose projects they wanted to work on to solve a challenge in their local community. We started in Alexandria in Egypt and this was a team of mentors I was training them. Each team of mentors was receiving like one of our mobile labs just enough to get them started with rapid prototyping like some Arduino boards, a Raspberry Pi, some sensors and the best part is that after they were designing a project they had to go to schools and community centers and teach to kids and this is one of the projects that was developed in Alexandria. I really like this project because we talk a lot about conductive ink and all these industrial projects. They actually managed to do conductive paint with vitamin C and you can also do that in your kitchen today and then the most proactive mentors from Alexandria would travel with me to Kenya to train the new team of mentors over there so like this they would pass on knowledge and also get to know people that they could collaborate with within their region and I think this is really important to enable local people to share ideas and solutions because they share the same context, share the same resources and our desire to go and help is not always helping and these are pictures from some slums in Kenya where our mentors went to train so the contrast is huge. In 2014 we have schools in Kenya where every child has a computer like the private schools but we also have schools in the middle of a slum like this where a million people are living and I wanted our mentors to be exposed to that and to understand why it's important for them to work with both of these communities. After that we went to Tanzania. Here we had a project for example on the on the microscope we went to Ruan that we had to go to schools where there was no electricity and like drive on dirty roads for hours. We also had the big challenge of accessing parts and electronics so the local mentors had to invent and create their new boards. This is like an Arduino board that is only two dollars and a half that they put together by using all the electronic parts. We worked under harsh conditions. The longest time I stayed without electricity was in Botswana for five days and I think you know it's very important to to look at this experience and journey of making around Africa as something that we could all learn from like all the conditions we have for prototyping learning going to work we kind of take them for granted and these people don't have the same conditions but at the same time because they are facing all these big challenges they are sometimes more creative and better at improvising and after doing this whole journey of making we actually documented all the projects and the stories there is a book that will be launched next month on this project and there are a few learnings that I wanted to share with you today. One of the important things that I learned in this journey I was there for four months is to let go. There are a lot of things that I had to adapt to and I didn't understand and I was there more as an enabler but I really really wanted to focus on the people in the process and not on the outcomes because the idea of this project was to plant the seeds for local collaboration long term so it didn't matter what would happen in the immediate that what were the immediate results of these workshops it mattered more if these people would stay engaged and continue to work on this project. Don't compromise on values. The reason why we selected local teams that would propose projects to solve problems in their local communities because we thought like these people could connect at a value level and once we connect on a value level everything else works. Use humor when things become overwhelming. People always ask me because I travel a lot and work with people around the world how do I constantly adapt and I think humor is one of the best ways for doing that. Don't forget there are 15 stones. This comes from a Zen Buddhist temple in Japan. They always have 15 stones but no matter where you sit in the temple you're not able to see all the stones and this is kind of a spatial lesson that we it's really hard for us as a species to have an overview and to be able to always kind of understand how things are related and how things function and just accepting the fact that we can't see it all and we can't understand it all and question the way we see and understand things is important. Empty your cup, this is also like from from Zen Buddhism, we all can learn from each other but we need to be you know have this mental attitude to be willing and ready to learn from each other and as I told you this was in the beginning of this year so I wanted to show you what's the progress and the status of the some of the people that participated in the projects. Opemipo who's only 21 years old ever since has organized 10 workshops 10 additional trainings for local mentors in Nigeria they went to schools and has started an internship at Intel and he's constantly pushing this maker movement in Nigeria and pushing new activities for for his fellow students. I also wanted to to share the updates from Sharif, he was one of our mentors in Alexandria one of our fellows. Ever since Sharif actually started a company his company is called Resha. They're building a mobile laser cutter for crafts people. Most of the laser cutters today are around 3,000 euros their laser cutter is actually 250 euros and it's meant and built for craft women in Egypt to make their work easier and to enable them to earn more. I also wanted to share the story of our fellow from Botswana Bocamoso who's 23. She actually participated in a project in Berlin this summer where we built an invention lab in a shipping container and I'm gonna play a small video where she talks about her experience with afremakers and the camp. Hi what's your name? My name is Bocamoso Pallai from Botswana and where are we now? We are in Berlin here for a maker camp which is about making and creating core projects with their resources that we have. And what was your project at maker camp? My project at maker camp was electricity monitor which measures the amount of electricity consumption in homes. And how does that work? How it works is that we used a sensor my current sensor that looks like this why you yeah it's sort of a magnetic field here why you put a cable that you want to measure current flow in then you close it you run a program in them the problem that we wrote in the environment and then you just measure the current consumption for them. And why did you want to do this project? I wanted to do this project because from back home we have a lot of we have shortage of electricity and a lot of people are not aware of the amount of electricity they're using and how they're consuming it so I wanted to create something that will make them aware of the consumption that they are doing and how by so doing they'll be able to see that okay I'm consuming this message how much I can spread them so that you have enough when you run. And what's your plan now that you go back home how are you going to continue this project? Okay my plan is to tell people about the project try to chest it out in the market to see the acceptance of it and then from there if they're more interested get the community more involved in the project and try to develop something much more effective and get it in the market. And what did you learn at Makercam that you didn't expect it to learn? I learned so much we could talk all day I learned that project management is virtue like you have to know you have to have a step by step plan on how you do your projects from day one to accomplish in the project. I'm not a president who is a public speaker so we were forced to learn how to talk to the public and interact with people and I thought that was a very valuable lesson. What else we learned how to make the makerspace as you can see it and then the process of actually doing something like this from recycled materials and stuff so yeah that was the most valuable lessons that I had. And if you were to choose a favorite moment at the Makercam what would that be? Favorite moment was the success of the Makercam like the project finishing the projects on time and presenting them and actually having people that like the audience were impressed with what we had so I enjoyed that very much that you managed and if you had one month and you managed to succeed. And if you had a message with young to younger women back home what would you tell them? I would tell them the making field electronics engineering field is not just for men we also can do this as you can see I managed to create something that is very useful and very electronic I had to learn to use a circuit and mechatronics but I managed to give them a female and they all can do that so they shouldn't be afraid of the girls. Cool thank you very much. Thank you so much. Yeah so I know this is not as sexy as synthetic biology and artificial intelligence but these are the pains of growth of starting to actually implement that and distributing our future. For Bocamosa to come to Berlin we had to call the Botswana embassy for three weeks every single morning to get her visa we had three other mentors from Africa that couldn't come to our camp afterwards and she had to stand against her mother the minister of transportation of the country and many other people that were trying to convince her to stay and not lose a semester from university although she knew she would pass the exams so for a girl her age to be that brave it's actually really admirable and ever since she she went back like in the past two months in Botswana in Gabarone she's leading presentation workshops training continuing to work on her electricity consumption consumption monitor and this is what it means when you're trying to to take an idea to take the technology solve problems and actually do it with local people and local communities step by step and and I think this is important because I came across this this study from MIT and we talked about money and growth and innovations and actually some of these researchers from MIT discovered that the metric that is the most telling at predicting our growth across the planet is actually the economic complexity and this economic complexity is defined by the diversity of activities within the society and the diversity of products and actually this is a graph where you could see where we stand like on on the first line we have the economic complexity and on the other side we have GDP per person per capita Europe and Asia are on the right side and all the yellow dots are the countries in Africa so why is that like if we we take a closer look this is what US exports and you can see it's very diversified anything from cars medicine machines this is the one for UK so our economy is quite complex and we have a whole range of activities but if we look at Nigeria which is actually one of the biggest economies right now in in Africa this is how it looks like so where does this diversity comes from it's a lot around tacit knowledge around communities of practice around capacity building this is also like how how products are connected everything you see in violet is chemical products everything you see in blue is machine products everything we do is connected which is why this type of growth is only going to last as long and as we look into into the change and as we have all these people looking of the future of Africa are reducing poverty I actually think that this change starts with people so this is an equation that I imagined this morning so I I think time you know we can think about change like in amounts of time multiplied with the work which is defined by innovation and R&D and divided by the number of people and the amount of collaboration that is happening between all these people and I want you to look at this imagined equation and I think the key element there is time we do not give these people the time to create their own solutions to develop their own initiatives to develop their own project their own industry there is too much foreign intervention happening right now in Africa and the change there is not going to come from all this funding that we are pushing on the trends it's actually going to come from developing local infrastructure from developing local diversity from recognizing old local know-how and encouraging it and I think I think this is important and relevant for all of us because if we think about the history of innovations and the history of manufacturing we kind of went from this which is Bell Labs Tesla are when they they invented the first satellite in 1970s to this this is innovation today by the way like this is how we build things and I think there's something fundamentally wrong with it and my message for you today is that I think in the face of all these complex challenges that we're you know handling we need to play together we can't have the arrogance of thinking we are better or more intelligent and we need to accept the difference and recognize it and not impose our values over other people and actually invite them to the conversation and invite them to think with us how we're going to deal with these challenges and with these problems that affect us all in terms of climate change economic crisis so yeah that was my message for for you today and I I think one question that I would like to to leave you with is what is meaningful for you how can we add value in what we do every single day and how can we work on meaningful projects together and kind of challenge our views and challenge the way we were brought up in a particular system so yeah that was my presentation thank you


Hello everyone and welcome to the CircuitPython Weekly for December 5th, 2022. This is the time of the week where we all get together to talk about all things CircuitPython. I'm Katny and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. Its development is primarily sponsored by Adafruit, so if you'd like to support Adafruit and 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. We hold the meeting in the CircuitPython-dev-text-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 a U.S. holiday. In the note stock, there's a link to a calendar that you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive those notifications, please ask us to add you to the CircuitPythonista's Discord role. There is a note stock to accompany the meeting and recording. The note stock contains timestamps to go along with the video, so you can use the dock to view only the parts of the video that interest you most. It tends to run 45 to 60 minutes, so this gives you the option to skip around. After each meeting, we post a link to the next meeting's notes document in the CircuitPython-dev-channel on the Adafruit Discord server. Check the pinned messages to find the latest note stocks so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hugger forts and status updates in the document for us to read during the meeting. The meeting is held in five parts. The first part is community news, which is a look at all things CircuitPython and Python on hardware in the community. The second part is the state of CircuitPython libraries and Blinka. This is a statistical overview of the entire project and a chance to look at the project by the numbers. Next up is hugger ports, which is the first of two round robins. It's an opportunity to highlight the good things folks are doing, taking the time to recognize awesome folks in our community. The fourth part is status updates, the second round robin. Status updates is an opportunity to sync up on what we've been up to. Take a couple minutes to talk about what you'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 and final part is in the leads. This is for more long form discussions that may come out of status updates or be something you've identified ahead of time is too long for status updates. And that covers how the meeting will go. I will make a note regarding the meeting times. Please look into it for the holidays. We are not going to be holding a meeting between Christmas and New Year's. And we may be moving a meeting or two to Tuesdays and the calendar will be accurate and we will be sure to let you know the week before. But if you're interested in finding that out now, you can check out the calendar. And with that, I will get started with community news. First up 100 circuit Python Blinka compatible single board computers. So Blinka brings circuit Python APIs and therefore circuit Python libraries to single board computers. It's a PIP installable Python library that runs on normal desktop Python. The circuit Python runtime isn't used. Circuit Python libraries can also be installed via PIP. The number of boards that support Blinka is now 100. If you're interested, check out the guide or there's a blog post also linked in the notes document. The project of the week was a Hanukkah lightsaber. A Hanukkah persistence of light lightsaber. And this is a quote from the author. Toward the Jewish month, Kislev, the month of light, I built a Hanukkah lightsaber prop based on a maker's project from the Adafruit company. Besides building the hardware, I made necessary adjustments for the Hanukkah holiday. 30 colored RGB Neopixel LEDs are connected to an Adafruit circuit playground board responsible for processing a bitmap image divided into columns. And when deflected the lightsaber and exposed to a camera with a slow exposure, you'll get an image floating in space without the person even deflecting the lightsaber. Happy holidays full of light to everyone. And there's a link to Instagram there. And finally, Pico Touch Synth. This is a quote from Todd Bot on Mastodon. First light on Pico Touch Synth and the cap sense pads work better than the Pico Touch board. The reverse mount Neopixel LEDs are totally awesome. The test code is in CircuitPython. So that has been community news. It is pulled from our CircuitPython weekly newsletter, which is a community run newsletter emailed every Tuesday. The complete archives are available on adafruitdaily.com, adafruitdaily.com slash category slash CircuitPython. Highlights all the latest Python on hardware related news, including CircuitPython, Python and MicroPython developments. To contribute your own user project, you can edit next week's draft on GitHub and submit a pull request. You can also tag a tweet or a toot to with CircuitPython on Twitter or Mastodon respectively, or email cpnews at adafruit.com. And that is community news. Next up, the state of CircuitPython, the libraries and Blinka. This is a statistical overview of the entire project, and it gives us a chance to look at the project by the numbers. This report contains information from the previous seven days. Any changes made today will not be included. So first up, overall, there were 98 pull requests merged by 20 different authors. A few that I don't recognize are Nicen, Jay Shimbo, Pete Kowalski, Kenneth Ryerson, and E. Karatso. Thanks to everybody who contributed and welcome to our new authors. And we had 11 reviewers. We had 40 issues closed by 13 people and 20 opened by 13 people. So next, Scott will talk about the core, then I will talk about the libraries, and Melissa will talk about Blinka. So Scott, go ahead. Thanks, Catney. State of the Core, 27 pull requests merged, which is awesome. We had 11 different authors. Some new names to me might not be the very first time, but newish to me. Jay Shimbo, Pixel Clay, Bill88T, and BablockB. Thanks to all those folks for being relatively new authors of PRs. We had four reviewers, thanks to Mike Rodev, who's a reviewer off and on. We have 22 open pull requests as of last night. We have three of them that are 150 plus days old. And I think this number is down thanks to Dan for closing some that didn't seem to be progressing at all. Issues-wise, we have 18 closed issues by five people and 12 opened by seven people. So we're net down six, which is great. And there's a lot of people involved, which is also really awesome. We have 577 open issues. This says 24 open issues on 8.0, but we just did a pass, so it's now 18, which is good. We have 504 long-term issues and two issues not assigned to Malistone as of last night. So doing pretty good. We are still slowly growing in issue count, but largely in that long-term category, which is to be expected. And that's it for the Core. Thanks, Scott. Next up, the libraries. So this applies to all the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore, CircuitPython underscore, as well as a few extras such as the community bundle and our cookie cutter. So across all those repositories, I had 64 pull requests merged by six different authors and seven reviewers. We closed out two over two weeks old. One of them was 91 days old. That's excellent. A majority of them were nine days old. These were all filed for a update across all the libraries, which is why the open pull requests from the last meeting was so high. And that's why it's down now. And that leaves us with 39 open pull requests, which is much closer to our usual number. We had 19 issues closed by nine people and six open by six people, leaving us with 585 open issues. 97 of those are good first issues. If you're interested in contributing to CircuitPython on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including an actual list of the open pull requests and a list of open issues. If you're new to everything, check out good first issues. Those are a great place to start. If you want to get involved with reviewing, take a look at the open pull requests. If you have the hardware, test it. If you don't, take a look for code syntax spelling, that sort of thing. Leave us a comment and let us know you did that. And once you're comfortable with that, we can talk about leveling you up to the review team. The next step is library PyPI weekly download stats across all of the libraries on PyPI. We had 195,955 downloads and the list of the top 10 libraries from the past week by downloads is listed in the note stock. One thing that is a little interesting this week that I haven't seen since we got back into tracking this is that everyone on the, the whole library on the top 10 list is over a thousand downloads. Typically that's not the case. So there's been a lot of downloading in the last week. Library updates in the last seven days. There was one new library, Adafruit Circuit Python Pixel Map, and way too many updated libraries to list. So that was truncated. And that's what I've got. Next up is Melissa to talk about Blinka. Hello, so Blinka is our circuit Python compatibility layer for micro Python and single board computers such as the Raspberry Pi. This week we had seven pull requests merged by five authors and two reviewers. And there are currently seven open pull requests. There were three closed issues by one person and two open by one person, leaving a net of 86 open issues. There were 33,616 Pi PI downloads in last week, and there were 7,007 Pi wheels downloads in last month, and we are now at 100 boards. And that's it. Thanks for listening. Thanks. All right, next up is hug reports. Hug reports is the first of our two round robins where I will start and then I will go through the list. I will read off notes for folks that are participating but not able to speak, and I will call on folks that are able to speak to read their own. This is an opportunity for us to call out the great things that folks are up to in the community and just generally point out positivity. So, I will start and then I will head down the list. The next two will be people that I read off. Hug report to tech trick for making a about happy and getting the library report running again to know it for designing the stand for my upcoming project guide and shipping me a printed copy to Liz for being an amazing collaborator for being incredibly helpful and supportive and an all around great person. I didn't keep track of anything last week apparently. If I missed you, it wasn't intentional and a group hug for everyone. Next up is notes from anecdata was a hug report for Naradok for figuring out the multi device nature of the mdns host name issue. Next up is see Grover who's text only a hug report to foamy guy for always informative streams and patients with my questions and a group hug. Next up is Dan. Thanks. Thanks to spa blots in discord for and then in GitHub for debugging and then submitting a PR. There was a confusing HTTP server issue, which we tracked down to a dictionary being passed in and having being modified when it shouldn't have been and that was so that was a bunch of us worked on this and we figured it out together. Thanks to Bab lock be in GitHub for GitHub code spaces support for the circuit Python repo. I don't exactly understand this, but it sounds very interesting and I'm trying it. Thanks to bill 80 for the PR for Pico W access point support.  And thanks to Jeff and Scott be after our 1pm internal meeting we had a very short 80 bug triage meeting again and managed to reduce the number of 80 bugs. So that's good. Okay. All right. Next up is DJ Devon three but I do not see them so I will read it off. I hugged everyone who agreed to receive a TR cowbell and provide feedback to John Park foamy guy and Reese brothers for their streams I learned something new every stream and a group hug. Next up is foamy guy. Alright, thanks, Kenny. First hard report this week. Thank you to Scott for providing throw review and feedback on the display change that I made inside the core. I learned a lot about both display and more generally just how the core works how to do stuff inside of it. So that was good. Definitely appreciate that. Thank you to everyone who's been discussing and sharing ideas about.info or more generally the way that we store secret information. I think it's a good discussion to be having. Even though it may be difficult to figure out what's the best path forward I think it's good to get it nailed down. So thanks to everyone for being involved. And lastly this week for me thanks to Johnny Bergdorf for putting me in touch with the simple electronics podcast folks may appear on a future episode of that podcast. So thanks. Excellent. Next up is Jeff. All right. Basically, I appreciate people sitting down and talking to me and working stuff through so. You and Dan and I had a good discussion last week. Dan and Scott and I had another useful discussion just before this meeting where we walked through some stuff about. Issues I was working on as well as the whole 80 backlog. And then Dan and Scott in particular for working together and finding a way forward from dot env we'll talk more about that later. And to bill 88 T for the pull requests that implements access point on Pico W. Really appreciate your work on that one. Thank you. Thanks, Jeff. Next up I've got notes from Keith, the E. E. High report to myself for a wonderful write up about what to expect when teaching circuit Python to folks with a programming background who might not have experience with electronics. And the hub for the community as a whole for always being awesome. Next up is Melissa. Hello. So I wanted to give a hug to everyone who contributed to us getting to 100 blink of boards to get need for quickly emerging a PR that brought that show that we had the 100 boards in the pickup Python org and a group of everyone else. Thanks. All right. Next up I have notes from Tammy makes things who gives me a hug report for hosting the meeting and a group hug. Next up is Scott. Good morning. First, a hug to Booleanmatic for fixing an issue with a slow duty cycle setting of PWM on the RP 2040. There's a PR out for that. Based on some discussion in the forums. Hug report to anecdata and Naradoc for helping with the empty NS name mangling debugging and testing. Hug report to evil Dave 666 for fixing your creator ID issue they found one adding another one. Lastly, a hug to Lee Atkinson 24 for the analog Baphio module that I revised last week. All right, thanks. And finally, I have notes for Tectric, who has a hug report for me for helping him out with Adabot and for a great conversation last week to learn more about mastodon. And to Naradoc for paying him about a neat issue with dependencies always enjoyed digging around in the packaging world again. And that is hug reports. Next up is status updates. This will go basically the same way as hug reports. However, this is an opportunity to sync up on what we've been up to since the last meeting and what we're going to be up to until the next meeting. So take a couple minutes talk about what's going on with you. And this is also an opportunity to provide tips and tricks if anybody's got quick questions, folks can answer and if it turns into something longer we can always move it to in the weeds. With that, I will get started. My list is pretty short. Last week I put a mastodon API intro guide into moderation. I moderated Liz's latest guide and updated the feather RP 2040 guide to reflect the latest version which now has a user controllable button. The boot button is now connected to GPIO4 and it is a right angle button so feather wings don't block it. This week, I'll be working on the I spy breakout guide with Liz. And then I have a project guide which is an event countdown timer display using quad alpha numeric three quad alpha numeric displays to scroll text. So that is sitting on my desk and looks excellent in the new stand. All right, that's me. Next I will read see Grover who is text only. Heads down working on a friend's vintage guitar pedal restoration for the last two weeks. Reverse engineered the capacitor leakage damaged PCB to help with component location not to remanufacture the board yet. Had to treat the pedal with great respect since the bucket brigade chips that components are no longer available. And yes the project involves circuit Python for the 80 9833 programmable waveform generator used for the audio tone and sweep tests and a link to that code I think is in the note stock. Developed a proof of concept wrapper class is that a thing that wraps a layer around display dot palette object to make it respond to typical list slice syntax. Imagining all sorts of psychedelic image surgery of bitmap images as a result. And finally snow shoveling lots of snow. Next up is Dan. Okay. In the past week I've been following up on and trying to reproduce a number of issues of 800 issues. Some of them are not reproducible. Some of them I'm not sure about so. I didn't actually solve that many issues but I'm investigating a whole bunch.  So I oversaw and debug some HTTP server issues. That's kind of relapsed with what I just said. I just tried a little thing we have we're having a trouble with Pico W startups and on certain samples of the Pico W. So I just stuck a delay in somewhere and had the people for whom it was a problem tried and it worked for them. And Jeff and I are still scratching our heads about this. But we did discuss it in the internal meeting before this. And I'm going to start to work on beta five release notes.  We'll probably just go ahead and do a beta five and do a beta six sooner though. We always say that and we don't always do it. So, but we need to catch up. We're behind it with zillions of PRs that we should put out there in a beta. Okay. Thanks Dan. Next up I have notes from DJ Devin three. Received PCBs of my cutie pie parent BFF. It's apparently useful for LED projects that need a lot of grounds. I will be using it in my dragon mask to make existing wiring much smaller. I have extras if anybody wants one. And there is a picture of that in the notes started assembling and packaging kits for TR cowbells to give away for beta testing. Found some serious hardware design flaws after more testing. I routed things in a way where all I squared C buses are being used should still function as intended. If people want to add a display or other peripherals, they'll have to use SPI only started designing cowbell version 1.3. Hopefully ensuring I squared C expansion and stamina will work. Made a YouTube video and upgrading the battery in a hyper X cloud flight wireless headset from 100 or 1500 million amp hours to 1800 million amp hours. It requires a three wire thermostat type battery that I couldn't find in the U.S. Had to get it from China took a month to arrive and the upgrade process was a success. Next up is foamy guy. Great. Last week I finished up a couple of changes in the core with the pixel map new core module as well as the display APIs. I resolved the issues that were reported in the Python layer for the pixel map. So the Python code that makes use of that new core module. I started working on updating Blinka display APIs to match the new core APIs. But I found that I ran into issues trying to use Blinka display in the way that I was using it, which is with Pi game. Kind of not necessarily how it's meant to work. So I ended up troubleshooting that and figuring out how to get it back to working in my environments and ended up spending most of the time on that instead of actually changing the API like I sat down to do. For this week though I do want to get back into that and actually change the API to match the new core one because we do want to match over there on the Blinka land. This morning I've been doing PR reviews and testing. A big one that I was looking over this morning was for the WizNet library that handles Ethernet connections. And I got the hardware out and we'll do some testing on that later on this afternoon as well. Some other stuff in my mind for this week. I want to try to come up with the easiest way to combine matrix portal projects or really theoretically any of the portal based projects. I've seen folks come on Discord a few times who are not necessarily brand new. They've gotten their matrix portal or whatever device it is, MagTag or whatever. They've gotten it out. They've hooked it up. They've done some projects. They've seen some cool stuff and they can switch between them. But they want to make it to where they can have one code pi that does multiple projects basically. Maybe they switch it with buttons or maybe it bounces back and forth on its own after a few seconds or whatever. I'm not aware of any examples that are quite like that. If anybody knows of one, point me towards it. But I'm going to try to come up with the best way to do that and just have something that we can show people that will hopefully explain the general approach for how to do it. And a couple of specific examples with some of those sort of beginner level matrix portal projects and trying to combine them together. A few other things that I'll be getting into are adding pixel map to the bundle that pixel map library is created. It's all spun up and got all of its stuff in, but it does need to be added to the bundles still, so I'll make that PR this week. And then in project ideas, I'm thinking about trying to make a menorah on the matrix portal and continuing with the matrix portal theme. I'm going to plan out and maybe try a few different ways to animate some little flames on the matrix portal display and see if I can get something that looks nice for that. So that's what I have going on. Thanks. Thanks, Tim. All right, next up is Jeff. Hello. First of all, a belated hug report to see Grover for working on this cool palette stuff. I am excited to see that come to fruition should make for some fun little projects anyway as to what I'm up to. I worked on this.env replacement. I'll continue that this week and in a bit down in the weeds, I will tell you what's going on with that if you haven't been following the PRs. Other GitHub pull requests activity. I opened a draft pull request for a future product called the Adafruit Think, Inc. RP2040. It's a little kind of tricky style board that has a ribbon connector for e-ink displays. It should be cool. I added socket pool.gai error so that when you are using sockets and you get an error, you can tell whether it has to do with resolving the host name or not. That's compatible with standard Python socket module. I wrote a PR called ensure orderly shutdown of SSL socket. And after talking it through with Dan, I think there's just one little cleanup to do and then we will merge that. I also need to test whether there's a different way to cause the crash that was originally reported. This fixes a user reported hard fault. Whether there's another way to reproduce it that doesn't involve the shutdown of the whole Python interpreter. And that will confirm that kind of my understanding and Dan's understanding of what is going on is accurate and satisfied as to what the root cause really is. Let's see. There's some other items in the document.  The other one that I fixed was there were some problems with SD card IO on the SAMD family microcontrollers where it would say that your pins were in use when they should not have been in use. So I fixed that and I tested it and confirmed that the Adafruit SD IO breakout works with the Grand Central M4. I reviewed and accepted some other PRs including the PyCow access point from a community member. And so my work this week is to complete the next keyboard guide. I have texts that I need to write. I need to complete the wiring for the version that I'm going to photograph in the guide and then make those photos. And then after that it's returning to work on the .env replacement. And that's what I got. Thank you. Thanks, Jeff. Next up is Melissa. Hello. So this last week I worked on rewriting the USB workflow or actually continue doing that to use the file system access API to be able to select a working folder and then I have a PR in for that. I also fixed an issue with the USB web serial connection locking up on disconnect so it doesn't do that anymore. And I helped with adding boards to Blinka and on to circuitbython.org. And this week I'm working on improving the overall connections workflow when there are multiple steps. So like if somebody like connects to serial but doesn't select a file system then it's total handles stuff like that better. And then I'm working on improving the BLE workflow after that. And that's it. Thanks, Melissa. Next up I have notes from Tanny Makes Things. Last week, super busy with work and holidays but did some work on a digital Christmas ornament, a gift for a coworker. And on my attempts to add NRPM message support to Adafruit MIDI. This week hoping to continue to make progress on these things despite the fact that we're doing performance reviews at work. And I'm missing next week's circuitbython meeting for a three hour performance review calibration session. Other had to get new tires on my car because of a huge nail on the freeway. And I was pleasantly surprised when my car stereo noticed the drop in tire pressure and showed me an alert with a screen displaying all four tires, all four tire pressures from the TPMS sensors. This gave me enough warning to get to a safe place before the tire went flat. I'm curious now to look into how TPMS works because that was really cool. Next up is Scott. Hello. I fixed an issue with the ESP32 S3's deep sleep, which has been a long standing bug that we thought was an expressive problem. And it turned out to be because we don't use their build system. There's a weird build flag that we needed, linking flag that we needed. So I found that and fixed it. There is a report that it's not working for somebody, but I'm going to take a look at that because I was testing it and it seemed to be working okay for me. So I'll take a look at what's going on with them. I also fixed the MDNS name mangling issue. The expressive MDNS code tries to make sure that the hostname is unique. MDNS can have a way of seeing if anybody else has the same hostname, but it's not really designed to work when we have two hostnames that we're dealing with, one that's unique like we have and then one that's shared. So I improved their MDNS code to make sure it only mangled the right thing, although it doesn't actually mangled the thing that clies. But anyway, it works, I think, better for a second by then. They opened an issue on their stuff. I also reworked the... Oh, I copied it as audio buffio. It's analog buffio, which is an API for getting a whole bunch of analog samples in a row. Not really meant to do into audio or anything, but you can set how many samples you want and how long. I reworked it a little bit to... The buffer was being passed into the constructor, and I moved it to pass it into the read function, and I renamed that and stuff. So that'll come in the next beta. You can now control C as well if you really slow it down. And now I'm starting to redo the coprocessor API. I've sketched out a memory map module, which will allow for just raw read-write access to particular regions of memory, and that's important for writing to the memory that the ultra-low-power processor on the S2 and 3 uses. And then I'm going to look at the coprocessor API as well. I haven't fully decided what that API is going to be. I don't think... I was just looking at the RB2040, and I think it needs to... It may need to be something more custom. I'm not entirely sure yet what that API will be, so I might switch it from a generic coproc API to a specific ESP-ULP API, maybe. That sounds better to me already. And then I am starting to travel for the holidays next Wednesday, so I'm trying to do any urgent stuff that comes before that. I'll be working some and will have some stuff with me, but not nearly as much as I have here at my home office. So if you have anything that you think is urgent for me, please let me know. And then in non-circuit Python stuff, I'm... I did a Google take-out of... We have two Nest cameras now that we're running in the house. One to watch Ari, who is my kiddo. And then one in the... Yeah, one in is Craven, one downstairs, and I decided to just download all of it to see, which turns out to be about 700 gigs of MP4 video from the last two months of all that. So that's been interesting, and I'm really glad I have fiber internet. I can download a 50 gig file in like 10 minutes? 10 or 15 minutes, which is amazing. And I have a Python script that I'm using to hash all the files before I scroll them away. So hashing them, keeping track of how big they are and storing that in a SQLite database. And I want to do that also because I want to get metadata from Google Photos and be able to know which photos do I have locally, which photos do I have on Google Photos, because they're automatically backed up that I need to download and all that stuff. So that's non-circuit Python things. And then talking a bit more about what I'm doing kind of once I'm in Michigan, which is where I'm going for the holidays. I want to kind of get the STM32G0 StemAQT tooling kind of all the way there, meaning we can like load code and have a template repository for creating code that runs on a StemAQT device. Probably acting as like an IO expander, or I was thinking it would be cool to have a program on the G0 that was literally just like a memory access thing. So you could, in the same way that memory map allows you particular access to stuff, you'd be able to do that over I2C. And basically write Python code that is very slow, but is actually interacting with anything on the other chip, which would be kind of neat. Dan and I talked about using a circuit Python device and PyOCD for a DIY SWJ tag in a pinch sort of thing. So for example, if you have an old NRF board that has a bootloader that can't update itself, this would be a way for us to kind of walk people through using any of our boards that run circuit Python to just like in one time just get it flashed. PyOCD makes it really easy to use plug-in system, which is really handy. And then I'm going to look some more into the logic analyzer software world, because one thing that I've wanted to do for a long time is a basic logic analyzer as well. And I'm kind of brainstorming a feather wing that would be like a combo SWDJ tag and a basic logic analyzer just for like really simple debugging like I squared C and spy and stuff. Yep, so this is the last full week of work at home, and I'll be around off and on over the holidays. And that's it for me. Thanks, Scott. Finally, I have notes from Tech Trick. This is last week, final touches on the PyPI stats reporting for libraries in Blinka. All the bugs should be worked out, but I've said that before. Happy shrug emoji. I'm working through many of the issues regarding typing and library infrastructure in my to-do list and going through a small backlog of PR reviews. This week, getting more information about the pilot update for the learn guide repository, starting to fix the warnings in the GitHub actions, or that GitHub actions is raising about deprecation. And in personal news, finished my last lab for my grad course for an embedded systems course. Thank you to everyone in this community for helping me to learn enough that programming the Arduino in this course in general has been relatively pain-free. Took and passed the Arduino certification test, though I'm still confident in my ability to conjure blue smoke when using one, and learning and practicing my C skills by doing the advent of code and C this year. It makes me appreciate Python, MicroPython, and CircuitPython so much more. And that is status updates, which brings us to in the weeds. In the weeds is an opportunity for more long-form discussions or discussions that just didn't fit in status updates. If you have a topic, please post it while other people are talking. Otherwise, once we get through the four listed here, we'll wrap up. So I will call on each person to talk about their topic. So first up is me. The new Feather RP2040 revision now has a user control button on it. Obviously, there are far more of the previous revision in the wild than the new version yet, and all those original versions will be in the wild for a long time. So how do we handle adding board.button to the Feather RP2040 CircuitPython pin definition?  Is there a new board diff? There isn't a new board diff. It's the same product number, right? Yeah. It's a revision of the same product. We won't ever be selling them again with a flat button that isn't user-controlable. Maybe we should make a new definition that's no button. I don't know. Yeah, I know. I gave it a lot of thought, and I don't have a conclusion either. I think that that's sort of... I mean, in the download, maybe we should, in CircuitPython.org, maybe we should have a Feather RP2040 no GPIO4 button or something like that. And it's a different color, right? Yes, it is black again. Right. So that could also be... So I think it sounds kind of good to me to... Rather than have a with button, or maybe we should just have like... What's the color of the other one? Or the other ones could be pink or something, right? Or black, yeah. So I think changing the name of the old one makes sense to me, but I don't... I agree. Because it seems weird to have a weird named one for every board moving forward? Yes. Don't change IDs. You could rename it on the website, but the actual name of the board should be the same. Doesn't it... Doesn't the build have its own name, or does the build pull from the board name? Inside, yeah, inside... Do you understand what I'm asking? So I'm saying that we can copy the old one, call it no button, and then edit the regular one, and don't give it a new name. No. Why not? Because that changes the experience for the people that have the old one. They need to know that the name of their thing changed. Right? It's an ID. It shouldn't mean something else in the future. I would just call it V2, or Rev, whatever. Yeah. If it has a Rev, does it have a Rev on it? Yeah. It's got to have a Rev. I just got one. I think it's D. Well, it's got a D on it. I guess that would not be a terrible way to go, because people can actually look at the board and see the circle. At one point, we had a Rev B for like Metro M4s or something like that. That board went through several. But we didn't sell nearly as many of the other old ones. Something Scott mentioned, tickled. Is it possible to rename everything on circuitpython.org for that board? It'll still be the same. The build or whatever will still be the same. The background stuff will still be the same. Don't include Rev D in the name on circuitpython.org for the new one, but have the build say Rev D in it so that it's different, right? Was that what you were suggesting, Scott? Yeah. That's what I'm saying. The ID should stay the same. But if you want to have, in the human readable version in both, you could say this button or that button. Yeah. OK. Style. I don't mind that at all. I have another idea. OK. Which is, why don't we call the name of the button Rev D button? But how does that, then people without the button can still put in board.revdbutton? Yeah, but they will say, why is it called Rev D button? But they also, they both have buttons. They both have boot buttons. Yeah. But the difference is one of those connected GPIO and the other is not. And I don't think calling it Rev D button makes sense because, A, it won't work with existing code, which a lot of things do. And B, people will still try to use it and it'll do nothing. OK. I think changing it to something weird in the existing build is probably not the best way to go. Right. I don't suppose we can detect when CircuitPython starts whether the button is hooked up in that way or not. I mean, I'm pretty sure the answer is no. And anyway, we can't, we don't have a way to change the content of the pins, the microcontroller. To change the content of the pins module. Yeah. So that doesn't help forget it. So Scott, are you OK with us or me creating the second for Dev calling that one something different in CircuitPython Core and then changing up the name of the existing one on CircuitPython.org, like visually? Yeah. I would change both. I would, I would have, because you're going to want to make it clear what the difference between the two is. Do you want them to have a different, different PIDs, USB? I mean, that would probably be best. I mean, they're cheap. Right. Yeah. Yeah, I don't think why not. OK. I will need help with that. But because I've not done that before, but I'm happy to learn. Can we? Oh. Aha. Now I understand. Well, I just, I was like, what? I don't get it. The boot button is connected to GPIO4 as well. On the new ones only. Right. Before it was just the boot button. That was the very first RP2040 board that she made and she didn't connect the boot button on that one. She put a diode in. So that it can still control the flash. Yeah. It's still a boot button. It just also is available in code, just like it is on the QDPI, just like it is on whatever, like it's the same on all the other RP2040 boards. Oh, right. It's the trick that the Pimeroni people did after we did this first board. Yeah. I just add a new board deaf and call it RefD. OK. And in the text of both boards on trickbython.org, we should say like if your boot button is angled this way. Yeah. And do you have a RefD on there? I mean, there will be a RefE maybe at some point too, so which might have no changes. So I'm trying to think of a better name than RefD, but I don't know. I would just call it RefD and assume that people understand ordering. Yeah. And then you want new PID, VID, or whatever it is that changes? Yeah, PID. OK. Got it. Yeah, VID is vendor ID. Yeah, OK. OK, OK, OK. That stays the same. Got it. Yeah, Dan can show you how to do that or I can show you how to do that. Keen. I already changed the board deaf to include the button, but I didn't get any further with anything. So it's not like PR or anything. It's just local, but OK. Thanks. The next topic is by Jeff. Right. So I was going to talk about this .env thing. And after I get done talking, I will paste links to a couple of issues and to my branch. But basically kind of collectively we identified that there were some things we didn't really like about the .env. Some of those things were the final name is difficult for a lot of people, especially on Mac, to access at all. It's a pain to access hidden files in this way. The .env, there are like packages for .env for several different programming environments, and they all get the quoting and the syntax a little bit different. And so we felt it wasn't quite standard enough. And also it's very different from the way that quoted strings are written in Python. So we went around for a while in a couple of meetings, and we've decided and documented on one of the issues that what we're going to do is implement a subset of the Tommel configuration language, which is similar to any files. If you know those, that's INI initialization files. ANY files would be something else. Anyway, so the new file is going to be called settings.tommel. And to get values out of that, you will use os.getenv, which does work today with .env. It's one of the two ways to get it. That will be the one preferred way to do it once we switch to settings.tommel. And we're implementing a subset of the file format. So you'll be able to read strings and numbers from what is called the global table, which is just the part at the top of the file. This leaves it open that we could later add a maybe implemented in Python as a whole Tommel parser, but that would be for the future. Anyway, and then in the notes document, it shows an example of what it would look like to set your Wi-Fi SSID and password. And of course, we will do our best to update all the guides and docs to reflect this. Due to the timing of things, this is probably not going to be in the next beta, but the beta after that. And yeah, so that's kind of an overview of what's going on. And if anybody has questions, I'll answer them. Guys, I'll mute and go find those links for the chat. I guess it's late. All right. Thank you. All right. Scott, you have the next topic. Oh, thank you. So Dan, Jeff and I were just talking, going through 8.0 issues and realizing that I think what's going to happen is that we're going to do 8.0 betas throughout the holidays and then we'll expect a release candidate in January for 8.0. And then we'll get 8.0 stable in January. I just wanted to give a heads up for folks on that. Any other thoughts and opinions about 8.0? I just wanted to mention that then. The next topic I have is thinking about the new year. We tend to start the new year with posts about what we think Circuit Python should be or do for the coming year. We've called it Circuit Python 2022. And next year is 2023. Usually I kick it off with a blog post on January 1. I just wanted to have an in the weeds topic for thoughts or things that we should do differently this year than we've done in previous years. Otherwise, what it was last year is like it's a kickoff post and we get an email set up an email alias and when people blog post about what they want we'll then kind of like post them once a day or once a week and we'll link to them and have a running list of all the posts that people have done. And then at the end of it we'll have like the final list of folks that have done Circuit Python. 2023 posts at the end of that. So that's typically what we do. Are there any thoughts or things that you'd like to see changed for going into this next year? I mean, I think it's worked pretty well. So I'm not really concerned about applying changes. Like what I would say is if anybody comes up with ideas between now and January 1 please let us know if there's some way you think it could go smoother, that sort of thing. But otherwise I think it works. All right. That works for me. That's how we've done it before.  All right. So I'm going to go ahead and wrap up. This has been the Circuit Python weekly meeting for December 5th, 2022. Let me get to my thing. 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 adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruit.daily.com to subscribe. The next meeting will be held next Monday as usual I believe at 2 p.m. Eastern, 11 a.m. Pacific. This meeting is held on the Adafruit Discord which you can join anytime by going to adafru.it slash discord. To be notified about the meeting or any changes to the time or day you can ask to be added to the Circuit Python Easter's roll. We hope to see you all next week. Thanks everybody.