Latest Bugs & Tasks
Fixed in https://github.com/haiku/webkit/commit/9327a14dd0f8db38dd7b5e1600d8a22e07a85639.
This will be available in HaikuWebKit 1.3.1.
Added the configure option (--target-board) in hrev47157.
It does not affect the build tools compilation yet, however.
FAT32 and other file system no longer supported by MKFS or Drivesetup, there was a mailing list thread about this some months ago but I am leaving this here as a ehnacement.
This is hrev47085. While debugging a Qt application (specifically, Designer; either by starting Debugger from the command line or by attaching to an already-running-not-crashed team), Debugger will repeatedly crash after doing normal tasks inside the Qt app (like opening and closing menus/dialogs).
I'm running Haiku inside a VirtualBox machine with Windows as the host OS.
Fixed in hrev47156.
Implemented in hrev47153.
Fixed in hrev47152. The window is activated and get focus, just like the first time a download is started. I don't think this is a problem.
Consider the following code used to create a stripped pattern using a BGradient:
gradient.AddColor(black, 0); gradient.AddColor(black, 127); gradient.AddColor(white, 127); gradient.AddColor(white, 255);
In ConvertToScreenForDrawing, the gradient stops will be sorted using BList.Sort. The sorting algorithm is not stable, so the two middle stops may be swapped. There are two ways to fix this:
- Implement a stable sorting algorithm (http://en.wikipedia.org/wiki/Category:Stable_sorts)
- Remove the AddColorStop method index parameter and use code similar to AddColor to find the proper index, or make that method private. This would allow BGradient to keep the list sorted, and remove the need for sorting it later. The method is used only in app_server (for reading the gradient data from app_server link) and when unarchiving a gradient.
What is the preferred solution?
Currently, HAIKU_BOOT_BOARD is given to Jam using the -s command line switch. There are problems with that:
- The build tools, which are built with configure, are currently specific to each board, or at least CPU core version.
- Jam invokes itself during the build, and does not forward the option.
- Changing this between two builds in the same dir doesn't work, because the compiler flags given for each board are incompatible.
Move the HAIKU_BOOOT_BOARD definition to configure-time to fix these problems.
We now have a separate libgcc for the kernel that disables C++11 threads support. However, the way this is built doesn't work properly with multilib compilers.
In ARM case, there are several versions of the libgcc built:
- libgcc.a (software floting point emulation, integer registers calling convention)
- fpu/libgcc.a (hardware floating point, float registers calling convention)
- soft/libgcc.a (hardware floating point, integer registers calling convention)
- thumb/libgcc.a (thumb instruction set)
- thumb/soft/libgcc.a (thumb instruction set, hardware floating point?)
- fpu/soft/libgcc.a (?)
Only the root one is considered by our libgcc-kernel build. As a result, it is not possible to build the kernel using the hardware floating point ABI. It would be nice to have at least the "fpu" version as well, and also having the others can't hurt.
Once the build-cross-tools script properly saves these libs, we will also need to modify some jam rules to make use of them. They currently always point to the default version of the library.
This is hrev47114.
When you're restarting the media services from the Media preferences, the restarting is aborted when you close the Media prefs' window. An impatient user could close it prematurely.
Making the window showing the restarting progress modal would be a solution. But what if something goes wrong and the restarting gets stuck?
Maybe that progress window wouldn't be only modal, but also grow a quit button like a regular window. Then the user could abort the restarting if it gets stuck (which hasn't happened to me yet).
Another, maybe better solution, could be to decouple the restarting process and use notifications to inform the user of the progress.
I have fixed the remaining issues myself in https://github.com/haiku/webkit/commit/48041f5a839c32916b27a66d6cac5a28d5a14c8f .
Haiku revision: hrev47127
Serial dump is attached.
When loading the desktop version of Yahoo mail the page loads better than the last release. But switching to different mail folders doesn't work. And viewing mails causes the tab the mail opens in to be blank.
It is a pretty strange bug probably the most severe I have seen so far among the sites I visit.
KDL fixed in hrev47129.
Apparently, VLC spawns threads with B_IDLE_PRIORITY what confuses the scheduler quite seriously. With the patch thread priority is clamped to a sensible range. Undoubtedly, VLC also should be fixed.
I think this can be considered fixed with the introduction of PM. Regarding installation time Haiku wipes the floor with BeOS, now. :-)
Fixed in https://github.com/haiku/webkit/commit/48041f5a839c32916b27a66d6cac5a28d5a14c8f. Will be part of HaikuWebKit 1.3.1.