- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Find a point inside (x,y,z) -> Bool
by Olaf Klinke 31 Oct '15

31 Oct '15

Martin, this may be impractical performance-wise, but Haskell offers magic data structures for searching. Have a look at Martin Escardo's blog post [1] on infinite search in finite time. There is a package on Hackage [2] implementing it. The `shapes` you get are compact, non-empty subsets of types. If you have a shape shape :: Data.Searchable.Set a then Data.Searchable.search (const True) shape will return some element of your shape. As far as I know nobody has ever used this data structure for solid geometry. You'd need to combine it with some implementation of exact reals [*] to have geometry in a product of closed intervals. A downside is that general intersections don't exist, since the shapes must be non-empty. But since images of searchable sets are searchable, you could define complicated shapes by starting with a simple one and distort it with a function. If your type of space is discrete, then the search function might resort to brute force enumeration if the shape was defined that way. -- Olaf [1] http://math.andrej.com/2008/11/21/a-haskell-monad-for-infinite-search-in-fi… [2] http://hackage.haskell.org/package/infinite-search [*] As far as I am aware there is no appropriate package on Hackage, but Haskell implementations exist in several theses.

1 0

Re: [Haskell-cafe] haskell-ide repository name
by Alan & Kim Zimmerman 31 Oct '15

31 Oct '15

This post generated some discussion on the mailing list(s) [1],[2] and on reddit [3]. The straw poll [4] garnered (as of time of writing this mail) 138 votes, broken down as ghc-ide-engine 56 votes 41% ghc-ide-service 43 votes 31% haskides 19 votes 14% ghc-ide-daemon 16 votes 12% something else 4 votes 3% So it seems -ide-engine is the favourite In a bait-and-switch operation, I think it makes sense to keep the current "haskell-ide" prefix, and so rename it to haskell-ide-engine This has the advantages of a) The prefix is the same, so continuity is slightly better b) It does not mentally shut out any tooling constructed using other compilers/techniques, such as haskell-src-exts If anyone feels strongly that this is wrong, please let me know. Regards Alan [1] https://mail.haskell.org/pipermail/haskell-cafe/2015-October/121965.html [2] https://groups.google.com/forum/#!topic/haskell-ide/hI3MzXbwqTo [3] https://www.reddit.com/r/haskell/comments/3qh19i/rename_haskellide_project/ [4] http://strawpoll.me/5842105/r On Mon, Oct 26, 2015 at 11:06 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > At the moment the repository/project is called haskell-ide > > This leads to the impression that it is an IDE. > > It is actually a backend/server to provide services for an IDE > > We are considering changing the name. > > The options are > > haskides / ghc-ide-daemon / ghc-ide-service / ghc-ide-engine > > Please cast your vote at http://strawpoll.me/5842105 > > Thanks > Alan >

1 1

New release Csound-expression 4.9 is out
by Anton Kholomiov 30 Oct '15

30 Oct '15

*The 4.9.0 is out! New features:* csound-expression - Functions for creation of FM-synthesizers. We can create the whole graph of FM-units (with feedback). Check out the module Csound.Air.Fm - Support for Monosynth patches. See atMono in the module Csound.Air.Patch see the function atMono and atMonoSharp. - Easy to use Binaural panning. See the module Csound.Air.Pan It’s like: headPan :: (Sig, Sig) -> Sig -> Sig2headPan (azimuth, elevation) asig = (aleft, aright) the compiler can supply the right extra files by reading the header of .csd - Construction of patches for sound fonts (sfPatch, sfPatchHall). - Table of tables. We can create a table that contains tables. - Harmonic oscillators for subtractive synth: buz and gbuz (the functions are adapted from the Csound ones) - Reverbs for patches. It’s very easy to add a reverb to your patch (withSmallHall patch, withLargeHall patch, etc) - Some bug-fixes csound-catalog - Many mono-synth were added. You can use them with function atMono in place of atMidi. The mono versions of patches have suffix m. Like hammonOrganm or nightPadm. We can use it like this: > dac $ atMono nightPadm - SHARC instruments. SHARC db contains a FFT-samples for sustain notes. It includes many orchestra instruments. There are many new patches that use natural sounding timbres taken from the SHARC library. Check out functions soloSharc, padSharc, dreamSharc. We can use it like this: > dac $ atMidi $ padSharc shCello csound-sampler - Handy function withBpm allows to query current bpm with in the scope of expression. - Sampler mappers were generalized. - Char trigering functions are synchronized with bpm. Cheers! Anton

1 1

