As you might know, I very recently actually managed to get floating panels landed on KD Plasma, so they will be in Plasma 5.25. At the same time, and seriously, at a rough the same time, I actually managed to get landed also the panel refactoring that I did, where I basically changed all of the code of the Plasma panels to make it more efficient and easier to actually understand and change later on. But doing these two things at the same time actually created so many bug reports about the Plasma panel and just during the review phase of Plasma 5.25. It will be released if you don't know that in a couple of weeks and that means that within a couple of weeks it should be ready and without bugs and there are a lot that were actually brought up by reviewers. So let me actually talk about that a bit. So this is my floating panel and there are about the floating panel. There are actually two bugs that I already knew about when I actually clicked on merge floating panels. The first one is that in Wayland, we are not on Wayland, so here it looks right, but on Wayland you still see a floating shadow into nothing that looks off and I would really like to get rid of it. However, I'm not sure how yet. I need to discuss that with K-Win developers. So that's one bug that I already know about and currently I cannot do that much about it. I need to actually take the time to discuss with K-Win developers why the function that in theory should hide the shadows isn't. The second bug that I already knew about when I merged the floating panels is that on Wayland, use X if you want a more stable session about floating panels apparently, but on Wayland if you're using floating panels and at the same time you're using scaling you will see that the background underneath the panel, so all underneath here and on the right is actually white for some reason and I actually know the reason very well. So when you draw a panel there is something that gets drawn underneath the panel which is called the contrast effect. This is like the fifth time I'm explaining the contrast effect. The contrast effect is basically a white rectangle with rounded corners that makes sure that A you can always see what's on the panel even on very dark wallpapers. It is a white rectangle so it makes sure that contrast is always there and of course it's whiter on dark backgrounds and it also takes color and makes them very saturated which means that if you got like a redish wallpaper the contrast effect will make that super red and the transparent floating panel with blur on top of it will make sure that you do actually see that red in the panel as a result of the blur which looks pretty. So it's an important part of the design. Now if you want to get rid of the bug you're just going to settings and disable contrast effect. I generally advise against it because it's part of the design of the plasma panels but if it's a bug then you can work around it by actually disabling contrast effect all together. Why it's happening? Okay so in order to know where this contrast effect should be applied the SVG of the panel has actually an element called an SVG element called the mask and the mask specifies the position and size basically and so when the SVG is loaded and positioned in the screen you also get a mask that is in the same position and the same size. What happens during scaling is that the mask gets actually scaled to be bigger than it should because of scaling but it shouldn't actually get scaled. I'm not sure why but it shouldn't and by scaling it it actually becomes bigger than it should. Imagine it as if we were applying scaling two times. So it is one and a half times bigger and then another wine and a half times bigger and of course it becomes bigger compared to the panel and the wet rectangle is visible underneath and to the right of the panel. That's what's happening. These were the two bugs related to the floating panels both of them both of them are still there and both of them require some help from the k-wind team because they're very k-wind related stuff. With these two out of the way there are also the bugs that pop up about the panel itself the refactoring.  Panel refactoring layout manager here. So we've got this thingy here look at here. I wrote if the applet plugin name is plasma icon and middle equals currently out chilled at. Okay what does this do? So first of all it checks the name of the applet and it checks that it's a plasma icon. Plasma icons are the ones that you can actually add by right clicking an app and clicking on add to panel as we get this thingy here and then you can actually get rid of it then. So it checks for those kind of applets and then it calculates the applet in the middle and it assigns it to the variable middle which will be later on used. So that's easy. I thought this was pretty straightforward. It's not why because before my fix I did not have this line and it still looks correct but middle now is not a declared variable which means that when I attempt to put a value inside of it I get an error because in QML I cannot give a value to anything that was not declared first. So I just had to literally add middle and the bug was gone. What was the bug? Well whenever there was an icon on the panel the whole panel would just stop working entirely. You wouldn't just see it and that's because after inserting the second element well there was this bug and an exception is raised here and everything that's next to this applet wouldn't even get processed because an exception stops the for loop it's in. So that was a bug. Also in theory these applets should be added to the middle which is why I'm checking for the middle element. However what happens which I also fixed in the same merge request is that for some reason it was added as the first element instead of the middle. Now within the middle I meant to the left of the middle element which is the task manager so it's here but it was added to the left of even the application launcher which was wrong. So what was happening? Well simply enough I had swapped the order of the things so this was up here and pretend that I didn't mess up the syntax but what happens here is that if x and y are positive coordinates then you insert the applet there otherwise I'll see if then you insert it at the middle. Issue the coordinates of the plasma icon item were zero zero which meant that they were actually added at zero zero which is top left so that was wrong and it was just a matter of actually changing the order of the elements and that was as easy as that. Some things weren't as easy and luckily even though some bug reports even though I've got exams honestly and I'm also working on the promotion of plasma5.25 so I don't have that much time to actually go around and fix bugs. I received help. I received help in actually finding those bugs and coming up with solutions by like Nate Fushan I think it's pronounced if it's not pronounced like that sorry about that. There was also this issue that when the panel is not floating yeah not floating but adaptive and then you maximize a window you can see that it becomes opaque and all of the applets also become opaque whereas if it's not maximized it's actually transparent you can see that much but it is and the applets are also transparent and there was this bug that Nate brought up to me because I didn't even notice the bug report which was that the opposite was happening and that was weird so when the panel was transparent the applets were opaque when the panel was opaque the applets were transparent and thankfully I managed to fix that also within 10 minutes this one is in the other session this one okay it is it was I'm actually missing right here so what's the issue well whatever I was doing is uh in here I'm checking whether the panel should be transparent based on various things like is it floating is the screen covered did uh is the setting set to adaptive or is it opaque all of these things and you can see that I'm setting this variable to be one if she if it should be opaque and zero if it shouldn't and what I was doing then in this if this is the if that actually tells applets whether they should be transparent or not and what I was doing is I was doing big um sorry panel opacity equals one okay so if panel opacity is one then also the applets should be opaque if it's zero then they shouldn't straightforward right well it's wrong why because yes I am setting this as an example I am setting this to one just before actually checking for this value so you would say that if I set it here to one then it becomes one it doesn't because this manual opacity is a property that has uh that have a behavior on this which is a number animation which means that it actually animates from one value to another which means that if I take this variable and it's zero and I set it one it actually takes uh around the second for it to actually get one because there's the whole animation from zero to one which means that in here if I set it to one and then immediately check for the value well I didn't have enough time yet to actually change the value from zero to one the animation wasn't complete so this still read at zero even though I had just set it at one and this means that it was actually taking the starting value and not the end value of the animation how did I fix this well I just created a new property called opaque applets which is just false or true and I set it to true when the applets should be opaque and this one is not animated which means that if I set it to true here it still stays true here it doesn't do any weird animation things now it's fixed this set there are still bugs about the panel hopefully they will be fixed by 5.25 release obviously and I don't know how much time I personally will be able to go there and fix bugs to merge requests because I've got so many things to do honestly I've got exams but I'm also going from Friday to Sunday to Florence to a Python conference I held a talk at a Python conference but I also organized Easter egg there and more because I also need to prepare everything for the Plasma 5.5 release from a promotion point of view so so many things and train my best luckily I've got people to help me so hopefully this will go for the best I just showcased the bugs that were reported to me that I actually managed to fix myself to talk about the things that I personally did to make sure that it actually worked in the it actually works in the final release so thanks for following along


