Argument handling on Haiku
Hi, I’m Nephele. I’ve not made a blog post before, but this seemed like a good opportunity.
There are two main ways to start an application from Haiku’s UI, directly and indirectly. Directly by opening it, and indirectly by opening a file that the application you want supports (and is configured to handle).
The indirect way involves opening a file that the application supports and having the mimetype plus the registrar figure out where to forward this to.
Project status overview During this period, I have been working to get the Release build of .NET SDK to work more stably. I have identified some issues related to POSIX thread scheduling in Haiku in the process. Sadly, I cannot deliver stable builds of the SDK at the moment because that depends on edge-triggered file events.
As mentioned on my forum thread, I have ported some sample applications of popular C# frameworks such as GtkSharp or FNA.
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.