Brassica SCA [v0.2.0]

[bradrn]

So I have good news and bad news. The good news is that I've managed to compile and run the brassica GUI on Linux. The bad news is that it was extremely involved to do so, largely because (til) Windows doesn't have a distinction between position-independent and position-dependent code, which lets you get away with more creative linking than on Unixen. The easiest way for me to get it running was to compile everything with -fPIC -fPIE and then dynamically link all the Haskell dependencies, which is also the preferred distribution format for my distribution's package management system.

I’m seriously impressed that you managed to do this — without proper documentation! (I’ve been meaning to write some, but alas, haven’t gotten around to it just yet…) I find it extremely surprising that this was easier to build on Windows than Linux; in my experience, it’s usually the other way around. On the other hand, I was originally intending to link the Haskell dynamically, but gave up when I discovered this is impossible on Windows.

In many ways, it's still easier to build on Linux. I basically didn't have to do any of the steps involving passing the locations of Qt tools. It's just that the way you link the GUI on Windows is impossible on Linux, since statically linked Haskell libraries aren't position-independent and so can't be linked into a Qt program that uses dynamically linked Qt, which is the default everywhere. So my workaround was to dynamically link the Haskell, but if you do that and your main linker pass isn't controlled by GHC then you have to manually pass the location of all the Haskell dependencies to the linker. Thankfully I found a perl script that can mostly automate this...

Thanks for explaining! Could you share the Perl script please?

Follow-up question: do the Haskell dependencies end up as separate dynamic libraries each, or is all the Haskell code+dependencies compiled into one big DLL? (Yes, I know that’s not the right term for Linux, but it’s late at night and I can’t remember what I should be calling it…)

[Hallow XIII]

I’m seriously impressed that you managed to do this — without proper documentation! (I’ve been meaning to write some, but alas, haven’t gotten around to it just yet…) I find it extremely surprising that this was easier to build on Windows than Linux; in my experience, it’s usually the other way around. On the other hand, I was originally intending to link the Haskell dynamically, but gave up when I discovered this is impossible on Windows.

In many ways, it's still easier to build on Linux. I basically didn't have to do any of the steps involving passing the locations of Qt tools. It's just that the way you link the GUI on Windows is impossible on Linux, since statically linked Haskell libraries aren't position-independent and so can't be linked into a Qt program that uses dynamically linked Qt, which is the default everywhere. So my workaround was to dynamically link the Haskell, but if you do that and your main linker pass isn't controlled by GHC then you have to manually pass the location of all the Haskell dependencies to the linker. Thankfully I found a perl script that can mostly automate this...

Thanks for explaining! Could you share the Perl script please?

Sure. I found it at this blog post, which also provides a more in-depth explanation of why the script exists.

Follow-up question: do the Haskell dependencies end up as separate dynamic libraries each, or is all the Haskell code+dependencies compiled into one big DLL? (Yes, I know that’s not the right term for Linux, but it’s late at night and I can’t remember what I should be calling it…)

Unfortunately, it's separate DLLs (the Linux term is "shared object"). IIRC I ended up with five Haskell DLLs including the main Brassica DLL, plus I think two from GHC and the GHC RTS itself.

[bradrn]

In many ways, it's still easier to build on Linux. I basically didn't have to do any of the steps involving passing the locations of Qt tools. It's just that the way you link the GUI on Windows is impossible on Linux, since statically linked Haskell libraries aren't position-independent and so can't be linked into a Qt program that uses dynamically linked Qt, which is the default everywhere. So my workaround was to dynamically link the Haskell, but if you do that and your main linker pass isn't controlled by GHC then you have to manually pass the location of all the Haskell dependencies to the linker. Thankfully I found a perl script that can mostly automate this...

Thanks for explaining! Could you share the Perl script please?

Sure. I found it at this blog post, which also provides a more in-depth explanation of why the script exists.

Thanks again! Oddly enough, I did actually consult Cheplyaka’s blog while figuring out how to make Brassica… I just didn’t find that particular article.

Follow-up question: do the Haskell dependencies end up as separate dynamic libraries each, or is all the Haskell code+dependencies compiled into one big DLL? (Yes, I know that’s not the right term for Linux, but it’s late at night and I can’t remember what I should be calling it…)

Unfortunately, it's separate DLLs (the Linux term is "shared object"). IIRC I ended up with five Haskell DLLs including the main Brassica DLL, plus I think two from GHC and the GHC RTS itself.

OK, this sounds like pretty much like what I was expecting. Even statically I have to find and link the RTS separately. (I was mostly worried about ending up with one file per dependency, which would be ridiculously many.)

[bradrn]

Brassica is now online! Try it at http://bradrn.com/brassica. The desktop version is still recommended, since it’s much faster and has a few extra features, but the online one should still be very usable.

