Is pure lang dead?

[λambda]

what about pure in 2021?

[Albert Graef]

Hi λambda, and welcome to the list! :)

On Thu, Feb 25, 2021 at 6:15 PM λambda <kk47...@gmail.com> wrote:

what about pure in 2021?

Well, some of the OBS package builds are currently broken, sorry about that, I'll try to fix those asap.

Other than that, Pure still works with LLVM 3.5. But it definitely needs work, and I mean a *considerable* amount of work, to get it ported to the MCJIT in order to make it work with current LLVM versions, since the old JIT was abandoned in LLVM 3.6. At some point I just got fed up with LLVM constantly breaking backward compatibility in the C++ API, so I never got around to this.

Unfortunately, I'm also busy with other projects right now, and this isn't going to change anytime soon. It would be great if someone proficient with LLVM and the MCJIT would be willing to take over! Any takers?

Best,

Albert

--

Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: agg...@gmail.com, web: https://agraef.github.io/

[John Cowan]

On Mon, Mar 22, 2021 at 6:12 PM Albert Graef <agg...@gmail.com> wrote:

 

Other than that, Pure still works with LLVM 3.5. But it definitely needs work, and I mean a *considerable* amount of work, to get it ported to the MCJIT in order to make it work with current LLVM versions, since the old JIT was abandoned in LLVM 3.6. At some point I just got fed up with LLVM constantly breaking backward compatibility in the C++ API, so I never got around to this.

It doesn't look to me (though I am no expert) like MCJIT makes much sense with Pure or any other REPL-oriented language: it is not a JIT in the usual sense but a dynamic module constructor that has to process a module all at once.  So you are going to be constantly constructing modules and abandoning them.

What I recommend (and again, I may be talking through my hat) is to declare that Pure works with LLVM 3.5 and that is it.  In fact, I would simply package it with Pure, thus making Pure independent of the erratic behavior of the LLVM people.

[Eddie Rucker]

It is a shame the LLVM folks pulled the rug out from under you, Albert. Pure is one of my favorite languages.

Sent from my Galaxy

--
You received this message because you are subscribed to the Google Groups "pure-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pure-lang+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pure-lang/CA%2BrUic2_A%3DTGNX8DXOo4%2Bp%3DEqzXtm9K0XSAoMcYoOjqE5EZ00g%40mail.gmail.com.

[Albert Graef]

Hi John,

On Tue, Mar 23, 2021 at 1:08 AM John Cowan <co...@ccil.org> wrote:

It doesn't look to me (though I am no expert) like MCJIT makes much sense with Pure or any other REPL-oriented language: it is not a JIT in the usual sense but a dynamic module constructor that has to process a module all at once.  So you are going to be constantly constructing modules and abandoning them.

Yes, that's how I remember it, too. Porting would be much easier if existing functions could be updated, that's something that Pure really needs. Well, the compiler might put each Pure function into its own module, but that seems extremely wasteful, it might be inefficient since the compiler would constantly be linking gazillions of single-function modules, and in any case it would require a major reorganization of the backend.

What I recommend (and again, I may be talking through my hat) is to declare that Pure works with LLVM 3.5 and that is it.  In fact, I would simply package it with Pure, thus making Pure independent of the erratic behavior of the LLVM people.

I'll keep supporting it as long as I can get LLVM 3.5 to compile. (I'm not bundling LLVM 3.5 with Pure, though. It's a behemoth, and takes ages to compile even on modern hardware, so it makes much more sense to just supply it as a separate package. I already have these on the AUR and in my OBS builds.)

