So, I just arrived from Brussels back home. One more FOSDEM done. As always it was action-packed, and I couldn’t clone myself enough times to see everything. The fact that we had the booth and that 3 out of the 4 talks I proposed were accepted probably didn’t help.

Luckily this time we were three to handle the half-booth, as both Olivier and Adrien made it with me, because yes, we shared the table with ReactOS this time, to increase the chances of being picked up.

The trip went without trouble, except I only slept like two hours and had to wake up at 5am, and I was still recovering from a flu, but you know, devotion. ;-) I arrived on Friday, and quickly found the hotel, took lunch and a well needed nap. I woke up too late to attend any of the outside events I was aware of, so can’t tell much about those. I also finished my slides, although they were already quite done in the train.

On Saturday we set up the booth with Olivier, after he spent 30 minutes finding a place to park the car, and we started chatting with our two ReactOS dev neighbours. Adrien soon joined us from Toulouse, so the team was complete. We pondered about printing a banner saying “We are NOT GNU/Linux distros” but we weren’t allowed to tape anything on the wall. Someone did a short audio interview of all the stands, including ours. We also had quite many people passing by, as we were located just next to the infodesk in the K building, where all the GNU/Linux distros are, so the place was crowded. Some people did ask us for the toilets though. :D

In the evening all five went to a Belgo-greek restaurant to discuss the projects further more.

On Sunday we woke up earlier as we had to check out of the hotel, and I had my three talks starting at 10:45. At least it was easier to park the car this time.

I went to see the first talk of the Decentralized Internet devroom by Tristan Nitot (ex-Mozilla, now at Cozy), but then I went to get accustomed to the Desktop devroom. One of the talks I wanted to see there was cancelled, it was about alternative graphics servers on Linux, and I wanted to thank them for helping make GNU/Linux software more portable to Haiku by removing X11 dependencies…

I started by talking about retro desktops in the Desktop devroom, and the room was almost full. Then I talked about Haiku, and I believe most people stayed. I had some interesting questions for both talks, but then I had to rush to another building for the third one. The Python devroom was in an amphitheater, and I had even more people watching me talking about Weboob, I’m not used to it… The videos for the talks are starting to become available, the talk pages should link them automatically when they are.

Then I took some much needed lunch. I checked the foodtrucks but they were quite busy, so I went for a sandwich at the caferaria. On my way out I saw Amaelle Guiton, a french journalist, on her first FOSDEM. She wrote a nice article about it in French (guess who’s on the photo). At FOSDEM, even lunch is an opportunity to discuss with people you met at other conferences.

It’s also an occasion to advertise useful FLOSS projects, like OpenFoodFacts, an open crowdsourced database of food informations (ingredients, allergens, nutrition tables…).

I also tried to go back to the Decentralized Internet devroom but it was full. Apparently it was full the hole day, so the topic got attention. I also wanted to meet with people organizing the next RMLL/LSM (Libre Software Meeting) in Saint Etienne, but it seems we missed each other. I also passed by other booths, and said hello to Stephanie, Josh and Jeremy from the Google OpenSource team (yeah, you know, GCI and GSoC).

Besides my own blue beret from the 2008 RMLL, I saw other people wearing berets, and some people wore even stranger hats, specially the VLC folks with their cone-heads…

I passed by more booths in other buildings. There were some funky things, like a system to detect failed street lights when passing under with a car from Automotive Grade Linux, and BBC’s micro:bit, a new microcontroller board to help kids learn coding and electronics. Back to our booth for some more discussions about Haiku, about applications, and driver support…

Then it was already time to tear down the tables, and I joined the ReactOS devs in the shuttle to the train station, although mine was a bit later.

I wasn’t sure I would be able to find someone to drive me from the TGV station, because, well, “Valence”-TGV is actually 15km away from the town called Valence, it’s just in the middle of nowhere, and of course there aren’t any shuttles after 11pm. But after begging some friends on twitter I finally found a lift.

I wish I was in a better shape so I could have seen more people and more talks, but it was still enjoyable to talk to many folks at the booth either remembering BeOS fondly or thinking about testing Haiku again after some years to see how the package management works.

And now we need to prepare for the JDLL in April, then the RMLL/LSM (Libre Software Meeting) this summer.

HaikuPorter is a python tool that takes a so-called recipe that describes the dependencies of a software and how to download, build and package it.

The HaikuPorts Wiki has all the info to get started writing recipes. But it gets into too much detail if all you want is use HaikuPorter to build stuff with existing working recipes.

Here’s a quick step-by-step guide how to do that.

1. Getting HaikuPorter and the Recipes

Get the HaikuPorter tool and the haikuports tree with all the recipes:

git clone https://github.com/haikuports/haikuporter.git
git clone https://github.com/haikuports/haikuports.git

That'll create two directories: "haikuporter" with the python tool and "haikuports" with all the recipes categorized in sub-folders.

2. Setting up HaikuPorter

Put HaikuPorter into the system's “Path”, so it can be invoked like any other command:

cd haikuporter
ln -s haikuporter ~/config/non-packaged/bin/

Copy and edit the haikuports configuration file:

cp haikuports-sample.conf ~/config/settings/haikuports.conf
lpe ~/config/settings/haikuports.conf

In the haikuports.conf file you have to edit/un-comment the lines:

• TREE_PATH - where you cloned the haikuports tree, e.g. "/boot/home/haikuports"
• PACKAGER - your name and email address, e.g. "Humdinger <humdinger@mymail.com>"
• TARGET_ARCHITECTURE="x86_gcc2"
• SECONDARY_TARGET_ARCHITECTURE="x86"

This is for running the official 32bit Haiku (gcc2hybrid), where the older gcc2 compiler is the default to maintain BeOS compatibility and "x86" is a modern compiler (currently gcc5.4) for applications that won't build with the ancient gcc2.

3. Using HaikuPorter

Now you can start using HaikuPorter. You get all its options with "haikuporter --help".

In the haikuports tree, you search the recipe of the software you’d like to build. You can also use, e.g. "haikuporter -o artpaint" to have haikuporter look for a specific recipe, here for “ArtPaint”.

To build ArtPaint, you type:

haikuporter -S -j4 --get-dependencies --no-source-packages artpaint

-S : enforce "strict policy" to create standard compliant HPKGs.
-j4 : use 4 cores when building to save time.
--get-dependencies : automatically download all packages needed for building that aren’t already installed.
--no-source-packages : don’t create a package with the source code.
artpaint : build the latest recipe for "ArtPaint".

You find successfully built packages in the folder "haikuports/packages".

4. Keeping uptodate

The haikuports tree receives almost daily changes with new, updated and fixed recipes. To stay abreast with those changes, you should regularly update. This is very easy with "haikuporter --get".

Likewise, haikuporter itself gets updated from time to time. At the latest if recipes start to fail building, you should update. This, too, is quite easy; you enter the directory "haikuporter" that you have cloned in the 1st step and use git to pull in all changes:

