* When --host-only is used, HAIKU_*ARCH is undefined.
* Various architecture variables are undefined resulting
in architecture dependant code paths getting called
recursively.
(blah/Jamfile loads blah//Jamfile vs blah/x86/Jamfile)
* Another option is setting HAIKU_*ARCH to the host arch
if undefined, but that might have unintended impacts.
It fails, of course, because it hasn't been ported to the new stack.
(I made an attempt at that, but quickly wound up in code that I didn't
understand enough to migrated...)
Update all in-tree consumers of the BJson API to match. Also added
const-qualifiers to the BString versions of the API, and added the leading
"_" to the header guards.
As found on http://seriot.ch/parsing_json.php -- anything using the API
presently with valid JSON should have no troubles, but more valid JSON
that previously didn't work now does (e.g. JSON with root array nodes, not
root map nodes), and invalid JSON that silently succeeded before now fails.
Not all the bad cases from that testsuite now fail, and not all of the good
ones pass, but the few that remain are odd things that wouldn't map well to
the BMessage API (e.g. root string nodes, etc.) or are other behaviors that
make sense to leave as they are for compatibility reasons.
This change will have no effect if your FreeType was compiled without subpixel
rendering support, but since FreeType is now binary compatible between versions
with and without subpixel rendering, all you have to do after this change
is to recompile and reinstall FreeType.
This mostly reverts commit 75b219d35a.
The changes to the image URLs in Alert.dox are still needed, so I
didn't revert those.
As per discussion on the mailing list and IRC.
The existing HTTP header date format handling code is employed
rather than using specific logic for HD. Also the "Location"
header handling is changed to work better for non-absolute
URLs arriving in this header value on a redirect. Both
suggestions from Adrien.
The asynchronous listener had no reliable way to access HTTP result and
headers from the callbacks. As the callbacks are triggered
asynchronously, they can be run after the request has carried on and,
for example, followed an HTTP redirect, clearing its internal state.
The HeadersReceived callback now passes a reference to BUrlResult for
the request. There are two cases:
- Synchronous listener: passes a reference to the request's results
directly
- Asynchronous listener: archives a copy of the result into the
notification message, and passes a reference to the unarchived copy.
Unfortunately this comes with several ABI and API breakages:
- Change to the prototype of HeadersReceived()
- Change to the class hierarchy of BUrlResult (implements BArchivable)
All users of HTTP requests will need to be updated if they implemented
in HeadersReceived or used BUrlResult.
The main lock on the cookie jar must always be locked before the rwlocks
for each domain list. This was reversed in one place, leading to a
typical deadlock pattern. Fixes one case of freeze in WebPositive: two
request threads whould interlock, and then anything trying to access the
cookie jar (including the main thread of Web+ to handle javascript
access to cookies) would also lock.
