doesn't change, it makes room for/removes items at the given index. This
simplifies the calling methods.
* Added InsertUninitialized() method, a generalized version of
AddUninitialized().
* Remove():
- Added optional "count" parameter.
- Added missing debugger() call.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34566 a95241bf-73f2-0310-859d-f6bbb57e9c96
MediaFilesManager; the client protocol implementation is still missing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34564 a95241bf-73f2-0310-859d-f6bbb57e9c96
one.
* Also renamed the settings file to "MediaFiles" which I had previously already
renamed accidently.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34562 a95241bf-73f2-0310-859d-f6bbb57e9c96
commands used a mix of old and new transfer_area() semantics, which didn't work
out too well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34558 a95241bf-73f2-0310-859d-f6bbb57e9c96
mean crashes with the media_server version I just checked in.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34556 a95241bf-73f2-0310-859d-f6bbb57e9c96
look into this now.
* Renamed the MMediaFilesManager to MediaFilesManager.
* Got rid of its Map usage, we're using std::map now instead.
* The media_server is using an unsafe method to transfer areas from the server
to the client. I've changed this for the BMediaFiles API to use Haiku's new
transfer_area() function. However, this seems to cause the above mentioned
problems.
* Improved naming and data exchange structures used for the BMediaFiles API.
* Fixed BMediaFiles leaking its lists.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34554 a95241bf-73f2-0310-859d-f6bbb57e9c96
so that it is no longer affected by vertical scrolling. This also fixes the
problem that it was laid out too small.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34550 a95241bf-73f2-0310-859d-f6bbb57e9c96
system_time_nsecs(), returning the system time in nanoseconds. The function
is only really implemented for x86. For the other architectures
system_time() * 1000 is returned.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34543 a95241bf-73f2-0310-859d-f6bbb57e9c96
replaced the previous, somewhat complicated and inexact method of
computing the TSC conversion factor using it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34542 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed global variable _DormantNodeManager to gDormantNodeManager.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34538 a95241bf-73f2-0310-859d-f6bbb57e9c96
waits for certain events on a given page, NotifyPageEvents() wakes up
waiting threads respectively.
* Used the new feature instead of condition variables for waiting on busy
pages. We save publishing and unpublishing of a condition variable whenever
a page is marked busy. There's only something to do, if there's at least
one thread waiting in the list of the respective cache. The general
assumption is that this is only rarely the case and even if it happens,
there should be only very few threads.
* Added an apparently missing notification in cache_io(). At least I didn't
see the reason for it not being there.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34537 a95241bf-73f2-0310-859d-f6bbb57e9c96
finished yet (it's a simple list of all waiting object groups, but should be
a tree), but it might already be helpful enough.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34532 a95241bf-73f2-0310-859d-f6bbb57e9c96
TermWindow catches the exception, and quits the application in that case.
Fixed weird wrapping of the text in the about window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34530 a95241bf-73f2-0310-859d-f6bbb57e9c96
outside of Haiku's repository, only.
* Also this fixes the build break that arose when the Haiku repo was checked
out with something different than svn (git for example:), due to a hardcoded
reference to the svn entries file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34529 a95241bf-73f2-0310-859d-f6bbb57e9c96
to clarify that they never enlarge the area.
* Reimplemented VMKernelAddressSpace. It is somewhat inspired by Bonwick's
vmem resource allocator (though we have different requirements):
- We consider the complete address space to be divided into contiguous
ranges of type free, reserved, or area, each range being represented by
a VMKernelAddressRange object.
- The range objects are managed in an AVL tree and a doubly linked list
(the latter only for faster iteration) sorted by address. This provides
O(log(n)) lookup, insertion and removal.
- For each power of two size we maintain a list of free ranges of at least
that size. Thus for the most common case of B_ANY*_ADDRESS area
allocation, we find a free range in constant time (the rest of the
processing being O(log(n))) with a rather good fit. This should also
help avoiding address space fragmentation.
While the new implementation should be faster, particularly with an
increasing number of areas, I couldn't measure any difference in the -j2
haiku build. From a cursory test the -j8 build hasn't tangibly benefitted
either.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34528 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Renamed to AVLTreeBase and moved it into its own header/source file.
- Renamed FindClose() to FindClosest().
- Added CheckTree() method for debugging purposes. It checks the validity
of the tree.
* Added a templatized class AVLTree which doesn't offer a map-like interface
like AVLTreeMap, but rather one similar to BOpenHashMap and SplayTree. It
is more convenient to use, if one wants to store objects that already
contain the key.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34526 a95241bf-73f2-0310-859d-f6bbb57e9c96
necessary and prevent the structures from being used in a union.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34525 a95241bf-73f2-0310-859d-f6bbb57e9c96
- fix listing projects when there are none yet, don't use ls|sed,
- don't use source as it's bash specific, and test if the .profile exists, avoids a warning when bootstrapping a project,
- add vim as a fallback $EDITOR.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34523 a95241bf-73f2-0310-859d-f6bbb57e9c96