cd haikuporter
git pull

5. Tips & Tricks

• To save yourself much typing, you can add this line to the file ~/config/settings/profile (a text file that you have to create if it doesn’t exist already):

  alias hp='haikuporter -S -j4 --get-dependencies --no-source-packages'

  Now you can build with a simple "hp artpaint" and have those standard parameters added automatically.

• Some software can’t be built with gcc2 and needs the modern compiler. You can see that in the recipes that declare:

  ARCHITECTURES="!x86_gcc2 x86 x86_64"
  SECONDARY_ARCHITECTURES="x86"

  The "!" says the package can't be built for that architecture. A "?" shows that it hasn't been tested for it.

  In such a case, haikuporter will complain that "it is broken on the target architecture". You instruct haikuporter to build with the secondary architecture by appending a "_x86" to the recipe name, e.g. " bepdf_x86".

• Sometimes you find recipes for different versions of a software. HaikuPorter builds the latest by default. If you'd like a specific version, you can append the version number found in the recipe's filename, e.g. "bepdf_x86-2.0.0" to build v2.0.0 of BePDF for the secondary architecture (gcc5.4 currently).

• If something goes wrong and you want a fresh start, open the folder of the recipe you try to build and delete all folders starting with "work-". Also delete the "download" folder if you suspect a corrupted source archive.
  Do a "haikuporter artpaint -c" for ArtPaint as example. In some weird cases you may have to also delete the folders "haikuports/packages" and "haikuports/repositories", which will be time-consumingly recreated with the next build.

Hello world!

Let’s see what happened in Haiku this month. This report covers hrevs 50928 to 50988.

waddlsplash worked on enabling real subpixel rendering in Haiku. This used to be protected by Microsoft patents, but they are all expired or will expire really soon. So, it is time to start experimenting with this and getting ready for enabling it.

waddlesplash also reworked the JSON API, and fixed several bugs found by the“JSON Minefield” tests. This makes our parser more compatible with all kinds of JSON data, and also easier to use.

humdinger added localization support to the package daemon and solver, allowing for pkgman and HaikuDepot to be fully translated.

More patches from mt were merged, in order to make it possible to build Haiku with GCC 6. This is still a work in progress, as GCC6 finds several new warnings also in 3rd-party code that was imported into Haiku. This code should be at least updated to a newer version, and at best, moved to packages.

korli investigated and fixed some bugs in our pthread API, in order to increase compatibility and make it easier to port software.

Dariusz Knociński improved the Polish keymap, adding various special characters (various kinds of typographic quotes, apostrophes, etc).

kallisti5 fixed a problem with host-only builds resulting in an infinite recursion in Jam (it was trying to include the same jamfile over and over again because of an unset variable). Now it is possible to build Haiku host tools only, without targetting a specific architecture. This is used by the package buildbots as they need the generic “package” tool, but nothing arch specific.

humdinger reworked the layout of Tracker info window, to fix some overlapped text depending on font and font size.

axeld fixed a memory leak in bfs.

tqh tweaked our ACPI code to fix all warnings, and enabled Werror so the compiler will now complain if someone adds warning-generating code in that area.

Skipp_osx added case insensitive comparison methods to BString, and used them to fix some bugs in the legacy PackageInstaller (to install SoftwareValet packages from BeOS).

kallisti5 worked on preparing support for AMD Ryzen CPUs (new cpuinfo fields) and reviewed XHCI/USB3 code for potential issues.

nielx worked on updating our Pootle install and cleaned up some problems with deprecated catalogs, missing languages, etc.

Lioncash fixed some memory leaks and late NULL pointer checks.

jua made many improvements to our FUSE layer, and used it to port and extend the fusesmb filesystem, allowing to access Windows network shared drives (or anything using the same protocol). This is nicely integrated in the Network preferences thanks to the add-on support there.

Kyle Ambroff helped investigate and fix a freeze of the network preferences, when trying to configure a network in static mode.

Are we released yet?

There are some good news about the beta1 release this month.

First, not mentioned above are a lot of package updates in the repositories, in order to keep them close to the release branches at haikuports.

But more importantly, the move of the haiku website and forums to new hosting was completed, freeing some space on our servers. kallisti5 used that space to set up a new buildmaster instance (much better than the half disassembled laptop in my basement I used for testing until now).

We are now working on connecting everything together: exposing a web interface showing the status of the builders, making changes to haikuports git repos trigger an automated build of the changed packages and update of the repos, etc. Having the server hosted on Haiku controlled infrastructure helps collaborating on that and should also make the builds faster, as the build master can upload packages to the slaves, and download from them, at a more decent speed than my home internet access allowed until now.

The spring is comming, the GSoC applications closed just today, and it is time for a new monthly report!

This report covers hrevs 50989 to 51063

Drivers

tqh is working on improving wifi performance. He identified some sub-optimal code in the FreeBSD compatibility layer which he replaced by much simpler and faster functions that the compiler can actually inline. This improved performance of all IO access to network devices, fixing some real time problems.

tqh also tweaked some DHCP timings to have a faster initial setup of wifi connections.

Kallisti5 added support for AMD Ryzen CPUs.

Hy Che (one of our GSoC applicants) fixed mounting of btrfs volumes. Our code was quite old and did not handle some features properly.

Kallisti5 updated acpica to the latest release, possibly fixing some issues with power management, power buttons, and other ACPI things.

Kallisti5 also fixed some PCI IRQ routing problems to get his new motherboard working.

wangxingdsb (another GSoC applicant) made some cleanups in our ext2 driver to prepare for ext4 support.

axeld fixed an issue in the VFS that was causing rather frequent panic on our package build slaves.

Network apps

Dave Thompson fixed handling of the INBOX folder for IMAP.

Kevin Wojniak fixed an issue with HEAD requests in PoorMan, and cleaned up some of the code while he was at it.

Alexander Andreev (one of our GSoC applicants) fixed a KDL in the IP stack, caused by mixup of different hash tables.

User interface

PulkoMandy did some rework of the support for font fallbacks. The support is still rather primitive, but it should behave a little better with the Noto font used now, which comes packaged as multiple font files for different scripts.