2nd CfP: Haskell in Leipzig (Germany) 2015
by Johannes Waldmann 29 Oct '15

29 Oct '15

HaL-10 Haskell in Leipzig (December 4/5) http://nfa.imn.htwk-leipzig.de/HAL2015/ We are proud to present Joachim Breitner (nomeata) as our invited speaker. The submission deadline (November 2) is approaching! See you - Johannes Waldmann (PC chair)

1 0

Re: [Haskell-cafe] GHC can't find DLL dependencies on Windows
by Ryan Scott 29 Oct '15

29 Oct '15

Never mind, I figured it out. Previously, I had been placing C:\msys64\mingw64\bin at the end of my user PATH. It turns out that my PATH was in fact on the DLL search path, but for some reason, an earlier directory on my PATH was causing problems. I can't exactly pinpoint what was causing the problem, but after moving C:\msys64\mingw64\bin to the start of my system PATH, I can run Haskell executables in PowerShell/cmd.exe without a problem. Ryan S.

2 1

Stripe-Haskell Updates !
by David Johnson 29 Oct '15

29 Oct '15

*stripe-haskell 2.0* has been released on hackage. *The 2.0 release will entail the following:* - All types will now live in their own repository 'stripe-core' (for better use w/ ghcjs projects). - 'stripe-http-streams' is a specific http client backend for 'stripe-haskell' - Other backends (wreq, conduit, etc.) can be added. As always, pull requests welcome. - 'stripe-haskell' is now a virtual package that wraps 'stripe-http-streams' and 'stripe-core'. - We have a 'gitter' chat for our repo, to promote collaboration. - We now have a multi-ghc travis build that uses stack. - Jeremy Shaw has implemented a novel approach to the optional parameters problem using typeclasses. The docs will contain more information. - For existing stripe-haskell users version 2.0 is a breaking change, but it features a nicer interface due to Jeremy Shaw's changes. *Other notes:* - Existing 1.4 users will not be neglected. We can continue to submit patches up to 2.0. *Future goals:* - Migrate to servant-client ASAP. - Continue to beg Stripe for a machine readable specification that will relieve us from having to perform manual updates on subsequent API changes, and furthermore will allow us to fully take advantage of this wonderful service. Please respond here if you have questions, or visit our gitter at https://gitter.im/dmjio/stripe.

1 0

installing GSL packages on Windows
by Sean Matthews 29 Oct '15

29 Oct '15

