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.
It definitely _can_ be deterministic, but my experience of pulling down packages without a frozen index is that it rarely compiles. This, inevitably is because the plan depends on the current state of hackage. A combination of “it might pick a different minor version”, “different versions can cause cascading effects”, “many libraries have breaking changes” and “Haskell is extremely unforgiving of potential breaks” makes it very difficult to use without either a) being really good or b) downloading a freeze index. (I download freeze indexes.)
The whole core libraries thing is difficult, in that I can see it’s a real problem for everyone constantly updating their packages (and consuming them), but also that most of the changes are actually good ideas.
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.
I think you're thinking of CommonMark. That link format isn't valid in canonical Markdown either (just to some of the common variants that also went by "Markdown").
I was always partial to the variants that could do citations well. They would automatically link-ify items postfixed by [1] etc with the link included at the citation at the bottom. I implemented a customer facig newsletter system at one job using that, where it automatically made the emails multipart when markdown was submitted, with the text part being raw Markdown. When using citations, it's still very readable.
I thought CommonMark was the attempt to standardize Markdown. Besides that, every markdown implementation I've touched since before CommonMark supported [text](url) format.
Actually, I'm totally wrong. I thought this wasn't part of the original spec for some reason, but it's totally in Gruber's list of features and works in Markdown.pl, I just missed it when checking to confirm originally (I saw automatic links and missed the other links feature).
Thanks for causing me to look again (I used babelmark[1] to check what versions supported it and noticed all of them do, including Markdown.pl). I dislike putting out wrong information. :/
> 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`).
It doesn't appear that Canonical JSON does anything about redundant escape sequences in JSON. I'm still looking into it to be sure. This is a big part of the motivation behind the Son spec, and represents about half the EBNF: https://github.com/seagreen/Son/blob/master/son.ebnf#L19
For anyone else who knows of more JSON subsets, if you report them here: https://housejeffries.com/page/7 it would be really appreciated. I definitely don't want to do duplicate work.
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).
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.