* As per the ML discussions. Bumps MIPS to tier 3.
* We've reached a unanimous descision that MIPS doesn't
target any real / valid hardware Haiku wants to pursue
at the moment. In the event that anyone wants to pursue
MIPS, feel free to fork Haiku into your own repository
(and we'll even link to it on the website ports page)
* If someone develops a viable plan for MIPS (and gets the
port working, it can be readded at a later date)
* The label might be truncated, in which case the entire width needs to be
redrawn when the menu field shrinks or grows.
* Invalidating the border in the parent looked a bit weird. Simplified.
* Moved "Install to:" besides the "Install" button again.
* Don't right-align menu field labels.
* Give the install type description some default text when no description is
given. Give it a smaller font, align with the type menu.
This is required to use some SSE instructions, which are generated by
gcc 4.8, most notably when compiling WebKit code (but it may happen
elsewhere as well).
Fixes about 900 crashes and 10000 test failures in WebKit, so this must
be working. Fixes#10509 for x86.
... don't try to call InitPath() then.
Also replace more hard-coded paths. Added TODO about refactoring this
code and not using hard-coded paths myself, which is no better than these
scripts.
This is useless, chunked support is mandatory in HTTP1.1, and it's not a
content-encoding, but a transfer-encoding, so accept-encoding wouldn't
help anyway.
* From debugging with the Gobe and Moho installer, scripts define which
folder to run them from. The PackageInstaller is supposed to run the script
in that working directory. The parser seems to have the correct folder in
"installPath" when adding the script as PackageItem, but that code is rather
horrible. I've changed it so PackageScript items also set the path, use
InitPath() to obtain the final working directory and set it before running
the script.
* Both Moho and Gobe create the Deskbar link from that script, the folder
is rewritten in the script via ReplaceAll().
* Correctly running the script makes a bug visible: Dynamically added files
in the install location by these scripts are not removed when uninstalling
the package. When re-installing a package, it is first uninstalled and this
currently gives an error for both Moho and Gobe, since they create some
links in these scripts which never worked before. To install again, the
install folder needs to be deleted manually.
* Some cleanup along the way... sorry.
Previously, the target folder was always unset, which meant one needed
to select a target folder manually. When running from a read-only media,
this would still be a problem (a TODO), so that instead of failing to install
the package, the user is simply prompted for a path.
The change means that together with rewriting old paths to packaged
locations to the non-packaged equivalents, just double clicking a PKG and
hitting "Install" will now work. Tested with Moho installer and
Gobe Productive.
* Also auto-hide vertical scroll-bars when not needed.
* Nicer margins everywhere
* TODO: Install type description could collapse when empty or display
a default message.
* More refactoring and cleanup
The ones with ARCH extension are used for setting up the KERNEL
ones, so no need to try and set both.
Also, the verdex target was not setting the ARCH one, and therefore
never configured gcc for ARMv5.
The new version breaks git, but only once it's in the repository.
Installing it manually alongside the old one works. Rebuilding git and
uploading a new package does not work, as for the package management,
the new version is exactly equal to the old, as the port revision isn't
newer. We need to come up with a proper way to handle this.
Also removes zsh, as that requires the new libpcre.
* Use atomic_get_and_set for return value
* Atomics are no longer volatile
* Add missing arch_cpu_pause stub
* Move arch_cpu_idle to arch_cpu header to match
other architectures
* Some cards have a lot of pins!
* Should fix#10536
* Add a check to give a friendy warning if we find
more GPIO pins than what we are prepared for.
* Technically the maximum GPIO pins could be
ATOM device max * 2 (16 for i2c and other)
however lets leave some room for expansion.
