Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
It was discussed and introduced based on docs that some systems
need this to shutdown properly. I can find no mention of this in
ACPICA or ACPI docs.
This needs to be re-evalutad, as all my shutdowns been successful
after disabling it and I can't locate where this info came from
or if it actually helped.
See 1316462ab0 for original commit
and bug 12306 on current shutdown issue.
As it turns out, using the xattr emulation layer plus "libgnu"
causes some strange mixups at package build time, and so packages
built with it were winding up with no attributes at all.
So I've just bitten the bullet and written a full passthrough layer
to the system attributes. Verified using a full build of haiku.hpkg
this time ... after a lot of painful debugging of symlink mixups.
Hopefully I am finally rid of this plague...
* The global lock, needed for hw <-> os to sync, was a no op.
This means that OS and HW could read and write to same value
at the same time, causing garbled data and crashes. This is easiest
to see in battery status, where battery values and OEM name would
become garbage. It also causes instability and failure to shutdown
* ACPI used 64 bit addressing (which it normally should) on 32 bit.
This would cause page faults as it would jump to incorrect addresses
To quote jscipione (from 95e8362c52),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.
In 5e19679ea3, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.
Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.
Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea3,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.
My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.
Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.
- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.
- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.
Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.
So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
Per #10267, "Most (ported) third-party software should be removed
from the Haiku source repository."
Since HaikuPorts already has the ncompress package, this file
should no longer exist.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Original patch missed modifying the "minimum" definition and the
src/bin/Jamfile, so I took care of that.
In MediaPlay.cpp, media_play returns non-zero value on failure but forgets to return zero on success.
Coverity CID: 1422617
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
set_var doesn't return any value yet its return type is ULONG, and Coverity freaks out about that. This patch turns that function into a void function.
Coverity CID: 603433
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
TeamWindow:
- Properly delete stack frame selection entries in destructor.
TeamDebugger:
- The reference to TeamDebugInfo wasn't correctly initialized to own,
leading to TeamDebugInfo never being destroyed.
FunctionInstance:
- Also clear source code reference in destructor.
ImageDebugInfo:
- Release references to specific infos in destructor. These are acquired
on our behalf when loading the image info, but were never released,
leading to the latter never being freed.
DwarfManager:
- Release references to files in destructor.
FileManager:
- Release entries in various destructors.
Somewhat improves the situation in #13800, but is still far from complete,
as a thorough review of this nature hasn't ever really been done.
TeamDebugger:
- In several cases, BReferences on thread handlers after a call to
_GetThreadHandler() weren't correctly initialized to account for
that function implicitly acquiring a reference on our behalf, leading
to the reference count to spiral out of control, and consequently the
handler would never be freed. Found while attempting to address
#13800, likely more to come.
- Recent changes to the build system appear to make the assumption
that the GNU regex APIs are universally available. This isn't the
case on FreeBSD, which requires libgnuregex to provide that
functionality. This broke the host keymap build.
gnuefi package was replaced by gnu_efi_kernel, but build
was not updated. This is guesswork, as I couldn't track down what changed.
It finds headers, headers_arch and lib and works so should be ok.
* Update the work status view with package state changes from
MainWindow instead of PackageListView, because PackageListView
does not always show all packages that are going to be installed
(e.g. dependencies that are not shown when a search filter is
active).
* Fixes the bug that prevented pending/download status to show up
for dependencies when filters are used.
Not in the POSIX specification, but defined (not behind any guards)
in (at least) FreeBSD, NetBSD, glibc, and macOS.
Found by miqlas and myself while working on porting GNU inetutils.
* During package population, when the repository is being
refreshed, thousands of package change messages arrive
in MainWindow while the PackageInfo fields are filled with
data.
Every such message caused a full generation of a package
list (including applying filters to all known packages),
which is quite slow, and caused the freezing from bug
#13823. The list was only used temporarily to figure out
if the package should be visible now or not.
* Instead of generating a new package list, we now only
match the single updated PackageInfo against the current
filters.
* Fixes#13823
* To reduce CPU usage even more, it would be better to not
generate at all, or not subscribe to, package changes while the
list is being initially populated, and/or to coalesce all the
changes to each package info into one update message (instead
of one for title, one for prominence, etc).
Deferring subscription requires some additional thought on when
to subscribe then, and how to avoid leaving a "hole" where
changes would go unnoticed.
I've updated the docs to match the current BMailComponent, documented
new functions, and cleaned up the MailComponent.h file to at least
somewhat match our coding style.
First in a series (there are 3 more old API docs on the Mail Kit in that
"Public API" folder.)
It was needed on macOS for a time when BUrl used regexes for parsing.
Now it does not, and so we can remove libshared's RegExp from build
libshared, and thus also libgnuregex.
scripting properties:
* Info, Grid, and Stick (true/false)
* CopyImage
* MakeSquare
* Zoom (1-100)
Decreasing pixel size from the menu will half the size
until it's less than 32.
fixes#13884
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Fixes Coverity issue CID 1340122.
Also resolves two TODO items in the code: allowing the deletion
of a selection of cookies, and deleting all cookies from a site
when there are no specific cookies selected.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The feature gives user ability to choose the position of notifications
out of Follow Deskbar, Lower Right, Lower Left, Upper Right and Upper
Left. Fixes#9749 - Notification_Server: add the ability to choose the
position of notifications (easy).
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
The Interface Kit is long since "99% functional", so lists of modules
with what's-implemented-what's-not are not really helpful anymore.
The one (rather lengthy) file describing the unit testing system
set up by the IKTeam is indeed useful, so keep that.
Previously when we used Drupal, the icon guidelines there "shadowed"
the ones in this tree. Now that the git-based website reigns supreme,
we should not keep two copies around. I've chosen to preserve
the one in the website repository and trash this one because the icon
guidelines primarily target artists, not programmers (as just about
all other docs in this directory do.)
Previously I had intended to take the simpler route and just lock the
already-inserted team before setting the io_context (as in prior commits),
but after hearing some reports from users that some other seemingly
unrelated KDLs had possibly cleared up after the first iteration of
that fix, I decided to go with this route instead.
Now we do not insert the team into the parent and hash and send the
notification until just before the team's main thread is actually started;
i.e. we now initialize not only io_context but also the team's args, VM
address space, and user data (and if creation of any of these fails
we do not inset the team into the hash at all.)
Since the team structure was not locked at all while this initialization
was taking place, any number of race-dependent bugs could have been
caused by this on multicore systems.
* Further improves the logging and provides some
basic performance numbers.
* Moves the bulk-load logic out of the data-model
class.
* Introduces a state-machine for the bulk-load
process so that it will be more easily able to be
shifted to non-blocking IO when the HTTP libraries
can do that.
* Implements concurrent loading of the bulk-data to
hopefully improve lead time for icons and meta-data.
* Loads data to a temporary file and then moves to the
final location in order to avoid partially written
data in the cache.
* Handles situations where no network is available;
prevents attempt to access the network.
* Allows bulk-load processes to be cancelled when the
application quits.
* Introduces command-line arguments to help simulate
scenarios to help with testing performance and
network absence.
* Implements ordered insert and binary search in the
'List' class + basic unit test.
The KDL in #13861 was apparently caused by a NULL io_context. I read over
the Team code and have applied the following fixes here as a result:
1. A NULL io_context is entirely possible, as implied by the NULL check
before deinitializing it in Team's destructor, so account for that.
2. Team objects have a class-wide lock which must be acquired before
directly accessing class members, so use that here.
First part of the fix for #13861.
calloc, when multiplying to find the true size of memory desired
by a user, will occasionally overflow if the numbers are too
large. This commit makes calloc ensure that the multiplication
does not overflow by dividing the result by one of the numbers,
and checking to ensure that the result is equal to the other
number. If there is overflow, it is treated as an OOM error.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
