- Haskell-Cafe - Haskell.org

hp2pretty-0.9
by Claude Heiland-Allen 02 Aug '18

02 Aug '18

Hi all, hp2pretty[0] graphs heap profiles as SVG, much like hp2ps graphs as PostScript. I release hp2pretty-0.9[1], with support for detached keys in a separate text file with individual label images, which lets you construct a single key for multiple graphs, and also workaround the issue of truncated names (running off the edge of the image) when using the +RTS -L option. I applied the same principle to the titles, they can now be omitted from the images and added as captions in a surrounding document if desired. The examples/ folder shows how to embed the output in PDF[2] using the LaTeX 'svg' package (which calls out to 'inkscape'). There's also an HTML5[3] example. Because one can now create PDF output from SVG, the vapourware plans for other output formats have been dropped. Get it from Hackage[4], use `cabal unpack hp2pretty` to access examples. Or browse the git repository[5]. Thanks, Claude [0] https://mathr.co.uk/blog/hp2pretty.html [1] https://mathr.co.uk/blog/2018-08-01_hp2pretty-0.9_released.html [2] https://mathr.co.uk/hp2pretty/0.9/report.pdf [3] https://mathr.co.uk/hp2pretty/0.9/report.html [4] https://hackage.haskell.org/package/hp2pretty [5] https://code.mathr.co.uk/hp2pretty -- https://mathr.co.uk

1 0

why different type variables enforce different types?
by Rui Azevedo 02 Aug '18

02 Aug '18

after using haskell for a while i was surprised by this little thing f::a->b f a=a and this is not making sense to me till now, so please can someone enlighten me, why does haskell assume that b can not be the same type of a? after all having two distinct math variables does not mean they can not have the same value. I know i could use f::a->a, but its not the same thing, on this last case I'm requesting them to be the same type, but on the first I'm not forbidding it, is there a math reason behind it? would type inference be rendered impossible if considering the case of them being equal? thanks Rui Azevedo (neu-rah)

3 2

JOB | Permanent Java Developer (Montreal, Canada)
by James Tobin 01 Aug '18

01 Aug '18

Hello, I'm working with an employer that is looking to hire (for their Montreal office) a permanent Java developer that has extensive hands-on Java coding experience. Consequently I had hoped that some members of this mailing list may like to discuss with me further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

4 3

JOB | Permanent Java Development Manager (Montreal, Canada)
by James Tobin 01 Aug '18

01 Aug '18

Hello, I'm working with an employer that is looking to hire (for their Montreal office) a permanent development manager that has extensive hands-on Java coding experience. Consequently I had hoped that some members of this mailing list may like to discuss with me further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

1 0

Missing common function for Maybe types
by Marc Busqué 31 Jul '18

31 Jul '18

Hi! I have two functions: ``` foo :: a -> Maybe b bar :: a -> Maybe c ``` >From which I want to build a higher order function: ``` foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c ``` The implementation I need is: ``` foobar x f g = case (f x) of Nothing -> g x Just y -> Just y ``` I'm a bit surprised that looking at hoogle I don't find a built-in solution for this quite common need for `Maybe` types (or perhaps for any monad). Am I looking in the wrong way? Does it exist a similar abstraction but with a different shape? Thanks in advance, Marc Busqué http://waiting-for-dev.github.io/about/

7 16

Testing a collision detection system
by mpevnev＠gmail.com 30 Jul '18

30 Jul '18

