Re: "GHC as a library" stalls when nobody is consuming it's output

Mads Lindstrøm wrote: While trying to implement a GUI for GHCi, I have run into an annoying concurrency problems. I think "GHC as a library" is at fault, as it stalls (maybe some deadlock) when nobody is consuming it's output. Thanks Mads, I took a look but didn't get to the bottom of the prob

Re: Locating shared libraries

adding -rpath to the linker flags. This adds two new entries in the .dynamic section (DT_RPATH, DT_RUNPATH) both responsible for signalling additional search paths to the dynamic linker, ld.so. According to Simon Marlow, Windows has similar mechanism via manifest files. Let's see how libtool

Re: Running multithreaded GHC on Itanium

Srđan Stipić wrote: I am currently trying to modify GHC 6.6.1 to run on Itanium in multithreaded mode (+RTS -N). Is it possible to do those modifications without generating back-end for Itanium? (If I am correct GHC on Itanium uses gcc to generate the code) It should be possible, all you have t

Re: Locating shared libraries

Bryan O'Sullivan wrote: Rich Neswold wrote: Actually, Haskell libraries ought to be placed in /usr/local/lib (or /usr/pkg/lib for systems that use the Package System: http://www.pkgsrc.org). They should go in $(libdir), as Simon suggests. If a particular OS wants to override libdir to put

Re: RTS/Garbage Collector idea

Isaac Dupree wrote: I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the "identical" heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the targe

Re: GHC Crosscompile

Cristian Perfumo wrote: Hi everybody: I would like to compile Haskell programs to run on Alpha architecture. As the target architecture is going to be simulated, I can't install GHC on an Alpha machine (because I don't have one). As most of you, I have got GHC installed and running on x86.

Re: Locating shared libraries

Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the unin

Re: 64-bit windows version?

Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw. The latest status update I could find is here: http://sourceforge.net/mailarchive/message.php?msg_id=4

Re: 64-bit windows version?

skaller wrote: On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw. Why do you need mingw? What&#

Re: 64-bit windows version?

Bulat Ziganshin wrote: Hello skaller, Tuesday, June 19, 2007, 8:15:19 PM, you wrote: are you plan to implement 64-bit windows GHC version? Why do you need mingw? What's wrong with MSVC++? really! Simon, how about unregisterised build? Unregisterised would still need a C compiler capable

Re: 64-bit windows version?

skaller wrote: On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote: I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly "free", and we want to retain the ability to have a complete

Re: 64-bit windows version?

Neil Mitchell wrote: Hi > I'm not sure I understand this. MS tools are free to download > by anyone, but not redistributable. The binaries needed by > programs *built* by those tools are not only free to download, > they're free to redistribute, and they're less encumbered than > almost all so-

Re: 64-bit windows version?

skaller wrote: GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena. Commercial programming is in a bad way! It NEEDS stuff like Haskell availab

Re: 64-bit windows version?

Peter Tanski wrote: skaller wrote: On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw

Re: 64-bit windows version?

Peter Tanski wrote: The make system does work well and must be kept in order to port GHC to a new posix platform--too many parallel projects (pun intended) work with the current system. I have not kept a good count of monthly configuration-based bugs but there are at least a few a month, for

Re: 64-bit windows version?

Peter Tanski wrote: Maybe this depends on the type of convenience you want to offer GHC-developers. With the autoconf system they are required (for Windows) to download and install: Mingw, perl, python (for the testsuite), flex, happy, alex and some others I can't remember right now. Oh yea

Re: 64-bit windows version?

skaller wrote: On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote: Ok, you clearly have looked at a lot more build systems than I have. So you think there's a shift from autoconf-style "figure out the configuration by running tests" to having a database of configurati

Re: 64-bit windows version?

Peter Tanski wrote: A bit invasive (it involves modifying the make rules so they take an object-suffix variable). Instead of the current suffix.mk: $(odir_)%.$(way_)o : %.hc it should be: $(odir_)%.$(way_)$(obj_sfx) : %.hc or some such. This may affect other builds, especially if for some

Re: 64-bit windows version?