Waddlesplash merged in several patches from AGG, our graphics rendering library, of which development has resumed on the 2.4 branch (there was a 2.5 release some years ago, but under a different licence so it didn't gain much traction).

Dariusz Knociński fixed the layout of the df command line tool, to have enough space for mount points of the package managed volumes.

Axeld fixed some drawing glitches in the BBox code.

Media

Barrett continues his work on the BMediaClient.

Vivek Roy (one of our GSoC applicants) added some error handling in MediaConverter, which will now complain if it can't write to the output directory.

Humdinger fixed a crash in the MIDI preferences when the settings file was missing.

PulkoMandy fixed an issue in the ffmpeg plug-in preventing to play some MP3 files.

Package management

The work on package management continues, mostly on the side of the "Software Updater". This is a graphical tool to update your system.

Anirudh (one of our GSoC applicants) made a small change to remove "Haiku" from the text, when distro compatibility isn't enabled.

Brian Hill is doing the bulk of the work here and merged in several UI cleanups

Other stuff

mirabilos (the main developer of MirBSD) submited a patch to get our /etc/profile to play well with his mksh and other non-bash shells.

PulkoMandy updated the WebKit port to merge a few month of changes from upstream. This is still a work in progress, no release yet.

Once again I am out of catchy taglines to introduce the monthly report. To apologize for that, I updated the statistics about Haiku git repository, and also added a similar statistics page for haikuports.

This report convers hrevs 51064 to 51139.

Network

A lot of activity on this side with no particular reason, with kallisti5 and waddlesplash working on the network preferences and underlying stack, towards support for VPNs and PPP connections.

Axeld also did some work in the network stack, fixing some locking issues and a memory leak.

Ayush (one of our GSoC applicants) fixed getaddrinfo to accept IPs in unusual formats with only 3, 2, or 1 number, as required by POSIX.

Media

PulkoMandy removed some annoying assert() in the ffmpeg decoder, which were there for safety, but prevented it to play some videos that would otherwise work just fine. The list of problematic videos continues to shrink, but there are still some files we get in trouble with. In at least one case however, MediaPlayer is able to play a video that no other media player (including on other platforms) could handle.

Barrett replaced the old playfile, playwav, playsound commands by a single media_client test application, making use of all the new features in the Media Kit he added over the past year.

Drivers

PulkoMandy made yet another fix to the intel_extreme driver, for another case of failed initialization and black screen.

tqh started investigating our Elantech touchpad driver, which is currently disabled and incomplete. This driver would provide multi-finger gestures on such touchpads (apparently less common than the Synaptics one, which are already supported).

kallisit5 fixed the ACM (generic USB serial) driver to handle some devices with a broken USB descriptor, allowing him to use an USB modem to test the PPP stack mentionned above.

He also continues investigating problems in our XHCI (USB3) driver, this time by comparing to the one in Google's Fuchsia, which is a quite clean implementation.

Filesystems

Axeld fixed some compatibility issues with BeOS in our BFS implementation. We allowed some things that BeOS does not handle the right way.

Axeld also added unit tests to KPath, the kernel-side counterpart to BPath. The tests allowed to uncover a bug, which he also fixed.

The GPT partitionning system now has a lower score when only the start or end of the disk has a valid partition table. This allows erasing just the start of the drive with another file or partitionning system to override GPT, which would otherwise continue to be visible until the backup table at the end of the drive would be erased as well.

User interface

BListView can now more easily be used inside a BScrollView when horizontal scrolling is needed. It did already configure the vertical scrollbar automatically, but the horizontal one was never set. This was mostly visible in the Locale preferences.

Brian Hill continues his work on the Software Updater, which is now included in the default image, and almost ready for production. This tool will be used to notify the user when updates are available in the repositories, and automatically apply them. No need to go to pkgman in the command line for this anymore.

Humdinger tweaked the decision to use black text on the desktop when the background color is light.

Launch daemon

It is not possible anymore to crash the system by restarting launch_daemon manually.

The launch_daemon creates some important directories on startup, allowing shared memory to work again.

System headers and C library

elf.h has a more complete set of ELF architecture constants, allowing to compile tools like avrdude without the need for a 3rd-party libelf.

PAGE_SIZE is now only defined if the _XOPEN_SOURCE feature is enabled. This allows plain standard C programs to use the name PAGE_SIZE for other purposes.

abort() will now call debugger(). This means applications which end up there (by calling it directly, or because of an uncaught exception) will now offer the usual crash dialog and option to save a debug report, instead of just disappearing without any warning.

_POSIX_SEM_NSMES_MAX is now 256, allowing Python3 to use more semaphores.

PIPE_BUF is now defined in limits.h as required by POSIX.

The runtime_loader can handle library sonames of more than 32 characters

Tracker

Owen (one of our GCI contestants this year) and waddlesplash worked together on various fixes and improvements to Tracker.

This work resulted in fixes to keyboard selection, freeze of BFilePanel when using some keyboard shortcuts, and allowing multiple selection from the keyboard while in a single selection file panel.

Outside the tree

Not all the activity around Haiku results in commits to the main git repository.

At HaikuPorts, Begasus is working on updating many recipes still using the old "bep" syntax from BePorts days, and making sure the software builds and runs on Haiku.

This month was also the the time for our GSoC mentors to review the GSoC applications and pick the selected students. The results will be announced by Google during the week.

Are we released yet?

Another step towards beta 1 was reached this month, with the official package buildmaster now being ready to run both for x86_64 and x86_gcc2. The build master is now set up on Haiku's own server and will soon start providing a package repository for use with Beta1. You can watch the build bots run through the packages:for x86_64 and for x86_gcc2.

We are now looking for more machines building packages, in order to make the process faster and more reliable. If you own a machine that you can keep online and running Haiku, and would like to contribute it, let us know. In particular, if you own one of the Mac Minis donated to Haiku by Mozilla, this is what they should be used for.

The next steps towards a release are connecting the buildmaster to git hooks on haikuports so it automatically builds recipes added there, and publishing the resulting package repository for testing by Haiku users. If the repository works well and there are not too much regressions from the existing ones, we will then proceed to making it the default repository for the beta1 branch.

Hello everyone

My name is Vivek (Trac: vivek-roy, IRC: vivu). I have been selected for Google Summer of Code 2017 to work with Haiku on the project 3D Hardware Acceleration in Haiku.

The Mesa renderer in Haiku presently ventures into software rendering. Haiku uses software for rendering frame buffers and then writes them to the graphics hardware. The goal of my project is to port Direct Rendering Manager (DRM) Driver for i915, from the Linux kernel to Haiku with the help of DragonflyBSD’s Linux Compatibility layer, so that those drivers can be later extended to add OpenGL support (Mesa3D) for hardware accelerated 3D rendering.

Present Scenario

Haiku presently uses software rendering to draw graphics to the screen. The rendering is done to a frame buffer which is then written to the graphics hardware’s memory. This offers acceptable performance for 2D rendering and to some extent light 3D rendering, but it is not good enough for intensive 3D applications like games that require rendering large amounts of 3D primitives while maintaining high frame rates. Hardware acceleration is critical in such cases.

3D Hardware Acceleration

For achieving hardware accelerated 3D rendering, the following things are needed:

• Direct Rendering Manager (DRM): Direct Rendering Manager or DRM is the interface for the software to communicate with the graphics hardware of the device. It consists of two parts - a generic DRM Core and a hardware specific DRM Driver. DRM core provides the basic framework where different DRM drivers can register, and also provides to user-space a minimum set of ioctls with common, hardware-independent functionality. A DRM driver, on the other hand, implements the hardware dependent part of the API, specific to the type of GPU it supports; it should provide the implementation of the remaining ioctls not covered by DRM core, but it may also extend the API offering additional ioctls with extra functionality only available on such hardware. It is responsible for handling sensitive aspects like hardware locking, access synchronization, video memory etc.
• libDRM: It provides the user-space with an API that can be used to submit commands and data in a format that is adequate for modern GPUs, which effectively allows the user-space to communicate with the graphics drivers.
• Mesa: Mesa is a free software implementation of the OpenGL specification, and as such, it provides a libGL.so, which OpenGL based programs can use to output 3D graphics. Mesa can provide accelerated 3D graphics by taking advantage of the DRM architecture to gain direct access to the underlying graphics hardware in its implementation of the OpenGL API. The very first step to achieving 3D Hardware Acceleration is porting DRM to Haiku.

DRM Driver and DRM-Auth

DRM drivers reside in the kernel-space, so the user-space programs must use kernel system calls to request it services. The drivers itself are kept relatively simple and well tested because any error in the kernel-space will cause a full system crash. In order to make DRM drivers, we will also need to make a DRM Core which will export several interfaces to user-space applications. Together DRM will be responsible for memory management, context management, DMA operations, AGP management, vblank control, fence management, memory management, and output management.

DRM also implements an authentication system for security purposes as well as concurrency issues to limit the number of user-space processes to one per graphics device. To implement this restriction, DRM limits such ioctls to be only invoked by the process considered the “master” of a DRM device, usually called DRM-Master. Any attempt to use one of these ioctls without being the DRM-Master will return an error. The display server is usually the process that acquires the DRM-Master status. For the remaining user-space processes the way to invoke some operation on the DRM device is called DRM-Auth. It is basically a method of authentication against the DRM device, in order to prove to it that the process has the DRM-Master’s approval to get such privileges. DRM-Master privileges are granted on a first-come-first-serve basis. Whichever process demands first, is granted the DRM-Master privileges. What I intend to do is make the app_server the first process which will request for DRM-Master privileges. Thus, every other process will have to work through the app_server (indirect rendering) or demand restricted ioctl privileges using DRM-Auth from the app_server to be able to directly invoke libDRM functions.

The Project

Porting kernel drivers itself is a lot of work to be completed in 3 months time. Also, the DRM Core has to be ported, which will provide the basic ioctls and allow the different DRM Drivers to structure themselves on top of it. So what I expect is a working DRM Core and i915 DRM driver with a working framebuffer by the end of this summer. This also includes the DRM-Auth mechanism of authentication which checks whether the user-space processes have the permissions of the DRM-Master. The reason for choosing i915 is that it covers a lot of Intel GPUs. Haiku, being an operating system targeting personal computing, is expected to run on a lot of laptops, and a lot of laptops use Intel’s integrated GPUs which in a lot of cases is the i915. Also, I do have an Intel GPU which is covered by i915 and thus I will be able to check/debug the drivers I plan to introduce.

References

• PDF copy of my GSoC Proposal
• Direct Rendering Manager wikipedia.org
• Direct Rendering Manager (DRM) freedesktop.org
• Introduction to the Linux Graphics Stack

What happens when you combine 337 students, 20+ mentors, and an endless volley of tasks? During the time from November 2016 to January 2017, 368 Haiku tasks were successfully completed. The seventh year of Google’s Code-In, and the seventh for Haiku as a mentoring organization was a grand success.

Students from all around the world aged 13-17 worked with the project mentors on improving Haiku during the 7 weeks of the contest. They coded applications, designed artwork, tested software, and wrote recipes, and more than anything else, had fun.

Out of the 10 students who completed the maximum number of tasks, finalists and grand prize winners were picked collectively by the diligent team of Haiku’s 20+ mentors.

Haiku’s Grand Prize Winners

• Raefaldhi Amartya Junior from Indonesia
• Vanisha Kesswani from India

Haiku’s Finalists

• Tudor Nazarie
• Stephanie Fu
• Dmytro Shynkevych

Rest of Haiku’s top ten finishers

• Tejpunj Raju
• Dacian Florentin Florea
• Punsith Ratnayake
• Owen
• Winston Durand

Congratulations finalists! Safe travels, grand winners! We are thankful for your precious contributions and will be delighted see you continue to contribute even after the program. This year Jessica Hamilton will make the trip to meet the winners as they both picked her as the mentor they would like to meet.

Haiku had an impressive growth in the number of students:

To list some of the students’ achievements:

• A map application, and a music manager for Haiku were coded.
• Over 50 recipes were written for HaikuPorts.
• Around 15+ recipes were de-linted.
• A dozen QA test plans were documented.
• Icons for Becasso, Hexvexed, Freeciv, Rocks ‘n’ Diamonds, and 2048 were created, as well as more icons to be used in the Weather application.
• WhereMyMouse and CapitalBe were updated to use the Layout Management.
• Addition of missing email provider information.
• Addition of Pthreads barriers implementation to Haiku.
• Articles converted to markdown for the new Haiku website.
• Video tutorials were prepared.
• Presenting Haiku at their schools or other local groups.
• Supplying icons, screenshots, and categories for packages in HaikuDepot.
• and much more!

I hope that despite probably being the best of their age in their field, the winning students will stay humble, and hunger for new knowledge.

So congratulations and thanks to all our hardworking students and their mentors, and especially Scott McCreary who once again shouldered the responsibility of administrating Haiku’s GCI participation.

I am Deepanshu(Trac: digib0y IRC:digib0y), I am one of the seven students selected for GSoC this year from Haiku. I will be working to add Harfbuzz support this summer.

Quick intro:

I am an engineering student of Christ University, India. I am pursuing a degree in Bachelor of Technology in Computer Science and Engineering.

I have been a previous Google Code-In student where I worked with Haiku for the first time, I can recall the first time I ever connected to an IRC channel during GCI 2014; it was both my interest in the GCI task and my attraction to the positive, friendly environment on #haiku that convinced me to continue working with Haiku.

Project Description:

Text is the primary means of communication in computers, and is bound to be so for the decades to come. With the widespread adoption of Unicode as the canonical character set for representing text a whole new domain has been opened up in a desktop system software design.

Haiku got internation support in 2009(Thanks to Pulkomandy!). However, it only works for languages with layouting rules similar to the latin alphabet, other scripts such as arabic, devanagari, or CJK, have several problems ranging from minor(word breaks at expected places) to unreadable text(characters rendered in the wrong direction, or not rendered at all). The goal of the project is to improve the situation, with a focus on Devanagari which is a script shared by over 120 languages.

HarfBuzz uses GLib for Unicode functions (to get few Unicode character properties an normalisation). It can also use ICU for this, or a small bundled library called UCDN. If HarfBuzz is built without GLib or ICU, it will use UCDN. Alternatively we can provide the Unicode callbacks to interface with something else. However, we will be using ICU which is in the core of Haiku.

FreeType is used for loading fonts and glyph metrics etc. We can also build HarfBuzz without FreeType and use HarfBuzz's internal font functions.
Font rendering will be reworked to use the HarfBuzz library (The Harfbuzz package contains an OpenType text shaping engine), instead of just Freetype, providing numerous supports.

What to expect on completion of project:

What and When to expect:

Community bonding period(May 4 - May 30)

Hello World.

I’m Anirudh Murali (Trac: anirudh; IRC: anirudhm), from the southern region of India. I thank Haiku for selecting me as one of Google Summer of Code 2017 student. I’ll be working on the idea: “Preferences GUI Refactoring” this summer along with my mentors: waddlesplash and Sean Healy.

As of now, if one has to access any Preferences, a right click on the Deskbar, and accessing it with the submenu of Preferences, and still people who are new to Haiku end up selecting the wrong preferences option, atleast it happened for me. Even though Preference options are labelled, new users who aren’t familiar with the terminology take time to find the right option. What I intend to do for this summer is to revamp the access method of Preferences.

Preferences Panel

A Preference Panel containing shortcuts to every preference options, sorted under respective categories. For example, Keyboard, Mouse, Trackpad preferences would be coming under Input section and similarly other options as well.

Here are snapshots from Windows’ Control Panel, macOS’ System Preferences and Ubuntu’s System Settings. Haiku’s Preferences Panel consisting of all preferences listing would make things simpler and easily accessible. One can still access the menu based Preferences listing and open the Preferences in the form of window which is present as of now.

Here’s a mockup of what Haiku’s Preferences Panel would look like (subject to change):

Nearby to every preference option, either in a side pane or nearby the option, a quick toggle of most used preference will be added. Example: Enabling/Disabling Trackpad with a checkbox in the central panel.

Search Implementation with Trie

Along with this, a Search bar to filter the displayed Preference listing. Every preference listing will be assigned with set of meta keywords which will include the options present inside the preference listing, and a Trie with all the keywords pushed in the tree. Using this method for traversal will allow us to fetch results in O(m) timeframe where m is the length of the string entered by the user.

Upon user’s query through the Search bar, depending upon the characters he/she enters, the string must be compared with the trie entries of multiple preference panels and then the preference panels containing the option will be highlighted, similar implementation in macOS’ System Preferences.

This is what I’ll be building this summer, I have plans to work on wildcard search feature, something similar to macOS’s Spotlight search, I’ll work on these after GSoC is done. Let’s see how things proceed.

Citations:

• https://github.com/michaelbull/c-dictionary-trie
• http://theoryofprogramming.com/2015/01/16/trie-tree-implementation/

Introduction

Hello I'm Akshay (IRC/Trac: akshay, GitHub: AkshayAgarwal007) from Kolkata, India. I would be working on developing a native Calendar Application for Haiku as a part of Google Summer of Code 2017. My mentors for the project are Scott McCreary and Kacper Kasper. I am very excited for this project.

Why a Calendar Application? Isn’t there already one?

A Calendar application is a must have application for any operating system and would be beneficial for end users as well as developers. Haiku doesn’t have a calendar application yet. There are a few existing 3rd party Calendar apps out there, but none are close to a simple and elegant Calendar app that an end user would like to use, with all the necessary features a modern Calendar app should have.

Also the existing ones (Borg, A-Book, Organizer, Eventual) have issues of their own and hence I would be writing one completely from scratch, referring them wherever required.

Features the Calendar app would have

I reviewed a bunch of Calendar apps on other platforms and came up with a subset of necessary features to be implemented:

• Create, modify and synchronise events.
• Set event reminders.
• Display Day, Month Calendar views.
• Set event color.
• All day long events, recurring events.
• Google Calendar integration.
• A minimal look with intuitive UI design.

Future features

These are the features that I plan to work upon after GSoC:

• Support for alternate calendars.
• Categorize events.
• Search for events.
• Week, Year View.
• Timeline view for a single day/week.

Google Calendar Integration

This is one of the most important feature the Calendar app would have. It is a must have so that the users can get their events synchronised between devices and other platforms they use. Since almost all the calendar apps have a Google Calendar integration, this would be the best way to achieve event synchronisation.

A Google Calendar API client would be written using Haiku APIs and would be integrated into the application.

Wireframes

These are some tentative designs for the Calendar application.

Add Event

• I would be coming up with a final design for this, incorporating all the options required for supporting recurring events and an event color picker.

Day View

• All day long events would be pinned to the top.
• Right click on an event will open a context menu with three options (View, Modify, Delete)
• View will open the entire event details in read only mode. Modify and Delete options would also be available inside View mode.
• Using the calendar widget in the side panel, user can navigate through months. Buttons to navigate one month at a time can be replaced by a dropdown to simply select month+year for user’s ease.

Month View

• Clicking on a particular day in month view will show events of that day in side panel.
• Again the buttons to navigate one month/year at a time can be replaced by a dropdown to simply select month+year for user’s ease.

I would be finalising the user interface design in the upcoming week and suggestions from you all would be highly valuable for the same.

Icons

I plan to use the following icons in the application (icons be Michele Frau [Zumi] are really cool):

• Main Application icon:
  http://zumi.xoom.it/myhaiku/3rd%20party%20apps/schedule%20r3.png
• Add Event toolbar icon:
  http://zumi.xoom.it/myhaiku/btoolbar/document%20open%20recent.png
• I would be needing a Calendar toolbar icon similar to one in the wireframes.

Apart from this I would also be working on to improve date/time classes in Haiku as required for the application.

References

• PDF copy of my GSoC Proposal
• Eventual Documentation
• GNOME 3 Calendar App Design

Hello everyone,

My name is Hy (Trac: hyche, freenode IRC: ugen), and this first blog is about my introduction and Btrfs. This is the first time I participate in Google Summer of Code, I also know Haiku through this event. My project in this summer is write supports for Btrfs and my main mentors are mmu_man and tqh (Fredrik Holmqvist).

During the community bonding period, I will

• Set up my development environment (userlandfs and fs_shell).
• Dig into the codebase to know more about Haiku kernel, how other support filesystems work and derive it for Btrfs.
• Try to fix issues to get me familiar with the existed works.

Btrfs

Btrfs (B-tree filesystem) is a filesystem uses B+trees as its main on-disk data structure. It is based on Copy-on-Write (CoW) principle which means it does copy only when a write is necessary. The following works will be implemented to bring off write features:

• Adding more Btrfs structures.
• Adding/Modifing tree manipulations (splitting, finding, CoW, etc).
• Implement file/directory operations.

That's all for now. You can read more details in the reference section. Bye and have a nice day!

References

• My GSoC proposal
• Btrfs wiki

Introduction

Hello everyone! I'm Joseph 'Calvin' Hill, (irc nick: return0e) a third year computer science student at the University of Hull and one of the 7 GSoC students participating with Haiku. I'm also a active contributor to the HaikuPorts organisation, by porting over useful cross-platform software found on other platforms, to be made available on Haiku. This summer, I'll be porting the Swift programming language to Haiku with my mentors Jérôme Duval 'Korli' and Julian Harnath 'jua', with the intention of merging these changes upstream.

Project Description

Haiku has ports for several modern programming languages available to developers, but some of them are in the form of version specific patches, which haven't been upstreamed yet. As new releases of programming languages come by, maintenance of platform support through patches becomes increasing difficult and Haiku misses out on official support for those languages. By working directly with the Swift community, this task aims to add Haiku support specifically for Swift and its sub-projects in the effort to not only improve Haiku's programming language diversity for future developers, but to make swift a possible alternative programming language to develop Haiku apps in.

Once the compiler and its standard library is built, it will be possible to compile and run Swift code on Haiku which will then allow developers to build libraries and applications that are written in Swift. If this is achieved early, the other utilities Swift uses such as debugging/REPL support (LLDB), package management and its testing frameworks will follow afterwards. The following will be done within the duration of the GSoC:

• Building swiftc and its standard library.
• Porting the core libraries to Haiku.
• Ability to compile/run simple swift programs.
• Run tests against the newly built standard library and swiftc.

As this task only focuses on the bare-minimum needed to get swift functional, I will further maintain Haiku support after GSoC and include:

• Porting libdispatch.
• Package Manager support on Haiku. (requires llbuild)
• Support for LLDB debugging.

About Swift

Swift is a general-purpose programming language built using a modern approach to safety, performance and modern software design patterns [1]. It was recently open-sourced by Apple in 2015 with goals such as being a C/C++ and Objective-C alternative, maintaining source compatibility with future releases and increasing portability with various platforms by leveraging the LLVM compiler for code generation and optimisation of source code. Swift is commonly used in the iOS/macOS communities for writing GUI apps, but it is also suitable for other scenarios, from teaching programming to server-side development.

It has several language features such as:

• Closures (unified with function pointers)
• Optionals
• Generics
• Built-in REPL for debugging (LLDB)
• Functional programming patterns support
• C and Objective-C interoperability via ClangImporter

Swift also provides additional libraries for functionality not included in the standard library. More information about them can be found here: [5]

Goals for next week

During the community bonding period, I will be in contact with the Swift team about which version I should port, as Swift 4 is scheduled to be released in late 2017. I'll also be discussing with my mentors on adding slight changes to the existing LLVM port in order for Clang to build itself, as using g++ to compile Swift is not supported. In the first two weeks (May 4th - May 18th) the following will be achieved:

• Add initial x86-64 platform recognition in the build script.
• Add Haiku as a standard library target.
• Haiku support for validation tests.
• Complete build-script support for Haiku. (Includes building only with LLVM and Clang)

I’ll be continuing to patch the build-script for initial Haiku support and I aim to get the build-script patches upstreamed in late May / early June.

References

Hello Haiku!

My name is Ayush (nick: a-star). I am really glad to have been selected for GSOC 2017 and I will striving to optimize the tcp implementation of Haiku this summer.

A little about me

I am in the junior year of computer science and egineering at VITCC, India.
I am a profound Linux user. I have gained formal education on the subject while pursuing the Redhat certifications. I have always been fascinated with the intricacies behind the scene, the internal working of an operating system which makes you believe that the trivial program of ‘Hello world’ is actually trivial.

Project Motivation

TCP and IP together form the most ubiquitous pair of protocols used in the implementation of the internet stack. It’s really important to get them working at full throttle. When I was going through the list of issues at Trac, a lot of them complained about the network:

• #1958, #12815 - slow speeds during file exchange using ftp, scp, sftp
• #10747, #11066, #1143 - network related KDLs
• #1073 - requesting implementation of path MTU discovery
• #2967 - bug with getpeername() that succeeds on unconnected sockets
• #1994 - requesting implementation of urgent data for TCP

Current state

The code for TCP can be found here. It provides for all the mainframe syscalls like: bind, listen, sendmsg, etc. Needless to say, all the salient features of tcp like checksum, window, ack, fin are well implemented.

So what we have is a up and running tcp implementation but it lacks much of the extensions suggested by rfc 7414 like the timestamps option, window scale option, round trip time mechanisms involving timestamps, appropriate byte counting (ABS) for congestion control, Robust header compressions, etc.

I haven't had the time to go through the complete code for TCP so if I mistated something above, well sorry for that. I am currently busy with my college exams. They are ending on 24th of this month and only after that will I be able to completely devote my time to this project.

What to expect

For this month, I am mainly focused on porting a TCP profiler such as tcpdive to haiku. It will be necessary to benchmark the improvements I will be making in the subsequent months. There are other alternatives to tcpdive like tcpstat and google's packet driller . Let's see which one turns out to be easily portable to Haiku. If anyone has any suggestions regarding any other profiler, I would be glad to try and port that as well.

During summer I will be implementing each section of rfc 7414 one after the other. There are majorly 3 sections and I will have 3 months to work on them:

• Section 2: describes the very fundamental functionalities of tcp.
• Section 3: Strongly Encouraged Enhancements - describes recommended TCP modifications that improve performance and security
• Section 4: Experimental Extensions - describes those extensions that are not widely but are gaining popularity

To more details on the timeline, you can refer to my proposal.
Thnx…

Hello Everyone!

In my previous post I introduced you all to the Calendar Application project that I would be working upon as a part of GSoC 2017. In this post I would be focusing on my first two weeks of the community bonding period.

Getting to know people

The first few days were spent in exploring more about the Haiku community, getting to know the mentors and fellow students, and learning in details about their project through their blog posts. All the projects are geared to take Haiku forward and it would indeed be an awesome summer for Haiku.

I would like to thank the community members for their feedback on my introduction blog post. Their excitement for a Calendar application makes me even more excited to develop a lovely Calendar application for the community.

Haiku has a beautiful community. All the members are cool and helpful, I would like to mention about a few of them.

• PulkoMandy: He's always there for you. Any issue you face and he'll resolve it in seconds. I am getting to learn a lot from him.
• Scott: Very helpful and motivating, will always point you to the right direction. I have a nice time talking to him.
• waddlesplash and humdinger: Always ready to help, and have helped me a lot with my PRs to apps in Haiku Software Archives.
• anirudhm, digib0y and vivek: Awesome guys, it's nice discussing stuff with them.

Things successfully done

I worked on fixing style formatting issue with BDurationFormat and BTimeUnitFormat classes which are a part of Locale Kit.

BDurationFormat is used to format time intervals in a localised way i.e it takes in a time interval and converts it to a string such as "10 hour, 2 minutes, 28 seconds". There are two formatting styles supported: full name and abbreviated name. For example, for English, the full name for hour duration is"3 minutes", and the abbreviated name is "3 min".

But the abbreviated style didn't work because the BTimeUnitFormat class didn't incorporate the same. I submitted a patch to resolve this and it got successfully merged (thanks to PulkoMandy). The abbreviated style works fine now.

Screenshot of TimeTracker app showing abbreviated style:

Issues that I faced and how I resolved them:

• I faced difficulties in pointing to the changed headers (rather than the one in system/develop) while compiling the test application. I used the -I flag with gcc pointing to the changed headers to get it done.
• I was not able to link the test application to the newly built libbe.so. I fixed it by adding the newly built libbe.so inside a lib folder next to my executable.
• For getting a new build of libbe.so after my changes to files in the locale kit, I simply did jam libbe.so from within root of my Haiku clone instead of compiling the entire source. Initially I was compiling the entire source and it was taking a lot of time.

I was able to resolve the issues quickly with PulkoMandy's help.

The Calendar App

I have started experimenting with the GUI. I am currently putting my code here:AkshayAgarwal007/Calendar. I started with adding a simple toolbar to a window and adding some vector icons to the toolbar buttons.

Issues that I faced and how I resolved them:

• I took one of the icons fromhere, exported it as HVIF Rdef using Icon-O-Matic, copied the hex representation into a .rdef file. Loaded the vector icon into a BBitmap object and passed it as a parameter to BToolBar::AddAction(). But the icons were not aligning properly in the toolbar buttons.
  
  The reason for the same was that the icons have transparent area to the right and bottom i.e they are 32x32px in size but only a 22x22px area in the corner is used.
  
  So I rendered the icon to a 32x32px bitmap and copied the required region in the corner to a 22x22px bitmap using BBitmap::ImportBits(). Finally, it got aligned perfectly.


• Also I wasn't the handling the BBitmap object properly. BBitmaps are expensive, since they create a full drawing context and thread in the app_server. B_BITMAP_NO_SERVER_LINK flag can be used while creating a BBitmap object to make it cheap to create but such a bitmap is not drawable. BBitmap::ImportBits() would work fine with this bitmap.
  
  The following two commits can be helpful for anyone facing similar issues:AkshayAgarwal007/Calendar@3f565bd
  AkshayAgarwal007/Calendar@8b7128f

Stippi and PulkoMandy helped me in getting it done right.

The icons are just placeholder icons.

Next I would be doing some more experimentation with the GUI, and dive into doing some base work/research towards the Google Calendar integration and storage part. Also would be working towards finalising the left mockups.

Learnings

• Bitmaps are expensive and should be handled properly. While creating a BBitmap object, B_BITMAP_NO_SERVER_LINK flag can be used when calling the constructor to make it less costly, but they are not drawable.
• i18n and L10n in general, ICU, and Haiku Locale kit.
• Writing good software (source:Haiku HIG).
• Compiling Haiku components and testing them.

Altogether, it's a nice experience till now, and I am enjoying working on the project very much.

Hello again

My previous blog post was a brief introduction to my project - 3D Hardware Acceleration in Haiku. The second week of GSoC demands the second post and so here we go.

Bonding

Well, there hasn’t been a lot of coding work in the last two week, as much as I would have liked, primarily because I wasn’t well for a couple of days. But, I did do what I am supposed to do at this period, i.e. “Bonding with the Community”.

I was regular to the IRC before GSoC started, so I was already familiar with the names. Last two weeks I came to know the people even better. Adrien (PulkoMandy), Fredrik (tqh), James Taylor (Duggan) and Alex (kallisti5) have helped me a lot, among others. I also made friends with my fellow interns - Akshay (akshay), Anirudh (anirudhm), Ayush (a-star), Deepanshu (digib0y), Hy (ugen) and Joseph (return0e). Good luck to all of them.

Progress

I started off, thinking of trying to generate an include dependency graph (every node in the graph represents a header/source file in the project and every directed edge from file1 to file2 indicates that file1 has included file2). The motivation was if I could generate such a graph, then I could easily move up from the leaf nodes to the highest-connectivity node in the graph, without breaking the compilability of the source. I tried to generate the graph using Doxygen, running it on DragonflyBSD’s sources.

It looked good for some files, like drm_atomic.h shown below.

But it failed for drm_auth.c (drmP.h has a fairly large list of dependencies, which I expected to see in the graph, but unfortunately did not).

I asked people on the mailing list for help, and surely enough, received a lot of it. PulkoMandy suggested some more tools, but none of the seemed to work the way I wanted them to. At last, on PulkoMandy’s and Duggan’s suggestions, I decided to add files to the source and rely on the compiler generated error files to proceed.

I have set up the development environment. The Jamfile for building DRM is ready and populated with the files required for DRM. The way I am moving forward from here is as follows:

1. Uncomment a file in the DRM Jamfile, so that an attempt is made to compile it.
2. The compiler complains about some missing file.
3. Try to add the missing file to the source tree.
4. Repeat

At some point, when everything actually compiles, then we will start the testing phase, as successful compilation does not mean everything will work.

Hamish Morrison (hamishm) started working on DRM Drivers in Haiku about 2 years back. His repository^[1] has been the starting point of my work. Duggan integrated hamishm’s work into his fork^[2] of Haiku’s latest code base and cleaned up a few files. I wanted to take things one-file-at-a-time. So, in my fork^[3], I started adding the source files and headers that are absolutely required for DRM one-by-one from Duggan’s repo and DragonflyBSD’s Linux Compatibility Layer, tweaking them as required.

You can track the changes I make by looking into the ‘drm’ branch of my fork^[3]. I have just started with this iterative process and I do not expect it finish quickly, but the effort is being made to be done with it as quickly as possibly, the road ahead is long.

References

1. Hamish Morrison’s haiku-drm repo
2. James Dewey Taylor’s fork
3. My fork’s drm branch

Hello everyone,

This is my second report about my project "Adding write supports for BTRFS". There hasn't been much coding in this week and previous week, just some researchs, some style fixes in btrfs code base, and I have managed on setting up fs_shell for btrfs, or now you can say btrfs_shell, based on bfs_shell work. fs_shell is a framework containing all the kernel emulation and the user and scripting interface (Thanks Ingo for the info), this allows to compile and run filesystem (Haiku's, for example btrfs) in userland under Linux or any host systems that can build Haiku.