As a part of a project, I write a collision detection system. It is in dire need of testing, but designing and writing tests for all possible pairs of types of colliding geometry would be a pretty big effort - not only I would have to calculate the fact of collision manually for 20-something pairs of types of colliding geometry, I would also have to do so multiple times for each pair, since each pair requires several test cases. So the idea is to use an existing collision detection library to generate (a lot of) test cases from random data. I've found two such libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings aren't documented at all, and HODE (which isn't really documented either, but at least lists available functions) is extremely ugly with IO all over the place, and manual tracking of objects' lifetimes (at least that's what I infer from `create :: World -> IO Body` and `destroyBody :: Body -> IO ()`, because again - no documentation). So my question is: does anyone know a library I could use? I'll pretty much settle for whatever. -- Michail.

5 4

using Haskell more like scripting language
by Dennis Raddle 29 Jul '18

29 Jul '18

I'm actually working in Purescript, but the issue is pretty much the same as one would encounter in Haskell. My application (animation of math-related ideas) is changing constantly. It's research, and I don't know where I'll be with it next week, or even tomorrow. For instance, the kinds of "objects" I'm animating (numbers, equations) and the way they move and interact with each other is a research project, and I'm constantly ripping out parts of my application and scavenging them for variations on a theme. My objects need state. At this point I'm thinking of just putting the state into a map with strings as keys and some kind of sum type to represent each data item I might need. So if I want to represent that an object has a particular color and position and velocity, itemState = M.fromList [("color" , DataColor blue ) ,("position", DataPoint 500.0 100.0) ,("velocity", DataVector 50.0 45.0 ) ] Which starts to look more like a dynamically-typed scripting language. But it's not hard to work with. I can uses lenses/prisms to inspect and update state, and it's okay if my program crashes on encountering malformed state. What this lets me do is create new objects that mix and match parts of old objects, and copy and paste a lot of the code. Is there a better way to do this? Is there a compromise I can make that will allow the compiler to help me out more with finding errors at compile time? D

4 4

stack test hangs when using 1.7.1 but completes with 1.4.0
by Olaf Klinke 29 Jul '18

29 Jul '18

Dear cafe, I recently upgraded (with some trouble) to stack-1.7.1 from 1.4.0. I have an older project using lts-9.2 that builds just fine when using the new stack, but it hangs on `stack test`. The difference is shown below. I suspect it is something that needs to be upgraded alongside stack. Maybe Cabal? Upgrading stack was troublesome because of different index formats, which is why using the other stack causes the rebuilds of my extra-deps, I suppose. When using stack --verbosity debug I see messages of the form Error while decoding $HOME/.stack/indices/Hackage/01-index.cache ... (this might not be an error, when switching between stack versions) Any help welcome. Olaf $> /usr/bin/stack-1.7.1 test Populated index cache. $MYPACKAGE: unregistering (missing dependencies: glpk-hs) gasp-1.0.1.0: unregistering (old configure information not found) glpk-hs-0.5: unregistering (missing dependencies: gasp) gasp-1.0.1.0: configure gasp-1.0.1.0: build gasp-1.0.1.0: copy/register glpk-hs-0.5: configure glpk-hs-0.5: build glpk-hs-0.5: copy/register $MYPACKAGE: configure (lib + exe + test) Configuring $MYPACKAGE... $MYPACKAGE: build (lib + exe + test) Preprocessing library $MYPACKAGE... <<< some more output ... >>> Registering $MYPACKAGE... $MYPACKAGE: test (suite: $PACKAGENAME-test) <<< with --verbosity debug >>> [debug] Run process within $PACKAGEDIR/: $PACKAGEDIR/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/$PACKAGENAME-testStub/$PACKAGENAME-testStub @(src/Stack/Build/Execute.hs:1711:27) Progress 1/2: $MYPACKAGE <<< Hangs from here on, does not consume CPU cycles >>> $> /usr/bin/stack-1.4.0 test Populated index cache. $MYPACKAGE: unregistering (missing dependencies: glpk-hs) gasp-1.0.1.0: unregistering (old configure information not found) glpk-hs-0.5: unregistering (missing dependencies: gasp) gasp-1.0.1.0: configure gasp-1.0.1.0: build gasp-1.0.1.0: copy/register glpk-hs-0.5: configure glpk-hs-0.5: build glpk-hs-0.5: copy/register $MYPACKAGE: configure (lib + exe + test) Configuring $MYPACKAGE... $MYPACKAGE: build (lib + exe + test) Preprocessing library $MYPACKAGE... <<< some more output >>> Progress: 3/4+++ OK, passed 100 tests. <<< some more output >>> Completed 4 action(s).

2 1

Monad Reader pubs?
by Donald Sitompul 28 Jul '18

28 Jul '18

I’m looking for past publications of the Monad Reader, where are they now? Donald Sitompul

2 1

Re: [Haskell-cafe] Why does this result in a runtime loop instead of a type error or typechecker loop?
by Anthony Clayden 26 Jul '18

26 Jul '18

On Thurs, Jul 26, 2018 at 05:39:00, Emil Axelsson wrote: >> Den 2018-07-26 kl. 01:02, skrev Anthony Clayden: >> >>> * On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote: *>*>> This seems like the canonical illustration of the dangers of * >>>* UndecidableInstances.* >> >>* No I don't buy that explanation. The worst UndecidableInstances can do * >>* is send the type checker into a loop.* > I used to have a counter-example to that claim: https://mail.haskell.org/pipermail/haskell-cafe/2010-January/072357.html > That example was causing looping dictionaries at run time on GHC 6.10. > But now, on GHC 8.2, the program terminates. 6.10 was rather a long time ago. The whole type inference/improvement engine has had several overhauls since 2010. To be clear: you can write looping programs without type classes at all -- such as mutually recursive functions. You can write looping programs with type classes -- by turning those functions into methods in classes. You can write looping programs with type classes that need `UndecidableInstances` -- by making those classes mutual superclasses or mutual constraints on instances. That doesn't mean the `UndecidableInstances` are to 'blame' for the looping. I would blame the functions/method calls for not reducing the problem. > But one wonders if there are other ways to create looping dictionaries? With `UndecidableInstances`, yes there's plenty. And I expect that'll make the typechecker loop at compile time. The O.P. here is not getting typechecker looping, so I think the explanation is to do with method calls -- for which we need to see what's going on in the imports. AntC

1 0