Peter Tanski wrote: On Jun 22, 2007, at 11:42 AM, Simon Marlow wrote: Peter Tanski wrote: A bit invasive (it involves modifying the make rules so they take an object-suffix variable). Instead of the current suffix.mk: $(odir_)%.$(way_)o : %.hc it should be: $(odir_)%.$(way_)$(obj_sfx

Re: 64-bit windows version?

Peter Tanski wrote: I keep on referring to this as temporary because there are two different builds here: (1) the build using the old mingw-GHC, without option support for CL; and, (2) the build using the new Windows-native GHC. Yes. And what I'm suggesting is the following - what I've been

Re: -keep-hc-files or -keep-hc-file?

Ian Lynagh wrote: On Thu, Jun 28, 2007 at 03:46:31PM +0200, Christian Maeder wrote: Christian Maeder schrieb: I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates shows plural o

Re: Vote for GHC 6.8 bugs!

Tomasz Zielonka wrote: On Tue, Jul 03, 2007 at 09:28:35AM +0100, Simon Peyton-Jones wrote: We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! How should we separate email addresses? Right now peop

Re: Unexpected boxing in generated code

Simon Peyton-Jones wrote: | I've got an inner loop that I think I can see is strict in the Int | argument being passed around, but that GHC 6.6.1 isn't unboxing. In the | following example both functions take a GHC.Base.Int, which I think | should be an Int#. OK this is an interesting one. Here'

Re: Qualified identifiers opinion

Stefan O'Rear wrote: On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haske

Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition

Seth Kurtzberg wrote: I was not aware of the Eclipse support, so thanks for that information. However, Visual Haskell will not install on the full version of Visual Studio 2005 either. To make sure this was not an issue specific to my installation, I completely wiped a disk, installed Windows,

Re: :def and ghci command output

Claus Reinke wrote: ghci's :def takes a 'String -> IO String' and converts it into a ghci command. this makes it possible to pass a command parameter to a haskell function, and to interpret the result of the call as a ghci command. that is nice, but how do i get access to the command's output?

Re: [Haskell] ghc as a library and profiling

Sönke Hahn wrote: I am working on a program that uses ghc as a library to typecheck code. I want to profile the program (compiling with '-prof -auto-all' and running with '+RTS -p'). Trying to compile, results in the following message: Could not find module `GHC': Perhaps you haven't in

Re: compiling on solaris 9

skaller wrote: On Sat, 2007-09-15 at 11:09 +0200, Sven Panne wrote: On Friday 14 September 2007 16:33, Robert Andersson wrote: stdint.h seems to be unavailable on solaris 9. Looking at the rts/posix/OSMem.c file we find /* no C99 header stdint.h on OpenBSD? */ #if defined(openbsd_HOST_OS)

Re: Another compilation problem

David Schonberger wrote: Another newbie question. To recap, running 6.6.1 on Vista. Fixed the other problem--lexical error, apparently a BOM added by Notepad--by getting Xemacs. Now when I type 'ghc -o hello hello.hs' at the prompt I get /gcc: installation problem, cannot exec 'as': no such fil

Re: STG to JavaScript translation

Victor Nazarov wrote: Hello. I'm working on the translation of GHC's STG language to JavaScript. I've started my implementation, but I've got stuck with the STG case statements. The problem is the binder in case expression. StgCase expr livevars liverhsvars bndr srt alttype alts Operationally,

Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function

Olivier Boudry wrote: On 9/18/07, *Stefan O'Rear* <[EMAIL PROTECTED] > wrote: There is a flag to do this, and it's even In The Manual! http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085

Re: OSThreads in the RTS

Cristian Perfumo wrote: I am diving into the RTS, trying to identify where an OSThread is created and where it is destroyed (join). The idea is to read some hardware counters when it is just created and read them again when it is about to be destroyed (for the time being let's ignore, for the

Re: Determining GHC version use to compile an executable?

Don Stewart wrote: ravi: I was wondering if there was a clever way to determine the GHC version that was used to compile a particular executable. I looked in the RTS flags and didn't see anything obvious, but I was wondering if I missed something or if there was a clever back door. It's not a bi

Re: GHC benchmarks

Ketil Malde wrote: I've recently implemented some benchmarks for my library, and while I expected a slowdown for 64-bit code, I'm a bit bit surprised by the results. In summary: with 64 bit ghc 6.6.1, my benchmark runs in ~160 seconds with 32 bit ghc 6.6, it runs in ~ 95 seco

Re: GHC benchmarks

Ketil Malde wrote: Simon Marlow <[EMAIL PROTECTED]> writes: Not so much code size, but data size (heap size, to be more precise). Of course. There was some talk about storing tags in pointers for 6.8, I couldn't find the reference, but I wonder if that would help m

Re: 6.8.1-candidate tested

Serge D. Mechveliani wrote: Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the pr

Re: ghc --make-parallel ?

Johannes Waldmann wrote: Can ghc execute compilations in parallel? (With GNU make, I'd say "make -j 2" but how to achieve this with "ghc --make" ?) Sorry, not at the moment. We implemented a hacky version of it for our Haskell Workshop '05 paper: http://haskell.org/~simonmar/bib/multiproc

Re: Can't seem to figure how to compile

John Vogel wrote: Running ghc 6.6.1 On Windows Vista I get this error when I run: ghc Main.hs gcc: installation problem, cannot exec `as': No such file or directory This is a known problem on Vista. The GHC 6.8.1 snapshot should work for you, e.g. http://www.haskell.org/ghc/dist/stable/di

Re: ANNOUNCE: GHC 6.8.1 Second Release Candidate

Claus Reinke wrote: > adding more status/next action/deadline/actor fields would help, if trac > supports that (could be simple free-form text > fields, or selections), FYI, Trac is bringing us "customised workflows", which will allow us to do some of this: http://trac.edgewall.org/wiki/WorkF

Re: Too many local registers...

Simon Peyton-Jones wrote: We are working on a substantial re-engineering of GHC's code generation, so this problem will eventually go away. But think "2008" not "Christmas 2007". Meanwhile does -fasm work? There's no NCG for IA64, unfortunately. Unless someone writes one before 6.10, IA64

Re: 6.8.1 compilation error

Seth Kurtzberg wrote: While compiling the new release (6.8.1, with both the primary source and the extra libraries) I experienced a gcc error, gcc of course called by ghc. I’m compiling 6.8.1 with ghc 6.6.1. The gcc version is 4.1.1. I’ve seen similar behavior in the past where some sort of

Re: 6.8.0.x, 64 bits, and memory profiling

Ketil Malde wrote: I'm using heap profiling on AMD64, and I am getting some slightly strange results. Running the profiling, 'top' shows about 600Mb in use, but the resulting profile shows ~80Mb. Rerunning with -M200M results in an out-of-memory error. Could it be that the profile is calcul

Re: 6.8.1 compilation error

Seth Kurtzberg wrote: At this point I don't believe the problem that I reported is related to ghc, although I'm repeating things to bolster that conclusion. (As an aside, except for memory testing, the manufacturing test suite for the product I'm about to discuss is written in Haskell with just

Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)

Don Stewart wrote: It seems 10.5/PPC/6.8 is currently a lethal combination. (not x86 though, nor 10.4/ppc). Here's the ticket, add yourself to the CC list. http://hackage.haskell.org/trac/ghc/ticket/1843 We need a Mac hero (or heroes) who can diagnose and fix this problem. Any takers?

Re: ghc-6.8.1, +RTS -N2

Bulat Ziganshin wrote: Hello Johannes, Tuesday, November 13, 2007, 12:08:20 PM, you wrote: i suggest you to test it on one-threaded CPU too I just did. The behaviour is identical (works with -N1, segfaults with -N2) Any ideas? - Best regards, J.W. no. just publish this into maillist, i

Re: GHC 6.8.1 Build Failure on Mac OS X Intel 10.4.10

Denis Bueno wrote: On Nov 9, 2007 4:38 AM, Bjorn Bringert <[EMAIL PROTECTED]> wrote: I have this in my ~/.profile so that I don't have to keep giving flags to configure for every single thing I build against MacPorts libraries: export CPATH=/opt/local/include export LIBRARY_PATH=/opt/local/lib

Re: Binary for Vista 64-bit

Bulat Ziganshin wrote: Hello Chris, Sunday, November 11, 2007, 4:57:39 PM, you wrote: Just wondering if a binary for Vista 64-bit will be released? i've asked here June 19. Simon Marlow asked: The main thing standing in the way of this is the lack of a 64-bit port of mingw. The l

Re: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5

There seem to be several issues arising with GHC 6.8.1 on MacOS X with various combinations of 10.4/10.5/x86/PPC. So that we don't lose track, can someone (or someones) create the relevant tickets and keep them updated? To start with, here are the current tickets open for MacOS: http://hacka

Re: IArray (IOToDiffArray IOUArray) Bool : Why it doesn't exist ?

Chaddaï Fouché wrote: IOUArray Bool exists, and is even a bits array in reality (which makes it really efficient), is there any reason that DiffUArray Bool can't exist ? No good reason that I can think of, no. Cheers, Simon ___ Glasgow-haske

Re: ANNOUNCE: GHC version 6.8.1

Ian Lynagh wrote: Hi Philip, On Mon, Nov 05, 2007 at 09:58:40AM +0100, Philip K.F. Hölzenspies wrote: Booting libraries/base Booting libraries/directory /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS run info '(automake)Extending aclocal' or

Re: Unpacking across modules

Scott Dillard wrote: What is the interaction between the UNPACK pragma and modules? I've attached a small test case where a datatype is unpacked when it and its associated functions are defined in the same file in which they are used, but it is not unpacked if the definitions are given in anothe

Re: Top-level bindings for unlifted types

Neil Mitchell wrote: The following program: --- {-# OPTIONS_GHC -fglasgow-exts #-} module Test() where import GHC.Base test = realWorld# - gives the error message: Top-level bindings for unlifted types aren't

Re: State of parallel GC?

Bryan O'Sullivan wrote: Ravi Nanavati wrote: It isn't an immediately pressing need a Bluespec, but we do get asked every once in a while about parallelizing the Bluespec compiler. Roshan James was working on parallel GC at MSR Cambridge last year. Unfortunately, it's not an internship-sized

Re: GHC 6.8.1 on powerpc OS X 10.5

Chris Kuklewicz wrote: Running "../utils/genprimopcode/genprimopcode --primop-tag" produces "Illegal instruction" There were other odd messages during the make,such as in this early output: == make boot -r; in /Users/ch

Re: GHC 6.8.1 on powerpc OS X 10.5

Chris Kuklewicz wrote: (gdb) run --make /tmp/t.hs -o /tmp/t Starting program: /Users/chrisk/Documents/projects/haskell/build/ghc-6.8.1/ghc-6.8.1/compiler/stage2/ghc-6.8.1 --make /tmp/t.hs -o /tmp/t Reading symbols for shared libraries +..+... done Program received signal EXC_BAD_ACCESS, Could

Re: Windows overlapped IO

Felix Martini wrote: I have made a prototype for overlapped IO that works with a modified version of Takano Akio's SSC library. Great! (I don't know what Takano Akio's SSC library is though) I have been trying to add it to GHC's IO implementation but there are some issues. Instead of file de

Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)

Christian Maeder wrote: Ian Lynagh wrote: On Sat, Nov 17, 2007 at 03:02:55PM +, C.M.Brown wrote: Is there a way for GHC on OS X to find where it was run from, so that it can find package.conf? The command: ghc --print-libdir should do it. But the way that knows what to print on unix mac

Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)