[Travis B.]

Brassica is now online! Try it at http://bradrn.com/brassica. The desktop version is still recommended, since it’s much faster and has a few extra features, but the online one should still be very usable.

I see you used ghcjs with that!

[WarpedWartWars]

Brassica is now online! Try it at http://bradrn.com/brassica. The desktop version is still recommended, since it’s much faster and has a few extra features, but the online one should still be very usable.

I hope you can add the missing features to the online version, especially since I'm not going to download the 32.7 megabyte installer. Now if you could bring that size down without sacrificing any of the features, then maybe...

[bradrn]

Brassica is now online! Try it at http://bradrn.com/brassica. The desktop version is still recommended, since it’s much faster and has a few extra features, but the online one should still be very usable.

I see you used ghcjs with that!

Oh, yes. That’s why it’s ridiculously slow and needs Nix to build. On the other hand, that’s also why it’s fully compatible with the desktop version. Everything is tradeoffs.

Brassica is now online! Try it at http://bradrn.com/brassica. The desktop version is still recommended, since it’s much faster and has a few extra features, but the online one should still be very usable.

I hope you can add the missing features to the online version, especially since I'm not going to download the 32.7 megabyte installer. Now if you could bring that size down without sacrificing any of the features, then maybe...

Some of the features can definitely be added; I’ll work on it. Making the installer smaller would be more difficult, since Qt alone takes up a substantial amount of space.

[WarpedWartWars]

I hope you can add the missing features to the online version, especially since I'm not going to download the 32.7 megabyte installer. Now if you could bring that size down without sacrificing any of the features, then maybe...

Some of the features can definitely be added; I’ll work on it. Making the installer smaller would be more difficult, since Qt alone takes up a substantial amount of space.

If you could make, say, a Python-based version, using Tkinter, you could probably get it much smaller.

[Travis B.]

I hope you can add the missing features to the online version, especially since I'm not going to download the 32.7 megabyte installer. Now if you could bring that size down without sacrificing any of the features, then maybe...

Some of the features can definitely be added; I’ll work on it. Making the installer smaller would be more difficult, since Qt alone takes up a substantial amount of space.

If you could make, say, a Python-based version, using Tkinter, you could probably get it much smaller.

You cannot just casually expect someone to rewrite their whole, highly non-trivial program written in Haskell in Python, and to do so just to make use of the misbegotten GUI framework known as Tkinter is really silly.

[WarpedWartWars]

If you could make, say, a Python-based version, using Tkinter, you could probably get it much smaller.

You cannot just casually expect someone to rewrite their whole, highly non-trivial program written in Haskell in Python, and to do so just to make use of the misbegotten GUI framework known as Tkinter is really silly.

The main benefit of Tkinter is that it comes with Python by default.

As for the Haskell>Python, If I knew Haskell and Qt, I could probably do it myself.

[Travis B.]

If you could make, say, a Python-based version, using Tkinter, you could probably get it much smaller.

You cannot just casually expect someone to rewrite their whole, highly non-trivial program written in Haskell in Python, and to do so just to make use of the misbegotten GUI framework known as Tkinter is really silly.

The main benefit of Tkinter is that it comes with Python by default.

As for the Haskell>Python, If I knew Haskell and Qt, I could probably do it myself.

So what if Tkinter comes with Python itself; just that Python comes with Tkinter is by no means justification whatsoever for rewriting a significantly-sized application written in Haskell just to use it. So to tell someone that they ought to rewrite their application in Python just because of Tkinter being available for use in Python comes off as awfully presumptuous.

[WarpedWartWars]

So what if Tkinter comes with Python itself; just that Python comes with Tkinter is by no means justification whatsoever for rewriting a significantly-sized application written in Haskell just to use it. So to tell someone that they ought to rewrite their application in Python just because of Tkinter being available for use in Python comes off as awfully presumptuous.

Please, I don't want to argue.

But as I said, if I learned Haskell and Qt, I could probably remake it in Python. No need to have bradrn remake it there.

[Travis B.]

So what if Tkinter comes with Python itself; just that Python comes with Tkinter is by no means justification whatsoever for rewriting a significantly-sized application written in Haskell just to use it. So to tell someone that they ought to rewrite their application in Python just because of Tkinter being available for use in Python comes off as awfully presumptuous.

Please, I don't want to argue.

But as I said, if I learned Haskell and Qt, I could probably remake it in Python. No need to have bradrn remake it there.

The fact that you say this highly implies that you don't know any Haskell. (For the record, I have worked in Haskell in the past.)

[WarpedWartWars]

Please, I don't want to argue.

But as I said, if I learned Haskell and Qt, I could probably remake it in Python. No need to have bradrn remake it there.

