No GHC v8.4.1 compatibility due to base max version requirement

[moll]

trafficstars

Hey,

Cabal on GHC >= v8.4.1 seems to fail to install fltkhs because of the custom-setup section's base max non-exclusive version of v4.11 Removing that does raise a few issues in Setup.hs that I'm working through. Have you or anyone else perhaps already done that, but not yet published their fixes?

Thanks!

[deech]

I have been mostly concentrating on the 1.4.0 branch, which includes a ton of bug fixes and sync's fltkhs with FLTK-1.4.0 which itself has a lot of bug fixes and features. I've removed that restriction there, are you able to use it?

Unfortunately it also breaks a lot of the API. It's currently under active development but I feel like the API changes are done at this point. If you're porting an existing codebase I'm happy to help you migrate.

[moll]

Ah, great. Thanks! I didn't notice there were active branches here. Fortunately a new app, so nothing to port over.

https://github.com/deech/fltkhs/commit/c7de421cf69807e53800fc75db051c4af8111b02 is sure one big commit. ^_^ I take it using it would be mostly cloning it to a local directory and cabal sandbox add-source path-to-fltkhs?

I'm new to the FLTK scene. Is FLTK v1.4 getting closer to its completion that you've decided to focus on that?

[deech]

Sorry about the commit size. I'll be cleaning that up when I release it. For now expect that Git history will change.

