Semaphore::ZeroCount() on new semaphores, not on used ones. Found by Stefano, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20052 a95241bf-73f2-0310-859d-f6bbb57e9c96
Rewrote url parsing (unfinished)
Added several url types. Now it handles: ftp, sftp, telnet, ssh, finger, sh, file, beshare (to BeShare), mms, rtp, rtsp (to VLC). Some make probably more sense to add to the respective apps (BeShare, VLC...) but it's still handy for now.
Now please everyone go fix your apps to use generic url support instead of hardcoding http: :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20048 a95241bf-73f2-0310-859d-f6bbb57e9c96
does. Marcus, what problem did you encounter?
The BuildPXEstage1 actions use "as" ATM, which is not correct, since it
should actually use the target platform assembler (i.e.
cross-compilation won't work). It should be replaced by $(TARGET_CC),
but that results in the following errors, when compiling with gcc 2.95.3:
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:
Assembler messages:
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:39:
Error: missing ')'
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:96:
Error: `0x6(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:102:
Error: `0xa(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:127:
Error: `2(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:128:
Error: `0(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:147:
Error: `16(%ebx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:149:
Error: `20(%ebx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:173:
Error: `2(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:174:
Error: `0(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:298:
Error: `(%esi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:299:
Error: `(%edi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:306:
Error: `(%esi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:307:
Error: `(%edi)' is not a valid 16 bit base/index expression
For the gcc 4 configuration all but the first errors disappear. It looks
like these are bugs in older assembler version. Any reasonable
work-around?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20043 a95241bf-73f2-0310-859d-f6bbb57e9c96
Currently supported are telnet:, ssh: and ftp:. Now you should be able to click telnet://towel.blinkenlights.nl on a webpage or in Vision :)
TODO: Jamfile; handle ":port" in urls.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20037 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've tested it and it seems to work. Could someone else please confirm that everything still works well?
Hmm, I'm still wondering why Axel took the time to suggest a possible solution to me instead of fixing it himself. There must be a catch. ;)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20036 a95241bf-73f2-0310-859d-f6bbb57e9c96
by Jon Watte.
This was a tough but interesting problem. My version still isn't quite as nice
as his. I think the color generation could be improved, and I KNOW the x and y
placement of the text could be improved.
I also think it would be nice to display the full message at the bottom of the
screen (similar to ShowImage showing the file type and name in full screen
mode.)
But this is a good base to work from.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20035 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed compilation under R5.
* Made Revert more user-friendly by also allowing to revert settings to the previously active state after having pressed Apply. This only works if you didn't make new changes in the meantime. In that case, only the new changes will be reverted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20031 a95241bf-73f2-0310-859d-f6bbb57e9c96
haiku.image. It is now created when print_server or the Printers preflet
is started.
Applied coding style.
"Flattened" some nested if statements.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20030 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes bug #1005. As a result, the Disks icon will now appear in file panels
when you change that setting with a panel open.
* _ObserverList is now in the BPrivate namespace (and renamed to ObserverList).
* its BHandler map is now only temporarily used for handlers that do not belong to
a looper yet; when BHandler::SendNotices() is called, they will be transferred
into the BMessenger map.
* Invalid messengers are now removed from the map when encountered.
* Added TODO comments about a possible reference counting if a handler is added
twice to a list (right now, this will be ignored).
* All {Start|Stop}Watching() methods are now more or less safe to be used in low
memory situations (adding some items to the map can still throw an exception...).
* Renamed BHandler::InitData() to _InitData().
* Some refactoring and cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20029 a95241bf-73f2-0310-859d-f6bbb57e9c96
* we now always flush the TLBs after having unmapped some pages.
* vm_soft_fault() could traverse to a source cache while it was being collapsed
by vm_cache_remove_consumer() - this is now no longer possible as the latter
marks the cache as busy when doing so, and the former now tests this flag and
locks the cache (via the new fault_acquire_locked_source() function).
* if fault_acquire_locked_source() fails with B_BUSY, the current cache is locked
again, and tested again for the page - as it might have been moved upwards to it
with the destruction of its former source.
* The cache delivering the page for vm_soft_fault() is now locked until the end;
it can no longer go away before having actually mapped the page into the area.
* This also fixes the issue where pages would get lost as vm_soft_fault() put the
page in the active list, no matter if its cache still existed.
* Also, we now keep a reference of to a cache in case a dummy page is inserted; this
makes again sure that it doesn't go away during the execution of vm_soft_fault()
(which could even add this page to the free list...).
* divided vm_soft_fault() into several smaller functions which should make it much
more readable.
* Added a "cache_chain" KDL command that dumps the whole chain until the bottom
when giving a pointer to a vm_cache as parameter.
* now usually call vm_cache_acquire_ref() before map_backing_store(), even though
it shouldn't be really needed (I added it for debugging purposes).
* Some minor cleanup.
* NOTE: a major problem still persists: when removing a vm_cache, it's possible
that some of its pages are still mapped, and there is currently no mechanism
to get rid of these mappings! I've added TODO comments into vm_cache.c where
appropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20028 a95241bf-73f2-0310-859d-f6bbb57e9c96
tested on Qemu with aslcompiler.l => it takes more than 1m30s here, and shows a bottleneck in the kernel (the use of pipes)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20025 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also prepare uname to return the build SVN revision number,
which will work only if I could figure out how to define it from Jamfile.
Or, better, in build/jam/BuildSetup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20023 a95241bf-73f2-0310-859d-f6bbb57e9c96
Please comment if anything is wrong (esp. the Linux build).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20021 a95241bf-73f2-0310-859d-f6bbb57e9c96
huge deal but it doesn't make much sense to resize images during a slideshow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20020 a95241bf-73f2-0310-859d-f6bbb57e9c96
The "lookup" option has been removed, there is now a "-p" for a physical address, and
"-v" for a virtual address.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20016 a95241bf-73f2-0310-859d-f6bbb57e9c96
build Haiku. Uncomment it to define "-pipe" which may speed up your build process
a bit if you have enough memory (it's about 25% faster on a test case over here
with BeOS).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20015 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes the ticket #627.
Ingo, could you review ? This check might also be needed at other places.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20014 a95241bf-73f2-0310-859d-f6bbb57e9c96
cropping an image to a certain size or taking similar sized croppings from
various images (as I need to do.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20012 a95241bf-73f2-0310-859d-f6bbb57e9c96
process group. This fixes bug #996.
* As a result, the process group stuff and wait_for_child() got much simpler;
get_death_entry() and update_wait_for_any() could go away completely.
* If a team goes away, all of its children are now "reparented" to the kernel team,
instead of the team's parent - this follows common implementations (and POSIX if
I understand it correctly), but not BeOS anymore. The OpenGroup Base says this
about this topic: "If a parent process terminates without waiting for all of its
child processes to terminate, the remaining child processes shall be assigned a
new parent process ID corresponding to an implementation-defined system process."
* We wait too long in wait_test_4 which at least puts us on par with Linux; see
comment in _user_setpgid().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20010 a95241bf-73f2-0310-859d-f6bbb57e9c96
broken (see bug #996), but less broken than Be's.
Also the Linux implementation is not perfect, as test 4 reveals: it waits for a
child with a certain process group, even if there is no child around anymore (because
the last child changed its process group. However, it will still return (and report
the correct error code) once this child exits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20009 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed comment, as Haiku now behaves properly at least for most cases :-)
* Style guide update.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20007 a95241bf-73f2-0310-859d-f6bbb57e9c96
I'm considered splashing it up a bit by adding parameters for colors, etc, but
this will make a good baseline.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20005 a95241bf-73f2-0310-859d-f6bbb57e9c96
So the mechanism with the global variable did not work for R5 what caused two USB stacks and host controller drivers to be active concurrently which resulted in completely unpredictable results.
This kind-of-inelegant fix was all I could come up with, if someone has a better idea please send it this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20003 a95241bf-73f2-0310-859d-f6bbb57e9c96