Re[2]: package lang
Hello Bulat, Saturday, July 8, 2006, 8:00:52 AM, you wrote: >> which refers to a package called "lang". > it was a part of ghc 6.4, but gone in 6.5. try to remove this package i'va found this package sources. all these modules now are part of 'base' package, they just has different names, say ArrayBase -> Data.Array.Base. you should just omit this package from .cabal file and change import statements to mention new hierarchical names of the same modules > I looked in the list of packages at: > http://www.haskell.org/ghc/dist/stable/docs/libraries/index.html look at http://www.haskell.org/ghc/dist/stable/docs/hslibs/index.html which lists old H98-style packages which uses plain names of modules look at info about each module - it says which new module form Base package supersedes it -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: package lang
Hello Doaitse, Friday, July 7, 2006, 10:24:38 PM, you wrote: > which refers to a package called "lang". it was a part of ghc 6.4, but gone in 6.5. try to remove this package dependency from .cabal file and see which functions will not be found at compilation. after that you can search existing packages to find which package contain these functions now you can download 6.5 sources from http://www.haskell.org/ghc/dist/current/dist and look at the directory "libraries" which contains one subdir for each package -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
package lang
I had to witch rather urgently to a new machine (an Intel based Mac OS X), on which I need to get lhs2TeX running. I have installed the ghc version from the page: http://cvs.haskell.org/trac/ghc/wiki/X86OSXGhc but when i try to compile lhs2TeX I get the following error message: /usr/local/bin/ghc -O -package lang --make -o lhs2TeX Main.lhs TeXCommands.lhs TeXParser.lhs Typewriter.lhs Math.lhs MathPoly.lhs MathCommon.lhs NewCode.lhs Directives.lhs HsLexer.lhs FileNameUtils.lhs Parser.lhs FiniteMap.lhs Auxiliaries.lhs StateT.lhs Document.lhs Verbatim.lhs Value.lhs Version.lhs ghc-6.5.20060608: unknown package: lang which refers to a package called "lang". I looked in the list of packages at: http://www.haskell.org/ghc/dist/stable/docs/libraries/index.html which does not mention a package by that name. Also at http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs this package seems to be unknown. The list of packages that apparently was installed with the compiler are: /usr/local/lib/ghc-6.5.20060608/package.conf: ALUT-2.0, Cabal-1.1.4, GLUT-2.0, HGL-3.1, HUnit-1.1, OpenGL-2.1, QuickCheck-1.0, X11-1.1, base-1.0, fgl-5.2, (ghc-6.5.20060608), haskell-src-1.0, haskell98-1.0, mtl-1.0, network-1.0, parsec-2.0, readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, time-0.3.1, unix-1.0 So my questions are: - what did I do wrong (I apologize for not being an able installer) - where can I find a package by the name "lang" - what is the next step to take Doaitse ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
On Fri, Jul 07, 2006 at 11:28:44AM +0100, Simon Marlow wrote: Hi, > We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be > released without a fix for this. I'm actually quite glad that we've > forced this into the open with 6.4.2, otherwise the bug would probably > have remained dormant, affecting only those who used -threaded on Sparc. Solaris x86 has similar bugs with the RTS (like mentioned in previous posts). A summary: 6.4 branch from cvs changed the occurrence a bit - it is harder to reproduce it - but possible - and now it segfaults (before - 6.4.2 - it hanged). To try a debug enabled -threaded version of ghc and follow http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes is on my TODO list. Regards Georg Sauthoff pgpr4GbL3eY5d.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
killed process
Malcolm Wallace schrieb: > A process can be "Killed" by the operating system if the machine runs > out of virtual memory. I suspect someone else is running a cron job on > Tuesdays that fills memory. Yes, I also run other jobs and the load is high. In fact the OOM-killer kills ghc-6.4.2 several times as is shown in the log messages. Probably ghc is requesting memory then. Other jobs are not killed, though. Cheers Christian OOM = out-of-memory ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
On Fri, 2006-07-07 at 11:28 +0100, Simon Marlow wrote: > We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be > released without a fix for this. I'm actually quite glad that we've > forced this into the open with 6.4.2, otherwise the bug would probably > have remained dormant, affecting only those who used -threaded on Sparc. As far as I know this does not affect Sparc Linux, only Sparc Solaris. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -threaded
On 07 July 2006 11:46, Christian Maeder wrote: > Simon Marlow schrieb: >> The reason we added it to the compiler was so that you could use >> programs that require -threaded under GHCi. Without it, these >> programs cannot be used with GHCi. > > Surely, running user programs is different from just compiling. GHC and GHCi are the same binary. >> Without -threaded, all FFI calls block the other threads in the >> program, and this makes it impossible to do lots of things. > > Obviously, I only want that (my old) sequentiell things are done as > reliable (one at a time) as before. And they will be - the threaded RTS only affects FFI calls on multithreaded programs. >> What version of glibc are you using on Linux? > > glibc-devel-2.3.4-23.4 > glibc-locale-2.3.4-23.4 > glibc-info-2.3.4-23.4 > glibc-html-2.3.4-23 > glibc-2.3.4-23.4 > glibc-i18ndata-2.3.4-23.4 I guess that isn't it, I have 2.3.2 here. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Simon Marlow schrieb: > The reason we added it to the compiler was so that you could use > programs that require -threaded under GHCi. Without it, these programs > cannot be used with GHCi. Surely, running user programs is different from just compiling. > Without -threaded, all FFI calls block the other threads in the program, > and this makes it impossible to do lots of things. Obviously, I only want that (my old) sequentiell things are done as reliable (one at a time) as before. > What version of glibc are you using on Linux? glibc-devel-2.3.4-23.4 glibc-locale-2.3.4-23.4 glibc-info-2.3.4-23.4 glibc-html-2.3.4-23 glibc-2.3.4-23.4 glibc-i18ndata-2.3.4-23.4 C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder wrote: Simon Marlow schrieb: Gregory Wright wrote: Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD. Could you summarize the advantages (or need) of the threaded RTS? The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi. In general, -threaded is the way forward, and at some point I hope we can make it the default (I was considering this for 6.6, actually). Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things. It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. What version of glibc are you using on Linux? There were bugs in glibc that could cause deadlocks occasionally, I remember having to upgrade glibc on our RedHat 9 box a while back. We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder <[EMAIL PROTECTED]> wrote: > It doesn't work under solaris and under linux [1] my nightly > compilation jobs are "killed" every tuesday morning (!) for some > reason that i cannot reproduce. I suspect the threaded RTS and heavy > load. I had no such problems with ghc-6.4.1 before. A process can be "Killed" by the operating system if the machine runs out of virtual memory. I suspect someone else is running a cron job on Tuesdays that fills memory. It is unlikely to be (only) ghc's fault. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
Gregory Wright wrote: A quick question: does the darcs repository have go back to 6.4.1? (The place to start looking a diff of the RTS from 6.4.1, which worked, and 6.4.2 or HEAD, which doesn't). No, 6.4.x is in CVS only. ghc-6-4-branch of CVS, to be precise. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -threaded
Christian Maeder schrieb: > > Could you summarize the advantages (or need) of the threaded RTS? > > It doesn't work under solaris I'm quite content with my non-threaded 6.4.2-cvs version under solaris (and I was already looking for a switch -non-threaded under linux). C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-threaded
Simon Marlow schrieb: > Gregory Wright wrote: >> Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by >> disabling the threaded rts, but that is not acceptable solution. > > This is a good datapoint, because it probably rules out much of the > threaded RTS code in the RTS itself, which has changed significantly > between 6.4.x and HEAD. Could you summarize the advantages (or need) of the threaded RTS? It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. As a friend of pure functions I hate such a non-deterministic behaviour of a (mere) compiler. Cheers Christian [1] http://www.haskell.org/ghc/dist/6.4.2/ghc-6.4.2-i386-unknown-linux.tar.bz2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
Hi Simon, On Jul 7, 2006, at 4:26 AM, Simon Marlow wrote: Gregory Wright wrote: I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD. A quick question: does the darcs repository have go back to 6.4.1? (The place to start looking a diff of the RTS from 6.4.1, which worked, and 6.4.2 or HEAD, which doesn't). If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD? No preference, since it's probably the same bug in both. Use whatever's easiest for you. I'll work with HEAD. Best Wishes, Greg Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X / PowerPC
Gregory Wright wrote: I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD. If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD? No preference, since it's probably the same bug in both. Use whatever's easiest for you. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
[EMAIL PROTECTED] wrote: "Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: Brian Hulley wrote: | import A.B.C( T1 ) from "foo" | import A.B.C( T2 ) from "bar" | type S = A.B.C.T1 -> A.B.C.T2 | I'd suggest that the above should give a compiler error that A.B.C is | ambiguous (as a qualifier), rather than allowing T1 to disambiguate it, But that's inconsistent with Haskell 98. FWIW, I agree with Brian that this is not good practice. If it can't be forbidden, I would suggest that compilers emit a warning about it. Is there really a case where someone would use that pattern intentionally? I'd vote for making it an error by default. Perhaps then a flag would be available that says "accept dangerous constructs that are legal according to Haskell 98". The Haskell 98 behavior compensates for the case where the module you used to import Old (foo,bar) has been split into two new modules, A(foo) and B(bar). You can import A as Old and B as Old so that Old.foo and Old.bar now resolve to A.foo and B.bar. I expect the pattern for the above would actually be closer to > import Old(T1,T2) from "original" > > mine :: Old.T1 -> Old.T2 becoming > import qualified A.B.C(T1) as Old from "foo" > import qualified D.E.F(T2) as Old from "bar" > > mine :: Old.T1 -> Old.T2 Which is a syntax that should be supported. -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
> "Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: > >> Brian Hulley wrote: > >> | import A.B.C( T1 ) from "foo" >> | import A.B.C( T2 ) from "bar" >> | type S = A.B.C.T1 -> A.B.C.T2 > >> | I'd suggest that the above should give a compiler error that A.B.C is >> | ambiguous (as a qualifier), rather than allowing T1 to disambiguate >> it, > >> But that's inconsistent with Haskell 98. > > FWIW, I agree with Brian that this is not good practice. If it can't > be forbidden, I would suggest that compilers emit a warning about it. Is there really a case where someone would use that pattern intentionally? I'd vote for making it an error by default. Perhaps then a flag would be available that says "accept dangerous constructs that are legal according to Haskell 98". > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Packages and modules
"Simon Peyton-Jones" <[EMAIL PROTECTED]> writes: > Brian Hulley wrote: > | import A.B.C( T1 ) from "foo" > | import A.B.C( T2 ) from "bar" > | type S = A.B.C.T1 -> A.B.C.T2 > | I'd suggest that the above should give a compiler error that A.B.C is > | ambiguous (as a qualifier), rather than allowing T1 to disambiguate it, > But that's inconsistent with Haskell 98. FWIW, I agree with Brian that this is not good practice. If it can't be forbidden, I would suggest that compilers emit a warning about it. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
