Latest Bugs & Tasks

Hello

Haiku slows down when assigning more than 1 processor to the virtual machine. I tested with an AMD Phenom II processor assigning from 2 to 4 processor, getting the same slow down. I don't have an Intel processor to test on.

When running with only 1 processor everything is ok. Everything returns to normal speed when I reduce the number of processors assigned to the virtual machine or when I disable the extra processors in the deskbar.

I also tested running Haiku in the bare hardware and using the 4 cores of the cpu does not trigger the slow down, only when using Virtualbox.

Versions used:
Virtualbox 4.2.12 on Windows 8.
Haiku R1/Alpha4.1

Regards

VL-Gothic fonts is updated to version 20130422.

URL: ​​http://sourceforge.jp/projects/vlgothic/downloads/58671/VLGothic-20130422.zip/
Changelog: ​​http://sourceforge.jp/projects/vlgothic/releases/58671/changelog

Thanks for the update!

If we add a replicant in the Deskbar using the command "desklink", if/when the Deskbar will crash, this replicant will be lost. Instead, if in the Deskbar we add a replicant like ProcessController or NetworkStatus, these replicants, will be restored after crash.
Would be nice improve user's replicants added via "desklink", to have them restored after a Deskbar crash.

Steps to reproduce:
1: open a Terminal windows and type:
desklink /boot/home/queries
(this will add the "queries" folder to Deskbar

2: do a CTRL+ALT+CANC to open Team Monitor and here kill the Deskbar

3: restart the Deskbar (clicking on "Restart the desktop") and you will see that the replicant added using "desklink" is not restored. Instead, if in your Deskbar you will add ProcessController or NetworkStatus, these replicants will be restored when you will restart the Deskbar.

In newer Haiku revisions (as i can remember at least since hrev 45439) wave files aren't properly played. I mean that, when i listen wave files i hear clicks and crackles, but is not due an old/low performance computer (is a modern dual-core pentium, 2,59 Ghz) in fact, if i drag and move windows on my screen, all is ok. And with mp3 files this issue is not present. This happen with every media player: Haiku's Media Player, SoundPlay, SMPlayer/Mplayer and Aplayer. And these file aren't corrupted or something else, since under Windows and Linux, on the same computer, are played fine.
This is mediainfo output of one of these wave file:

General
-- Complete name                            : /boot/home/Desktop/Radiohead - Karma Police.wav
-- Format                                   : Wave
-- File size                                : 44.0 MiB
-- Duration                                 : 4mn 21s
-- Overall bit rate mode                    : Constant
-- Overall bit rate                         : 1 411 Kbps
Audio
-- ID                                       : 0
-- Format                                   : PCM
-- Format settings, Endianness              : Little
-- Codec ID                                 : 1
-- Duration                                 : 4mn 21s
-- Bit rate mode                            : Constant
-- Bit rate                                 : 1 411.2 Kbps
-- Channel(s)                               : 2 channels
-- Sampling rate                            : 44.1 KHz
-- Bit depth                                : 16 bits
-- Stream size                              : 44.0 MiB (100%)

Implemented in hrev45548, example of (hopefully) finalized format attached.

Fixed in hrev45545.

While trying to get at some old files that used RCS version control, I found that the rcs commands are missing in Haiku (co, ci, rcs, rlog, etc). They're not on the Alpha4.1 image. They are in the source tree, but the usual build target of install doesn't make them. However, manually listing them as Jam targets gets them building.

Something for someone with Jam experience to look into...

Libnetapi currently lacks methods to get the system routing table.
Could be implemented in various places:

In the mailing list I proposed

int32 BNetworkInterface::CountRoutes()

and

status_t BNetworkInterface::GetRouteAt(int32 index, route_entry* entry)

but since the routing table isn't interface-specific, although a single route can of course be interface-specific, I think it could be implemented in BNetworkRoster as a single method

status_t BNetworkRoster::GetRoutingTable(const char* interfaceName, BObjectList<route_entry>*)

which would return a list of route_entry objects (or a more friendly class (BRoute?)), with the option of filtering by interface name, or even family.

Unfortunately I suspect we don't push the use of BObjectList in public api, so we'll need to use a BList here....

Other ideas ?

Should be fixed since hrev45436 (​http://cgit.haiku-os.org/haiku/commit/?id=274b8be6c415dfb623f95ca9e4709c9f79836ae9) according to ticket:9591#comment:4

The debugger CLI's "threads" command currently lists a thread's state, but does not actually include the reason for the stopped state, i.e. the message passed to a deliberate debugger call. It needs to, especially for things like app_server crashes due to hitting an assert.

Again, BePDF is a third party app that is not part of Haiku's tree.

I appreciate this feature in the sense that it's a bit safer, but on the other hand, I wouldn't have lost nearly as much work due to the crashing bug if I were able to keep with the typical habit of saving every minute or so, which this safety feature prevents. Maybe there's a best-of-both worlds where it can rename the current file to " (copy 2)" or whatever and then save with the original filename whenever you hit Alt+S? That would make this much more useful, and even safer, for marking up PDFs.

hrev45525 gcc4hybrid

For reference, this really isn't the right place for app-specific bugs like this. BePDF isn't part of the Haiku source tree, which is why it doesn't have a component under applications. It's actually located at ​http://sf.net/projects/bepdf, though I have no idea if it's still actively being developed.

1. open a PDF file (e.g. simple.pdf)
2. add a comment text annotation
3. right-click, choose Properties, type "comment #1"
4. save as simple2.pdf and close BePDF
5. open simple2.pdf
6. add a comment text annotation
7. right-click, choose Properties, type "comment #2"
8. save as simple3.pdf

Following these steps exactly, simple3.pdf is actually saved with both comments, but it still crashes (case 1).

I had originally been marking up a PDF sent to me generated using Mac OS X 10.5.7 Quartz PDFContext when I first encountered this, but since then I have reproduced this using simple.pdf, which I generated using StyledEdit and the PDF Writer driver.

Trying with the PDF sent to me but following similar steps, I've had (also reproduceable) the unfortunate result that it produces a PDF but without my latest annotations (this is both if I immediately choose to save a debug report, or try to debug, save the debug report, and then tell the debugger to continue)--in fact, the file size is identical to the version just opened containing the first round of annotations. So I'm attaching that PDF too.

hrev45525 gcc4hybrid.

Thanks for the note!