Programming Leftovers
-
Martín Abente Lahaye: Portfolio 0.9.15
In terms of visuals, by popular demand, the most notable change is the use of regular icons for the files browser view. It should be easier now to quickly catch what each file is about. Thanks to @AngelTomkins for the initial implementation, @Exalm for helping with the reviews, and to the GNOME design team for such lovely new icons.
Another addition is support for system-wide style management. This is specially useful now that desktops like GNOME provide quick toggle buttons to switch between dark and light modes. Thanks to @pabloyoyoista for the initial implementation.
-
Adapting Standard Usage Scenario Scripts For KDE Applications: My Journey As A Season Of KDE Mentee
My Journey into the KDE Community: From Season of KDE Application to Mentee
The notification about the Season of KDE program arrived like a ray of sunshine on a dreary day, and I eagerly clicked on it to see what opportunities it held. Amidst the many exciting project ideas, the Blue Angel Certification Preparation for KDE applications stood out to me as a challenge worth pursuing. I took the first step towards realizing my goal by engaging in a conversation with the community and making some initial contributions to FEEP. On January 24th, the selected candidates were announced. My heart was pounding as I scanned the list of names, and when I saw mine, I let out a cheer! Being accepted as a mentee in the KDE community was a great start to the year 2023.
For the project, I will be using emulation tools such as
xdotool
andKDE Eco Tester
to finish preparation of usage scenario scripts needed to measure KDE applications such as Kate and GCompris. To help guide my work, my mentor and I created a to-do list based on my proposed timeline and we selected the KDE infrastructure to manage the checklist of tasks. This was my first exposure to the diverse range of applications and platforms provided by KDE for the community. -
2023-03-14Next Debian/Ubuntu Releases Will Likely No Longer Allow pip install Ouside A Virtual Environment
-
PyTorch 2.0: Our next generation release that is faster, more Pythonic and Dynamic as ever
We are excited to announce the release of PyTorch® 2.0 which we highlighted during the PyTorch Conference on 12/2/22! PyTorch 2.0 offers the same eager-mode development and user experience, while fundamentally changing and supercharging how PyTorch operates at compiler level under the hood with faster performance and support for Dynamic Shapes and Distributed.
This next-generation release includes a Stable version of Accelerated Transformers (formerly called Better Transformers); Beta includes torch.compile as the main API for PyTorch 2.0, the scaled_dot_product_attention function as part of torch.nn.functional, the MPS backend, functorch APIs in the torch.func module; and other Beta/Prototype improvements across various inferences, performance and training optimization features on GPUs and CPUs. For a comprehensive introduction and technical overview of torch.compile, please visit the 2.0 Get Started page.
-
Pass by Value Meaning in Java
In Java, when you pass a parameter to a method, a copy of the value of that parameter is passed to the method, rather than the original object itself.
-
What are Varargs in Java and How to Use Them
In Java, varargs (variable-length arguments) are a feature that allows a method to accept an arbitrary number of arguments of the same type. The varargs feature was introduced in Java 5 and is denoted by an ellipsis ... after the parameter type in the method signature.
-
What are Java’s Access Modifiers and How to Use Them
In Java, access modifiers are keywords that determine the accessibility of classes, methods, and variables in an object-oriented program. There are four access modifiers in Java: Access modifiers are used to control the level of encapsulation of an object-oriented program and to restrict access to sensitive or implementation-specific details of the program.
-
BTHome: An open standard for broadcasting sensor data
Many wireless sensors broadcast their data using Bluetooth Low Energy (BLE). Their data is easy to receive, but decoding it can be a challenge. Each manufacturer uses its own format, often tied to its own mobile apps. Integrating all of these sensors into a home-automation system requires a lot of custom decoders, which are generally developed by reverse-engineering the protocols. The goal of the BTHome project is to change this: it offers a standardized format for sensors to broadcast their measurements using BLE. BTHome is supported by the Home Assistant home-automation software and by a few open-firmware and open-hardware projects.
The chances are high that the manufacturer of a BLE device requires the use of a smartphone app to remotely view its data. But, technically, there's no need to use the app. The device advertises its name and some data; anyone with a BLE receiver in the neighborhood is able to pick up those BLE advertisements. What those apps do is to convert the raw data to information such as a temperature or humidity value using a protocol decoder for the proprietary data format.
-
FSF Events: Free Software Directory meeting on IRC: Friday, March 17, starting at 12:00 EDT (16:00 UTC)
Join the FSF and friends on Friday, March 17, from 12:00 to 15:00 EDT (16:00 to 19:00 UTC) to help improve the Free Software Directory.
-
GNU Guix: Building Toolchains with Guix
In order to deploy embedded software using Guix we first need to teach Guix how to cross-compile it. Since Guix builds everything from source, this means we must teach Guix how to build our cross-compilation toolchain.
The Zephyr Project uses its own fork of GCC with custom configs for the architectures supported by the project. In this article, we describe the cross-compilation toolchain we defined for Zephyr; it is implemented as a Guix channel.
About Zephyr
Zephyr is a real-time operating system from the Linux Foundation. It aims to provide a common environment which can target even the most resource constrained devices.
Zephyr introduces a module system which allows third parties to share code in a uniform way. Zephyr uses CMake to perform physical component composition of these modules. It searches the filesystem and generates scripts which the toolchain will use to successfully combine those components into a firmware image.
The fact that Zephyr provides this mechanism is one reason I chose to target it in the first place.
This separation of modules in an embedded context is a really great thing. It brings many of the advantages that it brings to the Linux world such as code re-use, smaller binaries, more efficient cache/RAM usage, etc. It also allows us to work as independent groups and compose contributions from many teams.
It also brings all of the complexity. Suddenly most of the problems that plague traditional deployment now apply to our embedded system. The fact that the libraries are statically linked at compile time instead of dynamically at runtime is simply an implementation detail. I say most because everything is statically linked so there is no runtime component discovery that needs to be accounted for.