Re: [Haskell-cafe] Trouble installing haskeline: ExitFailure 139
Can you try running the setup script manually? ghc --make Setup.hs ./Setup configure and see if it prints an error that's any more helpful? Also, what operating system and version of ghc do you have? -Judah On Sat, Sep 14, 2013 at 1:57 PM, David Banas wrote: > Has anyone else hit an unexplained *ExitFailure 139* when trying to > install the *haskeline* package? > > Thanks, > -db > > dbanas@dbanas-lap:~/prj$ cabal install -v haskeline > Reading available packages... > Choosing modular solver. > Resolving dependencies... > Extracting > /home/dbanas/.cabal/packages/ > hackage.haskell.org/haskeline/0.7.0.3/haskeline-0.7.0.3.tar.gz > to /tmp/haskeline-0.7.0.3-16574... > creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup > creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist > creating /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup > /usr/local/bin/ghc --make > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs -o > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup -odir > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -hidir > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup -i > -i/tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3 -package Cabal-1.16.0 > [1 of 1] Compiling Main ( > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/Setup.hs, > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/Main.o ) > Linking /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup ... > /tmp/haskeline-0.7.0.3-16574/haskeline-0.7.0.3/dist/setup/setup configure > --verbose=2 --ghc --prefix=/home/dbanas/.cabal --user --flags=terminfo > --flags=-libiconv --flags=-legacy-encoding --constraint=unix ==2.6.0.1 > --constraint=transformers ==0.3.0.0 --constraint=terminfo ==0.3.2.5 > --constraint=filepath ==1.3.0.1 --constraint=directory ==1.2.0.1 > --constraint=containers ==0.5.0.0 --constraint=bytestring ==0.10.0.2 > --constraint=base ==4.6.0.1 --disable-tests --disable-benchmarks > World file is already up to date. > cabal: Error: some packages failed to install: > haskeline-0.7.0.3 failed during the configure step. The exception was: > ExitFailure 139 > dbanas@dbanas-lap:~/prj$ > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector (or List) to CArray?
On Thu, Jan 19, 2012 at 10:15 AM, Dominic Espinosa wrote: > Hello, > > I'm trying to use the fftw binding, and its functions operate on CArrays of > Complex. My data is coming from hsndfile, so it starts out as a Vector of > Double. How do I convert this data to CArray? The API functions in the > CArray module don't seem to indicate how. My first recommendation would be to use the vector-fftw package, which uses Vectors instead of CArrays. But as the author of that package I may be a bit biased. Alternately, converting between CArrays and Vectors isn't too hard if you want to do it directly. For example, you can convert from Vector to CArray by using Data.Vector.Storable.unsafeToForeignPtr and Data.Array.CArray.Base.unsafeForeignPtrToIOCArray. Other functions in those modules will let you go in the other direction. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 17, 2011 at 2:56 AM, Luis Cabellos wrote: > > Other issues to solve, > How to compile in hackage server to generate documentation online? > opencl.h isn't in the server so I getting errors. > In my experience, the nicest way to work around this problem is to just generate the documentation manually and host it somewhere off of Hackage. http://community.haskell.org/admin/ is a decent place to host something like this; you end up with a URL http://projects.haskell.org/yourproject which you can link to from the .cabal file description. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XCode Dependency for HP on Mac
On Thu, Jul 28, 2011 at 7:59 AM, Tom Murphy wrote: > +1 - does anyone know the answer to this? > > On Jul 27, 2011 2:04 PM, "Chris Smith" wrote: >> On Wed, 2011-07-27 at 07:20 -0400, Jack Henahan wrote: >>> Bundling things with the HP is just going to bloat that download >>> and confuse new users more (and my god, the dep-chasing... the >>> number of libs that might have to be piled in on top of it could >>> be absurd). >> >> I don't understand this. Are you saying it would be too hard for the >> Haskell Platform maintainers to build the install kits? It seems like >> bundling gcc would be just the thing to solve all the problems with the >> XCode dependency (which I'm now told include not just the install-time >> dependencies, but also the Haskell Platform regularly breaking with >> every new operating system release). Has anyone ever (say, in the last 5 years) maintained a separate gcc distribution for the Mac? I'm unaware of any such production. Even MacPorts requires the developer tools to be preinstalled: http://www.macports.org/install.php In contrast, Windows has both the MinGW and Cygwin projects which each provide a port of gcc with a (partial or complete) POSIX compatibility layer. GHC and the HP include MinGW on Windows. The Mac developer community at large has determined that the most programmer-friendly option is to just install the free tools provided by Apple: - Every DVD of OS X has come with an optional install of the Dev Tools. The only exception is 10.7, which has to be downloaded itself anyway. - I just double-checked on developer.apple.com; with my free registration I can still download every version of the Developer Tools since at least 2004. Even the latest, Xcode 4.1, can be downloaded directly from that site without logging into the App Store. As a side anecdote, I've been the teaching assistant several times for a college course on introductory C++. I've told my students with Macs that if they want to write programs at home they should install the Dev Tools, and I've posted a short list of instructions on my website. Nearly all of them have found it very easy to get started working in Xcode, either by installing it from a DVD or by downloading it from online. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Hi John, You should be able to install the Apple Developer Tools directly from one of the software installation DVDs that come with the Mac. If you're not downloading the tools from online, you shouldn't need to register. Best, -Judah On Fri, Jun 3, 2011 at 1:03 PM, John D. Ramsdell wrote: > I rarely use a Mac because it is too cute, but I bought one for my > wife. I'd like to install GHC on her Mac just to test Haskell > Platform and cabal install. (I rarely use Windows too, but testing > GHC & cabal install is completely painless.) To do a quick test, do > I really have to register as an Apple developer, or is there a way to > test the platform anonymously? > > Someone who some times worries about privacy, > > John > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doesDirectoryExist is always returning False
On Sat, Nov 20, 2010 at 6:55 AM, Marcelo Sousa wrote:
> Hi,
> I'm having currently a problem with System.Directory in my mac os.
> System Version: Mac OS X 10.6.5
> Kernel Version: Darwin 10.5.0
> Prelude System.Directory> let dirTest = do {dir <- getCurrentDirectory;
> doesDirectoryExist dir}
> Prelude System.Directory> dirTest
> False
What's the output of getCurrentDirectory? I just tried that on OS X
10.6.4 and dirTest returned True for me.
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GitIt
Two possible fixes come to mind: 1) In the .cabal file for cautious-file, it says: Flag posix description: Use POSIX-specific features default: True You can use "cabal install -fposix cautious-file" to explicitly turn on POSIX support, and "cabal install -f-posix cautious-file" to explicitly turn it off. (From above, the default is the former.) So you can probably get this working with: cabal install cautious-file -f-posix; cabal install gitit Incidentally, it would be better for the .cabal file to detect that automatically with "if os(windows)", as e.g. Haskeline does. 2) If you have a local, edited installation of a package with the same version number as the one on Hackage, then it seems to confuse "cabal install". (This may be a bug; I'm not sure.) Workaround is to bump the version in your local installation, e.g. from 0.1.5 to 0.1.5.0.0.0.1.; then "cabal install" won't try to rebuild it. Hope that helps, -Judah On Fri, Nov 19, 2010 at 12:20 PM, Andrew Coppin wrote: > The other day, I did a slightly foolish thing. I uttered the command > > cabal install gitit > > Actually, while I was "foolish", it actually worked better than you'd think. > It wanted to install several thousand billion packages, but all of them > compiled without issue. > > Well, all except one. You see, for reasons that I have yet to determine, > cabal is *convinced* that gitit transitively requires the "unix" package. > Astonishingly, this doesn't work on Windows. :-P > > Question: Why does 90% of the network-related stuff on Hackage require the > unix package? What's in there that's so network-related? I don't understand. > We've *got* a portable "network" package that works on all platforms, so...? > > Anyway, on further investigation, it appears that the culprit is > "cautious-file". If a certain CPP flag it set, "unix" gets added to the > Build-Depends: field. Except... I didn't set any CPP flags! What the hell? > > So I manually edit the package description (!), and now it builds and > installs perfectly happily. So now I tell cabal to install gitit again... > and it immediately tries to install unix, even though the only package that > (it thinks) requires unix is already installed? Wuh? > > So I unpack gitit and tell cabal to build it. Building takes about 30 > seconds. *Linking* takes about 4 minutes (??!) And then it fails due to some > missing symbols. (No, I don't remember off the top of my head what they > were.) > > At this point, I am completely lost. Does anybody have any ideas on how I > can make GitIt work, short of installing Linux? I've searched and searched > and I can't see a pre-built binary anywhere. > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 10:58 AM, John Millikin wrote: > I think the docs are wrong, or perhaps we're misunderstanding them. > Magnus is correct. > > Attached is a test program which listens on two ports, 42000 (blocking > IO) and 42001 (non-blocking). You can use netcat, telnet, etc, to send > it data. The behavior is as Magnus describes: bytes from > hGetNonBlocking are available immediately, while hGet waits for a full > buffer (or EOF) before returning. > > This behavior obviously makes hGet unsuitable for enumHandle; my > apologies for not understanding the problem sooner. You should note that in ghc>=6.12, hWaitForInput tries to decode the next character of input based on to the Handle's encoding. As a result, it will block if the next multibyte sequence is incomplete, and it will throw an error if a multibyte sequence gets split between two chunks. I worked around this problem in Haskeline by temporarily setting stdin to BinaryMode; you may want to do something similar. Also, this issue caused a bug in bytestring with ghc-6.12: http://hackage.haskell.org/trac/ghc/ticket/3808 which will be resolved by the new function 'hGetBufSome' (in ghc-6.14) that blocks only when there's no data to read: http://hackage.haskell.org/trac/ghc/ticket/4046 That function might be useful for your package, though not portable to other implementations or older GHC versions. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Trapping getChar before echo
On Fri, Feb 5, 2010 at 10:41 AM, Andrew Coppin
wrote:
> Tim Attwood wrote:
>>>
>>> Last time I tried something like this [on Windows], it didn't seem to
>>> work. I wanted to trap arrow keys and so forth, but they seem to be being
>>> used for input history. (I.e., pressing the up-arrow produces
>>> previously-entered lines of text, and none of this appears to be reaching
>>> the Haskell program itself.) Has this changed since I tried it last year?
>>
>> Doesn't work in windows, at least up till 6.10.1. There's a work-around
>> though.
>>
>> {-# LANGUAGE ForeignFunctionInterface #-}
>>
>> import Data.Char
>> import Control.Monad (liftM, forever)
>> import Foreign.C.Types
>>
>> getHiddenChar = liftM (chr.fromEnum) c_getch
>> foreign import ccall unsafe "conio.h getch"
>> c_getch :: IO CInt
>>
>> main = do
>> forever $ do
>> c <- getHiddenChar
>> putStrLn $ show (fromEnum c)
>
> Thanks for the info.
>
> Does anyone know how this is related to the "haskeline" package on Hackage?
The haskeline package provides a readline-like library for reading in
a line of input with arrow keys, tab completion, etc. It works on
both Windows and unix platforms. Documentation and a full list of
features can be found at http://trac.haskell.org/haskeline/ .
On Windows, haskeline gets all user input by calling Win32 API
functions such as ReadConsoleInputW:
http://msdn.microsoft.com/en-us/library/ms684961%28VS.85%29.aspx
That function returns an INPUT_RECORD struct with information about
key press events (among others); those includes simple characters,
arrow keys, page up/down, etc. AFAIK that's the only way to get at
such events in the Windows console; there's no effective analogue to
the unix setting, where e.g. pressing the up key causes stdin to
receive the ANSI key sequence "\ESC[A".
The source code of haskeline has examples of how to import and use
those API functions:
http://code.haskell.org/haskeline/System/Console/Haskeline/Backend/Win32.hsc
Best,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking in Large ByteStrings
On Fri, Jan 1, 2010 at 7:09 AM, Tom Hawkins wrote:
> I have a large tarball I want to link into an executable as a
> ByteString. What is the best way to do this? I can convert the
> tarball into a haskell file, but I'm afraid ghc would take a long time
> to compile it. Is there any way to link constant data directly with
> ghc? If not, what's the most efficient way to code large ByteStrings
> for fast compilation?
Possibly the simplest is to use unsafePackAddress or unsafePackAddressLen:
{-# LANGUAGE MagicHash #-}
module Const where
import Data.ByteString.Unsafe as U
import System.IO.Unsafe
my_bstr = unsafePerformIO $ U.unsafePackAddress "abcdefg"#
This trick of embedding raw strings (of type Addr#) is how happy and
alex store their parser lookup tables in the modules they generate.
I haven't seen any performance issues with it myself.
Hope that helps,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Configuring cabal install readline on Snow Leopard with MacPorts
On Mon, Dec 28, 2009 at 11:48 PM, Alexy Khrabrov wrote: > I've tried to do cabal install readline on Snow Leopard with MacPorts and it > fails with the infamous: > > $ cabal install readline > ... > checking for GNUreadline.framework... checking for readline... no > checking for tputs in -lncurses... yes > checking for readline in -lreadline... yes > checking for rl_readline_version... yes > checking for rl_begin_undo_group... no > configure: error: readline not found, so this package cannot be built > See `config.log' for more details. > cabal: Error: some packages failed to install: > readline-1.0.1.0 failed during the configure step. The exception was: > exit: ExitFailure 1 > > Googilng shows the usual explanation that Mac'y broken clone interferes; yet > I do have MacPorts and readline 6 there. So I try, per fixes recommended, > > $ cabal install readline --extra-include-dirs=/opt/local/include > --extra-lib-dirs=/opt/local/lib > ... > checking for rl_readline_version... yes > checking for rl_begin_undo_group... no > ... > -- same result. > > Downloaded the package and do configure manually: > > ./configure --with-readline-includes=/opt/local/include > --with-readline-libraries=/opt/local/lib You should use: cabal install readline --configure-option=--with-readline-includes=/opt/local/include --configure-option=--with-readline-libraries=/opt/local/lib Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with editline install
On Fri, Dec 25, 2009 at 2:17 AM, Andrew U. Frank wrote: > i tried to install editline (because i wanted to install djinn, which depends > on it): > with cabal install and with downloading and runghc Setup.lhs configure > i got the same error: > > checking for completion_matches... no > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. > > > in the log i did not see anything helpful (at my level of understanding). > i could then install with synaptic because a deb package existed for ubuntu). > > what did i wrong? thanks for helpful comments You probably need to install the Ubuntu libedit-dev package, which contains the necessary C headers. Note that's different than the libeditline-dev package, which is an old version of the library missing some important features. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Snow Leopard, gtk2hs
On Tue, Oct 6, 2009 at 11:41 AM, Arne Dehli Halvorsen wrote: > This may be a little off-topic, but if someone could help me, I'd be > grateful. > I am trying to get to a working gtk2hs environment in MacOSX Snow Leopard > > I have a Macbook Pro 2.1 with Snow Leopard. > While I had Leopard, I had the Haskell Platform installed, and it worked > fine. > I also had the MacPorts edition of gtk, and compiled gtk2hs by hand. > After I got Snow Leopard, I installed the Haskell Platform. I have made the > necessary changes to make it compile (flags to ghc), and it compiles normal > programs. > I installed the standalone version of the GTK+ platform, and then tried to > compile gtk2hs from /gtk2hs . > ./configure works, but make results in this: > [snip] > /var/folders/G8/G8LY9MSBEGuyatB+JjSWqTI/-Tmp-/ghc4162_0/ghc4162_0.split__2870.s:35:0: > invalid character '_' in mnemonic > /var/folders/G8/G8LY9MSBEGuyatB+JjSWqTI/-Tmp-/ghc4162_0/ghc4162_0.split__2870.s:953:0: > FATAL:Symbol L_gtk_misc_get_type$stub already defined. > make[1]: *** [gtk/Graphics/UI/Gtk/Types.o] Error 1 > make: *** [all] Error 2 > I also have gtk installed via macports recently, but I am not sure whether > this makes a difference. > I don't think there is any point currently in trying to go MacPorts all the > way, and install ghc+gtk2hs via MacPorts. > Does anyone have a recipe for getting ghc + gtk2hs + gtk working on MacOSX > Snow Leopard? > Best regards, > Arne D Halvorsen I was able to get gtk2hs working with ghc-6.10.3 (after patching the /usr/bin scripts with -m32) by following the steps from http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework with one change: call configure for gtk2hs as ./configure --disable-split-objs --disable-gio Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GD library on Mac OSX?
On Wed, Sep 23, 2009 at 12:23 AM, Colin Adams wrote: > 2009/9/22 Brandon S. Allbery KF8NH : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Sep 22, 2009, at 13:44 , Colin Adams wrote: >>> >>> It needs some missing C libraries - gd, png, jpeg, fontconfig and >>> freetype. >>> Does anyone know what to do to install these on OSX? >> >> >> Customarily, Fink or MacPorts. >> >> Several of those *are* installed on OSX by default (at least Leopard and >> up); if they're not being found, make sure you have installed the latest >> XCode and Apple's X11 (the latter should only matter for Tiger and earlier). >> You may also want the latest X11 from http://xquartz.macosforge.org. > > Well I tried using macports to install GD2. That was hard work (it > doesn't resolve dependencies for you). But it makes no difference. > Cabal install gd still fails saying gd.h is missing, and the libraries > gd, png, jpeg, fonconfig and freetype, as before. You probably want to use (if you haven't tried it already): cabal install gd --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coercion from a Word32/64 to a Float/Double
On Mon, Sep 14, 2009 at 12:24 PM, minh thu wrote: > Hi, > > I'd like to know if this should work: > > -- GHC coercion > getFloat :: BHeader -> Get Float > getFloat h = > case endianness h of > LittleEndian -> fmap (coerce . fromIntegral) getWord32le > BigEndian -> fmap (coerce . fromIntegral) getWord32be > where coerce (I32# x) = F# (unsafeCoerce# x) > > -- GHC coercion > getDouble :: BHeader -> Get Double > getDouble h = > case endianness h of > LittleEndian -> fmap (coerce . fromIntegral) getWord64le > BigEndian -> fmap (coerce . fromIntegral) getWord64be > where coerce (I64# x) = D# (unsafeCoerce# x) > > Loading this into ghci compiles fine (but I haven't try to parse > data), but compiling with ghc (6.10.1 or 6.10.4) reports: > /tmp/ghc1967_0/ghc1967_0.s: Assembler messages: > > /tmp/ghc1967_0/ghc1967_0.s:287:0: > Error: bad register name `%fake0' > > /tmp/ghc1967_0/ghc1967_0.s:349:0: > Error: bad register name `%fake0' I think that a more reliable (though not very pretty) way to do the casts is via pointer manipulation. Code like the following has worked for me in the past: getDouble :: Get Double getDouble = fmap word2Double getWord64le where word2Double w = unsafePerformIO $ with w $ \p -> do d :: CDouble <- peek (castPr p) return (realToFrac d :: Double) Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unable to install Haskell Platform without readline
On Fri, Sep 11, 2009 at 11:46 AM, Lyle Kopnicky wrote: > Hi folks, > > I just installed GHC 6.10.4 on Ubuntu 9.04 32-bit, and then tried to install > the Haskell Platform from source. It built quite a bit of stuff, with many > warnings but no errors, and then finally died with the error below. > > To install editline, I need cabal, which is of course why I installed the > Platform. I read an earlier thread from May that said that editline came > with GHC 6.10.2, so the Platform didn't work with 6.10.3, but was soon to be > updated. Now the web site for the Platform says it comes with 6.10.4, so I > assumed it should work with 6.10.4, but apparently it still has this problem > of still missing editline. > > Am I doing something wrong? > > checking editline/readline.h usability... no > checking editline/readline.h presence... no > checking for editline/readline.h... no > checking editline/editline.h usability... no > checking editline/editline.h presence... no > checking for editline/editline.h... no > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes > checking for sign of read_history result on error... negative > checking for rl_completion_matches... no > checking for completion_matches... no > configure: error: editline not found, so this package cannot be built > See `config.log' for more details. > > Error: > Configuring the editline-0.2.1.0 package failed > make: *** [build.stamp] Error 2 The above editline requirement is for the editline C library, not the Haskell bindings: http://www.thrysoee.dk/editline My guess is that you need to install a recent version of the libedit-dev package. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange console IO behavior (at least on Windows)
On Sat, Aug 22, 2009 at 2:37 PM, Peter Verswyvelen wrote: > Okay, I'll file a bug report. Maybe someone else on Windows could confirm > this behavior? > On Sat, Aug 22, 2009 at 11:36 PM, Jason Dagit wrote: >> >> On Sat, Aug 22, 2009 at 2:14 PM, Peter Verswyvelen >> wrote: >> > The following program >> > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8445#a8445 >> > should echo the ASCII code of each character the user types, on the fly, >> > with no line buffering whatsoever. >> > But it doesn't. At least not under Windows's cmd, and even less with >> > msys. This is probably the following issue: http://hackage.haskell.org/trac/ghc/ticket/2189 -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gbp sign showing as unknown character by GHC
On Wed, Aug 19, 2009 at 10:31 AM, Iain Barnett wrote: > Quick question: I've tested this in a couple of different terminals (roxterm > and xterm), so I'm fairly sure it's GHC that's the problem. Have I missed a > setting? > GHCi, version 6.10.4 > Prelude> putStrLn "£" > � > Hugs98 200609-3 > Hugs> putStrLn "£" > £ > ghc-6.10.4 and earlier don't automatically encode/decode Unicode characters. So on terminals which don't use the latin-1 encoding, you need to do the conversion explicitly with a separate package such as utf8-string, iconv or text-icu. For example, on OS X: $ echo $LANG en_US.UTF-8 $ ghci Prelude> putStrLn "£" ? Prelude> System.IO.UTF8.putStrLn "£" £ The conversion is done automatically by hugs, which is why the outputs differ. This feature will also be supported in ghc-6.12. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine if a FilePath is a directory name or regular file?
On Sun, Jun 21, 2009 at 11:12 PM, Colin Paul Adams wrote: > I've been hoogling like bad to try to determine if a function like > this exists. > > getDirectoryContents returns sub-directories as well as file names. I > want only the latter, so I'm looking for a suitable filter. Use System.Directory.doesDirectoryExist/doesFileExist. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode workaround for getDirectoryContents under Windows?
On Sat, Jun 13, 2009 at 8:41 PM, Shu-yu Guo wrote: > Hello all, > > It seems like getDirectoryContents applies codepage conversion based > on the default program locale under Windows. What this means is that > if my default codepage is some kind of Latin, Asian glyphs get > returned as '?' in the filename. By '?' I don't mean that the font is > lacking the glyph and rendering it as '?', but I mean 'show (head > (getDirectoryContents "C:\\Music"))' returns something that looks like > like "?? ". > > This is a problem as I can't get the filenames of my music directory, > some of which are in Japanese and Chinese, some of which have accents. > If I change the default codepage to Japanese, say, then I get the > Japanese filenames in Shift-JIS and I lose all the accented letters. > > I have filed this as a bug already, but is there a workaround in the > meantime (I don't know the Win32 API, but didn't see anything that > looked like it would help under System.Win32 anyways) that lets me > gets the list of files in a directory that's encoded in some kind of > Unicode? Try taking a look at the code in the following module, which uses FFI to access the Unicode-aware Win32 APIs: http://code.haskell.org/haskeline/System/Console/Haskeline/Directory.hsc Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confused about readline/editline
On Sun, Apr 5, 2009 at 10:06 AM, Martijn van Steenbergen wrote: > Hello café, > > I'm trying to write an executable that depends on Yogurt-0.3, readline > (indirectly) and hint. However, including hint in the build-depends field > causes cabal to link the executable against editline instead of readline. > Here is a small test case: > > File: Test.cabal > >> Name: Test >> Version: 0 >> >> Build-Type: Simple >> Cabal-Version: >= 1.2 >> >> Executable test >> Main-Is: Test.hs >> Build-Depends: base, Yogurt, hint >> GHC-Options: -threaded > > File: Test.hs > >> module Main where >> >> import Network.Yogurt >> >> main:: IO () >> main = do >> connect "eclipse.cs.pdx.edu" 7680 (return ()) > > The example doesn't use any functions from hint, but simply mentioning it in > the cabal file causes this behaviour. What's going on? How can I fix or work > around this? > > I am able to reproduce this behaviour in two configurations: > * Leopard Intel; cabal-install version 0.6.2, using version 1.6.0.1 of the > Cabal library; GHC 6.10.1 > * Ubuntu; cabal-install version 0.6.2, using version 1.6.0.3 of the Cabal > library; GHC 6.10.2 > Probably what's happening is that hint depends on the ghc package, which links to editline in 6.10 since it includes all the code for ghci. I'm not sure, but there might be some order of flags or packages you could give to Cabal which would cause it to link to readline first; I think if gcc gets "-lreadline -ledit" in that order then it will do what you want. Passing "-v" or "-v3" to cabal build should let you see what's going on. For ghc-6.12 there's plans to prevent this issue by separating out ghci as a separate program than the core ghc package. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Character I/O
On Tue, Mar 31, 2009 at 2:11 PM, Andrew Coppin wrote: > Judah Jacobson wrote: >> >> Sounds like you're on Windows, so it's probably this bug: >> >> http://hackage.haskell.org/trac/ghc/ticket/2189 >> > > I am on Windows. It looks like my programs are running editline or something > to give a command history. Ordinarily that would actually be quite useful, > but for this particular application, not so much. Actually, when you read a buffered line of input from the Windows console it automatically provides line history for the user. (This is Win32 behavior, nothing to do with Haskell or editline.) As you say, sometimes it's more useful than others. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Character I/O
On Tue, Mar 31, 2009 at 12:53 PM, Andrew Coppin wrote: > Edward Kmett wrote: >> >> You want to use: >> > main = do hSetBuffering stdin NoBuffering; c <- getChar > > Already tried that. It appears to make no difference. Sounds like you're on Windows, so it's probably this bug: http://hackage.haskell.org/trac/ghc/ticket/2189 Although: if you're trying to get at the arrow keys from the Windows cmd console, it's not possible by reading stdin; rather, you need to access the lower-level Win32 console APIs: http://msdn.microsoft.com/en-us/library/ms682073(VS.85).aspx Not sure if it will help, but you could take a look at what I did in Haskeline: http://code.haskell.org/haskeline/System/Console/Haskeline/Backend/Win32.hsc -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] advancePtr for ForeignPtr
On Mon, Feb 23, 2009 at 9:02 AM, Judah Jacobson
wrote:
> On Mon, Feb 23, 2009 at 6:48 AM, Henning Thielemann
> wrote:
>>
>> On Mon, 23 Feb 2009, Felipe Lessa wrote:
>>
>>> On Mon, Feb 23, 2009 at 10:12 AM, Henning Thielemann
>>> wrote:
>>>>
>>>> Is still someone on haskell.org ?
>>>
>>> Sorry, I don't know :).
>>
>> I meant f...@haskell.org
>>
>>>> Do I have to use 'touchForeignPtr' as finalizer of the subarray's
>>>> ForeignPtr
>>>> in order to assert that the superarray lives at least as long as the
>>>> subarray?
>>>
>>> This may work, but seems like a fragile hack. Why not
>>>
>>>
>>> data SubArray a = SA {-# UNPACK #-} !(ForeignPtr a)
>>> {-# UNPACK #-} !Int
>>
>> This would work, but I want to convert from StorableVector to CArray and
>> StorableVector has an offset parameter, which is missing in CArray.
>
> I've used something like the following for that purpose:
>
> advanceForeignPtr :: ForeignPtr a -> Int -> IO (ForeignPtr a)
> advanceForeignPtr fp n = withForeignPtr fp $ \p ->
>newForeignPtr_ (p `advancePtr` n)
Oops, sorry, that's definitely wrong. Probably the only fix is to use
touchForeignPtr in the finalizer of the new ForeignPtr, as you said.
Time to fix some of my code... :-)
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] advancePtr for ForeignPtr
On Mon, Feb 23, 2009 at 6:48 AM, Henning Thielemann
wrote:
>
> On Mon, 23 Feb 2009, Felipe Lessa wrote:
>
>> On Mon, Feb 23, 2009 at 10:12 AM, Henning Thielemann
>> wrote:
>>>
>>> Is still someone on haskell.org ?
>>
>> Sorry, I don't know :).
>
> I meant f...@haskell.org
>
>>> Do I have to use 'touchForeignPtr' as finalizer of the subarray's
>>> ForeignPtr
>>> in order to assert that the superarray lives at least as long as the
>>> subarray?
>>
>> This may work, but seems like a fragile hack. Why not
>>
>>
>> data SubArray a = SA {-# UNPACK #-} !(ForeignPtr a)
>> {-# UNPACK #-} !Int
>
> This would work, but I want to convert from StorableVector to CArray and
> StorableVector has an offset parameter, which is missing in CArray.
I've used something like the following for that purpose:
advanceForeignPtr :: ForeignPtr a -> Int -> IO (ForeignPtr a)
advanceForeignPtr fp n = withForeignPtr fp $ \p ->
newForeignPtr_ (p `advancePtr` n)
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On Sun, Feb 1, 2009 at 4:07 PM, Duncan Coutts wrote: > [re-sending the cc to -cafe as I sent from the wrong address the first time] > > On Sun, 2009-02-01 at 12:43 -0600, Antoine Latter wrote: > >> After a bit of digging, I saw this snippet in the .cabal file for the >> iconv package on hackage: >> >> > >> -- We need to compile via C because on some platforms (notably darwin) >> -- iconv is a macro rather than real C function. doh! >> ghc-options: -fvia-C -Wall >> < >> >> But it looks like the 'iconv' package is broken in the exact same way >> for me - I get the same crazy linker errors. > > Yes, the workaround of using -fvia-C stopped working in ghc-6.10. I will > have to adapt the iconv package to use a C wrapper. > > Someone said that it is just the macports version of iconv that has this > problem but I don't understand that at all. If we're using default > ghc/gcc then we should not be looking in any non-standard include > directories at all. The pcre library isn't installed by default, so an OS X users might get it from MacPorts (which installs it in /opt/local/lib). And when building the Haskell pcre-light package, they'd do something like cabal install pcre-light --extra-lib-dirs=/opt/local/lib But then any other package that depends on pcre-light will also get the same linker option. > The other thing that makes no sense is that > the /usr/lib/libiconv.dywhatever file apparently contains both > _iconv_open and _libiconv_open so why can't we link to the ordinary > _iconv_open one? The problem is that with -L/opt/local/lib (which is now passed to any package depending on pcre-light), the linker uses /opt/local/lib/libiconv.* and ignores /usr/lib/libiconv.* altogether. Hope that helps explain it better, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
On Sun, Feb 1, 2009 at 10:04 AM, Antoine Latter wrote: > On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote: >> This is caused by OS X's libiconv being entirely CPP macros, the FFI has >> nothing to get hold of. IIRC there's a ghc bug report open for it. >> >> Bob >> > > So why does it sometimes work? I can write and compile executables > using haskeline, both with 'ghc --make' and 'cabal configure && cabal > build'. > > This sounds like something I can patch haskeline to account for, then? > The OS X system libiconv is actually OK; it's the MacPorts libiconv that has the CPP macros. When the cabal package depends on pcre-light it pulls in all of pcre-light's options; and like me, you probably compiled pcre-light to link against /opt/local/lib. To confirm this I ran "ghc --make -L/opt/local/lib test.hs" on my OS X machine and saw the same error as you. Thanks for the report; I'm not sure of what the right solution is, but I opened a ticket on Haskeline's bug tracker: http://trac.haskell.org/haskeline/ticket/74 Feel free to add comments, propose a fix or suggest a workaround. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: ghci-haskeline 0.1
On Tue, Jan 13, 2009 at 6:03 AM, Mauricio wrote: >>> Haskeline is designed to remove the readline dependency, because Windows >>> does not have readline. So rlwrap is useless there. >>> >> >> Ah, I hadn't considered Windows support--that makes sense. Thanks, >> that answers my questions. >> >> AHH > > One nice thing would be to write something like rlwrap > that would work everywhere Haskell does. Even more > sofisticated behavior could come from some comunication > from the api, using standard OS facilities (like a file > with an updated list of completions, or something more > clever). > > (For those interested: rlwrap is available in cygwin. > It used to work very well on old ghci, when line > editing wasn't available.) This does sound useful; the main difficulty is that when a program has stdin piped from another process it may behaved differently. For example, ghci uses block buffering and doesn't print its prompt when stdin doesn't appear to be a terminal. The solution on POSIX is probably to use some sort of pseudo-terminal support; I don't know what the right thing to do on Windows is. The following post discusses those issues in a little more detail: http://www.haskell.org/pipermail/haskell-cafe/2008-May/042342.html -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] Haskell web server + wiki: salvia-0.0.4 + orchid-0.0.6
On Thu, Jan 1, 2009 at 10:39 AM, Sebastiaan Visser wrote: > On Jan 1, 2009, at 7:15 PM, Gwern Branwen wrote: >> >> On Thu, Jan 1, 2009 at 9:04 AM, Sebastiaan Visser wrote: >>> >>> Happy new year, you all! >>> >>> I'm pleased to announce three new packages on Hackage: >>> ... >> >> Miscellaneous comments: >> 1) You're right about cabal-install versus runhaskell etc. There seems >> to be a(nother) Control.Exception issue with cabal-install using >> base-4: >> src/Network/Orchid/Backend/DarcsBackend.hs:91:29: >> Couldn't match expected type `IOException' >> against inferred type `Exception' >> Expected type: IO (Either IOException String) >> Inferred type: IO (Either Exception String) >> In the second argument of `()', namely >> `(try (U.readFile (repo /+ file)) :: >> IO (Either IOException String))' >> In the expression: >> eitherToMaybe >> >> (try (U.readFile (repo /+ file)) :: IO (Either IOException >> String)) > > I tried to enable building against both the old and the new Exception > libraries by using some preprocessor statements. It seems this attempt > failed. You may find the extensible-exceptions package from Hackage to be useful. It provides the new Exeptions API on all versions of ghc since 6.6 (and possibly earlier), so you don't have to deal with any preprocessing or cabal-install issues. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't cabal install readline
On Fri, Dec 5, 2008 at 1:10 PM, Martijn van Steenbergen <[EMAIL PROTECTED]> wrote: > Hello, > > This week I upgraded to GHC 6.10 using the .pkg installer. It installed > without a single hiccup -- thanks! > > I've noticed two odd things: the standard library haddock that comes with > the installer doesn't have links to the hs-coloured sources anymore (and > neither does the online documentation); I miss that a lot. I also can't > Ctrl+R anymore in GHCi to search my command history. But I can learn to live > without those. The following instructions should re-enable Ctrl-R: http://mult.ifario.us/p/editrc-tidbit-for-ghci > Another minor inconvenience is that the packages I had installed (using > cabal) are no longer available to GHC -- I think I will have to reinstall > them. But I cannot continue working on my Yogurt project anymore, because it > depends on readline, which fails to build: > > > checking for rl_readline_version... yes > checking for rl_begin_undo_group... no > configure: error: readline not found, so this package cannot be built > See `config.log' for more details. > cabal: Error: some packages failed to install: > Yogurt-0.2 depends on readline-1.0.1.0 which failed to install. > readline-1.0.1.0 failed during the configure step. The exception was: > exit: ExitFailure 1 The above happens because GHC is using the OS X default installation of libreadline.a which is actually a link to libedit that doesn't implement the full readline API. If you already have the MacPorts readline, you just need to tell cabal where it is, with (for example) cabal install readline --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: "Real World Haskell", now shipping
On Wed, Dec 3, 2008 at 11:53 AM, Andrew Coppin <[EMAIL PROTECTED]> wrote: > Brandon S. Allbery KF8NH wrote: >> >> On 2008 Dec 2, at 14:44, Andrew Coppin wrote: >>> >>> Regardless, it has been my general experience that almost everything >>> obtained from Hackage fails miserably to compile under Windows. (IIRC, one >>> package even used a Bash script as part of the build process!) I haven't >>> seen similar problems on Linux. (But I don't use Linux very often.) About >>> the worst problem there was Gtk2hs being confused about some Autoconfig >>> stuff or something... >> >> >> Many packages assume you have the msys / mingw stuff installed on Windows >> (if they work at all; those of us who don't develop on Windows wouldn't >> really know how to go about being compatible). >> > > According to the Cabal experts, the issue is that Windows doesn't have a > "standard" place for keeping header files like the various POSIX > environments typically do. That means anything that binds an external C > library (i.e., almost all useful Haskell packages) don't easily work on > Windows. I'm not sure what the solution to this is... Have you tried passing the --extra-include-dirs and --extra-lib-dirs arguments to 'cabal install'? On OS X, that's how I deal with the macports package manager which puts all library files under /opt/local. I've found the process pretty painless. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem building HXQ on Mac OS 10.5.5
On Tue, Dec 2, 2008 at 9:49 AM, Tobias Kräntzer <[EMAIL PROTECTED]> wrote: > Hi, > > I'm new to haskell and wonted to start tinkering a bit with this language, > specifically with HXQ. I have installed ghc with macports. > > Now while building HXQ I get the following error: > > Main.hs:20:9: >Not in scope: type constructor or class `C.SomeException' > > Unfortunately I'm also new to Mac OS X. Before I developed on Linux. > It would be great, if someone could give me a hint. > I think you should be able to build it if you manually download the .tar.gz file from Hackage and then type: runghc Setup configure runghc Setup build runghc Setup install The Control.Exception module was changed in ghc-6.10.1 (specifically, in the base-4 package). HXQ's code assumes that when compiling with ghc-6.10 you're always using base-4; however, that compiler also comes with base-3.0.3 which is a compatibility package providing the same interface as previous versions of ghc. The 'cabal install' program tries to be helpful and selects base-3.0.3 (since HXQ does not specify which to use), causing the above error. I've cc'd the package author on this. A possible fix would be to use the extensible-exceptions package, or otherwise just copy the logic from its .cabal file. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] global variables for foreign C functions
On Mon, Dec 1, 2008 at 4:55 PM, Evan Laforge <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato > <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I'm writing the bindings to a C library which uses, in some functions, >> global variables. >> >> To make it clearer, those functions need a global variable to be >> defined. A C program using my_function, one of the library functions, >> would look like: > > I don't think you can use the FFI to declare symbols for C. One > not-so-pretty but effective way to do it is create a stub.c with the > variables declared along with setting functions, then bind those > functions like any other. You can limit the size of that stub file using: foreign import ccall "&progname" progname :: Ptr (Ptr CChar) which lets you access that global variable and write the getters/setters in Haskell rather than C. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] definitive list of editline bindings anywhere?
On Fri, Nov 28, 2008 at 2:37 PM, Paul Brown <[EMAIL PROTECTED]> wrote: > > All -- > > Anyone have a definitive list of editline keybindings available? I find > myself missing some of the capabilities of readline, and there doesn't seem > to be documentation. You can usually get this from "man editrc", or otherwise the following page: http://www.manpagez.com/man/5/editrc/ -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPFR / FFI - Nefarious (Simple?) bug
On Sun, Oct 5, 2008 at 6:01 PM, Jared Updike <[EMAIL PROTECTED]> wrote: > Thanks for trying out my code. I'm glad it's not particular to my system. > > I suspected it had to do with the GHC RTS monkeying around with the > heap (lower precisions print more iterations and maybe aren't moving > through the heap as fast?) but I think when I added a statement to > print out the hex address for each Ptr MPFR that those pointers (to > 'one') in particular weren't getting moved. Likely the stuff living in > the heap, pointed at in the MPFR struct, specifically the pointer to > the limbs (the mantissa or actual digits of the number) are getting > kludged.. I don't really understand why this is the case when I don't > think I'm allocating a lot of the heap or anything, just printing the > same number over and over... Is there a space leak somewhere? (I can > also verify that mpf_new_mpfr is only getting called once per program > run by appending to a file each time it gets called). How do I tell > GHC "leave this mess and anything in the C heap completely alone?" > Usually, you can expect GHC to leave the C heap alone. The exception, unfortunately, is GMP (which is used by MPFR). See the following ticket: http://hackage.haskell.org/trac/ghc/ticket/311 I'm guessing that's the cause of the corruption. The relevant note from that ticket: > It's a known problem that you can't use GMP via the FFI from > your Haskell code in GHC, or use a C library that internally > uses GMP. We should really use a private version of GMP > with function names that don't overlap, or better still > replace GMP altogether. The comment in that ticket from Benedict Huber details some possible workarounds. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-timeout with gtk
On Thu, Sep 18, 2008 at 9:46 AM, Marco Túlio Gontijo e Silva <[EMAIL PROTECTED]> wrote: > Hello, > > I've written a simple sequencer[0] using gtk2hs and control-timeout[1]. > In GHCi it works fine, but when I compile it, the timeouts generated by > control-timeout are not executed. Actually, when I use the keyboard a > lot, at some time they got executed. I thought it could be that these > two packages are incompatible, but the I wondered why they work in GHCi. > > Any ideas? > Just a guess, but this might be a problem with control-timeout's use of the unsafePerformIO global variables hack. It's missing the standard NOINLINE annotations which prevent multiple copies of the global variable from being created. See the haddock docs for System.IO.Unsafe.unsafePerformIO for more information. -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mac OS X dylib woes
On Tue, Sep 16, 2008 at 4:49 PM, John MacFarlane <[EMAIL PROTECTED]> wrote: > I'm hoping some Haskell developers who use Macs can help me with this > one. I can install pcre-light just fine using cabal install. But when I > try to use it, I get this error: > [snip] > OK, so it can't find the pcre library (which is in /opt/local/lib). > I can fix that: > > export DYLD_LIBRARY_PATH=/opt/local/lib > > Now it works. But other things are broken! For example, I can't run vim, > which looks for a library called libJPEG.dylib and now finds libjpeg.dylib > in /opt/local/lib (case-insensitive file system!). > I can't reproduce this, although I'm running ghc-6.8.3. It's possible something wonky happened when you previously installed pcre-light. If you type "ghc-pkg describe pcre-light", does it list "/opt/local/lib" under the "library-dirs:" field? If not, that's most likely your problem. Try unregistering the library and reinstalling with: cabal install pcre-light --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib If that doesn't work, I think you can work around your problem with libjpeg/libJPEG by setting DYLD_FALLBACK_LIBRARY_PATH=$HOME/lib:/usr/local/lib:/lib:/usr/lib:/opt/local/lib Which should cause the linker to favor system libraries over macports' libraries. Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] system in forkIO
On Sun, Sep 14, 2008 at 10:24 AM, Marco Túlio Gontijo e Silva <[EMAIL PROTECTED]> wrote: < > When I run this code, I get > > fork > > and the result of ls only after I press a key. Does getChar blocks the > other threads? > I think this behavior is caused by (or at least related to) the following GHC bug: http://hackage.haskell.org/trac/ghc/ticket/2363 That bug has been fixed for the 6.10 release; my testing indicated that your program behaves correctly in that version. See the above bug report for some suggestions on how to work around the 6.8 getChar blocking. Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] contributing to standard library
On Tue, Aug 26, 2008 at 2:49 PM, Tim Newsham <[EMAIL PROTECTED]> wrote: > Like everyone else who has used Haskell for a while, I'm accumulating > functions which I feel should have already been in the standard > libraries. What's the normal path to contributing functions for > consideration in future standard libraries? Is there some > experimental standard lib that we can contribute to to "try > out" for the big league? > > Here are some functions: > http://www.thenewsh.com/%7Enewsham/x/machine/Missing.hs > The official process for proposing a change to the standard libraries is documented at: http://www.haskell.org/haskellwiki/Library_submissions -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Top Level <-
On Tue, Aug 26, 2008 at 3:15 AM, Ashley Yakeley <[EMAIL PROTECTED]> wrote: > Judah Jacobson wrote: >> >> I've been wondering: is there any benefit to having top-level ACIO'd >> <- instead of just using runOnce (or perhaps "oneshot") as the >> primitive for everything? > > I don't think oneshots are very good for open witness declarations (such as > the open exceptions I mentioned originally), since there are pure functions > that do useful things with them. I think you're saying that you want to write "w <- newIOWitness" at the top level, so that w can then be referenced in a pure function. Fair enough. But newIOWitness's implementation requires writeIORef (or an equivalent), which is not ACIO, right? I suppose you could call unsafeIOToACIO, but if that function is used often it seems to defeat the purpose of defining an ACIO monad in the first place. > Not sure about TVars either, which operate in the STM monad. Would you also > need a oneshotSTM (or a class)? Interesting point; I think you can work around it, but it does make the code a little more complicated. For example: oneshot uniqueVar :: IO (TVar Integer) uniqueVar =< atomically $ newTVar 0 -- alternately, use newTVarIO uniqueIntSTM :: IO (STM Integer) uniqueIntSTM = uniqueVar >>= \v -> return $ do n <- readTVar v writeTVar v (n+1) return n getUniqueInt :: IO Integer getUniqueInt = uniqueIntSTM >>= atomically -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level <-
On Tue, Aug 26, 2008 at 12:07 AM, Adrian Hey <[EMAIL PROTECTED]> wrote: > > > But from a top level aThing <- someACIO point of view, if we're going to > say that it doesn't matter if someACIO is executed before main is > entered (possibly even at compile time) or on demand, then we clearly > don't want to observe any difference between the latter case and the > former (if aThing becomes garbage without ever being demanded). > > Maybe it would be safest to just say anything with a finaliser can't be > created at the top level. We can always define an appropriate top level > "get" IO action using runOnce or whatever. I've been wondering: is there any benefit to having top-level ACIO'd <- instead of just using runOnce (or perhaps "oneshot") as the primitive for everything? For example: oneshot uniqueRef :: IO (MVar Integer) uniqueRef =< newMVar 0 It was also suggested in that wiki page: http://haskell.org/haskellwiki/Top_level_mutable_state#Proposal_4:_Shared_on-demand_IO_actions_.28oneShots.29 Those proposals eliminate the need for creating an ACIO monad and enforcing its axioms, since one-shot actions are executed in-line with other I/O actions (rather than at some nebulous "before the program is run" time). So, in the context of top-level initializers, does ACIO offer something beyond what oneshot provides on its own? If not, I prefer the latter since it seems like a much simpler solution. Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LDAP 0.6.3 build failure
On Fri, Jun 13, 2008 at 4:39 PM, Jason Dusek <[EMAIL PROTECTED]> wrote: > I'm trying to build the LDAP libs, version 0.6.3, on a recent > MacBook Air with OpenLDAP 2.3.27 (the version of OpenLDAP > shipped by Apple). > > The "atom sorting error" I get from `ld` is outside my range > of knowledge -- if some could advise me on how to get around > it, I'd be much obliged. I'm using the Apple toolchain to do > do the build. > That "error" is actually a harmless warning; in my experience it can be safely ignored. More information at: http://www.nabble.com/Re%3A--Fwd%3A-Re%3A-Problem-building-hdbc-sqlite3-with-ghc-6.8.2--p14602140.html -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FunPtr error?
2008/6/9 Galchin, Vasili <[EMAIL PROTECTED]>: > Ryan, > > I tried but the compiler didn't seem to like the keyword "import": > > [EMAIL PROTECTED]:~/FTP/Haskell/unix-2.2.0.0/tests/timer$ runhaskell > Setup.lhs build > Preprocessing executables for Test-1.0... > Building Test-1.0... > [1 of 1] Compiling Main ( ./timer.hs, > dist/build/timer/timer-tmp/Main.o ) > > ./timer.hs:29:8: parse error on input `import' > Hi Vasili, To fix that error, you probably just need to add the line "Extensions: ForeignFunctionInterface" to the .cabal file. (That is the equivalent of calling ghc by itself with the command-line arguments -fffi or -XForeignFunctionInterface.) Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Patrick Perry's BLAS package
2008/6/6 Patrick Perry <[EMAIL PROTECTED]>:
>
> Apart from some warnings, the library compiles fine in my
> system. But there is a minor issue about the library it
> links against when `./Setup test'. I need to use `-lcblas'
> instead of `-lblas' to get it to link to correct libraries.
> I don't know other people's system. But in my system,
> Gentoo Linux, I use blas library provided by atlas, and
> libblas.so is a fortran library and libcblas.so is for C.
>
> I don't know of a good way to get around this. It seems like every system
> has a different convention for the location and name of the cblas libraries.
> So, everyone has to edit the "extra-libraries" and the "extra-lib-dirs"
> field in the blas.cabal file. Does anyone know of a better way of doing
> this?
>
My preference is to use an autoconf script to solve that problem.
("build-type: Configure" in the cabal file.)
For example, the editline and readline C libraries require termcap,
which may be linked using one of -lcurses, -ltermcap, etc. The
Haskell packages have a configure script which checks which of
curses/termcap is available and outputs an editline.buildinfo file
with the extra-libraries field filled in. That file is then used
automatically by cabal in the build and install phases.
See for example:
http://code.haskell.org/editline/editline.cabal
http://code.haskell.org/editline/configure.ac
http://code.haskell.org/editline/editline.buildinfo.in
There's also more information is in the Cabal manual:
http://haskell.org/cabal/release/latest/doc/users-guide/x30.html#system-dependent
Best,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fighting the monad stack, MonadIO
On Thu, Apr 10, 2008 at 7:50 AM, Adam Smyczek <[EMAIL PROTECTED]> wrote:
> For a small webapi binding I try to implement a session like monad
> by building a stack including BrowserAction from Network.Browser
> module as following:
>
> newtype RBAction a = RBAction
> { exec :: ErrorT String (StateT RBState BrowserAction) a }
> deriving (Functor, Monad, MonadState RBState)
>
> I would like the RBAction to implement MonadIO as well,
> but fight with the liftIO function for hours now, without success.
> Any idea how the implementation of liftIO could look like?
In order to make a stack of monads an instance of MonadIO, you need to
be able to run IO actions in the innermost monad (BrowserAction).
Ideally, that monad itself would be an instance of MonadIO; maybe the
authors of HTTP didn't do so because it would add a dependency on the
mtl package (which defines the MonadIO class).
Luckily, though, Network.Browser provides
ioAction :: IO a -> BrowserAction a
which is exactly what you need to write the MonadIO instances yourself.
-- Solution #1 --
> instance MonadIO BrowserAction where
> liftIO = ioAction
Then you can add MonadIO to the deriving clause for RBAction.
-- Solution #2 --
> instance MonadIO RBAction where
>liftIO = RBAction . lift . lift . ioAction
This pulls IO actions manually through the stack of transformers. It
might be better because if the HTTP package ever provided its own
instance of MonadIO BrowserAction, that would conflict with #1.
Hope that helps,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc?
On Sat, Mar 15, 2008 at 2:04 PM, Uwe Hollerbach <[EMAIL PROTECTED]> wrote: > > Hi, all, I have an old iMac G3, running OSX 10.3.9, to which I have a > sentimental attachment. I'd like to get ghc running on it, but the > pre-built binaries I can find are all for more-recent iMacs, so I > thought I would try to build it myself. I believe I read somewhere > that gcc 3.3.X didn't work quite right for recent ghc -- I'm trying > for now to build ghc 6.6.1 -- so I started by upgrading gcc to 3.4.6. > That's working. So, with that in place, I went to the "porting ghc to > a new arch" page and started going through the steps. I'm using a > laptop running linux as the "host" computer, so that's > i386-unknown-linux, some Fedora core derivative. It's using gcc 3.4.4. > It looks like ghc 6.4.1 had an installer package for 10.3.9; does that work for you? http://www.haskell.org/ghc/download_ghc_641.html I think that the current version of ghc is supposed to be buildable with 6.4, so you might be able to bootstrap 6.6 or 6.8 that way, without going through the whole porting process. Let us know if you run into problems with it. Hope that helps, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble finding exception source
Hi Denis, I was unable to run your program; it looks like there's a missing module 'Properties'. To include it in the sdist you probably need to add it under the other-modules field in the .cabal file. -Judah 2008/2/26 Denis Bueno <[EMAIL PROTECTED]>: > Hi all, > > I've got some code crashing with "Prelude.foldr1: empty list". In > GHCi, the code uses too much memory (I kill it after it consumes 1GB) > to be able to use :trace and :history, but I just found out about the > -xc RTS option. I tried that, and I get the following: > > dsat: Prelude.foldr1: empty list > > Now, manually going through GHC.List > (http://haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-List.html) > I only found one CAF, namely prel_list_str, at the bottom of the file. > However, it is late and I quite possibly missed something. This CAF, > of course, doesn't seem a likely culprit. I also stumbled on some > discussion of the explicit call stack > > (http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack/StackTraceExperience) > which exemplifies the behavior I've found, but doesn't seem to suggest > a way to fix it. > > I'm developing on GHC 6.8.2. I've attached my code, the output of a > cabal sdist, which requires parse-dimacs [0] and bitset [1] (both > cabalised) to build. If you build the executable (with profiling), > you should see my behavior by running: > > ./dist/build/dsat/dsat -verify +RTS -xc > > I know that the problem is somewhere in the "Backtracking" section, in > the backJump function. But I don't know where. > > Any help is appreciated. > > -- > Denis > > [0] > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parse-dimacs-1.0.1 > [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bitset-0.5 > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple network client
On Jan 30, 2008 8:31 AM, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: > Peter Verswyvelen wrote: > > > Then I tried the "seq" hack to force the handle opened by readFile to be > > closed, but that did not seem to work either. For example, the following > > still gave access denied: > > > > main = do > > cs <- readFile "L:/Foo.txt" > > writeFile "L:/Foo.txt" $ seq (length cs) cs > > This is unfortunately a classic beginner's mistake. You got the seq > wrong here, which is very common. > [...] > You need to float the call to seq out so that it's evaluated before the > call to writeFile: > > length cs `seq` writeFile cs > Another way of doing things: I've recently become a fan of Control.Exception.evaluate: main = do cs <- readFile "L:/Foo.txt" evalute (length cs) writeFile "L:/Foo.txt" cs This might be easier for beginners to understand than messing around with seq's (as long as you're already in the IO monad). -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Supporting both cabals?
On Jan 3, 2008 4:26 PM, Magnus Therning <[EMAIL PROTECTED]> wrote: > GHC 6.8 has just made it into Debian in a usable form. (w00t!) > > Due to the library split my old cabal files don't work any longer. > updating them isn't the problem, the problem is keeping them compatible > with both versions of Cabal. I searched the wiki (quickly) but didn't > find anything on this topic. Is there a cookbook out there for it? The standard fix is to use Cabal configurations: http://www.haskell.org/haskellwiki/Upgrading_packages Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: GHC version 6.8.2
I neglected to CC the below email to haskell-cafe; apologies if anyone gets this twice. -- Forwarded message -- From: Judah Jacobson <[EMAIL PROTECTED]> Date: Dec 21, 2007 2:12 PM Subject: Re: [Haskell-cafe] Re: ANNOUNCE: GHC version 6.8.2 To: John Dorsey <[EMAIL PROTECTED]> On Dec 21, 2007 12:48 PM, John Dorsey <[EMAIL PROTECTED]> wrote: > On a related topic, I've been trying to build 6.8.2 on Leopard lately. > I've been running up against the infamous OS X readline issues. I know > some builders here have hacked past it, but I'm looking for a good > workaround... ideally one that works without changes outside the GHC > build area (besides installing a real readline). > > Here's what I noticed before I started drowning in the build platform. > (I'm no gnu-configure expert nor GHC insider.) > > I can get gnu-readline installed from Macports, no problem. > > The top-level configure in GHC doesn't respond to my various attempts: > > o using --with-readline-libraries and --with-readline-includes > (Although it looks like the libraries/readline/configure script > might recognize these, I can't get an option to pass through.) Actually, this is supposed to work. When running the top-level ghc configure, you should be able to just say ./configure --with-readline-libraries=/opt/local/lib --with-readline-includes=/opt/local/include and have those arguments automatically passed to the readline configure script. I just checked that this works on my machine (Tiger x86) when building 6.8.2 against MacPorts' readline. If it doesn't work for you, what errors are you getting? Also, a couple of other generic questions: - Are you on x86 or PPC? (The latter is not working right yet with Leopard.) - How are you bootstrapping the build of 6.8.2: are you using a pre-built binary of ghc-6.8.1, or some other way? Best, -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is StateT what I need?
On Dec 17, 2007 1:04 PM, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote: > > On Dec 17, 2007, at 15:41 , Brent Yorgey wrote: > > > Yes, and in fact, you don't even need foldM. The only thing that > > actually uses IO is the readFile, so ideally > > Actually, a quick check indicates that the regex functions used in > getProcInfo are in IO as well (?!). > Those functions look pure to me: GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m +Text.Regex Prelude Text.Regex> :t matchRegex . mkRegex matchRegex . mkRegex :: String -> String -> Maybe [String] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet another top-level state proposal
On 5/26/07, Adrian Hey <[EMAIL PROTECTED]> wrote:
Judah Jacobson wrote:
> In contrast to recent proposals, this one requires no extra syntax or
> use of unsafe functions by the programmer.
I'm not aware of any proposals (recent or ancient:-) that require the
use of unsafe functions by the programmer (well apart from the
unsafePerformIO hack itself).
I was referring to the proposal to make that hack somewhat safer by
adding a NO_INLINE_OR_CSE pragma.
Also adding extra syntax is no problem
these days. It's trivially simple (and indeed desirable in this case
IMHO). It's the underlying compiler magic requires significant extra
work I think.
Reading last week's conversation on the topic, I got the impression
that the debate is still ongoing with respect to that point. Although
this proposal is a little less aesthetic than those for mdo or ACIO, I
think the fact that it touches so few parts of the language might make
some people more comfortable with it. In particular, an
implementation only needs to:
- add the OnceInit/OnceIO class declarations (trivial)
- add the "OnceIO" deriving clause logic (in GHC, this would be
isolated to one module)
- add a NO_CSE pragma at the Core syntax level. (already suggested for
other conservative proposals).
But whether that's being *too* conservative is a matter of opinion, of course.
>
> Under this proposal, we would write instead:
>
> newtype UniqueRef = UniqueRef (IORef Integer)
>deriving OnceIO
>
> instance OnceInit UniqueRef where
>onceInit = liftM UniqueRef (newIORef 0)
A purely aesthetic objection, but to me it looks quite obfuscated
compared to:
uniqueRef :: IORef Integer
uniqueRef <- ACIO.newIORef 0
But I guess perhaps what's going on here could be made clearer with
the right syntactic sugar :-)
If you're going to use syntactic sugar anyway, I think that negates
the main appeal of this proposal. Instead, we could ignore deriving
clauses altogether, and add an optional keyword "oneshot" to type
declarations, e.g.:
oneshot uniqueRef :: IO (IORef Integer)
uniqueRef = newIORef 0
Now that I mention it, that idea's not too bad either...
Finally, the useage problem I mentioned. Having to create a distinct
type for each "top level thing with identity" (my terminology)
seems like it could cause difficulties (probably not insoluble
problems though).
My feeling is that most programs would use few enough TWIs that having
to declare extra types would not be a big hastle. But I see you're
challenging that point below:
If you look at the wiki page you'll see the device driver example I
put there. This has two device handles at the top level (both same
type), with a device driver API that takes either the device handle
itself or a device session handle (which will contain the corresponding
device handle) as parameters (so in principle it can be used with any
number of devices provided the corresponding device handles are
available).
My question is, what would this example look like using the solution
you propose? I can think of at least two possibilities, both of which
seem quite awkward. But I'll leave it to you to think about this
with a bit more care than perhaps I have. It'd be nice to see the
solution on the Wiki too.
If you want several different devices, you could wrap them all in one
large type:
data DeviceHandle = ...
createDeviceHandle :: BaseAddress -> IO DeviceHandle
data AllHandles = AllHandles {handle1, handle2 :: DeviceHandle} deriving OnceIO
instance OnceInit AllHandles where
onceInit = liftM2 AllHandles
(createDeviceHandle baseAddress1)
(createDeviceHandle baseAddress2)
device1, device2 :: IO DeviceHandle
device1 = liftM handle1 runOnce
device2 = liftM handle2 runOnce
This proposal does seem to encourage consolidating TWIs into one part
of the program; from a design perspective, that may not be entirely a
bad thing.
Best,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yet another top-level state proposal
Hi all,
Given the recent discussion about adding top-level mutable state to
Haskell, I thought it might be a good time to throw my own proposal
into the ring. If enough people think it's worth considering, I can
add it to the wiki page.
(http://www.haskell.org/haskellwiki/Top_level_mutable_state)
In contrast to recent proposals, this one requires no extra syntax or
use of unsafe functions by the programmer. Any nonstandard "magic"
that might occur is kept within the compiler internals. Furthermore,
top-level initializations are only executed when needed; merely
importing a module does not cause any additional actions to be run at
startup.
The core idea, similar to that of "type-based execution contexts" on
the above wiki page, is to associate each top-level action with its
own type. For example, the current way to declare a source for unique
integers is:
{-# NOINLINE uniqueRef #-}
uniqueRef :: IORef Integer
uniqueRef = unsafePerformIO $ newIORef 0
uniqueInt :: IO Integer
uniqueInt = do
n <- readIORef uniqueRef
writeIORef uniqueRef (n+1)
return n
Under this proposal, we would write instead:
newtype UniqueRef = UniqueRef (IORef Integer)
deriving OnceIO
instance OnceInit UniqueRef where
onceInit = liftM UniqueRef (newIORef 0)
uniqueInt :: IO Integer
uniqueInt = do
UniqueRef uniqueRef <- runOnceIO
n <- readIORef uniqueRef
writeIORef uniqueRef (n+1)
return n
The above code uses two classes:
class OnceInit a where
onceInit :: IO a
class OnceInit a => OnceIO a where
runOnceIO :: IO a
The OnceInit class lets the programmer to specify how a type is
initialized; above, it just allocates a new IORef, but we could also
read a configuration file or parse command-line arguments, for
example.
In contrast, instances of the OnceIO class are not written by the
programmer; instead, they are generated automatically by a "deriving
OnceIO" clause.Each type for which OnceIO is
derived will have a special top-level action associated with it, which
is accessed through the runOnceIO function. Its semantics are:
- The first time that "runOnceIO" is called, it runs the corresponding
"onceInit" action and caches and returns the result.
- Every subsequent time that "runOnceIO" is called, it returns the
cached result.
This behavior is safe precisely because runOnceIO is an IO action.
Even though one can't guarantee when in the program an initialization
will occur, when the initialization does happen it will be sequenced
among other IO actions.
To illustrate this behavior, here are a couple sample implementations
in plain Haskell. These do use unsafePerformIO, but in practice any
such details would be hidden in the instance derived by the compiler
(along with any related NOINLINE/NOCSE pragmas):
instance Once UniqueRef where
runOnceIO = return $! unsafePerformIO onceInit
or (less efficient, but multithreaded safe):
instance Once UniqueRef where
runOnceIO = modifyMVar onceUniqueRef $ \mx -> case mx of
Just x -> return (Just x, x)
Nothing -> do {x <- onceInit; return (Just x, x)}
onceUniqueRef = unsafePerformIO $ newMVar Nothing
Finally, note that the deriving clause can easily check whether the
type in question is monomorphic (as is necessary for type-safety),
since it already has access to the type definition.
Anyway, that's the gist of my proposal; I hope I've explained it well,
but please let let me know if you have questions, suggestions or
criticisms.
Best,
-Judah
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question: template-haskell and profiling
Alternately, the "standard" way to use profiling with template haskell
is a 2-stage process:
- First, compile all of the modules normally, *without* -prof
- Then, compile all of the module again, with the following flags:
-prof -osuf p_o
These steps, and the reason this workaround is necessary, are
documented in the GHC user manual (section 7.6.4):
http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#id3154592
Best,
-Judah
On 4/27/07, Robin Green <[EMAIL PROTECTED]> wrote:
As a workaround, you could try to use zeroTH to preprocess the template
haskell. (I have a patched version of zeroTH that works better but it
currently requires a patched version of GHC - ask me if you want it.)
ZeroTH darcs repo: http://darcs.haskell.org/~lemmih/zerothHead/
Original announcement by Lemmih:
http://permalink.gmane.org/gmane.comp.lang.haskell.template/219
--
Robin
On Fri, 27 Apr 2007 20:26:21 +0700
"ET" <[EMAIL PROTECTED]> wrote:
> Hi, folks
>
> Trying to profile the modules, those contain a template-haskell
> splices, I have ran into problem - GHC6.4 (win2K) returns an error
> message and then stops. Without the "-prof" option all works fine.
>
> Is there a way to bypass this inconsistency?
>
>
> Example below illustrates the problem:
>
>
>
> {-# OPTIONS_GHC -fth #-}
> module Main where
>
> import MainTH
>
> main :: IO ()
> main = putStrLn . show . fact $ 100
>
> fact :: Integer -> Integer
> fact n = $(thFact "n")
>
>
>
> module MainTH where
>
> import Language.Haskell.TH
>
> thFact :: String -> ExpQ
> thFact s = appE (dyn "product")
> (arithSeqE (fromToR (litE . integerL $ 1) (dyn s)))
>
> preview :: IO ()
> preview = runQ (thFact "x") >>= putStrLn . pprint
>
>
>
> >ghc --make -prof Main.hs
> Chasing modules from: Main.hs
> Compiling MainTH ( ./MainTH.hs, ./MainTH.o )
> Compiling Main ( Main.hs, Main.o )
> Loading package base-1.0 ... linking ... done.
> Loading package haskell98-1.0 ... linking ... done.
> Loading package template-haskell-1.0 ... linking ... done.
> ghc:
> ./MainTH.o: unknown symbol `_era'
>
> With function "MainTH.preview" excluded from export list, final
> phrase were ghc:
> ./MainTH.o: unknown symbol `_entering_PAP'
>
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling GHC from CVS
I had this happen to me a few weeks ago; the fix was to upgrade make using fink. Right now I have v.3.79.1; which version do you have? -Judah On Fri, 25 Feb 2005 16:51:58 -0600, Arjun Guha <[EMAIL PROTECTED]> wrote: > I'm having trouble compiling GHC from CVS. Make seems to be looping > infinitely while compiling the stage1 compiler. Make -d gives me: > > Pruning file 'main/Config.hs' > > On and on and on. > > The commands I used to make (from the fptools) directory were: > > autoreconf > ./configure --prefix=/Users/arjun/local/fptools > Make > > I'm using Mac OS X 10.3.8 with GHC 6.2.1. > > -Arjun > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Global Variables and IO initializers
On Thu, 25 Nov 2004 01:46:03 +, Ben Rudiak-Gould <[EMAIL PROTECTED]> wrote: > Benjamin Franksen wrote: > > > My god, what a stupid mistake. I should just give it up... :-( > > Funny you should say that, because I made the same mistake two weeks ago > and felt the same way: > > http://www.haskell.org/pipermail/haskell-cafe/2004-November/007556.html > > Live and learn... > > -- Ben > And I (as the poster of the message correcting Ben) had made a related but even more severe mistake several days earlier: http://www.haskell.org//pipermail/haskell-cafe/2004-November/007527.html Strength in numbers? Best, -Judah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey <[EMAIL PROTECTED]> wrote:
> On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
>
>
> > On the other hand, these are perfectly safe:
> >
> > once' :: IO a -> IO (IO a)
> > oncePerString :: String -> IO a -> IO a
> > oncePerType :: Typeable a => IO a -> IO a
> >
> > once' seems virtually useless unless you have top-level <-, but the
> > other two don't need it. I'm not sure which would be preferable. I lean
> > toward oncePerString as more flexible and predictable, though it
> > requires a certain discipline on the part of its users.
>
> Having taken a bit of time to look at this, I have to say that IMO
> saying they are "perfectly safe" is over stating things a bit :-)
>
How is oncePerType in particular unsound? I've given a quick example
implementation below. It's a referentially transparent function (no
use of unsafePerformIO except to implement an internal global
hashtable), it's type-safe, and I imagine that the discipline involved
is no worse than that of dynamic exceptions, for example.
I'm not necessarily suggesting that this solves the discussion, but it
could be good enough to replace unsafePerformIO in many situations.
Incidentally, a similar idea was suggested by George Russell, but not
really followed up on:
http://www.haskell.org/pipermail/haskell/2004-June/014104.html
(This was perhaps the first message in the current months-long discussion?)
-Judah
---
module OnceType(oncePerType) where
import Data.Dynamic
import Data.Hashtable as HT
import Data.Int(Int32)
import GHC.IOBase (unsafePerformIO)
type Dict = HT.HashTable TypeRep Dynamic
oncePerType :: Typeable a => IO a -> IO a
oncePerType (action :: IO a) = do
let rep = typeOf (undefined :: a)
l <- HT.lookup globalDict rep
case l of
Nothing -> do -- run the action
x <- action
HT.insert globalDict (typeOf x) (toDyn x)
return x
Just dyn -> case fromDynamic dyn of
-- since we store values according to their TypeRep,
-- fromDynamic should never fail.
Just x -> return x
{-# NOINLINE globalDict #-}
globalDict :: Dict
globalDict = unsafePerformIO $ HT.new (==) hashTypeRep
-- this could be implemented better using the internals of Data.Typeable
hashTypeRep :: TypeRep -> Int32
hashTypeRep = hashString . show
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
On Thu, 11 Nov 2004 20:14:24 +, Keean Schupke <[EMAIL PROTECTED]> wrote: > I think you are right... The only safe operation I can see for a > one-time init > is type IO (). All results have to be returned via side effects. Hence with > my named-MVar proposal the first execution of the init function initialises > certain named-MVars, and subsequent executions do nothing at all. The > functions in the library would use the names-MVars directly. Therefore the > once function in the NamedSem library is: > > once :: IO () -> IO () > > Keean. > Actually, I don't see anything wrong on the face of it with oncePerType :: Typeable a => IO a -> IO a since the only instances of Typeable are monomorphic. Indeed, the implementation seems pretty straightforward: store the results of already-run computations as Dynamic values in a global dictionary, keyed by TypeRep. -Judah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
On Thu, 11 Nov 2004 12:27:17 +, Ben Rudiak-Gould
<[EMAIL PROTECTED]> wrote:
>
> On the other hand, these are perfectly safe:
>
> once' :: IO a -> IO (IO a)
> oncePerString :: String -> IO a -> IO a
> oncePerType :: Typeable a => IO a -> IO a
>
> once' seems virtually useless unless you have top-level <-, but the
> other two don't need it. I'm not sure which would be preferable. I lean
> toward oncePerString as more flexible and predictable, though it
> requires a certain discipline on the part of its users.
>
Reflecting on the matter, I don't think that oncePerString is
type-safe. For example, it allows us to create the following:
ref :: IO (IORef a)
ref = oncePerString "foo" (newIORef undefined)
Here's an example in which we subvert the type system (and probably
crash the program) by writing a String and reading an Int from the
same IORef:
do
ref >>= writeIORef ("foo")
(x :: Int) <- ref >>= readIORef
print x
This is similar to the reason for ML's value monomorphism restriction.
In contrast, oncePerType
preserves monomorphism nicely, since all instances of Typeable are monomorphic.
Thoughts? Am I missing something?
-Judah
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
On Thu, 11 Nov 2004 09:16:04 +, Adrian Hey <[EMAIL PROTECTED]> wrote: > > That's the trouble with unsafePerformIO. Haskell is supposed to be a > purely functional language and the compiler will assume all functions > are pure. As soon as you use unsafePerformIO to create something that > isn't a function you're in grave danger, even if it "looks safe" at > the local level, it still isn't a function and the damage can't be > contained at the local level. It's only really OK if it still is > a function despite the use of unsafePerformIO (which is possible, > but often hard to be sure about). Your first reply convinced me that supplying once as a function would be bad. I'm still not entirely convinced that hiding it in the compiler implementation of (x <- someAction) is infeasible, but as you say the devil's in the details. Even if it could be hacked to work, the added complexity is probably not worth it. > But I thought the point you were making was that the once guaranteed > that the resulting value was independent of when it got reduced > (presumably for any action). This isn't generally true, any more > than it would be true for the x <- someAction solution if some > action can be *any* IO monadic operation. Ok, I think that's where we diverged. I was trying to be more ambition and also consider actions such as reading in a configuration file, which seems to be another common use of unsafePerformIO. The idea behind "once" is that although the return value does depend on when it's reduced, this happens at a well-defined location (namely, where it first appears in the sequence of IO actions that makes up the program). But in any event, the proposal for oncePerString/Process/Type seems like a much a more robust solution than mine. Best, -Judah ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One-shot? (was: Global variables and stuff)
What about the following? It does use unsafePerformIO, but only to
wrap newMVar in this
specific case.
once :: Typeable a => IO a -> IO a
once m = let {-# NOINLINE r #-}
r = unsafePerformIO (newMVar Nothing)
in do
y <- takeMVar r
x <- case y of
Nothing -> m
Just x -> return x
putMVar r (Just x)
return x
The "Typeable" constraint forces the return value to be monomorphic,
which prevents the
following from happening (the first line doesn't type check under the
constraint):
> let ref = once (newIORef [])
> :t ref
ref :: forall a. IO (IORef [a])
> ref >>= flip writeIORef "foo"
> ref >>= readIORef >>= (\(x::[Bool]) -> print x)
[Illegal instruction
Additionally, I'd like to repeat the point that "once" (whether
defined my way or Keean's) is
not just a consequence of module initialization; it can actually
replace it in most cases!
For example:
myRef :: IO (IORef Char)
myRef = once (newIORef 'a')
readMyRef :: IO Char
readMyRef = myRef >>= readIORef
writeMyRef :: Char -> IO ()
writeMyRef c = myRef >>= flip writeIORef c
A library interface might consist of readMyRef and writeMyRef, while hiding
myRef itself from the user. However, what happens in IO stays in the
IO monad; myRef is an action, so the IORef is not initialized until
the first time
that one of read/writeMyRef is called. Indeed, any action wrapped by once
will only be run in the context of the IO monad. IMO, this is the primary
advantage of a function like once over the proposal for top-level
x <- someAction
where the exact time someAction is evaluated is unspecified.
Are there any applications of module initialization for which once
does not suffice?
-Judah
On Wed, 10 Nov 2004 17:11:31 +, Keean Schupke
<[EMAIL PROTECTED]> wrote:
> I have written a small library for supporting one-shot without using
> unsfePerformIO...
> The library uses SYSV semaphores under linux to make sure the functional
> argument of
> "once" is only ever run once. It uses the ProcessID as the key for the
> semaphore, so will
> even enforce the once-only property accross different Haskell threads.
> Some semaphore
> functions are also exported, allowing other constraints to be used (for
> example, once
> only over multiple processes by using a constant ID rather than the
> processID.
>
> I have attached the source for the library incase anyone is interested.
> If people think
> it is useful I could put it up on a website (let me know). Also attached
> is an example,
> which can be compiled with:
>
> ghc -o test NamedSem.hs Test.hs -package posix
>
> Keean.
>
>
> ___
> Haskell-Cafe mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
