Source Activity

Of course we were using it from our own gdb copy... until it got deleted. Of course we were using it from our own gdb copy... until it got deleted.

Those return uintNN_t types instead of our own types, but uint32 for example is long while uint32_t isn't, giving some trouble with the PRI* macros for example on PPC. Those return uintNN_t types instead of our own types, but uint32 for example is long while uint32_t isn't, giving some trouble with the PRI* macros for example on PPC.

We don't have /sbin so... We don't have /sbin so...

BApplication::ArgvReceived() is called in the already running app in case of a silent relaunch. It is therefore enough to just post a quit message. BApplication::ArgvReceived() is called in the already running app in case of a silent relaunch. It is therefore enough to just post a quit message.

It seems like glibc also has paths.h and m4 fails to bootstrap without _PATH_BSHELL. This file really needs some cleanup btw, since most is actually irrelevant or incorrect for Haiku. It seems like glibc also has paths.h and m4 fails to bootstrap without _PATH_BSHELL. This file really needs some cleanup btw, since most is actually irrelevant or incorrect for Haiku.

In both cases ask confirmation to the user. In both cases ask confirmation to the user.

In hrev47355 a logic reversal was introduced as part of a cleanup commit which caused B_ARGV_RECEIVED to be sent only to apps with the B_ARGV_ONLY flag set instead of clear. In addition to that, don't send the B_SILENT_RELAUNCH message for apps with B_ARGV_ONLY either, as they are not supposed to receive messages after launch. This is in line with the documentation and what BRoster does. In hrev47355 a logic reversal was introduced as part of a cleanup commit which caused B_ARGV_RECEIVED to be sent only to apps with the B_ARGV_ONLY flag set instead of clear. In addition to that, don't send the B_SILENT_RELAUNCH message for apps with B_ARGV_ONLY either, as they are not supposed to receive messages after launch. This is in line with the documentation and what BRoster does.

I'm not sure the 64bit versions are really implemented though... I'm not sure the 64bit versions are really implemented though...

* Drop some messy mmu externs * Set proper page flags * Drop some messy mmu externs * Set proper page flags

* We don't change the data cache (and other) settings. Interesting to know their state on each platform. * Not used by default as it needs called after serial-init in u-boot * We don't change the data cache (and other) settings. Interesting to know their state on each platform. * Not used by default as it needs called after serial-init in u-boot

The AddOnManager was in the global namespace, clashing with application classes with the same name. The input_server has an AddOnManager of its own. When the shortcut_catcher filter was loaded by said AddOnManager, it in turn loaded libgame.so, which in turn loaded libmedia.so, where an AddOnManager was created for the global AddOnManager instance in libmedia.so. Unfortunately the wrong AddOnManager, the one from the input_server, was created. This lead to two AddOnManagers being active in the input_server which very well could be responsible for #11049 and #11280. This was a regression since the move of the AddOnManager from the media_server to libmedia.so in hrev47086. This also fits with the two tickets. I actually noticed the problem when debugging the shutdown process of the input_server, where the destruction of the wrong AddOnManager caused a deadlock with itself. The AddOnManager was in the global namespace, clashing with application classes with the same name. The input_server has an AddOnManager of its own. When the shortcut_catcher filter was loaded by said AddOnManager, it in turn loaded libgame.so, which in turn loaded libmedia.so, where an AddOnManager was created for the global AddOnManager instance in libmedia.so. Unfortunately the wrong AddOnManager, the one from the input_server, was created. This lead to two AddOnManagers being active in the input_server which very well could be responsible for #11049 and #11280. This was a regression since the move of the AddOnManager from the media_server to libmedia.so in hrev47086. This also fits with the two tickets. I actually noticed the problem when debugging the shutdown process of the input_server, where the destruction of the wrong AddOnManager caused a deadlock with itself.

* libdvdread, libdvdnav, faac * Caya built in release mode (much smaller package) * Paragui and dependencies: libsigc++ and physfs. * libdvdread, libdvdnav, faac * Caya built in release mode (much smaller package) * Paragui and dependencies: libsigc++ and physfs.

* Appearance fix spacing. * Keyboard fix spacing. * Mouse fix spacing. * Notifications fix spacing. * Fixes #5230. * Appearance fix spacing. * Keyboard fix spacing. * Mouse fix spacing. * Notifications fix spacing. * Fixes #5230.

Signed-off-by: Augustin Cavalier Signed-off-by: Augustin Cavalier

Signed-off-by: Augustin Cavalier Signed-off-by: Augustin Cavalier

Signed-off-by: Augustin Cavalier Signed-off-by: Augustin Cavalier