There is no point in computing line breaks for a 10px wide text view and
it takes a long time because it needs a lot of linebreaks. The view
eventually gets laid out properly.
This may cause regressions, the TODO here is very old and I don't know
to which "other parts of the code" it refers. Possibly they were
rewritten, possibly not. In any case, there is no point in keeping this
nonsense initial text rect computation, it's better to fix the actual
problems.
Fixes#5582 (which was not locale-related, after all)
If be_app is not running yet, trying to lock it may easily end up in a
deadlock.
Fixes#2105
However, as a result of this, when this situation happens, the
translator roster will not be node monitoring added/removed translators.
This was already the case if BTranslatorRoster::Default was called
before BApplication constructor, now it's also the case if called inside
the BApplication constructor or from another thread before it finished
running.
Maybe BTranslatorRoster should try to register itself later on if it
detects this. But it's acceptable to have the app not monitor
translators, because adding and removing translators isn't a very common
occurence and restarting the app to get it to notice them is probably
ok.
Remove the InstallerInitScript (it does nothing) and the
InstallerFinishScript (it does too many things). Instead implement the
finishing directly in Installer. Separate writing the bootsector, so
that the "write bootsector" menu writes only the bootsector.
Fixes#16303
- libicule and libiculx do not exist anymore in newer ICU versions
(harfbuzz replaces them), but we didn't actually use them, so remove
them from the build feature and from the package dependencies
- Add namespace usage marcos since the newer ICU packages put ICU things
in a namespace, making it easier to have multiple versions of ICU used
side by side.
No functional change intended, but this makes it possible to build the
code with either ICU 57 (for gcc2) or 66 (for other architectures).
Reserved areas don't have the name field initialized, so explicitly
print "reserved" instead.
Change-Id: I26bcfcb8facb8b5df11a58074506e96a41943e31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2847
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes the output of the aspace KDL command more useful as it shows
reserved and free ranges in addition to areas.
Change-Id: Id6353820b7c040fce6bfc3297c1b34adb1c9bb99
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2846
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.
Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.
This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().
MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.
Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.
Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.
Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The limit was set when creating limits.h back in hrev88. It seems to be
used only in glob(). The limit is quite low by today standards and
prevents building icu 67.
I guess the liit was put at 32K because that's what BeOS did, but I see
no reason to keep it that way.
Change-Id: I74f95d9b56891dd90c79b7ced35ca8d1ec81d6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3117
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* efi-app-x86_64 is a undocumented legacy compatibility
target from the early days of EFI.
* This opens the door to native arm,arm64 loaders without
the gnu-efi 'fake pe' stubs in the future.
* This change also clairifies what's happening within the
undocumented efi-app-x86_64
* Future as in binutils fixing these:
https://sourceware.org/bugzilla/show_bug.cgi?id=26206https://sourceware.org/bugzilla/show_bug.cgi?id=26218
Change-Id: I60b4a4f5ceb36059033debbe6bf5b01928d6b223
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3016
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
The label to be truncated was copied into a fixed width buffer without
taking the null byte into account which would make
BFont::GetTruncatedStrings() read out of bounds when the name got long
enough. The output strings were also not allocated with the required
extra space for the ellipsis which would possibly have caused the
output to overflow.
Since the goal is to truncate a single string, remove the entire
temporary extra allocations and simplify to use BFont::TruncateString()
directly, which avoids both problems by being BString based.
Change-Id: Ib57430faf6f706c705497191000ee9686441857e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3116
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The name retrieved from GetName() on BTextEncoding is owned by that
instance which goes out of scope when identify_text() returns. A const
char pointer to it can therefore not be used as an output variable. Use
a BString instead which ensures an appropriate reference is acquired.
Change-Id: Ib87fc9879d29e927bb41d1a9165ca7599b74a3bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3115
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The panic is continuable, but moving on with the free will overrun the
array and corrupt memory.
Change-Id: I9a5849a40158042150a25740ca57d711aee872bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the vector is assigned to a CPU it means that the assignment
structure is still referenced from the CPU side and must not be reset.
This can happen when an interrupt vector is freed that still has a
handler installed, i.e. when the order of removing the handler and
freeing the vector is reversed.
Change-Id: Ib2dc5fa8f95a28b36e8f150dc8f16236ca4b2275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3113
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Freeing an interrupt vector that still has handlers is not allowed.
Change-Id: If2f256e5288c7a61b7e23bdb202f259f5b67b7ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3112
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The old buffer info was not initialized so would possibly contain bogus
initial content.
Since the introduction of the TimeComputer, the old buffer info was not
used to update the timesource data and the only remaining use was for
keeping track of the previous cycle number.
Replace the old buffer info by just the old cycle number and initialize
that.
Change-Id: I8be5a17f086a9f81f9b8fd0629e10460518f3d8c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3111
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I82465c3002cbf58fad79b9621074cafd8fbd16e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Abstacts the list of supported languages into
the LanguageModel class preventing use of
List. Also; fix a few cases where newer
logging techniques may have caused incorrect
logic flow.
Relates To #15534
Change-Id: I144fe4788abdaf0d93e53eeabc97b3f7aa2ec710
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3085
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Instead of adding "dummy views", leave the original views intact
and just add a resizing hack to take care of any movements that
apps have inflicted.
Fixes#16411, a crash in WonderBrush, and compatibility issues
in some other applications.
We need a different constant or mechanism to get the document
window border size, it appears, or a static method to get
a scroll bar's preferred size.
Should fix#16422.
Two indices into the fEntries ring buffer are used in TimeComputer,
fLastEntry which points to the most recent sample and fFirstEntry which
points to the oldest one. The drift calculation then uses the oldest
values pointed at by fFirstEntry to produce smoother values.
Both indices are initialized to 0, then fLastEntry is incremented prior
to writing the first sample, resulting in the first sample to be written
to fEntries[1]. When drift is calculated on subsequent samples, they
were using the uninitialized data from fEntries[0] due to fFirstEntry
still pointing there, until enough samples had been added for
fFirstEntry to be moved forward. The resulting incorrect drift values
would depend on the entry content and ratio between real and performance
time and generally end up being much too small.
The drift values are published on the time source and used to correct
the conversion between performance and real time in
BTimeSource::RealTimeFor(). Given the incorrectly small drift values,
this conversion produced real time values far in the future, causing
increased delays in processes that wait for such computed real times.
One likely victim was the startup of the AudioMixer, as it generally
starts soon after the driver and its MultiAudioNode. If it started right
in the time window where the drift was broken, it would end up delaying
its initial buffer processing by a factor generally depending on the
difference between real and performance time start points, so usually
the difference of the start of the boot process to the start of the
audio driver.
The symptom was then noticable by initial silence after boot, as the
mixer was not producing any buffers until the wrongly calculated real
time had been reached. After that, lots of queued up events were
processed at once, resulting in a CPU spike and glitchy audio for a
couple of seconds after which audio finally normalized. As the problem
was in the MultiAudioNode all mutli audio drivers were affected, HDA
being the most prominent.
As the erroneous delay depended on the initial entry content and the
boot time, it was highly variable. Whether or not the mixer was affected
at all also depended on it starting reasonably early after the driver,
which made the symptom of the bug appear and disappear depending on
slight timing changes, making unrelated code changes look like they were
affecting the bug.
The fFirstEntry index is now updated to fLastEntry after the initial
entry is added, so that the drift calculation always uses valid data.
Fixes#16222, may also affect #15472 and possibly other "no audio"
tickets in case they are really "delayed" audio tickets.
Change-Id: I61f4a67e8b8bf14d2f311cb41b24a1c385aebc19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3092
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The socket is a blocking one, which means Read() will block unless data
is available, thus WaitForReadable() is useless in this context.
Testing also shows a 2x performance increase from removing this call due
to poll() performance being botched when KDEBUG_LEVEL >= 2.
Change-Id: I3170f865e961112b420c1548726bb6fd38e94cb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3078
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This make sure that the temporary buffer will always be deleted should
any premature return happens.
Change-Id: I448ec7c3f3eeca1ef2b6473b49323f34bcb7bf86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3077
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Instead we can trigger a Read() immediately, as our socket is blocking
and won't return until some data has been made available. This avoids a
potentially costly syscall in the loop body.
Change-Id: I899f55ede41af7cb7e9311aa04006b33c40d3ee4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This commit brings the following changes:
- DownloadProgress() should now be reported for every DataReceived()
calls, similar to other BUrlRequest classes.
- Properly verify whether a listener has been set before invoking them.
Change-Id: I4ded82e318ba580b8869c3d1751da4e36882c39f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3075
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This simplify the clean up code path and make sure that the temporary
buffer will always be freed on exit.
Change-Id: I70c1a25bfa66c4f4a96dd3d0af3765a67e305fb2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3074
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Trigger DownloadProgress after DataReceived, similar to how other BUrlRequest
classes behave.
Change-Id: I4858c3736b1b1ebec55af9903dbfd4b976a77df3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3073
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