Christian Maeder wrote: Alfonso Acosta wrote: On Nov 19, 2007 10:51 AM, Alfonso Acosta <[EMAIL PROTECTED]> wrote: Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script

Re: GHC 6.8.1 on powerpc OS X 10.5

t to Apple about the fact that 'ld' seems (to me) to write scattered PPC_RELOC_HI16 segments which it cannot read and recognize. Corey O'Conner : you are debugging ld as well. Does the 'ld' code look broken to you (as detailed in my earlier reply to your message) ? Cheers,

Re: ghc 6.8.1 windows link issue ?

Fernand wrote: Fernand a écrit : Dear all, Giving a try to GHC 6.8.1 under Windows, I stumble upon the following issue (yes, I'm struggling with HDirect), which did not occur with the 6.6 version : the linking phase of my project fails with Actually, the issue appears with the following prog

Re: ghci changes in 6.8 that are not improvements

Alex Jacobson wrote: 1. just using : at the prompt caused a reload. Now you have to type :r. Interesting, I was not aware of that behaviour, so probably fixed it by accident :) 2. reload now reloads all modules rather than just the modules that changed (faster but not as fast as not reload

Re: suggestion: add a .ehs file type

Alex Jacobson wrote: I'm fine with that as well. I'm just opposed to being force to look up the precise names the compiler happens to use for each language extension I happen to use. Having -fglasgow-exts turned on by default also works. -fglasgow-exts is a historical relic. It's just an a

Re: label syntax vs DisambiguateRecordFields

Simon Peyton-Jones wrote: | Nice feature but feel like a band-aid. In particular it makes SYB style | programming more difficult because field labels aren't types. | | Almost every other record syntax plan involves field labels as types so | you can do interesting type dispatch. Record systems

Re: ghci changing 'm' to 'g'

Yitzchak Gale wrote: Quoth InteractiveUI.runGHCi: case maybe_expr of Nothing -> do #if defined(mingw32_HOST_OS) -- The win32 Console API mutates the first character of -- type-ahead when reading from it in a non-buffered manner. Work -- aro

Re: suggestion: add a .ehs file type

ags that tells it not to issue them. In any case, I'm pretty sure the correct answer is not 50 language pragmas with arbitrary spellings for various language features at the top of each source file. -Alex- Simon Marlow wrote: Alex Jacobson wrote: I'm fine with that as well. I&#x

Re: suggestion: add a .ehs file type

wrapper for GHC #!/bin/sh exec ghc -XTemplateHaskell -XFlexibleInstances ... $* I'm sure there are more... Cheers, Simon -Alex- Simon Marlow wrote: Alex Jacobson wrote: I'm fine with that as well. I'm just opposed to being force to look up the precise names the compiler happens t

Re: suggestion: add a .ehs file type

Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syntax. If you can parse the source, then you know which extensions it uses. I thought we'd already established that this isn't possible. Here are some code fragments that parse differently depen

Re: Profiling bugs in 6.8.1 and 6.6.1

Daniel Fischer wrote: Hello, first let me remark that 6.8.1 is really remarkable, compiles faster and produces faster executables than 6.6.1. However, I have a problem with profiling, the time is always reported as 0.00 secs: Sun Nov 25 22:58 2007 Time and Allocation Profiling Repor

Re: suggestion: add a .ehs file type

t parses a strict superset of Haskell98 - and that's hard to achieve. Cheers, Simon I am not taking a position here on the merits of any extensions. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syn

Re: Top-level bindings for unlifted types

fer to disallow them. Cheers, Simon On 13/11/2007, at 13:08, Simon Marlow wrote: Neil Mitchell wrote: The following program: --- {-# OPTIONS_GHC -fglasgow-exts #-} module Test() where import GHC.Base test = realWorld#

Re: suggestion: add a .ehs file type

ndex of the user's guide so should probably be turned off. I have no idea what it does. Note, in all cases where the extension is turned on by default, there should be a language pragma to turn it off. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Simon, from what I can tell, wi

Re: ghci changes in 6.8 that are not improvements

Lemmih wrote: On Nov 30, 2007 12:36 PM, Simon Marlow <[EMAIL PROTECTED]> wrote: Alex Jacobson wrote: $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskel

Re: ghci changes in 6.8 that are not improvements

Alex Jacobson wrote: $ darcs get http://happs.org/HAppS-Begin $ cd HAppS-Begin $ curl http://searchpath.org/searchpath/SearchPath.hs > SearchPath.hs $ ghc --make SearchPath.hs -o sp $ sp ghci -ihaskell haskell/Main.hs Prelude> :r I don't see any unnecessary reloading here: Ok, modules loade

Re: GHC porting to FreeBSD-amd64 progress report

W.B. Kloke wrote: In my effort to produce a working FreeBSD-amd64 compiler I made some progress. Now I have a working stage1/ghc-inplace (which is a 32bit executable producing 64bit code). But the compilation of rts fails in file Apply.cmm with the following message: == gmake all -r; in /.amd_m

Re: GHC porting to FreeBSD-amd64 progress report

Wilhelm B. Kloke wrote: Simon Marlow <[EMAIL PROTECTED]> schrieb: Perhaps you compiled mkDerivedConstants as a 32-bit executable? Yes. I was not attentive enough. But now I have got a working compiler on FreeBSD-amd64-7.0. If anybody is interested, I shall prepare a package of the ins

Re: ghc vs ghci: why can't ghci do everything ghc can do?

Claus Reinke wrote: 3) suggestions: a) could we have a :make command in ghci that doesa 'ghc --make' while reusing the information fromthe current session? Doesn't :set -fobject-code :reload do that? b) could we have a --prefer-source option for ghci, so

