More updates on the TUN Driver development!
So What’s Been Happening? Thankfully I’ve been able to get a lot more done on the driver this week with finishing the write/sending functionality of the driver and I am currently on the reading/receiving functionality which is getting close to being done. At first I tried to implement a solution in the networking interface (tun.cpp) that didn’t use iovecs but that just caught up to me in the end and it was just significantly easier to copy and paste the code from ethernet.
While the change request to add reference images was being reviewed, I started working on ticket #18415, which suggests adding shear and perspective transformations. I decided to implement the perspective transformation since I still need to figure out which way I’m going to implement the shear transformation. Hopefully the experience in implementing the perspective transformation will give me information that will help me decide how to implement the shear transformation.
Intro Hello again everyone! I wanted to write a long overdue update on how everything is going and what I’ve been learning over the past couple of weeks. Due to how my semester didn’t actually end until the 16th, progress has been relatively slow but now that I have more time I can get started on more things with this project.
Understanding the Project Better (If I get anything wrong about anything I am about to say, please correct me!
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev56962 through hrev57061. It was quite a busy month!
I have fixed three memory leaks. Before, leak_analyser.sh found 75 leaks from simply opening and closing Icon-O-Matic. It now reports only 27.
I am now planning to implement a new shape type called “reference images”. This implements ticket #2748. As discussed in the ticket, having a reference image in the background greatly assists in vectorizing it. Reference images are just for reference. They will not be exported to the final HVIF file.
The coding period has started today! In the last blog post related to GSOC, I said “Here are the plans that I currently have. As with all plans, they are subject to change.” They did indeed change since I found a tool to find memory leaks.
Before I was accepted into GSOC, I had been thinking about porting AddressSanitizer to Haiku to find memory leaks. I decided against it. During the community bonding period, I found a file called leak_analyser.
Project status overview Completed tasks The .NET SDK has been ported to Haiku after a few hacks. .NET on Haiku now has the ability to run Roslyn and build a simple console application.
.NET latest builds for Haiku are being provided at trungnt2910/dotnet-builds. You can follow the instructions there to install and try out .NET.
Current plans Before proceeding to the next step, I want to ensure the stability of the current SDK by bootstrapping .
In 2010-2011, mmlr created a new memory allocator: the guarded heap memory allocator. This allocator helps detect various bugs such as writing past the end of allocated memory, reading uninitialized memory, and freeing freed memory. These uses are detailed in “Using malloc_debug to Find Memory Related Bugs”. Later, in 2015, mmlr had a new project: updating the memory allocator to be able to report memory leaks.
To use this feature, start by loading libroot_debug.
It is barely a week since the start of GSoC, but there has been so much progress on this port. Ideally, this progress should be coupled with some documentation before my brain’s garbage collector reclaims the reasoning, so that future maintainers can have an easier time rebasing and porting newer versions of .NET.
Project status overview Completed tasks My current port has achieved all the tasks that the partial .NET 7 port did last summer, including:
As is the usual way of things, the monthly Activity Report is hereby combined with my Contract Report.
This report covers hrev56888 through hrev56961.