With fs_shell, now I can test btrfs in many files with different size after only 5 second of building. Initialy, I had to build btrfs source, made hpkg for it, move the package to /system/packages and restart to get it kicked in, luky for me that Haiku took few seconds to boot. Thanks axeld for recommending me fs_shell, and pulkomandy for helping me compile zlib for btrfs_shell and fix code styles.

Also in this week, I learnt more about Git and Jam. Before attending GSoC, I only knew git clone, commit and push with no arguments. The first blog of my introduction is also my first pull request. Now I know I should sync my local repository with the upstream haiku repository with git pull --rebase instead of normal git pull, this help clean the git history. Moreover, git commit --amend to fix the HEAD commit, or git rebase --iterative to fix previous commits that are before HEAD. I recommend this link for who want to learn about Git. With Jam, I know more some rules, some Haiku's built-in variables for example HOST_LINKFLAGS, it help me link zlib to compile btrfs_shell.

Next week works

Because I have set up my development evironment sucessfully, next I will continue dive into code base, read more about btrfs to understand more about it and will do some code if necessary. I made a branch for my work in my Haiku’s fork, still there is nothing there. If someone is interested, you can have a look at anytime and give me some comments if possible.

That's all, thanks and have a nice day, see you again next week.

Hello everyone,

As you already know I am working on HarfBuzz Support on Haiku this summer. You can find my introduction post here. In this post I will be you a brief details of my last 2 weeks with Haiku.

