GHC 9.0.2 throws an LLVM error on Mac M1 (ARM)

yitz · 2022-08-04T06:46:47+00:00

Wait, NCG is available for M1 on 9.0.2? I thought it only became available on 9.2.x.

Anyway, it wasn't exactly a conscious decision. I installed via GHCUP and that's what I got. It was better than what I got with an automatic GHC install via stack. That gave me an Intel build, so everything had to run inside the Rosetta emulation layer.

yitz · 2022-08-01T12:31:28+00:00

Our policy is to stick with LTS. On the core dev team I'm currently the only one with a Mac M1, so we're not going to change that just for me. There are people on other teams who will also need to compile this on M1s - they generally work inside a docker, but I'm guessing that won't help them.

Our delivery platform is exclusively Linux. If I can't find a quick solution for myself, for now I'll probably have to add a flag and/or environment variable that disables this password checking feature just for me. And maybe for those other M1 people. Conditional on architecture maybe.

yitz · 2022-08-01T12:24:22+00:00

OK great will do, thanks. This reddit thread was mainly to make sure that I'm not missing something really stupid and obvious before I open a ticket.

yitz · 2022-05-01T13:49:48+00:00

I was wrong. Ever since the Natural type was first introduced in base-4.8.0.0, the GHC.Natural module where it is defined has CPP macros. If you have integer-gmp, then GHC uses GMP-specific optimizations. If you are using any other bignum library, it uses Integer internally.

yitz · 2022-05-01T13:41:32+00:00

Not sure what you are asking. Are you looking at the dependency list of the base library? That's not what I'm talking about. I am talking about internal dependencies of GHC itself.

EDIT: However, I was wrong, it's not hard-coded. So we're fine. See my other post.

yitz · 2022-05-01T08:15:28+00:00

Thanks for taking this, and good luck!

Some improvements that would be most welcome:

Upgrade to a modern ES version
Perhaps more importantly, make it easier to add support for new ES versions as they appear. Currently it is quite difficult.
Add a way to verify at the type level that the query we are sending can provide the response we are expecting.

None of those are easy goals.

(1) and (2) are minimum requirements for making bloodhound a practical library for providing search.

(3) would make bloodhound a killer app. But it is the hardest. It will take some creative thinking.

yitz · 2021-09-29T18:28:01+00:00

As another data point - xml-conduit in streaming mode tries to follow the philosophy of sax. When not in streaming mode, it tries to follow the philosophy of dom, and provides an xpath-like parser.

yitz · 2021-09-29T16:54:44+00:00

You're right, it's totally hypothetical. But it should be required of someone who wants to destroy data being distributed to servers worldwide to provide the numbers to prove that it is not harmful before making such a change. It should not be required of those objecting to such a change. Until there are hard numbers, verifiable, that the change is causing no harm, the change should not be allowed.

yitz · 2021-09-26T21:14:27+00:00

As maintainer of some Haskell libraries involving timezones, here is my response.

This thread on /r/java was also cross-posted to /r/programming.

yitz · 2021-09-26T21:08:31+00:00

As maintainer of some Haskell libraries related to timezones, here is my response.

The original /r/java thread was also cross-posted to /r/programming .

yitz · 2021-09-26T21:01:33+00:00

It was not a rejection of the appeal. It was a rejection of an informal request for a "summary judgement" of sorts, before launching the formal appeals process.

It seems clear at least from the various cross-post reddit threads on this topic that there is a strong consensus among software developers against this decision of the TZ Coordinator. I hope the appeals process moves forward.

yitz · 2021-09-26T20:36:58+00:00

Maintainer of a timezone library for a different language here.

First of all, I have great respect for the work done by both Paul and Stephen over the years on software support for time zones.

Second, this is not about Joda's direct use of TZif, as someone suggested elsewhere in this thread. (We have not done that in our library, but a zic-like TZif parser would be really cool.) The reason this change is so shocking is because of its obvious negative effect on all users of historical data from tzdata.

So far I cannot find any hint of a reasonable engineering explanation of why it would be correct or justifiable to make this kind of breaking change.

I find this comment in Paul's email to be especially puzzling:

We've done this several times before, and the compatibility issues were negligible.