The downside is that many systems ship with their own LLVM libraries these days, since they use those, e.g., in their graphics stack. That's not generally a problem if I'm running Pure stand-alone, but guess what happens if you try to embed both Pure and those system libraries into the same application? Yep, instant crashes. ;-) That's why, e.g., I can't run Pd-Pure and Gem (Pd's 3D graphics library) at the same time in Pd, which is a big obstacle for me.

I solved that problem by porting all my important Pd stuff from Pure to Lua now. Pd-Lua is just as good as Pd-Pure, and it's a *lot* easier to maintain and get installed, no LLVM anywhere. ;-) And Lua is a really nice language, I like it a lot!

Albert

[Albert Graef]

Hi Eddie,

Long time no see! I hope that you and your family are doing well in these troubled times?

On Tue, Mar 23, 2021 at 3:07 AM Eddie Rucker <eru...@bmc.edu> wrote:

It is a shame the LLVM folks pulled the rug out from under you, Albert. Pure is one of my favorite languages.

Yeah, but I still think that it was the right, if not the only possible choice for Pure's compiler backend when I started this project. I don't really complain, LLVM is still a heaven-sent for the compiler writer. I'd be using it again, if I could stick to its C API which is much more stable. Unfortunately, that wasn't possible with Pure, the C API just didn't provide all the JIT functionality that I needed.

[Eddie Rucker]

We are all hanging in there and I hope your family is doing well. We'll have to catch-up soon!

I was awestruck with your developing ability, but still, the API must have been good for you to write what you did in that amount of time.

Eddie Rucker

Director of Institutional Research

Blue Mountain College

---

From: pure...@googlegroups.com <pure...@googlegroups.com> on behalf of Albert Graef <agg...@gmail.com>
Sent: Tuesday, March 23, 2021 10:40 AM
To: pure...@googlegroups.com <pure...@googlegroups.com>

Subject: Re: [pure-lang] Is pure lang dead?

--

You received this message because you are subscribed to the Google Groups "pure-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pure-lang+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pure-lang/CA%2BrUic3EQEcR2U0jHQcCcud%3D5MvPQHf-LxrgbQp3_D5Yd3L4sA%40mail.gmail.com.

[Albert Graef]

Dear Eddie,

Yeah, same over here, vaccination efforts are ongoing but supply is still limited (my wife already got her 1st jab, but I'm still waiting). Meanwhile we're on the rising slope of the 3rd wave rolling through Germany, same story all over again, just with a different variant. So we all try to stay safe and sane. ;-) I'm about to start teaching my 3rd teleconferencing semester, it's all a big mess!

Best,

Albert

To view this discussion on the web visit https://groups.google.com/d/msgid/pure-lang/CH2PR02MB6168A079A05E94C85A79DF25B1649%40CH2PR02MB6168.namprd02.prod.outlook.com.

[Albert Graef]

Just a quick status update:

On Mon, Mar 22, 2021 at 11:12 PM Albert Graef <agg...@gmail.com> wrote:

Well, some of the OBS package builds are currently broken, sorry about that, I'll try to fix those asap.

The bad news is that the Arch build of the llvm-3.5 package is still broken right now. I suspect that this is a compiler/linker issue, or maybe an intermittent issue with libstdc++ (STL specifically), because the package builds fine on Ubuntu 21.04 (see below) which already has gcc 10.3, while Arch is still on gcc 10.2. Fortunately, the last good build on Arch is only from April 18, so the existing packages should continue to work for a while, at least until a gcc update comes along. So I'm waiting for gcc to be updated in Arch before I look at this again, the issue might well just magically disappear at that point. This hopefully shouldn't take long, as the gcc package has already been flagged as out of date.

On the bright side, Debian and Ubuntu packages are all looking good (with some minor exceptions mentioned below), and I've added a repository for Ubuntu 21.04 (the latest Ubuntu version, released a few days ago) now. This needed some minor touches to pure-octave and pure-glpk for compatibility with the latest octave and glpk versions, hence the new releases for those two packages. I also had to update the pure-gen package to the latest version there, to accommodate the latest ghc and cabal versions.

Note that I won't bother with packages for 20.10 any more now that 21.04 has already been released. Also, I've disabled the Debian Testing and Unstable builds for now -- these are both still using gcc 10.2 at this time and exhibit the same compile issues that I also have on Arch right now.

So all in all things are still looking fairly good. The Windows (32 bit) package presumably still works, at least I haven't heard any complaints about it. I haven't checked on the Mac recently, but LLVM 3.4 is still supported there, through MacPorts, and it looks like it's going to stay that way, so Pure should continue to work there, too.

One pain point is ARM based computers, though, which are getting much more popular these days. The old JIT never worked properly there, so Pure can't support the Raspberry Pi, ARM Chromebooks, and the new Mac M1 computers. To make Pure work there will definitely require an update to the MCJIT.

Albert

[Ryan Schmidt]

On Apr 28, 2021, at 14:28, Albert Graef wrote:

> I haven't checked on the Mac recently, but LLVM 3.4 is still supported there, through MacPorts, and it looks like it's going to stay that way, so Pure should continue to work there, too.

MacPorts still has an llvm-3.4 port, but it is marked as incompatible with macOS Sierra and later. So it doesn't work on the five most recent versions of macOS.

[Albert Graef]

Hi Ryan,

On Mon, May 17, 2021 at 8:14 AM Ryan Schmidt <googl...@ryandesign.com> wrote:

MacPorts still has an llvm-3.4 port, but it is marked as incompatible with macOS Sierra and later. So it doesn't work on the five most recent versions of macOS.

Hmm, but I don't see this anywhere in the Portfile at https://github.com/macports/macports-ports/blob/master/lang/llvm-3.4/Portfile? All I know is that I'm happily running Pure using LLVM 3.4 on my OSX Mojave system right now, and have been running it on Sierra before that.

Albert

[Ryan Schmidt]

On May 18, 2021, at 10:33, Albert Graef wrote:

> On Mon, May 17, 2021 at 8:14 AM Ryan Schmidt wrote:
>> MacPorts still has an llvm-3.4 port, but it is marked as incompatible with macOS Sierra and later. So it doesn't work on the five most recent versions of macOS.
>
> Hmm, but I don't see this anywhere in the Portfile at https://github.com/macports/macports-ports/blob/master/lang/llvm-3.4/Portfile? All I know is that I'm happily running Pure using LLVM 3.4 on my OSX Mojave system right now, and have been running it on Sierra before that.

Ohh I was looking at the end of the llvm-3.4 Portfile but I didn't notice that that was inside the conditional that only applies to the clang-3.4 subport. So clang-3.4 doesn't work on Sierra and later but llvm-3.4 does still works even on Big Sur, however only on Intel. It currently fails on Apple Silicon, for which I've now filed https://trac.macports.org/ticket/63140.