- Glasgow-haskell-users

instances for bottom?
by Keean Schupke 23 Nov '04

23 Nov '04

I was wondering whether the method by which default types are chosen for unresolved overloading could be made available to the programmer. It seems that if we consider the overlapping instances: class x instance Int instance Float instance x x overlaps with Int and Float... I was wondering if it were possible to determine that type inferance had failed... like with: show (read x :: y) Here y (the type of read x) has no type... and does not match _any_ instance apart from 'x'... so would it not be possible to have an instance for "no type"? perhaps: instance _|_ ... Keean.

1 0

RE: Bug in touchForeignPtr?
by Simon Marlow 23 Nov '04

23 Nov '04

On 20 November 2004 23:02, Benjamin Franksen wrote: > 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. The problem is that the runtime is running all outstanding finalizers at the end of execution, without regard for GC dependencies like the ones introduced by touchForeignPtr. I've been planning to remove this automatic running of finalizers for other reasons. However, then you will get absolutely no guarantee that your finalizer will ever run at all (indeed, the property isn't always true right now, but it is usually true). Let me share with you something that I've come to appreciate over the last few years: Finalizers are almost always not the right thing. Finalizers look terribly attractive, but often lead to a huge can of worms - best avoided if at all possible. Cheers, Simon

7 14

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

22 Nov '04

On 21 November 2004 00:56, Isaac Jones wrote: > The systems that would want to do this kind of thing, such as Debian, > have other mechanisms for deciding whether packages conflict, etc. IIRC, this is the argument I just used against adding support for multiple libraries in Cabal, so I guess I agree :-D > Over-all I'm kinda neutral about whether HC-pkg needs to be an opaque > interface to the packaging system. What are the advantages to this? Well, for one thing it allows us flexibility in how we store the package database. In GHC, I'm using the show/read form of [InstalledPackageInfo] to store the database, but it'd be nice if I could use binary serialisation in the future. To support a directory of config files, we don't have to expose the complete format, though. As long as hc-pkg can process the InstalledPackageInfo to produce the native format into a file, then we just ship that file with the distribution. So I'm fine with this, as long as we're not specifying the contents of the *.conf file. Cheers, Simon

1 0

RE: unlit/ghci does not work on DOS file
by Simon Marlow 22 Nov '04

22 Nov '04

On 18 November 2004 20:31, Christian Maeder wrote: > 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) Thanks, fixed. Cheers, Simon

1 0

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