We don't need to create a BNode from a BDirectory because BDirectory derives
from BNode! So use the BDirectory we already have as a BNode and get the
node_ref from it so we can pass it into WatchNode().
Sorry for the noise.
* Add \since directive to each method.
* Add documentation for BScrollBar and BScrollView classes.
* Title Case group titles.
* Some other minor documentation updates.
When an ARMv7 CPU is detected, immediately turn on the FPU. This allows
us to use vsnprintf in the TRACE call in that function, as our libc is
compiled with floating point support and will trigger a fault if the FPU
is not available.
This lets the boot go further, and crash in mmu_init. Next steps:
* Find why mmu_init is crashing
* Setup some fault handlers, otherwise we call uboot ones, and they are
not very helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabled...
Loading of haiku_loader from an uImage is a 2-step process:
* First, the uImage is loaded (in our case from SD card using fatload)
to RAM at a temporary address.
* Then (using bootm), it is unpacked. The uImage is a container format
and can hold several files, with a load and execution address. The files
are copied from the uImage to their final location, and it's better if
that doesn't overlap with the uImage content
When this loading is done, bootm jumps to the entry point found in the
uImage.
We now actually execute our code from haiku_loader. This crashes with
the following call stack:
* vsnprintf
* dprintf
* boot_arch_cpu_init
* cpu_init
It seems vsnprintf is trying to use VFP instructions (probably from the
libgcc) but that triggers some kind of fault, and the handler (setup by
uboot?) ends up crashing the system by jumping to unmapped memory at 0.
* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* Previously, BPath::Append() would return an empty path if the
path didn't exist (and an error); in a nightly image, the
B_USER_ADDONS_DIRECTORY didn't exist, triggering the bug.
* Replaced the code with calls to BPathFinder instead, which takes
care of the empty path automatically.
You can't increment the list item counter as you delete because the count
decreases as you go. Instead delete the first item until there are no more
items, then delete the list.
The logic was reversed accidentally in hrev47355
Rewrite the method to make more sense. If data is NULL return
B_BAD_VALUE right away. Otherwise set the status based on the first
operation, if that succeeds perform a second one, and return the
result.
Fixes CID 1222666
The biggest change is the addition of \since to each method. I've gone
through old versions of the BeBook and documented what version of BeOS
each method was introduced in. I'm only counting production releases
so I'm starting with BeOS R3 ignoring all DR and PR releases. Likewise,
all methods new to Haiku are listed as being introduced \since Haiku R1
ignoring alpha releases.
No functional change intended.
Focused on documented classes only.
* Update copyright information.
* whitespace fixes.
* pointer style
* Rename some variables, msg => message, form => what
* Need consistent variable names to make documentation easier,
allows us to use \copydoc or \copydetails instead of repeating
ourselves over and over again.
* The Network Kit now makes use of it for BUrlContext, so we need this
in the public headers.
* Problem caught by the new build bot by compiling the unit tests.
* Each BHttpAuthentication object is locked on all field accesses,
* They are owned by the BUrlContext and never deleted, so there is no
need for reference-counting them,
* The BUrlContext itself is now reference counted, and all BUrlRequests
hold a reference to it.
This makes sure using the BHttpAuthentication objects from requests is
thread-safe.
* Change the semantics of the iterators copy constructor and assignment
operator: they now return a new iterator for the same cookie jar (and
same url for the UrlIterator). They don't try to point to the same
position as the copied iterator. The only purpose of these is to write
code such as:
Iterator it = jar.GetIterator();
so having a full copy isn't that useful.
* The per-domain cookie lists are now protected with a read-write lock.
The iterators retain a read lock while they are handling cookies from
that list. They get a write lock when doing Remove. Adding a cookie to
the jar also gets the write lock for the matching list
* Fix a memory leak when adding a new domain-list to the jar failed
* Simplify the declaration of the PrivateHashMap type (it would be
even simpler if HashMap was a public API)
* The domain hashmap is now a SynchronizedHashMap. It is locked as long
as an Iterator or UrlIterator exists, which may be a problem as these
are public APIs. Writing safe iterators for an hashmap with concurrent
accesses is not easy, so the API could be modified to return a list of
domains and a list of cookies for a given domain or URL instead. This
would suit the intended uses just as well.
* The jar now store const cookies, so there is no need to lock them for
access/modification. Updating a cookie is done by replacing it with
another one in the jar (with the same domain and value). There is still
the problem of deleting a cookie while other threads may still access
it, this will be fixed by making cookies BReferenceable.
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
* Word 105 of ATA IDENTIFY should contain the maximum number of block
ranges the device supports, but it always supports at least a single
one.
* This change lets the trim command do something on Virtual Box.
* This tests requires some private APIs which have been changed, it
needs to be rewritten.
* I'm also not sure if it's still possible to work on a copy of the MIME
* database to avoid messing with the system one.
If you have the Desktop window open when you switch to spatial
mode this will now close the window. You aren't allowed to have
the Desktop open in 2 places symultaneously in spatial mode.
... in a few more cases.
If you are in spatial mode and you double-click on the Desktop folder
it activates the Desktop putting all other Tracker windows in the
background.
If you are in browser mode and you double-click on the Desktop folder
it opens the Desktop folder in the current window.
If you issue 'open ~/Desktop' from Terminal or if you have Expander set
to open the expanded folder and you expand something on the Desktop
it won't open the Desktop folder in its own window in either spatial or
browser mode.
This patch alters Trackers behavior to open the Desktop folder in its own
window in these cases when you are in browser mode.
One might argue (as a few have on IRC) that this behavior should also
happen in spatial mode, but, this patch does not alter the behavior of
spatial mode. In spatial mode opening the Desktop folder with
'open ~/Desktop' or extracting a zip file with Expander on the Desktop
simply activates the Desktop pushing all other Tracker windows into the
background state.
Fixes#10929