Welcome. I welcome you all to this lecture in the course, Samasa in Panimian Grammar 2. As is our practice, we begin our lecture with the recitation of the Mangala Charana. In this course, we are studying the three important types of samasas in Sanskrit, namely, Avyaibhava, Bahubrihi and Dvandva. Currently, we are focused on the study of the Bahubrihi Samasa. This is a very important type of samasa in Sanskrit. The structure of the Bahubrihi Samasa can be briefly stated with the help of this following equation, where we have X plus Y generating X, Y. X and Y, both of them are independent entities in terms of the word form, as well as the meaning, as well as the accent. The plus sign marked in between shows that both X and Y are semantically interrelated. The speaker of Sanskrit decides to merge them together and generate an output in the form of XY, which is one unit. This one unit has three features, Aikarthya or Aikarthata, Aikapadya or Aikapadata and Aikasvaryya or Aikasvarata. As far as the Bahubrihi Samasa is concerned, none of the two, neither X nor Y, is the head of this particular samasa. Therefore, none of them is marked with the bold characters. In the Avyaibhava Samasa, the first member of the samasa is the head. So, it is marked in bold characters, that is X is marked in bold characters. In the Purusha Samasa, the second member or the final member of the samasa acts as the head, so Y is marked in bold characters. Nothing of the sort happens in the Bahubrihi Samasa because the head of this samasa lies outside of the samasa itself, something like Z, which is not part of XY. That is very significant as far as the Bahubrihi Samasa is concerned. In the Ashtadhyayi, the Bahubrihi Samasa is stated in different places. Thus, Samasa Vidhayaka Sutras, that is the compound prescribing sutras, that is the sutras which lay down the conditions for the samasa to take place from 2223 onwards up to 2228. 2223 is Shesho Bahubrihi and 2228 is Tenasaheti Tulya Yogi. Incidentally, 2229 is Charathed Vandvaha. Then, the Samasanta Prateja Vidhayaka Sutras are stated from 54113 onwards up to 54160. And then the Swara Vidhayaka Sutras are stated in 6.2. The very first sutra, Bahubriha Uprakrutya Purva Padam 6.2.1 is a very good example. Then we have 6.2.106 onwards up to 6.2.120 is another section dealing with the Swara Vidhayaka Sutras. And similarly, from 6.2.162 onwards up to 6.277, the Swara Vidhayaka Sutras related to the Bahubrihi Samasa are stated. Amongst these, we have already studied the Samasa Vidhayaka Sutras. And then we have also started studying the Samasanta Prateja Vidhayaka Sutras. And we came up to 154 in the previous lecture. Now in this lecture, we shall study the remaining sutras as far as the Samasanta Prateyas are concerned. And then as we noted that from 54128, we came straight to 54151, primarily because these sutras that come in between, they are dealing with the Samasanta Adeshas. And we shall be studying them too in the next lecture. Right now, let us continue studying the Samasanta Prateyas which are added at the end of the Bahubrihi Samasa. So far, we have studied that the suffix cup is to be added at the end of the Bahubrihi Samasa, stated by the Sutra, Uraprabhratibhyaha Kapu. Then we studied some more conditions, Nathritascha and Sheshad Vibhasa, etc. Now from this sutra onwards, we will see some sutras which negate addition of such a Samasanta suffix as far as the Bahubrihi Samasa is concerned. Let us study these sutras one by one. The first sutra is Na Saudnyayam, meaning in the Bahubrihi Samasa which denotes a term, the Samasanta Prateya Kap that is k is not added. I repeat, in the Bahubrihi Samasa which denotes a term, the Samasanta Prateya Kap is not added. This is the negation of the previous statement, 5, 4, 154 which we have studied in the previous lecture. So we have the examples, Vishvadevaha and Vishvayashaha. Let us study them one by one. So one who has all gods, that is the meaning to be conveyed and the laukika vigraha is Vishvadevayashyasaha. This Samasa is affected by the sutra, anekam anepadarthe. And then the laukika vigraha would be Vishva plus jas, plus Deva plus jas. Then the Pratipadiya Saudnyayam takes place. The Samasa Saudnyayam has already taken place but now here we don't apply the Samasanta Prateya Kap. Therefore we keep it as it is and then the Pratipadiya Saudnyayam takes place. Then Supodhatu Pratipadikayoho applies and so we have Vishva plus zero plus Deva plus zero. When we join both of them together we get the form Vishvadeva. Similarly one who has all success, when this meaning is to be conveyed, we have the laukika vigraha, Vishvam yashaha yasyasaha. So the laukika vigraha over here would be Vishva plus zero plus yashas plus zero. And then the Kap suffix is not added here. The Samasa Saudnyayam has taken place and then the Pratipadiya Saudnyayam takes place and then Supodhatu Pratipadikayoho applies so we have Vishva plus zero plus yashas plus zero. And then we join them together we get the form Vishva yashas. Remember there is no Samasanta Pratipadiya added because of 54-155 which says Saudnyayam. Because these are the Saudnyas, these are the technical terms and therefore the Samasanta Pratipadiya is not added over here in this Bahuvrihi Samasa. Let us move to the next sutra, Iyasascha 5.4.156. This sutra means that in the Bahuvrihi Samasa which ends in the suffix Iyas, the Samasanta Pratipadiya cup is not added. I repeat, in the Bahuvrihi Samasa which ends in the suffix Iyas, the Samasanta Pratipadiya cup is not added. Once again this is also the negation of 5.4.154. The word Iyas mentioned in the sutra represents the suffix Iyas or Iyasun stated by the sutra, 5.3.57 and this suffix Iyas denotes the comparative degree. So here is an example, one who has many distinguished females, if this meaning is to be conveyed, so we have the laukika vigraha Bahuvriha Shreyasyaha Yasyasaha, Bahuvriha Shreyasyaha Yasyasaha and so we have the laukika vigraha Bahuvri plus Yasy plus Shreyasi plus Chasy. Now here we may have added the Samasanta Pratipadiya cup but because of the present sutra Iyasascha, the Samasanta Pratipadiya is not added and so we have Bahuvri plus Chasy, plus Shreyasi plus Chasy, then Samasa Saudhna takes place, then Pratipadiya Saudhna takes place, then Supodhatu Pratipadiya Yahu applies, so we have Bahuvri plus 0, plus Shreyasi plus 0 and then the Pomadbhava application takes place which transforms Bahuvri into Bahu. So we have Bahu plus 0 plus Shreyasi plus 0 and then when we join them together, we get the finally derived Bahuvriha Samasa output Bahu Shreyasi, this is in masculine. Now Bahu Shreyasi plus Su and then we delete this Supratyaya, so we get the form Bahu Shreyasi, the Prathama Ekavachana of the masculine form of Bahu Shreyasi ending in long E. This is discussed in detail in the derivations of the nominal declensions studied in the Panayan grammar which is also known as the section on Shedlingi. The next question is because this is a Bahuvriha Samasa where both the constituents are upasarjana, why is the final long E not being shortened on account of the sutra? And the answer is provided in the form of a statement which says shortening of the final bauvel in the Uttarapada is not done, it is prohibited. Therefore it is not shortened, so we get the form Bahu Shreyasi, the masculine form of the word. Next we go to the next sutra, 5.4.157, Vandite Bratuhu. The meaning is in the Bahuvriha Samasa which ends in the word Brathru, when it denotes the sense of worship, the Samasanta Pratyakap is not added. I repeat, in the Bahuvriha Samasa which ends in the word Brathru, when it denotes the sense of worship, the Samasanta Pratyakap is not added. This is the negation of Nadritascha 5.4.153. So what is Vandita? The commentators say Vandita, Sthutah, Pujitah, Ittichchate. Vandita is one who is praised, one who is worshipped, is Vandita. Let us look at the example. When the meaning to be conveyed is Shobhanah Brata Yesyasaha, one whose brother is worshipped. The Laukika Vigraha is Shobhanah Brata Yesyasaha. And then the Laukika Vigraha is Su plus Su, and Bra plus Brathru plus Su. Now here, the Samasa-Saudhna takes place because of anekam anyapadarthe. And then, by the sutra-nadritascha, we may add the suffix-cup over here because the word Brathru ends in ru, but because of the present sutra, Vandite Brathru, the Samasanta Pratyaya is not added. Because Su, as a Pratipadika, here means Shobhanah, which is talking good about the brother, worshipped brother. So, this is Pujita, Vandita, and therefore we have Su plus Su, plus Brathru plus Su, Samasa-Saudhna takes place. So, Pratipadika Yoho applies. So, we have Su plus Zero, plus Brathru plus Zero. And so, we get the finally derived compound output in the form of Su Brathru. Now, we use it in the sentence and we add the suffix Su after it. So, we have Su Brathru plus Su and then we do the further processing and we get the form Su Bratha as the Prathama Ekabachana of Su Brathru. It's a long process when we have Su Brathru plus Su and then there is Anang that gets substituted in place of ru. So, we have Subha, Su Brathan plus Su and then Su. Because of Su, the penultimate vowel gets lengthened. So, Brathan plus Su, then Su gets diluted and we have only Subha, Brathan and then Nag gets diluted and we get the form Subha, Bratha. In contrast, when we say on whose brother is a fool, Murkhah, Bratha, yes, yes, aha. So, here we don't do the negation of the Samasanta Pratyaya. Rather, we do the Samasanta Pratyaya. So, we have Murkhah, Brathru and Ke and when we join them together, we get the Samasanta output as Murkhah, Brathru, Ke. Similarly, one whose brother is Viket. If this is the meaning to be conveyed, then we get the form Dushta, Brathru, Ke, Dushta, Bratha, yes, yes, aha. Here we do add the Samasanta Pratyaya, Ke because the word Brathru here does not stand for Vandita or Pujita. Then we go to the next sutra, 5.4.158, which is Ruttashchandasi. The sutra means, in the Bahubrihi Samasa, which ends in the Vavelru, the Samasanta Pratyaya Cup is not added in the Veda. I repeat, in the Bahubrihi Samasa, which ends in the Vavelru, the Samasanta Pratyaya Cup is not added in the Veda. This is the negation of Ndhrtashcha, 5.4.153. And this is the rule of the Vedic language, the language available in the Vedas. Here is an example. One whose mother is killed, if this is the meaning to be conveyed, then we have the Laukika Vigraha, Hatha Mata, yes, yes, aha. And the Laukika Vigraha would be Hatha plus Su, plus Matru plus Su. Now, because the word Matru ends in Ruh, Ndhrtashcha might apply, and we can add the suffix K perhaps, but because of this present sutra, Ruttashchandasi, we do not add any suffix Cup over here.   Then we add the suffix Su to it, Hatha Matru plus Su, and then finally we get the form Hatha Mata. From Hatha Matru to Hatha Mata, there is a process that is described in the Ajanta Pulling section of the Shedlingi Prakaranam, Hatha Matru plus Su, and we get the finally derived form Hatha Mata, one whose mother is killed. And then, when the meaning is one whose father is killed, we get the forms Hatha Pitru as the Samasa, and Hatha Pitta as the Prathama Ekavachana. Similarly, one whose sister is killed, and we get Hatha Svasru as the Samasa output, and Hatha Svasa as the Prathama Ekavachana. Similarly, one which has a good priest, and then the word that we have here is Suhotru, which is the Samasa, and Sohotta is the Prathama Ekavachana of Sohotru. Let us now proceed to the next Suhotra, Nadi Tantryoho Swange. The meaning of the Suhotra is the following. In the Bahuvrihi Samasa, which ends in the words Nadi and Tantri, in the sense of part of the body, the Samasanta Pratyayaka is not added. I repeat, in the Bahuvrihi Samasa, which ends in the words Nadi and Tantri, in the sense of part of the body, the Samasanta Pratyayaka is not added. This is the negation of 5.4.153 Nath Dhritastra to be specific, the word Nadi, which means any word ending in long E and U denoting the Sthri Pratyayaka. Nadi and Tantri are the two words ending in long E and also denoting the feminine sense, and hence they become Nadi, and therefore Nath Dhritastra might apply here, but because of this Suhotra now, 5.4.159, such an addition is negated. The word Nadi stands for a tube and Tantri stands for string or vane. Here is an example. The meaning to be conveyed is the body which has many tubes, Bahuvriha, Nath Dhritastra. This is the Laukika Vigraha. So, we have Bahuvi plus jas, plus Nadi plus jas as the Laukika Vigraha. And then we get the Samasa Saudnya, and then there is a scope here for Nath Dhritastra to add the Samasanta Pratyayaka in this case, but because of the present Suhotra, Nadi, Tantri and Swange, the Samasanta Pratyayaka is not added. So, we have Bahuvi plus jas, plus Nadi plus jas as the Laukika Vigraha, and cup is not added. And so now, we get the Samasa Saudnya, we get the Pratyayaka Saudnya and apply Supadhatu Pratyayaka Yoho. And so, we delete both the soaps.  And then, because the word Nadi is in the Bahuvrihae Samasa, so it is Upasarjana. So, we apply the Sootra Gosthriya Rupa Sarjanasya and shorten this vowel. So, we get the finally derived Bahuvrihae Samasa output in the form of Bahu Nadi. Then we decide to use it in the sentence and add the suffix Su after it. So, we have Bahu Nadi plus Su and that is Bahu Nadihi. And what it qualifies is Kaya Ha, the body, Bahu Nadihi Kaya Ha, the body which has many tubes. In contrast with this, if we have the meaning to be conveyed namely a pillar which has many tubes. Remember, this is not body, not swangha. It is a pillar that we are talking about. Then we would have added the Samasanta Pratyayaka and then we get the form Bahu Nadihi Kaya. So, Bahu Nadihi Kaya Sthambhaha, a pillar which has many tubes attached to it. Similarly, when the meaning to be conveyed is the neck which has many veins. Bahu Vihha, Tantriha, Yasya, Ha, Sa. This is the Laukika Vigraha. So, we have the Laukika Vigraha namely Bahu Vee plus Jas, plus Tantri plus Jas. And then the Samasa Sautnaya takes place. Now here we don't add the Samasanta Pratyayaka at this stage because it is negated by the present Sutra. And so then Pratyavadi Kaya Sautnaya applies. Supodhatu Pratyavadi Kaya applies and then we delete both the subs. So, we have Bahu Vee plus 0 plus Tantri plus 0. And then the Pummat Bhava takes place and then we have Bahu plus 0 plus Tantri plus 0. And then when we join them together, we get the finally derived Bahu Vihha Samasa output namely Bahu Tantri. And we add the Samasanta Pratyayaka and then we add the Supratayaka, Bahu Tantri plus Su. And we get the form Bahu Tantri. In contrast, when the intended meaning is not a swangha but it is a lute then and then the meaning is a lute which has many strings. The Ka Pratyayaka would be added and we would get the form Bahu Tantri Ka Vee Na, Bahu Tantri Ka Vee Na. The important point to be remembered over here is that there is no lengthening of Tantri as it does not end in the suffix denoting femininity. Just as you have Gauri where Gauri plus E is the derivation history where E stands for femininity and Gauri, Gauri is the Pratyayaka. Something similar does not happen here in Tantri. Tantri itself is the Pratyayaka ending in long E because there is no Pratyayaka. The question of shortening it does not arise. Let us go to the next and final sutra in this particular section and also the Pada which is 5.4.160 Nishpravanishcha. The meaning of the sutra is in the Bahu Vrihi Samasa Nishpravani the Samasanta Pratyayaka is not added. I repeat in the Bahu Vrihi Samasa Nishpravani the Samasanta Pratyayaka is not added. What is Pravani? Pravani is Viva's Shakle which means Pravayate Asyam in which weaving is made or Pravayantitaya by which weaving is done. So now the meaning to be conveyed over here is a cloth or blanket which has gone from the Viva's Shakle which has gone ahead. So we have Nirgata Pravani Yasyasaha. This is the Laukika Vigraha and the Laukika Vigraha is Nir plus Su plus Pravani plus Su. Then we have the Samasa Saudhna taking place and then Nir plus zero plus Pravani plus zero on account of Supodhatup Pratyavadika Yoho. And so we have Nir Pravani and then the shortening of Pravani happens Nir Pravani and finally this R is changed to Visarkha and then to Shra and we get the form Nishpravani. Then we add the suffix Su to it and we get the form Nishpravani. Nishpravani is the finally derived Bahu Vrihi Samasa output. So Nishpravani means Pataha. Nishpravani means Pataha, piece of cloth or Nishpravani means Kambalaha. What it means is apanita shalakaha samaptavanah pratyagrahnavakaha. This is what is Kambala. Apanita shalakaha samaptavanah pratyagrahnavakaha. To summarize, the Samasanta Pratyaya is a peculiar operation stated to the Bahu Vrihi Samasa. It is added to specific words with specific formal conditions as well as semantic conditions. It is also stated optionally after some words and always is after some other words. The Samasanta Pratyaya added to the Bahu Vrihi Samasa has several functions. It changes the final form of the compound from vowel ending to consonant ending etc. It also acts as a condition for a particular accent and it also acts as a condition for addition of a particular feminine suffix. Thus we come to the close of the Samasanta Pratyayas added after the Bahu Vrihi Samasa. Now next we go to the Samasanta Adeshas which are stated in this same section in the next lecture. These are the references. Thank you very much.