Getting to know people:

Project update:

Hello World.

This is an update to my previous blog post which dealt with the introduction to the GSoC project which I’ll be working this summer - Preferences GUI Refactoring. It’s been two weeks since the first post went live, so here’s the report for the weeks after that. This being the Community Bonding period, I pretty much did what the title says. Got to know about fellow GSoCers, they really are friendly and helpful. Myself, my mentors (waddlesplash and Sean), PulkoMandy, jua_ and humdinger had our first meeting, infact a very long meeting. The meeting was more of a discussion on the last blog post’s comments. Last blog post received so many suggestions and constructive criticisms, let me thank everyone for their valuable feedback. We did take everything into concern. The major changes that are done to the project after the blog post:

The control panel (we call it SuperPrefs for now) will be segregating preference panels category wise, along with an inner search implementation (as explained in last blog post). We’re dropping off the Preview pane, at least for now, it doesn’t seem to make many changes and there were more major things to be addressed. Incase you missed the last post, here’s a link to that. Note that SuperPrefs is not the final name; the final name will probably just be “Preferences”.

Hurdle #1:

Last week, messed up my Mac by updating Xcode via App Store. I’ve never had problems with updating apps through App Store until last week. I had to pause my download couple of times in between the download progress, and resume it. I’m not sure whether it was because of that, the Command Line tools got messed up, and I wasn’t able to even build Haiku. It seems that the compiler got crashed. There’s even an article about this stating why not to update Xcode through App Store. Xcode Upgrades: Lessons learned. The solution was to completely uninstall Xcode and its Command Line tools and had to reinstall it from the Apple’s developer site downloads page: developer.apple.com/downloads. So, if any macOS users are reading this, do not pause or terminate it in the middle of the update, had to learn it the hard way.

