Development

The BShelf is not owned by the BView (nor the BWindow for that matter) and so must not be deleted on destruction. The BShelf is not owned by the BView (nor the BWindow for that matter) and so must not be deleted on destruction.

This driver currently does not build. It would be needed for generic exploration of SCSI busses (not limited to mass storage).

libscg is one library that would make use of it (they already have the needed code from when scsi_raw was part of the image, or possibly from beos days). It is needed for clean porting of cdrecord (right now it uses hacks to identify the available drives).

duplicate

Is it possible to cross-compile Haiku on a Haiku host? I'm running gcc2h, and want to build an x86_64 version of Haiku for my UEFI hacking with QEMU. However, doing something like ./configure --build-cross-tools x86_64 ../buildtools ... followed by jam -q -j4 @minimum-anyboot results in an image that doesn't boot. I used setarch x86 before running any of this... in case that matters. ...

mån 6 apr. 2015 kl 23:14 skrev Axel Dörfler axeld@xxxxxxxxxxxxxxxx: Am 06/04/2015 um 10:36 schrieb Adrien Destugues: On Mon, Apr 06, 2015 at 10:22:26AM +0200, Ithamar Adema wrote: Is there any other reason then time/effort that we're tracking FreeBSD 9.x instead of 10.x for the network driver compatibility layer? An update would be very welcome at any rate. ...

* Use MemoryDeleter. * Avoid use of dynamic allocation. * Use MemoryDeleter. * Avoid use of dynamic allocation.

Hi all (but mostly aimed at Stephan and Ingo), Currently, there are (at least) two versions of Event and EventQueue in-tree -- one for MediaPlayer [1] and one for the Registrar [2]. At first glance these appear to be identical aside from coding style cleanups, but after some examination it appears that these classes have diverged significantly enough (void Execute instead of bool Do, locking, timing, etc.) that it's not possible for someone who doesn't intricately understand how these classes are supposed to operate to reconcile them. ...

Am 06/04/2015 um 10:36 schrieb Adrien Destugues: On Mon, Apr 06, 2015 at 10:22:26AM +0200, Ithamar Adema wrote: Is there any other reason then time/effort that we're tracking FreeBSD 9.x instead of 10.x for the network driver compatibility layer? There's some network driver support in 10.x that isn't back ported to 9.x, and I would prefer to simply update the BSD compatibility instead of starting to merge patches from 10.x into our 9.x base... ...

duplicate:

On the versionning scheme for Haiku: more details in #10289.

So basically the release will have a version of R1~alpha5.0 or R1~beta1.0 (no hrev info). Anything built for a specific nightly will be R1~alpha5.0~hrev44444, which is greater than the release version number in our versionning scheme.

The package manager needs no change. All packages for a release need to be built while running that release, or an older nightly (which would have a version lile R1~alpha4_pm~hrev33333) so it is installable on alpha5.

Haiku needs to define how package release repositories work. At the moment the ever-increasing hrev tag defines a functional package ecosystem. (This package was built on hrev32452 and should work on any os release newer than hrev32451) These hrev numbers are modified for releases via alpha1~hrev32452. (more details needed)

The package manager needs to sort the release prefix properly

On Mon, Apr 06, 2015 at 10:22:26AM +0200, Ithamar Adema wrote: Hi, Is there any other reason then time/effort that we're tracking FreeBSD 9.x instead of 10.x for the network driver compatibility layer? There's some network driver support in 10.x that isn't back ported to 9.x, and I would prefer to simply update the BSD compatibility instead of starting to merge patches from 10.x into our 9.x base... Anyway, just wondering if someone tried that already and found some ...

Hi, Is there any other reason then time/effort that we're tracking FreeBSD 9.x instead of 10.x for the network driver compatibility layer? There's some network driver support in 10.x that isn't back ported to 9.x, and I would prefer to simply update the BSD compatibility instead of starting to merge patches from 10.x into our 9.x base... Anyway, just wondering if someone tried that already and found some blocking issues or if it is just a lack of time / motivation ;) ...

Sometimes the preloaded images are loaded before the requested one.

How to reproduce this (In a single or dual core machine):

• put in a folder a small image and a very big one.
• open the small one.
• ShowImage took a very long time to open (time to load the big image + the small one)

This happen when the loading thread is scheduled after the insertion of the preloaded images in the queue