Re: GHC generated dll makes Excel crash on exit.

Olivier Boudry wrote: On Dec 3, 2007 10:07 AM, Simon Peyton-Jones <[EMAIL PROTECTED] > wrote: It's not part of the Haskell documentation! The FFI page http://haskell.org/haskellwiki/GHC/Using_the_FFI is part of the "contributed documentation", linked fro

Re: Leopard: ghc 6.8.1 and the case of the missing _environ

Joel Reymont wrote: Symptoms: You build 6.8.1 from source on Leopard (x86 in my case) and then junior:ghc-6.8.1 joelr$ ghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help ghc-6.8.1: /usr/local/lib/ghc-6.8.1/lib/base-3.0.0.0/HSbase-3.0.0.0.o: unknown symbol `_environ' Loading pac

Re: Leopard: ghc 6.8.1 and the case of the missing _environ

Chris Kuklewicz wrote: MacOS folks: is this still an issue? If so, could someone create a ticket? Cheers, Simon The issue for MacOS (10.5 Leopard) on powerpc is still http://hackage.haskell.org/trac/ghc/ticket/1843 But we suspect that there is more than one issue, since my patch for the

Re: ghc vs ghci: why can't ghci do everything ghc can do?

Claus Reinke wrote: btw, it would still be nice to have ghci limitations (vs ghc) summarized on a wiki page. i've seen fragments here and there, but no complete list answering my questions. :set -fobject-code :reload ah, thanks! i had forgotten about that one. it doesn't solve my main p

Re: C Preprocessor

Wolfgang Jeltsch wrote: Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? Yes, it is. There is cpphs () as an alternative. Yes,

Re: C Preprocessor

Neil Mitchell wrote: Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings. There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's

Re: Problems building and using ghc-6.9

Daniel Fischer wrote: Then I tried to build zlib-0.4.0.1: $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base >=2.0&&<2.2 ??? okay, there was something with flag bytestring-in-base, removed that, so

Re: Which ghc versions can build ghc-6.8.1?

Gregory Wright wrote: Can 6.4 build 6.8.1? Or is a later version required? We test the GHC build with 6.2.2, and the latest released version (previously 6.6.1, now 6.8.1). It's not unlikely that bugs have crept in that make the build fail with 6.4.x; if you find any such bugs then please

Re: More spam problems on trac

Tim Chevalier wrote: It seems the new thing for spammers to do is to add spam text wrapped in the tag. For example, http://hackage.haskell.org/trac/ghc/wiki/WikiStart?action=diff&version=106 I don't know if anyone else has noticed this. Maybe it's time to require captchas for account creation o

Re: [Haskell-cafe] class default method proposal

Duncan Coutts wrote: On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero wrote: On Dec 13, 2007 2:05 PM, Claus Reinke <[EMAIL PROTECTED]> wrote: try %HOMEDRIVE% %HOMEPATH% instead? Doesn't work either. you might have set %HOME% to help some unix software along, but this variable doesn't seem to exist by default. It worked in 6.8.1. With whi

Re: upgrading visual studio integration to use 6.8.2....

Nicholls, Mark wrote: I’ve just downloaded the vs integration package….which looks great….but it comes with 6.6.1, and I was hoping to move to 6.8.2….does anyone know how to do this? No, someone needs to rebuild Visual Haskell using 6.8.2, and test it etc. There have been lots of changes in b

Re: upgrading visual studio integration to use 6.8.2....

se it was trivial.but I'd much prefer it to be in VS. -Original Message- From: Simon Marlow [mailto:[EMAIL PROTECTED] Sent: 13 December 2007 16:22 To: Nicholls, Mark Cc: glasgow-haskell-users@haskell.org Subject: Re: upgrading visual studio integration to use 6.8.2 Nich

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero wrote: On Dec 14, 2007 3:53 PM, Simon Marlow <[EMAIL PROTECTED]> wrote: But do you really want getHomeDirectory to return $HOME? Yes! If I define %HOME, it is *exactly* because I don't want to use Windows' idea of a home directory (which could be perhaps

Re: ANNOUNCE: GHC version 6.8.2

Juanma Barranquero wrote: %HOME% is the de-facto standard for Unix-like shell applications that were ported to Windows and need a home directory. If someone sets that, it means they want to use the folder in that way. And yes, that is the way GHCi has been working until now, so I think it should

Re: ANNOUNCE: GHC version 6.8.2

Yitzchak Gale wrote: Removing support for %HOME% has suddenly broken many programs. If people don't like it, we can consider deprecating it in some future version of GHC, but for now it should put back. Only GHCi has changed here. Perhaps you're under the impression that we recently changed

Re: ForeignPtr performance

Bulat Ziganshin wrote: Hello Scott, Sunday, December 16, 2007, 11:57:33 PM, you wrote: My question is: what exactly does GHC.Prim.touch# do? This appears to it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc optimizer that data were accessed so it doesn't free the memory

Re: ForeignPtr performance

Scott Dillard wrote: Thanks for the response guys. I'm still curious as to the specific mechanism by which a strictly compile-time function affects the run-time behavior of the GC. Bulat says that touch# makes the runtime aware that the fptr object is still in use, but how does it do this if, at

Re: ANNOUNCE: GHC version 6.8.2

Felix Martini wrote: On Dec 16, 2007 10:56 AM, Duncan Coutts wrote: Note that for data files like the .ghci file it's probably better to use getAppUserDataDirectory "ghci" which will return $HOME/.ghci on unix systems and "C:/Documents And Settings/user/Application Data/ghci" on Windows. I've

Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2

Benjamin L. Russell wrote: This fixed the problem, and on Windows XP Professional, I was able to set GHCi to find .ghci in %HOMEPATH%, which turned out to be c:\Documents and Settings\. However, I would like to override this setting, and either have GHCi look for .ghci in %HOME%, as opposed to %

Re: ANNOUNCE: GHC version 6.8.2

alpheccar wrote: Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ? I had no problems to build the 6.8.1 but with 6.8.2, I get the error: ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist

Re: [Haskell-cafe] Re: #haskell works

Bulat Ziganshin wrote: Hello Simon, Thursday, December 20, 2007, 4:01:59 PM, you wrote: Fixing it all properly means some fairly significant architectural changes, and dropping the via-C backend oh, thank you. from my POV, C backend still may be used together with "non-registerized" compiler

Re: --make should not touch the -o file if it doesn't change it

Alex Jacobson wrote: Right now, if you recompile with --make, the exeutable gets a new timestamp. That seems incorrect. Is this a bug? If the executable was re-linked, then it gets a new timestamp, since the file's contents have changed, but if no compilation or linking was required, then t

Re: <.> defined in GHC and System.FilePath

Neil Mitchell wrote: The GHC API uses the <.> operator, which clashes with System.FilePath. Possibly this might want renaming to something else - I have absolutely no idea what it does! Prelude> :m GHC Prelude GHC> :i <.> (<.>) :: HsWrapper -> HsWrapper -> HsWrapper-- Defined in HsBinds I

<    2   3   4   5   6   7   8   9   10   11   >