Progress:

Coming back to Haiku, I learned how the menu entries of the deskbar menu are being fed, and working of Jam. I did a small work on adding SuperPrefs to the menu entry list. Most probably, SuperPrefs will be getting a place in the main menu rather than amongst Preferences menu entries. Here’s a preview:

In further weeks, I’ll be working on the implementation of the SuperPrefs’ app window. The major learning and coding part is yet to come, and am excited about it as well. The changes will be going here at my GitHub profile: AnirudhMurali. No changes as of now, you can see changes in the coming weeks. Thank you!

Hello everyone!

Community Bonding period

Last week I introduced myself and my GSoC project on porting Swift to Haiku, which can be found here in case if you missed it. The bonding period so far involved a mix of initial communication with my mentors jua_ and korli (Thanks for merging my HaikuPorter recipes!) alongside receiving assistance from other haiku-devs, notably PulkoMandy and waddlesplash. In addition, I mostly spent the week researching the swift front-end driver internals [1] by reading its documentation, patching more script files used for building swift and meeting several other GSoC students on IRC/mailing lists; and I wish them good luck with their projects. Shortly afterwards, I’ve made contact with the swift-dev mailing list about this project and asked about adding 32 bit support and both ideas are acceptable with the swift community [2]. But until the x86_64 port has a functioning toolchain, x86 support will be considered later.

