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: [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(): 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: 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
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: 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
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
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 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
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: idea to allow ghci to use a different libs list
Am Mittwoch, 7. Dezember 2005 12:21 schrieb Duncan Coutts: > On Fri, 2005-12-02 at 11:06 +, Simon Marlow wrote: > > On 30 November 2005 12:29, Duncan Coutts wrote: > > > Attached is a simple code change to allow packages to specify a > > > different list of "extra libraries" to link with when using the ghci > > > and dlopen/LoadLibrary compared to when using the native system > > > linker. > > > > Yes to the idea in principle; please go ahead and complete the patch. > > Ok, attached is the full patch. It has to be in two parts since the > darcs repos for ghc and the libraries are separate. > > I've briefly tested the change. I built Gtk2Hs with ghc-6.5 with the > patch. I modified (and registered) the gtk.package.conf file so that it > specified: > > extra-libraries: "gtk-x11-2.0", [...snip...], "pthread" > extra-ghci-libraries: "gtk-x11-2.0", [...snip...] > [...] Hmmm, I haven't followed the thread too closely, but aren't we just hacking around the real cause here? Wouldn't it be better to teach GHCi's linker about the ld scripts, at least in a very basic form? My concern is that the proposed hack puts additional burden onto the autoconf magic of package developers and makes doing "the right thing" portably quite tricky, I guess... Cheers, S. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: cc1plus.exe not included in Win32 distro
Am Dienstag, 18. Oktober 2005 01:58 schrieb Sigbjorn Finne: > It was intentionally removed (the intention being to remove > heft from the installer) after it had been unintentionally > included for quite a while. > > The rule has always been that only tools that GHC depends > upon to operate are bundled with it on the mingw side -- > the only exception to that rule has been the recent inclusion > of 'ar'. > > Should GHC binary dists include a C++ compiler? I'd say > no, but if there are practical and compelling reasons to do > so, it's no big deal to re-include the binary. Well, the main three files which are missing are cc1obj.exe, cc1plus.exe and cpp0.exe. Together they are 2.4MB (bzip2-ed), which is not that much compared to a 35MB installer. 6.4.1 should be a patchlevel release, so I'd argue to *not* remove any functionality in 6.4 and re-include the stuff. Perhaps we can leave it out in the next major release, but leaving it in the installer is not a big deal IMHO. Hmmm, I guess that cc1obj.exe is for ObjectiveC and cc1plus.exe is for C++, but what is cpp0.exe? 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: ghc.exe: panic! (the `impossible' happened, GHC version 6.3): urk
Satnam Singh wrote: I was trying to build GHC 6.3 for Windows and got the following error: [...] ghc.exe: panic! (the `impossible' happened, GHC version 6.3): urk [...] IIRC, I had the same problem 1-2 weeks ago, but SPJ fixed it already in the CVS HEAD. Could you try again after updating, please? Cheers, S. P.S.: I think that text mails are preferred in this group, not HTML ones... ___ 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: -fvia-c doesn't work
Simon Marlow wrote: [...] OK, after a couple more strange experiences, whereby -fvia-c sometimes worked and sometimes did not, depending on what directory I was in, I finally determined that the failure happened only when I had a file called "stdint.h" in the current directory. So apparently, since a straight call of gcc does not display the same problem, the search path given to gcc by ghc somehow has . before the standard location of /usr/include? Thanks for tracking this down. For a workaround, you can say ghc -I- ... this causes ghc to pass '-I-' to gcc, which causes gcc to interpret all the include paths as applying only to includes of the form #include "...". Includes of the form #include <...> will be searched for in the system directories only. Put the -I- after any other -I options on the ghc command line. I've made this change in GHC, but I probably won't merge it into 6.2.2 because it's only of those changes that could easily cause something else to break, so we need plenty of testing. FYI: This change breaks things quite badly, e.g. a simple #include fails for me now, because /usr/include/GL/glut.h contains #include "freeglut_std.h" But with -I-, /usr/include/GL/freeglut_std.h will not be found. A quick grep through the system header on my SuSE 9.1 shows that there are dozens of similar #includes. If I can't find a fix for this, I'll revert the change. Hmmm, why do we use a "-I ." in the first place...? 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: Testing stderr seemed horribly fragile to me, though: who knows what people may or may not opt to write to stderr in various versions of "ar" now or in the future? That's why I thought looking for concrete evidence that the right thing actually had happened might be a more solid solution. Nope, testing for stderr is not fragile: Any tool which writes to stderr during normal execution is doing something horribly wrong. Testing stderr for evidence when the tool is known to return wrong exit codes is standard autoconf practice. The problem with your approach is portability, e.g. "dd" is a bit unusual in autoconf tests, and I'm not sure if the find option "-size +10k" is really portable. The rules of the autoconf game are: "Use incredibly simple shell commands to detect ridiculously complex features." :-] 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: 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
[ 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
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: 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: Cool! What file(s) do I need to update? I just did a cvs update this was all I got: $ cvs -q -z3 update ? CONTRIB/haskell-modes/hugs/.new.hugs-mode U CONTRIB/haskell-modes/hugs/hugs-mode.el Somehow I don't envision hugs-mode.el being part of the problem... I guess you are using anonymous CVS, which is only a mirrored version of the "real thing", lagging up to one day behind IIRC. This is rather unfortunate and should probably be changed (Jeff?). Meanwhile I've attached a patch. Btw, how useful is it to report bugs against cvs HEAD? I know different projects use cvs HEAD differently... Bug reports for the HEAD are highly appreciated, although [EMAIL PROTECTED] is a more appropriate place for them. I'm not sure about its moderation policy, though. Cheers, S. Index: mk/package.mk === RCS file: /home/cvs/root/fptools/mk/package.mk,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- mk/package.mk 23 Jan 2004 13:37:40 - 1.35 +++ mk/package.mk 7 Feb 2004 14:08:57 - 1.36 @@ -1,5 +1,5 @@ # - -# $Id: package.mk,v 1.35 2004/01/23 13:37:40 simonmar Exp $ +# $Id: package.mk,v 1.36 2004/02/07 14:08:57 panne Exp $ ifneq "$(PACKAGE)" "" @@ -24,11 +24,11 @@ package.conf.inplace : package.conf.in $(CPP) $(RAWCPP_FLAGS) -P $(PKGCONF_CPP_EXTRA_OPTS) -x c $(PACKAGE_CPP_OPTS) $< | \ - sed -e 's/""//g' -e 's/, ]/ ]/g' >$@ + sed -e 's/""//g' -e 's/\[ *,/[ /g' >$@ package.conf.installed : package.conf.in $(CPP) $(RAWCPP_FLAGS) -P $(PKGCONF_CPP_EXTRA_OPTS) -DINSTALLING -x c $(PACKAGE_CPP_OPTS) $< | \ - sed -e 's/""//g' -e 's/, ]/ ]/g' >$@ + sed -e 's/""//g' -e 's/\[ *,/[ /g' >$@ # we could be more accurate here and add a dependency on # ghc/driver/package.conf, but that doesn't work too well because of ___ 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: 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 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 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: __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: __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: 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: ghc-pkg 6.2 incorrectly parses commas within quotes
Ashley Yakeley wrote:
The 6.2 version of ghc-pkg is incorrectly parses commas within quotes. [...]
This was a side-effect of a slighty obscure feature of ghc-pkg. I've made
things more robust now. From the CVS log:
--
Fixed the previous commit: All lists of Strings in package configuration files
were split at commas to allow list-based variables, but this broke perfectly
sensible things like
["-Wl,-rpath,/usr/lib/jvm-bridge/lib/"]
into
["-Wl","-rpath","/usr/lib/jvm-bridge/lib/"]
which is plainly wrong. Now we do this *only* when a variable occurs on its own,
like:
["${deps}","foo"] => ["base","haskell98","network","foo"]
I have slight doubts about this obscure feature, but Sigbjorn seems to want
it...
--
I can't see a good workaround, either, so you'll probably have to wait for the
next release... :-(
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
DEPRECATED not re-exported
There seems to be a small problem with the DEPRECATED pragma (both on the HEAD and the 6.2 release branch), see e.g. the deprecated function withObject: -- Main1.hs -- import Foreign.Marshal main = withObject 'a' print -- Main2.hs -- import Foreign.Marshal.Utils main = withObject 'a' print -- [EMAIL PROTECTED]:~> ghc Main1.hs [EMAIL PROTECTED]:~> ghc Main2.hs Main2.hs:2:7: Warning: Variable `withObject' is deprecated: use `with' instead -- It looks like deprecations are not re-exported, but I can't remember if this was a conscious design decision or simply happens by accident. Nevertheless, with the arrival of hierarchical modules, the current behaviour makes this pragma almost useless IMHO. Other opinions? 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: "Unused"ness 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: RFunE: "Unused"ness 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: 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: aclocal bug
Donald Bruce Stewart wrote: [...] This issue doesn't not occur with autoconf-2.57, but I think I read yesterday we were trying to keep >=2.50 compatibility :) Fixed, thanks. FYI: At least 2.52 is what we really need... Cheers, S. ___ 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
Simon Marlow wrote: > AFAICT, GHC on Windows has always done this quoting, the change was > to make GHC on Unix do it too. [...] Well, after some investigation of GHC's history, I came to the conclusion that quoting for -D and -U options on *nix has been a special case in pre-6.0 GHCs: -DFOO=BAR was passed as -D'FOO=BAR', but as "-DFOO=BAR" on WinDoze. The latter done on all platforms now, which is not very nice, but at least consistent. So I surrender and I will adapt my Makefile (as soon as I have a new GHC ready). Text substitution as a parameter passing mechanisms REALLY sucks... 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
Simon Marlow wrote: > [...] Perhaps we should be using single quotes instead. This would be a little bit more backwards compatible, so this is probably the way to go IMHO. OTOH, this might break arguments with a single quote in them, but they are probably much less common. > But in any case, just removing the double quotes from your -D option > should be enough to fix it. Well, fixing my humble Makefile is not the point, I'm more concerned about this gratuitous change in the handling of quoting which breaks other people's Makefiles. Regardless of the solution, th quoting issue should be documented in the GHC docs somehow. 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: problem compiling OpenGL/.../Extensions.hs with GHC version 6.0
Andres Loeh wrote: > [...] The problem (that can be witnessed by calling ghc with the > option -v) is that in calling the C preprocessor, the double quotes > around the value of GET_PROC_ADDRESS, which are syntactically > necessary, are no longer present. The problem can be fixed by > quoting the double quotes once more, i.e. by saying > > SRC_HC_OPTS += -DCALLCONV=ccall '-DGET_PROC_ADDRESS=\"glXGetProcAddressARB\"' > > However, this is a change in behaviour compared to earlier versions > of ghc that seems undesireable to me ... [...] I'm currently developing within the build tree of the HEAD from May 24th, and the double quotes *do* come through. If newer GHCs changed that behaviour, that would truly suck and probably breaks lots of Makefiles out there. I guess I'll have to build a new GHC to investigate this further... >:-( Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC version 6.0
Ralf Hinze wrote: > Compiling 6.0 from source fails with: [...] This only happens for WinDoze builds with --enable-hopengl and can easily be fixed: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/Makefile.diff?r1=1.17&r2=1.17.2.1 As you probably already have noticed, the OpenGL stuff in the hierarchical libraries is currently untested on WinDoze platforms, but in theory it should work. [EMAIL PROTECTED] is the right place to complain... :-} 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: [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
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: 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: 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: FFI: passing 6 FD arguments doesn't work
This was a bug in GHC's native code generator for SPARC, which sometimes misaligned the stack pointer. This has already been fixed in CVS (HEAD and branch), but it didn't make it into 5.04, see: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/nativeGen/MachCode.lhs.diff?r1=1.100&r2=1.101 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: Instruction Cache Flush in createAdjustor on SPARC
Wolfgang Thaller wrote: > [...] Can anyone with sparc experience think of a reason why cache flushing > should _not_ be necessary here? Synchronizing the data/instruction caches *and* the caches of different processors (most people forget the latter) is necessary for both PowerPC and SPARC. 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: 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 when using unpackCStringIO on strings > 65 KB
Christian Lescher wrote: > [...] I discovered that unpackCStringIO (module CStrings, package lang) > produces a stack overflow when applied to strings > 65 KB, which seems a > little strange to me. Is this a bug - or at least a too stack-intensive > implementation of unpackCStringIO? A comment from CString.lhs: NOTE: unpackCStringIO must traverse the entire string before returning, since it is often used on dynamically allocated strings which need to be deallocated after unpacking. This is done in a slightly stack-intensive way and could be hacked to stress the heap instead. But this will probably never happen, as this part from CString is effectively dead and deprecated, see http://www.haskell.org/ghc/docs/5.00/set/sec-cstring.html for a better alternative. > [..] BTW: For passing back the string result, I use an addional C function > "mallocAndStrCpy". Can I do without by replacing it with some Haskell > code? Again, have a look at the vastly improved libraries supporting the FFI. Only downside: AFAIK, there is no 5.00 for Windoze yet... :-} Cheers, Sven ___ 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:
Robert Will wrote: > [...] it works without -O, doesn't with -O2 Neither ghc-4.08 nor the CVS version have this problem, so you should probably upgrade, these versions are much more stable than 4.05 anyway. And -fvia-c should probably be -fvia-C. GHC doesn't always report unknown options (we should definitely fix that). 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: 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: 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 = x > 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
Re: Integer arithmetic broken (again)
Marc van Dongen wrote: > I downloaded the latest version of ghc from CVS yesterday, [EMAIL PROTECTED] might be the more appropriate list. > rebuilt and noticed that the Integer arithmetic is broken again. Could you send a (small) program exhibiting *what* is broken? Guessing one of the many numerical operations on Integers is a little bit hard... :-) > I decided to rebuild because of an email from yesterday that > suggested that gcd had been improved---but I may have understood > this incorrectly. GCD on Int/Integer now uses the GMP lib, not the generic version for Integral types. Furthermore, compile-time constant folding in general has been improved (or broken by me :-} since 4.06, so it could be a bug there, too, so an example would really be helpful. 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: bug in foreign import (for floats)
I wrote:
> [...] So you should write:
>
>...
>import CTypes(CFloat, CInt, CChar)
>foreign import floatByte :: CFloat -> CInt -> CChar
>...
I forgot the other way round: If you want to match the Haskell side
foreign import floatByte :: Float -> Int -> Char
just #include "HsFFI.h" and write
HsInt floatToInt (HsFloat fl) { ... }
HsChar floatByte (HsFloat fl, HsInt idx) { ... }
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:
> ghc-4.06 (downloaded from the ftp site; I haven't tried the current
> CVS version) appears to have a bug in the FFI, demonstrated by the
> following code using Floats. [...]
> /tmp/ghc9891.hc:256: warning: implicit declaration of function `floatToInt'
> [...]
Aaaah, a classic C bug! :-) Without a prototype float is widened
to double, so floatToInt only accesses one half of the value. GHC
should really emit a prototype into the .hc file, too (Simon{,M}?)
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. So you should write:
...
import CTypes(CFloat, CInt, CChar)
foreign import floatByte :: CFloat -> CInt -> CChar
...
This guarantees that the signatures match in the expected way.
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: allocaElem in ghc-4.07
Marcin 'Qrczak' Kowalczyk wrote: > > allocaElem :: Storable a => a -> (Addr -> IO a) -> IO a > should be > allocaElem :: Storable a => a -> (Addr -> IO b) -> IO b > and similarly allocaElems. OK, I've changed it that way. It makes sense e.g. for in-parameters. 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
Re: PANIC Line 84 causes panic
Which GHC version are you using? WIth the upcoming 4.07 one gets panne@marutea:~ > ghc Stimulus.hs Stimulus.hs:84: parse error on input `}' Compilation had errors which is the correct message. 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 can't make DrIFT
George Russell wrote: > Er what is going on here? CVS sources from this morning, building > with GHC binary release. [...] Splitting object files was broken, but this has already been fixed in the CVS yesterday. I don't know when exactly things get copied to anon CVS. 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: Posix.FileMode
Simon Marlow wrote:
> [...] In the meantime, you can add a 'deriving Eq' to the definition
> of FileMode in PosixFiles.lhs to get Eq. Integral needs some more
> hackery [...]
I've just added `deriving Eq' to the CVS sources, but nothing more.
Everything else (e.g. Ord, Integral) is a hack, anyway: What's the
point of being able to divide two FileModes or test if a FileMode is
even? :-) Eq plus nullFileMode/{union,intersect}FileModes is all
you need for constructing and testing FileModes.
> > BTW, is it really necessary to have separate
> > {union,intersect}fileModes
> > and nullFileMode instead of using Bits..{|,&}. and 0?
>
> not really. But Bits came after Posix, so that's why it's this way.
... and it's good that it is *not* an instance of Bits: Why should we
allow e.g. rotating FileModes?
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
Splitting object files
Somehow -split-objs disappeared from the build process, so the object files in the Prelude and hslibs are not split => monstrous executables. As usual, I'm building GHC from CVS. 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
Sven Panne wrote: > 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. Times are changing fast... I've just seen that the restless folks in Cambridge have fixed this, so you should be able to bootstrap 4.07 with 4.06 directly, including -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.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
Re: cvs: make all -> error PackedString.lhs
Marc van Dongen wrote: > Just to let jou know. I just updated and tried to rebuild > ghc from cvs. I then got: > > PackedString -c PackedString.lhs -o PackedString.o -osuf o > [...] I've already fixed that one (and a related bug in ghc itself) yesterday evening. But I don't know when exactly these changes are mirrored in the anonCVS. A note for GHC-from-CVS afficionados: Due to versionitis which is not reflected in GHC's version number, you probably have to temporarily downgrade to 4.06 to bootstrap 4.07 (or edit ghc/utils/FastString.lhs). This is not my fault, but I know who's the guilty one... ;-) 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: Enum instance for Ratio
Malcolm Wallace wrote: > I'd say that this is a bug in the Library Report, which seems to > specify this implementation. [...] But for Float, Double, Ratio and friends the report explicitly states that numericEnumFromFooBar has to be used, which generates the finite list. So it's only a bug in all implementations. >:-) 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
_ is not always small (syntactically :-)
GHC's lexer (function Lex.mk_var_token) treats names starting with an underscore followed by an uppercase letter as a constructor (conid) and not as a variable (varid): module Foo where data T = _ThisWorksAlthoughItShouldNot _ThisShouldWorkButItDoesNot = '?' A comment in the source code tells something about syntax in interface files, but I don't have clue... Could somebody (SimonM?) explain why this is done that way? 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
> 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: 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
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: Result type signatures cause parse errors
Marcin 'Qrczak' Kowalczyk wrote: > f x :: Int = 4 You have to write `f (x :: Int) = 4' and use -fglasgow-exts in this case. > g = case [] of [] :: Int -> 4 [] is definitely not an Int :-) , so this should read e.g. `g = case [] of ([] :: [Int]) -> 22', and again -fglasgow-exts is needed > They work only in lambdas. Hmm, strange. Given h1 = \ x :: Int -> 11 h2 = \ x :: Int y :: Bool -> 22 h3 = \(x :: Int) (y :: Bool) -> 33 h1 and h3 work, h2 does not. I wonder why h1 and h3 *do* work... 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 -M' 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