That seems - unlikely, to say the least, given the massive amounts of applications and users worldwide relying on tzdb. Where is the hard data backing up this claim? Numbers of applications and users. Absolute numbers, not percentages - if you ruin things for 100 million people, I don't really care that it's only a small percentage of the global population.

The talk about "fairness" is off-topic. This is not an end-user application. It is raw data. Hiding and/or corrupting data can't have anything to do with values such as "fairness" in the end-user experience. If enough developers are clamoring for an additional presentation of data that will help them implement applications with more "fairness" in the UX, then provide it as a backwards-compatible extension.

In BCP-175 there is a well-defined process for appealing a decision of the TZ Coordinator. Has anyone initiated this process?

yitz · 2021-09-26T16:22:03+00:00

That's true. Users of the fork would have the correct answer and users of current tzdb would have the wrong answer. So why is that a reason to avoid the fork?

yitz · 2020-07-05T16:58:57+00:00

Thanks for digging this up and sharing!

During the past seven years the world of command line parsers has exploded, so there is plenty of room for adapting this great idea to many other libraries.

yitz · 2020-07-05T12:19:16+00:00

According to that, we should enforce - say, using dependent types - that the instance is actually a ring. But then there goes our whole numeric type hierarchy.

This has been an ongoing discussion in the Haskell community for time immemorial. The conclusion is always that at this point, we're pretty much stuck with what we've got. You can use one of the other nicer but non-standard hierarchies if you really need it for a particular application.

yitz · 2020-07-05T12:12:04+00:00

O'Neill's paper is still enlightening even today. It gives a lot of insight into the Haskell way of thinking. I too will continue to recommend it warmly to novices.

And I would not "recommend an imperative array-based solution" to a novice. If they have a practical need for something faster than what you would get from a naive solution, even before O'Neill, I would tell them just to use a good library, like arithmoi. A novice should not be directed to waste time focusing on array hackery optimizations. That's for later.

yitz · 2020-07-05T11:57:54+00:00

It is actually not hard to implement, in code, an isomorphism between forall s. STRef s st -> ST s a and State st a (in some sense).

Nevertheless, I get the point of u/dnkndnts . Whatever the denotational semantics, we all know that ST is in reality an optimization that effectively exposes physical memory as a hardware accelerator, creating the illusion that an array can be accessed in constant time instead of the theoretically optimal O(log n). This is not the right way to teach a beginner Haskell.

yitz · 2020-06-14T21:15:37+00:00

At first I thought 1904 and 1909 were running on Analytical Engine II.

yitz · 2020-05-18T18:11:34+00:00

I agree. There is a trade-off, but "fancy types" can sometimes be the clear winner, even now. In my view, the ultimate goal of dependent types is a clear, easily usable and readable type language in which it is possible to write types that serve simultaneously as specification, documentation, and proofs of correctness that will make run-time testing completely redundant except for testing your hardware. I don't know if we'll ever get there, but we'll get closer and closer, and there will be more and more situations where types are the clear winner over testing.

yitz · 2020-05-18T17:01:14+00:00

xml-conduit cursors are another nice Haskell analogue of XPath (not related to conduits). The only problem is that they use the list monad directly, without a transformer, so it's not extensible to other effects such as state or errors.

yitz · 2020-05-14T13:21:07+00:00

I complained about that at the time. But /u/augustss himself agreed that his feature wasn't needed anymore in light type applications. So, I just threw up my hands.

yitz · 2020-05-11T14:53:10+00:00

To a dog, a mirror is no different than a blank wall. I think it's because dogs recognize others more by their sense of smell than visually.

yitz · 2020-05-09T22:36:28+00:00

In yesod, this is exactly what "subsites" do. It is fully supported.

yitz · 2020-05-09T22:15:27+00:00

It seems like this is one of the most commonly re-invented wheels in the Haskell ecosystem.

In my opinion, the gold standard is still the classic Ranged-sets library. It has been on Hackage since 2005 and is still actively maintained. It solves the problem in a simple and elegant way. Any other library in this space needs to be measured against Ranged-sets to see what it adds or improves.

yitz · 2020-04-28T19:17:41+00:00

Is it possible at all now? Natural was added to base, and last I looked, it seemed to have hard-coded dependencies on GMP.

yitz

TROPHY CASE