Re: [Haskell-cafe] Getting highest sum of list elements with Map
-- based on http://jtauber.com/blog/2008/02/10/a_new_kind_of_graded_reader/ -- TODO: read knownwords from file -- print out matching sentences as well (make optional) -- fix performance; goal: handle Frank Herbert corpus in under 5 minutes import Data.Ord import Data.Char (isPunctuation, toLower) import Data.List -- (nub, sort) import qualified Data.Set as Set import qualified Data.Map as Map import Control.Parallel.Strategies import Data.Function (on) import Data.List.Split (splitWhen) import System.IO.UTF8 (getContents, putStrLn) import System.Environment (getArgs) main :: IO () main = do depth - fmap (read . head) $ getArgs corpus - System.IO.UTF8.getContents let pcorpus = processCorpus corpus let knownwords = map (map toLower) [You, dont, see, more, than, that, The, first, episode, of, Kare, Kano, is, rotten, with, Evangelion, visual, motifs, the, trains, the, spotlights, and, telephone, poles, and, wires, the, masks, and, this, is, how, everyone, sees, me, etc, a, it, did, are, to, in, I, Dune, was, Stalin, Mussolini, Hitler, Churchill, beginning, That, all, be, like, on, an, Its, But, only, you, themes, into, as, my, human, paradox,he,said,paul,his,she,her,not,him,had,for,at,alia,no,from,what,asked,they,there,have,stilgar] let optimalwords = answer depth pcorpus knownwords System.IO.UTF8.putStrLn optimalwords -- | Clean up. Don't want 'Je suis. to look different from Je suis... -- -- stringPunctuation Greetings, fellow human flesh-sacks! ~ Greetings fellow human fleshsacks stripPunctuation :: String - String stripPunctuation = filter (not . isPunctuation) -- Turn a single big document into a stream of sentences of individual words; lower-case so we don't get -- multiple hits for 'He', 'he' etc processCorpus :: String - [[String]] processCorpus = map (sort . words . stripPunctuation) . splitWhen (=='.') . map toLower sentences :: (NFData a, Ord a) = [[a]] - Map.Map Int (Set.Set a) sentences = Map.fromList . zip [(0::Int)..] . map Set.fromList fidiv :: (Integral a, Fractional b) = a - a - b fidiv = (/) `on` fromIntegral ranks :: (NFData v, Ord k, Ord v) = Map.Map k (Set.Set v) - [(v, Rational)] ranks s = Map.toList . Map.fromListWith (+) $ [(word, rank) | (_sentenceId, wrds) - Map.toList s, let rank = 1 `fidiv` Set.size wrds, word - Set.toList wrds] approximation :: (NFData v, Ord k, Ord v) = Map.Map k (Set.Set v) - Int - [v] approximation _ 0 = [] approximation s n = case ranks s of [] - [] xs - let word = fst . maximumBy (comparing snd) $ xs in let withoutWord = Map.map (Set.delete word) s in word : approximation withoutWord (n-1) process :: (Ord v, NFData v) = [[v]] - [Int] - [[v]] process ss ns = map (approximation $ sentences ss) ns getBest :: [Int] -[[String]] - String getBest x y = unlines . last $ process y x filterKnown :: [String] - [[String]] - [[String]] filterKnown known = filter (not . null) . map (filter (flip notElem $ known)) answer :: Int - [[String]] - [String] - String answer depth corp known = let corp' = filterKnown known corp in getBest [1..depth] corp'___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SQL Database in Haskell?
2009/8/6 Don Stewart d...@galois.com: For pure Haskell persistance, there is TCache: A Transactional data cache with configurable persistence http://hackage.haskell.org/package/TCache io-storage: A key-value store in the IO monad. http://hackage.haskell.org/package/io-storage There may be others. persistent-map: A thread-safe (STM) persistency interface for finite map types. http://hackage.haskell.org/package/persistent-map (still experimental) Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
On 8/6/09, Don Stewart d...@galois.com wrote: leaveye.guo: Hi haskellers: There is a mistake in http://www.haskell.org/haskellwiki/State_Monad It post two functions like this : evalState :: State s a - s - a evalState act = fst $ runState act execState :: State s a - s - s execState act = snd $ runState act Both the '$' operators should be '.'. Anyone would correct it ? Fixed :) Well, it's a wiki ... :-) -- Don That might be true, but not everyone has an account :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI: Problem with Signal Handler Interruptions
The SIGVTALRM signal is delivered to one (random) thread in the program,
so I imagine it just isn't being delivered to the thread that runs your
second call to sleep. (the main Haskell thread is a bound thread and
hence gets an OS thread to itself).
Is there some reason you can't use threadDelay? threadDelay is much
more friendly: it doesn't require another OS thread for each sleeping
Haskell thread.
Cheers,
Simon
On 05/08/2009 17:01, Levi Greenspan wrote:
Nobody?
On Tue, Aug 4, 2009 at 10:06 AM, Levi
Greenspangreenspan.l...@googlemail.com wrote:
Dear list members,
In February this year there was a posting Why does sleep not work?
(http://www.haskell.org/pipermail/haskell-cafe/2009-February/055400.html).
The problem was apparently caused by signal handler interruptions. I
noticed the same (not with sleep though) when doing some FFI work and
compiled the following test program:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C.Types
import Control.Concurrent
sleep :: IO ()
sleep = c_sleep 3= print
fails :: IO ()
fails = sleep
works :: IO ()
works = forkIO sleep return ()
main :: IO ()
main = fails works threadDelay 300
foreign import ccall unsafe unistd.h sleep
c_sleep :: CUInt - IO CUInt
When compiled with GHC (using --make -threaded), it will print 3
immediately (from the fails function) and after 3 seconds 0 (from
works), before it finally exits. man sleep(3) tells me that sleep
returns 0 on success and if interrupted by a signal the number of
seconds left to sleep. Clearly fails is interrupted by a signal
(which seems to be SIGVTALRM). This was mentioned in the discussion
from February.
I would like to know why fails fails and works works, i.e. why is
sleep not interrupted when run in a separate thread? And what can be
done to make sleep work in the main thread? It wouldn't be wise to
block SIGVTALRM, wouldn't it?
Many thanks,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] n00b question: defining datatype
On Thu, Jul 23, 2009 at 08:17:34PM +0100, Iain Barnett wrote: [..] against the empty list it's not really a problem to have it there. I didn't realise I could use Maybe in the constructor because it's a monad, but that's good because I was wondering about the best way to make a nullable value. Actually, this has nothing to do with Maybe being a monad. The reason you can do this is because Maybe itself is not a type, but a (unary) type constructor(It has kind * - *), so you need to apply it to another type. Doing something like test :: Maybe would be an error. That Data.Tree module looks interesting too! It does seem to be a naturally recursive type, but I'm still trying to become easy with that sort of thought :) [..] A list is also recursively defined, so it is not really more difficult to use a Tree instead. E.g. one could define a list type like this: data List a = Nil | Cons a (List a) - Daniel pgpx25fhhGIwn.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FFI: Problem with Signal Handler Interruptions
Hi Simon,
Many thanks for your reply. I am not actually using sleep in my code.
I only used it for here for highlighting the problem. It will be the
same when using poll(2) for instance. Does this mean that because of
SIGVTALRM I can always get an EINTR when calling a foreign function
that blocks on a system call?
Cheers,
Levi
On Thu, Aug 6, 2009 at 12:17 PM, Simon Marlowmarlo...@gmail.com wrote:
The SIGVTALRM signal is delivered to one (random) thread in the program, so
I imagine it just isn't being delivered to the thread that runs your second
call to sleep. (the main Haskell thread is a bound thread and hence gets
an OS thread to itself).
Is there some reason you can't use threadDelay? threadDelay is much more
friendly: it doesn't require another OS thread for each sleeping Haskell
thread.
Cheers,
Simon
On 05/08/2009 17:01, Levi Greenspan wrote:
Nobody?
On Tue, Aug 4, 2009 at 10:06 AM, Levi
Greenspangreenspan.l...@googlemail.com wrote:
Dear list members,
In February this year there was a posting Why does sleep not work?
(http://www.haskell.org/pipermail/haskell-cafe/2009-February/055400.html).
The problem was apparently caused by signal handler interruptions. I
noticed the same (not with sleep though) when doing some FFI work and
compiled the following test program:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C.Types
import Control.Concurrent
sleep :: IO ()
sleep = c_sleep 3= print
fails :: IO ()
fails = sleep
works :: IO ()
works = forkIO sleep return ()
main :: IO ()
main = fails works threadDelay 300
foreign import ccall unsafe unistd.h sleep
c_sleep :: CUInt - IO CUInt
When compiled with GHC (using --make -threaded), it will print 3
immediately (from the fails function) and after 3 seconds 0 (from
works), before it finally exits. man sleep(3) tells me that sleep
returns 0 on success and if interrupted by a signal the number of
seconds left to sleep. Clearly fails is interrupted by a signal
(which seems to be SIGVTALRM). This was mentioned in the discussion
from February.
I would like to know why fails fails and works works, i.e. why is
sleep not interrupted when run in a separate thread? And what can be
done to make sleep work in the main thread? It wouldn't be wise to
block SIGVTALRM, wouldn't it?
Many thanks,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
Don Stewart wrote: leaveye.guo: Hi haskellers: There is a mistake in http://www.haskell.org/haskellwiki/State_Monad It post two functions like this : evalState :: State s a - s - a evalState act = fst $ runState act execState :: State s a - s - s execState act = snd $ runState act Both the '$' operators should be '.'. Anyone would correct it ? Well, it's a wiki ... :-) Which requires registration and has not been open for registration for some time now. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
On Thu, Aug 6, 2009 at 9:36 AM, Jake McArthurjake.mcart...@gmail.com wrote: Which requires registration and has not been open for registration for some time now. - Jake It's been open for registration for some time now. -- gwern signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
On Thu, Aug 6, 2009 at 15:52, Gwern Branwen wrote: On Thu, Aug 6, 2009 at 9:36 AM, Jake McArthur wrote: Which requires registration and has not been open for registration for some time now. It's been open for registration for some time now. In that case, how about changing the site notice[1] from Note: new account creation has been disabled as an anti-spam measure, which seems to indicate otherwise, to something more informative. Alternatively, add an informative link to the login page[2] and clear the site notice. Regards, Sean [1] http://www.haskell.org/haskellwiki/MediaWiki:Sitenotice [2] http://www.haskell.org/haskellwiki/Special:Userlogin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
On Thu, Aug 6, 2009 at 9:27 AM, Joachim Breitnerm...@joachim-breitner.de wrote: And cabal/hackage guys: Llease introduce a standard Changes format for cabal packages so that http://hackage.haskell.org/package/hlint readily lists (or links to) changes. (+1) Standardizing a CHANGES format and linking to from Hackage would be a very simple way to do changelogs in Hackage. I like this solution. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Request for Changelogs
Hi, (this is mostly a rant, but hopefully a constructive one) the Haskell/cabal/hackage eco system is pretty great, as we all know. But there is one huge gaping omission there: Changelogs! I’m involved in packaging Haskell stuff for Debian. Now, the Debian tools we have for that tell me „Hlint has a new version, 1.6.5, which is newer than the one you packages, 1.6.4. Huh, nice. What has changed? Is it relevant for Debian? Is it worth a new upload? There is no easy way to find out: http://hackage.haskell.org/package/hlint lists no changes http://community.haskell.org/~ndm/hlint/ lists no changes (and not every package has a homepage) http://community.haskell.org/~ndm/darcs/hlint/ contains on Changes file (and not every package has a (linked) darcs repository) http://community.haskell.org/~ndm/darcs/hlint/ also has no web frontend. Which leaves me with the option of getting the darcs repo and looking through darcs changes. If I know of a repository for the package. So please, package authors, put Changes files in your packages and keep the current for now. And cabal/hackage guys: Llease introduce a standard Changes format for cabal packages so that http://hackage.haskell.org/package/hlint readily lists (or links to) changes. Thanks, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
Hi I’m involved in packaging Haskell stuff for Debian. Now, the Debian tools we have for that tell me „Hlint has a new version, 1.6.5, which is newer than the one you packages, 1.6.4. Huh, nice. What has changed? Is it relevant for Debian? Is it worth a new upload? There is no easy way to find out: I went to my bug tracker, which informs me that: http://code.google.com/p/ndmitchell/issues/detail?id=206 http://code.google.com/p/ndmitchell/issues/detail?id=208 Were both fixed in this release. I don't think this is a practical way for people to find out what gets fixed, since it was rather difficult to get the information out, but it is the answer if you were interested in this case. http://community.haskell.org/~ndm/darcs/hlint/ also has no web frontend. Which leaves me with the option of getting the darcs repo and looking through darcs changes. If I know of a repository for the package. I also don't tag the darcs version when I make a release - I probably should... So please, package authors, put Changes files in your packages and keep the current for now. The problem is that this is the kind of dull administration stuff that isn't coding in Haskell, so tends to get neglected. If I know there is a user demand for a changelog I'm happy to provide one, but I don't want to waste time on something that isn't useful. For people who have a near zero-upgrade cost (anyone who is using Cabal) I'd suggest they upgrade to all of my packages immediately. For this change, I'd say it probably isn't worth rolling a new debian binary unless it's particularly easy. I will start a changelog in hlint - and for some of my projects (tagsoup) I do include a changelog in the user manual. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
On Thu, Aug 06, 2009 at 04:27:56PM +0200, Joachim Breitner wrote: And cabal/hackage guys: Llease introduce a standard Changes format for cabal packages so that http://hackage.haskell.org/package/hlint readily lists (or links to) changes. I second that! +1 -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
On Thu, Aug 6, 2009 at 10:01 AM, Sean Leatherleat...@cs.uu.nl wrote: On Thu, Aug 6, 2009 at 15:52, Gwern Branwen wrote: On Thu, Aug 6, 2009 at 9:36 AM, Jake McArthur wrote: Which requires registration and has not been open for registration for some time now. It's been open for registration for some time now. In that case, how about changing the site notice[1] from Note: new account creation has been disabled as an anti-spam measure, which seems to indicate otherwise, to something more informative. Alternatively, add an informative link to the login page[2] and clear the site notice. Regards, Sean [1] http://www.haskell.org/haskellwiki/MediaWiki:Sitenotice [2] http://www.haskell.org/haskellwiki/Special:Userlogin Only admins can edit the sitenotice, and the only active admin is Ashley, who I emailed earlier about this. -- gwern signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
Hi, Am Donnerstag, den 06.08.2009, 15:39 +0100 schrieb Neil Mitchell: So please, package authors, put Changes files in your packages and keep the current for now. The problem is that this is the kind of dull administration stuff that isn't coding in Haskell, so tends to get neglected. If I know there is a user demand for a changelog I'm happy to provide one, but I don't want to waste time on something that isn't useful. For people who have a near zero-upgrade cost (anyone who is using Cabal) I'd suggest they upgrade to all of my packages immediately. For this change, I'd say it probably isn't worth rolling a new debian binary unless it's particularly easy. I will start a changelog in hlint - and for some of my projects (tagsoup) I do include a changelog in the user manual. thanks, a changelog in the manual is at least a start. But the point I’d like to make is that even if everyone provides a changelog somewhere, if you need to keep track of four dozen packages[1], finding out where that is on a per-package base is quite some hassle. And even ordinary users are curious about the improvements that were made between two releases! If the changelog had a properly specified format and location, cabal upgrade could, if the user wants it, tell him all the downloaded changes. This really helps him to keep up-to-date. It is also a good channel for the authors to talk to his users („see this nice module I added to the package“, „some parts of the API are deprecated now, please move to this part“). Last but not least having documented changes is QA measure that the Haskell platform in the wider sense deserves. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A mistake in haskellwiki
On Thu, Aug 6, 2009 at 3:01 PM, Sean Leatherleat...@cs.uu.nl wrote: On Thu, Aug 6, 2009 at 15:52, Gwern Branwen wrote: On Thu, Aug 6, 2009 at 9:36 AM, Jake McArthur wrote: Which requires registration and has not been open for registration for some time now. It's been open for registration for some time now. In that case, how about changing the site notice[1] from Note: new account creation has been disabled as an anti-spam measure, which seems to indicate otherwise, to something more informative. Alternatively, add an informative link to the login page[2] and clear the site notice. If you click the link (new account creation) you will be lead to the information about how to get an account. Perhaps not the best way to lead people to that info, but it's all there. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell2Xml
On Wed, Aug 5, 2009 at 5:10 PM, Keith Sheppard keiths...@gmail.com wrote: Hello Dmitry, I too was looking for something like this and came up empty. I proposed something similar on the haskell_proposals reddit... http://www.reddit.com/r/haskell_proposals/comments/8zhkx/haxb_and_haxws/ ... but I was left with the impression that there isn't much interest. Several years ago, (probably 2005) I wanted this as well. I ended up hand crafting a DTD from the xsd and then using haxml. Since xsd is xml maybe it's easiest to use xslt (or use haxml) and write it yourself? I'm sure it would catch on once it exists. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
Hi http://community.haskell.org/~ndm/darcs/hlint/CHANGES.txt That will now be updated for future HLint releases. Thanks, Neil On Thu, Aug 6, 2009 at 3:49 PM, Joachim Breitnerm...@joachim-breitner.de wrote: Hi, Am Donnerstag, den 06.08.2009, 15:39 +0100 schrieb Neil Mitchell: So please, package authors, put Changes files in your packages and keep the current for now. The problem is that this is the kind of dull administration stuff that isn't coding in Haskell, so tends to get neglected. If I know there is a user demand for a changelog I'm happy to provide one, but I don't want to waste time on something that isn't useful. For people who have a near zero-upgrade cost (anyone who is using Cabal) I'd suggest they upgrade to all of my packages immediately. For this change, I'd say it probably isn't worth rolling a new debian binary unless it's particularly easy. I will start a changelog in hlint - and for some of my projects (tagsoup) I do include a changelog in the user manual. thanks, a changelog in the manual is at least a start. But the point I’d like to make is that even if everyone provides a changelog somewhere, if you need to keep track of four dozen packages[1], finding out where that is on a per-package base is quite some hassle. And even ordinary users are curious about the improvements that were made between two releases! If the changelog had a properly specified format and location, cabal upgrade could, if the user wants it, tell him all the downloaded changes. This really helps him to keep up-to-date. It is also a good channel for the authors to talk to his users („see this nice module I added to the package“, „some parts of the API are deprecated now, please move to this part“). Last but not least having documented changes is QA measure that the Haskell platform in the wider sense deserves. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org ___ 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] Parsec: using two different parser for the same string
Hi Dan,
thank you for the solution. It looks pretty interesting and usable, however
I'll have to spend some time understanding arrows: I never had an
opportunity to use them before. Anyway, it looks very close to what I
actually need, and in any case much less ugly than breaking the GenParser
encapsulation
2009/8/6 Dan Weston weston...@imageworks.com
Of course, since ParsecT s u m is a functor, feel free to use fmap instead
of parsecMap. Then you don't need to import from Text.Parsec.Prim.
And in hindsight, I might prefer the name (:) or cons to () for the
first function, but now I'm just obsessing. :)
Dan
Dan Weston wrote:
I think parsecMap does the job here:
---
import Text.ParserCombinators.Parsec hiding ((|))
import Text.Parsec.Prim(parsecMap)
import Control.Applicative((|))
import Control.Arrow((|||),())
-- Tagged (:)
() :: Either Char Char - Either String String - Either String String
Left a Left b = Left (a:b)
Left a Right b = Left (a:b)
Right a Left b = Left (a:b)
Right a Right b = Right (a:b)
-- Tagged concat
stringParser :: [Either Char Char] - Either String String
stringParser = foldr () (Right )
-- Parse Integer if properly tagged, keeping unparsed string
maybeToInteger :: Either String String - (Maybe Integer, String)
maybeToInteger = (const Nothing ||| Just . read) (id ||| id)
-- Tagged-choice parser
intOrStringParser = parsecMap (maybeToInteger . stringParser)
$ many1 (parsecMap Right digit | parsecMap Left (noneOf ;)))
-- Parse between parentheses
intOrStringListParser = between (char '(')
(char ')')
(sepBy1 intOrStringParser (char ';'))
---
Then you get a tagged version of each string, along with the string
itself:
*P parseTest intOrStringListParser $ (1;2w4;8;85)
[(Just 1,1),(Nothing,2w4),(Just 8,8),(Just 85,85)]
There may be some parsecMap-fold fusion optimization possible, though I
haven't looked into that.
Dan
Paul Sujkov wrote:
Hi everybody,
suppose I have two different parsers: one just reads the string, and
another one parses some values from it. E.g.:
parseIntList :: Parser [Integer]
parseIntList = do
char '('
res - liftM (map read) (sepBy1 (many1 digit) (char ';'))
char ')'
return res
parseIntString :: Parser String
parseIntString = manyTill anyChar eof
so for some input like this - (1;2;3;4) - I will have two different
result:
*Parlog parseTest parseIntList (1;2;3;4)
[1,2,3,4]
*Parlog parseTest parseIntString (1;2;3;4)
(1;2;3;4)
but the thing that I actually want is something like Parser ([Integer],
String) - results from both parsers at a time, no matter whether one of them
fails or not:
*Parlog parseTest parseIntListAndString (1;2;3;4)
([1,2,3,4], (1;2;3;4))
it is impossible at first sight, because first parser to use will consume
all the input, and there will be nothing to parse for the second one
Parsec contains choice function, but it is implemented via | and that
is mplus - so it tries second alternative only if the first one fails. Is it
possible to use two parsers for the same string (with try-like backtracking,
no input actually consumed till the second parser finishes)? I can assume
only dirty hacks with the GenParser internals - manual position storing and
backtracking - but that is obviously not good
however, my first attempt to solve the problem was kind a like that: to
parse string to String, and then to use it as an input for the next level
parse call:
parseIntListAndString :: Parser ([Integer], String)
parseIntListAndString = do
str - parseIntString
return (res str, str)
where res str = case (parse parseIntList str) of
Left err - []
Right val - val
but the problems with such a method began when I switched from Parser to
GenParser with user state: function parseIntList have to update the state,
but it can't have the same state as the parseIntListAndString any more: it
has it's own. I can explicitly pass the state from parseIntListAndString to
parseIntList, but I see no suitable way for the parseIntList to update it. I
can return the updated state value from the parseIntList function, and call
setState on a result - but it seems rather ugly to mee. However, if nothing
else will do, that is an alternative
it is of course possible to use two different parsers sequentially, but
it is also very ineffective: I need to use such multiple parsing on a
relatively small substring of the actual input, so little backtracking would
be a much nicier approach. Any suggestions?
--
Regards, Paul Sujkov
--
Regards, Paul Sujkov
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
Hi, Am Donnerstag, den 06.08.2009, 20:07 +0300 schrieb Max Desyatov: Did you see these tickets http://hackage.haskell.org/trac/hackage/ticket/299 http://hackage.haskell.org/trac/hackage/ticket/244 ? Probably the real proposal could be fixed in comments for that tickets, so anyone who wants to implement that feature would see all possible solutions in one place, without browsing through haskell-cafe archives. no, given that I wrote a rant, I did not do research :-). These tickets describe what I want, and I’ll be watching them, and hope for progress :-) Thanks, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Changelogs
Did you see these tickets http://hackage.haskell.org/trac/hackage/ticket/299 http://hackage.haskell.org/trac/hackage/ticket/244 ? Probably the real proposal could be fixed in comments for that tickets, so anyone who wants to implement that feature would see all possible solutions in one place, without browsing through haskell-cafe archives. Joachim Breitner m...@joachim-breitner.de writes: If the changelog had a properly specified format and location, cabal upgrade could, if the user wants it, tell him all the downloaded changes. This really helps him to keep up-to-date. It is also a good channel for the authors to talk to his users („see this nice module I added to the package“, „some parts of the API are deprecated now, please move to this part“). Last but not least having documented changes is QA measure that the Haskell platform in the wider sense deserves. Greetings, Joachim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking to check on some capabilities of Data.Colour
I was wondering if Data.Colour supported Double-valued colour components 1.0 or less than 0. I'm looking to create an HDR image processing library, and Haskell has one of the most extensive and correct colour models around, thanks to Russell. With 16bpcc or 32bpcc images, however, I need to be sure to be able to correctly calculate colour values that fall outside the usual [0.0,1.0] gamut. Does Data.Colour support this functionality? -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking to check on some capabilities of Data.Colour
On Thu, 6 Aug 2009, Jeff Heard wrote: I was wondering if Data.Colour supported Double-valued colour components 1.0 or less than 0. I'm looking to create an HDR image processing library, and Haskell has one of the most extensive and correct colour models around, thanks to Russell. With 16bpcc or 32bpcc images, however, I need to be sure to be able to correctly calculate colour values that fall outside the usual [0.0,1.0] gamut. Does Data.Colour support this functionality? Data.Colour supports values outside the range [0,1] for most computations. Components are clamped when extracting to Bounded component types such as Word8 (see toSRGBBounded). There may also some issues with negaive values when converting to non-linear coordinate systems via a transfer function. This is an area I haven't thought to much about, so there could be a few bugs lurking here. If found they should be fixed, assuming right behaviour can be found. -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking to check on some capabilities of Data.Colour
On Thu, 6 Aug 2009, rocon...@theorem.ca wrote: On Thu, 6 Aug 2009, Jeff Heard wrote: I was wondering if Data.Colour supported Double-valued colour components 1.0 or less than 0. I'm looking to create an HDR image processing library, and Haskell has one of the most extensive and correct colour models around, thanks to Russell. With 16bpcc or 32bpcc images, however, I need to be sure to be able to correctly calculate colour values that fall outside the usual [0.0,1.0] gamut. Does Data.Colour support this functionality? Data.Colour supports values outside the range [0,1] for most computations. To be slightly more techinical, I want add that Data.Colour.Colour is abstract and its interface cares nothing about [0,1]. Gammut issue only arise when converting the abstract data type to and from concrete coordinates, and which colours are outside [0,1]*[0,1]*[0,1] is coorinate system dependent. Since Data.Colour.Colour is abstract and coordinate system indepenent, it cannot (or at least should not) care about such issues for oprations that deal only with abstract colours (operations such as blending, etc.) Components are clamped when extracting to Bounded component types such as Word8 (see toSRGBBounded). There may also some issues with negaive values when converting to non-linear coordinate systems via a transfer function. This is an area I haven't thought to much about, so there could be a few bugs lurking here. If found they should be fixed, assuming right behaviour can be found. -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking to check on some capabilities of Data.Colour
Excellent. That's what I wanted to know :-) On Thu, Aug 6, 2009 at 4:01 PM, rocon...@theorem.ca wrote: On Thu, 6 Aug 2009, rocon...@theorem.ca wrote: On Thu, 6 Aug 2009, Jeff Heard wrote: I was wondering if Data.Colour supported Double-valued colour components 1.0 or less than 0. I'm looking to create an HDR image processing library, and Haskell has one of the most extensive and correct colour models around, thanks to Russell. With 16bpcc or 32bpcc images, however, I need to be sure to be able to correctly calculate colour values that fall outside the usual [0.0,1.0] gamut. Does Data.Colour support this functionality? Data.Colour supports values outside the range [0,1] for most computations. To be slightly more techinical, I want add that Data.Colour.Colour is abstract and its interface cares nothing about [0,1]. Gammut issue only arise when converting the abstract data type to and from concrete coordinates, and which colours are outside [0,1]*[0,1]*[0,1] is coorinate system dependent. Since Data.Colour.Colour is abstract and coordinate system indepenent, it cannot (or at least should not) care about such issues for oprations that deal only with abstract colours (operations such as blending, etc.) Components are clamped when extracting to Bounded component types such as Word8 (see toSRGBBounded). There may also some issues with negaive values when converting to non-linear coordinate systems via a transfer function. This is an area I haven't thought to much about, so there could be a few bugs lurking here. If found they should be fixed, assuming right behaviour can be found. -- Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec: using two different parser for the same string
Paul,
Arrows (and category theory in general) are interesting, but you
certainly don't need to understand them for this.
The only arrow in this code is the lowly function arrow (-). () and
(|||) are duals of each other and mean, respectively, both and
either (though for some bizarre reason, both is usually called
fanout!)
This style of pointfree (or pointless) code is clearer to me because I
don't have a bunch of variable names to invent and have lying around.
Anyway, if you prefer, don't import Control.Arrow at all, and just use:
-- |Both: Apply two functions to same argument and tuple the results
infixr 3
() :: (a - b) - (a - c) - a - (b,c)
(f g) x = (f x, g x)
-- |Either: If argument is Left, apply Left function, else apply Right
function
infixr 2 |||
(|||) :: (a - c) - (b - c) - Either a b - c
(|||) = either
either is implicitly imported from the Prelude and is defined as:
-- | Case analysis for the 'Either' type.
-- If the value is @'Left' a@, apply the first function to @a@;
-- if it is @'Right' b@, apply the second function to @b...@.
either :: (a - c) - (b - c) - Either a b - c
either f _ (Left x) = f x
either _ g (Right y)= g y
Dan
Paul Sujkov wrote:
Hi Dan,
thank you for the solution. It looks pretty interesting and usable,
however I'll have to spend some time understanding arrows: I never had
an opportunity to use them before. Anyway, it looks very close to what I
actually need, and in any case much less ugly than breaking the
GenParser encapsulation
2009/8/6 Dan Weston weston...@imageworks.com
mailto:weston...@imageworks.com
Of course, since ParsecT s u m is a functor, feel free to use fmap
instead of parsecMap. Then you don't need to import from
Text.Parsec.Prim.
And in hindsight, I might prefer the name (:) or cons to () for
the first function, but now I'm just obsessing. :)
Dan
Dan Weston wrote:
I think parsecMap does the job here:
---
import Text.ParserCombinators.Parsec hiding ((|))
import Text.Parsec.Prim(parsecMap)
import Control.Applicative((|))
import Control.Arrow((|||),())
-- Tagged (:)
() :: Either Char Char - Either String String - Either
String String
Left a Left b = Left (a:b)
Left a Right b = Left (a:b)
Right a Left b = Left (a:b)
Right a Right b = Right (a:b)
-- Tagged concat
stringParser :: [Either Char Char] - Either String String
stringParser = foldr () (Right )
-- Parse Integer if properly tagged, keeping unparsed string
maybeToInteger :: Either String String - (Maybe Integer, String)
maybeToInteger = (const Nothing ||| Just . read) (id ||| id)
-- Tagged-choice parser
intOrStringParser = parsecMap (maybeToInteger . stringParser)
$ many1 (parsecMap Right digit | parsecMap Left (noneOf ;)))
-- Parse between parentheses
intOrStringListParser = between (char '(')
(char ')')
(sepBy1 intOrStringParser (char
';'))
---
Then you get a tagged version of each string, along with the
string itself:
*P parseTest intOrStringListParser $ (1;2w4;8;85)
[(Just 1,1),(Nothing,2w4),(Just 8,8),(Just 85,85)]
There may be some parsecMap-fold fusion optimization possible,
though I haven't looked into that.
Dan
Paul Sujkov wrote:
Hi everybody,
suppose I have two different parsers: one just reads the
string, and another one parses some values from it. E.g.:
parseIntList :: Parser [Integer]
parseIntList = do
char '('
res - liftM (map read) (sepBy1 (many1 digit) (char ';'))
char ')'
return res
parseIntString :: Parser String
parseIntString = manyTill anyChar eof
so for some input like this - (1;2;3;4) - I will have two
different result:
*Parlog parseTest parseIntList (1;2;3;4)
[1,2,3,4]
*Parlog parseTest parseIntString (1;2;3;4)
(1;2;3;4)
but the thing that I actually want is something like Parser
([Integer], String) - results from both parsers at a time,
no matter whether one of them fails or not:
*Parlog parseTest parseIntListAndString (1;2;3;4)
([1,2,3,4], (1;2;3;4))
it is impossible at first sight, because first parser to use
will consume all the input, and there will be nothing to
parse for the second one
Parsec contains choice function, but it is implemented via
| and that is mplus - so it tries second alternative only
if the first one fails. Is it
[Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. Did you try playing with optimization options? I think someone just mentioned that compiling large amounts of static data in GHC is problematic and recommended something like -O0 to prevent GHC from analyzing it. Of course, I wouldn't recommend having unoptimized code, but I'm curious how that changes the results here. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. Oh that's icky. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) I just googled this and found this: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-March/014498.html That was linked from this discussion: http://www.nabble.com/ghc-6.8.2-and-timer_create-error-td16160635.html The second link seems to indicate that it's not a problem of antiquity but instead one related to what configure finds when building GHC for that system. In other words, it should be possible to make a version of GHC locally that doesn't use timer_create and then your student should be good to go. Hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Maybe it is attempting to unroll these loops, even with -O0? Dan Henning Thielemann wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-) ___ 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] Hugs faster and more reliable than GHC for large list monad 'do' block
Hi I think the issue you're running in to with 6.4 is this one: http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a while back. Thanks Neil On Thu, Aug 6, 2009 at 9:59 PM, Dan Westonweston...@imageworks.com wrote: I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Maybe it is attempting to unroll these loops, even with -O0? Dan Henning Thielemann wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-) ___ 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] Hugs faster and more reliable than GHC for large list monad 'do' block
On Thu, 6 Aug 2009, Dan Weston wrote: I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. Maybe that it was a list. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Indeed, this is also what we got from the executable built by GHC-6.8.2. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
On Thu, 6 Aug 2009, Jason Dagit wrote: 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) I just googled this and found this: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-March/014498.html That was linked from this discussion: http://www.nabble.com/ghc-6.8.2-and-timer_create-error-td16160635.html The second link seems to indicate that it's not a problem of antiquity but instead one related to what configure finds when building GHC for that system. In other words, it should be possible to make a version of GHC locally that doesn't use timer_create and then your student should be good to go. Thanks for the pointer. But it means building GHC myself, which I have no experience with. :-(___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Seeking for an extention (functional incapsulation)
Hello, cafe visitors! :)
This is a double topic:
1. Can't find any good informative resource with descriptions of Haskell
extensions. Could anybody please share good one if it exists?
The only good one I found:
http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions
But it's a bit too old and not that full...
I undestand, that Haskell is kind of boiling language, in a sense of being
neverending experiment. It develops all the time, extensions show up and
drop out. So it's not that easy to support community with a fresh
information about them. But on the other side, the property (of being
boiling language) makes such information really important for community
members... I think. :)
2. Consider situation:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = f (sdtField1 sdt) (sdtField2 sdt)
---
I induced recently, that it would be very comfortable if I could perform in
a way like this:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type, sdtField3 :: SDT_Field2Type, sdtField3 = f sdtField1
sdtField2}
---
The situation is not that rare, when dealing with nonprimitive data
constructions. Moreover would be really comfortable to reduce
---
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type} | SomeDataType_222 { sdtField1 ::
SDT_Field1Type, sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = case sdt of {SomeDataType_111 - f (sdtField1 sdt)
(sdtField2 sdt) ; SomeDataType_222 - g (sdtField1 sdt) (sdtField2 sdt)
(sdtField5 sdt)}
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField3 :: SDT_Field3Type, sdtField3 = f
sdtField1 sdtField2} | SomeDataType_222 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type, sdtField3 ::
SDT_Field3Type, sdtField3 = g sdtField1 sdtField2 sdtField5}
---
Usable mechanics for realization would be:
1. Funtion similar to Data.Function.on (example: (*) `on` f = \x y - f x *
f y), but opposite - I called it under.
t `under` f = \x y - (x f) `t` (y f)
2. currying and uncurrying
Is there any such extension?
Belka
--
View this message in context:
http://www.nabble.com/Seeking-for-an-extention-%28functional-incapsulation%29-tp24856249p24856249.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
No, I am using the latest released ghc: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 [ z.hs is attached ] time ghc -O0 --make z.hs [1 of 1] Compiling Main ( z.hs, z.o ) Linking z ... 14.422u 0.630s 0:15.10 99.6%0+0k 0+0io 0pf+0w time ./z z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort 0.007u 0.007s 0:00.02 0.0% 0+0k 0+0io 0pf+0w Dan Neil Mitchell wrote: Hi I think the issue you're running in to with 6.4 is this one: http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a while back. Thanks Neil On Thu, Aug 6, 2009 at 9:59 PM, Dan Westonweston...@imageworks.com wrote: I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Maybe it is attempting to unroll these loops, even with -O0? Dan Henning Thielemann wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-) ___ 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 import Control.Monad(guard) main = print z z :: [[Int]] z= do x1 - [0..3] x2 - [0..3] x3 - [0..3] x4 - [0..3] x5 - [0..3] x6 - [0..3] x7 - [0..3] x8 - [0..3] x9 - [0..3] x10 - [0..3] x11 - [0..3] x12 - [0..3] x13 - [0..3] x14 - [0..3] x15 - [0..3] x16 - [0..3] x17 - [0..3] x18 - [0..3] x19 - [0..3] x20 - [0..3] x21 - [0..3] x22 - [0..3] x23 - [0..3] x24 - [0..3] x25 - [0..3] x26 - [0..3] x27 - [0..3] x28 - [0..3] x29 - [0..3] x30 - [0..3] x31 - [0..3] x32 - [0..3] x33 - [0..3] x34 - [0..3] x35 - [0..3] x36 - [0..3] x37 - [0..3] x38 - [0..3] x39 - [0..3] x40 - [0..3] x41 - [0..3] x42 - [0..3] x43 - [0..3] x44 - [0..3] x45 - [0..3] x46 - [0..3] x47 - [0..3] x48 - [0..3] x49 - [0..3] x50 - [0..3] x51 - [0..3] x52 - [0..3] x53 - [0..3] x54 - [0..3] x55 - [0..3] x56 - [0..3] x57 - [0..3] x58 - [0..3] x59 - [0..3] x60 - [0..3] x61 - [0..3] x62 - [0..3] x63 - [0..3] x64 - [0..3] x65 - [0..3] x66 - [0..3] x67 - [0..3] x68 - [0..3] x69 - [0..3] x70 - [0..3] x71 - [0..3] x72 - [0..3] x73 - [0..3] x74 - [0..3] x75 - [0..3] x76 - [0..3] x77 - [0..3]
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
Yes, the GHC compiler will work on older kernels and CentOS kernels if you bootstrap it with 6.4 On Thu, Aug 6, 2009 at 4:51 PM, Jason Dagitda...@codersbase.com wrote: On Thu, Aug 6, 2009 at 1:39 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. Did you try playing with optimization options? I think someone just mentioned that compiling large amounts of static data in GHC is problematic and recommended something like -O0 to prevent GHC from analyzing it. Of course, I wouldn't recommend having unoptimized code, but I'm curious how that changes the results here. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. Oh that's icky. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) I just googled this and found this: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-March/014498.html That was linked from this discussion: http://www.nabble.com/ghc-6.8.2-and-timer_create-error-td16160635.html The second link seems to indicate that it's not a problem of antiquity but instead one related to what configure finds when building GHC for that system. In other words, it should be possible to make a version of GHC locally that doesn't use timer_create and then your student should be good to go. Hope that helps, Jason ___ 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] Hugs faster and more reliable than GHC for large list monad 'do' block
I should clarify that this was done on an older kernel (bootstrapped from ghc 6.4 as Jeff Heard suggested), in case that makes any difference: Main memory size: 7971 Mbytes 1 GenuineIntel Intel(R) Xeon(TM) CPU 3.40GHz processor Swap Size: 2047 Mbytes Num Processors: 1 Processor Type: Intel(R) Xeon(TM) CPU 3.40GHz x64 Clock Speed: 3400 MHZ OS: Linux 2.6.9-42.0.3.EL.spi OS-VERSION: CentOS release 4.4 (Final) OS-HW: x86_64 Dan Weston wrote: No, I am using the latest released ghc: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 [ z.hs is attached ] time ghc -O0 --make z.hs [1 of 1] Compiling Main ( z.hs, z.o ) Linking z ... 14.422u 0.630s 0:15.10 99.6%0+0k 0+0io 0pf+0w time ./z z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort 0.007u 0.007s 0:00.02 0.0% 0+0k 0+0io 0pf+0w Dan Neil Mitchell wrote: Hi I think the issue you're running in to with 6.4 is this one: http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a while back. Thanks Neil On Thu, Aug 6, 2009 at 9:59 PM, Dan Westonweston...@imageworks.com wrote: I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Maybe it is attempting to unroll these loops, even with -O0? Dan Henning Thielemann wrote: Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 - [0..3] x2 - [0..2] ... x600 - [0..5] guard (x1+x2+2*x3 = 0) ... return (x1,x2,,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-) ___ 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] Seeking for an extention (functional incapsulation)
Is there any good extension? Yes, it's in Control.Applicative.
Belka wrote:
Hello, cafe visitors! :)
This is a double topic:
1. Can't find any good informative resource with descriptions of Haskell
extensions. Could anybody please share good one if it exists?
The only good one I found:
http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions
But it's a bit too old and not that full...
I undestand, that Haskell is kind of boiling language, in a sense of being
neverending experiment. It develops all the time, extensions show up and
drop out. So it's not that easy to support community with a fresh
information about them. But on the other side, the property (of being
boiling language) makes such information really important for community
members... I think. :)
2. Consider situation:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = f (sdtField1 sdt) (sdtField2 sdt)
---
I induced recently, that it would be very comfortable if I could perform in
a way like this:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type, sdtField3 :: SDT_Field2Type, sdtField3 = f sdtField1
sdtField2}
---
The situation is not that rare, when dealing with nonprimitive data
constructions. Moreover would be really comfortable to reduce
---
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type} | SomeDataType_222 { sdtField1 ::
SDT_Field1Type, sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = case sdt of {SomeDataType_111 - f (sdtField1 sdt)
(sdtField2 sdt) ; SomeDataType_222 - g (sdtField1 sdt) (sdtField2 sdt)
(sdtField5 sdt)}
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField3 :: SDT_Field3Type, sdtField3 = f
sdtField1 sdtField2} | SomeDataType_222 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type, sdtField3 ::
SDT_Field3Type, sdtField3 = g sdtField1 sdtField2 sdtField5}
---
Usable mechanics for realization would be:
1. Funtion similar to Data.Function.on (example: (*) `on` f = \x y - f x *
f y), but opposite - I called it under.
t `under` f = \x y - (x f) `t` (y f)
2. currying and uncurrying
Is there any such extension?
Belka
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking for an extention (functional incapsulation)
More specifically:
sdtField3 sdt = f $ sdtField1 * sdtField2
You don't really need this inline in the record syntax, do you?
Dan Weston wrote:
Is there any good extension? Yes, it's in Control.Applicative.
Belka wrote:
Hello, cafe visitors! :)
This is a double topic:
1. Can't find any good informative resource with descriptions of Haskell
extensions. Could anybody please share good one if it exists?
The only good one I found:
http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions
But it's a bit too old and not that full...
I undestand, that Haskell is kind of boiling language, in a sense of being
neverending experiment. It develops all the time, extensions show up and
drop out. So it's not that easy to support community with a fresh
information about them. But on the other side, the property (of being
boiling language) makes such information really important for community
members... I think. :)
2. Consider situation:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = f (sdtField1 sdt) (sdtField2 sdt)
---
I induced recently, that it would be very comfortable if I could perform in
a way like this:
---
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type, sdtField3 :: SDT_Field2Type, sdtField3 = f sdtField1
sdtField2}
---
The situation is not that rare, when dealing with nonprimitive data
constructions. Moreover would be really comfortable to reduce
---
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type} | SomeDataType_222 { sdtField1 ::
SDT_Field1Type, sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type}
sdtField3 :: SomeDataType - SDT_Field3Type
sdtField3 sdt = case sdt of {SomeDataType_111 - f (sdtField1 sdt)
(sdtField2 sdt) ; SomeDataType_222 - g (sdtField1 sdt) (sdtField2 sdt)
(sdtField5 sdt)}
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/
data SomeDataType = SomeDataType_111 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField3 :: SDT_Field3Type, sdtField3 = f
sdtField1 sdtField2} | SomeDataType_222 { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type, sdtField5 :: SDT_Field5Type, sdtField3 ::
SDT_Field3Type, sdtField3 = g sdtField1 sdtField2 sdtField5}
---
Usable mechanics for realization would be:
1. Funtion similar to Data.Function.on (example: (*) `on` f = \x y - f x *
f y), but opposite - I called it under.
t `under` f = \x y - (x f) `t` (y f)
2. currying and uncurrying
Is there any such extension?
Belka
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking for an extention (functional incapsulation)
Thank you, for your reply, Dan! :) You don't really need this inline in the record syntax, do you? In fact, that was the point. To enclose direct functional dependants into the record declaration. To achieve better pithiness - it's valuable, and the value grows exponentially with LOC (lines of code) count. :) sdtField3 sdt = f $ sdtField1 * sdtField2 Doesn't look much better than my under function (t `under` f = \x y - (x f) `t` (y f)). What did I miss? I believe, there are good reasons to use Control.Applicative for lots purposes, but unfortunately, yet haven't had time to try it in my practice. Belka -- View this message in context: http://www.nabble.com/Seeking-for-an-extention-%28functional-incapsulation%29-tp24856249p24856983.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking for an extention (functional incapsulation)
the value grows exponentially with LOC (lines of code) count. :)
Exponentially? Now I'm missing something...
Your way has 156 chars:
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type, sdtField2 ::
SDT_Field2Type, sdtField3 :: SDT_Field2Type, sdtField3 = f sdtField1
sdtField2}
This way has 162 chars:
data SomeDataType = SomeDataType { sdtField1 :: SDT_Field1Type,
sdtField2 :: SDT_Field2Type}
sdtField3 :: SDT_Field2Type
sdtField3 = f $ sdtField1 * sdtField2
This adds 6 characters per dependent deconstructor function. As a
fraction of total LOC, this is insignificant.
Belka wrote:
Thank you, for your reply, Dan! :)
You don't really need this inline in the record syntax, do you?
In fact, that was the point. To enclose direct functional dependants into
the record declaration. To achieve better pithiness - it's valuable, and the
value grows exponentially with LOC (lines of code) count. :)
sdtField3 sdt = f $ sdtField1 * sdtField2
Doesn't look much better than my under function (t `under` f = \x y - (x
f) `t` (y f)). What did I miss?
I believe, there are good reasons to use Control.Applicative for lots
purposes, but unfortunately, yet haven't had time to try it in my practice.
Belka
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linking failing due to Control.Monad.State.Strict?
Hi,
I'm getting a linker error when generating makefile dependencies on
the below library for a program I'm using. It links fine under 'ghc --
make'. I'm using (more or less) the makefile from the haskell docs.
I am using the Strict State Monad in the object files it is
complaining about, the compile is fine, just the linker which is
blowing up. Any ideas what is causing this?
I'm using GHC 6.10.4 on PPC Mac OS X 10.5.
I've included the makefile below the error.
Cheers!
Phil.
ghc -o OptionCalculator -O2 -Wall ./FrameworkInterface.o ./Maths/
Prime.o ./Misc/Debug.o ./MonteCarlo/DataStructures.o ./MonteCarlo/
European.o ./MonteCarlo/Framework.o ./MonteCarlo/Interface.o ./
MonteCarlo/Lookback.o ./Normal/Acklam.o ./Normal/BoxMuller.o ./Normal/
Framework.o ./Normal/Interface.o ./OptionCalculator.o ./Random/
Framework.o ./Random/Halton.o ./Random/Interface.o ./Random/Ranq1.o
Undefined symbols:
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_info,
referenced from:
_r1hl_info in Acklam.o
_rGL_info in BoxMuller.o
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_closure,
referenced from:
_r1hl_srt in Acklam.o
_rGL_srt in BoxMuller.o
___stginit_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_,
referenced from:
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziFramework_ in Framework.o
___stginit_NormalziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziRanq1_ in Ranq1.o
___stginit_RandomziRanq1_ in Ranq1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [OptionCalculator] Error 1
Makefile:
HC = ghc
HC_OPTS = -O2 -Wall $(EXTRA_HC_OPTS)
SRCS := $(shell find . -name *.hs -print)
OBJS = $(SRCS:.hs=.o)
PROG = OptionCalculator
.SUFFIXES : .o .hs .hi .lhs .hc .s
${PROG} : $(OBJS)
rm -f $@
$(HC) -o $@ $(HC_OPTS) $(OBJS)
# Standard suffix rules
.o.hi:
@:
.lhs.o:
$(HC) -c $ $(HC_OPTS)
.hs.o:
$(HC) -c $ $(HC_OPTS)
.o-boot.hi-boot:
@:
.lhs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
.hs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
clean :
find . -name *.hi -exec rm -f {} \;
find . -name *.o -exec rm -f {} \;
rm -f ${PROG}
depend :
ghc -M $(HC_OPTS) $(SRCS)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking failing due to Control.Monad.State.Strict?
Try with ghc --make ?
On Thu, Aug 6, 2009 at 9:38 PM, p...@beadling.co.uk wrote:
Hi,
I'm getting a linker error when generating makefile dependencies on the
below library for a program I'm using. It links fine under 'ghc --make'.
I'm using (more or less) the makefile from the haskell docs. I am using
the Strict State Monad in the object files it is complaining about, the
compile is fine, just the linker which is blowing up. Any ideas what is
causing this?
I'm using GHC 6.10.4 on PPC Mac OS X 10.5.
I've included the makefile below the error.
Cheers!
Phil.
ghc -o OptionCalculator -O2 -Wall ./FrameworkInterface.o ./Maths/Prime.o
./Misc/Debug.o ./MonteCarlo/DataStructures.o ./MonteCarlo/European.o
./MonteCarlo/Framework.o ./MonteCarlo/Interface.o ./MonteCarlo/Lookback.o
./Normal/Acklam.o ./Normal/BoxMuller.o ./Normal/Framework.o
./Normal/Interface.o ./OptionCalculator.o ./Random/Framework.o
./Random/Halton.o ./Random/Interface.o ./Random/Ranq1.o
Undefined symbols:
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_info, referenced from:
_r1hl_info in Acklam.o
_rGL_info in BoxMuller.o
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_closure, referenced
from:
_r1hl_srt in Acklam.o
_rGL_srt in BoxMuller.o
___stginit_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_, referenced
from:
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziFramework_ in Framework.o
___stginit_NormalziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziRanq1_ in Ranq1.o
___stginit_RandomziRanq1_ in Ranq1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [OptionCalculator] Error 1
Makefile:
HC = ghc
HC_OPTS = -O2 -Wall $(EXTRA_HC_OPTS)
SRCS := $(shell find . -name *.hs -print)
OBJS = $(SRCS:.hs=.o)
PROG = OptionCalculator
.SUFFIXES : .o .hs .hi .lhs .hc .s
${PROG} : $(OBJS)
rm -f $@
$(HC) -o $@ $(HC_OPTS) $(OBJS)
# Standard suffix rules
.o.hi:
@:
.lhs.o:
$(HC) -c $ $(HC_OPTS)
.hs.o:
$(HC) -c $ $(HC_OPTS)
.o-boot.hi-boot:
@:
.lhs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
.hs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
clean :
find . -name *.hi -exec rm -f {} \;
find . -name *.o -exec rm -f {} \;
rm -f ${PROG}
depend :
ghc -M $(HC_OPTS) $(SRCS)
___
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] Linking failing due to Control.Monad.State.Strict?
Sorry, I missed that you'd tried that. Why would you not want to use
--make? The issue is that when you import a module in your standard
library, you need to link to it, and ghc --make takes care of figuring
out what to link to for you. Otherwise, you'll need to go digging in
your library for the .o files to link to by hand. There's nothing
stopping you from using ghc --make along with a makefile, if you have
various other complex things to do in your build.
Also, people in the Haskell community tend to not use makefiles much,
instead opting for the much more Haskellish cabal build and
packaging system. If you haven't tried it, I recommend it :)
Hope this helps (more than my previous email at least!),
Dan
On Thu, Aug 6, 2009 at 9:43 PM, Daniel Peeblespumpkin...@gmail.com wrote:
Try with ghc --make ?
On Thu, Aug 6, 2009 at 9:38 PM, p...@beadling.co.uk wrote:
Hi,
I'm getting a linker error when generating makefile dependencies on the
below library for a program I'm using. It links fine under 'ghc --make'.
I'm using (more or less) the makefile from the haskell docs. I am using
the Strict State Monad in the object files it is complaining about, the
compile is fine, just the linker which is blowing up. Any ideas what is
causing this?
I'm using GHC 6.10.4 on PPC Mac OS X 10.5.
I've included the makefile below the error.
Cheers!
Phil.
ghc -o OptionCalculator -O2 -Wall ./FrameworkInterface.o ./Maths/Prime.o
./Misc/Debug.o ./MonteCarlo/DataStructures.o ./MonteCarlo/European.o
./MonteCarlo/Framework.o ./MonteCarlo/Interface.o ./MonteCarlo/Lookback.o
./Normal/Acklam.o ./Normal/BoxMuller.o ./Normal/Framework.o
./Normal/Interface.o ./OptionCalculator.o ./Random/Framework.o
./Random/Halton.o ./Random/Interface.o ./Random/Ranq1.o
Undefined symbols:
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_info, referenced from:
_r1hl_info in Acklam.o
_rGL_info in BoxMuller.o
_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_a29_closure, referenced
from:
_r1hl_srt in Acklam.o
_rGL_srt in BoxMuller.o
___stginit_mtlzm1zi1zi0zi2_ControlziMonadziStateziStrict_, referenced
from:
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_FrameworkInterface_ in FrameworkInterface.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziEuropean_ in European.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziFramework_ in Framework.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_MonteCarloziLookback_ in Lookback.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziAcklam_ in Acklam.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziBoxMuller_ in BoxMuller.o
___stginit_NormalziFramework_ in Framework.o
___stginit_NormalziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziFramework_ in Framework.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziHalton_ in Halton.o
___stginit_RandomziRanq1_ in Ranq1.o
___stginit_RandomziRanq1_ in Ranq1.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [OptionCalculator] Error 1
Makefile:
HC = ghc
HC_OPTS = -O2 -Wall $(EXTRA_HC_OPTS)
SRCS := $(shell find . -name *.hs -print)
OBJS = $(SRCS:.hs=.o)
PROG = OptionCalculator
.SUFFIXES : .o .hs .hi .lhs .hc .s
${PROG} : $(OBJS)
rm -f $@
$(HC) -o $@ $(HC_OPTS) $(OBJS)
# Standard suffix rules
.o.hi:
@:
.lhs.o:
$(HC) -c $ $(HC_OPTS)
.hs.o:
$(HC) -c $ $(HC_OPTS)
.o-boot.hi-boot:
@:
.lhs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
.hs-boot.o-boot:
$(HC) -c $ $(HC_OPTS)
clean :
find . -name *.hi -exec rm -f {} \;
find . -name *.o -exec rm -f {} \;
rm -f ${PROG}
depend :
ghc -M $(HC_OPTS) $(SRCS)
___
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] Hugs faster and more reliable than GHC for large list monad 'do' block
On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 Confirmed on Gento amd64 with custom-built GHC from Haskell overlay: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 $ uname -a Linux kira 2.6.30-tuxonice-r4 #1 SMP Sat Jul 25 15:28:05 BRT 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block
felipe.lessa: On Thu, Aug 06, 2009 at 04:25:07PM -0700, Dan Weston wrote: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 Confirmed on Gento amd64 with custom-built GHC from Haskell overlay: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 $ uname -a Linux kira 2.6.30-tuxonice-r4 #1 SMP Sat Jul 25 15:28:05 BRT 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz GenuineIntel GNU/Linux Someone please file a bug report, http://hackage.haskell.org/trac/ghc/newticket?type=bug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking failing due to Control.Monad.State.Strict?
Thanks for the reply. Otherwise, you'll need to go digging in your library for the .o files to link to by hand. If I look with '-v' tho it seems to include Haskell libs in the underlying link - see below? Plus it only complains about this library, I use many other standard libs too? Looks like something stranger is going on? Also I've tried using --include-pkg-deps (perhaps incorrectly) - it doesn't help. Phil. rm -f OptionCalculator ghc -o OptionCalculator -O2 -Wall -v ./FrameworkInterface.o ./Maths/ Prime.o ./Misc/Debug.o ./MonteCarlo/DataStructures.o ./MonteCarlo/ European.o ./MonteCarlo/Framework.o ./MonteCarlo/Interface.o ./ MonteCarlo/Lookback.o ./Normal/Acklam.o ./Normal/BoxMuller.o ./Normal/ Framework.o ./Normal/Interface.o ./OptionCalculator.o ./Random/ Framework.o ./Random/Halton.o ./Random/Interface.o ./Random/Ranq1.o Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.3 Using package config file: /usr/local/lib/ghc-6.10.4/./package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Linker: gcc -v -o OptionCalculator FrameworkInterface.o Maths/Prime.o Misc/ Debug.o MonteCarlo/DataStructures.o MonteCarlo/European.o MonteCarlo/ Framework.o MonteCarlo/Interface.o MonteCarlo/Lookback.o Normal/ Acklam.o Normal/BoxMuller.o Normal/Framework.o Normal/Interface.o OptionCalculator.o Random/Framework.o Random/Halton.o Random/ Interface.o Random/Ranq1.o -L/usr/local/lib/ghc-6.10.4/ haskell98-1.0.1.0 -L/usr/local/lib/ghc-6.10.4/random-1.0.0.1 -L/usr/ local/lib/ghc-6.10.4/process-1.0.1.1 -L/usr/local/lib/ghc-6.10.4/ directory-1.0.0.3 -L/usr/local/lib/ghc-6.10.4/unix-2.3.2.0 -L/usr/ local/lib/ghc-6.10.4/old-time-1.0.0.2 -L/usr/local/lib/ghc-6.10.4/old- locale-1.0.0.1 -L/usr/local/lib/ghc-6.10.4/filepath-1.1.0.2 -L/usr/ local/lib/ghc-6.10.4/array-0.2.0.0 -L/usr/local/lib/ghc-6.10.4/ syb-0.1.0.1 -L/usr/local/lib/ghc-6.10.4/base-4.1.0.0 -L/usr/local/lib/ ghc-6.10.4/integer-0.1.0.1 -L/usr/local/lib/ghc-6.10.4/ghc- prim-0.1.0.0 -L/usr/local/lib/ghc-6.10.4 -lHShaskell98-1.0.1.0 - lHSrandom-1.0.0.1 -lHSprocess-1.0.1.1 -lHSdirectory-1.0.0.3 - lHSunix-2.3.2.0 -ldl -lHSold-time-1.0.0.2 -lHSold-locale-1.0.0.1 - lHSfilepath-1.1.0.2 -lHSarray-0.2.0.0 -lHSsyb-0.1.0.1 -lHSbase-4.1.0.0 -lHSinteger-0.1.0.1 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl - u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info - u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_runHandlers_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,- search_paths_first -read_only_relocs warning Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5490~1/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple- darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5490)
Re: [Haskell-cafe] Request for Changelogs
2009/8/7 Neil Mitchell ndmitch...@gmail.com: Which leaves me with the option of getting the darcs repo and looking through darcs changes. If I know of a repository for the package. I also don't tag the darcs version when I make a release - I probably should... This could be a nice feature for cabal (or an external tool... cabal-release?): auto-increment the version number (of course, the 'level' of release would have to be specified) and tag the current darcs repo accordingly, then 'cabal upload' it. - George ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
