News aggregator

[Announcement] FLTKHS - Bindings to the FLTK GUI Toolkit

Haskell on Reddit - Sun, 04/12/2015 - 9:49am

I'm pleased to announce the first release of Haskell bindings to the FLTK GUI toolkit.

It now works smoothly on Windows (64-bit), Linux and Mac allowing you to create truly cross-platform native GUI applications in pure Haskell and deploy statically linked executables with no dependencies.

Most of the FLTK API is covered except for a few minor widgets which I plan to get to in the next release.

Motivation behind the package and installation instructions are found in the Haddocks. And to get you started it ships with a number of demos.

If you have any issues please report them on the Github page.

I'd also love any other feedback so feel free to comment here or email me at the address listed on the Hackage page.

Hope you enjoy!

submitted by deech
[link] [9 comments]
Categories: Incoming News

Dealing with GHC 7.10 prelude imports

haskell-cafe - Sun, 04/12/2015 - 8:55am
Hi, I've run into a couple of cases when attempting to support multiple GHC versions in my libraries (7.6.3 -> 7.10) where I've repeatedly made mistakes due to being warned about unused imports for various modules that are now part of the Prelude such as Data.Monoid, Data.Foldable, etc. which I subsequently remove either manually or via editor automation sufficiently indistinguishable from magic. This then results in successful compilation on 7.10 and failure on earlier versions of GHC due to missing imports (ie. Data.Monoid (mappend, mempty)), which prior to my current workflow of manually building on multiple versions of GHC before releasing a new version, manifested once or twice only after uploading to Hackage. Now this is all user/workflow error on my part, but I wondered if others have some kind of trick up their sleeve for avoiding these kind of issues? I could attempt to tailor the compiler's warning flags appropriately, but it bodes ill for spotting genuinely unused imports. Cheers, Brendan ____
Categories: Offsite Discussion

SIMD

glasgow-user - Sat, 04/11/2015 - 5:44pm
What’s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD <https://ghc.haskell.org/trac/ghc/wiki/SIMD> but I get Dominic Steinitz dominic< at >steinitz.org http://idontgetoutmuch.wordpress.com _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

Proposal for a generic showIntAtBase

libraries list - Sun, 04/05/2015 - 5:46pm
Hi, The current implementation of showIntAtBase in Numeric is limited to Chars currently. *showIntAtBase* * :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* The 2 reasons for this constraint is: a) We only accept functions of the form (Int -> Char) b) An implicit concatenation using (:) I'd like to propose a new function showIntAtBaseGeneric that removes the (Int -> Char) function constraint and takes an additional function to replace the implicit (:) operator. *showIntAtBaseGeneric* * :: (Integral a1, Num b, Show a1) =>* * a1 -> (b -> a) -> (a -> s -> s) -> a1 -> s -> s* Now showIntAtBase may be implemented as: *showIntAtBase :: (Integral a, Show a) => a -> (Int -> Char) -> a -> ShowS* *showIntAtBase base toChr n0 r0 = showIntAtBaseGeneric base toChr (:) n0 r0* The API and behavior of showIntAtBase remains unchanged while allowing for generic conversions not limited to Chars alone. *Example: * *λ> showIntAtBaseGeneric 26 id (:) 500 [] -- convert 500 to base26 and provid
Categories: Offsite Discussion

A Random Strawman

libraries list - Sat, 04/04/2015 - 6:57pm
Hello All, Having skimmed the literature, run some tests and benchmarks: The current System.Random is broken: https://github.com/haskell/random/issues/25#issuecomment-87423142. Furthermore, this is recorded in at least two published papers: http://dl.acm.org/citation.cfm?id=2660195 and http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf. The tf-random package does not have this breakage and is based on good theoretical foundations. In my tests tf-random performs better than System.Random. As a result of which, I am very much inclined to suggest we replace the code in System.Random with tf-random. Before doing any more work on this, I’d like to understand what the next steps should be. How much review should be carried out? I have no reason to doubt the implementors have done a great job but should someone (who?) review the code more formally. If so what would the process / tools be? Tests in packages / applications may now fail as the (pseudo) random numbers will be different w
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News