Hello everyone! This is the CircuitPython Weekly for February 14th, 2022. This is the time of the week where we get together to talk all things CircuitPython. I'm Scott, and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to the URL 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 2pm Eastern, 11am Pacific, except when it coincides with the US holiday. In the Note Stock, there's a link to a calendar 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 these notifications, ask us to add you to the CircuitPythonDista's Discord role. I should note that next week is on Tuesday. Next week is 24 hours later than normal because it is President's Day here in the US. So just double checking that that's true. So next week, the meeting will be on the 22nd, not on the 21st. So I will try to make that clear and all the stuff that we're doing as well. But just adds up the meetings a day, 24 hours later than normal next week. Okay, there is a Note Stock to accompany the meeting and the recording. The Notes document contains timestamps to go along with the video, so it can use the doc to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. After each meeting, we post a link for the next meeting's notes in the CircuitPythonDev channel on the Adafruit Discord. Check the pinned messages to find the latest Note Stock so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. The first is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of our Python on microcontrollers newsletter. The second part is the state of CircuitPython libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to. It takes a couple of minutes. So take a couple of minutes and 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 weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time is too long for status updates. And that covers how the meeting will go. And I'll move on to the first section and take a time code and get this show on the road. So first up, this is community news. This is a chance for us to talk about all things CircuitPython. Oh, CircuitPython, MicroPython, and Python on hardware. Thank you to Ann for putting these together and whoever accidentally deleted stuff and undid it. Thank you for that as well. Okay. So the first thing we have here is 500 Adafruit projects have been certified products have been certified by the open source at certified as open source by the open source hardware association, Oshawa. Adafruit is an open source hardware and software company. To that end, Adafruit has been working to submit many of their boards for certification by the open source hardware association. According to Oshawa, the certification program exists to make it easy for creators and users to identify hardware that follows the community definition of open source hardware maintained by Oshawa. Hardware projects that display the certification logo are licensed and documented in a way that makes it easy for users to use and build upon them. So on February 7th, Adafruit hit the milestone of 500 certified projects and was the first to reach this number. By registering their boards with Oshawa, Adafruit aims to ensure that users ensure users that products they sell are open source and easy to learn about. Adafruit extends a special thank you to everyone who made this possible but especially the wonderful folks over at Oshawa who set this all up and were incredibly helpful throughout this process. Additionally, they thank the community that keeps this all going and encourages them to publish, share, and more. And thanks to FOMI-I for putting a link in. Next up, CircuitPython. Let me take a timecode. This is my first set of timecodes I've taken where I don't have the number keys labels. I'm working on that. Okay, so CircuitPython 7.2.0, Alpha2 was released. It was released this past week. It's the second published Alpha release for 7.2. It is relatively stable but there will be further additions and fixes before final release. Notable additions to 7.2 since 7.1 are continued work on the Raspberry Pi Broadcom board support, support for the ESP32-S3 and C3 including some Bailey, RP2040-PIO optional side set support, the addition of the Stema I2C board singleton constructor which is available on every board that has Stema connectors. Bineski CRC32 is added and VectorIO has a dot contains now as well. So those are some highlights. Next we have the Raspberry Pi Beta Test Network Install of Raspberry Pi OS. Until recently you've always needed to use another computer to run Raspberry Pi Imager or to run something similar to let you flash your operating system onto an SD card when you get a new Raspberry Pi. But how do you get the operating system onto an SD card if you don't have another computer in the first place? There's a new beta version of the Raspberry Pi bootloader that implements network installation and we'd like your help to test it. The new network install feature can be used to start the Raspberry Pi Imager application directly on the Raspberry Pi 4 or a Raspberry Pi 400 by downloading it from the Internet using an Ethernet cable. The Raspberry Pi Imager application which runs in memory on the Raspberry Pi can then be used to flash the operating system onto a blank SD card or USB disk. That's very interesting. Next up, the Raspberry Pi OS 32 versus 64-bit benchmarks have been published. Raspberry Pi 32-bit benchmarks have been compiled. Most operations benefit from the 64-bit software use. The best speedup is performing the Sysbench CPU test a 1,380% speedup. Overall, using the 64-bit operating system gave a 48% faster response overall. And next, the PiCast celebrates 10 years of Raspberry Pi. New episodes with Lady Aida, Ebon Upton, and more. The PiCast celebrates 10 years of Raspberry Pi. LaMours will be livecast tomorrow, February 15th at 2.30pm US Eastern. That's 7.30pm UTC. So heads up, that's coming tomorrow. It's marked in here as today because this will go out tomorrow morning in the newsletter, which I'll talk about in just a second. But we have one more thing to talk about before we get to wrapping up this section. The sensor watch on CrowdSupply is a circuit Python compatible. The sensor watch is a microchip SAM L22-based board driving a watch LCD.  It has connections for sensors to make it versatile. And a designed goal is ultra-long battery life without time between charges. There's a thread on Twitter where developer Joey Castillo discusses getting circuit Python working. And I gave a tip to Joey on that and he made progress as a result too, so that's great. Okay, so that is the Community News. The Community News comes from the Circuit Python newsletter, which is a Circuit Python community-run newsletter emailed every Tuesday morning. The complete archives are available at AdafruitDaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware-related news around the web, including Circuit Python, Python, and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub at GitHub.com slash Adafruit slash CircuitPython dash weekly dash newsletter, and submit a poll request so you can just click the little pencil icon in the top right and edit it there. With those changes, you may also just tag a tweet with hashtag CircuitPython on Twitter or email cpnews at Adafruit.com and we'll happily add the latest news for you as well. Okay, let's move on to the next section, which is the state of Circuit Python libraries in Blinka. This is a chance for us to take a look kind of more objectively at how things are going within the broader CircuitPython community. So I will start overall, and then go to, I will do the core, and then we'll kick it over to Katni and Melissa for the libraries in Blinka updates in just a bit. So first off, overall, we had 58 poll requests merged from 28 different authors, so thank you to all of our authors. Some new names that I haven't seen that maybe were covered before, but this is my perspective, is some new folks, new authors are Angerer, Joe Deller FC, Jonas Schatz, Tawes, VP Tech Ops, and Lashley D-A-V and Stefan Hitterholze. Those are all new authors, so that's out of the 28, so thank you everybody there for authoring PRs. And then on the reviewer side, we had 12 total reviewers for those 58 poll requests, and I just wanted to give a bit of a shout out to Tech Trick and Unexpected Maker, who I don't often see on this review list, so thank you to all of our reviewers and welcome to those newer folks. Next up, we had issues-wise, we had 38 closed issues by 18 people, and 17 opened by 14 people, so we're net down 21, which is awesome. And we have, you know, more than a dozen people interacting with issues on either side of this, so opening or closing them, so that's awesome to see people involved. Okay, next up for the core specific numbers, we had 22 poll requests merged from 16 different authors. I won't highlight some new folks here, but I'll say thank you to all of those authors, really appreciate it. We had five reviewers, thank you as always to our reviewers. We're always looking for more reviewers, so if you're interested in making the leap into reviewing, please let us know we'd be happy to help get you there. And we have 12 open poll requests, where three of them are over 100 days old, so we should take a look at those. And then actually the remainder are 31 days older or less, so that's been pretty awesome as well. Issues-wise, for the core, we had 12 closed issues by five people and 11 opened by eight people, so we're net down one, for a total of 503 open issues. This number is growing slowly, it's not the end of the world. The way that we kind of prioritize what the Adafruit Fundative Folks are going to work on sooner rather than later is through the milestone system. So we have kind of 7.2 milestone, which is the thing that we're wanting to do soonest, and then 7.xx are things that we should probably do sooner rather than later. And then we have a long-term bucket that is stuff that we're going to do in the long-term. So we have nine open issues for 7 to 23 for 7x, and then 440 for long-term. There's a few other buckets there, that's why they don't add up, but that's generally the idea. I think a lot of us are feeling that we probably want to get 7.2 stable release sooner rather than later, so I would not be surprised at those numbers. We took a look at these issues and kind of shuffled them around a bit, so don't be surprised that that happens as well. Okay, and with that, let's get the library update from Catney. Thanks, Scott. So this section applies to all of the Adafruit Circuit Python libraries, which is everything that starts with the Adafruit Circuit Python underscore as well as a few extras. Over the course of the last week, we had 31 pull requests merged from 12 different authors, and I want to point out that most of these authors are the new folks that Scott read off earlier, which is really amazing to see, and 10 different reviewers. And once again, welcome to Tech Trick for joining the review team. That leaves us with 17 open pull requests, which is just bonkers low. I'm very excited. We had 22 issues closed by 12 people and five opened by five people, leaving us with 625 open issues across all of those repositories. 219 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, consider going to circuitpython.org slash contributing. For all of this information and more, if you're interested in reviewing, check out the open pull requests. Leave a comment that you tested it if you have the hardware. If not, let us know that you took a look at the code that it looks good to you or it doesn't. It's very helpful, and once you're comfortable with that, we can look at upgrading you to joining the review team. If you're interested in contributing code or documentation, check out the issues list. If you're new to everything, there are a lot of ways to start, and we've got plenty of those available. We have a guide on contributing to Circuit Python using Git and GitHub, and we're always available on Discord to help out. We would like you to be able to contribute in a way that works for you, so we are always available to help you along that process if that's something you're interested in doing. In terms of library updates in the last seven days, there's one new library, the Circuit Python ADXL37X library, and a number of updated libraries which I will not read off, but they are in the notes if you are interested. And that's pretty much where we are with the libraries. Awesome. Thank you, Katnie. Next up, let's get an update on Blinka from MakerMalisa. Hello. Thank you, Scott. For Blinka, which is our Circuit Python compatibility layer for MicroPython and Raspberry Pi and other single-bolt computers, this week we had five pull requests merged by four authors and four reviewers. There are currently six open pull requests amongst all the different repositories, and there were four closed issues by three people, one open by one person, leaving a net of 70 open issues. And there were 16,676 PiWheels downloads in the last month. We are currently supporting 87 boards. And that's where we're at. Awesome. Thank you, MakerMalisa. All right. And that's it for the Stated Circuit Python Libraries in Blinka. Next up, we have the first of two round robins, which is Hug Reports. Hug Reports is a chance for us to say thank you to folks for the work that they've been doing within the community. I will start, and then we'll go through the list as is in the note stock. So it's not the end of the world if it's not out of alphabetical order like we used to do. We'll just follow the note stock and see where that takes us. So if you do want to speak up, make sure you're listed there so that I go to you. Otherwise I may miss you. So next up, I will start after I take another tanko. So first, I hug to for doing the unsung hero being the unsung hero of releasing libraries. She keeps library releases going and it's awesome. So thank you for doing that Eva. Next up, I thank you to Anecdata for continuing to improve the ESP Wi-Fi APIs and experience. And lastly, a hug report to Tammy for the type PRs and Tech Trick for doing the reviews for those PRs. With that, I will go to the next person and read Anecdata who says a hug report to Michael and Dan H for helping getting my circuit python build environment working again. And next up is Dan. Thank you. Thanks to Tech Trick for continuing to do a lot of type annotation stuff and starting to review library PRs. That's terrific and kudos to Tammy Makes Things and starting to work on a whole lot more PRs whether submitting or reviewing as well. Thank you. Awesome. Thank you Dan. Next up is FOMIGuy. Alright, thanks Scott. Hug reports this week. First one for Nirdoc who converted a old pure python library called PyFleet. It hadn't been updated in many years and it was using python 2 syntax. Nirdoc updated it for us so that we can use it on python excuse me, updated it to use python 3 syntax so that we can then use it on circuit python. Anecdata also helped look into the API that is returning the response that needs this zipping functionality that we kind of got led to. Thank you echoing what a couple of folks have said. Thank you to Tammy Makes Things for getting involved and doing typing PRs and other things around the libraries. Also echoing other folks, thank you to everybody and congratulations and such for joining the review team and continuing to help out in lots of different places across all the libraries and also for prompt fix inside of Blinka this week. So thank you to Tetric to Mark Gambler for looking into a older PR on the core that was dealing with that GZIP functionality that kind of goes along with my first two hugs and then lastly a group hug to everybody. Thank you to everyone who contributes to the amazing community and especially everyone that St. Good wishes my way last week when I ran the meeting for the first time. So thank you to everybody. Awesome, thank you FilmeGuy. Next up is Jepbler. Hello, and yeah I just need to hug FilmeGuy once more for doing more and more. Thanks to Dan for doing that next pre-release of 7.2 to Mark Gambler for reviving interest in the native modules and fixing some build problems with them. And I'm sorry but I couldn't resist tinkering further with it and submitting a separate PR because I never can figure out how on GitHub to work in somebody else's PR branch. Anyway, to Katni for continually wanting to grow your coding abilities and I'm looking forward to a little bit of pair programming with you soon. To Lady Aida, thank you for the reviews and constructive feedback about my work on Adafruit Floppy. To Eva Harada for your keyboard projects it's fun seeing those guides getting close to release I think. And to my friend Steve who is not on the Adafruit Discord for the loan of a classic Commodore SX64 computer for the Floppy project. Awesome, thank you Jepbler. Next up is Jerry. Hi, where'd it go? Come back here. There it is. Yeah, thanks to Katni and Andin for a quick response to a moderation request that I did over the weekend. It was nice to get some quick feedback. And Dan, thanks for the HTTP server demo. It's nice to play with that group hug to everybody else. Awesome, thank you Jerry. Next up is Katni. I got a long list today. That's because there's so many awesome people. Yeah, and my categories apparently. So first up is TechTrick for joining the CircuitPython Librarians review team. A lot of people have covered that but I really appreciate that the reason for that was so that TechTrick could fix all the readme's on the libraries which is also a great thank you. And for fixing the cookie cutter bugs I found when generating a new library there were things that we updated elsewhere that hadn't been updated in cookie cutter. And in addition to fixing all the readme's TechTrick really jumped in and started reviewing a lot of PRs and that's been super helpful. To Tammy makes things for submitting PRs to the libraries for open issues. To Carter for helping me find something incredibly obvious that I couldn't find. To Jeff for offering to help me with some code. I'm looking forward to that. To FoamyGuy for updating a guide for me. To Mark Gambler for writing two new pages and the first one for the new IS-31 code. That's the native slash additions to the library bits that makes things run faster in CircuitPython. And that's really good because I know people are really interested in that sort of thing. To Dan for the latest CircuitPython alpha release. To Paul for the upcoming CircuitPython show podcast. I am recording my episode this week. To everyone who is involved in finding the three layer deep Sphinx bug that was released last week. I think Tectric has all the names coming up. It was like three different libraries that you had to get through before you found the actual issue. And thanks to Tectric for submitting the quick fix and a group hug to everyone. Awesome. Thank you so much, Katani and Kat. Next up is K-Match. Thanks, Scott. So first hug is related to some discord information on the capabilities of the ESP32S3 and Deshapu gave me some interesting reading material on how to drive RGB displays. So that was useful. And second thanks is thanks to Katani. Thanks for always being welcoming and willing to listen. Thanks everybody. Thanks K-Match. Next up is maker Melissa. I wanted to give a hug first to Jepler for keeping on top of the Dublin Linux talk preparations. Hug to any data for testing out the PyPortal earlier today. Hug to Katani for quickly reviewing a PR they've been sitting for a couple of days and hugged everyone who had submitted a PR issue that needed my attention for and for having the patients to wait as they finished up the little FS project and group hug everyone else. Awesome. Thank you, Melissa. Next up I have notes for Mark Gambler. Mark says hug report to Jepler for looking at the native mod work I was experimenting with and hug report to Katani and Anbi for helping the learn system. And next up is Tammy makes things. Thanks. So I have hugs for FOMI guy and Tech Trick and also for Lady Aida. I forgot her on that list for helping me a ton with a bunch of those pull requests related to type annotations. It was very interesting to discover the limits of my understanding of something I thought I understood. Always an opportunity to learn and a group hug to everyone for being amazing. Thank you, Tammy. All right. Last up I've got notes from Tech Trick who says first hug report to FOMI guy Carter Dan H. Narodok and Katani in helping find a bug in Blinka's circuit python typing module quickly. Hug report to Katani and Iharata for helping me roll out the patch to the readmes and trusting me not to squash and rebase everything. Hug report to Gambler for help with explaining the review process. Hug report to Dan H for getting Blinka to work with the CI so we don't have to mock import circuit python typing or other libraries anymore. Hug report to Tammy makes things for the awesome typing PRs and for being patient with me being new to the review process. And lastly a group hug for everyone being so helpful and welcoming. Thank you all. That's it for hug reports. Let's keep on rolling right into status updates which is the sorry, I can't talk and take time because at the same time it just doesn't work. Status updates is also done as around Robin but this time we want to hear a little bit about what you've been working on in the past week and what you plan on working on in the coming week. It's a great way for folks to find ways or things to collaborate on and just give some tips or tricks if somebody's working on something that you've worked on in the past or may have looked at in the past. So this is a great way to see just kind of also the breadth of everything that's going on in circuit python land which is always amazing. So thank you all. I will start and then we'll go down the list of folks in the note stock. So first up last week I was wrapping up the work on the ESP32 S3. I have a PR out for GAT client support. I've got a PR out for the packet buffer test example so that's in the BLE library. And then I also did the updated or created a second broadcast net bridge broadcast net is this like collect sensor data from wirelessly from throughout your house over BLE and the bridge is the thing that listens to those BLE broadcasts and logs those to Adafruit IO. So I have a PR out to the broadcast net repo that does the bridge on a an ESP32 S3 instead of needing a full on Raspberry Pi like it used to be. And then on Friday I started looking into USB host on therapy 2040. I got the example code going. It works with a Microsoft mouse that I've got here. So that's a start and and this week I'm planning on bringing that USB example code into the tiny USB into tiny USB host stack and getting more familiar with both the example code and with tiny USB host stack and trying to get them collaborating and working together as a prerequisite to getting this all into certified on. So that's my week. I should also say that I'm out probably Thursday afternoon and then next week because it's a holiday Monday. I'll be off on Monday as well. All right. Next up is Tammy makes things. All right. Thank you.  There's one that is still in flight. We're working on a question with that one. The others have been merged. I submitted a PR to add a command line option to the PICU command line utility to specify the boundary for serial connections. I started working on a circuit Python class that represents a deck of cards for a project that I'm working on and I'm trying to make it as generic as I can. So it might be able to be added to the community library bundle at some point. I want it to be able to shuffle cards, pick cards, and I want cards to know how to draw themselves on a display IO group. So I'm working on that. I did a bunch of configuration and set up stuff for my first electronics making stream on Twitch, which, oops, type of there, that should be Twitch, which I'm hoping will happen this evening, Arizona time. We'll see how that goes. This week I'm going to continue working on all of those things and I'm hoping my first Twitch stream will be tonight. The next week is in the note stock and I will probably not be here for the next meeting. I'm out of town Thursday, Friday, Monday, Tuesday, and I'll be traveling Monday, so I probably will not be here. Okay. Feel free to drop notes for the meeting next week if you've got them and also when you go live on the stream, feel free to post your link on the live broadcast chat to let people know that you're doing that. Yeah, I think that's the place. Is it better or do we have a separate announcement channel as well? I don't know. I think live broadcast chat is usually what I do. Okay. Works for me. Thanks. Cool. Yeah, the announcement channel is only for admins. The chat will work just fine and can get people following your streams there. Next up is Dan. Okay, thanks. So, at the end of last week, I released 7.2.0 alpha dot 2 because it was kind of overdue for a release there were a bunch of accumulated changes. And as you read at the top, as Scott read at the top, there are a bunch of interesting things in there, probably most notably the board.stemma I2C, which is really handy. I started looking at Adafruit requests to modify it or to add some async possibilities to it or copy the code or structure or whatever, but use it as a starting point and I found some things that I wanted to fix in it partly because there's some stuff in there that simulates doing split and other things in CircuitPython 6. It's not really necessary anymore since we don't have to support CircuitPython 6 with that library anymore. So, I may eventually have a PR for Adafruit requests. I created a new library which is strictly for type annotation called Adafruit CircuitPython typing that's the CircuitPython typing module which right now is inside Blinka and it seems appropriate to me to move that out of Blinka because it's not always associated with Blinka and we can maintain it separately from Blinka. Blinka is not... All these additions of new types and type annotations don't have to go through Blinka. So, eventually I will try to get that working and change the few places where we need to add this as a dependency on a few libraries that do use CircuitPython typing right now. Finally, I fixed a bug, a time jumping bug on SAMD where somebody who checks the time all the time noticed that sometimes time.monototing that a second goes back or forward by three days, which isn't so great and that person hasn't reported back about whether it's been fixed but I hope that it has. Okay, that's it. Awesome, thank you Dan. Yeah, we almost invented time travel. Alright, next up is the Xiaomi guy. Alright, thanks Scott. So, this past week I got about half of the Winamp player that I've been working on for PyPortal. I got about half of the guide done and I did a bunch of commenting and documenting the code so that that's ready to get posted. I just need to wrap up the last couple of pages and I'm hoping to do that this afternoon. I started preliminary work on a project to pull data from this government web traffic API but ran into a hurdle because the server only sends data GZIPT even if you try to ask it for plain text it will respond to you with GZIPT data so it seems that browsers handle this automatically and so I didn't realize this until I got started on the microcontroller but I do have a couple more things to talk about that later in the weeds so I did start looking into the options for that and like I mentioned I'll talk a little more later but the other stuff I got up to was testing some tweaks inside of cookie cutter and then looking into the issue that arose from the circuit python typing that ended up in a fix inside Blinka and so that's what I've been up to. Thanks. Awesome, thank you filming guy. Next up is jepler. Hello, this ended up being kind of a long block of text even though it didn't feel like a lot so last week was another week of Floppies while doing that I successfully learned how to use the second core on RP2040 to enable streaming flux data to the computer in real time that's in the Arduino environment in fact most of this is in the Arduino environment so keep that in mind. I successfully wrote a D64 non-copy protected image to a floppy and booted it on a genuine Commodore SX64 which my friend told me is the portable version of the Commodore 64 and the first color portable computer and we put a video of it up on the Adafruit YouTube and the Adafruit blog I'll drop that link in just a second in the text chat. There is one weird MFM decoding bug that appeared with the new feature so I need to chase that down before we can think about merging the feature into Adafruit Floppy and as far as that relates to circuit python I'm still waiting for the repo the Arduino repo to settle down before adopting the latest to circuit python so if you want to try it you still have to try the older version from the pull request or build it yourself to try the few things with the floppy that does work in circuit python Last weekend I did finally do a few circuit python things I put in the second of a pair of PRs to add wrap and wrap target directives for PIO programs it can increase the performance of your PIO program in some extremely specific cases by removing the need for a jump instruction the PRs are both in but I haven't actually tested it on hardware so it should be considered experimental. My own use of PIO doesn't need it as urgently as I thought but I decided to finish the PRs anyway for the sake of completeness and I did close a couple of PRs of mine that weren't ready and that I had failed for weeks and weeks to get back to I would be happy to see anybody else interested in them take them up and finish them. This week my main goal is to merge micro python I think version 1.18 into circuit python. I don't think it has incompatible changes but if it does we will need to hold that until 8.0 so figuring that out will be kind of first on the list and then just getting an idea of the scope of how much work it is but I have some optimism that I can finish that this week. Awesome, thanks Jeff. I think you're right from my understanding of the latest micro python releases that it won't be too bad. My understanding is the next one will involve NPY version change which will need to do a major release for. Yeah, it sounds like there will be some really good benefits of that but for our users we'll have to hold it for 8.0 Yeah, I'm very excited about that. For those of you who haven't been following along, Damien is working on the ability to basically run NPY code from the NPY file which means that it won't take as much RAM as it does now which could be really cool. Okay, next up is Jerry. Hi again. So for all you RFM9x fans, I stumbled across at least a new to me library for the Raspberry Pi for RFM9x stuff. I'll link to it on there. In there they explained it's outgrows from other projects that have been around for a long time. But one of the nice things that handles interrupts pretty well and excuse me. And it does a much better job of working with Arduino pair, you know, if you pair it with an Arduino board I've had a lot of trouble with the circuit Python library when you when you're trying to do the reliable datagram mode and do the AC responses or catch the AC responses from an Arduino and this seems to do that a lot better. So there's still some quirks I'm running into with it but it's been fun and I'll be doing a lot more testing with that but it looks really promising fixes for the Pi side. Also I found a little bug typo in a recent update so I put it in a PR and I was really pleased to see that somebody's actively maintaining it because there hadn't been any action on the library in about 10 or 11 months but the PR immediately got accepted and implemented so it was good to see. And then if anyone does want to go use it if you install it via pip you get an older version they apparently haven't updated whatever it is to get it out there so you need to do a local install to get the latest versions which one nice feature is that the old version used to import NumPy which it didn't need but it did anyway and that's been fixed but one of the things I discovered in doing that was that if you have one of the libraries and you're sitting at the top level of it all you have to do is pip3install. And it installs your local version so if you make changes apparently that's the proper way of doing this with pip and who knew? Somebody should write this stuff down I never came across that before I'd always tried to use setup.py and do an install which I get all these nasty looking deprecation errors from and so it seems to be that's not the way to do it anymore but again, I made the last one to know that but it's really been nice and so I'll do much more testing on that this week and then there's a bunch of issues outstanding on the RFM9X stuff with these modem configurations that just make my head hurt when I try and test them but I'm keeping to trying to understand it and then I just started on a little trivial PR to the PN532 NFC reader library a discord user reported a problem when you tried to ever read failed trying to make it fail more nicely that's about it. Awesome, thank you Jerry. I think the switch to the pip3 install thing has come about from the Python packaging folks where there's a lot of different ways to package things now rather than just setup.py and then Dan points out there's the dash e so that it will do sim links instead of copying the files over oh and that way you can just edit the files and it will automatically use those again or use the edited version cool mindful. Thanks Jerry. Alright next up is Katny. Hello so last week I updated the 0.56 inch 7-segment backpack with the Stem AQT version we updated the board to have Stem AQT connectors and the guide is now updated I created the .star single LED status LED template I hadn't run into needing it yet so I hadn't generated it and has been running through a lot of board guides and putting all the templates in and obviously things like itsy bitsy and trinket have .star's only one and needed that template so I finally got around to doing that I updated the mcp4725 guide with the Stem AQT version I created a welcome to circuit python learn group it's a single link that goes to the foremost linked circuit python guides groups are something that has been in learn for a very long time but not very highlighted so it's something that learn dev is working on right now is making them more forward facing to users easier to find and making them more useful because they are super easy it is a very useful feature but we haven't been using it so there is going to be a page that you can go to that is like an explore page which will have groups on there that have a quick description and an image so you kind of can go and say I want a lightsaber project or whatever something like that and then it will be like here is all the light sword related projects and it's all in one place so it kind of usurps needing to search because search doesn't always return what you need so we are going to start putting more of those together I decided on doing only one further call for input this year this was discussed previously in my circuit python 2022 post and 2020 post I guess but I am going to do a call for input for circuit python day that's I believe August 19th this year so about a month ahead of time I think is about how long we did the one for this year for 2022 I will be putting out a call for input for folks who are interested in letting us know what they still want to see out of circuit python if there is anything new that sort of thing whatever comes to mind who knows where we will be by August as quickly as circuit python evolves so I am hoping that it inspires some new input I started on the ADXL 375 guide I wrote the ADXL 377x circuit python library and started updating the Vemmel 7700 guide with stem and QT version as well today so far finished and put the ADXL 375 guide into moderation and continued the Vemmel guide update this week which is actually hopefully this afternoon I am going to be adding an offsets functionality to the ADXL libraries starting with the 34x it is basically it is a manual calibration where you set it flat and you look at the numbers and you say okay it should be 0 it is 15 so you do a minus 15 for the offset and hopefully I can get that sorted out the rest of this week we will be finishing the Vemmel 7700 guide working on finishing the feather TFT guide including circuit python demos for the display there was a lot of feedback on that guide most of which was hey the one thing that people want to do is use this TFT and there is no example for it so we are going to fix that I say we I mean me I am going to do the Essentials template for async.io which goes along with all the other templates that have been going into the new board guides that is going to be a simple example pulled from the async.io guide and like I said will be included in every one of the board guides so folks will have a lot more exposure to async.io at that point which will be good and then once I am caught up on guides I still need to get some content up on circuitpython.org slash trademarks we do have the content it is in a very pretty PDF translating that to HTML is I could make it look pretty ugly and get all the content up there but it turns out Justin one of our developers has offered to help me make it pretty so I will have help there and hopefully it should at least have some resemblance to our fancy PDF when it is all said and done and in other news I should finally have some time to get back to the mailbox project this box of parts has been taunting me for a few weeks now and Jerry I hope to be pinging you this weekend or possibly this week with some help forgetting that going and that is what I have got awesome thank you catney next up we have Kmatch thanks Scott so this past week I updated the focal touch library it is a pastive touch panel library that currently as it existed handled screens with one touch point but I came into a touch panel and it has another chip that can monitor 10 touch points at the same time so I extended that library to also accommodate that chipset next thing is following up on some feedback I have gotten from gamblore and foamy guy suggesting how to consider handling touches using the core circuit python keypad module looking at that it looks to store interrupt pin timings but I am not quite sure how I can use that best to trigger a read of my touch panel since I needed the timing as well as some other data the position data pulled by I2C but suggestions are welcome on how I might do that or if that is bordering on interrupt handling maybe that is a core related issue but any suggestions feel free to send them along and follow those up related note on widgets for displays I created a circuit python org library for a vertical text scrolling box and I realized conflicts with foamy guy's recent horizontal scrolling box so I may need to reconsider that so feel free to give suggestions on that but the link is there and I got an ESP32 S3 board and I got REPL running on it so a lot of good work everybody is doing to make that so easy this coming week I am going to spend time more on trying to understand touch gestures and how to translate them into just points into some actions so between 1, 2, and 3 points just a few notes on how I am thinking about trying to handle it but first I need a way to visualize what is going on so I am actually looking at some of the other widgets and how to update them so I can plot some of the motion and velocity acceleration of the touch points so I can not just measure the data and put it in a spreadsheet and then deal with it later how do I just on the fly display it so just following the rabbit hole a little bit further and work on some other libraries in the process thanks awesome thank you K-Match it makes me the ice grid sea polling thing is something that has come up a lot I wonder if we actually need to think of a way of doing ice grid sea data buffering in the background sort of thing could fit into that as well okay next up is maker melissa hello last week I finally finished the little FS sporting project and integrated the whipper snapper firmware uploader so whipper snapper can now run on the ESP 8266 for anyone who has not been following along that was basically taking the little FS which was coded in C and converting it to native JavaScript at least enough of it to be able to create an image I fixed a weird issue on the 2.7 inch display in arduino where the colors got inverted if you use the reset pin so it wasn't working on the breakout but it worked fine on the shield I fixed an issue with the raspberry pi blink install script when the python command didn't exist that wasn't a common case but it apparently did happen for some people I tested a few PRs that were waiting for my review and I started adding some new boards at circuitpython.org that were missing so this week I'm gonna finish up adding those boards and then work on catching up on some more github issues and maybe work on some guide updates later and that's it awesome thank you melissa next up we have notes from mark gambler so I'll take a timecode and read those off mark says last week updated the native module code from micropython to work in circuitpython largely untested but will compile and didn't crash when I ran it discussed with foamy guy the need for an unzip type function that exists in xmod slash uzlib this week time is tight but I think putting a decompressed module like micropython in the shared binding slash module pattern is doable this is similar to what was started in PR 1274 first try will be just to get it going the old PR expanded on it I believe and lastly this week fixes the native PR module PR an example tests jebblers done I do not plan to take this code much further this time but if anyone has questions on it let me know I could also be convinced to look at it more if there's a lot of interest the first look was mostly to learn more about the that area of the code and to see if I if I could all right and lastly I have notes from tectric so tectric says last week learning the ropes of reviewing patch the issues with the split documentation sections in the readmes worked on some follow up PRs for the belee libraries fixes for the blink of circuit python typing library touching up the cookie cutter per cat knees recommendations and then this week taking some time to work on real life stuff but hopefully some odds and ends like bug fixes and library typing when there's time and with that we're into our last section in the weeds does anybody I know we're running a little bit later than we have been does anybody in the weeds need to go first I don't think I don't think Melissa or Jeff have time constraints I don't either have a couple topics in there but I don't have any time constraints already well I know some folks have to leave so in case somebody's about to leave remember that next week's on Tuesday it's 24 hours later than normal normal so just just a reminder to that before we get into some weeds and with that for me I go ahead and talk about your first your first item here right let me get scrolled down so this one comes out of something that I was looking at last week the web telescope data API that is this one is directly from NASA which is nice but it turns out that there is something going on with the SSL I think it is with that server I guess that's leading to us not being able to fetch data from it currently in circuit Python and I think it was anecdata so a late hard report to anecdata tested this out I think with the ESP IDF example code so like just using directly the ESP IDF and running it on I think an ESP32S2 and it seemed to work that way it was able to successfully you know mediate the SSL and get the data from there so I guess my question is like what all goes into updating the ESP IDF in the core and is that like a whole can of worms that causes a bunch of other problems or is that something that's relatively easy to try to tackle well it depends it depends on like what I tend to like to do is have us track a branch of the IDF that's not the main branch there's a lot of turn that happens in their main branch especially right now so we're on we're on the branch for their 4.4 release and so I would so it's easy to update along that release branch moving off that release branch to like their master branch is a whole other thing because they're currently working on 5.0 so they're making a lot of changes okay so my preference is that we stick kind of along their latest release branch I would say that if it's not fixed in the newest versions of that which they do pretty actively fix stuff in we should bug them about it and see if they'll back port the fix to their 4.4 branch okay cool I'll have to dig a little bit and figure out like which version it was specifically I did not end up looking into it but yeah I will check on that and then if it is the other one in that branch that we're not using we can look into it if there's not then I will do what you mentioned and ping them and see if they'd be willing to back port it into that branch for us the other thing we do occasionally have our own like we have our own version of the IDF branch in case we want to apply fixes to it so that's another option that we have Jeff is asking do we know what the problem is does it have to do with a missing certificate that is possible I don't know for sure I know the most elaborate error message that we've gotten to come out of it is just like SSL handshake error so that does sound like it could be a missing certificate to me I will say I don't have too much experience with SSL and HTTPS beyond just setting it up and making sure it works so some of the particulars are a little over my head is there oh yeah I don't if anybody could point me in the right direction to like how to try to test that or how to try adding a different certificate or something like that I'd be more than happy to try to do that but I don't know exactly how to go about it I would talk with Brent I think Brent is the person that if I need to know SSL certificate stuff I would talk with Brent okay because he's done a lot of that for all of the different IoT services that he's worked with yeah that would be ideal I guess if that turns out to be the issue if it's as easy as just updating a cert that's probably I would guess a whole lot easier and less likely to be a gigantic ordeal so yeah and I think we may actually have like we're using the certificate bundle that Nina uses as well which is the one that Brent has maintained for the IOT library stuff IOT library stuff I think okay so there's some possibility there maybe that gets it's updated possibly that resolves it for us I think the baseline for the certificate bundle comes from like I think Mozilla actually maintains like a bundle of root certs I think that's where it comes from plus any that we need to add I will mention it to Brent doesn't look like doesn't look like he's in the chat here but I'll ask Brent this week about that he should be responsive if he ping him I think he's around the other one I think that pretty much covers the first topic unless anybody has anything else to add but the second topic here is more along the lines of the GZIP utilities which I mentioned a little bit earlier quick rundown basically we have this other API which is also actually a U.S. government API interestingly enough but this one we are able to resolve the certs and everything we don't have that problem with this one but the data that we get back we try to parse the JSON that's in it and it doesn't work and it turns out the reason why is because the data is GZIP so the server always returns the data GZIP that didn't show it to you but so far our libraries like requests and like ESP32 spy and stuff like that and the Wi-Fi libraries in the core they don't do any of that automatic unzipping and so we have kind of I guess two paths forward that I see one of them is basically turning it on inside the core the ability to unzip or use zip I guess probably micro zip is the name there is a module from MicroPython that exists it's just not turned on in MicroPython somebody had started a PR at one point to do it but there were some additional changes that were requested and that person didn't end up I guess wanting to do it so it ended up getting a little stale but if we now have a specific need for it maybe now is the time to finish that up and then get it merged that way in which case then either user code or library code could make use of it so that's one option is kind of like turning it on in the core getting that PR resolved or starting a new one the other one is going with just pure Python inflation code which does exist there's an older library out there called Pyflate I think I mentioned before it needed to be updated because it hadn't been updated in quite a while it was using Python 2 code but that did get updated and we were able to successfully use it so that's kind of the other option is doing the inflating from pure Python code and then I will mention the one sort of follow up step beyond either of those doesn't really matter which one of those two we choose both of them will give us the ability to inflate gzip data and so then the next question becomes do we want to have requests or some other library that's in the stack try to automatically handle it I noticed on cpython requests I can fetch that same URL and it does seem to just silently do the unzipping so I figured it might be nice to match but I could also see a case to be made like adding extra stuff into requests and not everybody will need it so maybe it makes more sense to just say user code needs to fetch it and then unzip it manually rather than it just kind of magically happening when you do the request I think you probably wanted to behave the same but you needed to be careful and like I did some work to make sure that when we JSON decode stuff we don't have to load the entire giant string so like making sure that we can gzip kind of on demand not all at once that was I started kind of looking into that front really I started looking at it from the angle of trying to make requests give a better error when it came across gzip data and that was something I noticed is that there's something with read into it's basically like it looks like it's being able to parse the JSON in a buffered way without doing all of it at once and I did have some trouble trying to figure out how to like read the first couple of bytes and then I would from those decide if it's gzip data or not and then if it is raise that new error or if it isn't then just do the normal stuff but what I was finding is it seems like way that buffered loading occurs it almost seemed to me like it was one time as soon as I accessed the data the first time it didn't really want to let me access it anymore so I think it is I think it might be destructive I think the hurdle the only way I would know around that is storing it which it seemed not ideal since it would cause it to all the whole JSON to get loaded in memory so it's another kind of wrinkle is if we do want it to be automatic we'll have to figure out a way to kind of peak at the first couple of bytes without um losing access to the rest of them I don't think you need to do that I thought there was a header field that says that it's compressed so you know before you get to the body that it's going to be compressed yes I do think there is a header in this case yeah it returns the header content encoding with the value gzip which this is utterly broken because you it shouldn't send back gzip unless you say you will accept it and even if you say accept encoding identity which means it shouldn't compress it it still returns it compressed I think this website is broken personally I but I suspect the government will not look into it and fix it in any sort of timely manner I think that support could be really helpful especially for embedded because a lot of apis are giant text blobs and giant text blobs compress really well so like I think it's a worthwhile feature for us to have even if the reason that we have to add it is this broken website and it does look like I'm looking at the header it does come back with content encoding gzip so I don't think I've done it before but I assume that requests the request library must give us a way to access the headers so I could check that header and use that as the key to know um I think it just has dot headers because it's gotta load it to know whether it's chunked and stuff I will um I'll try that I think short term is just make requests try to throw a better error so that the next person that comes along it will get a clear message that the just needs to be unzipped and then I know Mark Gambler was going to look into that core PR we also have the follow up option if that doesn't pan out for any reason the Python code so is there any opinion on whether requests would handle it automatically to match the C Python I think it should because that's the way the regular request library we try to make it want to make it be like the regular request library yeah it should I would say it should if it can and if it can't it should do the nicer exception that you're talking about adding okay alright um I think that's all that goes into that unless anybody has anything more to add but that gives me the next couple of stones to try to hop to so I'll just say that UZlib has a stream API oh nice so that can maybe work sort of the same way that the JSON is doing its different stuff yeah nice yep well thank you thank you to looking into for looking into that it's like 12 what was it 12 something PR like it's pretty pretty awesome that it's something we wanted to do for a while yeah yeah and huge things as well I'll mention again to AnikData and AirDoc both both of whom I would not have been able to get even this far without so thank you to those folks as well cool alright um thank you filming guy next up is maker Melissa hello so one of the issues that we're running into is on certain boards like the matrix portal just the whole bundle of libraries that we need to add on to the board are really too large for it to run and so we suggested freezing in like the um portal based library for instance into there I noticed there's some other libraries that it are used on the matrix portal for instance uh like the request library that are supposedly in the frozen folder but they're also not accessible so I don't know how that exactly works they're in the frozen folder but they're not accessible right like if I want to import aid for request for instance so just because it's in the frozen folder doesn't mean it's enabled for a particular board okay you have to actually enable frozen libraries for a specific board so circuit playground express for example if you go into one of the um board files I don't remember which one it should be pretty obvious um there's like frozen libraries like are listed and they're enabled in that particular board so if you wanted to freeze requests for example into matrix portal you would have to actually go into the board file and set that yeah that's it right there so that's one thing uh now like bus device is frozen into there even though it's not specified so I don't know if that's like a certain one that's frozen into all boards we have a device now is native yeah ah okay that's what I didn't realize okay and you're doing this Melissa for memory savings is that your goal yeah okay so this is the thing that hopefully the newer version of MicroPython will fix for us okay cool um but in the meantime I think it's fine to freeze it in okay sounds good yeah with portal base we're using it on several different boards mm-hmm Melissa if you need help feel free to ask okay it's also not updated very often anymore so it seems I could candidate right uh that's it for me sweet thank you that was a a quick one uh right last up we have jet blur hello I think Scott this may be a you have opinions kind of question I don't I don't ever have opinions I don't know what you're talking about but uh with mark reviving the interest in the so-called native modules um which if you're not familiar with them um they are a way to include uh code compiled for the microcontroller in an mpy file and it's potentially more efficient anyway are there some boards where we want to consider enabling it I think it's possible that the rp2040 and expressive boards um given that they have a lot of RAM comparatively seem like good um candidates but um you know if we're gonna work on making this work and take pull requests about it we should enable it for some people you know for some boards where we think it could be helpful to people um so here's what I'll say I'm not against it but I think that there's a big hurdle that needs to be figured out before it's something that we actually support and it's the idea that native modules are port specific or at least CPU architecture specific yeah there would be two different forms there'd be one for the um expressive CPU boards and one for the ARM boards and maybe different ones for the ARM with and without hardware floating points so there are gonna be some variables there for sure right right yeah so I think I think we just need to make it very clear probably in both the file naming like the file naming needs to include like what architecture it's geared towards so that we can just be like oh yeah like you need a file that has this extension instead of just doing NPY right because NPY will work across architectures as long as it doesn't have native code um and then we should have really good error messages when people do try to or or have a the wrong architecture file there as well those are good points I hadn't thought about actually using the extension what I think MicroPython does is their convention is like say your module is um foo they will name the NPY file foo underscore x64.mpy where x64 is the common instruction set for desktop computers which was what I was testing mm-hmm and so you know it's in the name but it's not in the extension so we could potentially change that part of it I guess you know makes us do more work but it could be better for users I am pretty sure that when it's brought in you get a decent error message uh rather than just running code that is meaningless to the microcontroller that you have but I would have to double check on that yeah so that's my concern like I'm not against native modules I'm concerned about the maintenance burden of folks that are trying to use native modules that are for the wrong platform yeah so there may also be some tooling that we need to do around native like libraries that use native modules maybe we actually need to say like if it's generic it needs to actually like have a CI tooling that generates all the different combinations of architectures that it's yeah the CI tooling would be a whole new thing before we could ship like installable via circup modules so that would definitely be you know part of the whole solution yeah so I think how much of that we really feel we need to have in place before we would enable it in the you know my gut would be we can enable it in the core and then we don't even need to take advantage of it right away but we've enabled our advanced users to test it out and kick the tires we'll find out more of the details about it from them as we create the tooling the rest of the tooling around it right but at the same time like any conventions that you want to establish are easier to establish up front so like maybe it's maybe we should check file extension just to force it right like to check the file suffix just to make sure that it follows that convention sure would you be willing Scott to after the meeting just write up a few of those thoughts kind of a checklist for what we would do before we would enable it maybe on either Mark's pull request or mine that's related to this because otherwise I'd be tempted to just go enable it for Fetver RP 2040 you know for my own convenience in testing and just put it in the branch and then it would be there do we have do we have a native modules issue already I don't actually know if there's an issue mark and I were both working on separate pull request okay because I think I think an issue might be the right place to track these like higher level like goals yeah no that would be good too and then we could just link link to that issue from the PRs yes exactly let me make a note to myself on some paper that is on my desk I'm gonna have to go get lunch here shortly so I'm gonna do something today I need to note it down alright anybody else who wants to chime in about that I guess the other thing I will note about native modules before we move on is I don't think that there's a way to like efficiently work with a with our kind of shared module objects like you can't write a common howl call inside of a native module because they aren't available in the linkage between them so we might also in the future figure out here are the things that we're gonna add and make available from a native module that are in addition to what MicroPython has they basically don't have any of the machine interface stuff in there and I'm not sure you know you couldn't create an I squared C thing with I just think it doesn't work it's for compute stuff so it's great for being able to import Zlib which is one of the example modules but it's not great for I want to implement an I2C driver that needs to go in the core or operate in the background so it has limitation I think that's a really good point that could justify it like our bus IO and digital IO and microcontroller APIs are pretty damn stable so like I would be okay making those kind of public APIs in the sense that native modules can link against them if it means that for these folks like Kmatch that want to be able to do background background stuff for I2C maybe that's the way to do it Yeah as far as I understand it there's kind of two costs to adding these things and there is the you're committed to it cost and there's the you pay like the cost of one function pointer within flash for each thing that you expose and that cost is pretty minor at the scale of the RP2040s spy flash memory but the one where you're committed to it and also we might end up wanting to probably need two separate tables or something so that when MicroPython adds four more items they don't want a position where our first four items are otherwise it was a compatibility nightmare so we might need to do something else before we go adding to adding APIs that aren't in MicroPython Yeah I think it could be really interesting especially if that's our solution to the background story and maybe what we also need to do in the common how naming is actually call them like public common how like I know they're super long right now but your games are getting really long Scott I but but in this case I think it would be really nice for us to distinguish common how APIs that we think are private in the sense that native modules can't deal with them and then the ones that are public right like it is important to have that distinguish distinction just how much is public how yeah it could just be public how that would be fine but yeah having a if we expose or if or when we expose those things like just having a way to designate them as such yeah I think proving that we could do just pure compute native modules first is the way to go and then figuring out you know what is what is the good subset to expose of MicroPython specific hardware APIs would be a second thing that we could look at even you know version nine I don't we we don't have to get that right up front we can wait before we then do anything until late right right yeah I think you're right in that we should figure out what the baseline we want to do is and before we turn it on so that people can just experiment with it so I agree we do there all right well that that answers what I was looking for thank you all right well thanks for bringing that up Jeff and let's go to the meeting wrap up I will take one final time code first and foremost another reminder that next week is a day later than normal so we'll see you on Tuesday February 22nd at the normal time thank you all for joining us let me stall while I scroll down in our overview doc this has been the CircuitPython Weekly for February 14th 2020 thank you to everyone who participated if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing from the Adafruit shop at Adafruit.com the video of this meeting will be released on youtube at youtube.com slash Adafruit and the podcast will be available on major podcast services it will also be featured in the Python for Microcontrollers newsletter visit AdafruitDaily.com to subscribe the next meeting will be held on Tuesday next week 24 hours later than normal but at the usual time 2pm eastern 11am pacific the meeting is held on the Adafruit Discord server which you can join by going to the URL adafru.it to be notified about the meeting and any changes to the time or day you can ask to be added to the CircuitPython Nisa's role on Discord and with that we hope to see you all next week thank you all thank you thanks everyone


Hey guys, thanks for thanks for coming back. We're doing a beard product reviews And and chances actually has discovered something that I find to be absolutely amazing. How about you? How about you talk? It's not only amazing. It's for you.  Yeah, it's the cheapest product you can get and guess what it comes in tub sizes I'm shortening. Okay. It's the cheapest stuff you can get. You can get it Wal-Mart Target Anywhere that sells food Mexican grocery stores. Yeah, they sell something called lard. I think it's the same thing You can you can you can actually go to the grills in like Japanese restaurants and scrape it off the grills You can get it for free. I think that would really I think that would really resonate with people who don't give a flip about their beards But honestly the hold on this I don't I'm not positive, but I'm pretty sure it just well I put some in last year and I still can't get the darn stuff out of my beer It actually just grew out of it and I had to trim it off What I what I highly recommend to if you put enough in at the beginning of the day when you get home And you're hungry. You're tired.  Yeah, just just go to town.   Okay, it's an important part of doing what we do best And save that same in the beard Save it