fine, at least in the context of the layout management. I am investigating
a bug though that shows at least in WonderBrush (missing Filter menu).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27284 a95241bf-73f2-0310-859d-f6bbb57e9c96
developers was based on the oloh results, but these go only 3 years back. The
SVN revision history is much more complete and contains also the CVS history
apart from a screw up at revision 10. However, I was able to obtain a much
more correct list now and so some resorting was due. According to these stats,
Michael Lotz would not appear in the list - however, I feel he should be
in there, since he was the first to run Haiku with app_server, the first to
run a browser on it, wrote the USB stack and so on. The other possiblity would
be to make the cut at 7 entries, which coincidentally would mean everyone in the
list has contributed more than 1000 commits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27279 a95241bf-73f2-0310-859d-f6bbb57e9c96
the ipc hash table lock along with the semaphore set hash table lock were
hold, thinking (wrongly) that the semaphore set lock itself was not needed.
What could happen was that another process on semop could have gained the lock
of the set itself, and then release the semaphore set hash table lock.
This would make it think that the set was still valid, while it could have
actually been deleted right after it release the semaphore set hash table lock.
Same would have happened for any other processes waiting on the semaphore set
mutex queue. By calling the lock on the mutex when deleting the set, it
*should be* safe to assume that there is no one else waiting on its queue,
since the list of waiters is handled in a FIFO way.
As far as I can see from the mutex_destroy code, it looks safe to hold the lock
when calling this function. Please confirm.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27268 a95241bf-73f2-0310-859d-f6bbb57e9c96
* more get/ set functions, operators
* date until 1582 are handled in julian calendar
* date above 1582 are handled in gregorian calendar
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27264 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Changed the copyright line to say "The Haiku project", similar to the GNU
and BSD copyrights. Then a clarifying sentence as discussed on the developer
mailing list.
* Removed the outdated Team list in favor of a "Most influential developers"
list with the top contributors of the past and the present in order of
SVN commit numbers. It could be argued that Travis should be part of this
list but he is already mentioned later with a special note. I used this
wording to indicate that it could also mention no longer active, but still
"most influential" developers. "Lead developers" or "Core developers" would
not have this aspect.
* Created a new "Website, Marketing & Documentation" section which gives
hopefully all or at least most people a more prominent mention which are
contributing most in this area. Waldemar Kornewald could be moved to this
list as well. Koki was not mentioned anywhere before, which definitely needed
to be corrected! :-)
* Maurice Kalinowski and Fredrik Modeen are now commiters.
* Added Andrej Spielmann (Subpixel Anti-aliasing) to the developers list, since
he has commit access too now.
* Added David Powell to list of contributors, for his recent patch to the
boot splash generator and boot loader.
* Added Copyright for CQuantizer (part of the mentioned patch from David)
If you have suggestions for improvements, please shoot, especially if I forgot
someone!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27262 a95241bf-73f2-0310-859d-f6bbb57e9c96
#591. The helper class could be reused for similar situations (ex: Tracker context menu and
drag detection). See the brief doc in the code. Comments welcomed!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27258 a95241bf-73f2-0310-859d-f6bbb57e9c96
for message queue
* Removed unnecessary header Vector.h
* Removed HasSemaphoreSet method: since there will be an IPC table for each
subsystem, if a key exist, it already has a semaphore set associated
with it
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27256 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented _kern_msgget()
Work in progress, some stuff may be removed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27254 a95241bf-73f2-0310-859d-f6bbb57e9c96
variable. pthread_cond_broadcast() incorrectly returned an error
when no one was waiting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27253 a95241bf-73f2-0310-859d-f6bbb57e9c96
not only the times for the child process, but also for all other
threads. Gives some more insight into what was going on in the system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27249 a95241bf-73f2-0310-859d-f6bbb57e9c96
inherit it.
* IOScheduler::ScheduleRequest() uses the request's thread and team now
instead of the current one. Otherwise for requests processed
iteratively this would always be the I/O scheduler's notifier thread.
* Also get the thread's I/O priority now. It's still ignored later,
though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27248 a95241bf-73f2-0310-859d-f6bbb57e9c96
vector at the end of the file will be aligned to the given value.
* BFS uses an alignment of 512 bytes (should be block size of the
underlying device or BFS block size, whatever is less), which should
be fine, since file data are only stored in BFS blocks. This totally
avoids any partial operations at the I/O scheduler level, thus saving
disk operations. Not that I could measure any performance difference.
Theoretically it should help a lot though, particularly when dealing
with lots of small files, since we avoid using bounce buffers, which
are (a) limited in number and (b) require copying of the data.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27246 a95241bf-73f2-0310-859d-f6bbb57e9c96
while holding down the mouse over the date area in Deskbar.
One probably needs to clean and rebuild Deskbar to get it...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27236 a95241bf-73f2-0310-859d-f6bbb57e9c96