Porting progress

This week, early platform support has been added in various script files and those changes have made it possible to build the compiler inside Haiku by using clang++. While Haiku already had support for thread-local storage (TLS) for sometime, this was required for self-hosting the llvm/clang forks and the clang port had TLS support disabled upstream [3]. This briefly caused some build issues but was later fixed in my swift-clang fork.

As expected, the swift front-end (swiftc), runtime (libswiftCore.so) and the standard library (stdlib) are very unstable, with the compiler instantly crashing when running swift source files. More work needs to be done in resolving these issues but apart from that, not much serious programming was done so far; only preparation work for building the compiler on Haiku for the coding period.

Issues encountered so far

Swiftc and stdlib all contain allot of runtime bugs due to missing platform implementations at the moment. For example, directly compiling a source file causes the front-end to poll infinitely; thus never actually generating a executable. The runtime uses some platform-specific code to handle extracting metadata from dynamic libraries and this must be implemented in Haiku (dl_iterate_phdr() is used in ImageIntrospectionELF.cpp [4]), running swift programs won’t be possible without this. I also tried importing C libraries such as math and stdio from the SwiftGlibc metaclass to test the ClangImporter tool, but it fails to import certain modules in the standard library despite correctly adding the paths to the POSIX headers. For now, I’ll be investigating the compiler front-end and runtime issues in the swift port to enable compiling or running swift source files on Haiku.

