Koodihommia

In a previous blog post, I took a look at how to enumerate all the syscalls and even their arguments using tools such as  eBPF . That left me pondering and craving to learn more about how memory is mapped and what do simple variables look like in the memory. What is behind all those memory addresses you can see in the stack traces? I do have an intuitive sense of that. Sure, I have seen blog posts and talks about the topic, taken a look at heap dumps in a hunt for memory leaks but I wonder does it make any sense to look at the memory in a language/runtime agnostic manner. Probably not, but hey, could be exciting. To find out, I created a simple program that simply prints out the contents of a few variables  I try to make the outputs depend on the runtime environment to avoid any unexpected compiler optimizations. I want to make sure the memory will be allocated at runtime. I run the code in my trusty Digitalocean VM with "no hang-up" and attach the GNU Project debugger (GDB)

 I built a simple MIDI looper with the Teensy 3.2 development board  It's a simple device. It has two MIDI inputs, one serving as a THRU port, mostly for forwarding sync messages to the connected device. The other input port is for connecting the instrument. The output port binds the loop for sending and receiving notes. The first version soldered to a stripboard. The left and center MIDI connectors are the inputs connected to the Teensy (header pins visible) through  an optocoupler circuit Teensy is the perfect fit for this kind of project, mostly due to its tiny dimensions. It works with the same development setup as Arduino, and virtually all libraries that work with Arduino work with Teensy. It even includes a MIDI library, which came in handy. The code is trivial; the gist is that we read the input tempo, start and stop messages from the THRU port and merge the tempo message with incoming note data. The note data quantizes to the nearest 8th sync message. Up to date feature l

Besides the object geometry information, IFC files may contain properties for the IFC objects. The properties can be, for example, some predefined dimension information such as an object volume or a choice of material. Some of the properties are predefined in the IFC standards, but custom ones can be added. IFC files can be massive and resource-intensive to process, so in some cases, it helps to separate the object properties from the geometry data. IfcOpenShell  is a toolset for processing IFC files. It is written mostly in C++ but also provides a Python interface. To read an IFC file >>> ifc_file = ifcopenshell.open("model.ifc") Fetch all objects of type IfcSlab >>> slab = ifc_file.by_type("IfcSlab")[1] Get the list of properties >>> slab.IsDefinedBy (#145075=IfcRelDefinesByType('2_fok0__fAcBZmMlQcYwie',#1,$,$,(#27,#59),#145074), #145140=IfcRelDefinesByProperties('3U2LyORgXC2f_hWf6I16C1',#1,$,$,(#27,#59),#145141), #145142