I've only ever done installed it with stack. I haven't documented Git workflow but basically you would clone the repo into some directory that also contains your app directory ( if you don't have a prexisting app, I recommend the starter kit ) and build them all with stack build --flag fltkhs:bundled --silent with the following stack.yaml in the root of the project directory:

resolver: lts-12.11
packages:
- fltkhs
- fltkhs-hello-world
allow-newer: true
extra-deps:
- load-font-0.1.0.2
- asset-bundle-0.1.0.0
- Cabal-2.4.0.1

[deech]

To answer your last question, yes, FLTK v.1.4 appears to be moving closer to release but the core team haven't committed to a date. For now fltkhs bundles a development snapshot which seems pretty stable.

As an aside there is also active ( and unreleased ) work going on to make fltkhs look better.

[moll]

I'll give the current branch one last go before delving to v1.4. :) It has worked without the bundled flag ever, right? I'm seeing it still try to fire up Make through dist/build/c-src/Makefile and seek FLTK's source files, even though /usr/bin/fltk-config exists and has its shared libraries under /usr/lib.

[deech]

I does work (although I haven't tried it for a while) but you're better off building it from source yourself because I've noticed that package managers don't tend to do a good job of using the right build switches etc. For example, fltkhs tries to create statically linked binaries but package managers only provide shared libs. This maybe causing the problems you're seeing. This why I included the bundled option which automates that for you.

[moll]

I do have FLTK with static libs as I just rebuilt the Arch Linux FLTK package and see its .a files... I've been staring at this (fixing Setup.hs in the current master) for some time and I can't figure it out. It feels like it should be a ten line shell script, but it is 400 lines of Haskell. ^_^ I'd like to play it conservative initially and not jump on an unreleased version of FLTK (v1.4). Usually unreleased things lack good documentation and end up being a larger time sink than the added functionality. :)

Mind quickly walking me through what Setup.hs is supposed to do, let's say, when fltk is already installed on the system? I couldn't get the bundled approach to work either in a Cabal sandbox that has fltkhs as an add-source-style dependency. I tried to mimic your v1.4 branch fixes, but something is still off.

So, in the following scenario, my understanding is as follows:

• git clone $repo fltkhs
• mkdir app && cd app && cabal sandbox init && cabal sandbox add-source ../fltkhs
• cabal install fltkhs
• This first triggers your pre-conf hook, which in turn calls autoconf in the directory of ../fltkhs and generates a configure shell script.
• Then execution is passed on to Cabal itself and that calls the generated configure not in ../fltkhs, but in ../fltkhs/dist/dist-sandbox-1616d5af/build. This creates a Makefile, c-src/Makefile and a few other files.
• Next Cabal initiates compiling (building) and calls into the build hook.
• "Thanks" to my fixes of calling make in the build directory (presumably the same ../fltkhs/dist/dist-sandbox-1616d5af/build directory), the first Makefile is loaded, which in turn loads the one in c-src/Makefile. That assumes the sources files are in its directory and fails, because they're really way-up in the directory stack. I do see you added a copy routine to the configure hook to copy the contents of c-src to the build directory. Doesn't smell like a good solution, but I can understand why you did it. When I do it, however, something, possibly autoconf or the configure script, or who knows, detects duplicate headers and deletes the contents of c-src in the repo, thereby preventing any secondary reconfiguration (or the initial install itself) from finishing. That's because after libfltkc.a is created, Cabal continues on to Preprocessing library for fltkhs-0.5.4.5.., which seems to invoke c2hs and it can't find Fl_ExportMacros.h presumably because it was looking at it in ../fltkhs/c-src and that's been emptied.

I can't help but think the problem of compiling the bindings and linking FLTK to them cannot be that complicated that it requires 440 lines of Haskell, 64 lines of autoconf that generates 4919 lines of configure script, which in turn somehow generates a 24 line Makefile which calls another 164 line Makefile and probably a bunch I'm missing. :P

I put the version of Setup.hs that I based my description above at https://github.com/moll/fltkhs/commits/master.

[moll]

Found that header removal is to be blamed on Cabal's configure at https://github.com/haskell/cabal/blob/a94364183f9a7dcb1d15de990d2d3e37c8c75980/Cabal/Distribution/Simple/Configure.hs#L1667. This is one facepalm worthy action of Cabal's --- to delete files from the source directory that a person might be working in.

[sboosali]

Wait, Cabal deletes source files?? do you know the minimal situation in which cabal will permanently delete, say, a c-src/header.h?

On Sun, Oct 7, 2018, 16:31 Andri Möll [email protected] wrote:

Found that header removal is to be blamed on Cabal's configure at https://github.com/haskell/cabal/blob/a94364183f9a7dcb1d15de990d2d3e37c8c75980/Cabal/Distribution/Simple/Configure.hs#L1667. This is one facepalm worthy action of Cabal's --- to delete files from the source directory that a person might be working in.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427684585, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMZmChI7CTzGoKzGy1EsMcii88Y5nks5uimS4gaJpZM4XLyqU .

[moll]

@sboosali, I suppose my steps above should lead you to a convoluted reproduction case. ^_^ The behavior is, after all, described in the comment above the checkDuplicateHeaders function I linked to above.

[sboosali]

yeah I read that.

Cabal tends to do things well (like being robust about supporting different platforms and compilers and such).

but does it really delete the file from your sources, rather than not copying it into the build directory and/or (say) virtually "patching" includes?

On Sun, Oct 7, 2018, 18:53 Andri Möll [email protected] wrote:

@sboosali https://github.com/sboosali, I suppose my steps above should lead you to a convoluted reproduction case. ^_^ The behavior is, after all, described in the comment above the checkDuplicateHeaders function I linked to above.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427694111, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMTbmyWuVnNWfAS-O5D34XgbQ_UJ3ks5uioXQgaJpZM4XLyqU .

[moll]

Yeah, in my tests it consistently deleted the headers from c-src from the folder path given to cabal sandbox add-source if those headers were also copied to dist like @deech's v1.4 and my quick-fixed Setup.hs do (https://github.com/moll/fltkhs/commit/bd3ec58acbf0d75f1ad8dfe42f46981874240592#diff-8288955e209cfbead5b318a8598be9c0R166).

[moll]

And that's exactly what the comment in Cabal says it does. :P

[sboosali]

btw, I wouldn't use cabal sandbox, now that cabal new-build exists (unless there's a specific reason I'm unaware of). the equivalent is adding (given the relative path to the vendored dependency from your package) it to cabal.project:

-- cabal.project

packages:
  ./

optional-packages:
  ../fltk/

On Sun, Oct 7, 2018, 19:52 Andri Möll [email protected] wrote:

And that's exactly what the comment in Cabal says it'll do. :P

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427697478, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMe7cfcHC1yMMD0jzI7sSEKulP7sdks5uipO4gaJpZM4XLyqU .

[moll]

I wish I could, but hdevtools doesn't support new-build (https://github.com/hdevtools/hdevtools/issues/55) and its type checking while saving in Vim (with Syntastic) is indispensable. https://github.com/haskell/cabal/pull/2771 says changes necessary to accommodate hdevtools aren't in Cabal yet either.

Although I wouldn't be surprised if the same Setup.hs problems described above remain with new-build. After all, it has to run for the FLTK bindings to be compiled. ^_^

[deech]

Wow, you're right, Cabal-2.4.0.1 does delete my headers. I even tried adding those files to a data-files stanza, same result.

In any case, aside from that crazy bug, I do have a working fltkhs app building from the master branch with a pre-installed ( not bundled ) FLTK. It required a few changes to Setup.hs and fltkhs.cabal and using the multi-project feature of the new Cabal. I can put that out on a branch but I can't merge with master while this bug exists.

While I agree that this project needs a good non-stack dev/deploy workflow even without bugs in Cabal it's still a lot of work to get right across platforms (especially Windows) and currently stack seems to work pretty smoothly so can we go with that for now?

Also does anyone know how to set per-project flags on the command line, cabal new-configure -f<what-goes-here>? I can't seem to figure out how to set the bundled flag on the fltkhs project.

[sboosali]

yeah, cabal new-configure -fbundled should work (or just adding the flags on every new-build). afaik, new-build just "merges" your cabal.project with any command line options previously written into a cabal.project.local, and new-configure writes to said cabal.project.local.

Can you share the cabal.project.local? For example, it should be:

flags: +bundled

On Mon, Oct 8, 2018, 08:37 deech [email protected] wrote:

Wow, you're right, Cabal-2.4.0.1 does delete my headers. I even tried adding those files to a data-files stanza, same result.

In any case, aside from that crazy bug, I do have a working fltkhs app building from the master branch with a pre-installed ( not bundled ) FLTK. It required a few changes to Setup.hs and fltkhs.cabal and using the multi-project feature of the new Cabal. I can put that out on a branch but I can't merge with master while this bug exists.

While I agree that this project needs a good non-stack dev/deploy workflow even without bugs in Cabal it's still a lot of work to get right across platforms (especially Windows) and currently stack seems to work pretty smoothly so can we go with that for now?

Also does anyone know how to set per-project flags on the command line, cabal new-configure -f? I can't seem to figure out how to set the bundled flag on the fltkhs project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427816149, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMb1kymFPnAG_v7aL8GkqgYhcxbDXks5ui0cMgaJpZM4XLyqU .with any command line options

[deech]

I'm aware of that but there has to be a way of setting it on a per project bases, stack allows fltkhs:bundled.

[sboosali]

hmmm, since these flags are passed to ./Setup configure, maybe the custom setup isn't actually receiving them properly, or isn't processing it properly?

On Mon, Oct 8, 2018, 11:13 Spiros Boosalis [email protected] wrote:

yeah, cabal new-configure -fbundled should work (or just adding the flags on every new-build). afaik, new-build just "merges" your cabal.project with any command line options previously written into a cabal.project.local, and new-configure writes to said cabal.project.local.

Can you share the cabal.project.local? For example, it should be:

flags: +bundled

On Mon, Oct 8, 2018, 08:37 deech [email protected] wrote:

Wow, you're right, Cabal-2.4.0.1 does delete my headers. I even tried adding those files to a data-files stanza, same result.

In any case, aside from that crazy bug, I do have a working fltkhs app building from the master branch with a pre-installed ( not bundled ) FLTK. It required a few changes to Setup.hs and fltkhs.cabal and using the multi-project feature of the new Cabal. I can put that out on a branch but I can't merge with master while this bug exists.

While I agree that this project needs a good non-stack dev/deploy workflow even without bugs in Cabal it's still a lot of work to get right across platforms (especially Windows) and currently stack seems to work pretty smoothly so can we go with that for now?

Also does anyone know how to set per-project flags on the command line, cabal new-configure -f? I can't seem to figure out how to set the bundled flag on the fltkhs project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427816149, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMb1kymFPnAG_v7aL8GkqgYhcxbDXks5ui0cMgaJpZM4XLyqU .with any command line options

[sboosali]

oh, for a client of fltkhs?

the cabal.project (for say fltkhs-extra) would look like (iirc):

package fltkhs
  flags: bundled
  -- or +bundled

https://cabal.readthedocs.io/en/latest/nix-local-build.html#configuring-builds-with-cabal-project

(there might be a difference between (1) the stanzas for a vendor for local dependency in packages or optional-packages and (2) normal external dependencies).

the command line invocation is more verbose:

cabal new-build --constraint "fltkhs +bundled"

(since manual-flags become constraints, I guess)

https://github.com/haskell/cabal/issues/4271

On Mon, Oct 8, 2018, 11:17 deech [email protected] wrote:

I'm aware of that but there has to be a way of setting it on a per project bases, stack allows fltkhs:bundled.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427874492, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMcEj8I_e31XFO89otoNnEW0x9Viwks5ui2xvgaJpZM4XLyqU .

[sboosali]

to clarify, all packages in a project with a --constraint "fltkhs +bundled" will use that flag for that dependency.

(also, sorry if I'm misunderstanding or being unclear, didn't sleep much last night.)

On Oct 8, 2018 11:26, "Spiros Boosalis" [email protected] wrote:

oh, for a client of fltkhs?

the cabal.project (for say fltkhs-extra) would look like (iirc):

package fltkhs
  flags: bundled
  -- or +bundled

https://cabal.readthedocs.io/en/latest/nix-local-build.html#configuring-builds-with-cabal-project

(there might be a difference between (1) the stanzas for a vendor for local dependency in packages or optional-packages and (2) normal external dependencies).

the command line invocation is more verbose:

cabal new-build --constraint "fltkhs +bundled"

(since manual-flags become constraints, I guess)

https://github.com/haskell/cabal/issues/4271

On Mon, Oct 8, 2018, 11:17 deech [email protected] wrote:

I'm aware of that but there has to be a way of setting it on a per project bases, stack allows fltkhs:bundled.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-427874492, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMcEj8I_e31XFO89otoNnEW0x9Viwks5ui2xvgaJpZM4XLyqU .

[deech]

I have pushed up a couple of fixes to a branch that work with Cabal. @moll, if you could try them out I would appreciate it.

I upgraded to Cabal 2.4.0.1, once you have that installed hopefully the following workflow goes smoothly:

# install FLTK
> wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-1-source.tar.gz
> tar -zxf fltk-1.3.4-1-source.tar.gz
> cd fltk-1.3.4-1
> ./autogen.sh
> ./configure --enable-shared --enable-localjpeg --enable-localzlib --enable-localpng
> make
> sudo make install


# create a Cabal project
> mkdir app
> cd app
> cabal init
> git clone -b Cabal2401 https://github.com/deech/fltkhs
> git clone -b Cabal2401 https://github.com/deech/fltkhs-hello-world
> cabal new-configure
> cabal new-build all
> ./dist-newstyle/build/x86_64-linux/ghc-8.4.3/fltkhs-hello-world-0.0.0.1/build/fltkhs-hello-world/fltkhs-hello-world
# The above path maybe a little different if you're not running GHC 8.4.3

[moll]

Great, @deech! Thank you! You've been a good sport! I can't promise a quick confirmation as it unfortunately turned out FLTK didn't support rendering to an OpenGL buffer, but merely created the context for it. :/ I was initially under the impression FLTK was a great little library to use in a 3D game-ish project of mine.

I did give new-build itself a try today! Definitely better than Cabal's sandbox, but I couldn't find any tool to provide type checking for it. :( Neither Hdevtools nor the newer Haskell IDE Engine (internally using ghc-mod) support it. Definitely peculiar that the tooling section of the Haskell world moves so slowly. Do either of you use anything to go with your Vim/Emacs/Non-Vim-editor?

[deech]

Re: editors, I do use Emacs but have very little tooling turned on because they're usually fairly buggy.

Re: OpenGL, does this fit your needs https://github.com/deech/fltkhs-gl-demos/blob/master/src/fluid-triangle.hs#L19? It's just the famous triangle demo, FLTK seems to be doing more than creating a context.

[moll]

I was more thinking of something in which you make your windows, buttons, pass a few keyboard and mouse events as input and get back an array of bytes to then send to the GPU. That's what I meant by "rendering to OpenGL". https://github.com/ocornut/imgui seems to be an example of that, although going with that would require me to dive into writing Haskell bindings, too. ^_^

[sboosali]

i use dante on Emacs (and new-build for all my projects).

it has fewer features than those tools, but: (1) it's very robust, requiring only a working repl; and (2) does have some features, like dante-type-at, which works for arbitrary expressions and local (!) variables.

here's a quick config:

  (use-package dante

    :init
    (add-hook 'haskell-mode-hook #'flycheck-mode)
    (add-hook 'haskell-mode-hook #'dante-mode)

    :config (defun haskell-doc-current-info ()
               (call-interactively #'dante-type-at))))

(if you're not familiar with use-package, its author is the GNU Emacs maintainer, and is merging it into Emacs bundled package).

here's my full config:

(defun haskell-doc-current-info ()
  (when (commandp #'dante-type-at)
    (call-interactively #'dante-type-at)))

;; ^ `dante'+`eldoc' integration.
;;
;; NOTE disable if too slow.
;;
;; Alternatively:
;;
;; * `dante-info': more informative, pops-up a `*Help' buffer.
;; * `dante-type-at': more concise, prints to Echo Area (like `eldoc'
should),
;;
;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun sboo-dante-cabal-new-repl (root)

  "Locate a `cabal.project' file.
  "
  (interactive)

  (when (or (directory-files root nil ".+\\.project$") (file-exists-p
"cabal.project"))

    '("cabal" "new-repl" dante-target "--builddir=dist-newdante")))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defvar sboo-dante-repl-command-line-methods-alist

  `((new-build . sboo-dante-cabal-new-repl)
    (stack     . ,(lambda (root) (dante-repl-by-file root '("stack.yaml")
'("stack" "repl" dante-target))))
    (bare      . ,(lambda (_) '("cabal" "repl" dante-target
"--builddir=dist/dante"))))

  "Override `dante-repl-command-line-methods-alist'.")

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun sboo-dante-mode ()

  "Start/restart `dante'.

  (i.e. `dante-mode' or `dante-restart').
  "
  (interactive)

  (if (bound-and-true-p 'dante-mode)

    (dante-restart)

   (dante-mode 1)))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

  (use-package dante
    :after    haskell

    :commands (dante-mode dante-restart)

    :bind (:map haskell-mode-map
                (("C-c d" . sboo-dante-mode)))

;;;  :hook ((haskell-mode . flycheck-mode)
;;;         (haskell-mode . dante-mode))

    :init
    (add-hook 'haskell-mode-hook #'flycheck-mode)
    (add-hook 'haskell-mode-hook #'dante-mode)

    :config (setq dante-repl-command-line-methods-alist
                  sboo-dante-repl-command-line-methods-alist)
    ())

On Wed, Oct 10, 2018, 17:05 Andri Möll [email protected] wrote:

I was more thinking of something in which you make your windows, buttons, pass a few keyboard and mouse events as input and get back an array of bytes to then send to the GPU. That's what I meant by "rendering to OpenGL". https://github.com/ocornut/imgui seems to be an example of that, although going with that would require me to dive into writing Haskell bindings, too. ^_^

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/87#issuecomment-428731541, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMaJ_E5q2CJ2Q0yyejhKCncY_rIyDks5ujmECgaJpZM4XLyqU .