Goals achieved

• Support building Swift via Clang++ inside of Haiku.
• Refactor build-script to add initial platform support for recognising x86_64-unknown-haiku.
• Add x86_64-unknown-haiku target for swiftc front-end and stdlib.

Goals for next week

• Investigate issues preventing source files being compiled or run by Swift.
• Complete Haiku support for validation tests.
• Add WIP recipe to HaikuPorts.
• Investigate swift-corelibs and libdispatch requirements.

The repository used for porting is over at return/swift. Hopefully a WIP swift recipe will be available on HaikuPorts in a few weeks, so that my mentors or even others can try it out.

[1] https://github.com/apple/swift/blob/master/docs/DriverInternals.rst

[2] https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170508/004568.html

[3] https://github.com/llvm-mirror/clang/commit/ef7bceadf4b43c953855013577afac4c2fcb1d62

[4] https://github.com/return/swift/blob/swift-3.1-haiku/stdlib/public/runtime/ImageInspectionELF.cpp#L94

Hi everyone,

It's me again, this is my third report of my project about what I have done in this week. There is no coding, just reading and reading a lot. Now, I am confident to say that I can fully understand all the things in Btrfs codebase. I lurked a little around Linux's source and mailing list for Btrfs, but it didn't help much since the source is large, complicated and I don't know where to start to read, so I decide to implement Btrfs in my own way and back to read if encounter problems. I have tried to produce some bugs by making many directories and files with different size, and then see that can Haiku's Btrfs handle (cd and ls) it, lucky that it worked well otherwise I had works to do.

Also in this week, PulkoMandy help me to separate command results from fs_shell and tracing log because these are all redirected to stdout. I know how to read raw data from a disk device or file in Linux, with the help of PulkoMandy and axeld, this make debugging is easier.

Next week works

Next week is a first week of the coding period which mean I will follow what I listed in the proposal. But since I finished the first week works (set up fs_shell) in the previous week, so I will do the second week works, there are: Adding new structures btrfs_path and cache_extent. Those structures are helpful for manipulating trees and writing data. I may change, add or remove some things during the process because I lacked of understanding at the time of preparing the proposal, if there are any changes I will update it in weekly report.

Thanks for reading, see again next week.