...Unfortunately, after a little bit of testing and a lot more thought and consideration, I've realized there really isn't a way to do this without doubling the allocation. Ouch.
Followup to these two commits:
02617a854dad3a632927
In the second commit, the buildBuffer call in HTTPRequest was
found to conflict with the way local requests are made, with the
bytes being set directly. So buildBuffer was moved to NativeHTTPRequest
instead. Upon promise completion, now, the value of bytes should always
be correct, and buildBuffer need not be called.
But buildBuffer is called again in NativeHTTPRequest.loadText. For local
requests, this will lead to the same problem that the second commit
fixed (presumably), and for network requests, this leads to the nulled
out buffer being accessed a second time, resulting in a crash.
So since the received value of bytes is already correct and buildBuffer
is harmful, the buildBuffer call is removed from loadText.
Both local and network requests are happy now!
The HashLink executable expects hlboot.dat and libraries to be in the current working directory (it's not enough for them to be in the same directory as the executable). Make the .app file launch a shell script that 1) changes the current working directory 2) launches the HashLink executable
This change places the focus on the one known use case, while clearing
up potential confusion caused by similar-sounding classes that function
totally differently.
This is recommended as a best practice, though AFAIK this only matters
for projects that are going to be imported by other projects.
For instance, you used to be able to include `:deps:extension-api` by
including any extension that depended on it. Now, every project that
wants to use `extension-api` has to include it directly. (Which is fine
because in practice, they all already do so.)
vorbisFile.timeTell() returns the current decoding offset in seconds,
and it's updated each time vorisFile.read() is called. Since data is
buffered by calling vorbisFile.read() multiple times, the associated
time values also need to be preserved in order to get the correct time
offset.
Without this change, getCurrentTime() will return some time in the
future relative to the amount of buffered data.
