No GHC v8.4.1 compatibility due to base max version requirement #87
Comments
|
I have been mostly concentrating on the 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. |
|
Ah, great. Thanks! I didn't notice there were active branches here. Fortunately a new app, so nothing to port over. c7de421 is sure one big commit. ^_^ I take it using it would be mostly cloning it to a local directory and I'm new to the FLTK scene. Is FLTK v1.4 getting closer to its completion that you've decided to focus on that? |
|
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 |
|
To answer your last question, yes, As an aside there is also active ( and unreleased ) work going on to make |
|
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 |
|
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, |
|
I do have FLTK with static libs as I just rebuilt the Arch Linux FLTK package and see its Mind quickly walking me through what So, in the following scenario, my understanding is as follows:
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 I put the version of |
|
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. |
|
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 ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMZmChI7CTzGoKzGy1EsMcii88Y5nks5uimS4gaJpZM4XLyqU>
.
|
|
@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 |
|
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"
`include`s?
…On Sun, Oct 7, 2018, 18:53 Andri Möll ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMTbmyWuVnNWfAS-O5D34XgbQ_UJ3ks5uioXQgaJpZM4XLyqU>
.
|
|
Yeah, in my tests it consistently deleted the headers from |
|
And that's exactly what the comment in Cabal says it does. :P |
|
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 ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMe7cfcHC1yMMD0jzI7sSEKulP7sdks5uipO4gaJpZM4XLyqU>
.
|
|
I wish I could, but hdevtools doesn't support Although I wouldn't be surprised if the same |
|
Wow, you're right, In any case, aside from that crazy bug, I do have a working While I agree that this project needs a good non- Also does anyone know how to set per-project flags on the command line, |
|
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 ***@***.***> 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<what-goes-here>? 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMb1kymFPnAG_v7aL8GkqgYhcxbDXks5ui0cMgaJpZM4XLyqU>
.with any command line options
|
|
I'm aware of that but there has to be a way of setting it on a per project bases, |
|
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 ***@***.***> 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 ***@***.***> 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<what-goes-here>? 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
> <#87 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ACNoMb1kymFPnAG_v7aL8GkqgYhcxbDXks5ui0cMgaJpZM4XLyqU>
> .with any command line options
>
|
|
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)
haskell/cabal#4271
…On Mon, Oct 8, 2018, 11:17 deech ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMcEj8I_e31XFO89otoNnEW0x9Viwks5ui2xvgaJpZM4XLyqU>
.
|
|
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)
haskell/cabal#4271
…On Mon, Oct 8, 2018, 11:17 deech ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMcEj8I_e31XFO89otoNnEW0x9Viwks5ui2xvgaJpZM4XLyqU>
.
|
|
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: |
|
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 |
|
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. |
|
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. ^_^ |
|
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 ***@***.***> 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
<#87 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMaJ_E5q2CJ2Q0yyejhKCncY_rIyDks5ujmECgaJpZM4XLyqU>
.
|
Hey,
Cabal on GHC >= v8.4.1 seems to fail to install fltkhs because of the
custom-setupsection'sbasemax non-exclusive version of v4.11 Removing that does raise a few issues inSetup.hsthat I'm working through. Have you or anyone else perhaps already done that, but not yet published their fixes?Thanks!
The text was updated successfully, but these errors were encountered: