November 2004 - Glasgow-haskell-users

filterSet
by Serge D. Mechveliani 22 Nov '04

22 Nov '04

Dear GHC team, As there exists, say, Data.mapSet, is this natural to provide also filterSet ? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Another finalizer question
by Benjamin Franksen 21 Nov '04

21 Nov '04

The library docs say *** newForeignPtr :: ... ...Note that there is no guarantee on how soon the finalizer is executed after the last reference was dropped; this depends on the details of the Haskell storage manager. The only guarantee is that the finalizer runs before the program terminates. *** As others have noted too, there is in fact *no* guarantee that finalizers are called. The only way I found to force calling of finalizers is explicitly calling System.Mem.performGC before the program exits. Is this a bug in the implementation of finalizers or is the documentation wrong or am I just stupid? Ben -- Top level things with identity are evil. -- Lennart Augustsson

1 0

RE: proposal for ghc-pkg to use a directory of .conf files
by Simon Marlow 20 Nov '04

20 Nov '04

On 09 November 2004 17:36, Isaac Jones wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> On 08 November 2004 18:47, Duncan Coutts wrote: >> >>> We can use ghc-pkg at the build / install-into-temp phase to create >>> the $(package).conf files under >>> $TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final >>> installation is jsut merging files without any post-install calls to >>> ghc-pkg to modify installed files (ie the global ghc package.conf >>> file) >>> >>> So we can still keep the abstraction of $HC-pkg and gain simpler >>> packaging stuff. >> >> Ok, sounds reasonable. >> >> I'm going to be working on the package support in ghc and ghc-pkg to >> improve support for Cabal, so let's do this at the same time. > > As a Debian packager, I like the idea of changing the way HC-PKG > handles individual packages. > > The question in my mind is whether we want to execute any code on the > install target. Previously, I have thought of "./setup register" as > being a step that happens on the target, no matter what. So if Marcus > Makefile wants to do something specifically for the target at install > time, this is where he could do it. > > If we go this route and have the package registration happen at > install-in-temp time, then we don't have any standard way to run a > post-install script. Some people may prefer that we never execute > anything from Cabal on the target, but I would prefer to leave that > ability. > > One solution would be to move the registration step into > install-into-temp time, as above, but to add another standard command > to Cabal like "./setup postinstall" and maybe some others "preinst, > prerm, postrm" as in Debian. > > This would solve both problems; haskell packages installed with a > packaging system like Debian would usually just be moving files into > place, but if Marcus or Angela really needed to run something on the > target, this is how they'd do it. If ./setup register isn't going to run at install time, then I agree we might want ./setup postinst too. There's another thing that bothers me though: when you install a package using hc-pkg, a number of checks are made: 1. there isn't already a package with that name/version 2. If the package is to be exposed, then the modules provided by the package don't overlap with another exposed package. 3. if an older version of the package is already exposed, then the older one is supposed to be hidden in favour of the new one Since with the proposed change hc-pkg isn't running on the target system, it can't make any of these tests. GHC can detect at run-time that you have overlapping packages, but then it might not be possible to make changes to the package database (you might need to 'su' in order to do it). Cheers, Simon

2 1

Bug in touchForeignPtr?
by Benjamin Franksen 20 Nov '04

20 Nov '04

Hi, I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr inside the finalizers to express liveness dependencies as hinted to by the documentation. This doesn't seem to work, though, or at least I can't see what I've done wrong. I attached a test module; compiled with ghc -fglasgow-exts --make TestForeignTouchBug.hs, ghc version 6.2.2, this gives .../foreigntouchbug > ./a.out <hit enter here> before finalizing A after finalizing A before finalizing B after finalizing B <hit enter here> I expected the order of the finalizer calls be be the other way around, since the finalizer for the Bs explicitly touches the A value. Ben -- Top level things with identity are evil. -- Lennart Augustsson

1 0

[ ghc-Feature Requests-1069653 ] ghci compile option
by SourceForge.net 19 Nov '04

19 Nov '04

Feature Requests item #1069653, was opened at 2004-11-19 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1069653&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: Nightmare (goronsf) Assigned to: Nobody/Anonymous (nobody) Summary: ghci compile option Initial Comment: Sometimes you want to develop something using ghci, but a lot of files are just interpreted everytime (which takes a lot time), while they could also had been compiled. (An option is writing a simple script each time (but that's not what users want.) So what I want (and some people on #haskell): an interface to compile everything instead of interpretate it. So inside ghci I want to have an option: :compile which compiles everything (except maybe for the module you are currently working on.) This is how people in #haskell would appreciate it: 21:13 < goron> Is there some command to say in ghci: precompile everything? 21:13 < goron> I had to write some scripts to do it. 21:14 < Lemmih> goron: ghc --make, perhaps. 21:15 < goron> Lemmih: I meant inside ghci. My approach was ghc --make, but I had to include a lot of paths. 21:15 < goron> And it seems something useful. 21:17 < Lemmih> Agreed. 21:18 < Lemmih> But unfortunately I haven't heard of such feature. 21:18 < Somebody else> Yep, would be immensly useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1069653&group_…

1 0

Anybody that has an idea about Italian Verb Engine program?
by Suzan Bayhan 19 Nov '04

19 Nov '04

I will be gratefull if anybody knows how to compile and run this program. http://www.helsinki.fi/filosofia/filo/jvp/analisi.html http://www.cs.chalmers.se/~aarne/tmp/contributions/ranta/analisi.html Thanks a lot. Suzan BAYHAN

2 1

unlit/ghci does not work on DOS file
by Christian Maeder 18 Nov '04

18 Nov '04

Hi, calling unlit on a DOS file fails, whereas hugs is able to process the same file (under unix). Christian Prelude> readFile "Test.lhs" >>= putStrLn . show "\r\n> module Test where\r\n>\r\n" Prelude> :l Test.lhs Test.lhs line 2: unlit: Program line next to comment phase `Literate pre-processor' failed (exitcode = 1)

1 0

optimized compilation fails with gcc 3.4.3 under solaris
by Christian Maeder 17 Nov '04

17 Nov '04

Hi, when I compile "Hello World" optimized, I get error messages and an unusable binary. Everything works fine with gcc version 3.3.5 (or unoptimized). Cheers Christian maeder@leo -> uname -a SunOS leo 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-280R maeder@leo -> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.1 maeder@leo -> gcc -v Reading specs from /export/software/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/lang -program-suffix=_3.4.3 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 --enable-shared=libstdc++ --disable-nls Thread model: posix gcc version 3.4.3 maeder@leo -> ghc --make Main.hs -O Chasing modules from: Main.hs Compiling Main ( Main.hs, Main.o ) /tmp/ghc14393.hc: In function `__stginit_Main': /tmp/ghc14393.hc:5: note: if this code is reached, the program will abort /tmp/ghc14393.hc: In function `__stginit_ZCMain': /tmp/ghc14393.hc:12: note: if this code is reached, the program will abort /tmp/ghc14393.hc: In function `Main_a_entry': /tmp/ghc14393.hc:33: note: if this code is reached, the program will abort /tmp/ghc14393.hc: In function `Main_main_slow': /tmp/ghc14393.hc:49: note: if this code is reached, the program will abort /tmp/ghc14393.hc: In function `Main_main_entry': /tmp/ghc14393.hc:64: note: if this code is reached, the program will abort /tmp/ghc14393.hc: In function `ZCMain_main_slow': /tmp/ghc14393.hc:79: note: if this code is reached, the program will abort Linking ... maeder@leo -> ./a.out Illegal Instruction

1 0

RE: [Haskell] package with ghc and ghci
by Simon Marlow 17 Nov '04

17 Nov '04

[ moved to glasgow-haskell-users(a)haskell.org ] On 16 November 2004 07:51, Fred Nicolier wrote: > I have some packages for doing signal and image processing stuff. > Here is a little test program : > > \begin{code} > module Main where > import Hips > a = listSignal (1,10) [1..10] > b = liftSignals (:+) a a > c = fft b > main = do > putStrLn $ show a > putStrLn $ show b > putStrLn $ show c > \end{code} > > 1/ Compiled with : ghc -package hips testFFT.hs > 2/ interpreted with : ghci-package hips testFFT.h > > 1/ no problem > 2/ dont execute and gives 'unknown package name: =Numeric' (Numeric is > another package called by Hips, included in HaskellDSP). Please send the output of command (2) with -v added to the command line. Cheers, Simon

2 1

RE: Compiling Haskell on an UltraSparc/NetBSD
by Simon Marlow 16 Nov '04

16 Nov '04

On 15 November 2004 21:16, Stephane Bortzmeyer wrote: > [Not subscribed to haskell-users so please copy me the answers.] > > To compile the revision control system Darcs (http://www.darcs.net/) > I need Haskell but I'm not myself a Haskell user. > > My machine is an UltraSparc 10 running NetBSD 1.6.2 userland and 2.0 > kernel. > > There is a package source for Glasgow Haskell, so, let's try in > /usr/pkgsrc: > > % make > ... > checking build system type... sparc64-unknown-netbsd2.0. > checking host system type... sparc64--netbsd > checking target system type... sparc64--netbsd > Unrecognised platform: sparc64--netbsd > gmake: Entering directory > `/usr/pkgsrc/lang/ghc/work/ghc-6.2.1/glafp-utils' > ../mk/boilerplate.mk:66: ../mk/config.mk: No such file or directory > You haven't run ./../configure yet. > gmake: *** [../mk/config.mk] Error 1 There isn't an existing build for your platform, which means you'll have to bootstrap. Also, it looks like a small amount of porting effort will be required (the configure script hasn't recognised the platform, so at least you'll need to add a few obvious lines in there). Full porting instructions are here: http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l Bootstrapping generally works quite smoothly, but if you run into problems we're always happy to help. Send us any patches you end up needing. Cheers, Simon

1 0