TLDR: pkgman install nodejs
As some have already known for a long time, many platforms have had support for writing software in JavaScript or TypeScript with the help of the Node.js runtime and over the years, much of the software written by developers these days have gradually been written in either of those languages. However, Haiku has lacked a Node.js port for quite sometime and it wasn’t possible to run or develop JavaScript based software or libraries that depended on the Node.js runtime. Now I can say that Node.js is available for Haiku and can be downloaded from HaikuDepot on 64 bit (32 bit support is being worked on). The version which is currently available is 12.3.1 and is already being updated to the latest version at the time of this writing to 12.10.0 and support for the upcoming LTS version is also coming to HaikuPorts. Several patches have been upstreamed by members of the HaikuPorts team to projects such as libuv (cross-platform async I/O library), GN, etc and we hope to upstream to larger projects like V8 (Google’s JavaScript engine used in Chromium and QtWebEngine) and the Node.js project, which will ease the bringup of a future Node LTS release for Haiku.
Hello everyone!
This blog-post marks the final report on bringing Swift to Haiku in the Google Summer of Code period. My introductory post on this project can be found here for a brief overview of the project.
Summary
In the last 3 coding periods, my contributions to Haiku’s LLVM and Clang ports plus reporting some bugs with the Haiku developers have made it possible for the Swift toolchain to be built on Haiku. With this, it opens the possibility to use cross-platform Swift libraries used on other platforms and also allows to directly use the libc/glibc libraries via the GlibC module. I have already done an initial port of Foundation and libdispatch on Haiku as specified in the previous blog-post, but they still need to be polished for general use. As for upstreaming my patches for Haiku support, I’ve sent my patches to apple/swift and they are currently under review.
Time for another update on the swift port, which covers the last two weeks of my activity, So here it goes!
Week 9 - My Findings on Porting libdispatch
On the 9th week, I added early support for building libdispatch aka ‘Grand Central Dispatch (GCD)’ which is Apple’s event-driven concurrency framework which allows executing high performance code via asynchronous task queues or I/O file descriptors (including sockets), which enables programs to take advantage of multi-core systems and to run Swift programs that utilises this. After that, I’ve began porting the core-foundation-libraries aka ‘Foundation’ framework to Haiku, which is needed to support the package manager and other cross-platform swift libraries.
Hello everyone!
Since last week I worked on enabling Haiku support for running the swift test-suite. This allows the newly built compiler to be put through the same series of test-cases run by the swift buildbots for macOS, Linux and FreeBSD platforms. These tests cover different areas of the toolchain, from simple unit-tests to validation-tests that cover the compiler internals, major standard library API changes and most importantly, compiler stability via testing with malformed inputs. I ran the Swift 3.1 tests with the command ./utils/build-script -R -x , in which 2022 tests passed and 149 failed. A brief summary of the test results can be found here, and a list of the tests that have failed.
TL;DR: Compiling Swift programs works, added C library interoperability and adding support for running the test-suite.
Hello Everyone,
This report covers my activities done since the first evaluation of GSoC. I spent the first week looking into the most critical aspects of the compiler and focused my attention on the TaskQueue class. Whenever a task is executed, the TaskQueue tries to read its data via a pipe and it was found that it read 0 bytes from it, despite poll() reporting that there is still data available for reading. Therefore, the compiler fails to output a executable and becomes stuck in a infinite loop; at least with the Unix implementation.
Hello everyone! This report covers the span of the last two weeks of my porting efforts to get swift running on Haiku. I started debugging the runtime library ’libswiftCore’ on both Haiku and Linux and focused my attention specifically to the ImageInspection logic in order to fully understand how the runtime extracts ’type metadata’ from a swift generated shared object. My mentor korli, recommended me to use the get_next_image_info() function, which is the Haiku equivalent of iterating through the list of loaded libraries in a executable. Hence this, it was used to implement dl_iterate_phdr() in ImageInspection.cpp, taking some inspiration from the Cygwin port but parts were rewritten to be used on ELF based platforms.
Hello everyone! This is a rather short update on the Swift port and since the last blog post, I’ve worked around a small issue that prevented the compiler from importing libraries by specifying the -sdk parameter with a ‘/’ which passes the correct header search paths to swiftc. This issue also existed on other platforms such as FreeBSD according to this thread in the swift-dev mailing list [1]. Whilst researching around the frequent swift interpreter crashes when opening a swift source file, the fault lies in libswiftCore being unable to extract type metadata from swift-generated dynamic libraries when calling these functions specified in the ProtocolConformance and Metadata classes. It is also evident that whenever swift attempts to load this metadata at runtime, it uses ‘dl_iterate_phdr()’ to iterate over every ELF object loaded into the process address-space and will initiate a callback that will emit internal ELF information defined in the dl_phdr_info* struct. I will spend this week with my mentors to implement a Haiku replacement for this function.
Hello everyone!
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.
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.
