Re: [HOpenGL] renderString not working in ghci
[ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: I've been playing around with GLUT (latest version from hackage, on Debian) a bit yesterday and am having some troubles with renderString. It works fine when I compile a binary using ghc, but when running from ghci I get an error similar to the following (I don't have the actual error at hand atm). freeglut(interactive): font 0xsomething not found From looking at the freeglut code, it seems this means that the font pointer passed in does not match the address of any of the font variables in the library. I'm not completely sure how the linking works in ghci, but it appears that something goes wrong with dynamic linking? Is this a known problem, or does anyone have any pointers where to debug this? After thinking about this for a while, I got a déjà vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding --ghc-option=-fPIC to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] renderString not working in ghci
Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts:
I don't know how the problem reported in that message is related to the
renderString problem (which I do not understand), but the behaviour you
see there is not terribly surprising. It's an artefact of the way
dynamic linking works and should not generally cause any problems.
The word generally is a problem in itself. ;-) The main point is that GHCi'l
dynamic linker behaves differently from the system's dynamic linker, so this
is a very good reason to consider this a bug. It might not surface very often,
but it is nevertheless a different behaviour a.k.a. bug.
The only case where it should make a difference is if code is assigning
any meaning to the address of functions, eg to compare them for
identity. In that case going via a thunk will make a difference. Is that
what freeglut is doing do you think?
It is not about the address of functions, it is about data addresses. Here is
the relevant snippet from GLUT's/freeglut's header file for non-Windows
platforms:
--
/*
* I don't really know if it's a good idea... But here it goes:
*/
extern void* glutStrokeRoman;
extern void* glutStrokeMonoRoman;
extern void* glutBitmap9By15;
...
/*
* Those pointers will be used by following definitions:
*/
# define GLUT_STROKE_ROMAN ((void *) glutStrokeRoman)
# define GLUT_STROKE_MONO_ROMAN ((void *) glutStrokeMonoRoman)
# define GLUT_BITMAP_9_BY_15 ((void *) glutBitmap9By15)
...
--
As you can see, GLUT's fonts are represented by the addresses of global
variables. This might not be the nicest way to do this, but it has to be done
for binary compatibility reasons and there is *nothing* dubious about this.
Note that e.g. we are very lucky that errno is a macro for a function call
on all platforms for which -fPIC is relevant, otherwise we would have the same
problem with it, too.
The GLUT Haskell package uses a simple C wrapper around these macros:
--
void*
hs_GLUT_marshalBitmapFont(int fontID)
{
switch (fontID) {
case 0 : return GLUT_BITMAP_8_BY_13;
case 1 : return GLUT_BITMAP_9_BY_15;
case 2 : return GLUT_BITMAP_TIMES_ROMAN_10;
case 3 : return GLUT_BITMAP_TIMES_ROMAN_24;
case 4 : return GLUT_BITMAP_HELVETICA_10;
case 5 : return GLUT_BITMAP_HELVETICA_12;
case 6 : return GLUT_BITMAP_HELVETICA_18;
}
return (void*)0;
}
--
For reasons explained in great length in the mail thread quoted, GHCi's linker
doesn't link the wrapper correctly on some platforms when -fPIC is not used
for its compilation.
I rather suspect it's freeglut doing something dubious with comparing
function pointers.
The only one doing dubious things is GHCi's dynamic linker... ;-)
On most platforms -fPIC imposes some overhead and so it is only used
when it's advantageous or necessary. On most platforms code that will
live in a shared library should or must be compiled with -fPIC. x86-64
is one of the few architectures where the overhead is relatively low.
So my question is again: Why is -fPIC not the default for GHC on x86_64? If we
don't want the overhead, that's OK (any benchmark numbers?), but then GHC's
documentation should really contain a big, fat warning that GHCi's dynamic
linker gets cases like the one above wrong.
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Inter-module links with Haddock broken?
Am Samstag, 25. April 2009 14:48:03 schrieb Sven Panne: Currently I am unable to make inter-module links (of the form 'Foo.Bar.baz') work with the Haddock shipped with GHC 6.10.2. [...] Until a few moments ago, I wasn't aware of the fact that Haddock has a trac for itself nowadays, so I guess my problem is a symptom of: http://trac.haskell.org/haddock/ticket/78 What is the schedule for the Haddock milestone 2.5.0 mentioned in that ticket? When can we expect that fix in a shipped GHC? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Inter-module links with Haddock broken?
Currently I am unable to make inter-module links (of the form 'Foo.Bar.baz') work with the Haddock shipped with GHC 6.10.2. The library documentation on haskell.org has the same problem, see e.g. the last paragraphs of http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control- Exception-Base.html#v:catch This doesn't work for a few releases now, so I guess this is a known bug, but I can't find a ticket for it. Are there workarounds for this? A new syntax? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bug: wrong ghc location in package.conf
On Tuesday 11 September 2007 05:58, Conal Elliott wrote: In ghc-6.8 20070909, my package.conf contains some strange and incorrect paths, such as haddockInterfaces = [/usr/local/doc/ghc/libraries\\html\\containers\\containers.haddock], haddockHTMLs = [/usr/local/doc/ghc/libraries\\html\\containers] In fact, the installation location is c:/ghc/ghc-6.8.20070909/, not /usr/local. I do have a failed partial ghc build (from darcs HEAD) at /usr/local from last week. Perhaps there's some sticky info somewhere. [...] There was some confusion regarding build paths vs. installation paths in GHC's build system. I think I've fixed most of this in the last few days, at least I get a nice RPM on Linux now. Could you try to update to the bleeding edge and rebuild? It would be good to have some Windows feedback. Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #985: Memory Leak in freeHaskellFunPtr
Am Donnerstag, 1. Februar 2007 14:56 schrieb GHC:
#985: Memory Leak in freeHaskellFunPtr
--+
- Reporter: [EMAIL PROTECTED]| Owner: igloo
Type: merge | Status: new Priority:
normal| Milestone: 6.6.1 Component:
Compiler |Version: 6.6 Severity: normal
| Resolution:
Keywords: callback, FFI, freeHaskellFunPtr | Difficulty: Unknown
Testcase: provided | Architecture: Multiple
Os: Windows |
--+
- Changes (by simonmar):
* owner: simonmar = igloo
* type: bug = merge
Comment:
Fixed. Patch to merge (from 6.6 to HEAD):
{{{
Thu Feb 1 13:53:33 GMT 2007 Simon Marlow [EMAIL PROTECTED]
* fix memory leak in allocExec/freeExec (see bug #985)
}}}
Hmmm, I think I haven't seen this patch in the HEAD yet. In general: The
current quite liberal (a.k.a. chaotic :-) ) style where patches are
somtetimes applied to STABLE first and merged to HEAD later and vice versa
gives me some headaches. In good old times we fixed the HEAD and simply
merged this to STABLE. :-( Is there an automatic way to see which patches
should still be merged into which direction? If not, we should handle things
a bit stricter, I guess...
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: building docs fails for stable ghc-6.4.2 (2006/03/23 snapshot)
Am Freitag, 24. März 2006 15:55 schrieb Duncan Coutts: I built yesterday's ghc-6.4.2 snapshot (2006/03/23) and had a problem building the docs. [...] Things have improved, but make html still fails, this time when building the Haddock documentation for the base package: haddock: modules are recursive: Control.Exception GHC.Conc GHC.TopHandler Prelude System.IO GHC.Handle GHC.IO Data.IORef SimonM: Is make html part of the nightly builds? It should definitely be, as in the past it turned out to be one of the stages with most bugs in it... Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Still some GHC trouble when building Haddock
Some days ago I reported a regression in GHC: http://www.haskell.org//pipermail/cvs-all/2006-March/046637.html I've fixed Happy to produce correct code, so the 2nd problem mentioned is already solved. Nevertheless, the regression remains even in yesterday's GHC built from darcs HEAD (what's the right terminology here?). Shouldn't this be caught by the nightly builds somehow? Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Signal inconsistency between GHC and GHCi
Am Mittwoch, 28. Dezember 2005 14:05 schrieb Bulat Ziganshin: Wednesday, December 28, 2005, 3:28:07 PM, you wrote: [ usleep/nanosleep trouble deleted... ] may be you comile with -threaded? ghci don't use this option, afaik The SIGALRM happen with purely interpreted code and even without loading any code at all into GHCi... :-( Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Signal inconsistency between GHC and GHCi
Am Sonntag, 1. Januar 2006 19:40 schrieb Bulat Ziganshin: Sunday, January 01, 2006, 2:27:01 PM, you wrote: [ usleep/nanosleep trouble deleted... ] may be you comile with -threaded? ghci don't use this option, afaik SP The SIGALRM happen with purely interpreted code and even without loading any SP code at all into GHCi... :-( i say that your COMPILED code works ok because it uses -threaded, but GHCi fails because it just never use this option Well, you can safely assume that I would have mentioned any strange commandline flags used for compilation, so don't jump to wild assumptions... It was plain old ghc --make Blah.hs on x86 SuSE Linux. And no, GHCi did not get any options, either. Anyway, the question was (slightly reformulated): Why does GHCi seize the SIGALRM resource and why does it receive high-frequency signals even when idling on the prompt? Neither is this very power-saving-friendly nor necessary and can lead to problems with external libraries. Perhaps our RTS Grand Master SimonM can comment on this. :-) Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Signal inconsistency between GHC and GHCi
After some hours of debugging Haskell code which involves the FFI, I think I've found a bug or at least an inconsistency between code compiled with GHC and code executed by GHCi: My program calls out to native library code which uses usleep and/or nanosleep, and things work well when using the compiler. But when GHCi is used, a lot of SIGALRMs are happening, which are interrupting usleep/nanosleep (leading to EINTR). Are these signals really intended when using GHCi? If yes, what can be done to avoid them? One can argue that the library should check for EINTR after sleeping and re-sleep in that case. While it is easy and portable with nanosleep, the behaviour related to signals for usleep is explicitly unspecified, so there is not much which can be done in that case. :-( Any help is highly appreciated, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Signal inconsistency between GHC and GHCi
Am Mittwoch, 28. Dezember 2005 13:20 schrieb Sven Panne: [ usleep/nanosleep trouble deleted... ] I forgot something in my last email: -- from fptools/libraries/unix/System/Posix/Unistd.hs --- usleep :: Int - IO () usleep 0 = return () #ifdef USLEEP_RETURNS_VOID usleep usecs = c_usleep (fromIntegral usecs) #else usleep usecs = throwErrnoIfMinus1Retry_ usleep (c_usleep (fromIntegral usecs)) #endif --- Simply re-sleeping after an EINTR with the same amount of microseconds is not the right thing here, we should better use the time left. Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: happy documentation fails to build
Simon Marlow wrote: Odd, the Happy docs build for me. Although building the ps version does take nearly 2 minutes and dumps 3Mb of stuff to stdout in the process - Sven, any idea why this might be? It works for me in 21 sec and only 52kB of stdout. :-) The difference is that my PostScript is generated via fop (version 0.20.5) and Ian's via the PassiveTeX route. I have seen varying versions of DocBook + PassiveTeX breaking in various wonderful arcane ways in the past, so I recommend installing fop. The configure process will prefer fop if it finds it, just for that reason, BTW. Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Fwd: bug in argument processing in hsc2hs]
Antony Courtney wrote: I'm trying to upgrade my Java/Haskell interoperability framework to the latest Java version. Unfortunately, however, it appears that hsc2hs can't deal with embedded spaces in command line arguments.[...] Both of your problems look like the usual problems with the broken system function used within hsc2hs. One should really use rawSystem instead to avoid the problems with spaces and quotation. But I don't have the time to figure out how to do this correctly, keeping the backward compatibility with older GHC version. SimonM? Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.1 and FedoraCore2: ar-related build problem, looked like readline problem
Henrik Nilsson wrote: [...] So, in summary, there were two problems: * The configuration tools somehow thinks the system's ar supports -input. Hmmm, it should have been detected by configure that this is not the case for your platform. Could you please send a log of the configuration step and the resulting config.log? * The build system fails to detect when ar failed in the first place. What is the exit code of ar called with -input on your platform? Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.1 and FedoraCore2: ar-related build problem, looked like readline problem
[ Ooops, I've read Simon's reply *after* I've replied... ] Henrik Nilsson wrote: As Simon M. said, it seems the version of ar shipeed with FC2 is broken. It returns a 0 exit code when called with what it believes to be a non-existing file (-input). That's what I've assumed. Hopefully the shell-script snippet I sent, or something like it, can be used as a work-around. The correct way would probably be testing the exit code *and* stderr. There's already some support for this kind of stuff in our aclocal.m4 IIRC, I'll have a look into it... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.1 and FedoraCore2: ar-related build problem, looked like readline problem
Ian Lynagh wrote: I think you've already fixed this in CVS: [...] Alas, no. :-( Cheers, S. [...] I haven't looked to see if the fix was merged to the stable branch or not, though. HEAD and STABLE are identical in this respect. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 6.2.1 and FedoraCore2: ar-related build problem, looked like readline problem
Henrik Nilsson wrote: [...] So, in summary, there were two problems: [...] I think I've fixed this now (in HEAD and STABLE branch). Could you please test if it works now? If you like to merge the patch manually to your sources: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/aclocal.m4.diff?r1=1.174;r2=1.175;f=h Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: HOpenGL buglet
Ketil Malde wrote: With my (Gentoo) installation, I need to swap -lGL and -lGLU in the definition for OpenGL to make things (including -package GLUT, for some reason) work . This is apparently a known bug: http://www.haskell.org/pipermail/hopengl/2003-October/000430.html but (also apparently) it's still doesn't work (ghc 6.2). This is a known (but obviously still unfixed) bug in Gentoo's library dependencies, see e.g. http://www.haskell.org/pipermail/hopengl/2003-December/000459.html http://www.haskell.org/pipermail/hopengl/2004-May/000492.html Swapping the order would break linking on every correct platform, so you can either fix your Gentoo or patch OpenGL's package configuration. Keeping the illusion that everything is OK on Gentoo via ugly autoconf hacks is something I don't intend to do because it hurts quality in the long run... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: typo in decl. of timezone in Time.hsc?
Antony Courtney wrote: I think there may be a typo in libraries/base/System/Time.hsc. [...] Fixed in CVS (without unsafe, it's a no-op here), thanks. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Panic
Arjan van IJzendoorn wrote: [...] Loading package wxcore ... linking ... WARNING: Overflown relocation field (# re locs found: 30765) C:/cygwin/usr/local/lib/wxcore0.o: unknown symbol `_CC_LIST' ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1): can't load package `wxcore' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. This is a bug in GNU ld/BFD, see: http://haskell.org/ghc/docs/latest/html/users_guide/bugs.html#BUGS-GHCI (I've updated the wording to match the current message.) A workaround for this is mentioned there, too, please contact your wxHaskell supplier. :-) Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANSIfication of hp2ps
Nicholas Nethercote wrote: Ralf Wildenhues wrote a patch ANSIfying hp2ps, which included a fix that could avoid a bug. See: bugs.kde.org/show_bug.cgi?id=82098 I've applied the patch to GHC's HEAD and STABLE branches, thanks. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-pkg 6.2 incorrectly parses commas within quotes
Ashley Yakeley wrote: Any word on whether this has been/will be fixed? [...] Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a new GHC release comes out. Personally I'd favour tossing this feature altogether, [...] Me too... :-P * * * Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hopengl fails to compile in cvs head
Jeremy Shaw wrote: [...] ==fptools== gmake boot -wr; in /usr/ports/lang/ghc-cvs/work/fptools/libraries/OpenGL ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package package.conf.inplace Reading package info from stdin... Fail: Couldn't parse package configuration. gmake[2]: *** [../../ghc/driver/stamp-pkg-conf-OpenGL] Error 1 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/ghc-cvs/work/fptools/libraries' gmake: *** [build] Error 1 Huh? These lines look a little bit mysterious: Just before the ghc-pkg-inplace two lines seem to be missing. Here the relevant lines from my compilation log (about a month old): ==fptools== make boot -wr; in /usr/src/packages/BUILD/fptools/libraries/OpenGL gcc -E -undef -traditional -I../../ghc/includes -x c -DGLU_CFLAGS=',-I/usr/X11R6/include' -DGLU_LIBS=',-lGLU ,-lGL ,-L/usr/X11R6/lib ,-lX11 ,-lm' package.conf.in \ | sed 's/^#.*$//g' package.conf.inplace gcc -E -undef -traditional -I../../ghc/includes -DINSTALLING -x c -DGLU_CFLAGS=',-I/usr/X11R6/include' -DGLU_LIBS=',-lGLU ,-lGL ,-L/usr/X11R6/lib ,-lX11 ,-lm' package.conf.in \ | sed 's/^#.*$//g' package.conf.installed ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package package.conf.inplace warning: can't find GHCi lib `HSOpenGL.o' Reading package info from stdin... done. Expanding embedded variables... done. Saving old package config file... done. Writing new package config file... done. [...] Could you send me your full compilation log and fptools/config.log, please? Meanwhile I try to build the HEAD... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hopengl fails to compile in cvs head
Jeremy Shaw wrote: Under both Linux (Debian) and FreeBSD, I get the following error building ghc from cvs head: It was a bug in GHC's build system introduced lately. Fixed in HEAD. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: __stginit_Int_
Ralf Hinze wrote: [...]. Loading package fmp ... linking ... /home/ralf/Software/FuncMP/fmp.o: unknown symbol `__stginit_Int_' ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): can't load package `fmp' Try adding -package haskell98 to GHC's options or use the Data.Int module instead of module Int. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: __stginit_Int_
Ralf Hinze wrote: Thanks for the work-around(?). Adding -package haskell98 works if it listed after -package fmp. It's not a workaround, it's just a missing dependency for your fmp package. Probably the right thing would be adding haskell98 to the package_deps field of your package description for fmp. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: The impossible has happened ...
David Duke wrote: [...] Loading package GLUT ... linking ... C:/ghc/ghc-6.2/HSGLUT.o: unknown symbol `_glutMainLoop' ghc.exe: panic! (the `impossible' happened, GHC version 6.2): can't load package `GLUT' [...] Alas, this is a known bug in GHC's WinDoze installer, but it can easily be fixed, see the bottom of: http://haskell.org/pipermail/hopengl/2003-December/000457.html Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-pkg 6.2 incorrectly parses commas within quotes
Ashley Yakeley wrote:
Might it not be better to do it this way?
deps = base,haskell98,network
[${deps},foo] = (expand $-reference)
[base,haskell98,network,foo] = (quote things)
[base,haskell98,network,foo]
The idea is that unquoted things get implicitly quoted, so you don't
need to quote ${deps}.
I don't have very strong feelings about this, I just changed it in a
hopefully non-intrusive way. IMHO this feature is useless, anyway,
expanding during package installation time can easily be accomplished
by sed and friends...
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: DEPRECATED not re-exported
Simon Peyton-Jones wrote: I agree. Your message caught me at a moment when I needed some displacement activity, so I've implemented a fix. [...] I hope you need more displacement activity. :-) The fix makes things better, but not yet optimal: Warnings are issued for whole module re-exports now, e.g. [...] Foreign/Marshal.hs:28:0: Warning: Deprecated use of `withObject' (imported from Foreign.Marshal.Utils) use `with' instead [...] Foreign.hs:39:0: Warning: Deprecated use of `withObject' (imported from Foreign.Marshal, but defined in Foreign.Marshal.Utils) use `with' instead [...] Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug during documentation generation?
Andres Loeh wrote: Shouldn't the attached patch be applied to the file package.mk in the GHC 6.2 build system? [...] Thank for the patch, I've just applied it to the CVS version. I thought I fixed this some time ago, but OTOH I have been building my GHC including the OpenGL package for ages now... :-) Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: RFunE: Unusedness for warnings transitive in GHC 6.0.1
Simon Peyton-Jones wrote: I'd be interested to know what others think about this. The disadvantage with the GHC5 behaviour is that you might see a warning about unused f, remove the definition of f, and thereby provoke a new warning, for a function g that was mentioned in f's right hand side.[...] That's exactly the reason why the current behaviour is much better than the old one, IMHO, so I'd vote for: Keep the status quo. BTW, C/C++ compilers usually behave in a similar way for file-local entities, and I think people like it that way. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: RFunE: Unusedness for warnings transitive in GHC 6.0.1
Mike Gunter wrote: Is it hard to treat all names beginning with '_' as used (and otherwise behave as GHC6 does)? That seems to give us the best of both worlds. Or no? Sounds OK to me... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: user package blocks standard ones
Serge D. Mechveliani wrote: [...] /home/mechvel/test/export/HSdocon.o: unknown symbol `__stginit_List_' [...] Then, occasionally, tried to set package_deps = [data] , even though my contrived user package does not use data. And it started to work, to load everything needed! Then I try package_deps = [base] And here ghci -package-conf docon.conf reports again the `panic'. [...] I don't have your sources at hand, but it looks like they depend on the haskell98 package. Package data depends on haskell98, BTW. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
Alastair Reid wrote: This still feels like a brittle solution to me. But an ABI is one of the most solid conventions on any platform, so I really can't see a problem here. I believe that testing what your actual machine does and does not support is the right approach when not cross-compiling. Granted (almost :-). I appreciate that some people may disagree here but if you do agree, then surely the same applies when cross-compiling and the only issue is how to implement such an approach? So, I'll ask again: Can we split our autoconf scripts into two parts: one to be run on the host machine and one to be run on the test machine? :-P * * * Seriously: Should the configure script run tests via rsh/ssh? And what if the target platform can't be reached remotely? I've never seen such an autoconf trick before... My suggestion is: * If the test can be done via compilation (for the target platform!) alone, just do it that way (e.g. compile-time constants like EAGAIN etc.) * If the test can't be done via compilation alone, try the following in order: * If the test is very closely tied to the target host/platform (e.g. ABI-related stuff like underscores on external names) and it is a known host/target platform, use a case/switch on the host/target platform name. * If we are cross-compiling, we are out of luck: Abort! (with a suggestion, if possible, like you probably don't need an underscore because the host/target platform looks like ELF). * Use a runtime test. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
Alastair Reid wrote: Tests needing a *target* machine are bad when it comes to cross-compilation, so we should try to avoid this for GHC. OK, GHC is not really capable of cross-compilation yet, but we shouldn't make things worse. This is a topic I haven't thought about much. What is the recommended way of dealing with it? Do we cut the autoconf scripts in two and run one half on the source machine and one on the target machine? Do we replace all those autoconf tests (ugly but accurate) with platform-based tests (simpler but brittle)? [...] I just had a look at GCC 3.3.1's sources and the way this is handled is effectively based on the name of the target platform (which gets magically mapped to some header in gcc/config). I don't think that this brittle because things like this are hardwired into the platform ABI forever, otherwise one would lose binary compatibility. Furthermore, there seem to be some reasonable defaults for unknown or partly known target platforms (e.g. no underscores for ELF). Apart from that, I can't see any other solution for this problem. Doing a runtime test on the build/host platform for a feature of the target platform is simply wrong... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc 6.0.1 and Mac OS X 10.2.6 build
Alastair Reid wrote: Could I recommend that you use or adapt the autoconf test HUGS_TRY_DYNLINK (hugs98/src/unic/aclocal.m4 in the same cvs repository that has ghc). I would recommend against this. :-) This test generates a C object file to be loaded then tries to load the object file using one of dlopen, LoadLibrary, NSCreateObjectFileImageFromFile and shl_load then tries looking up both the symbol '_test' and 'test' in the file. It sets the linker flags to use to build dynamically loadable object files and whether or not to use an underscore when doing the lookup and it works on HPUX, Mac, Win32 and most mainstream unix variants. (Bug reports and improvements are, of course, welcome.) Tests needing a *target* machine are bad when it comes to cross-compilation, so we should try to avoid this for GHC. OK, GHC is not really capable of cross-compilation yet, but we shouldn't make things worse. Regarding the underscore story: I think I've seen similar tests in other programs (some version of Guile?), but I can't remember. Could somebody explain in a few sentences what exactly the underscore problem is in GHC(i) and/or the libraries? Things look a bit muddled in the source code... :-] Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: warning: assignment makes pointer from integer without a cast
Mark Shields wrote: Not really a bug, but seems disconcerting... This is from compiling Koen's SAT solver front-end, available from http://www.math.chalmers.se/~koen/paradox/paradox-1.0-casc.tar.gz Using ghc 6.0.1, -O2 ... Compiling: Sat.hs /tmp/ghc24790.hc: In function `Sat_identify_entry': /tmp/ghc24790.hc:903: warning: assignment makes pointer from integer without a cast That's a bug in Paradox: identify and solver_new are imported into Haskell without any prototypes. Fixing this would require some changes in Paradox, because the header containing the prototypes is a C++ header, not a C one, but GHC uses a C compiler... Cheers, S. P.S.: Adding #includes for assert would be nice, too... ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: locating package.conf
Simon Marlow wrote: [...] but 'make install' on Windows is very rare anyway (most people just install from the .msi or run it from the build tree). But a 'make install' is not so rare if you took the trouble of installing half a dozen utilities to do a successful 'make'. :-) I'd only be guessing at the right way to fix this. Perhaps SysTools should look for $prefix/lib/package.conf in addition to $prefix/package.conf? Hmmm, I'm not sure how to fix this correctly (probably the 'make install' logic on WinDoze is simply broken), but a quick workaround would be a shell script / batch file adding -Bc:\Programme\cygwin\usr\local\lib\ghc-6.1 to the commandline for ghc.exe and ghci.exe (if your prefix was /usr/local and your Cygwin is installed in c:\Programme\cygwin). Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: problem compiling OpenGL/.../Extensions.hs with GHC version 6.0
Quick guess: Are we using the wrong type of quotes ( instead of '') in SysTools now? Previous GHCs quoted -D/-U options with the latter ones... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] Re: GLUT copyright violation
Ross Paterson wrote: [...] The text you've used is also spread across the manpages included in the glut tarball. I wasn't aware of that. Assuming that makes the manpages part of libglut, they would be covered by the permission Michael Weber mentioned: http://www.fifi.org/doc/glutg3-dev/copyright Cool! Mark's reply on the bottom of that page is far more than we need. I'm a bit surprised though that he suddenly even allows modifications of his library, something which he tried so hard to avoid in the past. so it should suffice to change the acknowledgement in GLUT.hs to say that your docs are based on the manpages from libglut, by Mark J. Kilgard. I will gladly do so. Would this calm down everybody here? Many thanks to Ross for this Happy End! :-) Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
OpenGL documentation license [was: GLUT copyright violation]
And while we are at this thrilling topic: I'm using the man pages from SGI's OpenGL sample implementation (SI) as a basis for the documentation of the OpenGL part. This is in accordance to SGI's license http://oss.sgi.com/projects/FreeB/ which was confirmed by Jon Leech (see below). The only thing currently missing is the SGI copyright notice at the start page of the documentation, something which is on my ToDo list for a long time :-}. It will be added very soon, so we should be on the legal track here... Cheers, S. --- From: Jon Leech [EMAIL PROTECTED] To: Sven Panne [EMAIL PROTECTED] Subject: Re: SI license On Tue, Sep 10, 2002 at 02:32:15PM +0200, Sven Panne wrote: I have a small non-technical question about the license of the SI: Would it be OK to use the SI's man pages as a basis for the online documentation of my open source OpenGL binding for Haskell? (http://haskell.org/HOpenGL) I had a look a the SGI Free Software License B, but without being a lawyer it is a bit hard to tell. BTW, the project uses literate programming to automatically generate the API documentation from the Haskell sources, so there is no real separate documentation for the binding, if this is of any legal significance... In essence the FreeB license is BSD-like, so you can do almost anything with material covered by it other than change or remove the license applied to that material. If you were to integrate material from the SI man pages into your bindings and include the SGI copyright notice along with the material you integrated, that would be OK with us. I imagine there would be a significant problem with this scheme if your code is under an incompatible license like GPL, though. Jon Leech SGI ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GLUT copyright violation
Well, I've already responded to this allegation yesterday, but obviously not to this list. Mailing in hurry is seldom a good idea... So I'm trying to explain this once again: Let's start with non-legal (i.e. common sense) arguments: * I do not claim that the documentation of my GLUT binding is written from scratch and therefore I have included a reference to Mark's original work at a prominent place. Although I do not concur with Mark's attitude in all areas, I respect his work: Writing a simple but very useful library which is still in use after a decade is more than most people will probably achieve in their lifetime. * I've tried very hard to stay in GLUT's spirit and made no gratuitous additions, which is exactly what Mark is trying to achieve with the status GLUT. Although sometimes a nuisance, this is why GLUT hasn't evolved into yet another swiss army knife library, which are so common these days. * I do not earn a single cent from my binding, neither does Mark get any money for GLUT. And even if he did, making GLUT available to a broader audience would boost his income, not lessen it. * I've tried to contact Mark several times through different channels, but without avail. Browsing through the links Claus has kindly tracked down, it is clear that Mark has lost his interest in GLUT and probably has a mail filter deleting everything about this topic. On the one hand, I can understand this, because given GLUT's widespread use, he is probably flooded with mails about it. But on the other hand this makes it nearly impossible to really sort this simple copyright issue out, which is a pity. Now to the more formal arguments: Attaching a two-line copyright statement to something isn't even remotely enough to prevent any usage without explicit admission, so I suggest people should read a bit before starting a copyright infringement jihad against me, e.g. http://www.benedict.com/info/fairUse/fairUse.asp or the memorandum of a well-known person in her more peaceful days: http://fairuse.stanford.edu/rice.html And some final words taken from http://www.law.cornell.edu/copyright/cases/499_US_340.htm : [...] The primary objective of copyright is not to reward the labor of authors, but promote the Progress of Science and useful Arts. [...] To this end, copyright assures authors the right to their original expression, but encourages others to build freely upon the ideas and information conveyed by a work. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [HOpenGL] Re: GLUT copyright violation
Ross Paterson wrote: That is a delicate way of putting it. It appears that you've used almost all of his text. ... as a basis. And that's exactly what should be expected for a library binding: Either you follow the initial specs exactly or you don't really do a binding. Even though no money is involved, calling this fair use and ignoring his notice is quite a stretch. Well, the amount of work used is of course an issue, but not *the* issue, see e.g.: http://www.utsystem.edu/ogc/intellectualproperty/copypol2.htm#test I use Mark's published (see 2.) work in a non-profit way (1.), but not to a small amount (3.). But there is no market for the GLUT docs and I neither compete with Mark's work nor do I take away royalties from him (4.). So this *is* a fair use IMO, but IANAL... And to restate: I do not simply ignore Mark's notice, he ignores any attempt of communication on this issue. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Bus Error when profiled
Dean Herington wrote: I compiled a program with [...] When I run it, it evokes a Bus Error (with or without +RTS -p). Any ideas what's wrong? I'm using GHC 5.02.3 on Sparc/Solaris. Do you use the FFI and don't use -O or -fvia-C? There were some problems with the native code generator on SPARC, which have been fixed in 5.04.1. So as a rule of thumb, try using -O or -fvia-C on SPARC if you're experiencing segfaults or the like. Another source of trouble is GCC 3.x on SPARC, but I've lost track in this area. SimonM? Anyway, a program demonstrating the bug would be helpful. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: FFI: passing 6 FD arguments doesn't work
Simon Marlow wrote: [...] George, can you verify that your test case works fine if you use -fvia-C? [...] I tested George's stuff on our Solaris box, and it fails without -fvia-C (during the fprintf) and works with this option. Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Instruction Cache Flush in createAdjustor on SPARC
Simon Marlow wrote:
I'm not a sparc expert, would anyone like to suggest a patch?
From the top of my head (sorry, I forgot my SUN Enterprise Server at work :-):
/* the flush instruction works on double words */
inline void flushCacheOnSPARC(int64_t* from, int64_t* to) {
while (from to) {
asm(flush %0 : : r (from++));
}
/* it could take up to 5 instructions until the flush is visible */
asm(nop : : );
asm(nop : : );
asm(nop : : );
asm(nop : : );
asm(nop : : );
}
Cheers,
S.
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Stack Overflow Panic
Wolfgang Thaller wrote: [...] There is no problem with ghc-5.02.2 on Intel. I cannot try it out on ghc-5.03/intel due to lack of disk space. Any Ideas? The GHC from HEAD (Feb 28) crashes, too, even without -O. :-( No idea why, but -v tells me that it is the first simplifier pass... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Stack Overflow Panic
Just a small note: Changing PP from a datatype renaming (newtype) to an algebraic datatype (data) or inlining ppThen helps... Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Syntax for implicit parameters
Simon Peyton-Jones wrote:
[...]
1. [happy]. Use 'let'
2. [consent]. Use 'dlet' or 'with'
3. [hate] Use both 'dlet' and 'with'
Would the Hugs folk be willing to adopt (2)?
I'm getting a little bit lost in this thread: Everybody seems to
agree that stealing identifiers is bad, stealing a *very* useful
identifier ('with') is *very* bad, and Alastair promised to synch
Hugs with GHC, so why don't we adopt (1)?
Confused,
Sven
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Problem reading files...
Andre W B Furtado wrote: [ EOF at Ctrl-Z problem ] Sounds like you're using WinDoze which interprets Ctrl-Z as EOF in non-binary files IIRC (great idea, BTW! :-}. Alas, you have to use non-standard features (openFileEx or hSetBinaryMode) to get around this, see: http://www.haskell.org/ghc/docs/latest/set/sec-ioexts.html#AEN8657 Cheers, Sven ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Optimisation problem in pre-4.07-200000613 (and 4.06)
Armin Groesslinger wrote: I think I have found an optimisation problem in GHC pre-4.07-2613. [...] Cool bug! :-) The example can be cut down further to: main :: IO () main = print (length (filter (not . foo) (filter (const False) [Nothing]))) where foo (Just x) = x foo _= error "foo" After some experiments it seems that the RULE for filterFB is the wrong: "filterFB" forall c p q. filterFB (filterFB c p) q = filterFB c (\x - p x q x) At least everything works when it is removed from the corresponding interface file. Perhaps I'll have a closer look later. Cheers, Sven
Re: Optimisation problem in pre-4.07-200000613 (and 4.06)
The RHS of the RULE for filterFB confuses p and q, which can be shown as follows: filterFB is defined as follows: filterFB c p x r | p x = x `c` r | otherwise = r which is equivalent to filterFB c p x r = if p x then c x r else r () is defined as follows True x = x False _ = False which implies that if a b then c else d is equivalent to if a then (if b then c else d) else d Now we can deduce filterFB (filterFB c p) q a b = if q a then filterFB c p a b else b = if q a then (if p a then c a b else b) else b = if q a p a then c a b else b = filterFB c (\x - q x p x) a b which is *not* equivalent to filterFB c (\x - p x q x) a b Adventurous people can fix this this without recompilation by hand-editing PrelList.hi: Search for "filterFB" near the end of the file and flip p and q in the RHS. For more timid people: I'm checking in a fixed version of PrelList.lhs. :-) Cheers, Sven
Re: Problem solved...
[ I didn't see a CC: in Marcin's reply, so I'll quote the full mail again... ] Marcin 'Qrczak' Kowalczyk wrote: Mon, 5 Jun 2000 20:26:05 +0100, Nick Williams [EMAIL PROTECTED] pisze: data Cost = Val Integer | Infinity deriving Show deriving (Eq, Ord, Show) makes right instances in your case. instance Ord Cost where Val x Val y = xy Infinity Val _ = False Val _ Infinity = True Infinity Infinity = False Default implementation of (=) uses compare and vice versa. If you define neither of them, both will loop forever. It's enough to provide either compare or (=) in the Ord class, but not (). But -fwarn-missing-methods (which is on by default) should yield a warning in that case. Perhaps it doesn't handle circular default methods correctly? Don't know... Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Traditional bogus warnings
I know that those warnings below are longstanding buglets, but would it be possible to remove them before the release of 4.07? I had a medium-quick look at the desugarer/type checker, but with no real success. - module Foo where import Complex bar :: String - Int bar "ab" = 1 bar "c" = 2 bar _= 3 baz :: Complex Float - Int baz 0= 11 baz (_ :+ _) = 22 - panne@jeanluc:~ ghc -Wall -c Foo.hs Foo.hs:5: Pattern match(es) are overlapped in the definition of function `bar': bar "c" = ... Foo.hs:10: Pattern match(es) are overlapped in the definition of function `baz': baz (_ (:+) _) = ... Foo.hs:10: Pattern match(es) are non-exhaustive in the definition of function `baz': Patterns not matched: (#x) with (#x) `notElem` [0] ----- Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: ghc -v always makes gcc-2.95.1 dump core?
Marcin 'Qrczak' Kowalczyk wrote:
Now I understand, thanks strace. ghc -v tries to execute "time
gcc ...", but perl does not pass the command line to sh if it does
not contain shell metacharacters, tries to interpret it itself,
and tries to execute a program named time which does not exist.
[...]
Well, "time" is a builtin in bash and {,t}csh, but not in {,z,k}sh.
The same holds for e.g. kill, printf, test, ... I don't know much
about Perl's innards, but you should have equivalent standalone
programs in {,/usr}/bin, at least most Linux distributions, HP-UX,
etc. do.
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: bug in foreign import (for floats)
Malcolm Wallace wrote: And a warning: The FFI specs do not guarantee that Float maps to float, and likewise for the other Haskell types with names sounding like the C types. It is the task of the upcoming module CTypes to provide newtypes exactly for this task. Eek, so was this the consensus on the FFI mailing list? Yes. It seems rather horrible to me, but I imagine the rationale is that the primitive FFI should not be C-specific. Not only that: You can't dictate that all implementations of Haskell have to use e.g. int for Int. And I can't see what's horrible about writing `CInt' instead of `Int', you only state clearly your intent and don't rely on adventurous assumptions about the underlying representation. And which Haskell types should one choose for size_t, clock_t, time_t, ...? (Answer: CSize, CClock, CTime, ... :-) So is someone writing a JavaTypes module for release soon...? :-) Java is a slightly different story: At least the sizes for the basic types are specified, so e.g. a Java int fits into an Int32. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: If this bug is important let me know
Mike Jones wrote: I get this error with 4.05. If it is important, I can send source. c:/tmp/ghc5016.hc:30113: warning: `X1Z_closure' was declared `extern' and later `static' This is one of GHC's classics. But it isn't a real error, only a warning from the C compiler, which you can safely ignore. IIRC it is not easy to fix (comments from GHC HQ?). Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Bootstrapping ghc with -O fails
Building 4.07 with 4.06 works fine, but in a second bootstrapping phase the fresh 4.07 can't compile itself, at least not with "SRC_HC_OPTS += -O". Without -O everything seems to work... Cheers, Sven ... ghc -O -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:profiling:parser:usageSP:cprAnalysis:nativeGen -recomp -c rename/RnMonad.lhs -o rename/RnMonad.o -osuf o RnMonad.lhs:7: Failed to find interface decl for `MkId.aBSENT_ERROR_ID' from module `MkId' RnMonad.lhs:7: Failed to find interface decl for `MkId.mkPrimOpId' from module `MkId' RnMonad.lhs:7: Failed to find interface decl for `MkId.eRROR_ID' from module `MkId' RnMonad.lhs:7: Failed to find interface decl for `MkId.mkPrimOpId' from module `MkId' RnMonad.lhs:7: Failed to find interface decl for `MkId.iRREFUT_PAT_ERROR_ID' from module `MkId' RnMonad.lhs:7: Failed to find interface decl for `MkId.mkPrimOpId' from module `MkId' [ tons of similar error messages deleted ] -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Problems importing PrelGHC
Currently importing PrelGHC does not work if -O is used, e.g. when compiling hslibs: ../../ghc/driver/ghc-inplace -O -recomp -cpp -optC-fglasgow-exts -fvia-C -Rghc-timing -I../../ghc/includes -imonads -static -hisuf p_hi -O -prof -c Bits.lhs -o Bits.p_o -osuf p_o Bits.lhs:13: Could not find valid [boot] interface file `Ix' Bits.lhs:13: Failed to find interface decl for `Ix' from module `Ix' Bits.lhs:13: Failed to find interface decl for `Ix' from module `Ix' Compilation had errors Should Ix somehow be added to PrelGHC.hi-boot? Don't know... Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
f.e.d. broken
Given: -- module Foo where import Addr foreign export dynamic mkCallback :: (Int - IO Int) - IO Addr -- the current GHC from CVS dies: marutea:/tmp ghc -O -fglasgow-exts -c -Wall Foo.hs SaAbsInt.lhs:537: Non-exhaustive patterns in function absApply And if one forgets the first `IO': DsForeign.lhs:271: Irrefutable pattern failed for pattern Just (ioTyCon, [res_ty])) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: FFI, -O .hi files
Simon Peyton-Jones wrote: [...] a) to make the worker a NOINLINE thing, so it never got inlined anywhere b) allow it to be inlined freely in its own module, but then not export the inlining of any function that now has an embedded ccall. It's a little bit hard to decide between a) and b), because it will probably depend on the actual code which one is the better solution. I'm leaning towards a), but this more a feeling than anything else. Anyway, this is only the second best choice IMHO. c) leave it as it is Bad! d) make it command-line-flag controllable But GHC has too many command line flags already. [...] Granted, but we already have a very suitable one (SimonM, Sigbjorn, don't read any further! ;-) : -funfold-casms-in-hi-file Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: problem building optimized compiler
kirstin reese wrote: (building cvs top with 4.06) When compiling CoreUnfold with the -O flag: ParseIface.hs:6827: Non-exhaustive patterns in case Currently the way to go is: Compile 4.07 with 4.06 *without* -O for hsc. With the resulting 4.07 you can switch -O on again to get an optimized hsc in a second bootstrapping stage. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: ghc/compiler/utils/FastString.lhs won't compile (suspect version skew)
George Russell wrote: Er, has this bug report been lost? It doesn't seem to have been dealt with . . . [ ST / hPutBuf trouble deleted ] What GHC version are you using for compilation? Due to some library reorganization you have to build 4.07 with 4.06, most of the 4.07 versions from CVS won't compile the current sources. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: missing Native?
Simon Marlow wrote:
I don't think it's going to return, but if there is something you
rely on from it, then we should attempt to support it in the new FFI
story. [...]
The recent thread on binary IO almost included showBytes (in my
proposal for hPutBin):
---
type Bytes = [Char]
-- The code below is the same as
--(unsafePerformIO (inParam (unmarshalList (sizeOf x)) x) ++)
-- unfolded.
showBytes :: Storable a = a - Bytes - Bytes
showBytes x xs = unsafePerformIO $ do
buf - mallocElem x
poke buf x
val - mapM (peekElemOff buf) [ 0 .. sizeOf x - 1 ]
free buf
return (val ++ xs)
{- Even more imperative, but without ++ :-P
showBytes :: Storable a = a - Bytes - Bytes
showBytes x xs = unsafePerformIO $ do
buf - mallocElem x
poke buf x
let s = sizeOf x
loop i cs | i == s= return cs
| otherwise = do c - peekElemOff buf i
loop (i+1) (c:cs)
val - loop 0 xs
free buf
return val
-}
---
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Enum instance for Ratio
Both GHC and Hugs have a bug in their Prelude for Ratio's Enum instance. The following program import Ratio main = print [ 1, 4%(3::Int) .. 2 ] should print [1 % 1,4 % 3,5 % 3,2 % 1] but instead an infinite list of 1%1s is generated. The reason for this is that the default method for enumFromThenTo is used, which truncates 4%3 to 1 (same for enumFromTo). Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: litlits in interface files
Simon Marlow wrote: I think the only answer to this is "litlits are deprecated". We'll have to make do with foreign imports to get these kind of constants. It's not clear to me how exactly this should be accomplished via foreign import. The (well, *my* :-) basic problem is: How do you map about 1000 numerical #defines from C header files (OpenGL/GLUT) efficiently to Haskell? Saving some STG state, calling out to C land, and restoring some state for accessing every value will definitely make my binding about 1-2 orders slower. Currently the usage of litlits compiles into a single load instruction in machine code. *sigh* Normally I'm not an advocate of O(1) optimizations, but in this special case, which will happen in lots of inner loops, the situation is different... Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: litlits in interface files
Simon Marlow wrote: If you can #include the header file into the Haskell source, then you can get away without litlits. Of course, in the general (and in the OpenGL/GLUT) case you can't. If your header file contains extra gumph like prototypes and stuff, you can use this little trick: [...] Col trick, really! Didn't know the -dM flag. But again in my case it doesn't help: Depending on the OpenGL version there are #defines or a big enum. So the only portable way without litlits would be a small automatically generated C program that is run as part of HOpenGL's configuration process and outputs Haskell definitions or #defines for all needed constants. Aaaargl... Has anybody better ideas (coding tricks, extensions for the FFI, etc.) for a general solution to this problem? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: litlits in interface files
Marcin 'Qrczak' Kowalczyk wrote:
IMHO the following should be efficient, calling the function only
once, near the time of the first use (if not, should be fixed):
foreign import aConstant :: Int
#include header.h
int aConstant (void)
{
return A_CONSTANT;
}
Granted, but this still doesn't bring you back that single nice
machine instruction it would be in the case of litlits. OK, OK,
this is an O(1) optimization and going via C is bad, but sometimes
it's more efficient to be a bad boy... ;-)
A tool could be helpful in massive generating such functions...
And if you need a tool (which I desperately would), it can produce
the constants right away, without any foreign import. Hmmm, how
does this fit with Green Card? And the tool would seem conspicuously
like a cut-down version of Manuel's C-HS.
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Weak pointers, finalizers and SIGSEGV
Marcin 'Qrczak' Kowalczyk wrote: [...] Now it only sometimes crashes at Ctrl-C. The following progam does so too (about 1/10 of runs): [...] I can't reproduce this. BTW, the foreign object interface will change in future versions of GHC: module ForeignObj ( ForeignObj,-- abstract, instance of: Eq , makeForeignObj -- :: Addr - IO () - IO ForeignObj , foreignObjToAddr -- :: ForeignObj - Addr ) where ... I.e. the module name is more consistent, *every* foreign object has one finalizer, the foreign object is immutable, and foreignObjToAddr is not in the IO monad any longer. If you use ghc-4.06, you can simply use the module FFI, which imports Addr/ForeignObj among other things and offers malloc/free, too: import FFI import IO main:: IO () main = do hSetBuffering stdout NoBuffering sequence_ . repeat $ do addr - malloc 100 makeForeignObj addr (putStrLn "finalizer" free addr) putStrLn "x" But testing this showed another strange phenomenon: The heap grows infinitely. :-( A cut-down version, which has the same effect: import Addr import Foreign main:: IO () main = do fo - mkForeignObj nullAddr addForeignFinalizer fo (putStrLn "finalizer") main An example run: panne:/tmp ./Crash1 +RTS -M40M -Sstderr /dev/null Crash1 +RTS -M40M -Sstderr AllocCollectLiveGCGC TOT TOT Page Flts bytes bytes bytes user elapuserelap 263168262144120532 0.00 0.030.000.056 134 (Gen: 1) 6355968385024 8045144 0.08 0.100.080.1608 (Gen: 0) 803840 8306688 8340236 0.08 0.090.170.2600 (Gen: 0) 3056640 8605696 11735868 0.10 0.130.270.3900 (Gen: 1) 2166784 4026368 14311456 0.07 0.070.350.4700 (Gen: 0) 2547712 2846720 17382480 0.06 0.060.420.5400 (Gen: 0) 2390016 3350528 20249280 0.07 0.080.490.6300 (Gen: 0) 2423808 20512768 21617948 0.20 0.260.690.9000 (Gen: 1) 2452480 3190784 24565464 0.08 0.080.770.9800 (Gen: 0) Heap exhausted; Current maximum heap size is 39997440 bytes; use `+RTS -Msize' to increase it. Things get even stranger: Replacing `putStrLn "finalizer"' with a simple `return ()' yields constant space: panne:/tmp ./Crash2 +RTS -M200k -Sstderr /dev/null Crash2 +RTS -M200k -Sstderr AllocCollectLiveGCGC TOT TOT Page Flts bytes bytes bytes user elapuserelap 263168262144120532 0.00 0.030.000.047 132 (Gen: 1) 6355968385024120544 0.01 0.010.010.0605 (Gen: 0) 6356992385024120544 0.01 0.010.030.0800 (Gen: 0) 6356992385024120544 0.01 0.010.040.0900 (Gen: 0) 6356992385024120544 0.01 0.010.060.1100 (Gen: 0) [... ad infinitum ... ] Simon: Something wrong with the weak pointer stuff (used for implementing addForeignFinalizer)? Puzzled, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: False warning about overlapping patterns
Marcin 'Qrczak' Kowalczyk wrote:
GHC gives a false warning about overlapping patterns (-Wall):
f "ab"= 1
f ('c':_) = 2
Surprisingly, changing "ab" to ['a','b'] shuts up the warning.
[...]
This is one of GHC's classic false alarms, and has been reported
a couple of times by different people (including me :-}. But IIRC
it can't be fixed easily, because of the way literals are handled
in the desugarer(?). You see similar effects with numeric literals
when GHC compiles itself and its libraries (e.g. modules Complex,
Int, Num, IIRC). I'd like to see these warnings disappear, too.
Hmmm, perhaps I should update my (slightly dormant) Wish List...
:-)
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Wish List (Re: False warning about overlapping patterns)
Marcin 'Qrczak' Kowalczyk wrote: http://marutea.pms.informatik.uni-muenchen.de/wishlist/ is inaccessible... Oooops, that's because of our new firewall. I've moved it to a more generic address, which should work: http://www.informatik.uni-muenchen.de/haskell-wish-list/ Could somebody please update the link on haskell.org? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: parse error in Hugs98 library
Nick Eby wrote: In trying to compile the Random library from the hugs98 distribution i got the following error: Random.hs:205: parse error on input `::' Line 205 reads: primitive getRandomSeed :: IO Integer I don't see a syntactic error in this line. I do. :-) Does ghc have a problem with the 'primitive' declaration? [...] Exactly. In GHC (and probably already in NHC, too. Malcolm?) you have to write foreign import unsafe getRandomSeed :: IO Int A few remarks: * `unsafe' is not necessary, but improves performance, telling GHC that getRandomSeed won't re-enter Haskell-land before it has finished (less state to save/restore in the RTS). * You can't return `Integer' in GHC, only `Int'. This is a deliberate design decision, because only primitive types should be handled by the FFI. Integers are not primitive at all, see e.g. libgmp. * Obvious, but easily forgotten: Don't forget -fglasgow-exts and link with the object file containing getRandomSeed (which you probably have to rip off the Hugs98 sources). Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: FFI.lhs
Simon Peyton-Jones wrote: To be fair the 'how to build' notes do say "run autoconf first". I don't think autoheader is necessary. (If it is, someone say so, in which case it should get added to the build notes.) It *was* necessary to run autoheader after I've changed acconfig.h to re-generate mk/config.h.in. It's hard to specify exactly when its necessary to re-run autoconf. Specific suggestions for better documentation always welcome. If they take the form of draft text that's even better. My suggestion is simple: * "Normal" (= sane :-) people don't need autoconf/autoheader, because configure, mk/config.h.in, ... should always match their counterparts configure.in, acconfig.h.in, ... in a source distribution. * People compiling from CVS should always run both autoconf/autoheader in fptools and fptools/ghc. It doesn't hurt if nothing changed and guarantees consistency. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: FFI bug ?
Sigbjorn Finne wrote: Really? 'ByteArray Int' (and its mutable companion) is still available, but only if the user can guarantee that the 'import'ed call does not end up causing a GC, i.e., the following should work foreign import unsafe splat :: ByteArray Int - IO () the "unsafe" bit being the vital piece of info. Ooops, I forgot. :-} There was quite some mail traffic around this topic... At least this was the story for 4.045, so unless 4.06 behaves differently (I doubt it), you can still use ByteArrays. OK, but (Mutable)ByteArrays are so easy to implement given FFI (for creation/access) + Foreign(Obj) (for finalization), that the effort for maintaining, documenting, etc. them is at least a little bit doubtful. "Make it simple!" :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: FFI.lhs
"Jeffrey R. Lewis" wrote: Currently (out of CVS), a compile of `hslib/lang' fails on FFI.lhs: FFI.lhs:119: Data constructor not in scope: `SIZEOF_CHAR' FFI.lhs:120: Data constructor not in scope: `ALIGNMENT_CHAR' [...] Some parts of the configuration mechanism changed. Did you invoke autoheader and autoconf before configure? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: strange evaluation problem
Michael Weber wrote: It seems, today's GHC made the problem disappear (or, at least, it disappeared between 1999/12/06 and 2000/01/09), my test case now works as expected... Sven, what about yours? [...] *Sigh* A similar problem just occurred again! Given the following code snippet from the FFI proposal: - outParamWith :: (a - Int) - (Addr - IO a) - (Addr - IO b) - IO (b,a) outParamWith sizeOf_ unmarshal_ act = do buf - malloc (sizeOf_ undefined) retVal - act buf val - unmarshal_ buf free buf -- ** everything works if we comment out this free return (retVal, val) - It seems as if the unmarshaling (`unmarshal_ buf') is done at the moment the value of `val' is needed, which depends on the caller of outParamWith. But at this moment `free buf' has already happend and Electric Fence correctly complains. Further investigation shows that this happens when `unmarshal_' is bound to something like fixIO (\val - real unmarshaling via readCharOffAddr is done here) Hmmm, is this not as strict as I thought? %-( Perhaps I should try `seq' on the returned value... Confused as usual, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
DocBook tools versionitis?
Last night's build from CVS failed because of the docs:
[...]
+ cd docs
+ make dvi ps html
db2dvi -d /usr/src/packages/BUILD/fptools/docs/fptools-both.dsl installing.sgml
tex output file name is
jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported
jade:OSFD0:1:0:E: end of document in prolog
jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported
[...]
tex file name is
dvi file name is
This is TeX, Version 3.14159 (Web2C 7.3.1)
**
! End of file on the terminal... why?
The `-d' option seems strange:
panne@marutea:/usr/src/packages/SOURCES/fptools db2dvi --version
db2dvi - docbook-tools 0.5
panne@marutea:/usr/src/packages/SOURCES/fptools db2dvi --help
Usage: db2dvi [OPTION]... FILE
Run a DocBook SGML document trough various programs.
Options:
--help display this help and exit
-v, --version output version information and exit
-x trace the shell script
-d, --dvi output DVI
-f, --fot output FOT
-h, --html output HTML
-m, --mif output MIF
--pdf output PDF
-p, --ps, --postscript output PostScript
-r, --rtf output RTF
-t, --tex output TeX
-j, --jade VAR... set "jade" variables; e.g., "-V %shade-verbatim%"
-s, --style FILEuse FILE as driver style
HTML:
--nochunks don't produce HTML subdocuments; output to stdout
Only the last specified output format will be produced.
I've tried `-s' instead, but with no success:
marutea:/usr/src/packages/BUILD/fptools/docs db2dvi -s
/usr/src/packages/BUILD/fptools/docs/fptools-both.dsl installing.sgml
tex output file name is installing.tex
jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported
jade:/var/lib/sgml/CATALOG.docbk31:24:0:W: DTDDECL catalog entries are not supported
jade:/usr/src/packages/BUILD/fptools/docs/fptools-both.dsl:1:0:E: character "\" not
allowed in prolog
jade:/usr/src/packages/BUILD/fptools/docs/fptools-both.dsl:11:0:E: character "{"
not allowed in prolog
jade:/usr/src/packages/BUILD/fptools/docs/fptools-both.dsl:21:0:E: character "{"
not allowed in prolog
jade:/usr/src/packages/BUILD/fptools/docs/fptools-both.dsl:21:30:E: end of document
in prolog
jade:E: specification document does not have the DSSSL architecture as a base
architecture
jade:E: no style-specification or external-specification with ID "PRINT"
tex file name is installing.tex
dvi file name is installing.dvi
This is TeX, Version 3.14159 (Web2C 7.3.1)
(installing.tex
JadeTeX 1999/06/29: 2.7
(/usr/share/texmf/tex/latex/psnfss/t1ptm.fd)
(/usr/share/texmf/tex/latex/jadetex/isoents.tex)
Elements will be labelled
! LaTeX Error: Missing \begin{document}.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.8 {2}}B
uilding and Installing the Glasgow Functional Programming Tools Suite
(/usr/share/texmf/tex/latex/amsfonts/umsa.fd)
(/usr/share/texmf/tex/latex/amsfonts/umsb.fd)
(/usr/share/texmf/tex/latex/wasysym/uwasy.fd)
(/usr/share/texmf/tex/latex/lucidabr/lmrhlcm.fd)
(/usr/share/texmf/tex/latex/lucidabr/omlhlcm.fd)
(/usr/share/texmf/tex/latex/lucidabr/omshlcy.fd)
Overfull \hbox (36.2407pt too wide) in paragraph at lines 8--4647
[]\T1/ptm/m/n/10 Building and In-stalling the Glas-gow Func-tional Pro-gram-min
g Tools Suite Ver-sion 4.04The GHC Teamglasgow-haskell-$\OMS/cmsy/m/n/10 f$\T1/
ptm/m/n/10 users,bugs$\OMS/cmsy/m/n/10 g$\T1/ptm/m/n/10 @dcs.gla.ac.ukJanuary
[1.0.58] [2.0.58] [3.0.58] [4.0.58] [5.0.58]
! I can't find file `installing.aux'.
\enddocument ...makeatletter \input \jobname .aux
\fi \@dofilelist \ifdim \f...
l.4647 ...e{}\endNode{}\endNode{}\endNode{}\endFOT
{}
Please type another input file name
! Emergency stop.
\enddocument ...makeatletter \input \jobname .aux
\fi \@dofilelist \ifdim \f...
l.4647 ...e{}\endNode{}\endNode{}\endNode{}\endFOT
{}
Output written on installing.dvi (5 pages, 76420 bytes).
Transcript written on installing.log.
Suggestions?
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr.
Re: DocBook tools versionitis?
Michael Weber wrote: [...] IIRC, Sven's version is SuSE home-brewed (and incompatible, of course) [...] I've just realized the same, and immediately sent a bug report to SuSE. :-( Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: absCSyn/Costs.lhs won't compile
George Russell wrote: [...] gmake: *** [all] Error 1 M-x cvs-update :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Bug in Edison Makefile
Simon Marlow wrote: You shouldn't try building in the edison subdir; [...] That was only a test to see what is going on. I'm doing the usual `make all' directly in fptools/ in the course of building a ghc+hslibs RPM. The current hack is to add the following to mk/build.mk: SRC_HC_OPTS += -fallow-undecidable-instances (Actually, -O is included, too.) I'm not sure if adding -funbox-strict-fields would do any harm, so it is not added. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Overlapping LHS and unused imports
Sometimes the current GHC from the repository prints incorrect
warnings. Example:
---
module Foo where
bar :: String - Int
bar "ab" = 1
bar "c" = 2
bar _= 3
baz :: String - Int
baz ('a':'b':[]) = 1
baz ('c':[]) = 2
baz _= 3
---
panne@marutea:~/forschung/misc ghc -Wall -O -c Foo.hs
Foo.hs:4: Pattern match(es) are overlapped in the definition of function `bar':
bar "c" = ...
Note that there is no warning for baz. IIRC this has been reported
and fixed some time ago. Deja vu? Did they change the matrix? %-)
And another one: -Wall (which includes -fwarn-unused-imports) doesn't
warn about explicitly imported but unused entities anymore. An example
can be given if needed.
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: libgmp.so.2 desperately needed
"Manuel M. T. Chakravarty" wrote: [...] In the case of SuSE, IMHO, the Right Thing is a bug report to SuSE. Done. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Info table warning
I'm not sure if the following is harmless or not: Under some rare circumstances I get warnings of the following form: marutea examples/misc ghc -i/home/inst/panne/forschung/haskell/HOpenGL/lib -I/home/inst/panne/forschung/haskell/HOpenGL/lib -syslib posix -fglasgow-exts -recomp -Wall -O -c BspTree.hs -keep-hc-file-too ghc: module version changed to 2; reason: usages changed /tmp/ghc15974.hc:9889: warning: decimal constant is so large that it is unsigned /tmp/ghc15974.hc:9906: warning: decimal constant is so large that it is unsigned The following two lines from the .hc file provoke the above warnings: INFO_TABLE_SRT_BITMAP(c7b7_info,c7b7_ret,-2147483648,BspTree_zdwreadBspTree_srt,31,42,RET_SMALL,static ,IF_,0,0); INFO_TABLE_SRT_BITMAP(c7b6_info,c7b6_ret,-2147483648,BspTree_zdwreadBspTree_srt,31,43,RET_SMALL,static ,IF_,0,0); -2147483648 doesn't seem to be a nice value for an StgWord32... :-} Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: ghc-4.04: memory leak with foreign export dynamic?
Armin Groesslinger wrote: I think I have found a memory leak in GHC/FFI. [...] I think it's problem with stable pointers. You can start the following program several times and get several funny results, ranging from a sudden but silent death at different values of count with return value 1 to Fail: resource exhausted Action: writeChunks Reason: argument list too long (ghc-4.05 from CVS on Linux). import Stable loop :: Int - IO () loop count = do p - makeStablePtr count print count loop (count+1) main :: IO () main = loop 1 Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Offside rule bug?
I must admit that I don't fully understand the new offside rule anymore, but the following is probably a bug in ghc-4.04 (note that putStrLn is in the same column as the second occurrence of greetings): -- Foo.hs --- main = greetings where greetings = putStrLn "Hello, world!" - panne:~ ghc Foo.hs Foo.hs:3: parse error on input `' Compilation had errors Adding one more space in front of putStrLn makes ghc happy. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Instance bug
Here one of my favourite bugs in larger projects (IIRC, this
has partly been reported by me in the "Importing, hiding, and
exporting" thread):
-- A.hs -
module A where
data Foo = Foo -- Typo! Forgot "deriving Show"
-- B.hs -
module B where
import A
data Bar = Bar Foo deriving Show
data Baz = Baz Int deriving Show
-- Main.hs --
import A
import B
main :: IO ()
main = print (Bar Foo, Baz 42)
-
panne@jeanluc:~ ghc -Wall -O -c A.hs
ghc: module version changed to 1; reason: no old .hi file
panne@jeanluc:~ ghc -Wall -O -c B.hs
ghc: module version changed to 1; reason: no old .hi file
[??? Why does B compile? And why is Baz's Show instance not in B.hi? ]
panne@jeanluc:~ ghc -Wall -O -c Main.hs
Main.hs:4:
No instance for `Show Baz' arising from use of `print' at Main.hs:4
Main.hs:4:
No instance for `Show Bar' arising from use of `print' at Main.hs:4
This one drove me mad several times, looking at the completely
wrong place (i.e. B.hs).%-{
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Typechecker buglet
The typo in the following module causes ghc to crash:
--
module Foo where
data Bar = Bar { flag :: Bool }
data State = State { bar :: Bar, baz :: Float }
display :: State - IO ()
display (State{ bar = Bar { flag = f, baz = b }}) = print (f,b)
-- Typo! The line above should better be:
-- display (State{ bar = Bar { flag = f }, baz = b }) = print (f,b)
--
panne@jeanluc:~ ghc -Wall -O -c Foo.hs
panic! (the `impossible' happened):
tcLookupValue: b{-r4n-}
Please report it as a compiler bug to [EMAIL PROTECTED]
Done! :o)
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
callFun.s still needed?
And another one: Is callFun.s still needed? Almost everything is #ifdef-ed out and the Alpha assembler does not like the directive .file "callfun.S" Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Portability questions of the week :-)
My questions were:
What is the output of:
#include stdio.h
int main(void) { printf("%d\n", sizeof(sizeof(int))); return 0; }
Is this portable at all?
There was only *one* reply yet (via personal email), and, alas, it
was not correct... :-)
Quoting Harbison/Steele's "C: A Reference Manual":
* 7.5.2 sizeof Operator
[...] In ANSI C the result of sizeof has the unsigned integer
type size_t defined in the header file stddef.h. Traditional C
implementations often use int or long as the result type [...].
* 11.2 NULL, ptrdiff_t, size_t, offsetof, wchar_t
[...] The type size_t is the unsigned integral type of the result
of the sizeof operator --- probably unsigned long; pre-ANSI
implementations use the (signed) type int for this purpose. [...]
Especially note the "fun" words like "often" or "probably". The
program prints 4 on Intel and HP-PA. It prints 8 on Alpha, but this
only by pure luck: %d expects an int (= 4 bytes) and was passed a
size_t = unsigned long = 8 bytes. If Alpha had another byte order,
it would have printed 0.
To make things even more confusing, consider integral promotion:
int i, j;
i = j * sizeof(...);
You could lose some of your bits during assignment here. I guess we
will all have much fun when Intel/HP release their Merced processor...
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
RTS API and 64bits
At the moment I'm trying to compile ghc-4.04 with ghc-2.10 on Alpha. Apart from some easily fixed issues I have the following question: In fptools/ghc/rts/RtsAPI.c the functions rts_getInt, rts_getInt32, rts_getWord, and rts_getWord32 return an (unsigned) int (= 4 bytes on Alpha), but pointers and longs are 8 byte on this architecture. Is this correct? Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Portability questions of the week :-)
What is the output of:
#include stdio.h
int main(void) { printf("%d\n", sizeof(sizeof(int))); return 0; }
Is this portable at all? %-} Whoever can answer these questions
immediately should have a look GHC's RTS, especially the calculation
of bit masks, shifts, ...
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: GHC warnings
Simon Peyton-Jones wrote: [...] They only show up if you compile the compiler with -DDEBUG, which I always do. The r.u.n warnings show up with the "normal" ghc, too, I'm 99% sure about this. And another one (only with -DDEBUG): What do the warnings "extendCSEnv: long list: ..." try to tell me? Am *I* doing something silly or ghc? :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: Can't compile HaskellDirect with GHC
George Russell wrote: [...] So we have a bug in GHC itself, with a non-exhaustive match in ghc/compiler/typecheck/TcMatches.lhs. The version of GHC is up to date (as of last night) from the CVS sources. [...] The same happens during the compilation of Green Card: [...] ghc -fvia-C -fglasgow-exts -recomp -Rghc-timing -O -H10m -c Lex.lhs -o Lex.o -osuf o TcMatches.lhs:274: Non-exhaustive patterns in function tcStmts Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Scanner Bugs
The new GHC lexer contains some small bugs: -- Foo.hs module Foo where forall :: Int forall = 1 -- Main.hs --- import Foo main :: IO () main = print forall -- panne@liesl:~ ghc -Wall -c Foo.hs ghc: module version changed to 1; reason: no old .hi file panne@liesl:~ ghc -Wall -c Main.hs ParseIface.hs:6496: Non-exhaustive patterns in case -- Similar games can be played with the identifiers foreign, export, label, dynamic, unsafe, ... And a small quiz: What's wrong with the following program? :-) (no EOL after the 1) -- Main.hs --- main = print 1 -- panne@liesl:~ ghc -c Main.hs Main.hs:1: Couldn't match `IO t' against `a - IO ()' Expected type: IO t Inferred type: a - IO () When checking that `main' has the required type Compilation had errors -- Small hint: -- Main.hs --- main = print True -- panne@liesl:~ ghc -c Main.hs Main.hs:1: Data constructor not in scope: `Tru' Compilation had errors -- Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: heap and other problems self-compiling 4.02
Thomas Pasch wrote: [...] But when it cames to compile ParselFace.hs in ghc/compiler/rename the Heap was exhausted. IIRC, -dcore-lint radically cuts down the heap required for the compilation of this module. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Renamer buglet in 4.03
It's just a bogus warning from ghc's renamer (updated from CVS today), but anyway, here it is: -- Foo.hs -- module Foo where class Readable a where readIt :: String - IO a readN :: (Integral a, Readable b) = a - String - IO [b] readN n = sequence . replicate (fromIntegral n) . readIt -- Bar.hs -- module Bar where import Foo read42 :: Readable a = String - IO [a] read42 = readN (42::Int) panne@liesl: ~ ghc -Wall -prof -auto-all -O -c Foo.hs ghc: module version changed to 1; reason: no old .hi file panne@liesl: ~ ghc -Wall -prof -auto-all -O -c Bar.hs Foo.hi:18: Warning: The universally quantified type variable `a' does not appear in the type `[PrelIOBase.IO b] - PrelIOBase.IO [b]' In the interface signature for `s' ghc: module version changed to 1; reason: no old .hi file Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
bug in 4.03's desugarer
Unlike previous versions, last Friday's GHC 4.03 doesn't like the following code anymore: module Foo where class Bar a where bar :: a - Int data Baz = forall a . (Bar a) = MkBaz a boo (MkBaz _) = return () panne@liesl:~ ghc -fglasgow-exts -O -c Foo.hs DsUtils.lhs:241: Non-exhaustive patterns in function rebuildConArgs Cheers, Sven P.S.: The CVS repository (i.e. solander.dcs.gla.ac.uk) is dead at the moment. traceroute tells me something about an unreachable host somewhere in Glasgow. :-( -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: Re2: GHC-4.03 heap managemen bug?
[ Just a "me too" from Munich :-] "Michael V. Nikolaev" wrote: [...] PrelArr.lhs compilation permanently completes with error: ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelArr -H8m -c PrelArr.lhs -o PrelArr.o -osuf o hsc: fatal error: scavenge_stack: weird activation record found on stack. make[3]: *** [PrelArr.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [all] Error 1 make: *** [all] Error 1 Alas, I have the same problem with today's ghc-4.03, too. Two days ago everything was fine. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
unsatisfactory diagnostic in GHC
Anyone who thinks that Hugs' diagnostic messages are unsatisfactory
should try the following snippet with GHC::-)
---
module Foo where
import Posix(fdToHandle)
bar = fdToHandle ``0''-- ``0'' should be: (intToFd ``0'')
---
panne@liesl:~ ghc -fglasgow-exts -syslib posix -c Foo.hs
panic! (the `impossible' happened):
ERROR: ``literal-literal'' not a single-constructor type: 0; type:
PosixUtil.Fd{-rD4,j-}
Please report it as a compiler bug to [EMAIL PROTECTED]
---
In the real program the ``0'' was actually something more complicated,
of course.
Cheers,
Sven
P.S.: The "lookupBindC:no info!"-bug from Feb 22nd is still in
yesterday's GHC... :-(
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
