on R5 it seems a reply to a asynchronously-forwarded synchronous BMessage is the same as when no forward happens
I didn't test on Haiku, but I suspect the behavior is different, especially a _previous_ is added as for asynchronous BMessages
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17814 a95241bf-73f2-0310-859d-f6bbb57e9c96
(by linking them to haiku's libsocket.so and libbind.so). This in turn greatly
simplifies building their respective userland version as they now are the same
as the standard version.
- added ping and traceroute to install-userland-networking pseudotarget
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17717 a95241bf-73f2-0310-859d-f6bbb57e9c96
userland-networking files into a convenient place for easier testing:
+ net_server_driver and net_stack_driver are installed to
/boot/home/config/add-ons/kernel/drivers/bin and ../dev/net
+ net_stack_tester, ifconfig, arp and route are installed to
$(HAIKU_TEST_DIR)/kits/net/userland
+ libsocket, libnet, libbind and libnetapi are installed to
$(HAIKU_TEST_DIR)/kits/net/userland/lib
+ userland add-ons are installed to
$(HAIKU_TEST_DIR)/kits/net/userland/add-ons/obos_network
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17701 a95241bf-73f2-0310-859d-f6bbb57e9c96
log). Still doesn't seem to work correctly, though (but it's definitely
getting closer :-)).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17560 a95241bf-73f2-0310-859d-f6bbb57e9c96
environment: actually build it! :-)
Next step: fix the Jamfile to create the symlink to userland "obos_network" add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17520 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed Jamfile (was set to only support libbe_test).
* Fixed warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17457 a95241bf-73f2-0310-859d-f6bbb57e9c96
this is what bash is currently using (we're supposed to be posix compatible after all)
success on R5, R5 setjmp.h; fail on R5, Haiku setjmp.h (could be expected)
to be tested: on Haiku, R5 & Haiku setjmp.h
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17430 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file.
* An overlay is now also hidden in case its is removed from the window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also note that BeOS doesn't seem to pick up the cursor this way, it only
works when we're doing this later (ie. in MouseMoved() or Pulse()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16959 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note, it looks like we translate the cursor shape differently than R5
(according to the docs, black is always opaque and ignores the transparency
bits).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16958 a95241bf-73f2-0310-859d-f6bbb57e9c96
while working on the app_server should less likely happen - hopefully.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16836 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed DisplaySupport.h, wasn't needed anymore.
* Removed private color set functions from InterfaceDefs.cpp - we might want
something similar, but definitely not like that.
* Minor cleanup, added some missing licenses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16831 a95241bf-73f2-0310-859d-f6bbb57e9c96
even though we might need something similar, we can't use it (since it was
based on BGet++).
* Removed BGet++, it's not used anymore.
* Removed ServerMemIO class, was never used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16830 a95241bf-73f2-0310-859d-f6bbb57e9c96
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed another BMessageRunner leak.
* Added an optional second parameter which you can use to limit the run time
of the app.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16764 a95241bf-73f2-0310-859d-f6bbb57e9c96
connection.
StressTest now detects this case and quits those windows.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16752 a95241bf-73f2-0310-859d-f6bbb57e9c96
message they passed to a BMessageRunner object.
* Added note about the ownership of the message to the BMessageRunner
documentation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16751 a95241bf-73f2-0310-859d-f6bbb57e9c96
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_close_test_1
created port 2269
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
close port result 0x00000000 (No Error)
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 1234, size 10 (0x0000000a) (Unknown Error (10))
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 5678, size 20 (0x00000014) (Unknown Error (20))
should block now
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_close_test_2
created port 2270
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
close port result 0x00000000 (No Error)
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 1234, size 10 (0x0000000a) (Unknown Error (10))
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 5678, size 20 (0x00000014) (Unknown Error (20))
should block now
read port code 5678, size -2147479040 (0x80001200) (Bad port ID)
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_delete_test
created port 2271
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
delete port result 0x00000000 (No Error)
everything should fail now
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479040 (0x80001200) (Bad port ID)
read port code 0, size -2147479040 (0x80001200) (Bad port ID)
$
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16645 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added two more tests that exhibit the (now fixed) problem in FindLast()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16586 a95241bf-73f2-0310-859d-f6bbb57e9c96
free to continue (it would be nice to be notified before, though, in case
I get to it again in the next weeks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the test environment; the visual glitches should now be fixed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16368 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameter from a C++ to a C context doesn't work as expected (on x86).
The caller reserves 4 bytes on the stack, but initializes only the
less significant 2 of them, while the callee reads all four bytes.
A symptom was, that one couldn't remove a symlink pointing to a directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16352 a95241bf-73f2-0310-859d-f6bbb57e9c96
12 points to make sure it'll look acceptable.
* Fixed direct window rendering by disabling moving the animation area around
(would have to be changed in DirectConnected() as well).
* Refresh and density sliders now ResizeToPreferred().
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16206 a95241bf-73f2-0310-859d-f6bbb57e9c96
source directory is currently hardcoded in InstallerWindow.cpp, it could be changed in a macro
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16197 a95241bf-73f2-0310-859d-f6bbb57e9c96
The test application lets run a thread at the highest priority that calls
yield all the time - the system stays responsible when it runs, so it seems
to work fine :)
Changed the malloc implementation to use _kern_thread_yield() instead of
snoozing.
We should think about making this call public, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16166 a95241bf-73f2-0310-859d-f6bbb57e9c96
implement the B_GET_GEOMETRY command in a usable way. The bfs_shell is
able to play with partition devices under Linux, now.
* Fixed two warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16146 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server...
If you like to use it, define USE_DIRECT_WINDOW_TEST_MODE in the haiku_app_server
Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15504 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15478 a95241bf-73f2-0310-859d-f6bbb57e9c96
inline. Commented undefined virtual methods. BBitmapBuffer is still used, so
is ViewHWInterface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15472 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added B_SAME_POSITION_IN_ALL_WORKSPACES for the build under Haiku (and libbe_test)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15437 a95241bf-73f2-0310-859d-f6bbb57e9c96
