When installing a package, it is set to pending, which removes
the Install button from the package info area. When multiple
packages are downloaded, theould all be put to pending,
right now, they will still offer to be installed, although they
are already scheduled for downloading. Requesting a package to
be installed when it is already schduled will mess things up later.
Godm, I hate this nano bug...
...when sending the whole view state over the link.
Also inherit the fill rule when pushing states (DrawState
copy constructor). A somewhat sloppy oversight, I must add.
* I don't know what I am doing here, but the test app_server only
ever built for me recently when I disabled the define, so I might
as well commit this...
* Base class needs to check this as well because the subclass might
not override it (e.g. InitParametersPanel).
* Fixes crash when trying to initialize partition map. Thanks to
jessicah for pointing this out.
After load_image() the child thread is suspended and the parent is
expected to resume it later. However, it is possible that the parent
attempts to resume its child after it has been notified that the image
had been loaded but before the child managed to suspend itself. In such
case the child would suspends itself after that wake up attempt and,
consequently will not be ever resumed.
To mitigate that problem flag Thread::going_to_suspend has been added
which helps synchronizing thread suspension and continuation in a similar
way that "traditional" thread blocking is performed. This means that
the child should behave in a following manner: set its going_to_suspend flag,
notify the parent (i.e. any thread that may want to resume it), acquire
its scheduler_lock and suspend itself if the going_to_suspend flag is set.
The parent should follow pattern: clear going_to_suspend flag of the thread
that is about to be resumed, acquire that thread scheduler_lock and enqueue
it in a run queue if it is suspended.
Thanks Oliver for reporting the bug and identifying what causes it.
Most of the actual UserEvent work is done in DPC so that we don't have
to care about the limitations of the context in which UserEvent::Fire()
is invoked. This requires appropriate management of lifetime of UserEvent
instances to make sure that DoDPC() method is always called on a valid
object.
* Move actual definitions of respective image contents to files
underneath build/jam/images/definitions (minimum, bootstrap, regular).
* HaikuImage now only includes the image definitions for the selected
build profile and adds the Haiku packages.
* Simplified topmost Jamfile to some extent.
* Move definition of DESKBAR_APPLICATIONS and DESKBAR_DESKTOP_APPLETS
from build/jam/packages/Haiku to the respective image definition file.
* Sort and reformat several lists to make them more readable.
* Add new build profile 'minimum', which defines a minimum set of
packages.
* Introduce HAIKU_BOOTSTRAP_SOURCES_PROFILE and let it default to
'@minimum-raw'. This can be overruled in UserBuildConfig, setting
it to '@release-raw' will cause all source packages required for a
full release to be put onto the bootstrap-image.
* Add new image HaikuImageMinimum, which is meant to define the minimum
useful Haiku image (yeah, I know that's vague).
* Add HAIKU_MINIMUM_BUILD, which indicates that HaikuImageMinimum should
be used (it would be better to merge this with HAIKU_BOOTSTRAP_BUILD
into something like HAIKU_BUILD_TYPE)
* Cleanup duplicate references to basic packages - those are now added
by the topmost Jamfile (no longer referenced by the build profiles).
* This decouples the versions referenced by the architecture-specific
repository file from the actual versions available in the haikuports
branch that happens to be used for the bootstrap build.
This fixes building openssh on the bootstrap image.
The real problem is that it picks up this file instead of the histedit.h
from libedit, though. But since this include was missing anyway, it
makes sense to fix this file, too.
* That's the only one I would ever want to see (in most cases).
* I must admit that I don't really understand why the lists are created
and updated only for filtering, instead of just testing against the
package state.
* However, I also have no idea, why the NotContainedInFilter does not
work. I left it in because someone might see what I didn't, and maybe,
if the first confusion is cleared, it might even find some use.
* Before, we were putting both rigged and standard source packages
onto the bootstrap image, which caused the build to fail (because
non-rigged source packages can only be built with git available).
* BView gets SetFillRule/FillRule methods. The fill rule is part of the
view state.
* The B_NONZERO rule is the default. This is what we implemented before.
* The B_EVEN_ODD rule is the other common possibility for this, and
we need to support it to help WebKit to render properly.
- POSIX says the behavior for pthread_equal is undefined for
uninitialized arguments.
- However, gcc C++11 threads supports expects C++-compatible behavior,
that is, two uninitialized pthread_t should compare equal.
Avoids some runtime asserts in latest WebKit version.
In low latency mode the scheduler would not attempt to balance load
on not heavily loaded cores unless difference in load exceeded
kLoadDifference * 2 (i.e. 40 percentage points), which does not seem
to be good enough.
To make sure that load statistics are accurate on idle cores each time
idle thread is scheduled a timer is set to update load when current
load measurement interval elapses. However, core load is defined as the
average load during last measurement interval and idle core may be still
considered busy if it was not idle during entire measurement interval.
Since, load update timer is a one shot timer that information will not be
updated until the core becomes active again.
To mitigate that issue load update timer is set to fire after two load
measurement intervals had elapsed.
Should fix#10628. If there is a race condition with a writer getting
minimum or maximum from double ended heap may incorrectly result NULL.
Which is not expected in the most of the thread migration logic. Apart
from that, because of the race condition heap state may be observed as
inconsistent thus failing assertions.
ended heap
- Per DWARF4's specification, if a type's complete definition is
contained in a .debug_types unit, it should be referenced via the
DW_AT_signature attribute. 4.8 now actually does this rather than
setting e.g. DW_AT_attribute_origin to a signature ref, and
consequently we weren't finding said reference any more.
Gets .debug_types section support working again.
- Various other places in Debugger expect the highpc attribute to be
an address rather than an offset. As such, resolve it to one when
setting the attribute in the corresponding DIE so the resolved value
is available everywhere. Fixes variable scopes not being computed
properly, and consequently the missing variables mentioned in the
previous commit.
This gets things working properly again under gcc4.8.
- For DWARF4, lowpc/highpc can be specified as constants in addition
to addresses. Furthermore, they can also be specified such that highpc
is a relative offset from lowpc rather than an absolute address. We
weren't handling this case, which gcc4.8 is now using when emitting
version 4 debug information. Fixes another part of #10659.
There still remains a problem with regards to class/structure variables not
showing up in the local variables view.