The fact that you say this highly implies that you don't know any Haskell. (For the record, I have worked in Haskell in the past.)

You are correct--I do not know any Haskell.

Edit: Except I now kind of do, since haskell.org has a little tutorial and interpreter built-in.

[Travis B.]

Please, I don't want to argue.

But as I said, if I learned Haskell and Qt, I could probably remake it in Python. No need to have bradrn remake it there.

The fact that you say this highly implies that you don't know any Haskell. (For the record, I have worked in Haskell in the past.)

You are correct--I do not know any Haskell.

Edit: Except I now kind of do, since haskell.org has a little tutorial and interpreter built-in.

It will be worth your time to learn Haskell. It is probably the most advanced (and mind-bending) language out there, short of dependently-typed languages such as Agda (which I myself have yet to wrap my brain around). It is on my list of languages that every programmer should learn* (aside from Lisp, Forth, and some sort of assembly).

* Even if you never, ever use any of these at your day job, which will very likely be the case, it is well worth it to learn these languages; conversely, my day jobs have mostly been in C, C++, Java, JavaScript, Python, HTML, and SQL, but I never learned much from any of these languages.

[bradrn]

But as I said, if I learned Haskell and Qt, I could probably remake it in Python. No need to have bradrn remake it there.

That’s impressive. I’m not sure I could, at least not without a great deal of difficulty. Haskell and Python are basically polar opposites, and converting one to the other is very highly nontrivial. It’s not like, say, converting C to Python, where programs written in the two at least have the same basic kind of structure. This program relies heavily on Haskell’s support for algebraic design, sum types and parser combinators, and I’m not sure how much of that could be converted to Python.

It will be worth your time to learn Haskell. It is probably the most advanced (and mind-bending) language out there, short of dependently-typed languages such as Agda (which I myself have yet to wrap my brain around). It is on my list of languages that every programmer should learn* (aside from Lisp, Forth, and some sort of assembly).

I second all these recommendations. Haskell, as I mentioned, is very different in structure to imperative languages like Python and C, and I’ve found learning it to be immensely helpful for thinking about problems in new ways.

(As for Agda, that’s more of a proof environment than a programming language; Idris is more programming-oriented. OCaml is probably as advanced as Haskell, but in different ways.)

[WarpedWartWars]

That’s impressive. I’m not sure I could, at least not without a great deal of difficulty. Haskell and Python are basically polar opposites, and converting one to the other is very highly nontrivial. It’s not like, say, converting C to Python, where programs written in the two at least have the same basic kind of structure. This program relies heavily on Haskell’s support for algebraic design, sum types and parser combinators, and I’m not sure how much of that could be converted to Python.

What's a parser combinator?

It will be worth your time to learn Haskell. It is probably the most advanced (and mind-bending) language out there, short of dependently-typed languages such as Agda (which I myself have yet to wrap my brain around). It is on my list of languages that every programmer should learn* (aside from Lisp, Forth, and some sort of assembly).

BTW I am currently in the middle of learning Scheme. (trying to get R5RS (I hope I didn't misspell that))

I second all these recommendations. Haskell, as I mentioned, is very different in structure to imperative languages like Python and C, and I’ve found learning it to be immensely helpful for thinking about problems in new ways.

I would gladly learn Haskell, except I am not downloading a >55 MB compiler for it.

[Travis B.]

I second all these recommendations. Haskell, as I mentioned, is very different in structure to imperative languages like Python and C, and I’ve found learning it to be immensely helpful for thinking about problems in new ways.

I would gladly learn Haskell, except I am not downloading a >55 MB compiler for it.

Those 55 MB are worth it, seriously. I'm surprised that that much data is an issue in this day and age, unless one's sole Internet connection is a cell network hotspot.

[WarpedWartWars]

I would gladly learn Haskell, except I am not downloading a >55 MB compiler for it.

Those 55 MB are worth it, seriously. I'm surprised that that much data is an issue in this day and age, unless one's sole Internet connection is a cell network hotspot.

Except my sole Internet connection is a cell network hotspot.

[bradrn]

That’s impressive. I’m not sure I could, at least not without a great deal of difficulty. Haskell and Python are basically polar opposites, and converting one to the other is very highly nontrivial. It’s not like, say, converting C to Python, where programs written in the two at least have the same basic kind of structure. This program relies heavily on Haskell’s support for algebraic design, sum types and parser combinators, and I’m not sure how much of that could be converted to Python.

What's a parser combinator?

The idea is that you can use combinators (i.e., functions) to build up bigger parsers from smaller parsers: thus, for instance, if you have parsers ‘a’ or ‘b’, you can get things like ‘a then b’, ‘either a or b’, ‘a and b in any order’, ‘a inside b’ and so forth. Brassica uses parser combinators (via the megaparsec library) to parse both sound changes and paradigms.