Development

duplicate

Zipomatic will zip files either individually or in groups, but silently fails when trying to zip a whole directory.

262 MB

263 MB

264 MB

MemoryView: - Implement {Min,Max,Preferred}Size() hooks. The default BView versions were causing the inspector to sometimes not be properly resizable after previous settings were restored. MemoryView: - Implement {Min,Max,Preferred}Size() hooks. The default BView versions were causing the inspector to sometimes not be properly resizable after previous settings were restored.

* Add icu54 packages for x86 for compatibility. * Add icu54 packages for x86 for compatibility.

fixed:

Applied in hrev49165. Thanks!

Fixes #12063. Signed-off-by: Augustin Cavalier Fixes #12063. Signed-off-by: Augustin Cavalier

The documentation for makefile-engine opens in a text editor, not the web browser, because it is missing the HTML document level tags.

The file is haiku/docs/makefile-engine.html I'll append a patch shortly.

invalid

The cluster cache was used before porting to the file map API and is not and can not be used there anymore. The cluster cache was used before porting to the file map API and is not and can not be used there anymore.

The header file at /system/develop/headers/glib-2.0/glib.h contains inclusions which cannot be found by default. Paths inside refer to <glib/*.h> when they should refer to <glib-2.0/*.h>

There's no real need to distinguish between first/middle/last parts of the file and much of the initialization can be done simpler. This also checks for overflows when truncating the requested length. On 64 bit platforms this would always happen due to the kernel file map code requesting (size_t)-1 (i.e. unlimited) extents. This lead to the file end being reached when building the map from a position unequal 0, which would happen for files fragmented enough to need more than the default of 8 supplied vectors. An IO error was returned in that case, rendering the file partially unreadable. There's no real need to distinguish between first/middle/last parts of the file and much of the initialization can be done simpler. This also checks for overflows when truncating the requested length. On 64 bit platforms this would always happen due to the kernel file map code requesting (size_t)-1 (i.e. unlimited) extents. This lead to the file end being reached when building the map from a position unequal 0, which would happen for files fragmented enough to need more than the default of 8 supplied vectors. An IO error was returned in that case, rendering the file partially unreadable.

invalid:

We repeatedly asked people complaining about this to provide examples of software that can't be installed anymore. There was 1 single bug report as a result of our repeated requests, and we helped fix the affected software (it was yab).

I should also add that BeOS software would be hardcoded to use /boot/beos, not /boot/system, so whatever happens in /boot/system will not change anything. This means we already are out of the way of "old hardcoded software". Please reopen this bug only if you have software that is broken because of this problem (rumors that "other people said..." won't work, sorry).