Re: Debian stable not supported?
Yitzchak Gale [EMAIL PROTECTED] writes: Roman Cheplyaka wrote: I think I'll face with the similar problem in the nearest future, except I have far more old system. So I'll be very greatful if you provide the instructions and record your experience. (Looks like I may need to do this again soon for 6.10, unless they support Debian stable this time.) Hi, Looks like it would be best to coordinate with debian-haskell: http://urchin.earth.li/pipermail/debian-haskell/2008-September/000492.html -- Cheers, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Any Debian Etch packages for GHC 6.8.2?
Ian Lynagh [EMAIL PROTECTED] writes: On Tue, Jan 08, 2008 at 11:23:59AM +0100, Wagner Ferenc wrote: Ian uploaded 6.8.2 the day before yesterday... Maybe when he's finished with this work, a rebuild on Etch won't be too difficult. I do plan to do this at some point, but it's not imminent I'm afraid. Maybe I can lend you a hand if you describe the plan. I've got some packaging experience, but not with beasts of this complexity. -- Regards, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
Wagner Ferenc [EMAIL PROTECTED] writes: Stefan O'Rear [EMAIL PROTECTED] writes: On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Hmm, you have got a point, but then I can't uninstall/upgrade later easily, I'm afraid. I poked a little further down this road. For creating a package, it would be useful if I could ./configure --prefix=/usr and later DESTDIR=/tmp/stage make install (or similar, you got the idea) so that I can gather the would-be-installed files into a package for later installation. If no pathes are wired into the binaries during make install, then setting prefix to /tmp/stage/usr would do the trick, but it's not the case, I guess. Something similar must be necessary for Igloo to create the Debian Sid packages, so I find it somewhat surprising that it's not present in Makefile.in (or Makefile-bin.in?) On the other hand, he must be working with the source distribution, which may have this infrastructure... Anyway, it would be simple to add this by augmenting the install commands, but before I dive into this, I wanted to ask for your opinions. -- Thanks, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
In the end I created a new ghc6 package from the binary bundle by slight modifications and shameless theft from Ian Lynagh control file. It seems to work together with libreadline4 from Sarge. I'm willing to share it with anybody interested. -- Regards, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? -- Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [ ghc-Bugs-1188785 ] panic! ... forkM Declaration for tables{v}
Simon Marlow [EMAIL PROTECTED] writes: Comment By: Ferenc Wágner (wferi) Just to make sure: the Could not find module `HTMLMonadBase'... is entirely reasonable (and my package.conf is crap), it's the ghc: panic! I found worrying. Yes, we plan to fix the panic and emit a more helpful message. Fine! Anyway. Let me drift off topic: why no ghcOptions field in package.conf? I'd perhaps try porting Wash if it were present... The ability to specify extra GHC options in a package was a misfeature that we removed. It isn't reasonable for a package to be able to change the global GHC behaviour. I see. But why did hugsOptions remain, then? -- Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghci can't continue in a situation (HXml Toolbox)
Hello, Please have a look at the transcript below. GHC happily compiles the file with the Makefile, while GHCi chokes on it. I would be grateful for any insight into the problem. Feri. tba:~/haskell/xml/ $ cat xml2wiki.hs import System import XmlInput import XmlTree import XmlState getLength :: String - XState () Int getLength file = do [xmlTree] - getXmlContents $ newDocument file io $ putStr $ show xmlTree return 14 main :: IO () main = do [xmlFile] - getArgs l - run' $ getLength xmlFile putStrLn (show l) -- tba:~/haskell/xml/ $ cat Makefile HXT := $(HOME)/haskell/xml/HXmlToolbox-3.01 INCLUDES := $(HXT)/hdom:$(HXT)/hparser:$(HXT)/http:$(HXT)/popen:$(HXT)/parsec:$(HOME)/haskell/HTTP PACKAGES := -package util -package net xml2wiki: xml2wiki.hs ghc -o $@ --make -i$(INCLUDES) $(PACKAGES) $ -- tba:~/haskell/xml/ $ cat .ghci :set -package net -package util :set -i/home/wferi/haskell/xml/HXmlToolbox-3.01/hdom:/home/wferi/haskell/xml/HXmlToolbox-3.01/hparser:/home/wferi/haskell/xml/HXmlToolbox-3.01/http:/home/wferi/haskell/xml/HXmlToolbox-3.01/popen:/home/wferi/haskell/xml/HXmlToolbox-3.01/parsec:/home/wferi/haskell/HTTP -- tba:~/haskell/xml/ $ ghci xml2wiki ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package readline ... linking ... done. Loading package unix ... linking ... done. Loading package posix ... linking ... done. Loading package util ... linking ... done. Loading package network ... linking ... done. Loading package net ... linking ... done. Skipping Zord64_HARD ( /home/wferi/haskell/HTTP/Zord64_HARD.lhs, /home/wferi/haskell/HTTP/Zord64_HARD.o ) Skipping ParsecPos( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecPos.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecPos.o ) Skipping ParsecError ( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecError.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecError.o ) Skipping ParsecPrim ( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecPrim.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecPrim.o ) Skipping ParsecChar ( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecChar.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecChar.o ) Skipping ParsecCombinator ( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecCombinator.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/ParsecCombinator.o ) Skipping Base64 ( /home/wferi/haskell/xml/HXmlToolbox-3.01/http/Base64.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/http/Base64.o ) Skipping MD5 ( /home/wferi/haskell/HTTP/MD5.lhs, /home/wferi/haskell/HTTP/MD5.o ) Skipping AssocList( /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/AssocList.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/AssocList.o ) Skipping NTree( /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/NTree.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/NTree.o ) Skipping Util ( /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/Util.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/Util.o ) Skipping Unicode ( /home/wferi/haskell/xml/HXmlToolbox-3.01/hparser/Unicode.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hparser/Unicode.o ) Skipping Parsec ( /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/Parsec.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/parsec/Parsec.o ) Skipping XmlCharParser( /home/wferi/haskell/xml/HXmlToolbox-3.01/hparser/XmlCharParser.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hparser/XmlCharParser.o ) Skipping POpen( /home/wferi/haskell/xml/HXmlToolbox-3.01/popen/POpen.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/popen/POpen.o ) Skipping HTTP ( /home/wferi/haskell/xml/HXmlToolbox-3.01/http/HTTP.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/http/HTTP.o ) Skipping Browser ( /home/wferi/haskell/xml/HXmlToolbox-3.01/http/Browser.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/http/Browser.o ) Skipping XmlTreeTypes ( /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/XmlTreeTypes.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/XmlTreeTypes.o ) Skipping XmlKeywords ( /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/XmlKeywords.hs, /home/wferi/haskell/xml/HXmlToolbox-3.01/hdom/XmlKeywords.o ) Skipping XmlTreeFunctions (
Re: ghci can't continue in a situation (HXml Toolbox)
Simon David Foster [EMAIL PROTECTED] writes: I had to remove POpen from HXT to make it work correctly with GHC 6.2. I think this because posix now includes popen and so it conflicts with the version in HXT. Try removing POpen.hs and doing it again, make sure you load package posix. Yep, it seems you are right. Although I don't really understand this. Is POpen a new addition to the old libraries? Btw, I didn't need to add -package posix anywhere, it's probably implied by something else in my case. Thank you very much for the quick help! -- Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
Tomasz Zielonka [EMAIL PROTECTED] writes: On Sun, Jan 11, 2004 at 10:22:09PM +0100, Ferenc Wagner wrote: It isn't suitable for exchanging bigger amounts of data between processes. May I ask why? Well, if you were collecting big amounts of data (like dozens of megabytes) from the child process, you would probably rather want to either: a) consume it incrementally b) store it in a more economic data structure Of course, both can be done in Haskell. I wonder if I could change my code to abstract it away... I remember a discussion on the Haskell list about consuming database requests. The consensus was to use some pre-fold like callbacks (proposed by Oleg?) as the most general solution for such problems. You may want to look into that. Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
Tomasz Zielonka [EMAIL PROTECTED] writes: On Sat, Jan 10, 2004 at 04:50:28PM -0500, Mark Carroll wrote: Your code looks great, Thanks :) It isn't suitable for exchanging bigger amounts of data between processes. May I ask why? Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
Tomasz Zielonka [EMAIL PROTECTED] writes: I had a similar problem, and finally I created my own solution that doesn't leave zombies and doesn't block when the launched process writes too much to stderr. Pretty neat, I've got an application idea for that code! Couldn't it be include in the standard libraries? Anyway, thanks for posting it. Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
Simon Marlow [EMAIL PROTECTED] writes: Tomasz Zielonka [EMAIL PROTECTED] writes: I had a similar problem, and finally I created my own solution that doesn't leave zombies and doesn't block when the launched process writes too much to stderr. Pretty neat, I've got an application idea for that code! Couldn't it be include in the standard libraries? Anyway, thanks for posting it. There is an outstanding proposal for a System.Process library: http://www.haskell.org/~simonmar/System.Process.html This is currently stalled because we need a non-blocking implementation of getProcessStatus (which is in the pipeline). Something akin to Tomasz's launch could also be included here. How is it different from System.Posix.Process? Supposed to be more portable? Sounds good. Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: POpen, opening lots of processes
Hal Daume III [EMAIL PROTECTED] writes: On Thu, 8 Jan 2004, Glynn Clements wrote: What does the output from ps indicate? It lists all the processes as defunct: 19981 pts/5Z 0:00 [suffixtree defunct] 19982 pts/5Z 0:00 [suffixtree defunct] 19983 pts/5Z 0:00 [suffixtree defunct] 19984 pts/5Z 0:00 [suffixtree defunct] 19985 pts/5Z 0:00 [suffixtree defunct] ... if you have zombies (Z state), the program has terminated but the parent (your program) hasn't called wait/waitpid (the Haskell interface is getProcessStatus, getProcessGroupStatus or getAnyProcessStatus). I don't mind evaluating the contents returned strictly, but I can't figure out how to force the process into a dead state... They are dead, just not acknowledged by their parent, so the OS keeps their exit statuses around. I don't see how any of these three functions accomplishes that... what am I missing? These functions read the exit status, and the OS will clean up. If you start them sequentially, then simply insert a call to the appropriate function at a point where the previous child is already finished. Or spawn a thread which sequence_s nonblocking getAnyProcessStatuses... :) Never tried myself. man waitpid Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.2 breaks multiline string literals
Stefan Reich [EMAIL PROTECTED] writes: multilineLiteral = line1 line2 Use string gaps (see 2.6 in the Report): multilineLiteral = \ \ line1\n\ \ line2 -- Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
Ian Lynagh [EMAIL PROTECTED] writes: The (Interactive) Glasgow Haskell Compiler -- version 6.2 And, for Christmas, we at Debian bring you sackful of debs! Fantastic! Actually, I already downloaded them a couple of days ago, but thought to wait with the thanks until the announcement. *THANKS!* Both for the developers and for the packagers, who take the pain of providing Woody packages, too! Merry Christmas! Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling trouble
Simon Marlow [EMAIL PROTECTED] writes: Both of these bugs were fixed in 5.04.2. Great. I'm afraid there's no way at the moment, but I'll look into adding a flag. The problem is that the longer the stacks get, the less room there is for the graph - hp2ps tends to squeeze the graph up to make room for the labels, which is why we truncate them. It's clear. The disappointing thing was to find truncated names in the .hp file, too... Btw, a wonderful XML tool is coming, isn't it? :) Till then, a switch would be more than enough. The .prof file also helps. And the letters could be smaller, and the text could be wrapped, and... For a screen view (I've never printed a profile) almost everything will do. Your other problem (misattribution of costs in the profile) seems to be related to the use of overloaded functions, and the compiler isn't translating the definition of getStates properly. I haven't found a fix yet. On the other hand, I've already found the problem with my code (the heap profiler helped much), so I'm coding away happily! Thanks for the good work! Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Profiling trouble
Hello, something interesting turned up again. Setting cut=8 in Show2.hs and running it with ./show +RTS -h -i0.01 gives show: fatal error: main thread has been GC'd It may be silly, since 0.01 1/50, but this error message isn't too helpful. Btw, +RTS -? says: -imsec Time between heap samples (msec, default: 100) which is wrong (time is given in seconds really). One more question: is there a way not to truncate the call stacks? Ie in the hp file I see lines like (144)showData2/showData/ma... 12 and I'd like to see showData2/showData/main or so. Cheers: Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling trouble
Hello,
Please help me understanding GHC 5.02.2 profiling output!
Here is the root of my program (Show.hs):
\begin{code}
showData:: BaseVector a = Params - Operator a - String
showData params pot = unlines [Version 3.1,
,
showParams pot params,
tcsdim: ++ tcsDim,
,
conformal energies:,
diagonals,
perturbation matrix:] ++
matrixElements
where
cutStates = {-# SCC showData1 #-} getStates params
tcsDim = {-# SCC showData2 #-} show (length cutStates)
diagonals = {-# SCC showData3 #-} unlines $ map (show .
energy) cutStates
matrixElements = {-# SCC showData4 #-} unlines $ map unwords off
off = {-# SCC showData5 #-} [map (myShow . pot outV)
(take i cutStates)
| (outV,i) - zip cutStates [1..]]
main= do params - option
putStr $ showData params (superPot params)
\end{code}
If I compile it via
ghc -package util -o show --make Show.hs -prof -auto-all
I get in show.prof:
Fri Jan 24 17:46 2003 Time and Allocation Profiling Report (Final)
show +RTS -p -RTS -c 5 -s R -p 0 -t 0 -r 3
total time = 94.54 secs (4727 ticks @ 20 ms)
total alloc = 2,313,980,136 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
showData1Main86.1 88.5
cutAbove4Tcsa 3.61.5
ncEpsEpsilon 3.33.1
GC GC 2.20.0
vopMode Boson1.51.1
ncVopBoson1.21.0
getStatesTcsa 0.61.2
individual inherited
COST CENTRE MODULE entries %time %alloc %time %alloc
MAIN MAIN 00.0 0.0100.0 100.0
mainMain 00.1 0.0100.0 100.0
[...]
showData Main 10.0 0.0 91.1 91.9
showData5 Main 10.0 0.0 0.3 0.4
myShow Main 94530.3 0.3 0.3 0.3
showData4 Main 10.0 0.1 0.0 0.1
showData3 Main 10.1 0.1 0.1 0.1
showData1 Main 1 86.1 88.5 90.8 91.4
cutAbove Tcsa280.0 0.0 3.6 1.5
cutAbove2 Tcsa 10.0 0.0 0.0 0.0
cutAbove3 Tcsa270.0 0.0 0.0 0.0
cutAbove4 Tcsa283.6 1.5 3.6 1.5
spinSelect Tcsa 10.0 0.0 0.0 0.0
getStatesTcsa 10.6 1.2 1.0 1.4
incrementalBase Fermion 10.3 0.2 0.4 0.2
fermionNumber Fermion 776640.1 0.0 0.1 0.0
allTowers Boson10.0 0.0 0.0 0.0
inModule Boson 170.0 0.0 0.0 0.0
mergeUp Boson60.0 0.0 0.0 0.0
showData2 Main 10.0 0.0 0.0 0.0
[...]
My question: showData1 is a single function call, how can it
still have such a big individual share? Where is the
program spending its time? Sorry if it is a trivial
question, functional profiling is new to me.
Thanks: Feri.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: passing an option to gcc without a -
Hal Daume III [EMAIL PROTECTED] writes: I'm linking with a .a file built from C [...] so i tried ghc MyFile.hs -o myout -optctheafile.a but this doesn't appear to pass the paramter. If it's acceptable, you can try mv theafile.a libtheafile.a ghc MyFile.hs -o myout -L. -ltheafile Just a thought. Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