I'm currently trying to install the gsl packages (in particular hmatrix-gsl) for a Windows 7/32 system. I've been using a fairly stripped down version of the GHC for a while, but now that I'm trying to install packages like this, I'm running into problems. Anyway, I have installed pkg-config, etc. and I believe I've got the various bits of gsl installed. However cabal is still failing at attaching this to the appropriate haskell modules, at what looks to be very near the end, and suggstions for what I can try to get things to finish would be welcome. Below is the output as generated by cabal (this is the result of several iterations and systematic googling, but google seems to have run out on me). All suggestions, advice, etc. very welcome, Sean Matthews > cabal install hmatrix-gsl --extra-include-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\include" --extra-lib-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\lib" > cabal install hmatrix-gsl --extra-include-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\include" --extra-lib-dirs="C:\Users\sematthews\My Software\gsl-1.15-dev-win32\lib" > Resolving dependencies... > Configuring hmatrix-gsl-0.17.0.0... > Building hmatrix-gsl-0.17.0.0... > Failed to install hmatrix-gsl-0.17.0.0 > Build log ( C:\Users\sematthews\AppData\Roaming\cabal\logs\hmatrix-gsl-0.17.0.0.log ): > Building hmatrix-gsl-0.17.0.0... > Preprocessing library hmatrix-gsl-0.17.0.0... > [ 1 of 17] Compiling Graphics.Plot ( src\Graphics\Plot.hs, dist\build\Graphics\Plot.o ) > [ 2 of 17] Compiling Numeric.GSL.Internal ( src\Numeric\GSL\Internal.hs, dist\build\Numeric\GSL\Internal.o ) > [ 3 of 17] Compiling Numeric.GSL.Integration ( src\Numeric\GSL\Integration.hs, dist\build\Numeric\GSL\Integration.o ) > [ 4 of 17] Compiling Numeric.GSL.Fourier ( src\Numeric\GSL\Fourier.hs, dist\build\Numeric\GSL\Fourier.o ) > [ 5 of 17] Compiling Numeric.GSL.Polynomials ( src\Numeric\GSL\Polynomials.hs, dist\build\Numeric\GSL\Polynomials.o ) > [ 6 of 17] Compiling Numeric.GSL.Minimization ( src\Numeric\GSL\Minimization.hs, dist\build\Numeric\GSL\Minimization.o ) > [ 7 of 17] Compiling Numeric.GSL.Root ( src\Numeric\GSL\Root.hs, dist\build\Numeric\GSL\Root.o ) > [ 8 of 17] Compiling Numeric.GSL.Fitting ( src\Numeric\GSL\Fitting.hs, dist\build\Numeric\GSL\Fitting.o ) > [ 9 of 17] Compiling Numeric.GSL.ODE ( src\Numeric\GSL\ODE.hs, dist\build\Numeric\GSL\ODE.o ) > [10 of 17] Compiling Numeric.GSL.Interpolation ( src\Numeric\GSL\Interpolation.hs, dist\build\Numeric\GSL\Interpolation.o ) > [11 of 17] Compiling Numeric.GSL.LinearAlgebra ( src\Numeric\GSL\LinearAlgebra.hs, dist\build\Numeric\GSL\LinearAlgebra.o ) > [12 of 17] Compiling Numeric.GSL.SimulatedAnnealing ( src\Numeric\GSL\SimulatedAnnealing.hs, dist\build\Numeric\GSL\SimulatedAnnealing.o ) > [13 of 17] Compiling Numeric.GSL.Vector ( src\Numeric\GSL\Vector.hs, dist\build\Numeric\GSL\Vector.o ) > [14 of 17] Compiling Numeric.GSL.IO ( src\Numeric\GSL\IO.hs, dist\build\Numeric\GSL\IO.o ) > [15 of 17] Compiling Numeric.GSL.Random ( src\Numeric\GSL\Random.hs, dist\build\Numeric\GSL\Random.o ) > [16 of 17] Compiling Numeric.GSL.Differentiation ( src\Numeric\GSL\Differentiation.hs, dist\build\Numeric\GSL\Differentiation.o ) > [17 of 17] Compiling Numeric.GSL ( src\Numeric\GSL.hs, dist\build\Numeric\GSL.o ) > In-place registering hmatrix-gsl-0.17.0.0... > setup-Simple-Cabal-1.22.4.0-i386-windows-ghc-7.10.2.exe: > 'C:\Users\sematthews\My Software\Haskell\bin\ghc-pkg.exe' exited with an > error: > hmatrix-gsl-0.17.0.0: Warning: haddock-interfaces: > C:\Users\SEMATT~1\AppData\Local\Temp\cabal-tmp-8196\hmatrix-gsl-0.17.0.0\dist\doc\html\hmatrix-gsl\hmatrix-gsl.haddock > doesn't exist or isn't a file > hmatrix-gsl-0.17.0.0: Warning: haddock-html: > C:\Users\SEMATT~1\AppData\Local\Temp\cabal-tmp-8196\hmatrix-gsl-0.17.0.0\dist\doc\html\hmatrix-gsl > doesn't exist or isn't a directory > hmatrix-gsl-0.17.0.0: library-dirs: /usr/local/lib is a relative path which > makes no sense (as there is nothing for it to be relative to). You can make > paths relative to the package database itself by using ${pkgroot}. (use > --force to override) > hmatrix-gsl-0.17.0.0: include-dirs: /usr/local/include is a relative path > which makes no sense (as there is nothing for it to be relative to). You can > make paths relative to the package database itself by using ${pkgroot}. (use > --force to override) > cabal: Error: some packages failed to install: > hmatrix-gsl-0.17.0.0 failed during the building phase. The exception was: > ExitFailure 1 -- Sean Matthews seanmatthews1(a)gmail.com / +49 1515 800 1901

1 0

No warn on type in expression?
by amindfv＠gmail.com 29 Oct '15

29 Oct '15

An expression like: x = 5 :: Int Fails with -Wall -Werror, with "Top-level binding with no type signature". I propose we don't warn on bindings whose entire expressions are typed. This cuts in half the line noise for trivial variable values. Tom

3 2

GHC can't find DLL dependencies on Windows
by Ryan Scott 29 Oct '15

29 Oct '15

