I'm not sure what you mean by this. `cabal-install` is quite deterministic; you can even freeze the index date for full build plan determinism.
The largest challenge in this area is the fact that core libraries' interface sometimes change. Our [head.hackage](https://gitlab.haskell.org/ghc/head.hackage/) infrastructure is one way of addressing this. I agree that it would be great to leverage `head.hackage` to test GHC against a larger body of packages.
GHC is indeed a large piece of software and, like all software, has its share of bugs. Some of these bugs are indeed attributable to GHC's complexity or, rather, the complexity of its domain: compiling high-level languages to efficient machine code is not easy. To determine whether GHC is too complex we need a definition of what constitutes "too complex". I think a reasonable definition would be "too complex to be managed via abstraction". In general I think GHC does a reasonably good job here. There is a reason why Haskell programs passes through four different intermediate languages as it works its way through GHC. Each of these languages, and associated compiler passes, can focus on a specific set of needs constrained by a specific set of invariants.
Where this approach to encapsulating complexity can fall short is where we must maintain hard-to-check relationships between the state of the machine at runtime and the compiler. This is the source of many of the bugs which are most readily attributable to GHC's complexity (e.g. [#13615](https://gitlab.haskell.org/ghc/ghc/-/issues/13615) and [#14346](https://gitlab.haskell.org/ghc/ghc/-/issues/14346) come to mind here).
However, the sign-extension issue noted in this thread is, in my opinion, not one of these issues. In many ways it is a very boring bug, arising from a simple misunderstanding of the semantics of a function in the code generator (namely, that `getSomeReg` isn't guaranteed to return a fresh local register). There are a number of ways that this could have been caught: better code review, more thorough tests, better use of type safety in the backend. It's certainly an serious (and, frankly, embarrassing) bug, but I don't think it is a sign that the compiler has accrued more complexity than can be managed.
That is correct. The problem is only triggered by very particular patterns of integer operations which happen to get lowered to C-- where an operand is bound to a local register; this register then gets inappropriately mutated by the code generated by the backend.
As you say, GHC, like most language implementations, has an extensive [testsuite](https://gitlab.haskell.org/ghc/ghc/-/tree/master/testsuite) (10k tests which result in over 30k testcases). Sadly, none of these tests covered this particular case.
Moreover, we also have a systematic [property testing framework](https://gitlab.haskell.org/ghc/test-primops) testing the backends and primitive operations provided by the compiler. This testsuite also didn't test this form of program since it focuses on testing the expression fragment of the Cmm language (and therefore won't generate local register bindings). This is a blind spot that I am going to look into addressing.
> The iterative version in a number of languages is 10 lines, but the functional version needs some way of drilling down into an array in a mutable way (a monad) in order to make it match the iterative in performance
Sure, but IMHO the monadic code necessary to implement something like Arnoldi is neither harder to write nor uglier than the same implementation in an imperative language.
If anything, this highlights a strength of the language: we can capture an imperative idea in a functional setting, and even have the ability to nicely isolate the mutability from the rest of our functional program (with `ST`).
As someone who recently, despite my better judgement, dropped a non-negligible amount of money on a 802.11ac adapter bearing a Broadcom chipset, I will readily say that I will never buy another of their wireless products again. I had assumed that their increased activity on the `brcm[fs]mac` drivers signaled a possible improvement in their efforts on Linux driver support.
Well, this may or may not be true, but the best drivers in the world won't do a thing if the vendor forgets to release compatible firmware. That's not to say that the firmware doesn't exist: if you are willing to strip an image out of an access point firmware image then you can bring the card into a somewhat functional state, but, as expected, it's far from perfect. Namely, WPA rekeying appears to be broken, rendering the device useless for my application.
I've been in contact with the vendor; the most precise release date for the firmware I've been able to get is (paraphrasing) "maybe someday".
If you are considering the XPS 15, you might also look at the E7470. I have been using one of these as my primary machine for several months now and have been quite impressed. The high-DPI display is fantastic, it's built like a tank, and I've had no compatibility issues whatsoever after a firmware upgrade. Moreover, it runs at a reasonable temperature and I can get 7 hours out of the battery if careful (`killall -STOP firefox` is a must, unfortunately).
The only minor annoyance was the lack of driver support for the Alps touchpad hardware. Thankfully, after poking and prodding enough people I was able to get specifications and implement driver support. I do wish that Dell, et al would be more proactive in pushing their vendors to merge driver support but oh well.
Give the Latitude E7470 a shot. I recently switched to one with very similar specs to the XPS 13 and have been very happy with it: Great screen, solid keyboard, 7 hour battery life, and built like a tank.
> I'm looking forward to trying out the new debugging support: gdb was unusable with older GHCs.
Indeed; it should be slightly better now but as the documentation says, there are still plenty of rough edges. I certainly wouldn't recommend it for day-to-day use. I have a patch set in the works which ought to fix the remaining issues so hopefully 8.2 will finally be usable.
However, in my experience the implicit callstack functionality along with the ability to provide callstacks from profiling information greatly reduces the need for DWARF unwinding for debugging (low-cost profiling, on the other hand, it may still be quite useful for).
Most (essentially all) personal electronic devices charge with a fixed supply voltage (often 5 volts) and will draw up to some current. The product of current and voltage is power. Since we have fixed voltage, the power rating of an adapter is really telling you how much current it is capable of sourcing. For instance, in the case of a 12 Watt 5V adapter, the supply is capable of providing up to 2.4 Amperes of current. That is to say, the supply only guarantees it can keep its output at 5V if the device draws less than 2.4A of current. If the device draws more the voltage may sag which may cause the charge process to terminate.
What this means for your question is this: all other things being equal, the power rating of the adapter makes no difference to the charging process. So long as the device does not draw more current than the adapter is capable of supplying the charge process will proceed at the same rate.
The largest challenge in this area is the fact that core libraries' interface sometimes change. Our [head.hackage](https://gitlab.haskell.org/ghc/head.hackage/) infrastructure is one way of addressing this. I agree that it would be great to leverage `head.hackage` to test GHC against a larger body of packages.