Latest Bugs & Tasks
I have noticed a sort of issue while installing local packages using HaikuDepot. Well, I just double click on any HPKG file present on my disk, and HaikuDepot will prompt me to install this package. But i noticed that if my internet connection is busy (eg I'm downloading/uploading something over internet on another computer on my lan - or on the pc with Haiku) it will take a while to install local packages (and during the install process i can see, on Haiku, a connection activity, sign of the fact that the package management is looking for dependencies). So I guess that this is due to the dependencies resolution (stated in the .PackageInfo file). Well, obviously this cannot be avoided, but HaikuDepot/package management daemon should, before check on the server for dependencies, if these deps are already present on the disk, to avoiding the described issue.
Eg i noticed this issue while I was installing a local QupZilla package (it relies on libqt_x86), but libqt was already present on my disk, so in this case, is a waste of time use the connection to check for deps. I hope to have been clear in my explanation.
Initialized the array in hrev48334.
I followed the sequence used by Coverity and it is invalid, it jumps between states in way that the state tables in VPrsTbl.c would not allow (from CASE_ESC_IGNORE to CASE_ESC_DIGIT). The only way to enter ESC_DIGIT is from CASE_CSI_STATE, which sets the first element of the param array to DEFAULT. Then following elements of the array are initialized each time nparam is incremented.
Just to be safe, the array is now cleared once when entering the function.
Fixed in hrev48332 by updating grep.
That button doesn't exist anymore.
Replaced the BPictureButtons using BButtons with an icon in hrev48331. We get the standard BButton look this way.
Can't reproduce here either, probably fixed some time in the last 5 years.
Implemented in hrev48330 except "A" (cycle aspect ratios), which I think is not so useful and a bit more code to write.
The RAW editor's window is no longer horizontally resizable: I have to use the scrollbar, to horizontally resize this window.
Loot the attached video to see what I mean.
There is also another issue: the field for the String Editor, now shows unactivated scrollbars: see the screenshot.
I was hopeful that Google Play Movies might work on WebPositive but seems it has an issue playing. See attached Screenshot.
And now it works again... <rolleyes>
This is hrev48274.
Every blue moon I log into blogger to post an update to the Haiku Gazette... :}
Tried that today, but clicking "Login", Web+ starts loading, but never actually arrives anywhere...
Applied a reworked version of the patch in hrev48320.
Ok, thanks for reporting and sorry for the inconvenience.
Done in hrev48317.
This is so different from Haiku it's time you create your own project. But please use a different bugtracker for it.
I'm working on upstreaming Haiku support for Boost, and am running into a reproducible deadlock for the Boost.Interprocess module.
My current work can be found at https://github.com/jessicah/boost
I think git clone --recursive https://github.com/jessicah/boost.git should do the right thing. Else you'll also need to grab the build, config, predef, thread, filesystem, and interprocess submodules from my GitHub as well.
Steps to reproduce:
./bootstrap.sh ./b2 --without-mpi --enable-parallel-mark inlining=on threading=multi variant=debug link=static,shared runtime-link=shared --without-python -j<N> cd libs/interprocess ../../b2 --without-mpi --enable-parallel-mark inlining=on threading=multi variant=debug link=static,shared runtime-link=shared --without-python -j<N> -a -q test
Eventually, several tests will end up deadlocked, these are condition_test, condition_any_test, named_condition_test, and named_condition_any_test.
If I attach Debugger to any of these tests, I can break the deadlock by debugging all currently running threads, then resuming the test thread (this has the pthread_join call in the stack trace), then resuming the other threads. If I instead resume the other threads first, the deadlock remains.
The named tests sometimes require repeating the process, but will eventually resume.