I recently decided to try out a simple diagrams-cairo project on Windows 8 (x86_64) to discover that GHC (7.10.2, to be specific) acts rather bizarrely when dealing with external DLL dependencies. To start, I downloaded MSYS2 [1], installed the libraries needed for cairo and pango to work [2], installed diagrams-cairo [3], and tried running a simple diagrams program: module Main (main) where import Diagrams.Prelude import Diagrams.Backend.Cairo.CmdLine main :: IO () main = mainWith (circle 1 :: Diagram B) like so from MSYS2: runghc Cairo.hs -o circle.svg -w 400 And it worked. Hooray! Now, I normally use cmd.exe/PowerShell for most of my Windows command-line tasks, so later I tried invoking the above command on PowerShell, only to be greeted with an error message: $ runghc.exe .\Cairo.hs -o circle.svg -w 400 Cairo.hs: warning: _tzset from msvcrt is linked instead of __imp__tzset Cairo.hs: libcairo-2: The specified procedure could not be found. Cairo.hs: <command line>: can't load .so/.DLL for: libcairo-2.dll (addDLL: could not load DLL) PowerShell, alas, couldn't find libcairo-2.dll when MSYS2 had no trouble whatsoever. I realized that MSYS2 stores all of its MinGW-related DLL files in a special location (C:\msys64\mingw64\bin). This can be observed by running cygcheck on the executable: $ C:\msys64\usr\bin\cygcheck.exe .\Cairo.exe C:\Users\ryanscot\Documents\Hacking\Haskell\Cairo.exe cygcheck: track_down: could not find libcairo-2.dll cygcheck: track_down: could not find libglib-2.0-0.dll cygcheck: track_down: could not find libgobject-2.0-0.dll cygcheck: track_down: could not find libpango-1.0-0.dll cygcheck: track_down: could not find libpangocairo-1.0-0.dll ... After reading about DLL search paths in Windows [4], I got the impression that I could add C:\msys64\mingw64\bin to my PATH, and then executables would look for DLLs there. Adding C:\msys64\mingw64\bin to my PATH seemed to make cygcheck happy: $ C:\msys64\usr\bin\cygcheck.exe .\Cairo.exe C:\Users\ryanscot\Documents\Hacking\Haskell\Cairo.exe C:\msys64\mingw64\bin\libcairo-2.dll ... But invoking runghc Cairo.exe on PowerShell still fails with the same error message! For the life of me, I can't figure out what kind of sorcery MSYS2 is doing to make C:\msys64\mingw64\bin visible to the DLL search path from GHC. The only way I can trick PowerShell into seeing libcairo-2.dll is to (1) Copy libcairo-2.dll directly to C:\Windows\System32, or (2) Invoke SetDllDirectory("C:\msys64\mingw64\bin") [5] from a PowerShell startup script Neither of these options are very satisfying, since (1) has massive security implications, and (2) only works when you have one external DLL directory (if you called SetDllDirectory again with a different directory, it overrides the first one). I know there are folks out there who have managed to get diagrams working on Windows, so can someone let me know if I'm doing something wrong? Ryan S. ----- [1] http://msys2.github.io/ [2] pacman -S mingw-w64-x86_64-cairo mingw-w64-x86_64-pango 1.38.1-1 [3] cabal install diagrams-cairo [4] https://msdn.microsoft.com/en-us/library/ms682586.aspx#search_order_for_des… [5] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85…

1 0

best practice for lifting of IO and could lifting be automated?
by Oleg 28 Oct '15

28 Oct '15

Dimitri DeFigueiredo wrote: > Imagine I need to read a .CSV file which may or may not contain column > titles on its first line. I'm not interested in the column titles, I > just want the rest of the file. I am provided a library function to read > the contents of the file (using a "callback"). The library author > provided this function in the IO monad. > withCSV :: FilePath -> (Handle -> IO r) -> IO r > withCSV path action = do > putStrLn "opening file" > h <- openFile path ReadWriteMode > r <- action h > hClose h > putStrLn "file closed" > return r > The problem arises because I also want to use the ReaderT monad > transformer. My environment information will tell me > whether or not to disregard the first (i.e. column title) line. For this particular example, the answer is easy: If you have the IO monads, you have the Reader monad, and the State/Writer as well. This is just an IORef. > getFileContents :: IO String > getFileContents = do > ref <- newIORef False > withCSV "data.csv" (myReadFile ref) > where > myReadFile :: IORef Bool -> Handle -> IO String > myReadFile ref handle = do > header <- readIORef ref -- ask --- OOOPPSss!!! FAIL! Can't ask. > case header of > False -> return "" > True -> hGetLine handle -- skip first line > text <- hGetContents handle > return text Using just IO, you can get State, Reader, Writer, and Exception (and in a modular way!) As to you general question, I will and do advocating abandoning monad transformers altogether. The paper on extensible effects demonstrated a new solution to the MonadCatchIO problem that solved the long-standing issue of discarding state upon exception. See Sec 6 of http://okmij.org/ftp/Haskell/extensible/more.pdf

6 9